feat: (IAC-583): AKS add support for K8s 1.24

Background:
Starting from Kubernetes version 1.24.0 service account token is not automatically generated, thus it has to be created separately. The following resources were updated by the provider hashicorp/kubernetes to handle this change in v2.13.0: d/kubernetes_service_account, r/kubernetes_default_service_account, r/kubernetes_service_account. For Kubernetes clusters running v1.24+ default_secret_name will be empty. A warning message will be printed once any of the above resources are in use.
Changes:

To support 1.24+ Kubernetes version in AKS, secret is manually created for the service account
The default K8s value is updated from 1.22.6 to 1.23.8
Minor warning fix for provider hashicorp/azuread

Tests:

Verified cluster creation with K8s version: 1.24.0 was successful. Viya deployment was successful and application was accessible
Verified cluster was created successfully with the new default K8s version: 1.23.8. Viya deployment was successful and application was accessible
Verified cluster creation with K8s version: 1.22.6 was successful. Viya deployment was successful and application was accessible
Verified cluster creation with version 1.24.0 and create_static_kubeconfig=false was successful. Provider based kubeconfig was generated and used to deploy Viya successfully.

Updates made to unify the code across cloud providers. Verified cluster creation with both static kubeconfig and provider based kubeconfig. Changes ready for review.


[FLINK-21322][coordination] Make certain ExecutionGraph-logic re-usable

Moves various checkpointing/coordiantor/queryable-state scheduler logic into re-usable components. These will also be used by the declarative scheduler.

I think that this PR overlaps with #14879. I would suggest to close this one in favour of the other one.


What is the syntax for the CSS Selector option?

Dear Mrs. Sriramajeyam Sugumaran,
I would like to ask you how to make the CSS selector to work for me. I need only one example of the syntax to figure it out on myself. I tried with ID of the target panel, as well with name but without success so far. I would greatly appreciate it! Please - @yesoreyeram
Thank You in advance!

For the next developers who are wondering the same thing-here is what I found out, Mr. Sugumaran can add more to it, of course!

For the CSS Selector we use id type of selection based on our(your) dashboard in Grafana.
*Syntax: [id="1"] - this is going to call the first panel (in direction from the top to the bottom). It is not using the ID given to us from the JSON file.

In this way you can use the "Guided Tour" plugin on panels without a title! Thank You @yesoreyeram


Base class for blackbox or graybox attacks?

The BlackBox or GrayBox attacks are conceptually different from the WhiteBox attacks. The only existing BlackBox attack (Query-efficient black-box attack (Ilyas et al., 2017)) implementation does not extend any base class. It seems a separate base class for them could be very useful.

Hi @arashno Thank you very much for your interest in ART!
It is not correct that there is only one black box attack, because. ART also provides in addition to Query-efficient black-box attack the Zeroth-order optimisation (ZOO), HopSkipJump, or Spatial transformation attacks as black box attacks which are extending the base class EvasionAttack.
Why would a separate base class be useful for you?

Hi @beat-buesser
Thanks for your quick reply.
Sorry, I am new to this field and I don't know much details on different attacks.
First, I found that the Query-efficient black-box attack class does not extend any base class.
(https://github.com/IBM/adversarial-robustness-toolbox/blob/master/art/wrappers/query_efficient_bb.py)
I expected it to use the same base class as the other attacks. Is anything is so special about this attack that couldn't be fit to any base class or I am looking at an old version of the code?
Second, I expect to see different base classes for white-box and back-box attacks because they are different by nature. Am I wrong?

Hi @arashno
No worries, these are good questions. Maybe we should add attack-scenario-specific base classes at some point. Let me explain why we don't have them so far.

I think the implementation of Query-efficient black-box as a wrapper (of a classifier) instead of an EvasionAttack is that it behaves like a (black-box) classifier which through (efficient) queries approximates its loss gradients and that way could also be attacked with white-box attacks.

Currently ART's Classifier API (https://github.com/IBM/adversarial-robustness-toolbox/blob/master/art/classifiers/classifier.py) defines if a classifier can be attack by white-box attacks if it fulfils the ClassifierGradients mixin abstract base class in addition to the classifier abstract base class Classifier which by itself is sufficient for black-box attacks. The attacks then check if the provided/attacked classifier provides the API they require.


added  Authorization header if access_token provided

This fixes issue https://github.com/jupyterhub/binderhub/issues/952 by adding an Authorization: token <access_token> header to Github API requests from Binderhub if access_token is passed by either binderhub_config.py or GithubRepoProvider in secret.yaml.

Thanks for the PR!
I think @sgibson91 has been looking into this as well so getting your input here would be great. I've never even tried to use the features of a BinderHub for "private" deployments so don't have a good feeling if this would break other things or if it should have been solved some other way.

This change seems to have broken one of the tests here (sorry for the very verbose output of our CI).

There is also https://github.com/jupyterhub/binderhub/pull/940 to look at/compare to/check with.

This change seems to have broken one of the tests here (sorry for the very verbose output of our CI).
@betatim  I was actually looking into this, and it seems to be a weird point of failure from the CI test. The failure is from a null result of getting gitlab ref. The code changes I made were inside the class GitHubRepoProvider which should not be related to GitlabRepoProvider.

Is there a way to re-trigger the travis-ci tests?

You think this is a flakey test? I restarted it now. I thought it was related to the change because something in the GitLab provider broke.

You think this is a flakey test? I restarted it now. I thought it was related to the change because something in the GitLab provider broke.

Looked more into this and the failure was also the same as PR https://github.com/jupyterhub/binderhub/pull/951so I looked at the actual test. I think we are getting failures because the repository we are testing against was updated from  gitlab-ce to gitlab-foss. I did another branch on my fork with an updated repo name and tried a PR there. Waiting for the test to finish to see if that fixes that issue. Will keep you updated here 😄

@betatim  so the ci tests have finished for the new branch I made that rectified the test_gitlab_ref case that was failing and it is now passing (https://travis-ci.com/kaseyhackspace/binderhub/jobs/236599088#L3086). This branch should fix both this PR and the error in PR https://github.com/jupyterhub/binderhub/pull/951. Question now is, how do we proceed:

Do I PR the branch (https://github.com/kaseyhackspace/binderhub/tree/update-test-repoproviders) to jupyterhub/binderhub's master?
should I merge and push the branch to this current PR?

Ah, I just opened #956 to fix the failure after looking at a different PR (but not this one) during my morning coffee. Sorry for the double effort. If you could take a quick look at #956 and leave a review we could merge that. After that I'd rebase this PR and #951 onto master.

Ah, I just opened #956 to fix the failure after looking at a different PR (but not this one) during my morning coffee. Sorry for the double effort. If you could take a quick look at #956 and leave a review we could merge that. After that I'd rebase this PR and #951 onto master.

It's all good @betatim , it's never a wasted effort 😄 https://github.com/jupyterhub/binderhub/pull/956 is good to merge.


Wrong javadoc in AbstractObjectArrayAssert (and similar)

I noticed that currently org.assertj.core.api.AbstractObjectArrayAssert#startsWith and similar methods in this and other array related classes say
@throws IllegalArgumentException if the given argument is an empty array.
while in fact they do throw AssertError in that case (and only if the actual is not empty, the check pass if both arrays passed are empty).
This is also reflected in tests like here: org.assertj.core.internal.objectarrays.ObjectArrays_assertContainsExactly_Test#should_fail_if_array_of_values_to_look_for_is_empty_and_actual_is_not
  @Test
  void should_fail_if_array_of_values_to_look_for_is_empty_and_actual_is_not() {
    assertThatExceptionOfType(AssertionError.class).isThrownBy(() -> arrays.assertContainsExactly(someInfo(), actual, array()));
  }

It would be great to fix the javadoc. I can contribute to this.

Good catch, please send us a PR, thanks @pbacz !

done in https://github.com/assertj/assertj/commit/87f454ec22719baae69eec0b6f7cd826f70e8fde


avoid_types_on_closure_parameters suggests removing required types

I'm not sure if this is an issue with the lint or the analyzer (or neither, and it's just a place the lint would have to be excluded).
/// groupBy signature from package:collection
Map<T, List<S>> groupBy<S, T>(Iterable<S> values, T Function(S) key) => null;

void foo() {
  List<String> _filters;
  groupBy(_filters, (String f) => f.startsWith(''));
}

In this code, the variable f is explicitly declare as String and everything works as expected, but it triggers the avoid_types_on_closure_parameters lint ("Avoid annotating types for function expression parameters."). However, if I remove String so the code is like this:
Map<T, List<S>> groupBy<S, T>(Iterable<S> values, T Function(S) key) => null;

void foo() {
  List<String> _filters;
  groupBy(_filters, (f) => f.startsWith(''));
}

The type of f is now shown in the editor as dynamic. This results in no code completion, and the return value of groupBy being a Map<dynamic, ... which means no help with the types for the keys either.
The best option right now seems to be to ignore the lint that for that line, but it seems like either the type could be inferred or the lint could know that removing the type has undesired effects (for the editor, at least).

Thanks for catching this!
My understanding is that inference will push down bindings for type parameters from the surrounding context (and in this case there is no surrounding context for the invocation of groupBy and hence no bindings) and then pull up bindings from subexpressions. So, I believe that what's happening here is that S isn't bound to String until we're in the pulling up phase, by which time it's too late to push it down into the closure. Because there's no binding for S when inferring the closure, there isn't any way to infer T. Handling a case like this (in the general case) would require going up and down until we reach a steady state, which we decided not to do. @leafpetersen to confirm.
@scheglov Is there enough information in the AST for the linter to determine which types are necessary for inference? If not, could we add that information? If my understanding of inference is correct, then we'll need to update the lint, and I'd prefer to not need to re-run inference every time the lint finds a closure.
@pq for visibility

@bwilkerson yes, that's essentially it.  We can actually do better with this in the average case by using heuristics.  It's on my list of small improvements to type inference to do at some point.

CC @stereotype441 who is working on the language side of this. He has refactored a lot of how inference is performed in analyzer, and might be able to answer whether the nodes have enough info for the lint rule, without having to re-perform inference.

Inference has been updated to handle this case. If I rewrite a bit to support null safety:
Map<T, List<S>> groupBy<S, T>(Iterable<S> values, T Function(S) key) => {};

void main() {
  List<String> filters = ['h'];
  print(groupBy(filters, (f) => f.startsWith('')));
}

then the code is valid. This may have been inference-update-1, 2, or 3.
So I'm going to close this example. If there are other inference issues with thie rule (not unlikely), we can track with other issues.


Breakup log schema file

to: @ryandeivert @chunyong-lin @Ryxias
cc: @airbnb/streamalert-maintainers
Background
Currently all schemas are defined in one large logs.json file. This is pretty unorganized and would be better if the schemas could be split off by group, i.e carbonblack, ghe, slack, etc. That is exactly what this PR solves.
Changes

Split schema into multiple files in a new conf/schemas directory
Added the ability to configure the priority of individual schemas within a larger group after uncovering an issue with ordering that split schema files uncovered
Added unit tests for the new functionality and added priority to some rule tests

Testing
Unit tests and integration tests passed locally.

Have made several updates. PTAL

@blakemotl Can you resolve the conflict?

Fixed the issues Ryan pointed out, and fixed the merge conflict.

Coverage decreased (-0.002%) to 96.606% when pulling 28d154ae2cde6847a6f2bc9ada5ef95a0f563ab1 on breakup-log-schema-file into 0d545a3301a4851c83c5fa1f70bbd4f462eb430e on release-3-0-0.

Fixed another issue I found with the CLI trying to rewrite logs.json to disk which fails. Logs does not need to be written by the CLI and fixing it to work with the new schemas system(where it is aware of what file each schema came from) would require a lot of work.


Add unit test to make sure internal state of json writer is set correctly.

Follow-up to https://github.com/Azure/azure-sdk-for-c/pull/1905

cc @hwmaier


More Mesheryctl Error Wrappers

Notes for Reviewers
This PR fixes #8204  and continuation of #8256
Signed commits

[ ] Yes, I signed my commits.

@leecalcote thank you I have  noted these changes

@Philip-21 Let's discuss this on Meshery Dev call. Please add this as an agenda item in the meeting minutes if you would. :)

Please resolve all comments that have been addressed.

replace error codes with replace_me placeholder as ci is fixed Also please make changes packages wise it is hard to review everything in one go you haven't consider my previous suggestion

@suhail34 i did consider your suggestion

I want to get this done with before the weekend. Its why i decided to implement the meshkit errors here

@suhail34 i have added new errors for system  package


Testing Azure Boards

Sprint 6 Demo

Thanks for reporting - this issue is under review.  This is a Microsoft Internal DevOps Bug ID AB#194381


Flow does not complain about wrong property accesses in ternary operator

Flow won't complain about wrong property accesses within the boolean expression of the ternary operator.
type Y = {
  k: number,
}

function f1(y: Y) {
  var x1 = y.j === 1;           // flow finds the error
  var x1 = y.j === 1 ? 0 : 1;   // flow does not complain
}

It's not the same issue as #3500, but these things might be related (both pertain to the ternary operator).
/edit: The same behaviour can be found in normal if-checks:
if (y.j === 1) { ... }

will also typecheck. I wonder if this is a "feature"? Of course, this can be a legitimate refinement, but when I operate with (exact) types, I want to be able to rely on Flow to warn me about accessing properties which don't exist in a given type.

Does this still happen if Y = {| k: number |} ?

@singpolyma-shopify Yes, even with exact object types flow doesn't throw an error. For non-exact types, I could understand the point, that it shouldn't throw an error. However, for exact object types, it does not make any sense to not throw an error, in my opinion.
In both cases I would argue, that the user should use something more explicit like if (y.hasOwnProperty("j")) in order to check for not existing properties of a type.
At the moment, this behavior is really annoying, since I cannot trust flow completely when refactoring types. I still have to watch out for conditions like if (y.j === "something") {...} since flow doesn't complain about wrong type usages here.

I suspect this is related to #3887. I'm curious if anyone could comment on if this is expected behavior or not. It really makes some refactoring challenging and error-prone. For example, we recently migrated away from Immutable.js. In migrating from Immutable Lists to Arrays, we had a few instances of the following (as an example):
return list.size === 0 ? x : y;

size is not a valid property of an Array, but because it was referenced in a ternary, the unknown property references were not caught. If we were to put it in its own variable, it would have been caught:
const listSize = list.size;
return listSize === 0 ? x : y;

3: const listSize = list.size;
                         ^ property `size`. Property not found in
3: const listSize = list.size;
                    ^ Array

If this is an expected gotcha to look out for, it would be helpful if it were listed in the documentation. Something along the same lines as the "Array access is unsafe" section of the Array type documentation.

Is there any progress on this? The fact that flow is just completely okay with you doing wrong property access makes it pretty useless for static analysis, especially in React where you have a lot of ternaryys.


Thread pool is EXHAUSTED while active is 0

[x] I have searched the issues of this repository and believe that this is not a duplicate.
[x] I have checked the FAQ of this repository and believe that this is not a duplicate.

Environment

Dubbo version: 2.5.3
Operating System version: centos-6
Java version: 1.7.0_71

Steps to reproduce this issue

xxx
xxx
xxx

Pls. provide [GitHub address] to reproduce this issue.
Expected Result
What do you expected from the above steps？
Actual Result
What actually happens?
[DUBBO] Thread pool is EXHAUSTED! Thread Name: DubboServerHandler-xxxx, Pool Size: 100 (active: 0, core: 100, max: 100, largest: 100), Task: 8960329 (completed: 8960329), Executor status:(isShutdown:false, isTerminated:false, isTerminating:false), in dubbo://xxxxxxx:xxxx!, dubbo version: 2.5.3, current host: xxxxxxxxxx
If there is an exception, please attach the exception trace:
Just put your stack trace here!

You set up 100 threads, and active represents the number of connections currently available. So I think that active 0 is normal.

represents

How could that be normal? The whole thread pool is idle but log says no thread could be spared for new job?

represents

How could that be normal? The whole thread pool is idle but log says no thread could be spared for new job?

Sorry, I didn't look at it at the time. Can you use jstack to observe the current state of the thread?

Which thread poll you use it? In Duboo has CachedThreadPool,EagerThreadPool,FixedThreadPool,LimitedThreadPool

[x]  I have searched the issues of this repository and believe that this is not a duplicate.
[x]  I have checked the FAQ of this repository and believe that this is not a duplicate.

Environment

Dubbo version: 2.5.3
Operating System version: centos-6
Java version: 1.7.0_71

Steps to reproduce this issue

xxx
xxx
xxx

Pls. provide [GitHub address] to reproduce this issue.
Expected Result
What do you expected from the above steps？
Actual Result
What actually happens?
[DUBBO] Thread pool is EXHAUSTED! Thread Name: DubboServerHandler-xxxx, Pool Size: 100 (active: 0, core: 100, max: 100, largest: 100), Task: 8960329 (completed: 8960329), Executor status:(isShutdown:false, isTerminated:false, isTerminating:false), in dubbo://xxxxxxx:xxxx!, dubbo version: 2.5.3, current host: xxxxxxxxxx
If there is an exception, please attach the exception trace:
Just put your stack trace here!

Dubbo can't get the state of thread pool when it's exhausted, so the situation describe above is very likely to happen in heavy threading.

I had this issue too while high concurrency happened. I solve it by using a size of TaskQueue which larger than the maxPoolSize .It seem like a 1-sized(default config) TaskQueue cant perform well in high concurrency case

I had this issue too while high concurrency happened. I solve it by using a size of TaskQueue which larger than the maxPoolSize .It seem like a 1-sized(default config) TaskQueue cant perform well in high concurrency case

Thanks for your suggestion!


Improvement of the usebility of the class WeatherDataNetcdf

Introduction of individual data outputs in the same manner as in the class Ambient ...

ready


module: Expose more of the native module implementation

Only the declarations related to the linker section need be behind the
JERRYX_NATIVE_MODULES_SUPPORTED flag. When the flag is absent or 0,
it is now possible to pass an array of jerryx_native_module_t
structures to a new macro JERRYX_NATIVE_MODULES_INIT() which will
initialize the global variables __start_jerryx_modules and
__stop_jerryx_modules, just as the linker would if it were a gcc
linker.
Fixes https://github.com/jerryscript-project/jerryscript/issues/1952

@gabrielschulhof in the emx patch #1901 , we met this issue, and did a similar (not same) way to solve it.
Emx cannot simulate the linker vars like __start_jerryx_modules and __stop_jerryx_modules, but it can simulate the gcc constructor attribute. So for those "platforms" who dont support link __start/strop_xxx, we use the constructor attribute to register the native modules from different source files. In this way, we don't need to register them explicitly in centralization.
You can see the https://github.com/jerryscript-project/jerryscript/blob/569a0d95fe1811bea68a9cef94e38c8adaf16f8f/jerry-ext/module/module.c#L74 and https://github.com/jerryscript-project/jerryscript/blob/569a0d95fe1811bea68a9cef94e38c8adaf16f8f/jerry-ext/include/jerryscript-ext/module.h#L48
Any review comments are appreciated!
And for those platforms who dont even support the constructor attr, seems we had to register module explicitly in centralization like your patch.

I don't really want to add the second fallback of using a constructor, because that requires features from both the compiler and the C library.

I am ok with the constructor system as long as it does not increase the complexity too much. These are exclusive mechanisms. Anyway the constructor support can be added later.

I can use __GNUC__ to detect whether linker sections are supported or not, but how do I detect that constructors are supported, but linker sections are not?

Probably the same was as linker sections: based on people feedback we can add defines for those environments where it is supported.

That's just it though. I know about __GNUC__, but I don't yet know about __HAS_INIT_FINI__ or whatever its name. I think we should add support for constructors later and separately from this PR, because it's too both expose the native resolver and add support for a third (after section and explicit) loading mechanism.

I think we're gonna go with #2018 on this one.


[WinError 2] The system cannot find the file specified

Hello, I just implemented the code same as sample but get this error:

Request Method:
POST

http://<IP_ADDRESS>:8000/videos/new/

3.0.4

FileNotFoundError

[WinError 2] The system cannot find the file specified

If you are using Windows, make sure you added FFmpeg and FFprobe binaries to your system path.
You can open a command prompt and run the following command:
ffmpeg -version

If you did not get any error the path is fine, otherwise, you should add these binaries to your system path.
see the page below to learn how to do this:
https://www.wikihow.com/Install-FFmpeg-on-Windows
If you have any further problems, please post your code here.


BREAKING NEWS: The scorecard Monitor is part of the OSSF :partying_face:

TL;DR:
I am very glad to announce that this repository is now part of the OSSF Organization, so the Scorecard Visualizer is now an official tool in the OSSF Scorecard ecosystem. :confetti_ball: :confetti_ball:
Important Details
As part of the migration process, the repository has been transferred to the OSSF (from UlisesGascon/openssf-scorecard-monitor to ossf/scorecard-monitor). The redirection should be working, so no additional steps are required from your part. Starting from version v2.0.0-beta8, we will use the new URLs (soon to be released).
Let's celebrate this moment together :hugs:
This journey started a long time ago, even before the first commit on Feb 2023 when we started to adopt the OSSF Scorecard in the Node.js Organization (https://github.com/nodejs/security-wg/issues/851) in Dec'22, thanks to the GOSST Team (@gabibguti, @joycebrum, @pnacht, @diogoteles08 and others) that helped us understand in detail what this project is about and how it can help our organization be more secure (full video).
As soon as I understood how important this was for the Open Source Community, I tried to spread this idea into the ecosystem, so I started to blog about it and discuss it with the community on social media.
The real challenge came when we needed to adopt it at the scale of Node.js, in the Node.js' security WG (https://github.com/nodejs/security-wg/issues/851#issuecomment-1432257748). We realized that we needed a tool to help us monitor the scoring over time. In the following weeks, we started to iterate over this idea until we had the most basic features of the Monitor, especially thanks to Security WG (@mhdawson, @RafaelGSS, @marco-ippolito, @fraxken and others) for all the patience, feedback, ideas, and contributions to consolidate this tool and make it extensible to the community.
Once we had a clear idea on how to track the scores in our repositories, we realized that it was very hard for us to spot the evolution in terms of scoring differences. So, @kooltheba joined the efforts by creating the Scorecard Visualizer that allowed us to showcase the scorecard details per project using commit hashes and to compare between two different commits. This was a game-changer for us as it allowed us to quickly spot the differences and act on them on a bi-weekly basis, especially when the diff details were added.
Our next big problem was how to reduce the Time To Remediation (TTR). One day, the Step Security team did an eye-opening demo for the Node.js Security WG (https://github.com/ossf/scorecard-monitor/issues/37). Thanks, @varunsh-coder and @boahc077, for showing us the right way. Since then, there is a fix it link in the report to quickly apply many scorecard recommendations in any GitHub project.
I want to especially thank all the collaborators (@KoolTheba, @justaugustus, @lelia, @rajbos and others...) who helped us on this amazing journey, as well as all the users (@inigomarquinez, carpasse and others) and orgs that were early adopters and provided invaluable feedback and perspectives to the project!
Finally, thanks to the OpenJS Security Collab (@ruddermann, @ctcpip, @ljharb, @mrutkows, @shusak, @joesepi, @rginn, @bensternthal and others) for the endless discussions and invaluable knowledge shared in every session. Also, to the OSSF team for building these amazing tools and sharing them with me in advance (@laurentsimon, @naveensrinivasan and others...), and to the OSSF for helping us in all the donation journey and making all the changes required for us to join (@justaugustus, @afmarcum, @bbpursell1 and others).

📢 You can follow this discussion on Twitter, Linkedin and Mastodoon

Congratulations @UlisesGascon !
Happy to see that these tools that I've been using for a while keep improving and gradually becoming official in the Open Source world. 🚀

Great news, @UlisesGascon! 🎉
I wanted to clarify one thing about the status of v2.0.0-beta8 as I noticed this tag is now referenced in the README.md and package.json but I don't see a corresponding release for beta8 yet.
Is the tagging of this release intentionally delayed as part of the transition to ossf? Thanks!

There was a hold-up on legal review of the Marketplace Developer policy.  This is now approved, and @UlisesGascon should be able to publish it when he is ready.

There are a few things I want to review copy-wise before we republish. @UlisesGascon, let's have a quick sync in the next week before a new rev.


Outgoing API Error

I'm not sure what the issue is, but when running the included test I get the error:
/dj_twilio_sms/tests.py", line 20, in test_send_sms
self.assertEqual(result.created_at.tzinfo, UTC)
AssertionError: None !=
on Twilio's logs: Missing META param: u'HTTP_X_TWILIO_SSL'

Hi, thanks for checking. Second issue was twilio related and should be solved in commit #93ff509f6c3729ca106153595886299fb51ddc73
The first one is due to missing TimeZone in created_at field. What is the value of USE_TZ in your settings?

I implemented the change in issue-4 and Twilio now reports "Invalid Signature". I have no USE_TZ setting so it's in effect set to 'False'.

See #5 for Invalid Signature fix. Caused by no HTTP_X_TWILIO_SSL Meta tag so the URL is never constructed with https, causing the locally generated signature to not match the sent signature.

Solved on version 2.0

@chrisgrande @truhlik @nigma @lanshark can you verify the last version for incoming messages?

Just got back and around to testing, incoming and outgoing seem to work with no issue.
On the incoming view, the code comments:
#Override to add custom logic and configure url in the Twilio admin panel.
What's the best way to achieve this override?

Idea is to extend class and rewrite def post_save(self) function. Can be used for auto reply or confirmation or anything else.

Oh so just write a new function with it's own url endpoint and point Twilio at that, makes sense. I was thinking I was missing something! Thanks for the updates for the new API. 👍

Thank you @chrisgrande for reporting the problem.


[bug] Greenwave Powernode 6 measurements always reported on instance 1

Version
Checklist:

[ ] I am not using HomeAssistant. Or: a developer has told me to come here.
[X] I have checked the troubleshooting section and my problem is not described there.
[X] I have read the changelog problem was not mentioned there.

Build/Run method

[X] Docker
[ ] PKG
[ ] Snap package
[ ] Manually built (git clone - yarn install - yarn run build )

zwavejs2mqtt version: 4.5.1
zwave-js version: 7.7.1
Describe the bug
Two Greenwave Powernode 6 devices. Correctly detected by ZWaveJS2MQTT. Nodes 2 & 12.
Attached information:
zwavejs2mqtt-store.zip
Each socket is expected to update their "Electric Consumed [W]" information into their own instances (NODE-50-X-66049, with X = 1 to 6).
Unfortunately the electric consumed information is updated regularly but instead to be assigned to the proper socket, the information is assigned to X=1
For instance, in my node 12 I have only one device connected at X=3 right now but information of power consumption is updated on 12-50-1-66049, not in 12-50-3-66049

If I click on "Refresh" button, the 12-50-3-value-66049 is updated and 12-50-1-value-66049 goes to 0 for a few seconds. Until new measurement is received which instead to updated the expected 12-50-3-value-66049 updates the 12-50-1-value-66049.
In my other device (node 2) it happens the same but it could be less obvious because I have devices in a lot of more sockets. But in logs you can see only socket 1 is updated periodically but, based on the power consumptions it is obvious to me some times the reports if for one socket or another.
It seems quite similar to me to the issue reported over OpenZWave stack: https://github.com/OpenZWave/open-zwave/issues/1700 but I don't get the technical discussion on it of how it was solved on that ZWave stack. I'm not sure if it could be helpful for ZWaveJS stack.
kWh information (NODE-50-X-value-65537 Ekectric Consumed kWh) is only updated by polling mechanism so I guess I can do the same to get "W" information updated regularly but, as I said, Electric Consumed (W) information is being sent by device periodically and ZWaveJS is aware of that. The issue is ZWaveJS is assigning the values always to socket 1.
To Reproduce
Steps to reproduce the behavior:

Go to 'Control Panel'
Click on Greenwave PowerStrip 6 Node
Scroll down to 'Meter'
You'll see only NODE-50-1-value-66049 Electric Consumed W is updated regularly although that socket (1) isn't populated

Expected behavior
Each NODE-50-X-value-66049 Electric Consumed W should be updated with the information if its own socket X. X=1 should inform about the electric consumed (W) by socket 1, X=2 should report power consumption of socket 2 and so on.
Additional context
As mentioned above, it seems to me like this issue raised on other ZWave stack: https://github.com/OpenZWave/open-zwave/issues/1700

Please share a driver log (loglevel debug) which contains a power report from the device.


About cite/ack to OpenRLHF in README.md or paper.

Thank you for the fantastic work! It’s great to see OpenRLHF has contributed to this project. Could we kindly request you to add a citation/ack to OpenRLHF in the README.md (or clarify in the paper) to help us promote our project?
I’d also like to mention that about 80% of the RLHF infrastructure code in TULU-v3 is based on OpenRLHF, with some modifications and restructuring (such as https://github.com/allenai/open-instruct/blob/main/open_instruct/ppo_vllm_thread_ray_gtrl.py)
This also clarifies that the RLHF infrastructure of TULU-v3 is based on OpenRLHF, but the current paper does not make this clear.

Thanks！

Hi @hijkzzz,
We would be happy to acknowledge OpenRLHF, which is an amazing open-source project. I've updated our README.md to include an acknowledgement section.
For transparency, I want to clarify our RLHF infrastructure's lineage:

Our core PPO infrastructure was originally based on OpenAI's RLHF implementations:

lm-human-preferences, which we reproduced in vwxyzjn/lm-human-preference-details.
summarize-from-feedback, which we reproduced in vwxyzjn/summarize_from_feedback_details. Most of our PPO code are adapted from summarize_from_feedback_details/ppo.py

OpenRLHF has been invaluable in helping us scale to 70B models. Your ray + vllm broadcast approach is particularly elegant - it scales much better than our initial attempt at direct vLLM weight loading.

We've made sure to properly attribute OpenRLHF through:

Citation in our paper: "we also adapted model allocation techniques from existing distributed RLHF frameworks (OpenRLHF)"
Code comments at:

https://github.com/allenai/open-instruct/blob/c80c4049ef4c53f440ee333f7e80c9e97f1749b1/open_instruct/ppo_vllm_thread_ray_gtrl.py#L14-L29
https://github.com/allenai/open-instruct/blob/c80c4049ef4c53f440ee333f7e80c9e97f1749b1/open_instruct/vllm_utils2.py#L16
Regarding licensing, I've followed OpenRLHF's instructions, but noticed the Copyright [yyyy] [name of copyright owner] field is unfilled. Please let me know if you'd like this updated.
While we directly utilized OpenRLHF's code for scaling, our core PPO setup differs in many ways. For example, we 1) shard all the models equally across processes, 2) our vLLM inference runs through the entire batch at once as opposed to splitting it up using micro_rollout_batch_size, and 3) our setup is asynchronous: we run training / inference concurrently, and always learn from the second latest policy.
While we leveraged OpenRLHF's scaling approach, our RLHF implementation differs in several key aspects:

We shard all the models equally across processes
We do full-batch vLLM inference rather than using micro_rollout_batch_size
Our setup is asynchronous: we run training / inference concurrently, and always learn from the second latest policy.

We greatly respect OpenRLHF's contributions to the field and are committed to proper attribution. Please let us know if you have any additional thoughts or questions.

+1 on Costa, also answered via email. I think we're at a pretty fair spot and appreciate and highlight your work. I think counting contributions in percentages like that really works, unless all we did was copy the files in their entirety.

Hi we also do full-batch vLLM inference rather than using micro_rollout_batch_size
We also use a lot of PPO implementation tricks.
the asynchronous is developed by your repo.
However, thank you for your cooperation.


cl_theme Issues.

Main Menu/Tab Text Colors refuse to be changed, even if there is input in the cl_theme file changing the color codes for them.
http://steamcommunity.com/sharedfiles/filedetails/?id=412414251

@SomeSortOfDuck believe this is known?

It is known and will be fixed in the next update of GMod guaranteed or sooner.

I believe this has been fixed, please open another issue if this has persisted through the last GMOD update.


Modify the code to run in an environment use pytorch-1.3.0

and python3.7

1.to pickle error (lambda function), define a global function to do lambda function's work
2.to IndexError: invalid index of a 0-dim tensor. Use tensor.item() to convert a 0-dim tensor to a Python number, delete "[0]"


VTOL: Back transition timing.

Hi Guys,
Probably it is a strange request but we've had numerous dire situations flying in FW flight where we had stalled or there is some uncontrolled fall etc. We were thinking if there should be a way to recover from this situations with back transition to quad. But there is a problem, we have preset back transition time to 3 sec. in order to be smooth. In most emergency situations these 3 seconds are fatal.
So if we could trigger immediate mandatory back transition in the Taranis HS switch? We use HS switch for parachute launch usually. Can be connected to AUX3.
Then when in control, we can  just switch back to quad from the main dial and again to FW for another transition.

Closing this in favor of https://github.com/PX4/Firmware/issues/3823.
@tubeme If you regularly stall in fixed wing you have set up your plane parameters incorrectly. The stall speed that you have provided is awfully low (our experience suggests a stall speed of 11-14 m/s).
Given that you have a lot of stall related issues, have you considered that your assumptions about the plane might be fundamentally wrong and that your very unstable results are mostly driven by that? We almost never stall, in particular not in forward flight.

During our experiments, sometimes we are flying on the edge on purpose, to see where it can go. So we try everything in its extremes. So in this situations sometimes inevitable happens. Of course we will not use this settings for release version. The frame fly very good I assure you and it is very economical.


EGL BAD PARAMETER

Habitat-Sim version
Habitat-Challenge-2022
❓ Questions and Help
Hello everyone. I'm trying to reproduce a paper called l3mvn using docker. Originally I tried to use the cudagl 10.1 image, but it did not support 4090 graphics card. After a bit of searching, I switched to cudagl:11.7.1 but encountered the following error message. Does anyone have solutions working with newer generation cards? Thank you very much in advance!
Environment
OS: Ubuntu 20.04-wsl on Windows 11
GPU: 4090
Error message

Dockerfile
FROM fairembodied/cudagl:11.7.1-cudnn8-devel-1.2-glvnd-devel-ubuntu20.04
ARG MYENV=habitat

RUN apt-get update && apt-get install -y --no-install-recommends build-essential git curl vim \
  ca-certificates libjpeg-dev libglm-dev libegl1-mesa-dev xorg-dev freeglut3-dev pkg-config wget zip unzip openssh-client \
  && rm -rf /var/lib/apt/lists/*

RUN curl -L -o ~/miniconda.sh -O  https://repo.continuum.io/miniconda/Miniconda3-latest-Linux-x86_64.sh  &&\
    chmod +x ~/miniconda.sh &&\
    ~/miniconda.sh -b -p /opt/conda &&\
    rm ~/miniconda.sh &&\
    /opt/conda/bin/conda install numpy pyyaml scipy ipython mkl mkl-include &&\
    /opt/conda/bin/conda clean -ya

ENV PATH="/opt/conda/bin:/usr/local/nvidia/bin:/usr/local/cuda/bin:/usr/local/sbin:\
  /usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

RUN mkdir -p /home/app

RUN conda create -n $MYENV python=3.7 cmake=3.14.0
RUN conda install -n $MYENV pytorch==1.13.1 torchvision==0.14.1 torchaudio==0.13.1 pytorch-cuda=11.7 -c pytorch -c nvidia
RUN conda install habitat-sim-challenge-2022 headless -c conda-forge -c aihabitat -n $MYENV
RUN git clone --branch challenge-2022 https://github.com/facebookresearch/habitat-lab.git /home/app/habitat-lab
RUN conda run -n $MYENV /bin/bash -c \
  "cd /home/app/habitat-lab; pip install -e ."
RUN conda run -n $MYENV /bin/bash -c \
  "python -m pip install<EMAIL_ADDRESS>
WORKDIR /home/app
COPY ./requirements.txt /home/app
RUN conda run -n $MYENV /bin/bash -c \
  "pip install -r requirements.txt"

WORKDIR /home/app/l3mvn

nvidia-smi output

Hey @edwardjjj,
The latest GPUs should work just fine.
This is most likely a configuration issue as some level (drivers, libraries (EGL), wsl/docker).
Some quick troubleshooting steps:

What command did you use to get the error?
Can you run Habitat with the following environment variables: MAGNUM_LOG=verbose, MAGNUM_GPU_VALIDATION=ON? The program output will indicate additional information before the error.
Does eglinfo indicate a problem?
Are you running on X11 or Wayland? Can you try the other?

A similar issue was encountered on a similar environment in this thread. This probably will help troubleshooting.
This thread may also apply to you, as you are building from a similar environment. Make sure to delete your build folder after you fiddle with system libraries so that you don't pull out the issue from cache when rebuilding.

Hi @0mdc,
Thank you for your prompt response. I reverted back to the cudagl:10.1-devel-ubuntu18.04 image and ran the container.
eglinfo on the host
EGL client extensions string:
    EGL_EXT_platform_base EGL_EXT_device_base
    EGL_KHR_client_get_all_proc_addresses EGL_EXT_client_extensions
    EGL_KHR_debug EGL_KHR_platform_x11 EGL_EXT_platform_x11
    EGL_EXT_platform_device EGL_MESA_platform_surfaceless
    EGL_EXT_explicit_device EGL_KHR_platform_gbm EGL_MESA_platform_gbm

GBM platform:
eglinfo: eglInitialize failed

X11 platform:
eglinfo: eglInitialize failed

Device platform:
eglinfo: eglInitialize failed

The eglinfo inside the container:
EGL client extensions string:
    EGL_EXT_platform_base EGL_EXT_device_base EGL_EXT_device_enumeration
    EGL_EXT_device_query EGL_KHR_client_get_all_proc_addresses
    EGL_EXT_client_extensions EGL_KHR_debug EGL_KHR_platform_x11
    EGL_EXT_platform_x11 EGL_EXT_platform_device
    EGL_MESA_platform_surfaceless EGL_EXT_explicit_device
    EGL_KHR_platform_gbm EGL_MESA_platform_gbm EGL_EXT_platform_wayland

Segmentation fault

I'm confused here. So does this mean the container depends on the host EGL environment to function?
ldconfig -p | grep libEGL output:
libEGL_nvidia.so.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libEGL_nvidia.so.0
        libEGL_mesa.so.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libEGL_mesa.so.0
        libEGL_mesa.so.0 (libc6) => /usr/lib/i386-linux-gnu/libEGL_mesa.so.0
        libEGL.so.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libEGL.so.1
        libEGL.so.1 (libc6) => /usr/lib/i386-linux-gnu/libEGL.so.1
        libEGL.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libEGL.so
        libEGL.so (libc6) => /usr/lib/i386-linux-gnu/libEGL.so

Full output with MAGNUM_LOG=verbose and MAGNUM_GPU_VALIDATION=ON:
2023-11-25 00:57:09,741 Initializing dataset ObjectNav-v1
Scenes per thread:
Thread 0: ['4ok3usBNeis', '5cdEh9F2hJL', '6s7QHgap2fW', 'DYehNKdT76V', 'Dd4bFSTQ8gi', 'Nfvxx8J5NCo', 'QaLdnwvtxbs', 'TEEsavR23oF', 'XB4GS9ShBRE', 'bxsVRursffK', 'cvZr5TUy5C5', 'mL8ThkuaVTM', 'mv2HUxq3B53', 'p53SfW6mjZe', 'q3zU7Yy5E5s', 'qyAac8rV8Zk', 'svBbv1Pavdk', 'wcojb4TFT35', 'ziup5kvtCCR', 'zt1RVoi7PcG']
2023-11-25 00:57:12,258 Initializing dataset ObjectNav-v1
2023-11-25 00:57:13,067 initializing sim Sim-v0
[00:57:13:078395]:[Metadata] AttributesManagerBase.h(352)::createFromJsonOrDefaultInternal : <Dataset>: Proposing JSON name : default.scene_dataset_config.json from original name : default| This file does not exist.
[00:57:13:078483]:[Metadata] AssetAttributesManager.cpp(121)::createObject : Asset attributes (capsule3DSolid:capsule3DSolid_hemiRings_4_cylRings_1_segments_12_halfLen_0.75_useTexCoords_false_useTangents_false) created and registered.
[00:57:13:078508]:[Metadata] AssetAttributesManager.cpp(121)::createObject : Asset attributes (capsule3DWireframe:capsule3DWireframe_hemiRings_8_cylRings_1_segments_16_halfLen_1) created and registered.
[00:57:13:078526]:[Metadata] AssetAttributesManager.cpp(121)::createObject : Asset attributes (coneSolid:coneSolid_segments_12_halfLen_1.25_rings_1_useTexCoords_false_useTangents_false_capEnd_true) created and registered.
[00:57:13:078541]:[Metadata] AssetAttributesManager.cpp(121)::createObject : Asset attributes (coneWireframe:coneWireframe_segments_32_halfLen_1.25) created and registered.
[00:57:13:078556]:[Metadata] AssetAttributesManager.cpp(121)::createObject : Asset attributes (cubeSolid:cubeSolid) created and registered.
[00:57:13:078570]:[Metadata] AssetAttributesManager.cpp(121)::createObject : Asset attributes (cubeWireframe:cubeWireframe) created and registered.
[00:57:13:078587]:[Metadata] AssetAttributesManager.cpp(121)::createObject : Asset attributes (cylinderSolid:cylinderSolid_rings_1_segments_12_halfLen_1_useTexCoords_false_useTangents_false_capEnds_true) created and registered.
[00:57:13:078602]:[Metadata] AssetAttributesManager.cpp(121)::createObject : Asset attributes (cylinderWireframe:cylinderWireframe_rings_1_segments_32_halfLen_1) created and registered.
[00:57:13:078618]:[Metadata] AssetAttributesManager.cpp(121)::createObject : Asset attributes (icosphereSolid:icosphereSolid_subdivs_1) created and registered.
[00:57:13:078634]:[Metadata] AssetAttributesManager.cpp(121)::createObject : Asset attributes (icosphereWireframe:icosphereWireframe_subdivs_1) created and registered.
[00:57:13:078649]:[Metadata] AssetAttributesManager.cpp(121)::createObject : Asset attributes (uvSphereSolid:uvSphereSolid_rings_8_segments_16_useTexCoords_false_useTangents_false) created and registered.
[00:57:13:078660]:[Metadata] AssetAttributesManager.cpp(121)::createObject : Asset attributes (uvSphereWireframe:uvSphereWireframe_rings_16_segments_32) created and registered.
[00:57:13:078668]:[Metadata] AssetAttributesManager.cpp(110)::AssetAttributesManager : Built default primitive asset templates : 12
[00:57:13:079062]:[Metadata] SceneDatasetAttributesManager.cpp(35)::createObject : File (default) not found, so new default dataset attributes created  and registered.
[00:57:13:079075]:[Metadata] MetadataMediator.cpp(120)::createSceneDataset : Dataset default successfully created.
[00:57:13:079086]:[Metadata] AttributesManagerBase.h(352)::createFromJsonOrDefaultInternal : <Physics Manager>: Proposing JSON name : ./data/default.physics_config.json from original name : ./data/default.physics_config.json| This file does not exist.
[00:57:13:079097]:[Metadata] PhysicsAttributesManager.cpp(26)::createObject : File (./data/default.physics_config.json) not found, so new default physics manager attributes created and registered.
[00:57:13:079104]:[Metadata] MetadataMediator.cpp(210)::setActiveSceneDatasetName : Attempting to create new dataset ./data/scene_datasets/hm3d/hm3d_annotated_basis.scene_dataset_config.json
[00:57:13:079304]:[Metadata] AttributesManagerBase.h(352)::createFromJsonOrDefaultInternal : <Dataset>: Proposing JSON name : ./data/scene_datasets/hm3d/hm3d_annotated_basis.scene_dataset_config.json from original name : ./data/scene_datasets/hm3d/hm3d_annotated_basis.scene_dataset_config.json| This file does not exist.
[00:57:13:079328]:[Metadata] AssetAttributesManager.cpp(121)::createObject : Asset attributes (capsule3DSolid:capsule3DSolid_hemiRings_4_cylRings_1_segments_12_halfLen_0.75_useTexCoords_false_useTangents_false) created and registered.
[00:57:13:079346]:[Metadata] AssetAttributesManager.cpp(121)::createObject : Asset attributes (capsule3DWireframe:capsule3DWireframe_hemiRings_8_cylRings_1_segments_16_halfLen_1) created and registered.
[00:57:13:079361]:[Metadata] AssetAttributesManager.cpp(121)::createObject : Asset attributes (coneSolid:coneSolid_segments_12_halfLen_1.25_rings_1_useTexCoords_false_useTangents_false_capEnd_true) created and registered.
[00:57:13:079375]:[Metadata] AssetAttributesManager.cpp(121)::createObject : Asset attributes (coneWireframe:coneWireframe_segments_32_halfLen_1.25) created and registered.
[00:57:13:079389]:[Metadata] AssetAttributesManager.cpp(121)::createObject : Asset attributes (cubeSolid:cubeSolid) created and registered.
[00:57:13:079399]:[Metadata] AssetAttributesManager.cpp(121)::createObject : Asset attributes (cubeWireframe:cubeWireframe) created and registered.
[00:57:13:079412]:[Metadata] AssetAttributesManager.cpp(121)::createObject : Asset attributes (cylinderSolid:cylinderSolid_rings_1_segments_12_halfLen_1_useTexCoords_false_useTangents_false_capEnds_true) created and registered.
[00:57:13:079423]:[Metadata] AssetAttributesManager.cpp(121)::createObject : Asset attributes (cylinderWireframe:cylinderWireframe_rings_1_segments_32_halfLen_1) created and registered.
[00:57:13:079436]:[Metadata] AssetAttributesManager.cpp(121)::createObject : Asset attributes (icosphereSolid:icosphereSolid_subdivs_1) created and registered.
[00:57:13:079446]:[Metadata] AssetAttributesManager.cpp(121)::createObject : Asset attributes (icosphereWireframe:icosphereWireframe_subdivs_1) created and registered.
[00:57:13:079459]:[Metadata] AssetAttributesManager.cpp(121)::createObject : Asset attributes (uvSphereSolid:uvSphereSolid_rings_8_segments_16_useTexCoords_false_useTangents_false) created and registered.
[00:57:13:079470]:[Metadata] AssetAttributesManager.cpp(121)::createObject : Asset attributes (uvSphereWireframe:uvSphereWireframe_rings_16_segments_32) created and registered.
[00:57:13:079477]:[Metadata] AssetAttributesManager.cpp(110)::AssetAttributesManager : Built default primitive asset templates : 12
[00:57:13:079586]:[Metadata] SceneDatasetAttributesManager.cpp(35)::createObject : File (./data/scene_datasets/hm3d/hm3d_annotated_basis.scene_dataset_config.json) not found, so new default dataset attributes created  and registered.
[00:57:13:079595]:[Metadata] MetadataMediator.cpp(120)::createSceneDataset : Dataset ./data/scene_datasets/hm3d/hm3d_annotated_basis.scene_dataset_config.json successfully created.
[00:57:13:079603]:[Metadata] MetadataMediator.cpp(217)::setActiveSceneDatasetName : Attempt to create new dataset ./data/scene_datasets/hm3d/hm3d_annotated_basis.scene_dataset_config.json   succeeded. Currently active dataset : ./data/scene_datasets/hm3d/hm3d_annotated_basis.scene_dataset_config.json
[00:57:13:079610]:[Metadata] MetadataMediator.cpp(175)::setCurrPhysicsAttributesHandle : Old physics manager attributes  changed to ./data/default.physics_config.json successfully.
[00:57:13:079615]:[Metadata] MetadataMediator.cpp(66)::setSimulatorConfiguration : Set new simulator config for scene/stage : data/scene_datasets/hm3d/val/00877-4ok3usBNeis/4ok3usBNeis.basis.glb and dataset : ./data/scene_datasets/hm3d/hm3d_annotated_basis.scene_dataset_config.json which is currently active dataset.
eglQueryDevicesEXT(): EGL_BAD_ALLOC error: In eglQueryDevicesEXT: Failed to allocate device list.
Platform::WindowlessEglApplication::tryCreateContext(): no EGL devices found, likely a driver issue
WindowlessContext: Unable to create windowless context
Traceback (most recent call last):
  File "main_llm_vis.py", line 1037, in <module>
    main()
  File "main_llm_vis.py", line 152, in main
    envs = make_vec_envs(args)
  File "/home/app/envs/__init__.py", line 10, in make_vec_envs
    envs = construct_envs21(args)
  File "/home/app/envs/habitat/__init__.py", line 255, in construct_envs21
    zip(args_list, env_configs, range(args.num_processes))
  File "/home/app/envs/habitat/utils/vector_env.py", line 142, in __init__
    read_fn() for read_fn in self._connection_read_fns
  File "/home/app/envs/habitat/utils/vector_env.py", line 142, in <listcomp>
    read_fn() for read_fn in self._connection_read_fns
  File "/opt/conda/envs/habitat/lib/python3.7/multiprocessing/connection.py", line 250, in recv
    buf = self._recv_bytes()
  File "/opt/conda/envs/habitat/lib/python3.7/multiprocessing/connection.py", line 407, in _recv_bytes
    buf = self._recv(4)
  File "/opt/conda/envs/habitat/lib/python3.7/multiprocessing/connection.py", line 379, in _recv
    chunk = read(handle, remaining)
ConnectionResetError: [Errno 104] Connection reset by peer
Exception ignored in: <function VectorEnv.__del__ at 0x7f14194940e0>
Traceback (most recent call last):
  File "/home/app/envs/habitat/utils/vector_env.py", line 549, in __del__
    self.close()
  File "/home/app/envs/habitat/utils/vector_env.py", line 416, in close
    write_fn((CLOSE_COMMAND, None))
  File "/opt/conda/envs/habitat/lib/python3.7/multiprocessing/connection.py", line 206, in send
    self._send_bytes(_ForkingPickler.dumps(obj))
  File "/opt/conda/envs/habitat/lib/python3.7/multiprocessing/connection.py", line 404, in _send_bytes
    self._send(header + buf)
  File "/opt/conda/envs/habitat/lib/python3.7/multiprocessing/connection.py", line 368, in _send
    n = write(self._handle, buf)
BrokenPipeError: [Errno 32] Broken pipe

Seems like a WSL specific issue, closing here.


Convert to Nx

Change the architecture of the project from two folders under src client and server to being a monorepo using Nx so they can both use the ng build and server functionality

Need to rebuild the entire project to better take advantage of Nx and better schematics overall.

Progress is going well. Character and User modules are almost finished being rebuilt in Nest v6. Still need to rebuild front end. GraphQL connections are working well.


Allow order of layers to be changed (be able to bring layers forward / backward)

Changing the order of overlapping elements is extremely cumbersome (user has to delete the furthest layer and recreate it to bring it to the top of the stack).  We need an easier way to manipulate ordering (see the scenario below).  The big question is how should the UI look.
Option 1. We implement a context menu (e.g. a menu that appears when the element is right-clicked, see below), or
Option 2.  We put the ordering controls in our existing sidebar (and avoid creating a whole new menu mechanic)?

Context menu example:

Coming from other tools, the context menu that's in v2 works well and was expected.


gh action updates

manual upgrades from #431 and #432.
potentially interesting read https://pin-gh-actions.kammel.dev/
Rationale:
Not because of being paranoid but mainly because it's considered a good security practice. That practice is also checked by tools like OpenSSF Scorecard so if our repos are benchmarked using that common tooling, it shows we are "compliant".

we make the checks monthly it should be bearable

added a commit to make the cadence monthly. it's "on the first day of the month"


volume thicknessFactor bug?

KHR_materials_volume thicknessFactor seems to be ignored in the Sandbox.
There is no thicknessTexture in this example, not sure if that affects it, or if it's the cause.
volumeThicknessFactor.zip
Thanks!

It was mentioned in this issue in the glTF-Sample-Viewer repo
https://github.com/KhronosGroup/glTF-Sample-Viewer/issues/302

The production site is not updated yet with the latest changes regarding the thickness factor of the volume extension. When it is, this link should render:

and not:

However, even with those changes, your asset will render as:

The thickness only modulates the refraction transmittance in Babylon. The formula is:
refractionTransmittance *= exp(log(attenuationColor)*distance/attenuationDistance);

distance = thicknessFactor in the sample because there's no thickness texture and attenuationDistance = +Infinity because the gltf file does not provide a value. So, exp(...) = (1,1,1) and there's no change in the refraction transmittance color. Even if attenuationDistance is not +Infinity, exp(...) = (1,1,1) because attenuationColor = (1,1,1) (it's the default color when no value is provided in the gltf file).
I can see in the Khronos GLTF viewer that the IOR is modified by the thickness factor (or at least it's what it seems):

From my understanding of the spec, IOR should not be modified by the volume extension...

Adding @bghgary about the spec.

Apparently they are not affecting the IOR at all, rather they are using thickness value to determine the length of the ray in the volume, therefore higher values can lead to a larger offset of the ray.

I have answered in the issue: I think they are recomputing a ray at the exit point of the surface, something we don't do in Babylon, hence the difference.

We have added a new flag to use the thickness to modulate the ray length in the refraction computation: https://github.com/BabylonJS/Babylon.js/pull/10212
With this flag, the output of volumeThicknessFactor.glb is:

closed by #10212


[FEA] Support to_date with non-UTC timezones without DST

I wish we can support to_date with CST(China Time Zone) support.
SELECT to_date(col) from xxx;

@nvliyuan What is the specific string format needed for to_date needed here?

Confirmed in customers query, they only use default format.(yyyy-MM-dd)

Thanks. Then it's on the list of our supported formats. It's depending on https://github.com/NVIDIA/spark-rapids/issues/9997 @razajafri
'yyyy-MM-dd', 'yyyy-MM', 'yyyy/MM/dd', 'yyyy/MM', 'dd/MM/yyyy',  'MM-dd', 'MM/dd', 'dd-MM', 'dd/MM'

to_date(date_str, fmt) is actually replaced at runtime with cast(gettimestamp(date_str, fmt, TimestampType, Some(<session timezone>), false) as date). So it actually depends on #10035 which might depend on #9997

Ultimately once the dependency issues are completed, this is just a verification task.

Basically this requires GpuGetTimestamp work with a non-UTC timezone


XMLParser for jsp only works for jsp directives, but not for all jsp syntaxes

According to this link  and other sources online, there are multiple tags possible in jsp.
It seems the parser is failing to handle different tags than the tested directive.
See unit test added as reference using 2 examples from provided link.
Caused by: org.openrewrite.xml.XmlParsingException: Syntax error in scriptlet.jsp at line 4:5 no viable alternative at input '<%'.
	at org.openrewrite.xml.XmlParser$ForwardingErrorListener.syntaxError(XmlParser.java:120)
	... 123 more
Caused by: org.antlr.v4.runtime.NoViableAltException
	at org.antlr.v4.runtime.atn.ParserATNSimulator.noViableAlt(ParserATNSimulator.java:2031)
	at org.antlr.v4.runtime.atn.ParserATNSimulator.execATN(ParserATNSimulator.java:470)
	at org.antlr.v4.runtime.atn.ParserATNSimulator.adaptivePredict(ParserATNSimulator.java:396)
	at org.openrewrite.xml.internal.grammar.XMLParser.element(XMLParser.java:1060

Added a test case that shows the failure.

Thanks! I think this might be similar to this issue right?

https://github.com/openrewrite/rewrite/issues/4240

We added some basic JSP parser support in March via

https://github.com/openrewrite/rewrite/pull/4075

Looks like we'd need to extend that to cover additional syntax.

Ah!
Now I know where we get these loggings from!
Most likely related indeed!
Did not consider this one to be the same as it was talking about mod cli.
Sorry for the double!

found https://github.com/wjase/jsp-parser/tree/master/src/main/antlr4/com/cybernostics/jsp/parser
which could be usefull for a bases for the antlr processing

found https://github.com/wjase/jsp-parser/tree/master/src/main/antlr4/com/cybernostics/jsp/parser which could be usefull for a bases for the antlr processing

Nice find! One of those times where "last changed 7 years ago" feels right, and not problematic. 😅
Are you exploring an extension to our Antlr spec then?

Well, if I can't sleep I will have a look at this. It's haunting me 😅
But feel free to assign someone if there is no progress here. Started several times already and rollend back.
It's not a piece of cake


transit.roundtrip requires not-included transit.generators

Not clear whether transit.generators was intended to be included as part of this project, or a different one, but it is not in this one right now.

Actually, the transit.roundtrip is obsolete. Removed from src.


cmd/compile: internal compiler error: bad live variable at entry (part 3)

$ gotip version
go version devel +9ab9ca27bb Wed Jun 5 16:33:20 2019 +0000 linux/amd64

This is a follow-up to #29218. On the CL that fixed that one, @josharian wrote:

It is not clear that this fixes every variant of #29218,
but it is a reasonable standalone change.
And code like #29218 is rare and fundamentally buggy,
so we can handle new instances if/when they actually occur.

This is a variant of the reproducer on #29218 that still crashes the tip compiler. The program:
package p

type T struct {
	s string
	f float64
}

func f() {
	var f float64
	var st T
	for {
		switch &st.f {
		case &f:
			f = 1
		}
	}
}

The error is the same as in #29218:
$ gotip build crash.go

# command-line-arguments
<autogenerated>:1: internal compiler error: bad live variable at entry of f: st (type T)

goroutine 37 [running]:
runtime/debug.Stack(0xfd83c0, 0xc000098008, 0x0)
	/home/alberto/go/src/runtime/debug/stack.go:24 +0x9d
cmd/compile/internal/gc.Fatalf(0xe498c8, 0x24, 0xc0004f9758, 0x2, 0x2)
	/home/alberto/go/src/cmd/compile/internal/gc/subr.go:188 +0x291
cmd/compile/internal/gc.(*Liveness).epilogue(0xc0002c8500)
	/home/alberto/go/src/cmd/compile/internal/gc/plive.go:1004 +0xc0e
cmd/compile/internal/gc.liveness(0xc0004d6120, 0xc0004ce420, 0xc0002c6150, 0x0, 0xe3a97a, 0xd)
	/home/alberto/go/src/cmd/compile/internal/gc/plive.go:1399 +0xc4
cmd/compile/internal/gc.genssa(0xc0004ce420, 0xc0002c6150)
	/home/alberto/go/src/cmd/compile/internal/gc/ssa.go:5286 +0x92
cmd/compile/internal/gc.compileSSA(0xc0002c4160, 0x3)
	/home/alberto/go/src/cmd/compile/internal/gc/pgen.go:308 +0x3c2
cmd/compile/internal/gc.compileFunctions.func2(0xc0004c34a0, 0xc0004a4230, 0x3)
	/home/alberto/go/src/cmd/compile/internal/gc/pgen.go:363 +0x49
created by cmd/compile/internal/gc.compileFunctions
	/home/alberto/go/src/cmd/compile/internal/gc/pgen.go:361 +0x128

cc @randall77

Continuing the tradition of fixing these bugs indirectly, I have a CL coming shortly that fixes this, but not for any deep reason, and which is independently justifiable. Thanks for continuing to file these, @ALTree; they're productive sources of optimizations. :)


Reduce cost of basic steel

As setting New Steel has been hidden, basic steel is 8:1 iron plate to steel plate. This is a bit rough. Reduce the cost to 6:1.

Code would be something like this:
if angelsmods then
    if data.raw.recipe["angels-plate-steel-pre-heating"].normal then
        data.raw.recipe["angels-plate-steel-pre-heating"].normal.energy_required = 3 --4 original
        data.raw.recipe["angels-plate-steel-pre-heating"].normal.ingredients = {
            { type = "item", name = "angels-plate-hot-iron", amount = 6 }
        }
    end
    -- dont change marathon
end


restarting builder requires app destroy

if you stop and start builder by deisctl you can't rebuild the app
lorieri@local:~/git/myhack 1 $ git push deis master
/usr/local/bin/gitreceive: line 33: /home/git/myhack.git/hooks/pre-receive: No such file or directory
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
lorieri@local:~/git/myhack 128 $ deis destroy

 !    WARNING: Potentially Destructive Action
 !        To proceed, type "myhack" or re-run this command with --confirm=myhack

> myhack
Destroying myhack...
done in 0s
Git remote deis removed
lorieri@local:~/git/myhack 0 $ deis create myhack
Creating application... done, created myhack
Git remote deis added
lorieri@local:~/git/myhack 0 $ git push deis master
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (5/5), 731 bytes | 0 bytes/s, done.
Total 5 (delta 0), reused 0 (delta 0)

it happened only with heroku build

I've encountered this once, when my cluster moved builder from one node to another. As quick workaround (if you don't want to destroy app), it's sufficient to log to builder instance and execute rm -rf /home/git/myhack.git. It will be recreated with next push.

Thanks :) Very useful!
It didn't migrate.

closing as a duplicate of #3458


cannot install<EMAIL_ADDRESS>

Description
Fails on 3.4.0

Works when downgrading to 3.2.3

We need to revert #901
Steps to Reproduce
Follow Readme for the first time.
https://github.com/lottie-react-native/lottie-react-native#ios-and-android
Versions
8.8.0

Same issue here:
[!] CocoaPods could not find compatible versions for pod "lottie-ios":
  In snapshot (Podfile.lock):
    lottie-ios (from `../node_modules/lottie-ios`)

  In Podfile:
    lottie-ios (from `../node_modules/lottie-ios`)

    lottie-react-native (from `../node_modules/lottie-react-native`) was resolved to 5.1.3, which depends on
      lottie-ios (~> 3.2.3)

Same issue too

It seems that a new version is pending due to this pr: https://github.com/lottie-react-native/lottie-react-native/pull/878

Same issue.
3.2.3 doesn't work for me.
yarn add lottie-react-native<EMAIL_ADDRESS>

node modules podspec has dependency on 3.2.3 version of lottie-ios on lottie-react-native version 5.1.3

same problem

node modules podspec has dependency on 3.2.3 version of lottie-ios on lottie-react-native version 5.1.3  Updating the dependency on podspec to 3.4.0 it works.

This is the only working solution at the moment. The latest version still has the bug. Thanks for this. You should ask the team to have it merged

Also experiencing this using the recommended combination: lottie-react-native@latest <EMAIL_ADDRESS>[!] CocoaPods could not find compatible versions for pod "lottie-ios":
  In snapshot (Podfile.lock):
    lottie-ios

  In Podfile:
    lottie-ios (from `../node_modules/lottie-ios`)

    lottie-react-native (from `../node_modules/lottie-react-native`) was resolved to 5.1.3, which depends on
      lottie-ios (~> 3.2.3)

Also experiencing this using the recommended combination: lottie-react-native@latest <EMAIL_ADDRESS>Updating lottie-react-native.podspec did solve the issue for now!
[!] CocoaPods could not find compatible versions for pod "lottie-ios":
  In snapshot (Podfile.lock):
    lottie-ios

  In Podfile:
    lottie-ios (from `../node_modules/lottie-ios`)

    lottie-react-native (from `../node_modules/lottie-react-native`) was resolved to 5.1.3, which depends on
      lottie-ios (~> 3.2.3)

Yes, just updating this will work, please release a new update!

They mentioned this issue a while go, maybe we are closer to getting it merged ☝
I inspected that PR, it doesn't actually change the line that has the bug, so maybe that line is already fixed in master, but they have not released it! Which means, merging that PR won't be enough to fix our issue. Luckily for us, they noticed it (phew), so we need to wait for the PR merge and release. Hold still my beating ❤ 😬

They've updated the readme on master because the the update commit has landed on master (but has not been released yet)
if you see the readme on the v5.1.3 tag, it tells us to install<EMAIL_ADDRESS>so if you're installing v5.1.3 - run
yarn add lottie-react-native
yarn add<EMAIL_ADDRESS>

Please try installing 5.1.4.
You can see the changelog here:
https://github.com/lottie-react-native/lottie-react-native/releases/tag/v5.1.4

This is unresolved, even with 5.1.4:
Command `pod install` failed.
└─ Cause: CocoaPods could not find compatible versions for pod "lottie-ios":
  In Podfile:
    lottie-ios (from `../node_modules/lottie-ios`)

    lottie-react-native (from `../node_modules/lottie-react-native`) was resolved to 5.1.4, which depends on
      lottie-ios (~> 3.4.0)

~This is unresolved, even with 5.1.4~
users must use exactly<EMAIL_ADDRESS>or earlier

Yes

make sure that both lottie-ios and lottie-react-native have identical dependency versions.

I'm using
 "lottie-react-native": "^5.1.5",
    "lottie-ios": "^4.1.3",

And the problem still there:
Command `pod install` failed.
└─ Cause: CocoaPods could not find compatible versions for pod "lottie-ios":
  In Podfile:
    lottie-ios (from `../node_modules/lottie-ios`)

    lottie-react-native (from `../node_modules/lottie-react-native`) was resolved to 5.1.5, which depends on
      lottie-ios (~> 3.4.0)

I can see that the readme page only states that <= 5.1.4 will need to install lottie-ios 3.4.0.
Just wondering if version 5.1.5 still requires users to install lottie-ios 3.4.0.

I'm using

 "lottie-react-native": "^5.1.5",

    "lottie-ios": "^4.1.3",

And the problem still there:

Command `pod install` failed.

└─ Cause: CocoaPods could not find compatible versions for pod "lottie-ios":

  In Podfile:

    lottie-ios (from `../node_modules/lottie-ios`)

    lottie-react-native (from `../node_modules/lottie-react-native`) was resolved to 5.1.5, which depends on

      lottie-ios (~> 3.4.0)

I can see that the readme page only states that <= 5.1.4 will need to install lottie-ios 3.4.0.
Just wondering if version 5.1.5 still requires users to install lottie-ios 3.4.0.

You do not need to install lottie-ios separately after 5.1.4.
Run pod update to update your cocoapods repositories or clear your cache or try it with a new project.
I will close issue as I could not reproduce on a new fresh project.

You do not need to install lottie-ios separately after 5.1.4.
Run pod update to update your cocoapods repositories or clear your cache or try it with a new project.

This is the final and correct solution, thank you!

You do not need to install lottie-ios separately after 5.1.4.
Run pod update to update your cocoapods repositories or clear your cache or try it with a new project.

This is the final and correct solution, thank you!

thanks

I tried to  do a local build
eas build --platform ios --local
i get this error
Fastlane is not available, make sure it's installed and in your PATH
spawn fastlane ENOENT
npx exited with non-zero code: 1
But when I try to do  a build for ios i get this error
eas build -p android --profile production
[!] CocoaPods could not find compatible versions for pod "lottie-ios":
In Podfile:
lottie-ios (from ../node_modules/lottie-ios)
lottie-react-native (from ../node_modules/lottie-react-native) was resolved to 6.5.1, which depends on
lottie-ios (~> 4.3.3)
[!]  attempted to initialize an object with an unknown UUID. DFC5960ABF794B898B00C404 for attribute: files. This can be the result of a merge and the unknown UUID is being discarded.
Error: Compatible versions of some pods could not be resolved.
You are seeing this error because either:

pod update

Worked for me


Update quickstart.rst

Update dead link for Retreiving Single Application

Pull Request Test Coverage Report for Build 250

0 of 0   changed or added relevant lines in 0 files are covered.
4 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.7%) to 98.328%

Files with Coverage Reduction
New Missed Lines
%

nexmo/init.py
4
99.0%

Totals

Change from base Build 222:
-0.7%

Covered Lines:
294

Relevant Lines:
299

💛  - Coveralls

Looks good - thank you!


Change tracking breaks with string lists

I ran into a problem with a string list on my model where it would try to track the strings, and it would then die. Is this a known issue, and can you replicate?
I've included a small example that also died in 2.0.13
    public class TestThing
    {
        public virtual IList<string> MyStrings { get; set; }

        public TestThing()
        {
            MyStrings = new List<string>();
        }
    }

// ----------------------------------------------------------------
            var test = new TestThing();
            test.MyStrings.Add("wat");

            test = test.AsTrackable();
            test.MyStrings = new List<string>() { "ok", "yea" };

Exception:
|System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.InvalidOperationException: Property Chars is not virtual. Can't track classes with non-virtual properties.
   at ChangeTracking.ChangeTrackingProxyGenerationHook.NonProxyableMemberNotification(Type type, MemberInfo memberInfo)
   at Castle.DynamicProxy.Contributors.MembersCollector.AcceptMethod(MethodInfo method, Boolean onlyVirtuals, IProxyGenerationHook hook)
   at Castle.DynamicProxy.Contributors.WrappedClassMembersCollector.GetMethodToGenerate(MethodInfo method, IProxyGenerationHook hook, Boolean isStandalone)
   at Castle.DynamicProxy.Contributors.MembersCollector.AddMethod(MethodInfo method, IProxyGenerationHook hook, Boolean isStandalone)
   at Castle.DynamicProxy.Contributors.MembersCollector.AddProperty(PropertyInfo property, IProxyGenerationHook hook)
   at Castle.DynamicProxy.Contributors.MembersCollector.CollectProperties(IProxyGenerationHook hook)
   at Castle.DynamicProxy.Contributors.MembersCollector.CollectMembersToProxy(IProxyGenerationHook hook)
   at Castle.DynamicProxy.Contributors.ClassProxyWithTargetTargetContributor.CollectElementsToProxyInternal(IProxyGenerationHook hook)+MoveNext()
   at Castle.DynamicProxy.Contributors.CompositeTypeContributor.CollectElementsToProxy(IProxyGenerationHook hook, MetaType model)
   at Castle.DynamicProxy.Generators.ClassProxyWithTargetGenerator.GenerateType(String name, INamingScope namingScope)
   at Castle.DynamicProxy.Generators.BaseProxyGenerator.ObtainProxyType(CacheKey cacheKey, Func`3 factory)
   at Castle.DynamicProxy.ProxyGenerator.CreateClassProxyWithTarget(Type classToProxy, Type[] additionalInterfacesToProxy, Object target, ProxyGenerationOptions options, Object[] constructorArguments, IInterceptor[] interceptors)
   at ChangeTracking.Core.AsTrackable[T](T target, ChangeStatus status, Action`1 notifyParentListItemCanceled, Boolean makeComplexPropertiesTrackable, Boolean makeCollectionPropertiesTrackable)
   at ChangeTracking.ChangeTrackingCollectionInterceptor`1..ctor(IList`1 target, Boolean makeComplexPropertiesTrackable, Boolean makeCollectionPropertiesTrackable)
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor, Boolean wrapExceptions)
   at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   at ChangeTracking.Core.AsTrackableCollectionChild(Type type, Object target, Boolean makeComplexPropertiesTrackable, Boolean makeCollectionPropertiesTrackable)
   at ChangeTracking.CollectionPropertyInterceptor`1.<>c__DisplayClass12_0.<GetGetterAction>b__0(IInvocation invocation, Dictionary`2 trackables, Boolean makeComplexPropertiesTrackable, Boolean makeCollectionPropertiesTrackable)
   at ChangeTracking.CollectionPropertyInterceptor`1.Intercept(IInvocation invocation)
   at Castle.DynamicProxy.AbstractInvocation.Proceed()
   at ChangeTracking.ComplexPropertyInterceptor`1.Intercept(IInvocation invocation)
   at Castle.DynamicProxy.AbstractInvocation.Proceed()
   at Castle.DynamicProxy.AbstractInvocation.Proceed()
   at ChangeTracking.ChangeTrackingInterceptor`1.Intercept(IInvocation invocation)
   at Castle.DynamicProxy.AbstractInvocation.Proceed()
   at ChangeTracking.NotifyPropertyChangedInterceptor`1.Intercept(IInvocation invocation)
   at Castle.DynamicProxy.AbstractInvocation.Proceed()
   at Castle.Proxies.TestThingProxy.get_MyStrings()
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor, Boolean wrapExceptions)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Reflection.RuntimePropertyInfo.GetValue(Object obj, Object[] index)
   at ChangeTracking.NotifyPropertyChangedInterceptor`1.Intercept(IInvocation invocation)
   at Castle.DynamicProxy.AbstractInvocation.Proceed()

We had the same problem.
As far as i remember the problem is, that the string class is sealed.
Requirements and restrictions
We solved it by creating a new class to wrap the string.
For example:
public class TrackableString : INotifyPropertyChanged
{
    private string _value;
    public virtual string Value
    {
        get => _value;
        set
        {
            _value = value;
            OnPropertyChanged();
        }
    }

    public event PropertyChangedEventHandler PropertyChanged;

    protected virtual void OnPropertyChanged([CallerMemberName] string propertyName = null)
    {
        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
    }
}

It would be great if this library supported lists of primitives, even if you just get a record of the old list and new list and if the list as a whole was modified - it doesn't have to tell you per-item what was added/removed/modified

This was already discussed in #4. Thanks for the feedback, I will keep it in mine.


Incomplete response

I am running base_model : h2oai/h2ogpt-gm-oasst1-en-2048-falcon-7b-v3
and it runs slow but works until it stops being an incomplete answer and breaks to ask again to input instruction.
I am using cli version on windows.
Thanks

For windows and CPU or small GPUs  you should use GGML models instead.  I updated docs to reflect that recommendation better.  Thanks!


Incorrect time for created schedule when event is after Daylight Saving Time change

Version
latest version of tui-calendar.js, tui-date-picker.js and tui-time-picker.js, via uicdn.toast.com
Development Environment
Google Chrome Version 77.0.3865.90 (Official Build) (64-bit) on Fedora Linux
Current Behavior
On the day I am writing this, October 4th 2019, England is using British Summer Time, or DST.  DST will end on Sunday October 27th 2019.
If I use a tui-calendar with default pop up for time and date picker to create an event for a date before 27th October (when DST ends), everything works correctly.  The selected date is passed to my "onCreateSchedule" action with event.start._date of 13:00:00 BST  and I can see that the GMT offset is -60.  When the calendar is rendered again, the display time for the event is correctly shown as 14:00 .  Because I can also store the offset in my database, I can also calculate the correct time to display in an email reminder.  So far, everything is fine.
But, if I now try and create an event on a day after DST has finished, the time is not handled correctly.  For instance, if I create an event on Monday 28th October at 14:00, the time that is passed to my "onCreateSchedule" handler is 16:00, with GMT offset of 0.  When the calendar is next rendered, the event time is 17:00 .
I drilled down into the code to try and understand what happens.  I set a breakpoint in tui-calendar.js at line 19530 - this is in the function
ScheduleCreationPopup.prototype._onClickSaveSchedule = function(target) {
.....
}
19530 has the code
startDate = new TZDate(this.rangePicker.getStartDate()).toLocalTime();
now - if I use the console to display different variables, I can see
this.rangePicker.getStartDate()
Mon Oct 28 2019 14:00:00 GMT+0000 (Greenwich Mean Time)
So the range picker itself has the correct value - 14:00 hours in GMT
var x=new TZDate(this.rangePicker.getStartDate())
undefined
x
TZDate {_date: Mon Oct 28 2019 15:00:00 GMT+0000 (Greenwich Mean Time)}
So TZDate now has a time one hour after the value from the rangePicker.getStartDate().
The final value for the startDate variable in this function is
new TZDate(this.rangePicker.getStartDate()).toLocalTime();
and the result of that is
Mon Oct 28 2019 16:00:00 GMT+0000 (Greenwich Mean Time)
So between creating a TZDate from the correct value from the time picker, and calling toLocalTime() on that, we now have a time that is two hours away from the one in the time picker.
Now in my onCreateSchedule event handler, I get
event.start._date
Mon Oct 28 2019 16:00:00 GMT+0000 (Greenwich Mean Time)
and
event.start._date.getTimezoneOffset()
0
So the time in my event handler (that I send to the database) is two hours away from the time I selected in the time picker, and there is no offset value (of course, there should not be an offset value - the value is correctly 0 for GMT).  So I have the wrong time, and no way to correct it (except for doing a dirty fix, and checking that if the offset is 0 in the target date and not 0 in the date for today, then I should take two hours off myself somewhere).
Next time the calendar is rendered, the situation seems to be even worse, because the displayed time is 17:00 - one more hour is added.  I did not look where that hour is added, but I would guess that there is a further problem with TZDate.  To fix that, it looks like I would have to another GMT/BST check myself and then make another correction (perhaps in my reviver code)
Expected Behavior
When selecting a time of 14:00 hours in GMT, the calendar should pass that time to the onCreateSchedule event, and the calendar should display that time when it is next rendered.

@simonkelly1973  Did you find a fix/ workaround for this? We're seeing the same thing

@simonkelly1973 Did you find a fix/ workaround for this? We're seeing the same thing

I opted for the following (that I referred to as a rather "dirty fix" in my original post).
calendar.on('beforeCreateSchedule', function(event) {
....other stuff....
var today=new Date();
if(today.getTimezoneOffset()===-60 && event.start._date.getTimezoneOffset()===0) {
//We need to hack the time setting.  We may need to still do this after end of BST as well.
event.start.setHours(event.start.getHours()-2);
event.end.setHours(event.end.getHours()-2);
}
....rest of my event handler....
}
So the if block basically checks that if timezone offset for today is -60 (then we are in BST) and timezone offset of date in the event is 0 (then that is in GMT) then we expect that the time for the event will be out by 2, so I set the hours back by two.
What I don't know yet is what will happen after BST finishes in a couple of weeks time - i.e. will events in GMT that are created during GMT be correct, or out by some different number.  So this hack works for now, but I will need to check again in a couple of weeks time after BST ends.  (I thought about getting a VM and just moving the system clock forward, but didn't get to that yet).
Don't forget to also add the same logic to your "beforeUpdateSchedule" logic as well - I forgot that on my first pass.
That takes care of making sure that your created/edited events are correct.  For the problem of the extra hour being added on when the calendar is rendered, I went for the following (basically the same solution)
var schedulesFromJSON=JSON.parse(this.responseText,
(key,value) => {
if(key=='start' || key=='end') {
var d=new Date(value);
if(today.getTimezoneOffset()==-60 && d.getTimezoneOffset()==0) {
d.setHours(d.getHours()-1);	//Deduct the hour to fix tui-calendar/TZDate issue
return String(d);
}
}
.....
});
Again, not sure what will happen after the end of BST.
Hope that helps.

Thanks for that @simonkelly1973
We've ended up with something similar but for dates going into the calendar as well

Hi, here just to share my approach (Only for displaying, entries are done different in my case).
            data.start = moment(currentItem.from_full).toDate();
            data.end = moment(currentItem.till_full).toDate();

            let nowDate = moment().toDate();

            if (nowDate.getTimezoneOffset() === -60) {
              if (data.start.getTimezoneOffset() === -120) {
                data.start.setHours(data.start.getHours() + 1);
              }
              if (data.end.getTimezoneOffset() === -120) {
                data.end.setHours(data.end.getHours() + 1);
              }
            } else if (nowDate.getTimezoneOffset() === -120) {
              if (data.start.getTimezoneOffset() === -60) {
                data.start.setHours(data.start.getHours() - 1);
              }
              if (data.end.getTimezoneOffset() === -60) {
                data.end.setHours(data.end.getHours() - 1);
              }
            }

@haringsrob Hello Rob.  I guess from the "-120" values in your code that you are somewhere in the Europe (Belgium from your profile) at GMT+2 (BST+1)?  So the problem is not exclusive to GMT/BST in the UK?

Hi @simonkelly1973 , Yes I am from Belgium indeed.

Hi,
in Spain we also have that problem. We have summer (GMT+2) and winter (GMT+1) time. If we perform any treatment to show it well, the time change with another use would not be correct and this is a problem when showing two time uses.

This Sunday we go back to GMT here in the UK-so I will check if the behaviour changes for GMT events created in GMT.

Here in the UK, it's now GMT and events scheduled in GMT now work correctly. I'm yet to test an event in BST from GMT.

For me (with my code) it works fine as well.

Same problem. All schedules which are created in datetime saving (GMT+2) are shown at wrong time.
Example: Wed Oct 23 2019 05:00:00 GMT+0200 (Mitteleuropäische Sommerzeit) is shown at 04:00.

I am in the US (East Coast) and experienced a similar problem when Daylight Saving Time (EDT) here ended and adjusted back to Standard Time (EST) recently on 11/3 where the schedule times were 1 hour off the time actually entered when viewing across the DST time change on the calendar grid.
I am running v 1.7.0 and cannot easily upgrade to a new version, though it appears the problem may still exist in the later versions as well.  So, I investigated the calendar library code myself to see if I could resolve the issue.  I discovered that the internal Timezone class in the calendar library provides a callback facility where you can register your own custom function to calculate and return the timezone value you need.  So, my solution was to implement and register my own custom function to basically extract and return the timezone from the timestamp value passed to the custom function.  This has resolved my issue without having to modify the actual TUI Calendar library code or adjusting my schedule event starting or ending times.  I do see in the code that this callback facility is marked as deprecated, but hopefully this issue will be resolved in a future version rendering this custom callback unnecessary.
In the hopes of helping someone else with a similar issue, I am adding more code details below.
The line that seems to be causing the issue in the Calendar library code is in the "src/js/common/timezone.js" module inside the createDateWithSingleArg() function.  The last line that returns the calculated value is causing the issue.  Here is how my version of this function looks:
function createDateWithSingleArg(arg) {
    var time;

    if (arg instanceof Date || arg instanceof TZDate) {
        time = arg.getTime();
    } else if ((typeof arg) === 'string') {
        time = Date.parse(arg);
    } else if ((typeof arg) === 'number') {
        time = arg;
    } else if (arg === null) {
        time = 0;
    } else {
        throw new Error('Invalid Type: ' + arg);
    }

    return new Date(time - getCustomTimezoneOffset(time) + getTimezoneOffset(time));
}

In the return statement line in the code above, after adjusting to EST the getCustomTimezoneOffset(time) call was returning 5 and the getTimezoneOffset(time) call was returning 4, which yields the following:
return new Date(time - 5 + 4);
which resulted in the 1-hour offset (earlier in this case, but after switching back to EDT it will be later).
The following were the changes I added to my code:

In the module where I created the Calendar instance, I registered the callback just before creating the Calendar instance with the following statement:
Calendar.setTimezoneOffsetCallback(getLocalTimezoneOffset);

The getLocalTimezoneOffset() callback function that I implemented simply extracts and returns the timezone offset from the timestamp passed to the function (which ultimately comes from the schedule starting and ending timestamps):

    function getLocalTimezoneOffset(timestamp) {
        return new Date(timestamp).getTimezoneOffset();
    }

That is all I needed to address the issue.  I hope this helps someone else that is experiencing this issue until it is resolved in a future release.  I would like to commend the developer that had the foresight to add this feature, which really helped me resolve my own issue without having to modify the library code itself.  Overall, I have been impressed with the functionality of the TUI Calendar and hope to upgrade to a newer version at some point in the future.  Thanks!

Bump, same here. Please fix it ASAP.

The following were the changes I added to my code:

In the module where I created the Calendar instance, I registered the callback just before creating the Calendar instance with the following statement:
Calendar.setTimezoneOffsetCallback(getLocalTimezoneOffset);
The getLocalTimezoneOffset() callback function that I implemented simply extracts and returns the timezone offset from the timestamp passed to the function (which ultimately comes from the schedule starting and ending timestamps):

    function getLocalTimezoneOffset(timestamp) {
        return new Date(timestamp).getTimezoneOffset();
    }

That is all I needed to address the issue. I hope this helps someone else that is experiencing this issue until it is resolved in a future release.

Thanks @clelmore for this quick fix. I will be using that fix until my PR is reviewed and merged.


[3375] Add system admin users tab

Context
Add a users show page so we can see individual user details.
Changes proposed in this pull request
add users show page

@richardpattinson I think the show page should look like the lead school show page.
User show page

Lead school show page

@richardpattinson I think the show page should look like the lead school show page.
User show page

Lead school show page

Should be fixed now =)

 [S] User show page


Cluster autoscaler 1.19.2 nr1

branched off of https://github.com/kubernetes/autoscaler/tree/cluster-autoscaler-1.19.2
cherry picked https://github.com/newrelic-forks/autoscaler/pull/2/commits/ef38ce684c4ac851934d9b18c4a4da92f98caf0e
i probably could have used hack/update-vendor.sh from master. to get this one running on your mac
brew install bash
brew install<EMAIL_ADDRESS>brew install findutils #for xargs
# edit hack/update-vendor.sh because the flags don't work
# K8S_REV="v1.19.2"
# OVERRIDE_GO_VERSION="true"
/usr/local/bin/bash ./hack/update-vendor.sh  # use your new bash
CGO_ENABLED=0 GO111MODULE=off GOOS=linux GOARCH=amd64 go build -o cluster-autoscaler-amd64
docker build -t cluster-autoscaler:v1.19.2-nr1 -f Dockerfile.amd64 .

I think this PR needs to be rebased to cluster-autoscaler-release-1.19. This should fix all the conflicts.
Also to follow the standards and the previous work, could we rename this branch to cluster-autoscaler-release-1.19-nr1 ?

Might be interesting to port https://github.com/kubernetes/autoscaler/pull/3940 as well, just like we did in https://github.com/newrelic-forks/autoscaler/pull/2


[Android] Bitwarden not working on newer versions, but works for older ones.

I updated to v85 from v83, but I noticed that it didn't update the app. It installed a new app. The newer version doesn't properly support Bitwarden. If I manually summon autofill, Bitwarden doesn't detect the site, but it only detects Ungoogled Chromium as a regular app, not a browser. It worked just fine on the older version.

Can you file a bug report with them? They need to update the package names in [Android/Accessibility/AccessibilityHelpers.cs) and Android/Autofill/AutofillHelpers.cs.

Just did https://github.com/bitwarden/mobile/issues/1118

@nullsurfer @wchen342 PR done. :thumbsup:

Merged: https://github.com/bitwarden/mobile/pull/1119. Thanks @contribucious!!!

:v: :wink: