Manual roll Flutter Engine from 84dcb4fb9301 to 2fb824c3cb3b (18 revisions)

Manual roll requested by<EMAIL_ADDRESS>https://github.com/flutter/engine/compare/84dcb4fb9301...2fb824c3cb3b
2023-10-30<EMAIL_ADDRESS>Revert "Roll Dart SDK from 5a666e8d8259 to 38e8459ca2aa (4 revisions)" (flutter/engine#47459)
2023-10-30<EMAIL_ADDRESS>Roll Skia from 09818d8c9d3c to<PHONE_NUMBER>82 (1 revision) (flutter/engine#47458)
2023-10-30<EMAIL_ADDRESS>Roll Skia from 6e9cd1b79105 to 09818d8c9d3c (1 revision) (flutter/engine#47456)
2023-10-30<EMAIL_ADDRESS>Remove call to SkTypeface::MakeDefault (flutter/engine#47344)
2023-10-30<EMAIL_ADDRESS>Roll Fuchsia Linux SDK from LbIVijDVwcB56_wgv... to zf2xLsbeoVrbnEDiH... (flutter/engine#47452)
2023-10-30<EMAIL_ADDRESS>Roll Skia from c732ec7f5d74 to 6e9cd1b79105 (2 revisions) (flutter/engine#47451)
2023-10-30<EMAIL_ADDRESS>Roll Skia from e45946f89a8b to c732ec7f5d74 (2 revisions) (flutter/engine#47448)
2023-10-30<EMAIL_ADDRESS>Roll Fuchsia Mac SDK from OJfJYAvhpAkE-kvbY... to jCjz-imbNBDjiRVa1... (flutter/engine#47447)
2023-10-30<EMAIL_ADDRESS>Roll Skia from 7545d1468268 to e45946f89a8b (1 revision) (flutter/engine#47446)
2023-10-29<EMAIL_ADDRESS>Roll Skia from e224e1dc5e2c to 7545d1468268 (1 revision) (flutter/engine#47444)
2023-10-29<EMAIL_ADDRESS>Roll Fuchsia Linux SDK from v-9_Di17lm_C_mrpZ... to LbIVijDVwcB56_wgv... (flutter/engine#47443)
2023-10-29<EMAIL_ADDRESS>Roll Fuchsia Mac SDK from s0pbwY5MGxyq0tNrT... to OJfJYAvhpAkE-kvbY... (flutter/engine#47439)
2023-10-29<EMAIL_ADDRESS>Roll Skia from d29cc3fe182f to e224e1dc5e2c (1 revision) (flutter/engine#47438)
2023-10-29<EMAIL_ADDRESS>Roll Fuchsia Linux SDK from nreLekedxzmcdb3ww... to v-9_Di17lm_C_mrpZ... (flutter/engine#47436)
2023-10-29<EMAIL_ADDRESS>Roll Fuchsia Mac SDK from qiHQ7aarDQb_1Rq3G... to s0pbwY5MGxyq0tNrT... (flutter/engine#47431)
2023-10-28<EMAIL_ADDRESS>Roll Fuchsia Linux SDK from ESkamdoXWIwkdWdP-... to nreLekedxzmcdb3ww... (flutter/engine#47429)
2023-10-28<EMAIL_ADDRESS>Roll Fuchsia Mac SDK from 9YSl2rN0sj5YpYNdQ... to qiHQ7aarDQb_1Rq3G... (flutter/engine#47428)
2023-10-28<EMAIL_ADDRESS>Roll Dart SDK from 5a666e8d8259 to 38e8459ca2aa (4 revisions) (flutter/engine#47426)
Also rolling transitive DEPS:
fuchsia/sdk/core/linux-amd64 from ESkamdoXWIwk to zf2xLsbeoVrb
fuchsia/sdk/core/mac-amd64 from 9YSl2rN0sj5Y to jCjz-imbNBDj
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC aaclarke@google.com,rmistry<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://issues.skia.org/issues/new?component=1389291&template=1850622
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Closing. The analyzer flake is preventing this from landing, and the fix should be coming very shortly.


Relationship between 'Population Frequency', 'Relative Population Frequency', and 'Condition Risk' Annotations

These three annotation types are related as they build on each other to make statements of higher-order reach and complexity.  Here, more fundamental annotations are/can be used as input or evidence in building more complex annotations. So a higher-order Condition-Risk Annotation may package a pre-existing 'Relative Population Frequency' annotation as evidence, which in turn may package a pre-existing 'Population Frequency' annotation as evidence/supporting data (see the data example  below).
Definitions/Scope of Each:
Population Frequency

Definition: an annotation about the observed frequency of a variant in a defined group of individuals.
Examples: "Allele CAR:CA123287 occurs in 1198 of 7344 chromosomes measured in Non-Finnish Europeans"
Scope (of statement): reports data from a single study, that is about only the freq of a variant in the participants in the study
Evidence: n/a  - these annotations merely report data/findings from a study, not broader evidence-based conclusions/assertions.

Relative Population Frequency

Definition: an annotation about the relative frequency of an allele as found in two different groups of individuals or specimens (e.g. affected vs unaffected study groups of a case-control clinical study, ethnic group populations, tumor sample collections from two cancer subtypes)
Examples:

The frequency of the CAR:CA024311 allele was between 2 and 10%  in cases (of a condition) and .013% (9/66740) in controls
The odds ratio for the CAR:CA253316 variant being associated with hearing loss in a clinical cohort relative to race-matched ExAC population used as control  is 9.1361 (6.1425 - 13.588) w/ 99% confidence
The  CAR:CA253316 variant  is 5 times more common in ER+ vs ER- breast carcinoma specimens

Scope (of statement): reports data from a single study, that is about only the participants in the study (but maybe used to infer broader conclusions/assertions about a larger population in the world)
Evidence:  uses Population Frequency annotations/data (from two different populations) as evidence to calculate relative freq scores

Condition Risk Annotation (formerly Variant Predisposition Annotation)

Definition: an annotation about the likelihood of developing  a particular disease prior to its onset, given the presence of a particular genetic variant (e.g. high, medium, low, or no risk).
Example: "“NM_007194.3(CHEK2):c.1100delC (p.Thr367Metfs) confers a low risk for Familial Breast Cancer”"
Scope (of statement): broader conclusion about anyone meeting the criteria defining a 'population' having inc/dec risk of developing a condition
Evidence:  uses Relative Population Frequency annotations/data (from one or more studies) as evidence to infer statement about overall risk associated with a variant

Evidence Hierarchy Example
id: CondRiskAnnot00001
type: Condition Risk Annotation
description: "NM_007194.3(CHEK2):c.1100delC poses a moderate risk for Breast Cancer in Caucasian women"
subject: NM_007194.3(CHEK2):c.1100delC (p.Thr367Metfs)
predicate: moderate_risk_for
descriptor: Breast Cancer
qualifier: {
  id: Population00001
  type: Population
  race: caucasian
  age: any
  ...
}

evidence: [
    {
     id: RelPopFreq00001
     type: Relative Population Frequency
     description: "The odds ratio for the NM_007194.3(CHEK2):c.1100delC variant being associated with Breast Cancer in a clinical cohort relative to race-matched ExAC population used as control is 1.85"
     subject: NM_007194.3(CHEK2):c.1100delC (p.Thr367Metfs)
     descriptor: {
         id: OR000001
         type: odds ratio
         value: 1.85
      }
      ...

  evidence: [
      {
      id: PopFreq00001
      type: PopFreqAnnotation
      description: "NM_007194.3(CHEK2):c.1100delC is present in control female Caucasian populations (in ExAC) at a frequency of 0.021%"
      . . .
     },
     {
      id: PopFreq00002
      type: PopFreqAnnotation
      description: "NM_007194.3(CHEK2):c.1100delC is present in the Caucasian female case group at a frequency of 2.3%"
      ...
     }

Issues:

Does this generally make sense as a way to partition and relate annotation types?
Relative Population Frequency annotations can include things like relative risk scores and odds ratios, which go beyond describing relative frequencies  to provide a quantification of the chance of developing a condition.  This seems more in scope for Variant-Condtion Risk Annotation, but in our model here is framed as more fundamental info used as evidence for making the Risk Annotation which represents a broader conclusion about the wider population.

Just a semantic note: Please don't use 'race'. It is used in U.S. census data with some specific, but not genetically relevant, meaning; it (rightfully) isn't used with a genealogic meaning.
"ancestral group" may be fitting (but there may be expert opinions about alternatives...).

I am not a domain expert by any means, but conceptually it looks like a sound and logical approach to me. I will share with some of the ClinGen domain experts and report back their comments.
@mbrush - minor observation - your example should have the variant subject in the lowest level pop freq evidence items, I believe. If not, I'd like to know why not.


Android Compatibility

Android Client API for Dolphin Platform

This change is

Coverage decreased (-0.03%) to 67.701% when pulling 2dd1ef1c96fe3f88af713886931437c628a94132 on android into 356979fadd08814b6aabc0239f782d1291bcce00 on master.

Coverage increased (+0.04%) to 67.768% when pulling cb455ee73c64517a023cba3052a4f6762cce6f3b on android into 356979fadd08814b6aabc0239f782d1291bcce00 on master.

Coverage decreased (-0.3%) to 67.425% when pulling 453647b5cce46119267a71ad385d7ac77c2c00eb on android into 356979fadd08814b6aabc0239f782d1291bcce00 on master.

Coverage decreased (-0.2%) to 67.486% when pulling e0f549496fcd399152e976e1f448b6d6f8ef286d on android into 356979fadd08814b6aabc0239f782d1291bcce00 on master.

Coverage decreased (-0.3%) to 67.468% when pulling 43aeee96195a7c95566959932bb2642c4cc1ac60 on android into 356979fadd08814b6aabc0239f782d1291bcce00 on master.

Coverage decreased (-0.2%) to 67.486% when pulling 4dc734c7d8f3924a1c8731a582b97a02931cb238 on android into 356979fadd08814b6aabc0239f782d1291bcce00 on master.

Coverage decreased (-0.2%) to 67.486% when pulling 4dc734c7d8f3924a1c8731a582b97a02931cb238 on android into 356979fadd08814b6aabc0239f782d1291bcce00 on master.

Coverage decreased (-0.2%) to 67.704% when pulling 0d98d32e9a97670f1f1355854e6287b4a2a9d26e on android into af9c851f16de91e8525d70198d1eb0e20d7f230c on master.

Coverage decreased (-0.2%) to 68.449% when pulling 1c26a03b96f19e8c42fbcc34928c56273dd9a2fc on android into 905c67f19ed9e539bc60c8a2c9bb615547dba6a7 on master.

integration-tests/src/test/java/com/canoo/dolphin/integration/AbstractIntegrationTest.java, line 52 at r8 (raw file):

                    HttpURLConnection httpURLConnection = (HttpURLConnection) connection;
                    httpURLConnection.connect();
                    if(httpURLConnection.getResponseCode() == 200) {

Use Enum

Comments from Reviewable

Coverage decreased (-0.3%) to 68.347% when pulling 58f3817cca725f6f8ab1fbf053fd203da8ec8a9b on android into 905c67f19ed9e539bc60c8a2c9bb615547dba6a7 on master.

Coverage decreased (-0.3%) to 68.329% when pulling 00ee8f2de55fe075dfd7014b3cc1bd2fcede93dd on android into 905c67f19ed9e539bc60c8a2c9bb615547dba6a7 on master.

Coverage decreased (-0.3%) to 68.347% when pulling 5792540b3725c23f5058c0711e7b53e77f24313a on android into 905c67f19ed9e539bc60c8a2c9bb615547dba6a7 on master.

Coverage decreased (-0.3%) to 68.347% when pulling 5f774c710d0c298f0cc2e533a969e181dd03cd93 on android into 905c67f19ed9e539bc60c8a2c9bb615547dba6a7 on master.

Reviewed 7 of 23 files at r1, 10 of 13 files at r2, 10 of 11 files at r3, 10 of 14 files at r4, 1 of 2 files at r5, 8 of 11 files at r8, 1 of 5 files at r9.
Review status: 42 of 47 files reviewed at latest revision, 1 unresolved discussion, some commit checks failed.

Comments from Reviewable

Coverage decreased (-0.3%) to 68.329% when pulling 5f774c710d0c298f0cc2e533a969e181dd03cd93 on android into 905c67f19ed9e539bc60c8a2c9bb615547dba6a7 on master.

Review status: 42 of 47 files reviewed at latest revision, 1 unresolved discussion, some commit checks failed.

integration-tests/src/test/java/com/canoo/dolphin/integration/AbstractIntegrationTest.java, line 52 at r8 (raw file):
Previously, timo0 (Timo B) wrote…
Use Enum

Done.

Comments from Reviewable

Reviewed 3 of 5 files at r9, 1 of 2 files at r10, 1 of 1 files at r11.
Review status: all files reviewed at latest revision, 1 unresolved discussion, some commit checks failed.

Comments from Reviewable

Coverage decreased (-0.3%) to 68.347% when pulling 5f774c710d0c298f0cc2e533a969e181dd03cd93 on android into 905c67f19ed9e539bc60c8a2c9bb615547dba6a7 on master.

Coverage decreased (-0.3%) to 68.329% when pulling 5f774c710d0c298f0cc2e533a969e181dd03cd93 on android into 905c67f19ed9e539bc60c8a2c9bb615547dba6a7 on master.


az webapp does not support deployment source of Azure Pipeline

Expected
In the azure portal a webapp can be configured to be deployed from azure pipeline. "Az webapp" is expected to support this configuration as well.
Actual
"Az webapp" does not support configuring a webapp to be deployed from azure pipeline.

route to appropriate team

@FlourishS I am not sure I understand the issue here - what exact deployment are you referring? GitHub deployment/ git hub actions? can you share the screenshot from azure portal you are referring to? Thanks!

Thank you very much for your reply.
Please see below the screenshots from azure portal:

This is by-design, there are no plans to support Azure Pipelines configuration through WebApps CLI
CC: @panchagnula


Include hidden username field on password reset to help password managers

Include hidden username field on password reset to help password managers

Hi @collinanderson,
New features require a ticket at https://code.djangoproject.com/
Could you create a new ticket if one doesn't already exist?

@collinanderson Thanks :+1: I added a simple test.


Add elastix and transformix cli examples to test suite

Ref #1664 and #1732

The GitHub actions build with Elastix enabled and is reporting the following error:
terminate called after throwing an instance of 'itk::ExceptionObject'
[9236](https://github.com/SimpleITK/SimpleITK/actions/runs/3313102149/jobs/5470623360#step:7:9237)
  what():  /var/lib/actions-runner/_work/SimpleITK/SimpleITK/sitk-bld/Elastix/Common/ParameterFileParser/itkParameterFileParser.cxx:117:
[9237](https://github.com/SimpleITK/SimpleITK/actions/runs/3313102149/jobs/5470623360#step:7:9238)
ITK ERROR: ParameterFileParser(0xfffffdeeeaf0): ERROR: the file /var/lib/actions-runner/_work/SimpleITK/SimpleITK/sitk-bld/SimpleITK-build/Testing/Temporary/CXX.Example.elx.TransformParameters.txt does not exist.

Ah, yes, the tfx test depends on the elx test to generate the transform parameters. I don't see a way to add this dependency between the tests. Do you know? Otherwise we can perhaps also add the transform parameter file to SimpleITKData? What do you think?

#1732 also happens on self-hosted-arm. Trying with the fix suggested in the issue.

Through CMake test properties dependencies can be added:
https://cmake.org/cmake/help/latest/prop_test/DEPENDS.html

I very much agree that it doesn't fix the underlying problem. I just wanted to test if the work-around on your CI and will revert the commit to keep this PR focused on adding the CLIs to the tests.

@kaspermarstal Are we close to understanding the underlying cause of the issue and finding a solution? If not perhaps we should move forward with the work around and document the issue so hopefully it can be worked on in the future?

@kaspermarstal Do you have some time to move this additional testing and quick fix forward?

Yes, sorry, I think I've found the underlying cause. Let's see what the CI says :)

@kaspermarstal I updated your PR branch to be based on the current release branch. Hopefully that helps with some of the CI issues.

I see the follow error in CDash(https://open.cdash.org/test/884577464):
Image Compare: /Users/runner/work/1/s-build/SimpleITK-build/Testing/Temporary/CXX.Example.elx.nii /Users/runner/work/1/s-build/SimpleITK-build/Testing/Temporary/CXXT.Example.tfx.nii 40
/Users/runner/work/1/s-build/SimpleITK-build/bin/tfx /Users/runner/work/1/s-build/SimpleITK-build/ExternalData/Testing/Data/Input/BrainProtonDensitySliceShifted13x17y.png /Users/runner/work/1/s-build/SimpleITK-build/Testing/Temporary/CXX.Example.elx.TransformParameters.txt /Users/runner/work/1/s-build/SimpleITK-build/Testing/Temporary/CXXT.Example.tfx.nii
libc++abi: terminating with uncaught exception of type itk::ExceptionObject: /Users/runner/work/1/s-build/Elastix/Common/ParameterFileParser/itkParameterFileParser.cxx:117:
ITK ERROR: ParameterFileParser(0x7ffeee1010b8): ERROR: the file /Users/runner/work/1/s-build/SimpleITK-build/Testing/Temporary/CXX.Example.elx.TransformParameters.txt does not exist.
sitkCompareDriver: Process exception: Subprocess aborted

@Zivy The format for the file is outside the scope here. However, should the file be committed directly or be converted to a sha512 and placed in the ExternalData repo? Either way the file should still be moved to the Testing/Data/Input directory.

@blowekamp I think the config file should be left in its current place and included into the sphinx documentation, possibly also include a hyperlink pointing people to the elastix model zoo.

@zivy @kaspermarstal  I'll create a follow up PR with the suggestion.


Lsp autocompletion no close parenthesis

Godot version
4.1.3
System information
Godot v4.1.2.stable - KDE neon 5.27 22.04 - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1650 (nvidia; 525.125.06) - Intel(R) Core(TM) i5-10300H CPU @ 2.50GHz (8 Threads)
Issue description
I using an external editor (Neovim). I've also tested this with Visual Studio Code. When I use autocompletion for functions, it doesn't automatically close parentheses. I've tested this on both Linux and Windows, with the latest version (4.1.3) as well as the Steam version.
If I use autocompletion with the print() function, the editor suggests the function, and when I press Enter, the autocompletion result is: print(. The same issue occurs with the append() function of an array, and the result is test.append(. Likewise with many other functions. However, in the Godot editor, there is no problem.

Steps to reproduce
I don't know how to reproduce this bug. I tested the autocompletion on someone else's Ubuntu, and there were no issues using VSCode. As mentioned above, I tested it on two different computers with different operating systems, using both VSCode with godot-tools installed and Neovim, and the bug still persists for me.
Minimal reproduction project
Any project with a GDScript script is sufficient.

Godot auto completion only returns the opening parenthesis if the function has parameters. It relies on the client doing auto brace completion which both VSCode and the Godot Script Editor support. If it would return both opening and closing braces, the cursor would be placed after the closing brace, which would make it very hard to enter arguments.
Looks like a design constraint to me, although it would be interesting to know how other Language Servers handle this.
You should look for an auto brace completion plugin for neovim.

Godot auto completion only returns the opening parenthesis if the function has parameters. It relies on the client doing auto brace completion which both VSCode and the Godot Script Editor support. If it would return both opening and closing braces, the cursor would be placed after the closing brace, which would make it very hard to enter arguments.
Looks like a design constraint to me, although it would be interesting to know how other Language Servers handle this.
You should look for an auto brace completion plugin for neovim.

As mentioned in my post, I tested it on VSCode. I work with different languages, and I've never had this issue with Neovim and VSCode. So, for me, it's indeed a bug coming from the GDScript LSP. Let me clarify; I tested it on VSCode with the Godot plugin, which is well-configured since I have autocompletion that correctly detects function names. The same goes for Neovim, which correctly captures function names along with their documentation.
And it cannot be a flaw coming from a VSCode setting that does not correctly close parentheses or from my Neovim plugin that automatically closes parentheses and braces because, in a simple text file, or any other non-exotic languages, both editors correctly close them.

This is extremely disturbing. The problem still persists and that's the only reason I can't use Godot. Have you found any solution?

This is extremely disturbing. The problem still persists and that's the only reason I can't use Godot. Have you found any solution?

I'm sorry, but the bug still persists and I haven't found any workarounds. I think our only option left is to use the mono version of Godot which uses C#. We won't have any LSP issues with C#. But, it's a shame to have to use this language instead of GDScript. Alternatively, we could use Godot's built-in tools.

Ok I somehow remembered not being able to reproduce this, but after trying again I can (in VSCode).
I also looked at what other languages do (in VSCode). Python as well as typescript don't add parenthesis at all. I wonder if that would be better. It will probably solve problems for some people that use strict settings to prevent mismatched parens. But you would still need to type the braces yourself.
That being said I think it would make sense to align the GDScript behavior with more popular languages, to not break expectations. (Only talking about VSCode, since everything works well in Godot).


Support correctly .prettierignore

Description
Support prettier ignore configuration load from .github/config/.prettierignore
Changes Made
Support prettier ignore configuration load from .github/config/.prettierignore
Related Issues
Fixes #61
Checklist

[x] I have used a PR title that is descriptive enough for a release note.
[x] I have tested these changes locally.
[x] I have added appropriate tests or updated existing tests.
[ ] I have tested these changes on a dedicated VM or a customer VM [name of the VM]
[x] I have added appropriate documentation or updated existing documentation.

@hiimjako following this pr, you can add a file .github/config/.prettierignore
with:
../../vendor/*.md
../../vendor/*.MD

in golang repos and should do.


Funding TX Recovery

For the final part of #386
Comments:

Uses CPFP, spending from our change funding point output
Done some refactoring in fundingmanager + lnd test to prevent code dup
Have only been testing this in simnet so far, but the workflow seems correct

This PR is mainly to get initial feedback on how this mechanism will work, would be great to get some comments on my initial ideas.
Pull Request Checklist

[ ] If this is your first time contributing, we recommend you read the Code
Contribution Guidelines
[ ] All changes are Go version 1.12 compliant
[ ] The code being submitted is commented according to Code Documentation and Commenting
[ ] For new code: Code is accompanied by tests which exercise both
the positive and negative (error paths) conditions (if applicable)
[ ] For bug fixes: Code is accompanied by new tests which trigger
the bug being fixed to prevent regressions
[ ] Any new logging statements use an appropriate subsystem and
logging level
[ ] Code has been formatted with go fmt
[ ] For code and documentation: lines are wrapped at 80 characters
(the tab character should be counted as 8 characters, not 4, as some IDEs do
per default)
[ ] Running make check does not fail any tests
[ ] Running go vet does not report any issues
[ ] Running make lint does not report any new issues that did not
already exist
[ ] All commits build properly and pass tests. Only in exceptional
cases it can be justifiable to violate this condition. In that case, the
reason should be stated in the commit message.
[ ] Commits have a logical structure according to Ideal Git Commit Structure

How do we handle stuck funding transactions with no change output?
Also, note that there is a fundingmanager refactor PR up: #1910

Then we should not entering recovery mode, and just continue to note. Will need to implement that

How do we handle stuck funding transactions with no change output?

Currently we fail the recovery workflow, added a change to prevent entering it in the first place

@halseth I've rebased ontop of your changes in #1910

Now that we have fee bumping added, we should explore reusing that logic to bump the funding tx fee: https://github.com/lightningnetwork/lnd/pull/3140

After discussing this a bit we have come to the conclusion we do not want to introduce more persistent state during the funding process. Instead we should let the fundingmanager

unlock the coins after a timeout, making them spendable in other transactions.
In combination with something like #1755  this should allow it to gracefully fail the channel.

To bump the fee on an unconfirmed channel manually, the current bump fee logic can be used.
I will add this to the issue, feel free to open a new PR for 1).


HikariPool Open Connection is constantly throwing error message. Can i evict every connection before closing it?

I am getting the following message on every open connection, it seems like the connection.isAlive check is trying to setNetworkTimeout, which is not implemented. It is just a warning message, but i noticed that it ends up just closing the connection. Is is okay for me to do that, but evicting the connection manually before calling hikariconn.close(), this way it does the same thing, but does not throw this nasty exception everytime ?
WARN 1 --- [   scheduling-1] com.zaxxer.hikari.pool.ProxyConnection   : HikariPool-5 - Connection oracle.jdbc.driver.T4CConnection@65eff3f5 marked as broken because of SQLSTATE(08003), ErrorCode(17008)
java.sql.SQLRecoverableException: Closed Connection
at oracle.jdbc.driver.T4CConnection.doSetNetworkTimeout(T4CConnection.java:6967) ~[ojdbc8-<IP_ADDRESS>.jar!/:<IP_ADDRESS>.0]
at oracle.jdbc.driver.PhysicalConnection.setNetworkTimeout(PhysicalConnection.java:9083) ~[ojdbc8-<IP_ADDRESS>.jar!/:<IP_ADDRESS>.0]
at com.zaxxer.hikari.pool.ProxyConnection.setNetworkTimeout(ProxyConnection.java:425) ~[HikariCP-3.2.0.jar!/:na]
at com.zaxxer.hikari.pool.HikariProxyConnection.setNetworkTimeout(HikariProxyConnection.java) [HikariCP-3.2.0.jar!/:na]
at com.zaxxer.hikari.pool.PoolBase.setNetworkTimeout(PoolBase.java:550) [HikariCP-3.2.0.jar!/:na]
I am able to resolve this issue, but just evicting the connection and then closing the connection, but does this cause other problems if i do this ?

"HikariCP-3.2.0.jar!"  This is an absurdly old version of the pool.  Upgrade.


Document recent addition to allow arbitrary beans to be added to catalog and used in config, initializers, and elsewhere

Thanks!  Fixed and merged.


multiclass_logreg

Implement multiclass log regression by @yangkevin2, @ruiqi-zhong and @sIncerass.

To fix Travis failure, try adding scikit-learn at a specific version or version bounds (e.g. scikit-learn==0.23.2) as a dependency to the test_requirements list in setup.py.

I can take over this PR. If you prefer, I can work with you on it if you give me push permissions to your fork/branch.


Proposal: Support Kafka Streams Topology customizer

The streams Topology is current in a limited scope, there are use cases where the user might want to customize it, by adding processors that influence GlobalKTables which is my case.
I think it can possibly assist on use cases like https://github.com/spring-projects/spring-kafka/issues/1236
Please let me know if it's a valid idea so I can proceed with documentation and more tests, the current test is very simple and actually doesn't represent the power of the Topology customization, but it's the fastest functional example I can write while the idea is evaluated!
I'm glad to hear your thoughts, thanks you!

@renatomefi Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.

@renatomefi We'd be happy to take a look, but we're not allowed to even look at your code until you sign the CLA. Thanks.

@renatomefi Thank you for signing the Contributor License Agreement!

@garyrussell could you please check then? thank you!

2.4 will be released soon; the 2.4.0 clients are not binary compatible with code compiled against the 2.3.0 clients, so 2.4. will be (mostly) functionally the same as 2.3.
The 2.4 clients are currently scheduled to be released 11/15; I have scheduled 2.4 RC1 for 11/22.

@garyrussell based on my question
https://stackoverflow.com/questions/59689821/adds-a-state-store-to-the-underlying-topology-before-streamsbuilder-started
Is there a plan for this PR to continue?

@renatomefi Thanks for the contribution!
Closed in favor of https://github.com/spring-projects/spring-kafka/pull/1350
Also see https://stackoverflow.com/questions/59689821/adds-a-state-store-to-the-underlying-topology-before-streamsbuilder-started/59690035#59690035


Syntax highlighting issues

I recently converted the C Improved language into YAML using AAAPackageDev and found out some highlighting issues.
I'm reporting this because you mentioned you can't fix what you don't know.
And thanks for an amazing tool, buddy!

Thanks for the report. Next time, please paste the breaking code into the bug report so we can reproduce more easily (for this issue I'll manually convert https://github.com/abusalimov/SublimeCImproved/blob/master/C Improved.tmLanguage).

I fixed one half of the issue above.
The other half of the issue is that this pattern gets converted into a double-quoted scalar in YAML which uses escape mechanisms that the regex doesn't cover (and would be hard to do so). Basically "\\(" is equivalent to \(, but because the \\ is consumed by the string to be turned into a single literal backslash, the following opening parentheses is matched as a group, even though it is not.
Instead, I will tweak the importing (mainly rearranging) command to dedent leading spaces like the tabs in the example, which I expect to be causing the use of a double-quoted scalar by the dumper.

Unfortunately the C Improved syntax definition contained a lot of mixed spaces indentation and YAML doesn't play well with tabs after newlines in block scalars, which is what caused the bad conversion.
The proper workflow is as follows:

Open C Improved.tmLanguage in ST
Convert indentation to spaces (using Indentation: Convert to Spaces command)
Run AAAPackageDev: Convert to YAML and Rearrange Syntax Definition

I also added this in to readme, notably the indentation conversion.


Cannot pass constant to lax.fori_loop body inside pallas kernel

Description
Hi,
I have a basic reproduction of an issue I've been facing where I cannot pass a constant inside of a fori_loop in a pallas kernel on jax nightly:
import jax
from jax import numpy as jnp
from jax.experimental import pallas as pl
from jax import lax
import functools

def kernel_func(A_ref, out_ref, scale: float, blocks: int, N: int):
    accum = jnp.zeros((N, N), dtype=jnp.float32)
    def body(idx, accum):
        tile = pl.load(A_ref, (idx, pl.dslice(None), pl.dslice(None)))
        accum += tile * scale
        return accum

    out_tile = lax.fori_loop(0, blocks, body, accum)
    pl.store(out_ref, (pl.dslice(None), pl.dslice(None)), out_tile)

@jax.jit
def f(A, scale):
    blocks, N, _ = A.shape
    grid = (1, 1)
    in_specs = [ pl.BlockSpec(lambda r, c: (0, 0, 0), (blocks, N, N)) ]

    kernel = functools.partial(kernel_func, scale=scale, blocks=blocks, N=N)
    out = pl.pallas_call(
        kernel, grid=grid, in_specs=in_specs,
        out_shape=jax.ShapeDtypeStruct((N, N), A.dtype),
        name="f"
    )(A)
    return out

N = 64
A = jax.random.uniform(jax.random.PRNGKey(0), (5, N, N), dtype=jnp.float32)

C = f(A, 1.1)
print(C)

yields
jax.errors.SimplifiedTraceback: For simplicity, JAX has removed its internal frames from the traceback of the following exception. Set JAX_TRACEBACK_FILTERING=off to include these.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/mnt/xfs/home/engstrom/src/backward-backward/issue.py", line 34, in <module>
    C = f(A, 1.1)
  File "/mnt/xfs/home/engstrom/src/backward-backward/issue.py", line 24, in f
    out = pl.pallas_call(
  File "/mnt/xfs/home/engstrom/conda_envs/ajax/lib/python3.10/site-packages/jax/_src/pallas/pallas_call.py", line 1359, in wrapped
    jaxpr = _trace_kernel_to_jaxpr(
  File "/mnt/xfs/home/engstrom/conda_envs/ajax/lib/python3.10/site-packages/jax/_src/pallas/pallas_call.py", line 1123, in _trace_kernel_to_jaxpr
    raise ValueError(
ValueError: The kernel function in the pallas_call kernel_func at /mnt/xfs/home/engstrom/src/backward-backward/issue.py:7 captures constants [ShapedArray(float32[], weak_type=True)]. You should pass them as inputs

I am not sure what it means to pass these as inputs, it feels like bad practice to pass these values through the carry if they are just constants. Is there a different way of doing this, or is this a bug?
System info (python version, jaxlib version, accelerator, etc.)
Python 3.10.14 (main, Mar 21 2024, 16:24:04) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import jax; jax.print_environment_info()

jax:    0.4.32.dev20240827
jaxlib: 0.4.31
numpy:  1.26.4
python: 3.10.14 (main, Mar 21 2024, 16:24:04) [GCC 11.2.0]
jax.devices (1 total, 1 local): [CudaDevice(id=0)]
process_count: 1
platform: uname_result(system='Linux', node='deep-chungus-10.csail.mit.edu', release='5.15.0-113-generic', version='#123-Ubuntu SMP Mon Jun 10 08:16:17 UTC 2024', machine='x86_64')

$ nvidia-smi
Wed Aug 28 15:35:43 2024
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.15              Driver Version: 550.54.15      CUDA Version: 12.4     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA A100 80GB PCIe          On  |   00000000:01:00.0 Off |                    0 |
| N/A   41C    P0             65W /  300W |     425MiB /  81920MiB |      2%      Default |

You need to make scale a static argument to f. e.g.
@functools.partial(jax.jit, static_argnames=['scale'])
def f(A, scale):
  ...

Otherwise, it is not actually being interpreted as a constant by JAX since the function does not know what value scale will be during jit compilation.


Unclear approach for integrating Dishka with Strawberry GraphQL

Context
I'm trying to integrate Dishka with Strawberry GraphQL in a FastAPI application. The main challenge is injecting dependencies into GraphQL resolvers while maintaining compatibility with Strawberry's type system.
Working Solution
What ended up working was modifying how we pass the container to the GraphQL context:
async def get_context(request: Request) -> GraphQLContext:
    return GraphQLContext(request=request, container=request.state.dishka_container)

graphql_app = GraphQLRouter(schema, context_getter=get_context)

POC Available
To make it easier to get started with Strawberry, I put together a small POC.
Questions

Is accessing the container through request.state.dishka_container the recommended approach for integrating Dishka with Strawberry GraphQL?
Are there any potential issues or drawbacks with this method that we should be aware of?
Is there a more idiomatic way to integrate Dishka with Strawberry GraphQL that we might have overlooked?
Could the documentation be updated to include a specific section on integrating Dishka with GraphQL libraries like Strawberry?

Any guidance or best practices for this integration would be greatly appreciated.
Thank you for your time and for creating this wonderful library!

Usage of request.state.dishka_container in fastapi application is a proper way to access to container outside of fastapi handlers. inject decorator uses it as well. Writing your own version of such decorator is up to you.
I am not sure what to add, except maybe details about fastapi and other existing integrations details

@Tishka17 Thank you for your quick response.
I discovered this solution by examining the setup_dishka code, as I couldn't find it in the documentation. I want to ensure that using request.state.dishka_container is the correct approach and not an internal detail we shouldn't rely on.
Two key requests:

Could you please add this approach to the official documentation, especially for integrating Dishka with GraphQL libraries like Strawberry?

Could you please review the simple POC and confirm if this implementation (using request.state.dishka_container) is the correct, long-term supported approach?

Your clarification on these points would be greatly appreciated. Thank you for your valuable work on this library.

Approach depends on framework you are using. For fastapi container is stored inrequest.state. it is not planned to change unless fastapi breaks something
I'll review poc later.

Your POC looks valid for me. I don't think you need components here (it is primarily needed for isolation of providers), but it is still ok if you want to set them

The proof of concept (POC) I shared is a simplified example demonstrating request.state.dishka_container in action, alongside Strawberry. In my actual project, which follows the same principles (including the use of components), I've observed some notable performance improvements. Some observations:

There's a minor delay (a few milliseconds) on each request for resolving dependencies.
Importantly, this doesn't negatively impact the overall requests per second.
For concurrent requests, the library appears to manage resources more efficiently, even reducing latency in some cases.

I'll admit that I don't fully understand the underlying mechanisms of this library, but its effectiveness is undeniable. It's arguably the most impressive library I've encountered recently.
The most significant advantage is that it allows me to focus on developing rather than struggling with dependency management.
Thank you for your valuable contribution to this project. I wish you continued success in your development efforts!

@Tishka17 I closed the issue for now. If you feel you could add a section on documentation  or an example about FastAPI + Strawberry, that would be really great.
Last, I would like to ask two questions please, about my case of using strawberry + FastAPI:

Do I need to use router = APIRouter(route_class=DishkaRoute) ?
Are there any other good practises I should follow / be aware of?

Thank you once again 🙏


Merge Tree: Rationalize registers

Related microsoft/Prague#1381
I'm not sure we want to keep registers. They are currently not used heavily, are not snapshotted,  never clean-up, and not tested well.
If we keep them merge tree should add a new op for copying text to a register, and we should remove the register property from remove op, cut then becomes a group op of copy, and remove.
It's probably ok to keep the register on insert for paste.

This issue is 2 years old. Closing. @anthony-murphy - if we need some cleanup due to not supporting registers right now, please open separate issue,


[Bug] Studio Link property creation "linked class" select not enabled

Small OrienDB Studio bug:

It can still be changed on the properties table.
Tested in 1.6.4 and 1.7RC1

Fixed long time ago
Closing
Thanks
Luigi


Wrong information about maximal length of option string

I think the statement about the maximum length (250) of the option string is not up to date.
I just created an option field with 40 option members with length 10 each option (Option0000,Option0001,...Option0039) and also captions for ENU and translations in the xlif with 40 characters each ==> No problems with compiling and no problems in the client.
==> Could you please check and correct the statement about the maximum length.

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

ID: 60d64a53-4e2a-6eb3-e9b0-618160a01b3c
Version Independent ID: 0a941f99-ef01-4570-de2f-45a927ddc792
Content: OptionString Property - Business Central
Content Source: dev-itpro/developer/properties/devenv-optionstring-property.md
Service: dynamics365-business-central
GitHub Login: @SusanneWindfeldPedersen
Microsoft Alias: solsen

Thanks for the feedback. This issue has been resolved.


Update build.gradle

Oh. I was about to merge #7 when you closed it. Was wondering why. This is a lot better. Thanks!
I see that you updated support library version too. Still building? Oh well, we can just fix that later.
Thanks again for the contribution. Have a nice day!

In that pull request (https://github.com/xiprox/ErrorView/pull/7) I didn't notice that I was using an incorrect e-mail (I saw it using the "git log" command). And, how did you say, I also noticed that I could update the support library version, therefore, I think better and I decided to close it.
Yes, I'm building and there is new PR possibilities coming soon.
Thanks @xiprox! Have a nice day too! :)


README: add git as required package

Hi, just adding git as required package since tests are failing without it:
failures:
    aaa_trigger_cross_compile_disabled_check
    git::use_the_cli
    new::author_prefers_cargo
    new::finds_author_git
    new::finds_local_author_git

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nrc (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.


Doesn't show SVG with any of the 3 methods

Using:

iOS / emulator and device / iPhone 7+ or iPhone 12 / iOS 14.4

tns --version
nativescript has 7.2.0
@nativescript/core has 7.3.0
@nativescript/ios has 7.2.0
@nativescript/android has 7.0.1
I don't use nothing special in my app, in fact, I've made it load a blank component without any additional plugins just to see if it would make any difference but it didn't.
The result is that I don't see any SVG image. I don't get any errors it is just blank where an SVG image should be.

@butaminas maybe it would be best to share a sample code, don't you think ? ;)

@butaminas maybe it would be best to share a sample code, don't you think ? ;)

OK. Fair enough.
ns create HelloWorld --template @nativescript/template-blank-vue
Doesn't work with the default blank template.

@farfromrefug I think I figured out where the issue is.
I have my SVG at /app/images/image.svg and when I try to link it in the <Image src='~/images/image.svg' /> tag it doesn't work. But if I change the structure like in the docs and have the image in /app/assets/svgs/image/svg/image.svg and then link it like so <Image src='~/assets/svgs/image.svg' /> then it works.
Is there any particular reason why it has to be under assets/svgs if not, is there any way to change the directory?

you issue is not with this plugin but with your path. must be ~/assets/...

how can I use this library to get SVG from a URL?

Hey.. were you able to figure it out?

how can I use this library to get SVG from a URL?
i want something like this: <SVGView height="30%" src="url"><SVGView>

Hey.. were you able to figure it out?


Adding request trial interface

Summary
Adding request trial interface
Ticket Link
MM-25341
Related Pull Requests

Has server changes mattermost/mattermost-server#14603

Screenshots

/update-branch


lrange performance problem

CPU: 16C
MEM: 16G
test server process inside docker, both garnet and redis use one single process node
gartner built with release conf
use redis-benchmark for testing
garnet
PING_INLINE: 37230.08 requests per second, p50=0.743 msec
PING_MBULK: 36576.45 requests per second, p50=0.759 msec
SET: 36376.86 requests per second, p50=0.759 msec
GET: 35676.06 requests per second, p50=0.767 msec
INCR: 35855.14 requests per second, p50=0.759 msec
LPUSH: 36258.16 requests per second, p50=0.767 msec
RPUSH: 36697.25 requests per second, p50=0.759 msec
LPOP: 36616.62 requests per second, p50=0.759 msec
RPOP: 37091.99 requests per second, p50=0.759 msec
SADD: 36536.36 requests per second, p50=0.759 msec
HSET: 35625.22 requests per second, p50=0.783 msec
SPOP: 36443.15 requests per second, p50=0.767 msec
ZADD: 36805.30 requests per second, p50=0.751 msec
ZPOPMIN: 35893.75 requests per second, p50=0.759 msec
LPUSH (needed to benchmark LRANGE): 36536.36 requests per second, p50=0.759 msec
LRANGE_100 (first 100 elements): 14766.69 requests per second, p50=2.783 msec
LRANGE_300 (first 300 elements): 2128.43 requests per second, p50=18.831 msec
LRANGE_500 (first 500 elements): 801.81 requests per second, p50=47.871 msec
LRANGE_600 (first 600 elements): 587.45 requests per second, p50=64.447 msec
MSET (10 keys): 30413.62 requests per second, p50=0.919 msec

CPU 400%
lrange use full cpu, memory 25%
redis
PING_INLINE: 34855.35 requests per second, p50=0.815 msec
PING_MBULK: 36995.93 requests per second, p50=0.783 msec
SET: 36536.36 requests per second, p50=0.799 msec
GET: 35625.22 requests per second, p50=0.807 msec
INCR: 35298.27 requests per second, p50=0.807 msec
LPUSH: 36075.04 requests per second, p50=0.807 msec
RPUSH: 35536.61 requests per second, p50=0.799 msec
LPOP: 36995.93 requests per second, p50=0.799 msec
RPOP: 35701.54 requests per second, p50=0.815 msec
SADD: 35161.74 requests per second, p50=0.831 msec
HSET: 36166.36 requests per second, p50=0.799 msec
SPOP: 36036.04 requests per second, p50=0.791 msec
ZADD: 36231.88 requests per second, p50=0.799 msec
ZPOPMIN: 36697.25 requests per second, p50=0.783 msec
LPUSH (needed to benchmark LRANGE): 36376.86 requests per second, p50=0.823 msec
LRANGE_100 (first 100 elements): 26116.48 requests per second, p50=1.055 msec
LRANGE_300 (first 300 elements): 15363.34 requests per second, p50=1.727 msec
LRANGE_500 (first 500 elements): 11440.34 requests per second, p50=2.279 msec
LRANGE_600 (first 600 elements): 9536.52 requests per second, p50=2.655 msec
MSET (10 keys): 36258.16 requests per second, p50=0.839 msec

CPU 350%
lrange cpu 100%, memory 0.1% in all scene
### Tasks

https://github.com/microsoft/garnet/blob/484c576b9734ea8c2604d945418d1f4c7125c2c9/libs/server/Objects/List/ListObjectImpl.cs#L190-L194
feel like there's something can do here. 👻

Yes, repeatedly using ElementAt is a poor implementation. It should go to the first element and iterate from there. Anyone care to PR a fix?

Yes, repeatedly using ElementAt is a poor implementation with quadratic overhead. It should go to the first element and iterate from there. Anyone care to PR a fix?

have tried
foreach (var bytes in list)
{
    while (!RespWriteUtils.WriteBulkString(bytes, ref curr, end))
        ObjectUtils.ReallocateOutput(ref output, ref isMemory, ref ptr, ref ptrHandle, ref curr, ref end);
}

but still the same.
flame graph shows the same hotspot as before

you need to seek to the start, then traverse until the required number of elements (e.g., 100, 200, etc.)

the list here is for all.

What perf do you see with the fixed code?

What perf do you see with the fixed code?

var i = 0;
foreach (var bytes in list)
{
    if (i < start)
        continue;
    if (i > stop)
        break;
    while (!RespWriteUtils.WriteBulkString(bytes, ref curr, end))
        ObjectUtils.ReallocateOutput(ref output, ref isMemory, ref ptr, ref ptrHandle, ref curr, ref end);
    i++;
}

seems ok
LPUSH (needed to benchmark LRANGE): 36036.04 requests per second, p50=0.759 msec
LRANGE_100 (first 100 elements): 26961.44 requests per second, p50=0.991 msec
LRANGE_300 (first 300 elements): 15728.22 requests per second, p50=1.631 msec
LRANGE_500 (first 500 elements): 11376.56 requests per second, p50=2.223 msec
LRANGE_600 (first 600 elements): 9981.04 requests per second, p50=2.535 msec

the list here is for all.

didn't skip the first n elements, I have submitted another pr #220

I run the test and passed it. 👻
Missing some test cases.
Yes, that's not an implementation of LRANGE.


User can explore and edit gene sets on desktop

User Story: As an eBio, I often want to explore the expression of groups of related genes instead of individual genes to better understand biological processes and identify cell types.
Requirements:
Loading a gene set

Desktop users can load a csv containing gene sets from the command line
Gene set conforms to gene set data format #1860
Gene set names are strings that follow the same conventions as category names.
Gene lists are non-redundant, non-mutually exclusive, and contain only features from var, see #1609 for more info
Users are warned in the UI when gene(s) do not import (are not included in the dataset)

Interacting with a gene set

By default, gene sets are collapsed in the RSB and show a histogram of the mean expression
The order genes are shown in in the UI reflects the order in the input file
Users can color cells by average expression of a gene set
Users can plot a gene set by x or y.
Users can brush over the gene set to select a range of expression values
Users can expand a gene set to see the individual genes
On an expansion of an individual gene, a user sees a large histogram with axes, and brush to select range

Notes:

For this epic, the "Autosuggest genes", "Bulk add genes" and "Add Gene" functionality will remain at the top of the RSB. Individual genes added will precede gene sets in the RSB

@colinmegill can you add instructions for the gene sets prototype to this epic? And links to figma as applicable. This will help dev know what the designs are and @ambrosejcarr demo as necessary.

Instructions on use of gene sets prototype:
git checkout colinmegill/geneset-prototype
make start-server CXG_OPTIONS="--experimental-annotations-ontology --experimental-enable-reembedding --debug --genesets-file ./data/krasnow-genesets.csv" DATASET=./data/krasnow_lab_human_lung_cell_atlas_smartseq2-2-remixed.h5ad
make start-frontend

Closing in favor of https://app.zenhub.com/workspaces/cellxgene-explorer-600f112266e8830017f47e12/issues/chanzuckerberg/cellxgene/2041


Fix browser build

This PR will:

Add a build for browsers to include with import OrbitDB from 'orbit-db'
Add a webpack config file to build ^ without leveldown (LevelDB)
Set package.json's browser field to dist/orbit.js built with ^
Clean up webpack config files and remove all obsolete settings
Pull in a fix from orbit-db-cache

Closes #280
Closes #285

Will merge this soon, update the changelog and release as 0.19.0 before midnight today :)

Thanks! Still travelling, but will try as soon as I come back home :)


load staff via csv

w : Even better (since we have this data): have course staff automatically added to the course based on their LDAP/Shib membership in the course staff group.

There should be a blue "Manage staff" button on the course page - do you not see that? It'll only show up if you're an admin or already on course staff for that course.


CalTRACK Issue: Heating balance point temperatures abnormally low?

Prerequisites

[x] Are you opening this issue in the correct repository (caltrack/grid/seat)?
[x] Did you perform a search of previous Github issues to check if this issue has been previously considered?

Article reference number in CalTRACK documentation (optional): 3.2
(Also: see original issue #95, closed during CalTRACK transition from OEE to EM2, and Appendix <IP_ADDRESS>)
Description
Background: Each building has a specific balance point temperature, an outdoor temperature at which heating or cooling loads engage. Getting this right is critical, due to the non-linear nature of degree days and the importance of accurate heating and cooling coefficients in any building model. This type of model error is indicated in the chart below as type 3: the balance point selected is not accurate for the building.

CalTRACK uses an industry-standard “best R-squared” approach to determine the best balance point temperature for each building. We believe there is a better approach for residential buildings.
Issue:  During HEA's first residential EE programs (in 2011) we used the industry standard approach. But our building energy experts and a number of energy-savvy homeowners recognized that our HVAC load analysis was inaccurate in many homes, and by investigating individual buildings (via submetering and other ground truth sources) we determined the inaccuracy was caused by low balance point temperature selection (in the case of heating). We attributed the inaccuracy of this method to two issues:

The method is based on the assumption that energy consumption depends linearly on HDDs and/or CDDs. When this occurs the correct balance point temperature linear model will have best R-squared value compared to other linear models. However in HEA’s experience since then (now over 10,000 residential buildings analyzed & vetted by owners and energy coaches) we have seen that pure linear dependencies between energy and weather are quite rare in homes: many homes are "bad buildings". As a result, at least in residential buildings, we believe the best R-squared value does not indicate the correct balance temperature.

In the case of heating, the number of non-zero HDD data points decreases as the balance temperature decreases (the same is true for cooling, but in the opposite direction). We suspect -- but have not tested -- that fewer data points may result in better R-squared values. (Clearly, in the extreme case of a very low balance point temperature the R-squared value would become 1.0 with only two data points.) If this hypothesis is true, the R-squared approach to balance point selection will systemically select lower balance temperatures.

After discovering these inaccuracies, we switched to a different approach we believe is superior: our base temperature algorithm utilizes an analysis of Average Temperature vs. Average Energy Use curves, where we identify the HVAC-engagement inflection point.
Below are charts for two homes showing average temp vs electric use:

And here are the corresponding charts for the same two homes showing average temp vs average electric use:

With these last two charts in mind, we'll describe our Cooling Base Temperature algorithm. (Heating works in a similar fashion.)
The algorithm analyzes each AvgTemp point between Min_CDD_Temp and Max_CDD_Temp (currently we use 65F and 90F respectively) and builds two trend lines. The first line crosses two points: the leftmost point of the curve (presumably the lowest temperature and lowest cooling energy use) and the temperature point currently being analyzed. The second line also crosses two points: the currently analyzed temperature point and the rightmost point of the curve (presumably the highest temperature and highest energy use). The algorithm calculates the ratio of the angle coefficients for both lines. Across all temperature points, we identify the temperature where the ratio is maximized. Simply speaking the algorithm attempts to identify the temperature point where the energy use becomes temperature-dependent.
This method is also not ideal, because some homes do not have clearly identifiable inflection points. But HEA has used it for many years and in most cases we (meaning our energy coaches and homeowner-customers) are satisfied with the results. We believe it is significantly better than the R-squared approach.
Validation: Across a cohort of 84 homes in PG&E territory, CalTRACK’s average heating balance point temperature was 59.9F for electricity and 60.95F for natural gas. These figures are abnormally low, and significantly lower than the results of the algorithm described above when run on the same homes (within HEA).
If these balance point temperatures are incorrect the CalTRACK analysis will utilize too few HDDs and underreport weather-dependent loads. This will cause inaccurate savings calculations across all buildings analyzed, which will vary significantly based on weather conditions in the reporting period compared to the baseline period: hotter temperatures in the reporting period will produce one type of inaccuracy, and cooler temps the opposite. The same direction of error will occur for all buildings analyzed during that period, systemically.
Requested CalTRACK changes:

Investigate alternative methods to balance point temperature selection such as the one described above; and
Identify a method to test the accuracy of balance point temperature selections, such as those described in Issue #73. One possibility is the use of CBECC-Res data, where energy data can be generated for a variety of "virtual home" test cases, with any desired balance temperature, infiltration rate, etc.

Proposed test methodology
[I could use some help here...]

Run current methods on a large sample of homes and record "before" balance point temperature values. What is the average? What are the CVRMSE values?
Adjust the method to calculate balance points as suggested above.
Rerun with the updated method, and compare "after" balance points, and CVRMSE values.

Acceptance Criteria
Balance point averages should improve (closer to industry norms) and CVRMSE values should improve in most cases, and never get worse.

Clarifying question: are you proposing averaging temperatures over calendar months or over billing periods, or in some other way?

In the charts above we are using average daily temperatures, together with the associated daily energy use.

Thanks for clarifying. So you are charting average daily temperatures vs average daily energy use in the charts labeled "Avg Temp vs Avg Electric Use". It didn't look to me like there were 365 points, so I assumed it was a longer period you were averaging over, but it may just be a trick of the chart plotting, or maybe the model wasn't built on a full year of data.
What are you charting in the charts labeled "Avg Temp vs Electric Use"? Are those hourly or sub-hourly energy use data, then? If so, are the temperature values in those charts also averaged over the hourly/sub-hourly energy use periods, or are those also daily average values?

Sorry for not being more clear:
"Avg Temp vs Electric Use" has (at least) 365 points of daily data.
"Avg Temp vs Avg Electric Use" displays only the average daily energy use for each temperature.

@danrubado Agreed -- not sure how much it would help with monthly data. We have only applied it to daily data.


Update AltStore source

Permissions and stuff https://faq.altstore.io/sources/make-a-source#app-permissions

Done


Error instilling node

Been at this for hours but to no avail
Trying to run vagrant provision to install node and nam using your latest repo on Yosemite but keep getting

==> default: Now using node v6.3.1 (npm v3.10.3)
==> default: Creating default alias: default -> node (-> v6.3.1)
==> default: default -> node (-> v6.3.1)
==> default: Now using node v6.3.1 (npm v3.10.3)
==> default: npm
==> default:
==> default: WARN
==> default:
==> default: optional
==> default:  Skipping failed optional dependency /pm2/chokidar/fsevents:
==> default: npm
==> default:
==> default: WARN
==> default:
==> default: notsup
==> default:  Not compatible with your operating system or architecture<EMAIL_ADDRESS>==> default: npm
==> default:
==> default: ERR!
==> default:  Linux 3.13.0-93-generic
==> default: npm
==> default:
==> default: ERR!
==> default:
==> default: argv
==> default:  "/home/vagrant/.nvm/versions/node/v6.3.1/bin/node" "/home/vagrant/.nvm/versions/node/v6.3.1/bin/npm" "install" "-g" "npm" "pm2"
==> default: npm
==> default:
==> default: ERR!
==> default:
==> default: node
==> default:  v6.3.1
==> default: npm
==> default:
==> default: ERR!
==> default:
==> default: npm
==> default:  v3.10.3
==> default: npm
==> default:
==> default: ERR!
==> default:
==> default: file
==> default:  /home/vagrant/.npm/kind-of/3.0.4/package/package.json
==> default: npm
==> default:
==> default: ERR!
==> default:  code EJSONPARSE
==> default:
==> default: npm ERR! Failed to parse json
==> default: npm ERR!
==> default:  No data, empty input at 1:1
==> default: npm
==> default:
==> default: ERR!
==> default:
==> default: npm
==> default:
==> default: ERR!
==> default:  ^
==> default: npm
==> default:
==> default: ERR!
==> default:  File: /home/vagrant/.npm/kind-of/3.0.4/package/package.json
==> default: npm
==> default:
==> default: ERR!
==> default:  Failed to parse package.json data.
==> default: npm
==> default:
==> default: ERR!
==> default:  package.json must be actual JSON, not just JavaScript.
==> default: npm
==> default:
==> default: ERR!
==> default:
==> default: npm
==> default:
==> default: ERR!
==> default:  This is not a bug in npm.
==> default: npm
==> default:
==> default: ERR!
==> default:  Tell the package author to fix their package.json file. JSON.parse
==> default: npm
==> default:
==> default: ERR!
==> default:  Please include the following file with any support request:
==> default: npm
==> default:
==> default: ERR!
==> default:      /home/vagrant/npm-debug.log
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.

not sure what it means at the moment.

It sounds to me like your package.json (or at least the one in that package) has an error or a typo. This is not an issue with Vagrant or this project.

I'm not even sure anymore.... I had successfully used an older version of your box and it worked with just node but didn't with php....I upgraded and now it works with php/ composer but not with node/ npm.... I gave up trying.

I'm guessing the reason it wasn't working with node was due to you having your args_npm_install_dir set to /vagrant instead of /home/vagrant/app as you had set for the other configurations. I replied in #29 with a new Vagrantfile that I hope works for you to solve all of these issues.

Closing to consolidate issues. This is likely another side effect of #29. Feel free to re-open if this is not the case.


Fix typo 'matro' -> 'metro' in asset documentation

The title speaks for itself ;)

Yeah, I did yesterday but maybe with the wrong email address? I will try again.

Try closing and re-opening PR.

Yeah there is a :heavy_check_mark: now :)

@hiddewie Thank you for your contribution to webpack.


Add support for TIME_STYLE environment variable

This PR adds support for parsing the date/time format from the TIME_STYLE environment variable as requested in #450.
For full GNU ls compatibility, an upgrade of time to version 0.2 is required as the currently used version 0.1.44 doesn't support nanosecond output as format string (placeholder %N).
The date option in the default configuration has been commented out to allow the environment to specify a date/time format. As DateFlag itself defaults to DateFlag::Date, this does not change default behaviour.
Changes to Configurable<T> allow other or future flags to be specified from the environment as well. The trait method from_environment has a default implementation for minimal change throughout the code.
EDIT: For some reason, the tests fail sometimes, even without recompiling. Probably because cargo's test harness runs multithreaded, but environment variables are modified process-wide. Using std::env::vars(), passing the iterator to every call to Configurable::from_environment and iterating through all environment variables would fix this issue, but this would be a performance hit as every call would require a new iterator to be created.

TODO

[X] Use cargo fmt
[X] Add necessary tests
[X] Add changelog entry

Codecov Report

Merging #471 (3f6a019) into master (5b2dbca) will increase coverage by 0.02%.
The diff coverage is 85.18%.

@@            Coverage Diff             @@
##           master     #471      +/-   ##
==========================================
+ Coverage   83.90%   83.92%   +0.02%
==========================================
  Files          35       35
  Lines        3300     3329      +29
==========================================
+ Hits         2769     2794      +25
- Misses        531      535       +4

Impacted Files
Coverage Δ

src/main.rs
0.00% <ø> (ø)

src/app.rs
95.91% <75.00%> (ø)

src/flags.rs
85.71% <75.00%> (-1.79%)
:arrow_down:

src/flags/date.rs
88.59% <82.75%> (-2.00%)
:arrow_down:

src/meta/date.rs
94.11% <93.75%> (+0.85%)
:arrow_up:

src/config_file.rs
81.25% <100.00%> (ø)

src/flags/blocks.rs
93.36% <0.00%> (+0.44%)
:arrow_up:

Continue to review full report at Codecov.

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

Codecov Report

Merging #471 (3f6a019) into master (5b2dbca) will increase coverage by 0.02%.
The diff coverage is 85.18%.

@@            Coverage Diff             @@
##           master     #471      +/-   ##
==========================================
+ Coverage   83.90%   83.92%   +0.02%
==========================================
  Files          35       35
  Lines        3300     3329      +29
==========================================
+ Hits         2769     2794      +25
- Misses        531      535       +4

Impacted Files
Coverage Δ

src/main.rs
0.00% <ø> (ø)

src/app.rs
95.91% <75.00%> (ø)

src/flags.rs
85.71% <75.00%> (-1.79%)
:arrow_down:

src/flags/date.rs
88.59% <82.75%> (-2.00%)
:arrow_down:

src/meta/date.rs
94.11% <93.75%> (+0.85%)
:arrow_up:

src/config_file.rs
81.25% <100.00%> (ø)

src/flags/blocks.rs
93.36% <0.00%> (+0.44%)
:arrow_up:

Continue to review full report at Codecov.

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

I've changed the things you mentioned. Tests now run using serial-test, flags are now parsed in the order arg -> env -> config and return early and the time is now stored using chrono instead of time. I've also added my GitHub name to the changelog.

I've changed the things you mentioned. Tests now run using serial-test, flags are now parsed in the order arg -> env -> config and return early and the time is now stored using chrono instead of time. I've also added my GitHub name to the changelog.

The two failing checks in the last CICD build are two Windows builds that somehow failed to download the Rust toolchain. Can you please re-run the checks?

The two failing checks in the last CICD build are two Windows builds that somehow failed to download the Rust toolchain. Can you please re-run the checks?

Awesome, thanks!

Awesome, thanks!


RuntimeError: Binder exception: Variable __existence already exists.

Hi, above error can be reproduced by following snippet:
import kuzu
from uuid import uuid4
import tempfile

with tempfile.TemporaryDirectory() as dbpath:
    conn = kuzu.Connection(kuzu.Database(dbpath))
    conn.execute(
        """
        CREATE NODE TABLE T (id UUID, PRIMARY KEY(id));
        CREATE NODE TABLE U (id UUID, name STRING, PRIMARY KEY(id));
        CREATE REL TABLE has (FROM T TO U);
        """,
    )
    # Prerequirement: existing :T
    tid = uuid4()
    conn.execute("CREATE (t:T {id: $id}) RETURN t;", {"id": tid})

    # Merge :U from memory (new here, but might already exist)
    uid = uuid4()
    conn.execute(
        """
        MATCH (t:T {id: $tid}) // (1)
        MERGE (u:U {id: $uid}) // (2)
        SET u.name = $name     // (3)
        MERGE (t)-[e:has]->(u)
        RETURN t,u,e;
        """,
        {"tid": tid, "uid": uid, "name": "foo"},
    )

Some background for clarification:
Goal was to construct a simple kind of object graph mapper (OGM) with MERGE: Given entities T,U with composite relation (:T)-[:has]->(:U), try to merge a new or existing U from memory.
(1) ensures :T exists
(2) merges an :U by its identifier (otherwise MERGE would try to create a new entity, if any property has changed)
(3) update all :U properties in database (assuming object memory has most recent version or creates new entity)
Kuzu 0.4.2

Hi @sapalli2989,
I can confirm this is bug on our side and working on it. Meanwhile, I wonder if the following workaround works for u?
# Create :T
tid = uuid4()
conn.execute(
"""
CREATE (t:T {id: $tid}) RETURN t;
""", ....)

# Create :U if not exist
uid = uuid4()
conn.execute(
"""
MERGE (u:U {id: $uid})
SET u.name = $name
""", ...)

# Create :has if not exist
conn.execute(
"""
MATCH (t:T {id: $tid}), (u:U {id: $uid})
MERGE (t)-[e:has]->(u)
RETURN t, u, e
""", ...)

Essentially we split merge into multiple statements instead of one.

Great, thanks!

This is now fixed in #4046


Add localization support

We should support EFIGS (English, French, Italian, German, Spanish), Japanese, Chinese and Russian for the UX.

Language icon in the corner which opens a modal containing a select input with different language options.
There should be a note in the current language which explains that Chat is in alpha and only officially supports English at the moment.

Languages available:
English, Russian, Chinese.
Languages left to add:
French, Italian, German, Spanish, Japanese.


CertificateException: Domain specific configurations require that hostname aware checkServerTrusted(X509Certificate[], String, String) is used

Hi,
I'm setting up a minimal Realm Kotlin (Android only) sample but as soon as I call:
app.login(Credentials.anonymous())
I get the following ConnectionException:
[Custom][Unknown(1002)] java.security.cert.CertificateException: Domain specific configurations require that hostname aware checkServerTrusted(X509Certificate[], String, String) is used.
As I just followed the official documentation: Do you have any ideas what's wrong?

We have seen that issue before. That was when running on an older Android emulator, and upgrading to the latest version fixed it.
What device/emulator are you seeing this on?

Unfortunately I'm getting this exception with all my devices (latest emulator version 31.3.7 with Android API 32, Samsung Galaxy S10 with Android 12 and Google Pixel 6 Pro with Android 13)

Hi @sdeff. We have tried different setups with different x86 emulators and two physical devices (Pixel 6 and 3) and couldn't reproduce the error you are seeing. Are you using any specific network settings we should be aware of?

I'm currently using a custom network-security-config for the local build that looks like this:
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config>
        <trust-anchors>
            <certificates src="system" />
            <certificates src="user" />
        </trust-anchors>
    </base-config>
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">localhost</domain>
        <trust-anchors>
            <certificates src="system" />
            <certificates src="user" />
        </trust-anchors>
    </domain-config>
</network-security-config>

When I remove this config, the app.login() call succeeds. Is there any need for a specific config for Realm Sync?

When I remove this config, the app.login() call succeeds. Is there any need for a specific config for Realm Sync?

No, you shouldn't need any specific network configuration to run Sync.
If you still need to have a domain-specific configuration please be aware of the existence of a bug in the Ktor library, which we use internally as our network transport for enabling Sync: https://youtrack.jetbrains.com/issue/KTOR-2243/Android-CIO-client-fail-with-javasecuritycertCertificateException#focus=Comments-27-5915979.0-0

Thanks for that hint!

Will look into a workaround...
Looks like the problem is not on realm's end, I think this can be closed.


Call getUnionOrIntersectionProperty in getAllPossiblePropertiesOfTypes

I noticed this at some point while doing some perf investigation; this was something I thought mattered for my problem but didn't.
Currently, all calls to createUnionOrIntersectionProperty go through getUnionOrIntersectionProperty as the latter has a cache. But getAllPossiblePropertiesOfTypes bypassed this and created the property instead. It's probably advisable to always go through the cache, and probably improves the performance of completions (the only place getAllPossiblePropertiesOfTypes is used). But, I doubt we have a perf test that covers this case specifically.

@typescript-bot perf test this


view.root.sanitizer.sanitize is not a function

check a possible way how to cause this error

v11.11.2 has been released and contains a fix for the issue. Feel free to reopen the issue or to submit a new one if you meet any problems.


Offchain Worker Api should be optional

Currently the Substrate client requires that every runtime implement the Offchain worker runtime Api. Many (maybe even most?) runtimes do not use offchain workers and have to stub this Api like
impl sp_offchain::OffchainWorkerApi<Block> for Runtime {
	fn offchain_worker(_: &Header) {}
}

While it isn't the hardest thing to paste that code into your runtime, it adds an entire dependency on sp_offchain for runtimes that don't otherwise need it.
I suggest the offchain worker api not be required.
cc @kianenigma

Probably has the same answer as https://github.com/paritytech/substrate/issues/11743, so will close to keep our enormous issue backlog at least one less :D


Compilation Failed when starting debug session

My guess is that this is caused by this line in one of my HTTP handlers:
mutationData.query = readAsciiFile("pkg:/mutations/addDevice.gql")

Is there any limitation for reading project files with readAsciiFile? I've searched through Issues and couldn't find anything.
I'm also receiving these errors in VSCode dev tools:
  ERR ENOENT: no such file or directory, open 'extension-output-#4': Error: ENOENT: no such file or directory, open 'extension-output-#4'
log.ts:197   ERR timeout after 1000 ms: Error: timeout after 1000 ms
    at t.RawDebugSession.handleErrorResponse (file:///Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:3184:226)
    at file:///Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:3183:532
    at async t.RawDebugSession.shutdown (file:///Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:3181:536)
log.ts:197   ERR Cannot determine fsPath for uri: file:///Users/dtasevski/Projects/roku/src/components/services/Auth.brs: Error: Cannot determine fsPath for uri: file:///Users/dtasevski/Projects/roku/src/components/services/Auth.brs
    at BrighterScriptPreviewCommand.getSourcePathFromPreviewUri (/Users/dtasevski/.vscode-insiders/extensions/celsoaf.brightscript-2.5.4/dist/commands/BrighterScriptPreviewCommand.js:224:23)
    at /Users/dtasevski/.vscode-insiders/extensions/celsoaf.brightscript-2.5.4/dist/commands/BrighterScriptPreviewCommand.js:57:31
    at l.fire (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:46:222)
    at t.ExtHostEditors.$acceptEditorPropertiesChanged (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:783:833)
    at m._doInvokeHandler (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:816:707)
    at m._invokeHandler (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:816:399)
    at m._receiveRequest (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:815:59)
    at m._receiveOneMessage (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:813:886)
    at /Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:812:34
    at l.fire (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:46:222)
    at v.fire (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:237:381)
    at /Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:1004:179
    at l.fire (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:46:222)
    at v.fire (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:237:381)
    at t.PersistentProtocol._receiveMessage (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:241:921)
    at /Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:238:926
    at l.fire (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:46:222)
    at p.acceptChunk (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:234:851)
    at /Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:234:203
    at Socket.t (/Applications/Visual Studio Code - Insiders.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:243:500)
    at Socket.emit (events.js:223:5)
    at addChunk (_stream_readable.js:309:12)
    at readableAddChunk (_stream_readable.js:290:11)
    at Socket.Readable.push (_stream_readable.js:224:10)
    at Pipe.onStreamRead (internal/stream_base_commons.js:181:23)

I have extension version 2.5.4 installed
VSCode:
Version: 1.48.0-insider
Commit: 8c426f9f3b6b18935cc6c2ec8aa6d45ccd88021e
Date: 2020-07-23T05:40:23.559Z
Electron: 9.1.0
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: <IP_ADDRESS>-electron.0
OS: Darwin x64 19.5.0

Figured that I haven't passed this file's path to bsconfig files property... Closing


Update showCupertinoModalPopup documentation

This PR fixes #106273
Pre-launch Checklist

[x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
[x] I read the [Tree Hygiene] wiki page, which explains my responsibilities.
[x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement].
[x] I signed the [CLA].
[x] I listed at least one issue that this PR fixes in the description above.

Thanks for your contribution!


Allow non-https sites with certain features disabled

HTTPS should be encouraged but can be a hassle.
HTTP should be usable but it will disable things such as payment.

HTTPS is now configurable.
Some code needs to be added to disable payment when HTTPs is turned off.

Payments is a key feature that needs to be disabled if there is no HTTPS

We decided since HTTPS is so easy to enable now - there's no real justification for running Happening without it.
If you need SSL I recommend https://letsencrypt.org or using https://www.cloudflare.com CDN which provides SSL (both free).


Bugs in "String" serialization

index.js serializes 0x7f as \u007f.  This incompatible with ECMAScript 2015 and forward.
index2.js doesn't properly sort a property expressed as "".
I'm BTW working on the same problem and this is what I came up with:
https://github.com/cyberphone/json-canonicalization

Thanks for raising that @cyberphone , would be great if you could reproduce that in a failing test or even contribute a PR with a fix.

Hi @mirkokiefer  Actually it is Crockford's json2 that is incompatible with ECMAScript 2015.
Index2 is almost right but fails on the "" edge case because ECMAScript 2015 has its own sorting rule.
This code does (AFAIK...) canonicalization in a way that is compatible with ECMAScript 2015 edition 6:
// ES6 JSON Canonicalizer
'use strict';
var canonicalize = function(object) {

    var buffer = '';
    serialize(object);
    return buffer;

    function serialize(object) {
        if (object !== null && typeof object === 'object') {
            if (Array.isArray(object)) {
                buffer += '[';
                let next = false;
                object.forEach((element) => {
                    if (next) {
                        buffer += ',';
                    }
                    next = true;
                    serialize(element);
                });
                buffer += ']';
            } else {
                buffer += '{';
                let next = false;
                Object.keys(object).sort().forEach((property) => {
                    if (next) {
                        buffer += ',';
                    }
                    next = true;
                    buffer += JSON.stringify(property);
                    buffer += ':';
                    serialize(object[property]);
                });
                buffer += '}';
            }
        } else {
            buffer += JSON.stringify(object);
        }
    }
};

module.exports = canonicalize;

I'm hoping to make this an IETF standard.


Add latest tx fees to page header price carousel

Is your feature request related to a problem? Please describe.
No existing problem, I just had the idea of displaying the latest fee rate as one of the price carousel options, alongside price, block height, etc. I thought this would be an interesting metric to see since lately the on-chain fees have been pretty high
Describe the solution you'd like
Another option that shows the fee rate for the most recent block. I assume we can get this from SN's node via LND but I have not investigated further.
Describe alternatives you've considered
N/A
Additional context
https://stacker.news/items/315636/r/WeAreAllSatoshi

That'd be fun! They are just so crazy right now

I think this is done, right?

I think this is done, right?

nothing to see here


Update bito-actions.sh - change git_url to pr_url

Summary by Bito
The changes in this PR primarily involve replacing the 'git_url' variable with 'pr_url' in the 'bito-actions.sh' script and the sample properties file. This includes updates to variable assignments, error messages, and echo statements. The modifications ensure that the script now references 'pr_url' instead of 'git_url' throughout.

Code change type: Refactoring, Configuration Changes

Unit tests added: False

Estimated effort to review (1-5, lower is better): 1

Code Review Agent Run Status

Limitations and other issues: ❌ Failure - The AI Code Review Agent skipped reviewing this change because it is configured to exclude certain pull requests based on the source/target branch or the pull request status. You can change the settings here, or contact the agent instance creator at<EMAIL_ADDRESS>

/review

AI Code Review is in progress (usually takes <3 minutes unless it's a very large PR).

AI Code Review is in progress (usually takes <3 minutes unless it's a very large PR).


Feature/GitHub actions

This PR is to add CI/CD scripts to build and push docker hub images with referenced branch name tags using Github Actions and which reduces the build time compared to docker hub auto builds.

This PR is superseded by PR #22


size filter does not support webp image format

Say I use the filter like {{ "/assets/img/test.png" | size: 480 }} then it outputs /assets/img/test-480w.png. But if the file is test.webp it outputs /assets/img/ without the file name.
I think it's because of the following line, but the srcset function has it too, yet it works.
https://github.com/lawmurray/jekyll-responsive-magick/blob/4f809ea4a0629f7ea728bb26629498446397479b/lib/jekyll-responsive-magick.rb#L145

Thanks @d9beuD. Happy to accept a pull request to fix this if you have the time. Probably just a case of adding .webp to the list of acceptable file extensions, as ImageMagick already supports the format I believe.

What do you think about checking the mime type of the file instead of the extension? I don't know Ruby enough to say if it's doable, but:
if File.exist?(src) and File.mime?(src, "image/*)

instead of the line I quoted in my original comment. If you're okay with this idea, assign me to the issue and I'll try my best to make it work.

Nice idea if you can get it working @d9beuD. That should open up support for any image formats that ImageMagick supports. Assigned you the ticket, thanks for the contributions!


[doc] Add User Lab Day slides to documentation

Fixes #503

Codecov Report

Merging #520 into master will decrease coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #520      +/-   ##
==========================================
- Coverage   91.44%   91.42%   -0.03%
==========================================
  Files          72       72
  Lines        8767     8767
==========================================
- Hits         8017     8015       -2
- Misses        750      752       +2

Impacted Files
Coverage Δ

reframe/core/config.py
82.6% <0%> (-1.74%)
:arrow_down:

Continue to review full report at Codecov.

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

@jenkins-cscs retry none


Update MuJoCo to 3.X

A key part missing from recent Metaworld renovation work is to stop depending on MuJoCo 2.X. Upgrading to MuJoCo 3.X opens up useful features such as:

The ability to use MJX in the future
The repository properly installing and working on latest macOS (MuJoCo 2's library path for OpenGL is wrong)

The main reason for not using MuJoCo 3.X before was that the benchmark did not work as intended and appeared to be broken (i.e. tests would fail).
Over the past few months, I did a deep dive on why this is and how to fix it. You can find a relatively in-depth documentation of the process and the findings in this issue on the MuJoCo repo.
In the end I had to make a single change to get it working:

Adjust the mocap weld constraint to have the correct relative position we want between the hand and the mocap bodies (that's what changing 1.0 to -1.0 achieves, which corresponds to the first part of the quaternion in the rotational part of the relpose attribute of the weld constraint), and also to weigh the rotational part of the constraint quite high (set torquescale, the last part of the constraint data, to 3.75 from 1.0)

(For an explanation as to why this change was necessary please see the discussion on the this issue in the MuJoCo repo)
I tried different values for torquecale but found that at 3.5 soccer breaks, and at 3.75 and up everything works.

I initially got it working and visually verified that the arm position looked like MuJoCo 2 using torquescale="5", then before making the PR I tried lower / more conservative values before ending on 3.75 as the minimum value that had tests passing on my machine. Apparently 3.75 and even 4 is still brittle as CI was failing so I suppose let's go with 5.

Does this update break the environments with mujuco<3.0.0
besides, visual validation of the rendered arm, has there been done any other validation, can you collect a trajectory of 1k steps with the old version of metaworld and mujoco and check how it compares with the new version of metaworld and mujoco (with the same action)
Thanks

With regards to validation, I did not run much before opening this pull request as I was requested by another maintainer to open it as soon as possible to run some RL experiments against it and verify that algorithm performance is not impacted.
That said I ran some comparisons today.

The new weld constraints do not seem to break the environments if I downgrade MuJoCo to <3.0.0. The tests still pass. That said I noticed soccer-v2 fail once in my runs with (0.40 / 0.50) success rate (right on the verge of 80% which is the threshold). In general I think that for MuJoCo <3.0.0 the previous weld parameters should be kept.
For validating consistency with the "old version" (old weld parameters + mujoco 2.3.7), I wrote this script to collect a trajectory for 1000 timesteps and a video with random actions. I ran it across 2 environments, one with the new weld parameters + mujoco 3, and one with the old weld parameters + mujoco 2. I then wrote this script to compare the two trajectories and get the mean square error and mean absolute error for their observations and rewards, which I report below for reach-v2. Additionally I'm attaching the two videos in MP4 and Webm. To me they look more or less identical and the actual losses seem very low to me as well.

Observation loss (MSE): 4.0295320364805266e-08
Observation loss (MAE): 6.401240239811621e-05
Reward loss (MSE): 0.0003537485342146791
Reward loss (MAE): 0.012771805151261308

MP4 videos
https://github.com/user-attachments/assets/d45f9642-31ec-44bb-856a-76de17faa8f3
https://github.com/user-attachments/assets/044096a5-4fb9-4498-992f-ebe6b129435b

Web videos
https://github.com/user-attachments/assets/1f46c534-55dc-468e-a5e7-273abf374070
https://github.com/user-attachments/assets/9fd0a6ba-449d-4fba-b561-3999ba637a76

In case this is not satisfactory, the mai thing I can think of to better match the old behaviour is to perhaps run a hyperparameter tuner on the weld constraint parameters using these losses against the mujoco 2 / old weld parameter trajectory, which I might do anyway out of curiosity now that I have this set up.
Also validation RL experiments are still planned to check for behavioural similarity (which in my opinion is what matters more than the actual error between observation values).

I ran some hyper parameter tuning and it looks like with torquescale set to around 8.2 we can get an even closer match
Observation loss (MSE): 1.9481068874279174e-08
Observation loss (MAE): 4.892414725179199e-05
Reward loss (MSE): 6.343976866590461e-05
Reward loss (MAE): 0.005374891027247032

There is no need to try to match the behavior of mujoco==2.3.7 and mujoco==3.0.0 on top of which I am not sure if fine-tuning for 1 environment would do it anyway

also does the change in mocap_welds sign, break the environments with mujuco<3.0.0

@reginald-mclean do you want to maintain support for both mujuco<3 and mujoco>=3, if not I would recommend a version bump

There is no need to try to match the behavior of mujoco==2.3.7 and mujoco==3.0.0 on top of which I am not sure if fine-tuning for 1 environment would do it anyway

There's a slight degradation in performance when training a multi-task algorithm. The simulation is more accurate with Mujoco >= 3 which is likely why. We're digging into it to make sure that's the case

also does the change in mocap_welds sign, break the environments with mujuco<3.0.0 & @reginald-mclean do you want to maintain support for both mujuco<3 and mujoco>=3, if not I would recommend a version bump

Yes, this will break for Mujoco <= 2.3.7. We do not want to support Mujoco <= 2.3.7, so I agree that a version bump is necessary. We also are working on getting the docs and a few other things ready for a polished V3 release so I think this can be included in that release.

There is no need to try to match the behavior of mujoco==2.3.7 and mujoco==3.0.0 on top of which I am not sure if fine-tuning for 1 environment would do it anyway

I don't think it matters what environment it's fine-tuned for as long as the difference in rewards isn't used as the objective to minimise as the parameters here only affect the robot arm itself and how it responds to actions randomly sampled uniformly from its action space.
That said the difference is infinitesimal to begin with and as is shown in the tuning report the difference for values between 5 and 9 is almost within margin of error, so I don't think the actual value matters as long as it's within that range.
I will say anecdotally I have never seen tests fail for torquescale=5 (my initial value) but I have seen them fail (at 0.39/0.5 or 0.4/0.5 like in this latest CI run) for 8.22 which is what the tuner found. I might revert it back to 5.
Also I definitely agree that there is no need to match mujoco==2.3.7 down to arbitrary precision, but I thought it would be interesting to try.

also does the change in mocap_welds sign, break the environments with mujuco<3.0.0

The entire rotational part of the weld constraint is ignored in mujoco==2.3.7 due to a bug so any changes in those values actually shouldn't matter. To verify, I ran the tests with the quat being (-1, 0, 0, 0) and torquescale=1 with mujoco==2.3.7 and they pass.
But as @reginald-mclean said, I don't think supporting mujoco<=2.3.7 is desirable anyway and a version bump for supporting MuJoCo 3 would make the most sense.

Also I have finished running a multi-task algorithm (MTMHSAC) on the MT10 benchmark for 3 seeds and the results seem in line with previous ones obtained on MuJoCo 2.3.7.
An MT50 run is still planned but I am currently facing some technical difficulties getting experiments running on my university's compute cluster, which is the only compute I have access to that could tractably handle MT50 at the moment.

@rainx0r have we confirmed that everything looks good from a performance standpoint using torquescale 5?

I'd say so. I've got MT50 runs done more or less (one of seeds got cut off at 96M timesteps and my compute is out of commission at the moment so I can't resume it) which can be seen on this report. MT10 runs can be found on the report posted previously for torquescale 8.2, and for torquescale 5 there are some newer runs here which seem to replicate the 8.2 results.
Since MT10 and MT50 runs seem to work and reproduce existing results then this should indicate that the benchmark does indeed work on MuJoCo 3.
Also below are some comments on the MuJoCo 3-related settings after I've done some more thinking and research into them. tl;dr I think relpose quat could be reverted to (1,0,0,0) but it doesn't really matter, and torquescale should stay at 5 even though it also doesn't seem to matter much, but I'm open to suggestions for ways to find a better value if anyone has any.

P.S. 1: On the torquescale value
I mostly switched from torquescale 8.2 to 5 in an attempt to fix my failing MT50 runs but it seems like the problem was elsewhere. After debugging my algorithm implementation a bit more I was also able to more or less replicate the successful torquescale=5 MT50 runs on torquescale=8.2 on local compute for 1 seed. So overall the value doesn't really seem to matter to the RL algorithm. My opinion would be to stick with 5 for simplicity, unless there are any suggestions for how to potentially get a better value.
The optimisation metric I used for my previous experiment that found the value of 8.2 was very noisy so I don't have much faith in that value especially as there's no clear trend in the hyper parameter sweep. The distance between the observations across the two versions being so small as to be noisy as well as the two values not mattering to the RL algorithm should indicate that the value ultimately isn't that important though, unless I'm missing something.

P.S. 2: On the relpose quat
As for the relpose quat value, it's important that it's not (0,0,0,0)--which sets relpose based on qpos0. Then both (1,0,0,0) and (-1,0,0,0) represent the same rotation, so both should work and indeed at the same torquescale both have tests pass.
I used (-1,0,0,0) when I was trying out different things to get MuJoCo 3 working (and frankly I hadn't realised it was the same (lack of) rotation as (1,0,0,0) as I only read more into quaternions later; I'm sadly not an engineering major nor a game dev). We could revert it to (1,0,0,0) for simplicity and to avoid changing things when not necessary, or keep it as is since it does represent the same rotation after all and we have confirmed that (-1,0,0,0) works for RL. Personally I think it shouldn't matter.

@rainx0r thank you for the update and the hard work! Results look good to me