Need to add buttons or links inside the calendar

I need to add buttons or links inside the calendar (inside date box)

You can use a custom template to replace the default templates with something that works better for you: https://mattlewis92.github.io/angular-bootstrap-calendar/#!?example=custom-templates


Lazy-load settings pages (and split out bots code).

This code handles the settings pane for "Your account," which
has email/name/password/avatar/etc.

Automated message from Dropbox CLA bot
@showell, it looks like you've already signed the Dropbox CLA. Thanks!

Merged the changes so far; leaving the PR open so we you can just keep adding here.

@timabbott If you are happy with the approach here and merge it, then the next logical step would be to do the same cleanup process for admin.js, which is every bit as huge as settings.js was.  The whole process of splitting things up actually wasn't super painful, since there aren't nasty dependency coupling.  But I think there might be a little more current activity with admin.js.

Looks great, merged, thanks @showell!
I agree doing the same with admin.js makes sense.  We should think a bit about naming with that process -- it's possible we want to use the settings_ prefix for all of those pieces as well, rather than "admin" which is in the process of being deprecated.
I think the main big thing going on with the admin pages is #4454, which we should definitely merge before you start doing the split.  We can use @adnrs96's TinglingGit tool to scan for anything else significant likely to conflict.

One more thought as a follow-up to this -- I think we can probably refine some of the code in server_events.js related to settings changes to run conditionally on the relevant part of the settings UI having been rendered.

Yeah, blunt-force live-updates are probably mostly harmless, but with increased modularization, we can probably be smarter about it.


NTLM Authentication Error

We've been using PyExchange to read appointments in an Outlook calendar in work, and recently after a seemingly unrelated code release have been getting "FailedExchangeException: Unable to parse response from Exchange - check your login information. Error: None". I've narrowed the error down to when the ExchangeNTLMAuthConnection sends "request = urllib2.Request(self.url, data=body, headers=headers)" to our company's Exchange URL, it's getting an empty string from "urllib2.urlopen(request).read(). I've tried reading another URL with this method and it returns data, I can't figure out why it's getting an empty string here. The login details haven't been changed or altered in the db where they're stored. Can anyone help?

This turned out to be a password issue, unsurprisingly.


minify/tdewolff says TypeError but can't reproduce

Hi @privatenumber , what do you use to verify the validity of the minification output? It says "TypeError" for all minify/tdewolff outputs, but loading the minified output in Firefox or Chrome works fine (no errors), and putting it in ESLint gives no relevant errors (tested with moment.js).
Is the library outdated? Have you tried using https://www.npmjs.com/package/@tdewolff/minify?

It seems to be using version 0.5.2.
There's work to update to the npm registry in https://github.com/privatenumber/minification-benchmarks/pull/234, but it's blocked due to an unrelated problem.

To unblock the PR, I did a quick patch on my end to convert it back to CommonJS:
// https://nodejs.org/api/esm.html#no-native-module-loading
const { string, config, file } = require('node-gyp-build')(__dirname);

// Starting from node 16, json imports have been unflagged
// import pkg from "./package.json" assert { type: "json" }
const version = require('@tdewolff/minify/package.json').version;

module.exports = {
	string,
	config,
	file,
	version,
};

Was there a reason your package needs to be in module mode?
Using a CommonJS module might be something you want to consider as the file is just re-exporting via require().

Thanks for the quick fix, and amazing the improvement in speed!
Regarding modules, it is my understanding that ES modules is the new standard way and that CommonJS modules is specific to NodeJS? If this is not the case I can convert it to a CommonJS module, there is no specific need from the library, just trying to be up-to-date with technology ;-)

No problem and congrats on the fastest minifier!
ESM is the new standard but it's negated if only used to createRequire and create a CommonJS dependency.
I would keep it CommonJS unless you can figure out how to load tdewolff-minify without using any CommonJS.

Not exactly sure what you mean, it seems to me that loading with ESM works well: https://github.com/tdewolff/minify/blob/master/bindings/js/test/index.js. But to be honest I don't know much about the subject...

Yes, it works, but I'm saying there's no benefit to using ESM because you do require() via createRequire instead of import.
Changing it to CommonJS (code snippet I posted above) will also still be loadable from ESM because ESM cam parse CommonJS exports.


Adding text format serialization / deserialization

Per issue #36, this adds protobuf text format serialization and deserialization. To load a text format protobuf into a message, you use
let message = try Message(text:protobufText)

and to serialize it out to text, you use
try message.serializeText()

I'll admit, this is a bit of a hack, in that I copied over the JSON serialization / deserialization files and modified those until they matched the protobuf text format. A ton of code is therefore replicated between these files and could be abstracted out to a shared set of text/JSON input and output code.
My unit tests are rudimentary, but they exercise the data types from the Proto3TestAllTypes class, which seem to cover the available data types. I'm sure that I'm not handling all error cases correctly.
I've tested this against a series of complex .prototxt text format files from the Caffe framework, and all of them appear to load correctly.

Thanks for the comments. I'll see if I can clean up the easier elements first (mostly copy-paste items left over from the JSON parsing code), then move on to expansion of the tests. The JSON tests and some of the commented code are artifacts left over from my experimentation, and I simply forgot to pull them out when I reviewed this earlier.
This was just the minimum viable implementation to do what I needed, so there's a lot to clean up inside it. I'll see what I can do to improve it per these suggestions.

Sorry it took me so long to respond, I had a few other things come up in the meantime.  I've updated the pull request per many of the review comments above:

Renamed the Test_Text.swift file to Text_Text_proto3.swift to give room for proto2 tests.
Removed the leftover JSON tests that I'd been using for debugging purposes.
Split the text encoding tests into one per field type, and added some failure cases.
Added tests for repeated items.
Shorthand bracket syntax for repeated fields is supported, and added a test for that.
Removed identified commented-out code.
Removed left-over debugging statements.
Removed unnecessary (_) pattern matches in case statements.

These are issues that I haven't addressed yet, due to the limited time I've had to work on this:

Failure test cases are not exhaustive.
Not sure what to do about the errors that refer to JSON error cases.
Not sure if I should combine the JSON and text numeric parsers, haven't dug into this: https://github.com/google/protobuf/blob/master/src/google/protobuf/text_format.cc#L900
Haven't addressed the differences in group name capitalization from here: https://github.com/google/protobuf/blob/master/src/google/protobuf/text_format.cc#L445
Don't handle text format unknown fields at present: https://github.com/google/protobuf/blob/master/src/google/protobuf/text_format.cc#L1928
I don't verify string escaping per here: https://github.com/google/protobuf/blob/fd046f6263fb17383cafdbb25c361e3451c31105/src/google/protobuf/stubs/strutil.cc#L579
The "-Infinity" and similar cases need to be tested against Google's C++ implementation to make sure this is the correct coding.

If these are still blockers, I can keep working on the remaining issues.

I looked through the C++ unit tests some and have a few thoughts:

I see no short-term need for duplicating the excessive number of formatting options supported by the C++ version.  Our encoder does not need to support UTF-8 and non-UTF8, "short" vs. "long" vs. "single line mode", configurable indent level, etc.

Our text format decoder probably should support all of these, of course.  The C++ unit tests give a lot of examples we can use to build our own unit tests.

Especially given that our unknown field support for protobuf binary is still evolving, I don't feel an immediate need to handle that for protobuf text format.

For ObjC TextFormat generation I did utf8 only (Apple's tool chains generally do better with utf so there didn't seem to be a need to do non utf8); I did support an optional initial indent, but that was in part because I reused TextFormat generation for -description.
If we are going to support TextFormat parsing, we do need to support parsing all forms as they could come from any other implementation (or be hand written).

@BradLarson:  I just sent you a PR with a number of new tests that I cribbed from the C++ unit test suite.  Let me know if this is helpful...

I'm going to reconcile this with #139 today and hopefully fix some of the other outstanding issues with it.

@BradLarson:  I just pushed a bunch of work into my branch of this.  In particular:

I restructured everything to match the new file organization (most files define just one type, filenames mostly match the type of that name, many of the Protobuf prefixes are gone)
I rewrote the token struct and most of the scanner to better match protobuf text conventions (e.g., protobuf text has both an 'identifier' literal and a 'string' literal)
I copied a bunch more tests from the protoc C++ test suite (lots more to go!)

With the above, I think I have most of the repeated field handling, octal and hex numeric literals, and a number of other things working.  I haven't yet looked at groups, maps, extensions or the proto3 Well-Known Types.
Let me know what you think...

Oh, yeah:  I also got bytes encoding/decoding working pretty completely.

@tbkka - My apologies on being slow on the response. Had a few things that drew me away at work. I'll see if I can't review all this tomorrow.

Although still incomplete, I think #169 is getting close.  Any feedback greatly appreciated.

Given the work that tbkka's done on this over a #169, I'll close this out in favor of that pull request.


Failed to add ACL to volume

Hi there,
I gave truenas-csp a try but can't get a pod mount a volume. Pod description at start shows the following:
AttachVolume.Attach failed for volume "pvc-8a464e26-5d41-499a-a151-4d99f895a25c" : rpc error: code = Internal desc = Failed to add ACL to volume Data_K8s_pvc-8a464e26-5d41-499a-a151-4d99f895a25c for node &{ debian-k8s cc2cb9e8-24c5-16f2-766e-3c0059f3be1c [0xc0005a9e00] [0xc000803110 0xc000803120 0xc000803130 0xc000803140 0xc000803150 0xc000803160 0xc000803170 0xc000803180 0xc000803190 0xc0008031a0 0xc0008031b0 0xc0008031c0 0xc0008031d0] []  } via CSP, err: Request failed with status code 500 and errors Error code (Exception) and message (Traceback (most recent call last):
File "/app/truenascsp.py", line 151, in on_put
'initiator': initiator.get('id')
AttributeError: 'list' object has no attribute 'get'
Same message is seen on the trunas-cps provisioner pod:
Sat, 06 May 2023 17:27:05 +0000 backend INFO Volume found: Data_K8s_pvc-8a464e26-5d41-499a-a151-4d99f895a25c
Sat, 06 May 2023 17:27:06 +0000 backend INFO Volume found: Data_K8s_pvc-ad63e81c-52d0-48e7-ad82-54893b606451
Sat, 06 May 2023 17:27:06 +0000 backend INFO Host updated: cc2cb9e8-24c5-16f2-766e-3c0059f3be1c
Sat, 06 May 2023 17:27:06 +0000 backend INFO Host updated: cc2cb9e8-24c5-16f2-766e-3c0059f3be1c
Sat, 06 May 2023 17:27:06 +0000 backend ERROR Exception: Traceback (most recent call last):
File "/app/truenascsp.py", line 151, in on_put
'initiator': initiator.get('id')
AttributeError: 'list' object has no attribute 'get'.
I'm using Kubernetes 1.27.1 on a debain 11.7 VM. Using latest version of hpe-storage and truenas-csp manifests. This happens on both TruneNAS Core and TrueNAS Scale (always latest versions) via iSCSI (as the guide shows).
By the way: I see the provisioner is using APIv1, is there a way to force/set APIv2? Would it make any difference?
Thank you!

Thanks for reporting this. It appears this call returns more than one initiator. I found one occurrence this could happen and fixed that, but this is yet another corner case.
If you don't mind, would you want to test this image: quay.io/datamattsson/truenas-csp:v2.3.0-initfix?

Looking at the logs there I'm assuming that you're provisioning a workload with two PVCs attached on a completely fresh system?
Another workaround is to delete one of the duplicate initiators that got created in the publishing process.

Looking at the logs there I'm assuming that you're provisioning a workload with two PVCs attached on a completely fresh system?
Another workaround is to delete one of the duplicate initiators that got created in the publishing process.

That's correct! I just tested the storage provisioner with a pihole instance that requests 2 PVCs for the same pod.

Thanks for reporting this. It appears this call returns more than one initiator. I found one occurrence this could happen and fixed that, but this is yet another corner case.
If you don't mind, would you want to test this image: quay.io/datamattsson/truenas-csp:v2.3.0-initfix?

Sure, I'll test it and give you a feedback!

That's correct! I just tested the storage provisioner with a pihole instance that requests 2 PVCs for the same pod.

Makes sense. If the initiator doesn't exist on the backend (TrueNAS) and two or more requests comes in at the same time, the same initiator gets created twice and will cause problems in the staging phase.

Tested with new image you mentioned but still fails. I see again 2 identical initiators created:

This time the provisioner complains about something else:
Sat, 06 May 2023 20:59:18 +0000 backend INFO Volume found: Data_K8s_pvc-ea371f8c-1175-408c-a581-ee9ca8a27215
Sat, 06 May 2023 20:59:18 +0000 backend INFO Volume found: Data_K8s_pvc-97f910f6-454d-43d4-9b47-1cdaae1233ad
Sat, 06 May 2023 20:59:18 +0000 backend INFO Host updated: cc2cb9e8-24c5-16f2-766e-3c0059f3be1c
Sat, 06 May 2023 20:59:18 +0000 backend INFO Host updated: cc2cb9e8-24c5-16f2-766e-3c0059f3be1c
Sat, 06 May 2023 20:59:18 +0000 backend ERROR Exception: Traceback (most recent call last):
File "/app/truenascsp.py", line 167, in on_put
req_backend['auth_networks'] = api.ipaddrs_to_networks(discovery_ips)
File "/app/backend.py", line 120, in ipaddrs_to_networks
for alias in interface['aliases']:
TypeError: string indices must be integers

Tested with new image you mentioned but still fails. I see again 2 identical initiators created:

The duplicate initiator being created is a race I don't think I can mitigate. Living with it is what the patched image fixed.

This time the provisioner complains about something else:

Oh, I think I know what this is. Either you have the hpe-csi portal misconfigured or just one IP address assigned to it?

Tested with new image you mentioned but still fails. I see again 2 identical initiators created:

The duplicate initiator being created is a race I don't think I can mitigate. Living with it is what the patched image fixed.

This time the provisioner complains about something else:

Oh, I think I know what this is. Either you have the hpe-csi portal misconfigured or just one IP address assigned to it?

It is a homlab, only 1 IP address is assigned for TrueNAS/iSCSI portal:

I was not aware that there must be more than 1 IP available. It would make sense in a PROD env though. Is there a workaround for this?

Tested with new image you mentioned but still fails. I see again 2 identical initiators created:

The duplicate initiator being created is a race I don't think I can mitigate. Living with it is what the patched image fixed.

This time the provisioner complains about something else:

Oh, I think I know what this is. Either you have the hpe-csi portal misconfigured or just one IP address assigned to it?

It is a homlab, only 1 IP address is assigned for TrueNAS/iSCSI portal:

I was not aware that there must be more than 1 IP available. It would make sense in a PROD env though. Is there a workaround for this?
P.S: I could add a second IP to TrueNAS I guess

Added a second IP to the portal but issue persists:

Is there somethins else I need to do on the provisioner side?

Added a second IP to the portal but issue persists:

I'm trying to reproduce this on my end. Do you only have one NIC on this system? (configured or not)

I'm trying to reproduce this on my end.

I got it broken now. It's the single NIC that is causing issues. I'll have a new image shortly.

Added a second IP to the portal but issue persists:

I'm trying to reproduce this on my end. Do you only have one NIC on this system? (configured or not)

Yes, only one NIC at the moment. I added a second IP to the same NIC but it's still not working. Everything is running in a virtual environment, I could add a second NIC and split IPs (one per NIC) for testing purposes, but to be honest this exceeds the idea of having a simple homelab setup :)

Ok, this image quay.io/datamattsson/truenas-csp:v2.3.0-initfix-sif should work. You can remove your additional IP address, it's not needed.

quay.io/datamattsson/truenas-csp:v2.3.0-initfix-sif

Yes sir!!! Pod mounted both volumes without issues. Provisioner logs are clean:
Sat, 06 May 2023 22:25:52 +0000 backend ERROR Not found: Volume with name pvc-444aa725-5c30-4984-a051-79249897721f not found.
Sat, 06 May 2023 22:25:52 +0000 backend ERROR Not found: Volume with name pvc-367e95d4-3dc0-4276-bee7-0c9bb1048ce3 not found.
Sat, 06 May 2023 22:25:53 +0000 backend INFO Volume created: pvc-367e95d4-3dc0-4276-bee7-0c9bb1048ce3
Sat, 06 May 2023 22:25:53 +0000 backend INFO Volume created: pvc-444aa725-5c30-4984-a051-79249897721f
Sat, 06 May 2023 22:26:33 +0000 backend INFO Volume found: Data_K8s_pvc-444aa725-5c30-4984-a051-79249897721f
Sat, 06 May 2023 22:26:33 +0000 backend INFO Volume found: Data_K8s_pvc-367e95d4-3dc0-4276-bee7-0c9bb1048ce3
Sat, 06 May 2023 22:26:33 +0000 backend INFO Host updated: cc2cb9e8-24c5-16f2-766e-3c0059f3be1c
Sat, 06 May 2023 22:26:33 +0000 backend INFO Host updated: cc2cb9e8-24c5-16f2-766e-3c0059f3be1c
Sat, 06 May 2023 22:26:34 +0000 backend INFO Volume published: Data_K8s_pvc-444aa725-5c30-4984-a051-79249897721f
Sat, 06 May 2023 22:26:34 +0000 backend INFO Volume published: Data_K8s_pvc-367e95d4-3dc0-4276-bee7-0c9bb1048ce3
Sat, 06 May 2023 22:26:42 +0000 backend INFO Token created (not logged)
Sat, 06 May 2023 22:26:42 +0000 backend INFO Volume found: Data_K8s_pvc-444aa725-5c30-4984-a051-79249897721f
Sat, 06 May 2023 22:26:44 +0000 backend INFO Volume found: Data_K8s_pvc-367e95d4-3dc0-4276-bee7-0c9bb1048ce3
Thanks a lot for your quick support!!!

Thanks a lot for your quick support!!!

You're most welcome and thank you for working with me on this! These fixes will be part of the next release.

Fixed in #42


System {"type":"systemConfig"} not found

Qinglong version
2.17.11
Steps to reproduce
系统设置--依赖设置，点开就报这个错误System {"type":"systemConfig"} not found
What is expected?
修复
What is actually happening?
重新拉的也会这样，最新的版本也有这个问题，然后青龙跑不了京东的脚本
System Info
No response
Any additional comments?
No response

https://github.com/whyour/qinglong/issues/2472


Refactor starknet_getEstimateFee + getEstimateFee error handling

Pull Request type

Please check the type of change your PR introduces:

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, renaming)
[X] Refactoring (no functional changes, no API changes)
[ ] Build-related changes
[ ] Documentation content changes
[ ] Testing
[ ] Other (please describe):

What is the current behavior?

Issue Number: #397
What is the new behavior?

starknet_estimateFee method now takes BlockId & BroadcastedTransaction parameters instead of BlockId and String.
starknet_estimateFee now can throw BLOCK_NOT_FOUND, CONTRACT_NOT_FOUND and CONTRACT_ERROR errors via BeerusApiError

Change starknet_estimateFee param from String to BroadcastedTransaction
Add error handling for starknet_estimateFee (proposal for handler multiple types of errors), as described in the Starknet standard, estimateFee can throw the following errors:

Does this introduce a breaking change?

[X] Yes
[ ] No

Changing the method param of starknet_estimateFee
Other information

Synced with @dubzn to check this. Here a brief recap:

We have seen that lot's of work is done in starknet-rs about typings and codegen from the spec. So @dubzn will propose a rework of this PR based on those observations to stick to the generated code that have high chance to become the source of truth for all Rust-based implementation of starknet projects.

Even if the JSON-RPC spec of Starknet has a very defined set of errors, we have a situation. The implementation MUST deal with invalid value. For instance, if the error code sent back by the node in the response is 500000, we can't map that to an actual value of the specification. For this reason, dub will explore a way to correctly handle this.

Finally, for ETH endpoints, we will remove any abstraction possible to work with helios types as much as possible, to ensure that future users of Beerus (that may use helios today) can find the exact same API.

Dub will probably integrate this PR in the other PR more generic with all endpoints.
@dubzn will focus on only on Starknet endpoints.

@phklive @drspacemn this is the debrief from @dubzn and I after syncing today on this. :+1:

Okay great, let's see what that translates in in terms of code and let's go 👍


Energy totalizers

In the integration the Energy Totaliziers are not implemented. I tried to solve it by myself, but without success.

Added in release 1.1.0.


scripts: Move node info into common sourceable scripts

Just the one cleanup, then looks good.

@dghubble Updated


GDNative default parameters cause breaking changes

The dodge_the_creeps example in godot-rust, which uses Input::is_action_pressed(), no longer compiles with Godot 3.4.
Reason is an API change in GDNative:

Class Input for Godot 3.3:

Class Input for Godot 3.4:

The extra parameter exact is optional, which is a non-breaking change in GDScript and C++, but a breaking one in Rust, since the language does not support default parameters.
There are likely more places in the GDNative API with such changes. At the moment, they make it impossible for godot-rust to support multiple Godot minor versions simultaneously. Either we find a way to support such APIs in Rust, or we can only support the latest minor version.

Related: https://github.com/godot-rust/godot-rust/issues/291 https://github.com/godot-rust/godot-rust/issues/264

The extra parameter exact is optional, which is a non-breaking change in GDScript and C++, but a breaking one in Rust, since the language does not support default parameters.
There are likely more places in the GDNative API with such changes. At the moment, they make it impossible for godot-rust to support multiple Godot minor versions simultaneously. Either we find a way to support such APIs in Rust, or we can only support the latest minor version.

There was once a proposal to introduce call-builders on Discord, but it appears that it has never been formalized as a feature proposal on GitHub. The idea being:

A builder type is generated for all methods with optional arguments. Calling is_action_just_pressed would look something like input.is_action_just_pressed_ex("action_name").exact(false).call().
The non-builderized version of the method will always contain only the required arguments (so the addition of an optional argument won't be breaking).

However, there were a few issues for which no consensus was found:

What the method name should look like, how collisions (however unlikely) should be handled, and whether "raw" versions with full optional arguments should be kept.
What should happen if a builder is dropped unused. The safest option is to just "do nothing", but some have argued that the method should get called on drop, even if that would result in a call order that's probably not the intention. #[must_use] can help prevent this in practice, but it doesn't make the type linear.
Whether binary compatibility should be part of this new improvement. Failure to provide an optional argument when calling a method through ptrcall is UB. Claiming binary compatibility would require abandoning ptrcalls.
What happens when optional arguments are provided out of order (e.g. when the second optional argument is provided while the first is not). One simple way to handle this, that could be used in an initial implementation, would be to simply panic whenever this is detected, but that's not what is usually expected from a builder pattern. Eventually, this should be changed, but doing so requires parsing the highly irregular serialization format that is used for default values in api.json.

On a broader view, there is the question of what "engine compatibility" actually means. For reference, there are currently two definitions of a compatible engine in the README:

The minimum compatible engine version (MCEV), with api.json replacement. This is currently Godot 3.2.  Changing this version would require a breaking semver. The specific problem described in this issue does not require a change to the MCEV.
The default API version (DAEV), which is currently Godot 3.2.3-stable. What would happen when this version changes does not appear to be clearly defined, but if a change is expected to break user code, I would assume that it would require a breaking semver. The specific problem described in this issue requires a change to the DAEV.

It seems to me that if current policies are followed, changing the DAEV to Godot 3.4 would:

Require a breaking semver release.
Not require reverting the compatibility promises to "only the latest minor version", as the top comment suggested.

Thanks for the insights, great that some thought already went into it!
Call-builders sound like a highly sophisticated solution, although I have some more basic concerns:

Is compatibility with multiple Godot versions a feature that many users benefit from? Obviously it's nice to have, but when it comes at a cost (more cumbersome function calls), we'd need to consider the trade-offs. Maybe it turns out that most people either pin a godot-rust version or are able to freely update Godot minor versions, and we would make our sometimes already verbose API even more awkward to use.

The suggestion works for default parameters, but what about other breaking changes, like change of types, function names, etc? The Godot versioning guide only says:

The minor version is incremented for feature releases which do not break compatibility in a major way. Minor compatibility breakage in very specific areas may happen in minor versions, but the vast majority of projects should not be affected or require significant porting work.

In other words, best-effort and breaking changes can happen at any time.

There are two scenarios, I don't know if it makes sense to treat them differently?

GDNative API exposed through bindings changes in a breaking way. This may be the result of the user deliberately selecting a different engine version, but may leave godot-rust working otherwise.
GDNative API used by godot-rust itself breaks. This mostly affect the central classes Object, Reference etc. This would need some feature-gating or separate release.

I agree with you that changing the DAEV would require a new minor release of godot-rust.

1. Is compatibility with multiple Godot versions a feature that many users benefit from?

This is one of the things that is very hard to tell, due to selection bias. We don't see anyone benefit from the feature, not because it isn't truly useful, but because at this point in time, nobody has maintained a godot-rust codebase over a long period yet. User polls are also unlikely to be useful in this case, because developers who have released, or plan to release commercial games, that can actually benefit from the feature, are far outnumbered by developers that never even plan to release anything serious. If user demographics are followed blindly, you'd end up with something that appeals entirely to novices and of dubious value to veterans -- like the YouTube tutorial scene.

2. The suggestion works for default parameters, but what about other breaking changes, like change of types (often not breaking in C++), function names, etc?

Those would be changes to DAEV, but not MCEV, and thus in line with the current commitment described in README.
An approach like #496, but limited to minor versions, used to select different pre-generated -bindings crates, could be used as a way to hit a stable 1.0 even if such changes occur.

There are two scenarios, I don't know if it makes sense to treat them differently?

GDNative API exposed through bindings changes in a breaking way. This may be the result of the user deliberately selecting a different engine version, but may leave godot-rust working otherwise.
GDNative API used by godot-rust itself breaks. This mostly affect the central classes Object, Reference etc. This would need some feature-gating or separate release.

I'm not sure I understand how the first scenario differs from breaking api.json changes, that would be a simple DAEV increment which doesn't affect the current compatibility commitment.
The second one would require some feature-gating, and is the only scenario where real maintenance effort is required to keep the current commitment, I agree.

It looks like there still isn't a consensus on how to handle this issue. In the meantime, you could add a note in the README stating that godot-rust is not compatible with godot 3.4 unless you build from source with latest api.json.
Additionally, you could create a 3.4 branch with the latest api.json + changes needed for doge_the_creeps to compile and point to the branch in the master branch README.

Sorry, forgot to update this issue.
Over the next days, I'll work on making master compatible with stable Godot 3.4. There are likely more people who are willing to upgrade and benefit from latest Godot features/bugfixes, than downgrade. Those who want to stay with 3.2 or 3.3 can still manually generate the api.json.
In a next step, we should think about simplifying the custom api.json generation step. https://github.com/godot-rust/godot-rust/issues/640 offers a very interesting idea, for example.

@robert-w-gries Latest master is now up-to-date with Godot 3.4.
I will keep this issue open to discuss the handling of default parameters in the GDNative API.

Using "varcalls" instead of "ptrcalls" should make those additions of optional parameters non-breaking changes, at the expense of having slower method calls into engine classes.
Using "varcall" is essentially the same mechansim that GDScript or VisualScript uses, so also shares the performance characteristics.
Doing a "ptrcall" is basically the same as taking an untyped function pointer that points directly (more or less) to the in-engine implementation of a method. When doing such a call the number and types of arguments and return values must match exactly, because it's like calling a function pointer.
Because the performance is better with ptrcalls, the bindings generator tries to select those wherever possible (there are some conditions where a varcall is necessary).
For more "used across different versions" projects, such as plugins that build on GDNative and ship with binaries, it might make sense to switch every method binding to use varcalls.
That would mean performance might be a little worse, but it would be guaranteed to be compatible across minor versions, even with the same binary.
We could add a feature flag like generate_only_varcalls (or with a different name) that overrides this selection process to never generate ptrcalls, in case a plugin author wants to guarantee compatibility across minor versions.
https://github.com/godot-rust/godot-rust/blob/42a6e768a02ed32068ae1dfe5a5e655181ea2e6f/bindings_generator/src/methods.rs#L124-L135
Would that be interesting for users of this crate or does this seem like a niche case and not requiring an extra feature flag and another knob to turn or not turn?
Would it make sense to make varcalls the default and recommend users to use ptrcalls only in release builds?
Let me know what you think!

Sounds like a good idea to me! This should deal with ABI compatibility issues to the extent that is possible on our side, although ideally we'd still want to (separately) make API compatibility easier in some way.

If we're exporting methods based on pointer, can we just check Option<T> arguments and generate n^2 methods with slightly different names where n is Option<T> count?

The ABI part is addressed in #973. I'll try to implement the call-builder solution for the API part for v0.12. The plans to deal with previously unresolved questions (https://github.com/godot-rust/gdnative/issues/814#issuecomment-963308724) are:

Builderized methods are named {original_name}_ex. "Raw" versions with full optional args are no longer generated. Currently, there are no methods with a _ex suffix in the Godot API. To guard against name collisions in the future, any Godot methods with names that end in _ex(_ex|_godot)+ will have an extra _godot appended to their names (and _godot_ex appended to their builderized versions).

Examples of collision avoidance
Given the following Godot methods, all containing optional args:
foo
foo_ex

// Implausible names
foo_ex_godot
foo_ex_godot_ex
foo_ex_godot_ex_ex
foo_ex_godot_ex_ex_godot

The following Rust methods will be generated:
foo (minimal version of `foo`)
foo_ex (builderized version of `foo`)
foo_ex_godot (minimal version of `foo_ex`)
foo_ex_godot_ex (builderized version of `foo_ex`)

// Implausible names
foo_ex_godot_godot (minimal version of `foo_ex_godot`)
foo_ex_godot_godot_ex (builderized version of `foo_ex_godot`)
foo_ex_godot_ex_godot (minimal version of `foo_ex_godot_ex`)
foo_ex_godot_ex_godot_ex (builderized version of `foo_ex_godot_ex`)
foo_ex_godot_ex_ex_godot (minimal version of `foo_ex_godot_ex_ex`)
foo_ex_godot_ex_ex_godot_ex (builderized version of `foo_ex_godot_ex_ex`)
foo_ex_godot_ex_ex_godot_godot (minimal version of `foo_ex_godot_ex_ex_godot`)
foo_ex_godot_ex_ex_godot_godot_ex (builderized version of `foo_ex_godot_ex_ex_godot`)

This may seem horrifying at first, but really what we're hoping for here is for the engine to never introduce _ex and much less _ex_godot suffixes to their methods in the first place. It doesn't make much sense from an Engine point of view to create such variants, because they can leverage optional arguments for GDScript and C#.

Call-builders do nothing when dropped. However, they will be annotated with #[must_use], which should cause Rust to emit warnings unless they are explicitly ignored (probably not what the user wants).
For the initial implementation, optional parameters must be provided in the correct order. This will hopefully be enforced statically (see below).
For the initial implementation, ptrcall will only be used if all optional parameters are provided, and if the ptrcall feature is enabled. Non-builderized versions of methods will always use varcall under the hood, if any optional arguments exist, even if ptrcall is enabled as a feature.
The type will have to be nameable for the sake of doc generation, but stability promises will be explicitly limited.

I expect the initial API to be something like:
#[must_use]
struct IsActionPressedEx<T1, T2 = ()> {
    action: T1,
    exact: T2,
}

impl SomeType {
    fn is_action_pressed_ex<T1>(&self, action: T1) -> IsActionPressedEx<T1, ()>
    where
        T1: Into<GodotString>,
    {
        IsActionPressedEx {
            action,
            exact: (),
        }
    }
}

impl<T1> IsActionPressedEx<T1, ()>
where
    T1: Into<GodotString>,
{
    fn exact(self, exact: bool) -> IsActionPressedEx<T1, bool> {
        IsActionPressedEx {
            action: self.action,
            exact,
        }
    }

    fn call(self) -> bool {
        todo!("use varcall")
    }
}

impl IsActionPressedEx<T1, bool>
where
    T1: Into<GodotString>,
{
    // shouldn't cause a conflict with the `()` impl above
    fn call(self) -> bool {
        todo!("use varcall or ptrcall depending on feature flags")
    }
}

It's not a feature that C++ and GDScript provide and is thus expected by users.

It can also be argued that it's a feature that Rust libraries commonly provide, and is thus expected by users.

Changing a parameter name now becomes a breaking change in Rust, while it wasn't in GDScript/C++.

This is something I haven't considered about. It should be however be possible to "remember" all the past names of an argument with automation, and keep any old named methods around (with #[deprecated]). This only needs to apply to crates builds, of course.
We might need to dig into past api.jsons to find out the actual probability of this happening, but I do not anticipate it to be very high.

Not compatible if a required parameter becomes optional. This is also true for the named approach.

This neither. For the named approach it's possible to force all parameters to be specified through the builder interface (i.e. no arguments in the initial is_action_pressed_ex call), but this still leaves open the question of non-builderized versions.
One option is again to memorize the original required parameter count, and generate a new version each time a parameter is optional-ized and deprecate the original. I'm not sure how ugly this will get though, since this scenario may have a higher chance of actual occurrence compared to the previous one, and the impact is higher (new method on the base type vs. new method on a builder). Might need to dig into past api.jsons to find out.
I'm not sure I can come up with something better for the positional API.

Overall I feel like that the proposed pros of the positional API do not outweigh the ability to have a idiomatic Rust interface. Realistically call() is very unlikely to be forgotten due to #[must_use] -- the lack of strict linearity being only a theoretical issue. The last two a named approach does as well. So ultimately, it comes down to a stylistic choice, and I sense that this is where the two libraries must diverge.
Thanks a lot for your input!

It should be however be possible to "remember" all the past names of an argument with automation

That's actually an interesting suggestion, I could also imagine other cases where fallbacks can be useful. Although it might be quite a bit of effort.

Overall I feel like that the proposed pros of the positional API do not outweigh the ability to have a idiomatic Rust interface. So ultimately, it comes down to a stylistic choice, and I sense that this is where the two libraries must diverge.

I agree that it's a stylistic choice. Might also need some experimenting to see if the positional API works well enough or not -- I'm open to use named arguments in GDExtension too if the other one proves to be a hassle 🙂

I'm not sure I can come up with something better for the positional API.

The tricky one is that the base method breaks whenever a required parameter becomes optional, regardless of named/positional approach. Even with awareness of previous versions and changes, we might in the worst case be forced to keep legacy versions around for years:
obj.method(many, no, longer, required, arguments);

// which would, as a fresh method, just be written as:
obj.method(many);

Some brainstorming how to handle that with the "ex" APIs:
// named: support additional conversion from ()
obj.method_ex(many, (), (), (), ()).call(); // positional
// note: I didn't want to suggest having *every* required parameter as a builder method

// positional -- ex method *always* takes exactly one tuple:
obj.method_ex((many, no, longer, required, arguments));  // initial
obj.method_ex((many,));                                  // later

Or, we just add a new base method:
obj.method(many, no, longer, required, arguments); // now deprecated
obj.method_v2(many); // new one

TLDR: every approach is ugly 😬 it's a matter of how seriously we take compatibility (even across 0.minor versions)

I don't think we want to jump to conclusions here, before looking at empirical data of how often did any of these "exotic" breaking patterns actually happen for the whole duration of Godot 3, if ever. Every approach here is indeed ugly, but not in equal ways so:

Or, we just add a new base method:
obj.method(many, no, longer, required, arguments); // now deprecated
obj.method_v2(many); // new one

The nightmare case is, of course, as you have said, becoming forced to keep multiple legacy versions for years. Docs get clogged with v1, v2, v3 and v4s of multiple functions and everything is terrible. The best case here, however, is just perfectly natural Rust.
This would be ideal in a world where optionalizations are few and far-between, and when they do happen, multiple arguments become optional at once (so fewer versions are necessary).

// positional -- ex method *always* takes exactly one tuple.
// the trait would have (min=1, max=5) arity, and enlarging this range is backwards-compatible
obj.method_ex((many, no, longer, required, arguments));  // initial
obj.method_ex((many,));                                  // later

This avoids the nightmare case, at the cost of making every single method call slightly, but uniformly ugly, regardless of which world we're living in.
This would be ideal in a world where arguments become optionalized, one by one, all the time, as such events do not generate extra permanent ugliness under this design.

This is a blocking issue for me as I described in godot-rust/gdextension#162.
If you have a prefered solution I am happy to give it a try implemeting it.

@mio991 Note that this is the gdnative project, so implementing it here will not immediately help your use case.
Also, while inconvenient, I would dispute the "blocking" nature of this: this issue has existed for years, and there's a simple workaround of specifying arguments explicitly. It's definitely not pretty, but definitely not a dealbreaker either. This just to keep in mind when it comes to priorization of different features/bugfixes.
I'll try to make some room in the next few weeks for looking at default parameters in gdextension, but there are a few more important things I'd like to tackle first (such as online documentation).

Also, while inconvenient, I would dispute the "blocking" nature of this: this issue has existed for years, and there's a simple workaround of specifying arguments explicitly.

I can not specifiy the last argument for ArrayMesh::add_surface_from_arrays because the default value 0 is not a defined ArrayFormat.

Ah, I see, that's about bitsets though (they're conceptually similar but not the same as enums in Godot)!
I will implement something for them 👍


Code color highlighting in docs

Please :) It's been a few years since I coded in notepad...

Syntax highlighting is live http://martyjs.org/guides/flux/index.html


Output instance specific options

I was thinking of making my instance available for the public too, if there are more they could potentially even be listed in the README so that users can choose one. I think it would be good then if the bot could output instance specific options so that the users know if it's up-to-date or configured as they would like to use it, e.g.

check_interval: maybe via feeds command as in "The feeds are checked for updates every {check_interval} seconds"
version: this is the most interesting one IMO but also tricky as the version only exists in setup.cfg and via git tag. Maybe the former could be loaded/parsed or migrated to setup.py  if that helps? Either a dedicated version or status command might make sense, or simply adding it to help

What do you think?
I wanted to implement the first one already but failed with generating the translations correctly, if you are interested in it I can create PRs if you point me in the right directions :)

Both are nice ideas. I'm opposed to adding another command, however. The interval in "feeds" and the version in "help" sounds fine.
The translations are done with gettext. I didn't master that myself, yet. It's probably easiest to simply add the necessary lines to the nina_xmpp/locale/nina_xmpp.pot and nina_xmpp/locale/de/LC_MESSAGES/nina_xmpp.po files manually...

Great, I'll create a PR for that then soon!


[WARNING] macOS Sequoia exposes(?) extreme memory leak

[x]  I confirm that this is an issue rather than a question.

Bug report
I just realised, that Hyperion cannot be used on macOS Sequoia (beta 1, Apple Silicon).
After updating my Mac to the current beta Hyperion causes the WindowServer UI management process to consume immense amounts of RAM (as in GBs/s) which crashes the system unrecoverable. No other screen-grabbing application I tested so far exposes this behaviour.
I tested several arm64 as well as Intel builds (via Rosetta) on my MacBook Pro 16" (M1 Pro).
I will continue to observe this behaviour and update this post accordingly. The current ticket number within the Apple Feedback system is FB13910081.

@Rastafabisch Thanks for sharing your finding.
Would be good, if could keep us posted!

The issue is still and unchanged (possibly worse?) in Beta 2.
Within seconds WindowServer consumes more than 60GB of RAM.

Apparently Beta 2 also evokes another issue, I did not realise previously. Hyperion itself now always consumes around 90% macOS CPU cycles (100%=One Core). Also it now often freezes, especially after system sleep. I did not experience this on Beta 1.

Due to the main issue (windowserver) I currently use Hyperion without screen grabbing access, which on macOS to not cause any unknown behaviour basically only allows access to the desktop background, but not any content or applications.

The WindowServer memory issue triggered by Hyperion seems to be resolved with beta 3.
Hyperion still appears to be using abnormal amounts of CPU. Using the QT grabber an entire core is used. With the OSX grabber around 20-30% of one Core on my MacBook Pro with M1 Pro chip are used. That is still 50% more than it used to be under Sonoma, if I recall correctly. I also credit the occasional flickers to black to this elevated processing needs, though that's just a hunch.


moving items with extract set to stack can void items

xnet-1.3.2
forge <IP_ADDRESS>5
If you have a node set to extract but have it set to stack size and destination nodes are set to keep less than a stack in that inventory, it'll quickly empty your input chest and void the excess.
assuming it tries to move items and grabs them from input and then any left over from each output node gets lost?

Can you give me a few screenshots of that setup? Thanks

First off, I apologize.  I totally didn't give you a ton of information to go on.
http://imgur.com/a/jI3T5
setup was to deal with pam's pressers for soy and beets.  The issue was the first batch that did the first processing for soy and the only processing for the beets.
if I didn't set the stack extract, it would continuously only feed one presser, so I switched it to stack.
when I did that, pam's doesn't recognize input/outputs and it would fill all slots.  so I had to set the pressers to fill something less than a stack.  The voiding happened when I set the insertion to keep 32 of each in each presser.
we have recently discovered a completely unrelated issue due to pam's on server and now I'm wondering if it's completely at fault here or if it's just an interaction.
I will try to find some time to test this with chests I guess and get back to you if you think it's something that needs to be done as well.
My initial thought was that if you set stack extract, it allocates 64 of an item if available, but if you set the insert to be less than a stack, what does it do to the remaining items?  Or, if xnet doesn't pull out more than it needs, but the destination object lies as to how much space it has, I can see how it would void items because your mod is just confused or who knows.

Hi
I have reproduced the same issue to work out Actually Addition Canola production automation.
Precisely the crystalized seed automation.
My setup is the following

I have a canola seed storage drawer as input
I want to output canola seeds to a precise dropper from Actually addition, 5 at a time.

To do this I extract from the storage drawer, with stack activation.
In addition, I cap the storage limit to 5 within actually additions.
In practice, XNet extracts 1 stack at a time. But it voids the 59 remaining items.
I confirm the bug :)
Regards, Guillaume

I will try to reproduce this

Hmm. I cannot reproduce this with just regular vanilla containers. It is possible that this is actually a bug in the corresponding mods. But can either of you provide me with more exact methods to reproduce? Preferably with screenshots. As minimal as possible and using as little modded blocks as possible

If I recall this seems to happen with Actually Additions precision dropper,
and a pretty standard xnet stack transfer setup with capping of the output
in the dropper.
Not just with regular containers...
If you still can't reproduce it I'll build a setup
On Sat, 12 Aug 2017, 10:39 McJty<EMAIL_ADDRESS>wrote:

Hmm. I cannot reproduce this with just regular vanilla containers. It is
possible that this is actually a bug in the corresponding mods. But can
either of you provide me with more exact methods to reproduce? Preferably
with screenshots. As minimal as possible and using as little modded blocks
as possible
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/McJty/XNet/issues/122#issuecomment-321964199, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AdWJy9FXotCuqQVGziDGzagTz8U0Dwglks5sXVbNgaJpZM4OBfsB
.

I cannot reproduce it. Here is my setup:
http://imgur.com/a/rsROg
It always properly extracts 5 items from the chest into the dropper. Nothing is lost


[BUG] 500 for no product found for navigation Id issue

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
Go to the https://frontends-demo.vercel.app/Beach-bag-NYK/SW10411 , we getError: No product found for navigationId: 0c0995b393d74e91bdf00ffdf9bfb2a0   and after reloading the page

Expected Behavior
No response
Steps To Reproduce
No response
Environment
- OS:
- Node:
- pnpm:

Anything else?
No response

the API issue is reported under internal task NEXT-37152


Shortcuts for press and release

Would it be possible to run different commands on press and release of a certain key/button/shortcut? This would allow me to start something on press and stop it on release, basically running it while the shortcut is pressed.

Hi, this ils not possible for now but couldn't be hard to implement. I'll take a look at it asap.

You were right, it was pretty easy to implement after all. (See PR #2.)


Unknown or wrong config value a9lh folder type

Japanese New 3ds V11.4
Followed the guide to update a9lh to b9s
Last part where I need to install Lumaupdater to update luma I get error
Luma is on v8.1
Deleted and installed lumaupdater cia twice, still the same

https://cdn.discordapp.com/attachments/196635695958196224/341461447194181632/20170731_140540.jpg

I assume you figured it out?


[QUESTION] big data

Hi,
how big is the maximun data that phpexcel can handle?
I am trying to export around 40,000 rows of Mysql data in PHP(Laravel5.2) using blade to excel

It's impossible to say a certain number of rows as it is very closely linked to how slow your query is and how much columns you have.
There are known problems with phpexcel and big data. If you need 40,000 rows and you can settle with csv, you should consider using league csv.


Feature Request: Play a sound when showing popup

Need to research how to correctly implement this.

is this yet ongoing? It's been a while since last update, and I would love to have this feature too. Sometimes I'm playing games in full-screen, which results in the popup not showing.

@lebel-louisjacob if you buy me a Coffee: https://ko-fi.com/applemann
I can implement this feature for you ;)

This feature request is on my list, but unfortunately I don't have time to work on this project at the moment. It might be several months before I can find the time to do that. Any pull requests are very welcome, of course.

I just finished #15. Have a look when you have time.

For now we cannot set the volume of the played sound. Want me to add an option for this?

I just added the -v option to specify the volume of the played sound.

Merged :) Thanks for contributing!


Update MsgFee spec to account for new events added

Description
Update msg fees event spec with details about new events in 1.12+
closes: #1091

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against correct branch (see CONTRIBUTING.md)
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Wrote unit and integration tests
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
[ ] Added relevant godoc comments.
[ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
[ ] Re-reviewed Files changed in the Github PR explorer
[ ] Review Codecov Report in the comment section below once CI passes

I added an update to #1060 to fix this documentation, so I'm not sure if this PR is needed.

@SpicyLemon I added a comment to your PR.  It makes sense to put them in there and make things easier.  I added a suggestions to add more details and move an event to a different section.
Closing this PR since it is moved to PR #1060


Return 404 for wrong badge url (missing '/status')

For a while, I had incorrectly been using https://david-dm.org/cnap-cobre/synapse.svg?path=frontend as my badge.  As you can see (as of now, 04/25/2018) it returns an SVG with status = pending.

I think this probably shoudl return a 404 instead.  The correct URL is https://david-dm.org/cnap-cobre/synapse/status.svg?path=frontend and reflects the current state of my repo:

Oops, my problem was .../synapse.svg?frontend rather than .../synapse.svg?path=frontend.  That explains it.  Closing...
Had the perfect issue number too. (#404)


Textarea?

Hi! I have a text area that looks like this:

Is it possible to make that textarea dropzone enabled? Thanks!

Hi @shaunc869
Unfortunately the component isn't well-configured to handle this at the moment, this pull request would possibly help but I still dont think it would be ideal. In an ideal world we'd somehow let people pass in their own div and instantiate the dropzone on that, similar to this approach in the dropzone docs.
The other option is that you could possibly just override the default css styling, or you could go all out and disable the vue-dropzone styling and create your own. You might get enough flexibility with that approach to resize and reposition the dropzone div so it effectively sits on top or behind your text area...
Hope that helps
Cheers
Rowan


Node failures 1

This covers the stop kubelet and node crash scenarios Mike mentioned in issue: https://github.com/openshift-scale/kraken/issues/8
I based a lot of my more general set up of the node kill scenario yaml file from the below and this could be combined at some point https://github.com/openshift-scale/kraken/pull/10/files
These 2 scenarios are not cloud specific.
This is a first pass of stopping kubelet. I was hoping to add the ability to stop, wait, and then restart of kubelet but I was not able to get it to work properly.
I also had to find a separate command then the one Mike mentioned for the fork bomb scenario.

Can one of the admins verify this patch?

@paigerube14 please check the travis-ci failure - looks like a style issue:  https://travis-ci.com/github/openshift-scale/kraken/builds/170789518

Hey @paigerube14, I had worked on stop kubelet and node crash scenarios as I was assigned the node chaos scenarios issue #8 . However, I was not able to update the same in my PR as I got sidetracked with the issues in cerberus.

Hey @yashashreesuresh, ah sorry about that. I had seen your pull request that covered the first couple of scenarios and figured you had not gotten to the other 2 yet so was going to try to help out.  What do you want to do here? I would love to see what you were working on here and I can add in some things you had worked on to get this pull request merged for these 2 scenarios. Or I can just drop this pull request and you can fully cover the issue in your pull request. @mffiedler @chaitanyaenr Would love some input here.

@chaitanyaenr @yashashreesuresh Thoughts on moving forward?   Keep working in this PR?  or move the work over to #10?

Agreed that we should assign the issues to ourselves to avoid any confusions, I totally forgot to do that, sorry my bad.
Think both the PR's are valid and we can keep working on them in parallel since they cover different node scenarios. https://github.com/openshift-scale/kraken/pull/10 covers node reboot,stop and terminate scenario while this PR covers stopping a kubelet and fork bombing a node. We might want to sync up on the code structure/design for consuming node scenarios before moving forward though to make sure they are in sync.
Thoughts?

Definitely agree that we need to try to sync up code for all node scenarios. It sounded like the pull requests cover different scenarios but Yashashree might have already been working on the 2 I covered as well just not in the pull request.

Sorry I missed that, we can move the work to https://github.com/openshift-scale/kraken/pull/10 then if it's okay with everyone.

Hey @yashashreesuresh, ah sorry about that. I had seen your pull request that covered the first couple of scenarios and figured you had not gotten to the other 2 yet so was going to try to help out. What do you want to do here? I would love to see what you were working on here and I can add in some things you had worked on to get this pull request merged for these 2 scenarios. Or I can just drop this pull request and you can fully cover the issue in your pull request. @mffiedler @chaitanyaenr Would love some input here.

I have been working on aws node scenarios. I have used boto to start/stop/restart/terminate the nodes. In all my node scenarios I execute a scenario and perform the check to see if the node is back healthy. For the kubelet scenario, I have used the restart module of boto to restart the kubelet after it is stopped. Therefore, the entire scenario to stop and restart the kubelet becomes cloud specific. However, if you could add the functions kubelet_action and crash_node under kraken/node_actions/common_node_functions.py, I can use them in my functions which include restart and checking if the node is back healthy. This way, both of us can contribute to the kubelet and node crash scenarios. :)
There’s no option for me to add the label on the PR indicating WIP or assign the issue to myself, else I would have added the label which would have avoided this confusion.

@paigerube14 @chaitanyaenr  I think we can close this in favor of the current AWS node scenario support.   Agree?   We can continue Azure and GCP support using #40 and #41 .  If no objections I will close this out.

@paigerube14 @chaitanyaenr I think we can close this in favor of the current AWS node scenario support. Agree? We can continue Azure and GCP support using #40 and #41 . If no objections I will close this out.

Yes I agree that this can be closed. This was partially included in Yashashree's PR

+1, I agree that this can be closed as well.


How to debug connection timeouts?

Hi all,
We are experiencing a lot of connection timeouts posting to the HTTP data collector, and it’s not clear if the issue is related to the data usage or some temporary connection issue.
Here the exception
System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond <IP_ADDRESS>:443 at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult) at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Exception& exception)
It would be really useful to get a log of the connections to the http data collector endpoint and in case be able to request to scale it up.
Is there any tool for this?
Regards

@AntonioSpalluto We will now proceed to close this thread. Please open a new issue on the document you are providing feedback on. If you query is related to implementation,please open a new MSDN forum post and community will help address your query. Please refer to below link to MSDN forum to ask new question -
https://social.msdn.microsoft.com/Forums/azure/en-US/newthread?category=windowsazureplatform


BIGTOP-4049: Remove python dependency from Hive deb

Description of PR
Remove Python 2 dependencies from Ranger Debian packages to align deb dependencies with spec.
How was this patch tested?
For code changes:

[ ] Does the title or this PR starts with the corresponding JIRA issue id (e.g. 'BIGTOP-3638. Your PR title ...')?
[ ] Make sure that newly added files do not have any licensing issues. When in doubt refer to https://www.apache.org/licenses/

@iwasakims @sekikn
Could you help review this PR?


Implement proper multi-threading

Use a thread pool rather than direct thread creation. Thread pools are preferable because they avoid the costly instantiation that raw Thread operations incur. The pool is static because MineSkinFetcher is also static.
I would use Bukkit's scheduler for asynchronous operations, but it requires a non-null JavaPlugin and MineSkinFetcher can't get a JavaPlugin.
I initially used a cached thread pool. However, I personally create my NPCs and load their skins on startup, and I imagine others, also, don't view skin loading as a highly critical, time-sensitive task. So, I realised that there wouldn't be any advantage of a cached thread pool. If anything, it makes more sense to use less resources at startup, since resources are scarce at startup when everything is loading. For NPCLib, a single thread pool works best, in order to consume less system resources.

Thanks for the PR. Merging!


Adding interface to handle manual step execution.

Manual step execution are meant to be executed outside runner domain.
E.g Collecting user feedback through prompt.
The goal of this change is to provide support  for executing semi-automated tests as well as simulated tests that still needs user interaction (manual command execution)
The step result depends only on the user response ( Based on the prompt options).
PASS
FAIL
NOT APPLICABLE
Related Issue in TH
CHIP-Specifications/chip-certification-tool#884
General Discussion
Is there a policy related to plugin versioning?
Changes in interface shouldn't increase plugin version?
The change related to this PR is already in place as a patch on TestHarness.

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


A question for train_action.py

Thanks for your excellent work！
In the picture from  train_action.py, I find that the "idx" is got in the for loop. but after the loop The if statement calls the  variable "idx " again. Why the "idx "  can be called in here?

Good catch! You can move it into the loop (pull request is welcome if you want).


Refactor/absl array

This PR removes our home-brew Array<T> and Span<T> classes with absl::InlinedVector<T> and a new Span<T> which is only a thin wrapper for std::span<T>.
Span<T, N>
This is a thin wrapper for std::span<T, N> with the following additional features:

Constructor with std::initializer_list (C++26 will get this ...)
Constructor for any compatible Vectorlike argument
rsubspan (reverse subspan)
structured binding, if N != std::dynamic_extent:void f(Span<int, 3> span) {
    auto& [a, b, c] = span;
    b = 23;
    // ...
}

This will save us a few copies as we formerly copied over to std::array in order to be able to decompose the array.

Vector
This thing behaves like a std::vector but is under the hood an absl::InlinedVector. The number of inlined elements is 4 for most element types.
Misc

No more DefArray vs DefVec. Just use DefVec = Vector<const Def*>
No more confusion with Array<T> (the C++ data structure) vs Arr (the thorin type) - Array<T> is gone
There is subtle difference with our old Span class vs our new one: the old one always used const T internally. Now, you have to do either Span<const T> or View<T> (an alias).
The lambda generator constructor is now a free function:auto vec = vector<int>(23 ,[](size_t i) { return i; });

I replaced a few places with explicit loops (rewrite.cpp) as stepping through std::function and friends during debugging becomes super annoying.

LGTM. Only the nit that I find the vector<..>() helper a bit confusing as I am then looking for using namespace std or using std::vector to identify if this is coming from std::vector - maybe make_Vector? :)

Alright, I now subclassed absl::InlinedVector instead of aliasing it. So the original c'tors are back via:
auto vec = Vector<int>(23, [](size_t i) { return i; });

There btw seems to be a gcc problem for this:
auto vec = Vector<int>(my_range_of_ints, [](auto i) { return i; });

It's a subtle issue with template instantiation, overloading, concepts, etc. I'm pretty sure it's a gcc bug. Works with clang. As a workaround, you have to explicitly specify the argument:
auto vec = Vector<int>(my_range_of_ints, [](int i) { return i*i; });

Subclassing gives us another benefit to have vec.span() and vec.view() methods, which are a bit nicer to use:
for (auto elem : vec.view().subspan(1)) { /*...*/ }

instead of
for (auto elem : View(vec).subspan(1)) { /*...*/ }


RFC: Should the infoview set the cursor to the bottom on update?

Right now if the infoview contents are too long, we show the top lines.
It seems more natural perhaps to show the goal instead, which is almost the bottom modulo us showing diagnostics below the goal state.
Comments welcome if someone prefers the current behavior.

I certainly prefer the current behavior.  Scrolling to the bottom of the diagnostics is rarely what I want.

It seems more natural perhaps to show the goal instead, which is almost the bottom modulo us showing diagnostics below the goal state.

This is a reasonable compromise.  The full goal should still be shown though if it fits on the screen.  (That is, don't show the last line of the goal as the first line in the infoview.)

Scrolling to the bottom of the diagnostics is rarely what I want.

The goal is what I was really suggesting as in the body yeah. Essentially vim.fn.search('^⊢ ', 'c'); vim.cmd('normal z-') -- i.e. "find first goal, then run z-". Do you still prefer the current behavior to that?

Oh sorry, that wasn't really clear to me in the first post.  Scrolling to the ⊢ is fine.


Add ycmd-with-handled-server-exceptions macro

I have this branch for a couple of months and was using it at work without problems.
This PR introduces a new macro ycmd-with-handled-server-exceptions which wraps all boiler-plate code for handling exceptions and running code on exception or if we should bind the current-buffer for the request and response when we need to make sure we run the response code in the buffer that was used for the request.
@abingham What do you think?

The travis build is failing because of a request.el dependency on emacs 24.4. I think this is nonsense, and you change looks like it works fine, so I'll merge it in.

The problem is the dependencies are not installed with the right Emacs Version. I have the impression that the system emacs is used and not the one we specify. Maybe it's a problem with our makefile. Unfortunately I have not much time to look into this right now

The request.el in their github repo actually specifies emacs-24.4. I've asked for clarification from the project.

That's fine. The removed some patches for emacs version lower than 24.4. The problem is with installing dependencies on Travis. If you look a the logs, package.el tries to install dependencies into a folder containing 24.3 in the  path which indicates that the emacs version is 24.3. I think Cask is not picking up the right version on Travis


update

复工后

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

902 of 1100 (82.0%)  changed or added relevant lines in 107 files are covered.
9 unchanged lines in 9 files lost coverage.
Overall coverage increased (+1.0%) to 72.345%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/actions/ui-state-actions.js
3
4
75.0%

src/actions/vis-state-actions.js
1
2
50.0%

src/components/map/layer-hover-info.js
0
1
0.0%

src/components/map/map-legend.js
22
23
95.65%

src/components/modal-container.js
0
1
0.0%

src/components/plot-container.js
1
2
50.0%

src/components/side-panel/interaction-panel/tooltip-config/tooltip-chicklet.js
7
8
87.5%

src/components/side-panel/layer-panel/panel-view-list-toggle.js
18
19
94.74%

src/layers/base-layer.js
9
10
90.0%

src/layers/geojson-layer/geojson-layer.js
10
11
90.91%

Files with Coverage Reduction
New Missed Lines
%

src/components/kepler-gl.js
1
81.33%

src/components/map-container.js
1
48.83%

src/components/modals/export-map-modal/export-json-map.js
1
46.67%

src/components/side-panel/map-manager.js
1
70.37%

src/layers/base-layer.js
1
86.65%

src/layers/trip-layer/trip-layer.js
1
92.08%

src/layers/trip-layer/trip-utils.js
1
88.12%

src/utils/dataset-utils.js
1
87.5%

src/utils/interaction-utils.js
1
82.54%

Totals

Change from base Build 744636905:
1.0%

Covered Lines:
7695

Relevant Lines:
9849

💛  - Coveralls


Make /package/latest/file responses use nginx X-Accel-Redirect instead of HTTP redirect

So no longer weird redirect cases for any type of files in QFC.

We gain a lot -> no longer the need to handle redirects. This automatically reduces QField and QFieldSync by thousands of line of code.

But if you use directly S3's URL, there would be no redirect, or did I miss something ? (I'm talking about just serving files directly from the S3 endpoint, without any proxy/redirect/whatsoever). No idea how much changes this means (probably too much if URLs are somehow hardcoded in Qfield or qfieldsync, probably not much if URLs are returned by the API). IMO that must be even less lines of code as we let S3 handle files completely.

We need to check if you have permissions to access that object first, so django is involved. Then we either should return a response with the actual resource URL or redirect. The first one is basically manual redirect, so we use HTTP redirect.

Otherwise, if you want to completely hide the storage backend from the client:

why do we still need presigned urls ? shouldn't we remove that, as we're supposed to only access S3 internally ?

Because history and it is easier to manage. I do agree would be better if we directly access them, but needs extra time to do so. Having presigned URLs does not hurt anyone when they are internal.

not sure where the buckets config is defined in the codebase, but we should make sure that the buckets are not publicly accessible and/or objects created with private ACLs.

This will now be possible, because some objects were defined public before (e.g. avatars).

(sorry if my comments don't make sense, I'm not too familiar with that part of the stack yet :-) )

Perfectly fine, I like getting questioned.
However, if you don't have any strong objections, I would susggest to make the discussed improvements (e.g. drop the presigned URLs) in a follow up PR.

I think I understood you now, you mean:
GET qfield.cloud/api/v1/files/path/to/file -> returns s3.com/path/to/file
GET s3.com/path/to/file

I find this not very convinient API to consume, as the download process will be two step process. It adds additional client logic which I am trying to avoid as much as possible when using QT networking, which I find huge pain, especially in C++.

You can include the URL in the step before (in your example, you assume the client has already retrieved a list of files)
GET qfield.cloud/api/v1/project/myproject -> returns {'name': 'project', 'files': [s3.com/path/to/file1, s3.com/path/to/file2, s3.com/path/to/file3], ...}
GET s3.com/path/to/file1

The main problem I see there is that you get a presigned url with X mins expiration. If you start downloading after X minutes, the client MUST refresh presigned URLs which is extra logic. This is real world situation, since there is a limit of 4-8 concurrent requests from a client (browser or Qt) at point of time. So you never know how much time it passed since you got your presigned URL and the actual time of request.
Anyway, if we don't merge this, we would need to keep 3 bug reports open and adjust 3 API clients to be able to consume it. I am open to discuss this as a fututure API change, but would propose to merge this for now,  so I can continue with the upcoming release these days.

Anyway, if we don't merge this, we would need to keep 3 bug reports open and adjust 3 API clients to be able to consume it. I am open to discuss this as a fututure API change, but would propose to merge this for now, so I can continue with the upcoming release these days.

Yes sure !


Filter on top of feature page not isolating PLFams correctly

Somebody can log into my account and look at the genome group PB and RB Yeaman.  Click on that group, go to the group view, and then click on the Feature tab.  In the filter box at the top of that tap put in PLF_1279_00000541 and hit return.  The table filters itself to show TWO PLFs that don't even look similar.  Why is this happening?

Use double quotes: “PLF_1279_00000541”
without it, you will get all there records that have PLF AND 1279 AND 00000541

On Jul 28, 2018, at 1:42 PM, ARWattam<EMAIL_ADDRESS>wrote:
Somebody can log into my account and look at the genome group PB and RB Yeaman. Click on that group, go to the group view, and then click on the Feature tab. In the filter box at the top of that tap put in PLF_1279_00000541 and hit return. The table filters itself to show TWO PLFs that don't even look similar. Why is this happening?
https://user-images.githubusercontent.com/11475316/43359687-6f4851ba-9274-11e8-961f-238406c77ccb.png
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/PATRIC3/patric3_website/issues/2058, or mute the thread https://github.com/notifications/unsubscribe-auth/ABLd72wArfKo58CQLAFDtWaqcFRCVIe3ks5uLLCQgaJpZM4VlJHt.


New tab file for active or used coils

Hello,
I have an idea for an extension to include an additional tab on the left-hand side titled Spools in Use.
Where you then press and you can see which coils are currently being actively used. This would have the advantage if you have several printers and all of them are operated from a central Raspberry Pi and there you have an overview of the current status of the spools that are being printed.
This way, if you have several printers, you don't have to go through the hassle of going to each one and checking them.

Spoolman does not know which printer send the commands to decrease the spool length. (AFAIK).
In fact spoolman doesnt know of the printer itself at all - it only knows about filaments and spools, and the spools are grabed by the integration to select them.


Set loca format based on num glyphs

Currently we blindly write long loca. Don't.

Fixed by https://github.com/googlefonts/fontmake-rs/pull/260


Media Queries / Element Queries

We need some way to add media query support.
header = styled div
    [ padding (rem 4)
    , media (maxHeight (rem 10))
        [ padding (rem 2)
        ]
    ]

I don't know if we should add element query support as well. Media queries are definitely more important.

Media query support added in https://github.com/styled-components/elm-styled/commit/e28286ef87f3a782262237ca2d702d9f49f7a6ee

Hi,
For some reason I have to add |> important after padding (rem 2) or it doesn't work. It works if it's a new property, but not to overwrite existing properties.
Am I doing something wrong, or do you have the same issue?
Cheers, Ryan

Mhh that's probably because of some incorrect order of the styles. Could you post an example?


api: RootFS -> SnapshotKey

This PR replaces RootFS string with SnapshotKey string so as to make sure the string won't be a rootfs directory path.
RootFS []mount.Mount variables are kept as-is.
Discussed in https://github.com/containerd/containerd/pull/1366#discussion_r134296523
Signed-off-by: Akihiro Suda<EMAIL_ADDRESS>

Codecov Report

Merging #1466 into master will not change coverage.
The diff coverage is 71.42%.

@@           Coverage Diff           @@
##           master    #1466   +/-   ##
=======================================
  Coverage   40.82%   40.82%
=======================================
  Files          23       23
  Lines        2920     2920
=======================================
  Hits         1192     1192
  Misses       1451     1451
  Partials      277      277

Impacted Files
Coverage Δ

metadata/buckets.go
46.66% <ø> (ø)
:arrow_up:

metadata/containers.go
47.2% <71.42%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

LGTM + carry
@containerd/containerd-maintainers PTAL

LGTM


Add neo4j vector support

Neo4j has added vector index integration just recently. To allow both ingestion and integrating it as vector RAG applications, I wrapped it as a vector store as the implementation is completely different from GraphCypherQAChain. Here, we are not generating any Cypher statements at query time, we are simply doing the vector similarity search using the new vector index as if we were dealing with a vector database.
Todo:

[x] Tests

I feel like the code is more or less ready. Please let me know if I have to do anything else.
What needs to be done is to add the notebook to the documentation, however I haven't grasped yet how does your json file works. Also, I would appreciate if you could create a Neo4j provider page and add this vector index and GraphDBCypherQA notebook there.
Thanks a lot! Let me know if there is anything else needed from my side

Thank you @baskaryan for the review. I have amended the code based on your and @jexp reviews!
As mentioned, the only thing I haven't figured out is how your guide_imports.json works.

Ok, now I am really finished :)

looks awesome, thank you @tomasonjo!!


Added libfunc to constrain felt252 into one of two guarantees.

Stack:

#5871
#5870
#5869 ⬅
#5867
#5858
#5852

⚠ Part of a stack created by spr. Do not merge manually using the UI - doing so may have unexpected results.

This change is

crates/cairo-lang-sierra/src/extensions/modules/bounded_int.rs line 119 at r1 (raw file):

        IntoGuarantee(BoundedIntIntoGuaranteeLibfunc),
        Felt252Constrain(BoundedIntFelt252ConstrainLibfunc),
        VerifyGuarantee(BoundedIntVerifyGuaranteeLibfunc),

wasn't this added in a diffrent PR?
Code quote:
  VerifyGuarantee(BoundedIntVerifyGuaranteeLibfunc),


[UNDERTOW-2256] Resource predicate presentation differs depending on how it is set up

https://issues.redhat.com/browse/UNDERTOW-2256

@fl4via could I get a review on this?

@fl4via Could I get a review on this?

Looks fine.


tpl: Add "cache" piped option

See #3042
The partialCached template func name makes for a bad API.
It would be nice if we could say:
{{ partial "head.html" . | cache }}
{{ partial "head.html" . | cache "some-key" }}

We would keep the old func as an alias, and this keyword would only work for the partial func at the start, but one could imagine we could use it for other things, and maybe add more "options" later.
I guess this would only work for funcs with "vararg room" on the end.

/cc @moorereason @digitalcraftsman

In other words: the partial func could become more generic in the sense that it could also cache / handle more things than just templates in the future, right?

No, turn it around: It is the cache keyword that is the generic part.

No, turn it around: It is the cache keyword that is the generic part

So, cache becomes the more generic version of partialCached?

So, cache becomes the more generic version of partialCached?

Yes. Maybe not relevant for partial, but for, say, images, one could imagine piping several "action options"; image | rotate 30 | flip...?

images, one could imagine piping several "action options"; image | rotate 30 | flip...?

Do you want to cache a composition of template functions this way?

No.

And the slightly longer version is:
I would love to come up with a generic "cache func" (how-to-suggestion welcome), but this is just options sent into another func (which can be accumulated).
So both of these are the same:

partialCached "head.html"
partial | cached

The reason we added the partialCached variant was because func Partial(name string, cached bool is kind of hard to use and document as a template func. And it becomes worse if you get func Partial(name string, cached, pretty bool`.
Then you may end up with:

partialPrettyCached "head.html"

And this breaks down fast if you need some additional and optional cache key etc. So:

partial "head.html" | pretty | cache "home-page"

And please don't ask me what pretty is -- I just made it up, but it is a configuration option and not a function doing the work.

I agree and understand the reasoning, but the proposed implementation doesn't make sense.  With
partial "head.html" . | cached

the partial will always be executed.  cached needs to control execution, so the pipe usage would be rare, I think.

proposed implementation doesn't make sense.

I haven't proposed and implementation, just the API.

But this isn't really important. Let it linger.


Does it only work with mdp. ids?

I tried downloading this book, (https://babel.hathitrust.org/cgi/pt?id=hvd.hn2s91&view=1up&seq=9) which has a hvd id and it stays stuck on zero. I've downloaded a few others but they were all mdps. Just wanted to know if mdp was the only supported id.

No problems here, at least the first few pages are downloaded when running hathitrust-downloader hvd.hn2s91 1 5


Move to grammar injection implementation

This PR changes how the implementation works.
Instead of generating a whole new syntax grammar for MyST,
we now inject into the existing markdown grammar only the
specific aspects that MyST introduces.
Also the YAML grammar template is now written as a Jinja template,
allowing us to implement the build code (which is much simplified) in both javascript and python.

Curious where you saw the benefit of this approach vs. implementing a whole language from scratch. I don't know the upside and downside well...it seems a reasonable decision to me though

Curious where you saw the benefit of this approach vs. implementing a whole language from scratch. I don't know the upside and downside well...it seems a reasonable decision to me though

Well firstly I don't didn't know this approach was possible until today! Yes I think it makes more sense (a) because that is what MyST is actually doing; extending Markdown and (b) because it means you can reuse all the current functionality associated with VS Code Markdown (previews, outlines, code-folding, etc)
As I mention in #3, I don't know if this approach is possible in other editors.
If the full grammar was required though, it would be easier to take this grammar and inject it into e.g. vscode-markdown-tm-grammar, to create the full grammar.
Regarding syntax highlighting for Jupyter Lab: https://github.com/jupyterlab/jupyterlab/issues/5504#issuecomment-450854288

I think its quite nice that now this package boils down to just building around this nice compact description of the syntax extension: https://github.com/ExecutableBookProject/myst-highlight-grammar/blob/injection-grammar/template/myst.tmLanguage.j2.yaml


convert-pr-to-draft-improvements missing or misplaced with auto-merge and merge-queue

Description
Normal repos:

Auto-merge repos:  (any open PR on https://github.com/refined-github/refined-github/pulls)

Merge-queue repos: https://github.com/refined-github/sandbox/pull/60

How to replicate the issue + URL
See above
Extension version
23.8.3
Browser(s) used
Safari

yeah the merge-queue feature is one that I'm interested in using more, but it's kinda hard to when this extension doesn't really seem to know about it...

Closing in favor of this other issue since the feature needs to be rewritten for the new view

https://github.com/refined-github/refined-github/issues/8123


Remove buffer-alloc and buffer-from deps

Buffer.alloc and Buffer.from were added in Node 6.
So, this change only drops support for Node 4 and lower, which no one should be running at this point. Especially since Node 6 is already EOL and Node 8 is about to be EOL in December 2019. :)
I also removed package-lock.json which is not useful in packages since it doesn't get published to npm. It's existence only ensures that package authors get outdated deps that the users are not going to get.
For: https://github.com/brave/brave-browser/issues/5490

LGTM.


How to use in angularsJS web app ?

Hi,
I've seen libraries wrapping pdf.js for angularjs:

ng-pdfviewer

angularjs-pdf

angular-pdf-viewer

but none exposes "print" and " download" functionalities.
I would like to have many of the functionalities of the viewer here : https://mozilla.github.io/pdf.js/web/viewer.html
I thought I could use pdf.js directly without any wrapper but I have seen in the code that print was : window.print(); but what I would like to print is not all the content of the window, just the content of an element.
Any suggestions ?
Thanks

Any suggestions ?

Browsers can print only what's visible (when corresponding CSS rules applied) -- there is no web API to create a print job.  Your main page shall do what PDF.js generic viewer does (notice that it will not work as iframe):

hide all main content using CSS @media print directive
unhide/show all page divs/canvas
handle mozPrintCallback or use its polyfill to print canvases

Closing as answered.


Invariant Violation: requireNativeComponent: "VRTText" was not found in the UIManager

I created a simple Helloworld ar app with Viro. I am using a single scene with a text component in it.
<ViroARScene onTrackingUpdated={onInitialized}>
      <ViroText
        text={text}
        scale={[0.5, 0.5, 0.5]}
        position={[0, 0, -1]}
        style={styles.helloWorldTextStyle}
      />
    </ViroARScene>

I get the error as soon as I load the app.
I am using the latest version of Viro React 2.23.0 and React native version 0.64.3
Can someone help me this?

try removing the bold from  HelloWorldSceneAR.js. Not a perfect solution but it enabled me to spin up the scenee
 _onInitialized(state, reason) {     if (state **== ViroConstants.TRACKING_NORMA**L) {       this.setState({         text : "Hello World!"       });     } else if (state == ViroConstants.TRACKING_NONE) {     }   }

try removing the == ViroConstants.TRACKING_NORMAL from from HelloWorldSceneAR.js. Not a perfect solution but it enabled me to spin up the scene

I tried this but I did not get any results.  Is there any solution in this situation?


Add more vision models (DeiT, Swin, Yolos)

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


Change 'when one extra smooth frame' to test two frames, because bugs can occur between frames; also refactor


Warpbeetle Animation Update

-Warpbeetle now actually stands on it's legs instead of t-posing
-New Ant Walk-Cycle animation for Warpbeetle Walking

LGTM, tested in-game and it works. Merge at your own discretion


support oidc implicit flow

Description & motivation 💭
Screenshots (if applicable) 📸
Design Considerations 🎨
Testing 🧪
How was this tested 👻

[ ] Manual testing
[ ] E2E tests added
[ ] Unit tests added

Steps for others to test: 🚶🏽♂🚶🏽♀
Checklists
Draft Checklist
Merge Checklist
Issue(s) closed
Docs
Any docs updates needed?

#4  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @bgerrity and the rest of your teammates on  Graphite


[Question] Is there a way I can apply the browser to other docs?

Title really says this all.
Would like to use it for the Kubernetes Documentation

Hello liquidsaul,
it's actually work in progress, you will soon be able specified the list of the website that the query will look into.
Are you using Kubernetes with unreal ?
Because if you don't use unreal I was thinking about splitting the browser feature into her own extension since other people have the same issue has you. (UVCH will still have this feature but has a dependencie to the other extension and with a custom config for UE)

I just release a new version where your able to specified the AllowedWebsite of you search.
I close this issue but if it's not working your very welcome to open a new one :)

@hcabel I don't use Unreal with Kubernetes and the splitting out would be pretty neat :)


[Fix] Try make sure we use bundled rubocop #trivial

Force us to use the bundle'd rubocop

          1 Warning

:warning:
Tests were not updated

  Generated by :no_entry_sign: Danger

CI fixed 🙏

Ah, that worked? Awesome. Let's ship it.


Add ngrok enriched errors

What
Describe what the change is solving
Add support for ngrok.Error and enriched errors
How
Describe the solution
New package
Breaking Changes
Are there any breaking changes in this PR?

#555  👈 (View in Graphite)
main

This stack of pull requests is managed by Graphite. Learn more about stacking.


Issue remapping keys within just the Preview app

Hi, I've read through all the documentation and issues and have not been able to solve my problem.
I'm simply trying to remap the "j" and "k" keys to the "Up" and "Down" menu commands with in the Preview app. What is the best way to go about setting up mappings to application specific menu commmands?
Sorry, not well versed in *nix quite yet.
Thanks for your time.

You can configure shortcuts for menu bar entries in the system preferences for any app, but you're not allowed to set just j and k without any modifier keys.

With skhd, you can add this to your config, emulating a ↓ keypress whenever J is pressed for just Preview.app.
j [
    "Preview" : skhd --key "down"
]

Thank you! Solved it perfectly.


Pull from main into oci-branch

Keeping up to date with main branch
Also fixes an argument order bug in kpt pkg push

@phanimarupaka can you pl. take a final look and get it merged in the branch.

Checking why the live tests are failing.

I noticed in the pull from main it started back in November. There could have been something not quite right in the earlier rebase - I can take a look at that first, wouldn't want you to spend time troubleshooting a broken PR.


Add s390x support for Travis

As Travis CI officially supports s390x builds, adding support for building Apache storm for s390x in travis.

Hi, any updates on the PR if the changes can be merged?


[CT-1661] [Bug] Grants fails to correctly quote username when revoking

Is this a new bug in dbt-core?

[X] I believe this is a new bug in dbt-core
[X] I have searched the existing issues, and I could not find an existing issue for this bug

Current Behavior
As part of the new grants feature, https://docs.getdbt.com/reference/resource-configs/grants dbt will attempt to revoke users not part of the grant before reapplying users listed in the grant.
DBT does this (at least in the Redshift adaptor ) by pulling the table permissions and explicitly looping through every user then using a revoke command like
revoke select on "database"."schema"."table" from user1, user2 ;
The user is not quoted so a user like user.name will fail with
syntax error at or near "."
LINE 2: ...user1, user.name, user2...
I am fairly certain the macro in https://github.com/dbt-labs/dbt-core/blob/main/core/dbt/include/global_project/macros/adapters/apply_grants.sql line 82 just needs some quotes
Expected Behavior
the revoke command should quote users
revoke select on "database"."schema"."table" from "user1", "user2" ;
Steps To Reproduce
Create a user with a period in the name for example in Redshift
create user "first.last";
Create a simple dbt incremental model and user the grant syntax to give permission to that table within dbt.
Run DBT twice (on the first run the revoke macro is not run as the table is new)
Relevant log output
No response
Environment
- OS:Ubuntu 20.04
- Python: 3.8.10
- dbt: 1.3.1

Which database adapter are you using with dbt?
redshift
Additional Context
No response

This issue is biting us as well in Redshift.  I added an IAM:user.name last night to a group and all of our DBT jobs broke that refer to this group, complaining of an unquoted user in the revoke command.

Hi, this problem is still pretty much alive in Redshift. I have IAM users with - in the name, and if it wasn't for this fix:
{%- macro default__get_revoke_sql(relation, privilege, grantees) -%}
    revoke {{ privilege }} on {{ relation }} from
    {% for grantee in grantees %}
    {{ adapter.quote(grantee) }}
    {% if not loop.last %},{% endif %}
    {% endfor %}
{%- endmacro -%}

We wouldn't have a way. Couldn't this be part of the default packages?

Hi, this problem is still pretty much alive in Redshift (dbt-core=1.8.7, dbt-redshift=1.8.1, dbt-adapters=1.9.0). I have IAM users with - in the name, and if it wasn't for this fix:
{%- macro default__get_revoke_sql(relation, privilege, grantees) -%}
revoke {{ privilege }} on {{ relation }} from
{% for grantee in grantees %}
{{ adapter.quote(grantee) }}
{% if not loop.last %},{% endif %}
{% endfor %}
{%- endmacro -%}
We wouldn't have a way to work.
The problem happens for incremental models on REVOKE commands, as stated here.
Couldn't this solution be part of the default packages?


Rustup to 1.11.0-nightly (7d2f75a95 2016-06-09)

This was broken the latest nightly:
src/lib.rs:91:13: 91:17 error: cannot infer an appropriate lifetime for borrow expression due to conflicting requirements [E0495]
src/lib.rs:91         cx: &*cx,
                          ^~~~

Awesome, thank you!
(FYI, you probably shouldn't be using the regex!.)

We only use them in Clippy's tests for regex specific lints.

@BurntSushi can we get a version bump?

Ah right! regex_macros 0.1.36 should be available now!

Cool, thank you!

@BurntSushi Thanks, but I think you have published a version without this PR.

@mcarton How embarrassing! Should be fixed now in regex_macros 0.1.37.

@BurntSushi thanks, all green now!


update garbage collector info in replicaset

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For 1.12 Features: set Milestone to 1.12 and Base Branch to release-1.12
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Please delete this note before submitting the pull request.

technical details lgtm

Already get a tech lgtm.
Ping @tengqm for approve.

@CaoShuFeng, PTAL I updated the wording, can you please make sure this is still saying what you intend?

can you please make sure this is still saying what you intend?

Yes, it is.
Thanks for update.

/lgtm
/approve