Changes in the load chart do not show up after changing strategies

Only after refreshing the page...

I can reproduce this if I'm not signed in.


undefined symbol: _ZN2at5sliceERKNS_6TensorElN3c108optionalIlEES5_l

Thanks for your error report and we appreciate it a lot.
Checklist

I have searched related issues but cannot get the expected help.
The bug has not been fixed in the latest version.

Describe the bug
I have the following installations and try to run the following installations but ending up with the below error
torch - 1.12.0
torchvision - 0.13.0
mmdet - 2.25.0
mmdet3d - 0.11.0
File "demo/pcd_demo.py", line 3, in
from mmdet3d.apis import inference_detector, init_detector, show_result_meshlab
File "/home/hykeserver/Downloads/3d_OD/TransFusion-master/mmdet3d/apis/init.py", line 1, in
from .inference import (convert_SyncBN, inference_detector, init_detector,
File "/home/hykeserver/Downloads/3d_OD/TransFusion-master/mmdet3d/apis/inference.py", line 8, in
from mmdet3d.core import Box3DMode, show_result
File "/home/hykeserver/Downloads/3d_OD/TransFusion-master/mmdet3d/core/init.py", line 1, in
from .anchor import *  # noqa: F401, F403
File "/home/hykeserver/Downloads/3d_OD/TransFusion-master/mmdet3d/core/anchor/init.py", line 1, in
from mmdet.core.anchor import build_anchor_generator
File "/home/hykeserver/anaconda3/envs/transfusion/lib/python3.8/site-packages/mmdet/core/init.py", line 3, in
from .bbox import *  # noqa: F401, F403
File "/home/hykeserver/anaconda3/envs/transfusion/lib/python3.8/site-packages/mmdet/core/bbox/init.py", line 8, in
from .samplers import (BaseSampler, CombinedSampler,
File "/home/hykeserver/anaconda3/envs/transfusion/lib/python3.8/site-packages/mmdet/core/bbox/samplers/init.py", line 12, in
from .score_hlr_sampler import ScoreHLRSampler
File "/home/hykeserver/anaconda3/envs/transfusion/lib/python3.8/site-packages/mmdet/core/bbox/samplers/score_hlr_sampler.py", line 3, in
from mmcv.ops import nms_match
File "/home/hykeserver/anaconda3/envs/transfusion/lib/python3.8/site-packages/mmcv/ops/init.py", line 2, in
from .assign_score_withk import assign_score_withk
File "/home/hykeserver/anaconda3/envs/transfusion/lib/python3.8/site-packages/mmcv/ops/assign_score_withk.py", line 5, in
ext_module = ext_loader.load_ext(
File "/home/hykeserver/anaconda3/envs/transfusion/lib/python3.8/site-packages/mmcv/utils/ext_loader.py", line 13, in load_ext
ext = importlib.import_module('mmcv.' + name)
File "/home/hykeserver/anaconda3/envs/transfusion/lib/python3.8/importlib/init.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
ImportError: /home/hykeserver/anaconda3/envs/transfusion/lib/python3.8/site-packages/mmcv/_ext.cpython-38-x86_64-linux-gnu.so: undefined symbol: _ZN2at5sliceERKNS_6TensorElN3c108optionalIlEES5_l
Reproduction

What command or script did you run?

python demo/pcd_demo.py demo/kitti_000008.bin configs/second/hv_second_secfpn_6x8_80e_kitti-3d-car.py checkpoints/hv_second_secfpn_6x8_80e_kitti-3d-car_20200620_230238-393f000c.pth

A placeholder for the command.

Did you make any modifications on the code or config? Did you understand what you have modified?

What dataset did you use?
nuScenes
Environment

Please run python mmdet3d/utils/collect_env.py to collect necessary environment infomation and paste it here.
Getting the below error while running the above command
Traceback (most recent call last):
File "mmdet3d/utils/collect_env.py", line 18, in
for name, val in collect_env().items():
File "mmdet3d/utils/collect_env.py", line 10, in collect_env
env_info = collect_base_env()
File "/home/hykeserver/anaconda3/envs/transfusion/lib/python3.8/site-packages/mmcv/utils/env.py", line 87, in collect_env
from mmcv.ops import get_compiler_version, get_compiling_cuda_version
File "/home/hykeserver/anaconda3/envs/transfusion/lib/python3.8/site-packages/mmcv/ops/init.py", line 2, in
from .assign_score_withk import assign_score_withk
File "/home/hykeserver/anaconda3/envs/transfusion/lib/python3.8/site-packages/mmcv/ops/assign_score_withk.py", line 5, in
ext_module = ext_loader.load_ext(
File "/home/hykeserver/anaconda3/envs/transfusion/lib/python3.8/site-packages/mmcv/utils/ext_loader.py", line 13, in load_ext
ext = importlib.import_module('mmcv.' + name)
File "/home/hykeserver/anaconda3/envs/transfusion/lib/python3.8/importlib/init.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
ImportError: /home/hykeserver/anaconda3/envs/transfusion/lib/python3.8/site-packages/mmcv/_ext.cpython-38-x86_64-linux-gnu.so: undefined symbol: _ZN2at5sliceERKNS_6TensorElN3c108optionalIlEES5_l

You may add addition that may be helpful for locating the problem, such as

How you installed PyTorch [e.g., pip, conda, source]
Other environment variables that may be related (such as $PATH, $LD_LIBRARY_PATH, $PYTHONPATH, etc.)

Error traceback
If applicable, paste the error trackback here.
A placeholder for trackback.

Bug fix
If you have already identified the reason, you can provide the information here. If you are willing to create a PR to fix it, please also leave a comment here and that would be much appreciated!

Same issue! Have you found out how to sovle it?


plugin "mobilefriendly" doesn't trigger event properly.

Describe the bug
plugin "mobilefriendly" doesn't trigger event properly.
To Reproduce
Steps to reproduce the behavior:

Exemple:

new Litepicker({
    plugins: ['mobilefriendly'],
    setup: (e) => {
        e.on('show', () => console.log('show'));
        e.on('hide', () => console.log('hide'));
    }
});

Event "show" is never invoke

Expected behavior
All predefined events in core Litepicker should be invoke like intended.
Additional context
Tested with "mobilefriendly" only.

My bad, can fix with mobilefriendly.show


Added a rake task to update the digest of tags

Fixes #827
Signed-off-by: Miquel Sabaté<EMAIL_ADDRESS>

LGTM


Pygments style less accurate than Ace editor theme

The joined image shows a same syntax highlighted (LaTeX) code in two blocks codes, both with the same Dracula style/theme:

the first one with Pygments,
the second one with Ace Editor.

As one can notice, the Pygments syntax highlighting is less accurate than the Ace Editor one. Is it possible to improve the Pygments syntax highlighting style in order to make it as accurate as the Ace Editor one (and as close as possible)?

Sure! Do you want to have a go? The source is here: https://github.com/pygments/pygments/blob/master/pygments/lexers/markup.py#L277

Well, I'm afraid this is beyond my scope but I could have a look.
Nevertheless, I noticed on the Demo page, with the sample code:
\documentclass{article}
\begin{document}
Test.
\end{document}

that Pygments doesn't distinguish between:

arguments of commands (between curly braces in LaTeX): article and document in the sample code,
ordinary text: Test. in the sample code.

Indeed, the tokens formatter shows that both arguments of commands and ordinary text are considered as “Text”:

Keyword
\documentclass

Name.Builtin
{

Text
article

Name.Builtin
}

Text

Keyword
\begin

Name.Builtin
{

Text
document

Name.Builtin
}

Text
Test.

Keyword
\end

Name.Builtin
{

Text
document

Name.Builtin
}

Text

Is is possible to enhanced the TeX and LaTeX lexer in this respect?

I took a look at it. The TexLexer lexer contains :
(r'[{}]', Name.Builtin),

This seems odd since, AFAIU, the token for [, {, } and ] should be Punctuation:

Punctuation
For any punctuation that is not an operator (for example [, (...))

Let's assume I'm not mistaken, then a PR with :
(r'[{}]', Punctuation),

would probably modify many existing documents. Would that be acceptable?


Use optimal layout for texture copying

Thank you! I don't recall the exact reason why COPY states were not exposed at the beginning. AFAIR, the reason was simple - usage complexity. Old VK validation was silent.

@vertver There were other places using vkCmdCopy... which used GENERAL. I fixed it. Fix will be included into the next update.

Thanks. I'll check them

I'm removing newly added COPY_SOURCE and COPY_DESTINATION texture layouts. There is no a benefit in using VK_IMAGE_LAYOUT_TRANSFER_*_OPTIMAL instead of VK_IMAGE_LAYOUT_GENERAL on NV HW at least. But the complexity of usage increases, potentially adding more transition barriers. Additional point - these do not exist in D3D12, what already implies that usefulness of those on desktop is minimal on any desktop HW.

But your change is useful, in VK implementation I added this:
// TODO: no benefit on desktop from "IMAGE_LAYOUT_TRANSFER_*_OPTIMAL" but keep for future needs
#if 0
    #define IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL
    #define IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL VK_IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL
#else
    #define IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL VK_IMAGE_LAYOUT_GENERAL
    #define IMAGE_LAYOUT_TRANSFER_DST_OPTIMAL VK_IMAGE_LAYOUT_GENERAL
#endif

VK spec does allow to use GENERAL. There is a validation message (not error) suggesting using TRANSFER instead, but it was silenced in NRI ages ago.
TL/DR: TRANSFER adds complexity in usage without giving a performance benefit.

There is no a benefit in using VK_IMAGE_LAYOUT_TRANSFER_*_OPTIMAL instead of VK_IMAGE_LAYOUT_GENERAL on NV HW at least.

But on AMD, it makes a difference.

Additional point - these do not exist in D3D12

They does. But it is fair to say that it is not supported on older drivers.

OK. You convinced me - COPY_SOURCE and COPY_DESTINATION stay. Probably, AMD is one of reasons why enhanced barriers appeared.


Associate a monograph with a press. Story #95

This looks great. Thanks Val!
@val99erie @jgmorse @mark-dce For future discussion: When dealing with Monograph metadata, what's the difference between a Publisher and a Press? Will there ever be a case where the Publisher is different than the Press? If we don't think so, by default the publisher field should inherit the value of the Press with the ability to overwrite it if needed, or, if don't anticipate the need for a custom publisher, maybe the Press field should just replace the publisher field and take on its existing and planned behavior (be facet-able across the entire platform, searchable etc.).


Broken replacement in #{tc}

As shown:
ECE_TRADE_C_CEFACT_2018_1E.adoc
https://github.com/metanorma/mn-samples-un/blob/master/sources/ECE_TRADE_C_CEFACT_2018_1E.adoc
        <title>Note</title>

The designations employed and the presentation of the material in this publication do not imply the expression of any opinion whatsoever on the part of the Secretariat of the United Nations concerning the legal status of any country, territory, city or area, or of its authorities, or concerning the delimitation of its frontiers or boundaries.

      </clause>
      <clause>
        <title>#{tc}
Simple, Transparent and Effective Processes for Global Commerce</title>

UN/CEFACT’s mission is to improve the ability of business, trade and administrative organizations, from developed, developing and transitional economies, to exchange products and relevant services effectively. Its principal focus is on facilitating national and international transactions, through the simplification and harmonization of processes, procedures and information flows, and so contribute to the growth of global commerce.

This is how it looks when rendered

And there is also an HTML tag shown below.

#47

@w00lf has fixed.

Hi @w00lf, I have confirmed that #{tc} issue is fixed. However, I think that the HTML tag issue persists, according to my outputs. (I have fetched directly from metanorma-un repo.)

My outputs:
Rec42.zip


FIX: Split testing

Let's see if this works.

Codecov Report

Merging #4358 into master will increase coverage by 0.1%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master    #4358     +/-   ##
=========================================
+ Coverage    82.9%   83.01%   +0.1%
=========================================
  Files         346      346
  Lines       63068    63074      +6
  Branches     9692     9694      +2
=========================================
+ Hits        52287    52358     +71
+ Misses       8089     8019     -70
- Partials     2692     2697      +5

Okay, this works and prevents timeouts more effectively. We might be able to use containers to speed things up, too, but it would be tricky. The reason scikit-learn and SciPy get gains from containers is by caching their C builds (and there is a good tool for doing this properly), not their Python environments. I suspect doing the environments would be difficult to get right. But we can try it in another PR.
Ready for review/merge from my end.

thx @

Thanks @Eric89GXL, great work - cool to see the army of builds :)
I'll rebase my PR today (in a few hours).


React: "New Session" react component

A react component needs to be created that can handle creating a new game session, with these options:

Category *required by backend
-Type (t/f, multiple choice) *required by backend
Number of questions *required by backend
Timers On/Off
Timer Difficulty
Joinable Midgame *either needs to update backend "joinable" flag at game start or game end

Works as intended except for passing it's data up to parent element, which seems to be a groupwide block that may not be solvable this sprint.


Build script refactoring

Description
Refactor the Gradle's build script (here's an example in Kotools Types).
Checklist

[x] Refactor.
[x] Test.

Done.


Unfollowed somebody without my knowledge - am I the only one?

Hi
I just found out by coincidence that I was not following https://bsky.app/profile/frenaville.bsky.social any longer. I am sure that I did not do this on purpose. Do you have other reports about this?

Not sure if there's anything actionable here

Closing


4.4.3

update release and tested

Thank you for the contribution! Unfortunately, I didn't see this before updating my own local repository.
One thing I noticed is that you updated the change log and files necessary to build the new version, but not the README.md and docker-compose.yml. I'd appreciate it if you would take a moment to update the version reference in all files before sending a pull request. Thanks.

Thank you for responding.
my branch 4.4.3 was up to date, but I still needed to apply the changes to my master branch
I checked the files with diff and they look identical, but maybe they checked the master branch before it was updated.
greetings and thank you for the warning


Handle errors to enqueue failed events

Handle errors to enqueue failed events

This is an improvement because it makes the reconciler retry failed events, but in the future, we should treat those errors better to ensure we do not leave anything in an inconsistent state.


Unicode characters are not deleted completely in terminal

Rancher Server Setup

Rancher version: 2.7.6
Installation option (Docker install/Helm Chart): Helm

If Helm Chart, Kubernetes Cluster and version (RKE1, RKE2, k3s, EKS, etc): RKE2

Proxy/Cert Details:

Information about the Cluster

Kubernetes version: v1.25.13+rke2r1
Cluster Type (Local/Downstream): Local

If downstream, what type of cluster? (Custom/Imported or specify provider for Hosted/Infrastructure Provider):

User Information

What is the role of the user logged in? (Admin/Cluster Owner/Cluster Member/Project Owner/Project Member/Custom)

If custom, define the set of permissions: Admin

Describe the bug

When the customer uses the built-in terminal in the Web UI it does not handle Unicode characters well. As an example when they write this: "árvíztűrő tükörfúrógép" in the console and then delete the whole line, the cursor disappears, and they have to delete the "nothing" for some time to get rid of all the Unicode bytes. Usually, it is not a problem as they mostly write there in English, but it can cause false alarms after mistyping on a non-English keyboard.
To Reproduce

Pick a cluster, it can be local cluster
Click a button to open kubectl shell
Enter Unicode characters and delete them. Once you delete the first one on the left side there still will be "nothing" prepended and has to be deleted for some time. If you hit enter at that point the remaining unicode section will be shown in the error message (e.g. "bash: $'\303\241r': command not found")

Result
áåčģŃáå
bash: $'\303\241\303\245\304\215\304\243\305\203\303\241\303\245': command not found
Expected Result
should as below

áåčģŃáå
bash: áåčģŃáå: command not found

Screenshots

Additional context

Internal ref: https://jira.suse.com/browse/SURE-6995

Re-opening for QA

Fix for this issue has been verified on rancher 2.8-head, 2.8.4-alpha and 2.7.13-alpha1. It is a retest pass. PFA
https://github.com/rancher/rancher/assets/149133120/33497242-4265-4f5b-a684-98ff7d6699d6


Fix a syntax error.

Fixes /Users/mz/.tmux.conf:8: command not found: setw error as mentioned in #25.

As per tmux manual, xterm-keys is effectively a window option and it's perfectly legitimate to do set -w xterm-keys on.


Refactor ValidateLogin

Thanks for the review! We're refactoring the old ValidateEmail call to a new ValidateLogin call that no longer requires chaining behavior. This flow is encountered when an account adds a secondary email and clicks on the resulting email validation link, leading them to verify their account on NewDot.
Due to the fact that we no longer chain the subsequent navigation on the result of the API call, we encountered a race condition where we were attempting to navigate before the NavigationComponent was full rendered. The solution was to temporarily cache the intended destination and do the redirect after the component had been fully loaded.
The corresponding backend API change has gone out already, and can be found here: https://github.com/Expensify/Web-Expensify/pull/34365
Fixed Issues
$ https://github.com/Expensify/Expensify/issues/218822
Tests
Four use cases can occur with this flow:

A user is already logged into NewDot, and the secondary login is NOT validated
A user is already logged into NewDot, and their secondary login is already validated and/or the link is invalid
A user is NOT logged into NewDot, and their secondary login is NOT validated
A user is NOT logged into NewDot, and their secondary login is already validated and/or the link is invalid

Resulting Conditions

In the first two cases, the user is simply redirected to their last open report/conversation with no error message displayed. Additionally, in Case 1, the account is silently validated behind the scenes.

In the latter two cases, the user is redirected to the login page. In Case 4, an error message would displayed below the password field stating: "This set password link is invalid or has expired...", while in Case 3, the user would encounter a password prompt.

To test the cases described above:

Log into OldDot and add a Secondary Login from Account Settings e.g<EMAIL_ADDRESS>Log into NewDot, or not, depending on the test cases above.
Formulate the URL to emulate clicking a verification link http://localhost:8080/v/<accountID>/<validationCode> on local dev (use script/clitools.sh generator:validateLink), http://staging.new.expensify.com/v/<accountID>/<validationCode> on staging, and http://staging.new.expensify.com/v/<accountID>/<validationCode> on production (or, use an email you have access to)
Verify that the resulting conditions described hold true for all 4 cases

[x] Verify that no errors appear in the JS console

PR Review Checklist
Contributor (PR Author) Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] iOS / native
[x] Android / native
[x] iOS / Safari
[x] Android / Chrome
[x] MacOS / Chrome
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product was added in all src/languages/* files
[x] I verified any copy / text that was added to the app is correct English and approved by marketing by tagging the marketing team on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] Any functional components have the displayName property
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

PR Reviewer Checklist
The Contributor+ will copy/paste it into a new comment and complete it after the author checklist is completed

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] iOS / native
[ ] Android / native
[ ] iOS / Safari
[ ] Android / Chrome
[ ] MacOS / Chrome
[ ] MacOS / Desktop

[ ] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product was added in all src/languages/* files
[ ] I verified any copy / text that was added to the app is correct English and approved by marketing by tagging the marketing team on the original GH to get the correct copy.
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] Any functional components have the displayName property
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

QA Steps

[ ] Verify that no errors appear in the JS console

Screenshots

Web

Mobile Web

Desktop
Not applicable, validation link opens browser
iOS
Not applicable, validation link opens browser
Android
Not applicable, validation link opens browser

Not ready for review just yet!

Still in progress, just need to fill out the tests section and provide screenshots once I get the App test environment working locally.

Should be ready, thanks for the reviews! :shipit:

What's going on with the route things, why did we need these changes here?

Race condition as a result of removing chaining (and the convenient delay that an API call adds). See OP for explanation.

Updated, and re-tested, thanks!

Merging per https://expensify.slack.com/archives/C02HWMSMZEC/p1661369238865979?thread_ts=1661349810.605389&cid=C02HWMSMZEC
Let me know if there's anything else and I can address in a followup PR 👍 #urgency #iterate

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

It was?

🚀 Deployed to staging by @robertjchen in version: 1.1.90-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

What's going on with the route things, why did we need these changes here?

@flodnv Also, it has to do with the fact that we have two navigation containers – one for PublicScreens and one for AuthScreens. When one unmounts, we have to wait for the other to be ready before we can navigate to routes again. Better long-term design would be to have one parent navigation container, and conditionally render screen groups instead of conditionally rendering navigation containers.


[docs] explain xdebug profiling with ddev

The Problem/Issue/Bug:
If someone prefers to use XDebug for profiling, it should be documented how to do it.
How this PR Solves The Problem:
Extends the documentation

Updated this to get it into the mkdocs.yml, and also made it automatically put the files in .ddev/xdebug so you don't have to work so hard to get them.
Thanks so much for this contribution!


#126 When user add/removes courses, the schedule page now automatically update the changes

hours:4


Add redraw snippet 'gridSnippets' on reload (#556)

Why is that?

It is fix for issue #556

The issue is caused by instante/extended-form-macros component so this PR is not necessary.


[spinner] Missing declaration file when using path import

When trying to import a component with path import, typescript shows an error about missing declaration file.
Note: There is no runtime error
RingSpinner

Checking the dist folder, declaration files are generated in a sub-folder:

Declaration files should be in the same folder of its js files.


[Core dev]: Standard COBOL manual memory allocation, pointers, and address of variables

Current Issue:
Standard COBOL defines statements for manual memory allocation (ALLOCATE and FREE), a data item clause where those can be used (BASED), and data item pointers / addresses (ADDRESS OF identifier).
C# itself does not like giving out pointers to GC allocated memory, because there's no guarantee that it won't be moved around by the GC eventually. Keeping all variables pinned is also not ideal (potentially very bad actually).
This means that we realistically can't get the address of a .NET heap allocated object. This is needed though, because Standard COBOL allows users to get the address of a working-storage data item, which is always a static heap allocation.
Possible Solutions:

Call C malloc and free.
Call Rust's equivalent of malloc and free.
A C or Rust implementation of a "memory pool" (Native equivalent of an ArrayPool<T>).
Custom stack-based memory allocator (outside the actual stack).

I need to read COBOL around memory allocation w..r.t OS.. but are you aware about C# this API.. it's an unmanaged way... Ideally we should avoid any p/invoke

@birojnayak Either way, we might have to step outside of the .NET heap for statically allocated memory like the working-storage. We can't get a stable address of a C# heap allocated object.
The standard also mentions this: "Identifier-1 shall not be defined in the working-storage or file section of an object or a factory object."
Which makes sense, because the standard also requires a GC for the object oriented features, and the working-storage memory of objects is managed by the GC. This also tells us a very important thing, the local-storage of methods is ALWAYS stack allocated (for primitive types).
It has to be stack allocated, because the standard allows us to get the address of a primitive data item from a method's local-storage. If it was heap allocated like the working-storage, that wouldn't be allowed.
Another important implication of this, is that the local-storage space is limited. For .NET on x64, the stack size is 4MB, allocating more than that will cause a stack overflow.
@GitMensch I would love to hear your opinion and recommendation on this. You have much more experience with memory allocation than I do, from working with C.

@birojnayak, there's also this one: NativeMemory
It should be more portable than Marshal.FreeHGlobal, but NativeMemory is also just a thin wrapper around C malloc and free (the source code for it just pinvokes malloc).

4MB is not enough so have a constructor that does the allocation and a destructor that does the free...
For performance reasons you'll likely consider to use 1 single block and just points the storage in there (either via address or by generating an internal struct).

Hey @GitMensch,

4MB is not enough so have a constructor that does the allocation

Wait, you mean allocating the local-storage on the heap instead of the stack?

For performance reasons you'll likely consider to use 1 single block and just points the storage in there

Yeah I was considering something similar using a "memory pool".
We could allocate a single chunk of memory that will be used for all statically allocated working-storage primitive types, and then distribute safe slices of it using C#'s Span<byte> and Memory<byte>.
But we could also allocate smaller blocks that can be reused so that we can avoid the performance overhead of constant allocations and deallocations if a function or program is called inside a loop.
If the compiler could somehow identify common local-storage block sizes in a COBOL compilation group, we could preallocate some of those upfront and reuse them by "renting" and "returning" them to the memory pool.
When a function is called it would check the pool to see if a block of suitable size is already available for it to "rent" before allocating another one. The block would then be "returned" to the pool after.

With objects you'll already have a "common size" at runtime, but using the memory chunk you could also reallocate the buffer if there's no space left for the next one (the exact details could be adjusted later, possibly start with a configurable size, defaulting to 4 MB, then double each time until reaching 200 when you'll only increase by 200.

@GitMensch is realloc on an existing buffer more performant than a malloc on a new one?
For example, if there is need for more than 4MB and we call realloc on the single buffer, will realloc allocate a new 8MB buffer, move the data over and free the previous, or will it expand the existing buffer?
I'm asking this because I imagine that it might affect performance a bit if a program needs more than 200MB of memory. It has to wait for a new 400MB buffer to allocate, move 200MB over, and free the previous buffer. The memory allocation would have to be done in a separate thread to avoid blocking the main thread on every reallocation.
I'll start implementing the allocator and configurable size option in the runtime library. Need to figure out the most performant way to allocate an unmanaged byte buffer in C#.

will realloc allocate a new 8MB buffer, move the data over and free the previous, or will it expand the existing buffer?

all reasonable implementations will extend the buffer if there's enough space behind

I imagine that it might affect performance a bit if a program needs more than 200MB of memory

only minimal; the increasing single buffer has the benefit that this does not happen often - because it is only used for the current active programs and you could configure to be "high" if you know that this is needed ...
... but actually: that approach is useful for different things but it is not usable for LOCAL-STORAGE "as is". You can use a similar approach but need to handle the slots yourself because you cannot reallocate an "active" LOCAL-STORAGE - as that would likely invalidate any pointers to it.
Therefore: do the slots (maybe configure "size of initial slot" and "size of additional slots") and then, if there isn't space in a current slot create a new one, keeping called programs together (so the slots at the end will normally be used first and therefore are likely to get "unused" together, allowing them to be GC'd if there are enough free slots or be realloc'd if there's the need for a slot to be bigger than the "size of additional slots").

I was looking in the standard for mentions of stack allocations (was curious if it was required), and the only thing I found was this:
"In many implementations of initial programs, working-storage is allocated "on the stack", which can conserve space because it goes away when the program terminates." -- D.6.2 Recursive and initial programs
That makes sense, but wouldn't that be too limiting? It would essentially make both the working-storage and local-storage stack allocated, and on most Linux distros (and macOS) the stack size is only around 8MB. Hmmmmmm...
Even though the standard doesn't explicitly mention anywhere else (I think) that the local-storage is stack allocated, it seems to imply it a little bit with the above quote (initial would cause working-storage to be stack allocated, so local-storage must already be, right?) and because it calls the local-storage "automatic data" (stack memory is automatically released on function return).
This makes sense for recursive programs, because we do actually want to crash with a stack overflow error if it infinitely loops itself and uses up all available stack memory (small, fixed size). On the other hand if the local-storage is allowed to infinitely grow on the heap during recursion, we risk using up all available system memory.
@GitMensch Are we sure that the intention isn't for the local-storage to be automatic stack allocations (of non object types), and the working-storage to be static heap allocations?

but actually: that approach is useful for different things but it is not usable for LOCAL-STORAGE "as is".

The single buffer idea might actually work if we use the buffer as a "stack memory". We would heap allocate a single, fixed size buffer, that behaves just like the actual stack. Whenever a program or function is called, it allocates the local-storage "on top of the stack" in the buffer and moves the stack pointer up, when it returns we zero fill the space and move the stack pointer back.
We could make the "stack" size configurable at compile time, and would have the benefit of making recursion less dangerous on system memory.

Added "Custom stack-based memory allocator" to the possible solutions.

There's no "intention" about stack/heap in the COBOL standard, it just describes what the result should be (it doesn't matter if you implement that yourself in a constructor/destructor or if it is done "automatically").
Also note that the Annex D is "informative" - so it does not specify any actual rules.

it doesn't matter if you implement that yourself in a constructor/destructor or if it is done "automatically"

What do you think of the custom stack memory idea?
I'm a bit worried of having the local-storage be heap allocated because of the potential to make recursion dangerous. With "infinite" heap allocations in case of an accidental infinite recursion situation.

You don't have to worry about that. If exception checks are not active then "whatever happens, happens"; if the user did enable EC-PROGRAM-RECURSIVE-CALL then this will be checked for non-recursive programs ("functions and methods are always recursive" attribute, and if a program defined as recursive is called infinite, then you have a problem in any case; but an implementor is free to add restrictions, so you could add an additional recursive entry (and/or section/paragraph) counter that also can be adjustable by the user; GC has an option to include a stack check, if enabled the default is 255, but a user can limit that or not enable it).

and if a program defined as recursive is called infinite, then you have a problem in any case

Yes, it should end up crashing in both cases. Even if exception checking is not enabled, because most of the time you can't recover from stack overflows.
But the thing is that it is much more dangerous to have the program occupy several GB of heap memory before crashing, than to occupy just a few (user configurable) KB or MB of (fixed size) stack memory before crashing.
If this accident happens on a server then the "rogue" infinite recursion program could easily cause a denial-of-service by occupying the entire available memory before crashing with an OOM error (possibly crashing other things as well).
Here's an example, FUNCTION-1 was coded in a way that it will accidentally cause an infinite recursion.
FUNCTION-1 when called will allocate its local-storage on the heap, when it calls itself its local-storage will remain allocated, because it has not returned yet.
So now FUNCTION-1(1) is still "active", and FUNCTION-1(2) will allocate a new local-storage on the heap. These allocations will continue until the OS itself is forced to terminate the application with an OOM error.
We probably shouldn't allow the local-storage allocations to expand infinitely like this.

As noted: just add a hard default limit that is user-configurable during compile time - so the generated program will check with a single static variable that it either:

isn't called recursive too often static int number_of_recursive_calls   or:
does not allocate a bigger stack than N in all iterations static int amount_of_local_heap

@GitMensch, Here: https://github.com/otterkit/otterkit/blob/main/Libraries/Otterkit.Native/native/stackalloc.c
I implemented a simple allocator using mmap on unix-based systems. The idea is that our allocator should be designed for only allocating bigger blocks, that we can then use for the local-storage memory.

I abstracted the pointer away on the C# side, so that whenever we want to write to the memory block we can either get a safe Span<byte> around the whole block, or a limited slice of it (can't read or write the whole thing). This gives us a safe way to interact with the native memory.
I didn't want to use the system malloc because it seems to be slow on Windows. Calling malloc on Windows for some reason is slower than allocating a full C# array of the same size.

Updated it to use malloc instead of mmap. Allocating with mmap is simple enough on Unix, but then we have Windows... and yeah I'm just going to use the standard malloc to allocate memory.
Windows doesn't have a direct equivalent to mmap with private and anonymous maps as far as I know, instead we'd have to go with the win32 HeapAlloc and HeapCreate (Or GetProcessHeap, but there's no way to know if the dotnet runtime is already using this one).
There's a weird lack of documentation and usage examples for those APIs.

@GitMensch, @birojnayak I did some benchmarks to see which one would be more performant. A direct malloc/free call (through pinvoke), or allocating a pinned uninitialized array in C# of the same length (512KB).
Unsurprisingly, malloc and free is around 29 times faster than allocating a managed C# array.
The benchmarks below won't show the amount allocated for the native call, because it's outside the .NET managed heap.
[MemoryDiagnoser]
public class MemBench
{
    [Benchmark(Baseline = true)]
    public void AllocNative()
    {
        var memory = StackMemory.Alloc(524288);

        var span = memory.Span;

        StackMemory.Dealloc(memory);
    }

    [Benchmark]
    public void AllocArray()
    {
        var array = GC.AllocateUninitializedArray<byte>(524288, true);
    }

    [Benchmark]
    public void AllocMemory()
    {
        var array = GC.AllocateUninitializedArray<byte>(524288, true);

        var memory = MemoryMarshal.CreateFromPinnedArray(array, 0, array.Length);
    }
}

Method
Mean
Error
StdDev
Ratio
RatioSD
Gen0
Gen1
Gen2
Allocated
Alloc Ratio

AllocNative
993.5 ns
11.26 ns
9.98 ns
1.00
0.00
-
-
-
-
NA

AllocArray
29,498.3 ns
87.70 ns
82.03 ns
29.69
0.28
166.6565
166.6565
166.6565
524366 B
NA

AllocMemory
29,362.4 ns
156.74 ns
138.95 ns
29.56
0.37
166.6565
166.6565
166.6565
524366 B
NA

BenchmarkDotNet=v0.13.5, OS=Windows 10 (10.0.19045.2965/22H2/2022Update)
Intel Core i3-7100T CPU 3.40GHz (Kaby Lake), 1 CPU, 4 logical and 2 physical cores
.NET SDK=7.0.200
  [Host]     : .NET 7.0.3 (7.0.323.6910), X64 RyuJIT AVX2
  DefaultJob : .NET 7.0.3 (7.0.323.6910), X64 RyuJIT AVX2

Revisiting this again because we can't use the system malloc, and we need an allocator to progress further on certain parts of the runtime. Malloc on Windows and macOS is too slow, and the glibc implementation is also not ideal.
I'm working on a custom allocator specifically for COBOL, one that is optimized for the language's needs. Which also means that we can throw thread safety out the window (COBOL's concurrency model doesn't use multithreading) and gain some nice performance improvements.
I've been reading a bunch of research papers about this the past month. I think I have a pretty good architecture we could use, and if this works out it might end up simpler and faster than the vast majority of malloc implementations.
The Fast Efficient Fixed-Size Memory Pool by Ben Kenwright paper really caught my attention, it describes a memory pool that is incredibly simple in its design, they also suggest that it's several times faster than malloc. With the right design this could be adapted into a size-class based allocator, with each fixed-size pool being responsible for each size class.
Only issue right now is mmap on Linux not having an option to align the mapped memory, which then leads to needing to over allocate and munmap the unaligned parts.
@GitMensch do you know any solutions for this? Most state of the art implementations do this but it seems like a huge waste of CPU cycles for the 3 (or more) system calls needed to align the mapped memory on Unix systems. On Windows the VirtualAlloc function returns a 64KiB aligned address which works really nicely to optimize free, but on Linux there doesn't seem to be an option to do this.
The need to align the mmapped address on Unix leads to a much worse "slow path" performance when the allocator needs to request more memory from the OS. This is obviously not ideal at all, and a solution that avoids these multiple system calls could result in an allocator that is several times faster than any current state of the art designs.
Also, the reasoning for a custom allocator implementation is that from personal experience, the system malloc is just too slow for a language runtime (on every OS). The above paper I linked corroborates my experience with this quote:

In retrospect, studies have shown that in some cases an application can spend on average 30% of its processing time within the memory manager functions [1–4] and in some cases this can be as high as 43% [5].

Given that the majority of applications out there are most likely using the system malloc, this seems to confirm my suspicions, and if that wasn't enough there's also a discussion on the LLVM forums that seem to suggest that compilation speeds can be improved by up to 10 times just by overriding Windows' malloc implementation with a custom one (rpmalloc).

I think I just had a sudden realization! The methods used to request memory from the OS on nearly all malloc implementations don't (instantly) allocate physical memory, but actually virtual memory on the process' virtual address space (which gets translated to physical addresses by the kernel).
The functions used (VirtualAlloc and mmap) also won't touch all of the pages or zero out the whole requested space, it only reserves the range so that future (unfixed) mappings cannot be made there. So... what's stopping us from reserving an obscenely large range of virtual address space for our allocator, say... 2 terabytes, and then use MAP_FIXED inside that range to allocate and deallocate the aligned 64KB slabs?
Considering that on x64 the available virtual address space today is at least 250 terabytes, mmap won't fail in finding a free 2TBs range to reserve. We're also essentially future proof with this design, given that virtual memory is very unlikely to become an obsolete thing in any modern (or future) operating systems.
This would completely solve the aligned mmap issue. The allocator only needs to align the very first slab (at initialization), and further slabs can be created with fixed mappings that use an address with a 64KB offset relative to the address of the first slab.
In fact, if this works and we can actually reserve 2TBs of virtual memory, we could align the first slab at a larger boundary than 64KBs, delaying the need for calls to mmap even further. Thus potentially improving the overall performance of the allocator.
I'll have to test this!

I'm not sure that this will work with a low ulimit and don't have a clue how this would look in top /task manager.
It sounds like if you go that route then it would be best to make this configurable, possibly defaulting to 1GB and increase as necessary (not re-allocate but use a second blob when needed).
It likely will break x86 - or is that out of scope in general?

and don't have a clue how this would look in top /task manager.

@GitMensch, I was curious how it would look as well, so I tested it. I reserved 2 terabytes of virtual address space using mmap with PROT_NONE and MAP_NORESERVE | MAP_ANONYMOUS | MAP_PRIVATE, then I did a fixed mapping of 400MBs at a 2GB offset from the start of the reserved space, this time with PROT_READ | PROT_WRITE and MAP_FIXED | MAP_ANONYMOUS | MAP_PRIVATE.
The MAP_NORESERVE flag is so that it doesn't use any swap space for the reserved 2TBs of address space, which is what we want. Swap space can be reserved afterwards, when the slabs are mapped into it with MAP_FIXED.
At this point it didn't show up in top or macOS' activity monitor yet, so I looped through the 400MBs writing a single byte every 4096 bytes to force the pages to allocate into physical memory. This is what is shown in top after:

And this is from the activity monitor (macOS' task manager equivalent):

This seems reasonable, both are showing the physical memory being used from the pages that I looped through. It doesn't show the 2TBs of virtual memory that was reserved or the 2GBs that I skipped at the start of it. It looks like this might actually work really well!

possibly defaulting to 1GB and increase as necessary (not re-allocate but use a second blob when needed).

This might be too low, it would limit alphanumeric items, tables and objects in Otterkit to have a maximum size of 1GB each. I was hoping to allow users to create larger tables and alphanumeric items if needed, which could be useful is certain scenarios.

It likely will break x86 - or is that out of scope in general?

It's currently out of scope for Otterkit. We're focusing on supporting only 64-bit architectures, which also includes ARM64 (AArch64). Supporting x86 (32-bit) would also severely limit some optimizations like this allocator design, and some hardware intrinsics (like SIMD) that might not be present in older processors.

possibly defaulting to 1GB and increase as necessary (not re-allocate but use a second blob when needed).

This might be too low, it would limit alphanumeric items, tables and objects in Otterkit to have a maximum size of 1GB each.

No, because if you get a request of 1,8 GB you obviously will use a 1,8 GB block.

Supporting x86 (32-bit) would also severely limit some optimizations like this allocator design, and some hardware intrinsics (like SIMD) that might not be present in older processors.

Yes, that's reasonable for a new environment that also doesn't have a compatibility promise (and burden). I'd suggest to recheck the project description and README for including that note "a modern COBOL compiler for 64-bit environments" could be in the description and a longer statement similar to yours above in the README. (just a suggestion)

I'd suggest to recheck the project description and README for including that note

I updated the project description to reflect this: "A free and open source Standard COBOL compiler for 64-bit environments". I'll work on a longer statement to put in the README later.

No, because if you get a request of 1,8 GB you obviously will use a 1,8 GB block.

I was thinking of how this would work, but it might make the optimization not worth it with the virtual address space split into multiple blocks because then there's no guarantee the they'll be allocated next to each other, and would make bookkeeping more difficult requiring a linked list of virtual memory blocks.
The contiguous heap design would work like this: Reserve an obscenely large virtual address space range at initialization, we can treat it like a contiguous array. Initialize the heap's global bookkeeping at the very start of the reserved space, and maintain an offset to the very first 128KiB-aligned address (and set guard pages between it and the heap's global bookkeeping).
At this point we have what is essentially a contiguous 128KiB-aligned 2TiB array, we are free to mmap fixed-size pools there to manage the heap's various size class based allocations. The pools would be allocated on 128KiB offsets which makes bookkeeping extremely simple as there's no longer a need for a linked list, just offsets relative to the start of the heap. This could also theoretically improve cache locality, because the fixed pools will be much more likely to be allocated right next to each other in memory.
But this doesn't exactly work well when huge multi-gigabyte allocations are done, because those would have to be allocated right next to the 128KiB pools, right? Well, not if we treat huge allocations differently.
We can make smaller allocations always occur in the 128KiB pools, growing upwards, and huge allocations to occur at the very end of the heap, growing downwards. Effectively guaranteeing that huge allocations won't completely destroy the cache locality of the smaller pools, and won't cause fragmentation problems there as well. There's no way to make huge allocations cache-friendly anyways, so moving it far away shouldn't be a problem.
Finalizing and freeing the entire heap if needed would also be much easier, just a single munmap call.

It sounds like if you go that route then it would be best to make this configurable

@GitMensch, I was thinking about what you said earlier, about making it configurable. I think I have an idea that would still allow us to use the contiguous heap design. Let me know what you think of this idea.
Instead of hardcoding the size at compile time, what if we first try to fetch an OTTRK_ADDRESS_SPACE environment variable at initialization to set the desired maximum reserved address space?
This would only be done once at initialization so it shouldn't cause performance issues, and would make it so that the reserved address space can be changed without requiring a recompilation. It would first check if the environment variable is set to fetch the size, and if it's not set it defaults to 2TiB.
This would also work on a per process basis by passing the variable directly to the executable on the terminal. So if needed you could set the reserved size to be 4GB for example.

Something like an environment variable as a runtime configuration was what I've meant.
Still it would be necessary to "somehow" check the "free" space.
Your approach of 128KByte from start and big ones from the end sound good (in the hope that this wouldn't reserve the complete space).
Did you check the effect on Win32 with ProcessExplorer / Task Manager already? The notes above only included GNU/Linux and MacOS.

Did you check the effect on Win32 with ProcessExplorer / Task Manager already? The notes above only included GNU/Linux and MacOS.

@GitMensch, here are the results from the Task Manager on Windows:

And also from the Process Explorer:

Seems reasonable, the results appear to be the same with just 400MiB being used, even with 2TiB of virtual address space being reserved. It looks like the program already starts with 4MB of memory used even before reserving the address space, so the result ends up being 404MiB, that's odd.

4MB .NET runtime...

@GitMensch this was actually a standalone C executable calling the OS functions, which makes it even weirder. It has to be some sort of Windows weirdness, but I'm not sure what it could be.

Here's the C source code I used to test it on Windows:
https://github.com/otterkit/otterkit/blob/main/Libraries/Otterkit.Native/nativelib/main.c
And our CASPAL abstraction layer header (still WIP):
https://github.com/otterkit/otterkit/blob/main/Libraries/Otterkit.Native/nativelib/CASPAL.h

Still it would be necessary to "somehow" check the "free" space.

@GitMensch I'm thinking of using a bitmap index tree with a depth of 4. If my math is right, it should be able to index all the 128KiB pools in the entire 2TiB address space with just 4 bit scan instructions.
So worse case scenario, when the allocator needs another pool we just need 4 bit scan instructions and a system call. In theory this sounds like it should be more efficient than the pointer chasing and 3 system calls every 64KiBs that other allocators are doing.
Should also require only 2MiBs to store the bitmap when the entire 2TiB is in use. We also guarantee that the allocator is capable of handling at least 2TiB with this design, which should be amazing for high-end servers.

Heap layout sketches and trying to figure out how to maintain an index of free blocks. The math in this might be wrong, I'll check as I update it.
|--- 128 TiB Virtual Heap ------------------------| * Maximum possible with this design,
| 128GiB slab | 128GiB slab | 128GiB slab | . . . | | not the default heap size.
|-------------------------------------------------| + Design is future proof?
       ||
       || 1024 memory slabs maximum in a given application.
       || 1024 bits to index all possible 1024 slabs in the heap.
       \/ (32 uint32s = 128 bytes = 1024 bits).

|--- 128 GiB Memory Slab -------------------------| * Logical entity to make pool
| 128MiB page | 128MiB page | 128MiB page | . . . | | index bookkeeping easier.
|-------------------------------------------------| + Expressed as offsets.
       ||
       || 1024 allocator pages in each 128GiB slab.
       || 1024 bits to index all 1024 pages in a slab
       \/ (32 uint32s = 128 bytes = 1024 bits).

|--- 128 MiB Allocator Page ----------------------| * Logical entity to make pool
| 128KiB pool | 128KiB pool | 128KiB pool | . . . | | index bookkeeping easier.
|-------------------------------------------------| + Expressed as offsets.
       ||
       || 1024 object pools in each 128MiB page.
       || 1024 bits to index all 1024 pools in a page
       \/ (32 uint32s = 128 bytes = 1024 bits).

|--- 128 KiB Object Pool ------ 128KiB aligned ---| * Physical entity defined
| header | -- bytes | -- bytes | -- bytes | . . . | | as a C struct.
|-------------------------------------------------| + 32 byte bookkeeping header

|--- Total Memory Usage for index bookkeeping ------| * Each bit is an index into a 32-bit
| 1 virtual heap in an application     => 1 uint32  | | integer array one level down.
|---------------------------------------------------| | This creates a bitmap tree with
| 1024 memory slabs in total           => 128 bytes | | a maximum depth of 4.
|---------------------------------------------------| |
| 1'048'576 allocator pages in total   => 128 KiBs  | | The index of a free pool can be
|---------------------------------------------------| | found with just 4 _mm_tzcnt_32
| 1'073'741'824 object pools in total  => 128 MiBs  | | instructions on modern CPUs
|---------------------------------------------------| +

The index works like this: we start with one 32-bit integer at the root, which when
used as a bitmap can store 32 boolean values indicating whether that bit position
(as an index) will lead to a free pool in the next level of the tree.

The second level of the tree has exactly 32 integers, and so if the last bit of the
root integer is 0 then a call to _mm_tzcnt_32 (with a bitwise NOT of the root) will
point us to the first of the 32 integers. We then perform another call to _mm_tzcnt_32
with the first integer to find the next index, we continue this until we find the free pool.

By also using virtual memory to store the indices we can lazily initialize them as the
heap usage increases, with a total of 128 MiBs of memory for index bookkeeping when
all of the 128 TiBs are in use.

This seems acceptable, if we already have that many terabytes allocated, an additional
128 MiBs for bookkeeping is not that much.

@GitMensch, here's a working implementation of the above allocator design. Tested on Windows, Linux and macOS. It seems to be working (just missing large allocation support), but I'll have to override the system malloc on existing applications to test it properly.
https://github.com/otterkit/otterkit/blob/allocator/Libraries/Otterkit.Native/nativelib/allocator.c
The math above was slightly wrong, we needed a depth of 5 on the tree in order to support up to 128TiB of heap space. This allocator design is likely the only one right now that can allocate up to 128TiB without fragmenting the entire virtual address space on every slab allocation.
The implementation is also incredibly simple, less than 400 lines of C.

You may want to check the speed versus -ltcmalloc.


Creating world-space covariance matrices

Hi, thanks for the great work. I was trying to understand your code, and I have doubts with the following operation.
    # Create world-space covariance matrices.
    covariances = build_covariance(scales, rotations)
    c2w_rotations = extrinsics[..., :3, :3]
    covariances = c2w_rotations @ covariances @ c2w_rotations.transpose(-1, -2)

Could you please clarify why this is being done?
Thanks in advance

Hi @Shubhendu-Jena, since our encoder predicts Gaussian parameters in camera space, these parameters must be transformed into world space before rendering. In particular, these operations here build the covariance matrix from the predicted scales and rotations and then transform it into world space for further rendering.

Hi, thanks for the quick response. Why didn't you just multiply the rotation matrix with the c2w matrix in that case? Is it because converting it back to the quaternion format will cause ambiguity? I wanted to just use the scales and rotations and not the covariance matrix as input to the rasterizer, hence the question.

I see. We use an off-the-shelf rasterizer, which takes the world space covariance matrix as input, so we do need to do those operations to match its input.

Got it. Thanks so much for the response.


Cannot get snackbar to show - Unknown custom element

Hello, I am very new to both Vue and Vuetify. However I have the beginning of a project working fine. I would like to use this plug in. I am not using nuxt. I am using vuetify 2.x and vue 2.x.  I've tried installing as instructed - I did:  npm install vuetify-toast-snackbar just fine.
My 'main.js' has:  import VuetifyToast from 'vuetify-toast-snackbar' at the top... and:  Vue.use(VuetifyToast) in the middle, near the other 'Vue.use' blocks. I do not have it in the new Vue ({ block.  i tried it there and it did not make a differenece.
My plugins/vuetify.js now looks like this:
import Vue from 'vue'
import Vuetify, { VSnackbar, VBtn, VIcon } from 'vuetify/lib'
import VuetifyToast from 'vuetify-toast-snackbar'

Vue.use(Vuetify)

export default new Vuetify({
  theme: {
    options: {
      customProperties: true
    }
  },
  components: {
    'v-snackbar': VSnackbar,
    'v-btn': VBtn,
    'v-icon': VIcon
  }
})

Vue.use(VuetifyToast) //new line for vuetify toast

In the 'components' block I tried it first without 'names', and then with.  I tried 'proper names' for each name, i.e., VSnackbar, as well as the value that the errors display, i.e., v-snackbar.  Neither seems to work.
Here are the errors I get back when trying a test from within my App.vue component:
[Vue warn]: Unknown custom element: <v-snackbar> - did you register the component correctly? For recursive components, make sure to provide the "name" option.
(found in <Root>)

I've tried reading through other issues/resolutions, but could not find a solution. Assuming I get this working, I then want to use this within another plug-in I am using, vuetify-dialog.  I read about the problems of using this plug-in from within another plugin and did not see a final resolution.  Maybe I missed it (or didn't understand it yet).
Thank you!

I re-read all of the closed issues and found my error.  I had mistakenly added the 'components block' to the 'export default new Vuetify({ section instead of the Vue.use(Vuetify section.  Once I did it correctly, as the install instructions specified, all works fine.
As for it working from 'within' another plug-in, i.e., the Vuetify-Dialog plug-in, it 'works', however it displays relative to the overall browser window, not the 'popped up' dialog window. In other words, I have opened a modal dialog window with a 'form' inside it. When the user clicks 'OK' (or 'Sign In', I want to display the toast widget within the dialog, not at the bottom of the overall browser. Do you think this is possible?
Thank you again and sorry for the false issue.  I will wait on closing this until you get back concerning the 'relative positioning' issue.

@davbaron do you mind posting your solution? Can't seem to get it working, have same error

Hello Corey,
Hopefully this will get to you…
Shortly after my issue with Eolant Toast/Snackbar, I decided to switch to a different source for my ‘toast/snackbar’ needs:  https://github.com/xon52
The developer produces a ‘notify’ component, which is very similar to the Eolant offering.  However he also produces a ‘modal dialog’ component and a ‘google maps component’ which I use.   He is very active and open to changes/updates.
In any case, I no longer have the code in my project that deals with the Eolant component.  That said, after going thru my comments on the github site, I can see that I eventually followed the installation/set-up directions correctly and was thus able to get it working.
Feel free to contact me if you need… hope this helps (especially the xon52 stuff),
-David
Centennial, CO
From: corey-cosman<EMAIL_ADDRESS>Reply-To: eolant/vuetify-toast-snackbar<EMAIL_ADDRESS>Date: Wednesday, June 10, 2020 at 9:31 PM
To: eolant/vuetify-toast-snackbar<EMAIL_ADDRESS>Cc: David Baron<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [eolant/vuetify-toast-snackbar] Cannot get snackbar to show - Unknown custom element (#34)
@davbaronhttps://github.com/davbaron do you mind posting your solution? Can't seem to get it working, have same error
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/eolant/vuetify-toast-snackbar/issues/34#issuecomment-642384746, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABCJFL74DUBPSIFPGARNQT3RWBF2TANCNFSM4LM3H2TQ.


[MM-45615]: Fix problem where "View plans" button pushes Search box to the left

Summary

Previously, when the "View plans" button is shown, the search bar gets pushed to the left a bit. I've made the size of the left and right part of the header the same size. This allows the center part of the header (which contains the search bar) to always be centered.
Ticket Link

https://mattermost.atlassian.net/browse/MM-45615
Related Pull Requests

Has server changes (please link here)
Has mobile changes (please link here)

Screenshots

before
after

Release Note

NONE

E2E tests not automatically triggered, because PR has no approval yet. Please ask a developer to review and then try again to attach the QA label.

/e2e-test

Successfully triggered E2E testing!
GitLab pipeline | Test dashboard

Thank you @emmyni ,
I've tested at changes.
Also invited @stevemudie also to do a QA pass on this.


Bryan Zamora's Biography

@bzamora020 Your comment about applying what you've learned made me think of one of my (many) favorite xkcd comics: https://xkcd.com/208/.
I look forward to hearing more about your future company and the positive change that it can bring into this world!


dashboard Repositories Unknown state

Hello,
I just add k3s cluster with 3 masters and 3 workes to rancher, and tried to enable charts repositories but all of them appear unknown, no logs or info why found.
How to troubleshoot this?

Best regards

K8s 1.20 is not supported by the version of Rancher you're running. Upgrade to the current 2.5.x.

Hello,
Thank you for tip @vincent99
Strange was that other cluster in same rancher have charts working without problem.
Best Regards


Smooth radius problem

My extreme hills edge and extreme hills have both a large smooth radius and use volatility1 and volatility2. When they generate next to each other (which very frequently happens as EHedge is the border of EH) there are often giant cliffs like in the image. I think that shouldn't happen as the smooth radius of both is high. Weird things also happen when EH (or a different biome with vola1) generates next to one without that setting turned on.
More information can be found in the image.

Using the instructions and images I PM'ed to Timethor this is reproduceable.

(I accidentally closed it. It's reopened now. I hope so actually :D

After some PM's this is being converted to a Feature Request for the ability to set a flag that would include Volatility1 and Volatility 2 in the smoothing process. Those two settings currently do not get smoothed out.

Any plans of adding this feature? Most of the biomes I use uses volatility 1 and 2 and it would be nice if i could smoothen the edge of biomes.

After much investigation, this seems rather unfeasible without more effort than I am prepared to give at the moment. This issue will remain open but I have no plans of implementing it anytime soon. Maybe in a rewrite?

@Timethor
Can't you just do something like this?
-- Current process of world generation --
Generate terrain
Use smooth radius
Add vola1 and vola 2
Add other stuff
Isn't that changeable to this?
-- Some other kind of process that could possibly solve this issue --
Generate terrain
Use smooth radius
Add other stuff

@Timethor
Can't you just do something like this?
-- Current process of world generation --
Generate terrain
Use smooth radius
Add vola1 and vola 2
Add other stuff
Isn't that changeable to this?
-- Some other kind of process that could possibly solve this issue --
Generate terrain
Add vola1 and vola 2
Use smooth radius
Add other stuff
(As you know, I can't code, so I don't know how difficult this is to change.)

Or do you have a workaround?

@Timethor (now I see you're online ;) ) there are sometimes weird things happening with biome intersections with and without vola1/2. Sometimes giant cliffs or walls or floating stuff generate when two of those biomes meet, creating weird terrain that shouldn't generate in those biomes.
I created a 2D image explaining what's happening sometimes in the terrain.
There are two biomes, green (G) and blue (B).
G doesn't use vola1/2, B does.
If B didn't use vola1/2, it would generate like light blue. You can see it generates in this example mountainous terrain with floating islands, so the green biome gets a bit of that mountainous terrain at the edge, because of smoothradius.
But B does use vola1/2, and because of this settings, the terrain is randomly a lot lower at that point than it would be without. But as smoothing happens before vola1/2, the smoothing creates a lot of mountains and weird stuff at the edge of G, assuming B generates weird and high. So you get G with a mountainous edge. Then in the generating process, vola1/2 is used, so you get the lower terrain in B (darker blue). And suddenly there's a big wall and floating island in the sky because of an incorrect smoothing process!

You understand what's happening, right? (If my explanation wasn't clear, that might have happened, please say that, I'll try to explain it better then) The smoothing process creates this weird terrain that in this case shouldn't happen. And of course the opposite may happen too.


added json completion

wow! this is all it took then?? this is so exciting to see LSP libraries being used without requiring an lsp compatibility layer

love it! awesome work


[Improve] Introduce SeaTunnel web project in README.md

Purpose of this pull request
This PR introduce SeaTunnel web project in README.md. Also remove some useless text.

Does this PR introduce any user-facing change?
No

How was this patch tested?
unnecessary.

Check list

[ ] If any new Jar binary package adding in your PR, please add License Notice according
New License Guide
[ ] If necessary, please update the documentation to describe the new feature. https://github.com/apache/seatunnel/tree/dev/docs
[ ] If you are contributing the connector code, please check that the following files are updated:

Update change log that in connector document. For more details you can refer to connector-v2
Update plugin-mapping.properties and add new connector information in it
Update the pom file of seatunnel-dist

[ ] Update the release-note.

cc @EricJoy2048 @FlechazoW

Some conflicts need to be resolved.

Some conflicts need to be resolved.

Done


[Question] Telegram 1.9.9

I have packed the file avrt.dll in the main installation directory of Telegram: D:\Telegram Desktop. Still nothing happens. Maybe you can tell me where my error is. I use Windows 10 64bit and Telegram Desktop Version 1.9.9

Please check if the ArLog.txt file exists in the root directory after starting TG.
If the file does not exist, it is because the hijacking of avrt.dll failed.
The error is trying to be fixed. Thank you for your feedback!

I have checked all over there are only the normal telegram log

A beta version to fix this bug is released, try it.
https://github.com/SpriteOvO/Telegram-Anti-Revoke/releases/tag/0.1.4
If the test is OK, remember to tell me here please.

Thanks now it works


Camera frame transformations

When plotting star positions on the camera (transforming from sky coordinates to the camera frame), the positions do not appear where one would expect for different telescope types:
LST

CHEC

I would expect to see a mirroring in the second image with respect the the first, due to the 2M telescope.
As I understand now (from talking to @ParsonsRD), the camera frame is not the actual coordinates you expect to have when physically looking at the face of the camera, but it is instead a "MCCameraFrame". This frame has already taken into account this reflection in the simulations, and therefore does not need to be handled differently in the analysis.
However, when handling observations from real camera data, this approach is not intuitive.
@ParsonsRD has suggested to include an additional camera frame which represents what you would see if you look at the face of the camera:
CameraFrame (New frame which represents what you see when you look at the camera face. Data read from real telescopes are associated with this frame)
↓
MCCameraFrame (Currently existing CameraFrame. Data read from simulations are associated with this frame)
↓
TelescopeFrame, etc.

Code snippet for the above plots:
import matplotlib.pyplot as plt
from astropy.time import Time
from astropy.coordinates import SkyCoord, EarthLocation
import astropy.units as u
from ctapipe.coordinates import CameraFrame, HorizonFrame
from ctapipe.visualization import CameraDisplay
from ctapipe.instrument import CameraGeometry

location = EarthLocation.of_site('Roque de los Muchachos')
obstime = Time('2018-11-01T04:00')

crab = SkyCoord.from_name("crab nebula")

horizon_frame = HorizonFrame(location=location, obstime=obstime)
pointing = crab.transform_to(horizon_frame)
camera_frame = CameraFrame(
    telescope_pointing=pointing,
    focal_length=u.Quantity(2.15, u.m),#28 for LST
    obstime=obstime,
    location=location,
)

# cam = CameraGeometry.from_name('LSTCam')
cam = CameraGeometry.from_name('CHEC')
fig, ax = plt.subplots()
display = CameraDisplay(cam, ax=ax)

ax.set_title(
    f'La Palma, {obstime}, az={pointing.az.deg:.1f}°, zenith={pointing.zen.deg:.1f}°'
)

stars = [crab]
for name in ['o tau', 'zet tau']:
    stars.append(SkyCoord.from_name(name))
for star in enumerate(stars):

    star_cam = star.transform_to(camera_frame)

    x = star_cam.x.to_value(u.m)
    y = star_cam.y.to_value(u.m)

    ax.plot(x, y, marker='*', color=f'C{i}')
#     ax.annotate(
#         text=name, xy=(x, y), xytext=(5, 5),
#         textcoords='offset points', color=f'C{i}'
#     )

# plt.show()

Connected to #255

I agree to have this additional Frame: if this is added, I can also add it to the coordinate notebook which I am preparing.
I would also add this frame for LSTCam and the other cameras, since know the plotting of the camera is not realistic. You can compare what I produced in #875 with what an observer should see when really looking at the camera (have a look at https://forge.in2p3.fr/projects/cta_analysis-and-simulations/repository/show/Simulations/MCModelDescription/trunk/reports)

Agreed I would propose to place this frame in between the CameraFrame and the TelescopeFrame, such that the MC can be read into the MCCamera frame, but transformed back to the "real" camera frame if needed.

Fixed by #1085


VIM/Emacs configurations

Is it acceptable to remove the VIM/Emacs configuration strings from the beginning of .py files? I think these settings should probably be set project-wide.

Sure, no problem on my end.


remove run mount point for containerd-based apps

Seems we have problem with our mounts for no-hyper mode.

Containerd adds mount for /run: https://github.com/lf-edge/eve/blob/master/pkg/pillar/vendor/github.com/containerd/containerd/oci/spec.go#L201-L206
Mysql image prepare directories inside /var/run (symlink to /run): https://github.com/docker-library/mysql/blob/c506174eab8ae160f56483e8d72410f8f1e1470f/8.0/Dockerfile.debian#L82-L85
Docker do not do the same (no /run mount inside https://github.com/moby/moby/blob/1430d849a4fe74d601896d4bbb0134e898ef8a76/oci/defaults.go#L34). And just use files as is.
We override /run with tmpfs, so, I see can't create lock file /var/run/mysqld/mysqlx.sock.lock' and halting of app.

Signed-off-by: Petr Fedchenkov<EMAIL_ADDRESS>

docker, even though it uses containerd under the covers, does not use the default Unix spec; it generates its own.
The strange part is that containerd would do a default for /run. Going to dig a bit.

Correct. This is what containerd does by default. It mounts /run as a tmpfs.
The question is, why does this matter? /run normally is tmpfs. Here is a typical Ubuntu running on AWS:
$ df /run
Filesystem     1K-blocks  Used Available Use% Mounted on
tmpfs            1623556  1644   1621912   1% /run

/run is intended to be ephemeral things, only for this invocation of the OS.
Why does having it as a tmpfs mess up mysql?

Seems, mysql expect some files inside /run (as I mentioned in the comment of PR):
docker run -it --rm mysql bash
root@4da5a0782387:/# ls -l /var/run
lrwxrwxrwx 1 root root 4 Oct 11 00:00 /var/run -> /run
root@4da5a0782387:/# ls -l /run
total 0
drwxrwxrwt 1 root  root  0 Oct 11 00:00 lock
drwxrwxrwt 1 mysql mysql 0 Oct 18 21:35 mysqld
-rw-rw-r-- 1 root  utmp  0 Oct 11 00:00 utmp
root@13f2e11c1b42:/# date
Mon Nov  8 17:59:37 UTC 2021

Seems, mysql expect some files inside /run (as I mentioned in the comment of PR):

Sure, but those should be ephemeral: locks and the like. It shouldn't expect anything permanent there.
It should be easy enough to replicate this:
docker run -it --rm -e MYSQL_ROOT_PASSWORD=root --tmpfs /run mysql

will have the same effect.
And it does, indeed, fail.
It looks like the mysql image expects the three directories you highlighted above to exist already in /var/run/. You would have the same problem if you mounted /var/run or /run to anything else. This is not so much "docker vs containerd" as it is, "mysql startup script docker-entrypoint.sh should be ensuring those directories exist before handing it off to mysqld."
The containerd default - that /run is tmpfs - makes a ton of sense, and is what normal distributions do. mysqld is in the wrong here, in my opinion, in insisting that the directories exist because they are in the pre-built image.
The right thing to do here is to open an issue (or better yet, a PR) at the mysql library to ensure it exists. This will solve going forward.
How do we fix existing ones, i.e. that the current (and previous) versions of docker.io/library/mysql can run? I am not sure.

Well, I am not sure that only mysql rely on persistent data inside /run. But I do not know how to find them (I remember finding coverage tests somewhere for a batch of different docker images but can't find them yet).
I can see another approach of coping file into tmpfs mount: https://github.com/opencontainers/runc/pull/845/commits/c7406f707524f1df23d0fa75b8165573ff58ed97

mysql doesn't rely on persistent data in /run; its problem is that it relies on directories already existing when it runs, without validating that they exist first. If the startup script checked, it would be fine.
I rather like the approach of your link: if the underlying image as stuff in/run, copy it over. Still, it should just mkdir, but it doesn't, we need to deal with it.

Opened PR onto mysql: https://github.com/docker-library/mysql/pull/797

Just to add a little context -- in a "normal" system, the init script (or systemd unit via tmpfiles.d) is responsible for creating any necessary directories under /run before starting the service.  When this /run default was added to containerd, I actually argued against it for this very reason: in containers, the Dockerfile is our "pre-start" script to prep directories like /run for use inside a container, but I obviously lost that argument. :sweat_smile:
That being said, we do plan to fix this in at least the MySQL image. :innocent: :+1:

Hey @giggsoff can this be closed now?

Waiting for upstream changes


[BEAM-2469] Handling Kinesis shards splits and merges

Follow this checklist to help us incorporate your contribution quickly and easily:

[X] Make sure there is a JIRA issue filed for the change (usually before you start working on it).  Trivial changes like typos do not require a JIRA issue.  Your pull request should address just this issue, without pulling in other changes.
[X] Each commit in the pull request should have a meaningful subject line and body.
[X] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue.
[X] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[X] Run mvn clean verify to make sure basic checks pass. A more thorough check will be performed on your pull request automatically.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

This pull requests tries to address stream resharding operations described in detail here.

@jkff would you like to review this one? @rtshadow is on holidays till the end of December.

Sorry for the delay. I took a high-level look, understood very little, so I'm going to need some guidance to review this.
Can you give some background on what Kinesis is doing, how this is reflected through the Kinesis API, how the current PR is handling that at a high level, and what parts of that are in what classes?

@jkff I’ll try to describe this in short.
Kinesis stream consists of shards which are the base throughput units. Each shard has a capacity of 1MB/s input and 2MB/s output data. So in order to adjust the required throughput you can control the number of shards the stream has. Data records are segregated and routed to shards based on the partition key specified while putting data into the stream. Partition key is hashed and compared with the range of possible hash key values for the shard.
In order to adjust the number of shards in the stream, you have to split or merge already existing shards. Split operation closes the chosen shard and creates two new shards that together cover the same range of hash keys (you can choose the hash key at splitting point). Merging operation closes two specified adjacent shards and creates a new shard that covers the same hash keys range.
Each shard has following properties:

id
id of it’s parent (or 2 parents if shard is a result of merging 2 other shards)
HashKeyRange - the range of possible hash key values for the shard.
SequenceNumberRange - the range of possible sequence numbers for the shard. Shards that are in the OPEN state have an ending sequence number of null.

So in practice there are 2 situations that need special handling in Kinesis connector. One is at the very beginning, when the connector has to find it’s starting point in Kinesis stream. User can specify starting position by using special descriptors like LATEST, TRIM_HORIZON or by supplying a starting Instant. All these cases are handled by StartingPointShardsFinder class. This class goes over stream shards chronologically and validates them by getting iterator at given starting point and trying to read records. If shard does not pass the validation then it is considered expired and we look for it’s successors. Finally, all valid shards are gathered and used as initial shards.
The second situation that required special handling is the case when reading (in ShardRecordsIterator class) reached the shard’s end. The GetRecords operation will return null value for NextShardIterator property then. This means that we need to stop reading this shard and pick up it’s successor(s). This is handled in ShardReadersPool class in a catch clause where KinesisShardClosedException was caught. Firstly we wait until all records read from expired shards are taken from internal queue. Then in readFromSuccessiveShards method we find shard’s successors and replace old shardIterator with the new one(s). In case of merge operation, two shards have one successor so only one of them will be replaced with it.
It’s not a comprehensive description so please let me know if anything is not clear.


Terraform Lab4: Adding reserved=true for Linux app service plans

Must add reserved=true for Linux app service plans while creating one, reserved defaults to false Reference - https://www.terraform.io/docs/providers/azurerm/r/app_service_plan.html

Created https://github.com/richeney/terraform-lab4/pull/2 for change in lab files. Please merge both together after checking

Thanks!!


Shut-off option

It's possible I've missed some existing way to do this, but I couldn't figure out how using the extension or jupyter lab in general. Basically I'd like to be able to completely turn off autoprofiler and have it clear its memory and not do anything. I'm currently working with very large dataframes and I think autoprofiler is causing a lot of slow down, so I just uninstalled it, but I would have preferred to just shut it down instead if that was possible!

Hey thanks for filing this! Totally agree. Right now AP computes profiles even when the tab is not open so is adding unnecessary overhead, I will look into this soon and hopefully a pretty easy fix because I agree very annoying right now

Hey @mjohnson11 just merged in a fix that should only update the data in AutoProfiler when it is actually open and visible so should not cause slow downs if not visible. It will be included in our next release!

Great, I will plan to redownload it!
On Mon, Apr 17, 2023 at 9:29 AM Will Epperson @.***>
wrote:

Hey @mjohnson11 https://github.com/mjohnson11 just merged in a fix that
should only update the data in AutoProfiler when it is actually open and
visible so should not cause slow downs if not visible. It will be included
in our next release!
—
Reply to this email directly, view it on GitHub
https://github.com/cmudig/AutoProfiler/issues/124#issuecomment-1511704709,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AC6GRS3JZMOZ43W6PZ6C7K3XBVVV3ANCNFSM6AAAAAAWILMI3A
.
You are receiving this because you were mentioned.Message ID:
@.***>


[question] What to use instead of StandardProps?

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Current behavior 😯
StandardProps was deprecated in #22312 but there is no directions in the v5 migration guide on what should be used instead.

Hi.
You can still import it like import { InternalStandardProps as StandardProps } from '@mui/material';
but please note that this is for internal use.

Thank you


Create guide for Exchanges

Fixes #645

@rg911 I think I have addressed all your concerns, except the ones regarding the REST API (which are tracked in https://github.com/nemtech/symbol-docs/issues/645).
Changing this guide to use REST instead of the SDK is going to be a significant effort. How about I do that in another task?
Does this guide look good to you then? You can see the preview here.

@rg911 I'd like to close this one. It's been sitting here for 22 days now.
I think I have addressed all your comments and the rest will be dealt in another guide (#662).

I would put a section for Aggregate / standalone transactions, a brief explanation, and the payload comparison.

I understand the problem of monitoring agg txes, but I thought I already had addressed it:

In the SDK guide, the sample code already uses embedded=true and then checks the type of the returned object (transactionInfo instanceof AggregateTransactionInfo)
In the REST guide there's a whole section called Parsing of embedded transactions about this topic. This section has a table comparing the TransactionMetaDTO and EmbeddedTransactionMetaDTO as you requested.

What else is missing?

I would put a section for Aggregate / standalone transactions, a brief explanation, and the payload comparison.

I understand the problem of monitoring agg txes, but I thought I already had addressed it:

In the SDK guide, the sample code already uses embedded=true and then checks the type of the returned object (transactionInfo instanceof AggregateTransactionInfo)
In the REST guide there's a whole section called Parsing of embedded transactions about this topic. This section has a table comparing the TransactionMetaDTO and EmbeddedTransactionMetaDTO as you requested.

What else is missing?

yeah, saw that, would it be better to add a note in this one to exchange user, e.g. to expect incoming aggregate transactions

I've added the note to the #674 PR, let's continue the discussion there. Having dependent PRs is not comfortable on GitHub.


ERROR in Error: Unexpected value 'AngularSplitModule

We are getting the following error when using angular-split 0.2.7.

ERROR in Error: Unexpected value 'AngularSplitModule in /node_modules/angular-split/dist/angularSplit.module.d.ts' imported by the module 'SharedModule in /src/app/shared/shared.module.ts'. Please add a @NgModule annotation.

If we revert to angular-split 0.2.6 everything works as it should. So our workaround is currently to use the older version, but of course we want to understand why it fails with the latest. I suspect this is the same issue as #70 and that the error message differs just due to us using a different angular version.
We just use a normal import to import it:
import { AngularSplitModule } from 'angular-split';
ng --version gives me the following output:
Node: 6.10.1
OS: win32 x64
Angular: 5.0.1
... animations, common, compiler, compiler-cli, core, forms
... http, platform-browser, platform-browser-dynamic
... platform-server, router

@angular/cli: 1.5.0
@angular/tsc-wrapped: 0.4.2
@angular-devkit/build-optimizer: 0.0.32
@angular-devkit/core: 0.0.20
@angular-devkit/schematics: 0.0.35
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.8.0
@schematics/angular: 0.1.2
typescript: 2.6.1
webpack: 3.8.1```

Please checkout the answer I just did on https://github.com/bertrandg/angular-split/issues/70.
Anyway, if you are using angular 5.x, use latest 1.0.0-beta-9.
Even if it's tagged beta, it's more robust than 0.2.x, you can have a look on preview doc & demo

Thanks! We've set our dependency to ~1.0.0-beta.9 || ^1.0 and now it works fine.


evaluate a reason of non-working OpenCL

on SD 652/Android 7/32
same code working on PC, magickCore build with CL support

IM try to load CL as libOpenCL.so, while default qualcomm implementation is libopencl.so - to check case-sensitive possible issue

libOpenCL load is OK. functions is working well
issue: at opencl.c:2273
number_devices=GetOpenCLDeviceCount(clEnv,platforms[i]); return 0 for existing platform 1;

"OpenCL 2.0 QUALCOMM build: commit #7d18700 changeid #I8ee426a9a2 Date: 10/07/16 Fri Local Branch: my"

IM code required OpenCL 1.0

~opencl.c:2230
if (clEnv->library->clGetDeviceIDs(platform,         CL_DEVICE_TYPE_CPU|CL_DEVICE_TYPE_GPU,0,NULL,&num) != CL_SUCCESS)     return(0);

can't open binary cache file of OpenCL program at `blob.c:354'

remove from 04_qmake_build milestone since a reason of issue is more clear now

OpenCL works with disabled binary cache

reason is clear, need a fix in #20


Can not open CLOB in external editor

System information:

Operating system (distribution) and version: macOS Monterey 12.1
DBeaver version: 21.3.2
Additional extensions: -

Connection specification:

Database name and version: Oracle Database 19c Enterprise Edition Release <IP_ADDRESS>.0 - Production
Driver name: Oracle JDBC driver <IP_ADDRESS>.0
Do you use tunnels or proxies (SSH, SOCKS, etc)? : no tunnels

Describe the problem you're observing:
Exception at "Open in external editor" in MacOs.
Project imported from DBeaver for Windows
Steps to reproduce, if exist:

execute query
click "Open in external editor"
Get an exception

Include any warning/errors/backtraces from the logs

File exception while opening
Failed to open, edit or print /var/folders/9l/wtsf9g5s6md2l1n0bh3xpdkw0000gq/T/dbtmp1653569136757077542.octet-stream. Error code: -10814

The problem is solved by assigning a file assotiation

Hi @Haikson , I still got this issue on DBeaver 22.0.4 when try to open the json field in external editor.
It throws this error
File exception while opening

Reason:
Failed to open, edit or print /var/folders/3f/xl_n65zd0ds32yjk7v9532vc0000gn/T/dbtmp10169212175961119803.octet-stream. Error code: -10814

I also assigned the editor for *.octet-stream type in File Association setting


Compilation failure on android with webpack

Hi, i tried using your plugin with webpack but it fails on android.
To reproduce:
Create a sample app based on default angular template:
Add the webpack plugin + nativescript-contacts-lite + worker loader
Add some codes using the web worker
Run the bundled project
npm run start-android-bundle

Gradle fails at :asbg:generateBindings
Warning: there already is an extend called com.tns.FragmentClass.
Warning: The static binding generator will generate extend from:vendor.js implementation
:asbg:generateBindings
Exception in thread "main" java.io.IOException: File already exists. This may lead to undesired behavior.
Please change the name of one of the extended classes.
File:/Users/mevindhunnooa/Documents/workspace/my-app-name/platforms/android/src/main/java/com/tns/FragmentClass.java Class: com.tns.FragmentClass
        at org.nativescript.staticbindinggenerator.Generator.writeBindings(Generator.java:68)
        at org.nativescript.staticbindinggenerator.Main.main(Main.java:15)
:asbg:generateBindings FAILED

FAILURE: Build failed with an exception.

According to  #778, This occurs because the plugin loads the tns modules which are already in the vendor.ts. I even tried using android@next version but it still fails. Here is a sample project with minimalistic code to reproduce https://github.com/mevinDhun/nativescript-webpack-error-app
Is there any way to fix this?
Thanks

Hi Mevin,
I am traveling until next week, so I am less available to check things. However, I was able to run with webpack last time I checked. Thanks for the demo project, I will get bak to you soon.
Cheers!

@mevinDhun I was able to reproduce with your sample project. However, since this seems to be an issue with the android runtime (see my addition to this issue, I don't think I have anything to change for now.
However, as a work around you can do the following:

use the getContacts function instead of the getContactsWorker
remove these lines from index.js in your node_modules/nativescript-contacts-lite/index.js

Then run npm run start-android-bundle and it will work. I will leave this issue open for now and keep an eye out to see when the issues with web workers will be fixed.

@abhayastudios The getContacts will block the UI and is not suitable for my app. Using webpack is not a must for me right now, hence i can skip it for android. I will wait for 778 to be resolved and then will try to integrate wepack on my android version.
Thanks

@abhayastudios Did you find any solution for getContactsWorker to work on Android ?
According to 778 the issues with web workers was solved.

@alexandruantonica Indeed it is supposed to be released with NS 3.2. I haven't gotten around trying it yet in the @next build. Will update here when I get a chance.

Fixed with NS3.2 and bb9f85a020ca718622cae3ca163c635b5043d7d5


fix: try using replacement approach

https://github.com/getgrit/gritql/issues/416, but unfortunately the comma doesn't appear as an error node.

Done in https://github.com/getgrit/gritql/pull/566