[Feature] Added support to save non-tensor data in tensor class

Description
This is a WIP PR for Issue 145 : [Feature Request] tensorclass with non-tensor data
Made the changes to accommodate the following:

Save non-tensor data
Access tensor class object
Indexing

Types of changes
What types of changes does your code introduce? Remove all that do not apply:

New feature (non-breaking change which adds core functionality)

Checklist
Go over all the following points, and put an x in all the boxes that apply.
If you are unsure about any of these, don't hesitate to ask. We are here to help!

[x] I have read the CONTRIBUTION guide (required)
[x] My change requires a change to the documentation.
[x] I have updated the tests accordingly (required for a bug fix or a new feature).
[x] I have updated the documentation accordingly.

@sreevasthav we have made some important changes to the tensorclass construction. If you need help resolving the conflicts don't hesitate to reach out!

@vmoens  Thanks for letting me know. Is this a functionality change or just code refactoring? Can you share me the issue for this?

@sreevasthav PR is #165. There's no corresponding issue, but the main problem that we needed to fix was making tensorclasses picklable. That meant dropping the locally defined _TensorClass.
No change in functionality, but lots of stuff got moved out of tensorclass decorator into globally defined functions etc. Those functions should broadly correspond to methods on the old _TensorClass.

@vmoens  Can you please review the code? The above code has one limitation with nested use case. I am trying to save the non-tesor data for a nested class using class type since this is the only information available while getting the attributes as we already saved the tensor class to tensor dict.
The issue with the implementation is when the non-tensor data is optional and one of the nested class didn't use the attribute. Since we are saving at the class type level while getting the attributes we don't have this information we fetch the non-tensor data for all the nested class of same type as the same value.
Let me know if you can suggest any other approach to save and extract this correctly

Also I think the lint is not working, check the CONTRIBUTING.md for more info

@vmoens  Thanks for pointing out on setting the attributes in nested use case, I have updated the code and updated the test cases to include the suggestions you pointed out for

the constructor is modified by this PR, let me know if that's a problem for your PRs

It does clash with what we were doing, but it's not clear immediately whether it's a problem. Will have a play around and understand better what you're doing here!

@sreevasthav could you update the doc too?
https://github.com/pytorch-labs/tensordict/blob/main/docs/source/reference/prototype.rst

Codecov Report
Base: 89.87% // Head: 88.03% // Decreases project coverage by -1.85% :warning:

Coverage data is based on head (5e7813f) compared to base (1ae3066).
Patch coverage: 93.79% of modified lines in pull request are covered.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #157      +/-   ##
==========================================
- Coverage   89.87%   88.03%   -1.85%
==========================================
  Files          24       24
  Lines        8116     8397     +281
==========================================
+ Hits         7294     7392      +98
- Misses        822     1005     +183

Flag
Coverage Δ

linux-cpu
85.80% <93.79%> (+0.14%)
:arrow_up:

linux-gpu
87.97% <93.79%> (+0.07%)
:arrow_up:

linux-macos-cpu
85.80% <93.79%> (+0.14%)
:arrow_up:

linux-stable-cpu
85.84% <93.79%> (+0.23%)
:arrow_up:

linux-stable-gpu
87.97% <93.79%> (+0.07%)
:arrow_up:

linux-torchrec-gpu
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

tensordict/prototype/tensorclass.py
88.74% <87.07%> (-4.47%)
:arrow_down:

test/test_tensorclass_nofuture.py
96.30% <97.91%> (-2.87%)
:arrow_down:

test/test_torchrec.py
26.66% <0.00%> (-71.12%)
:arrow_down:

tensordict/utils.py
51.53% <0.00%> (-21.48%)
:arrow_down:

tensordict/tensordict.py
83.44% <0.00%> (-0.18%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

LGTM, just a couple of things: for nested tensorclass, can you clarify the behaviour a bit? Can we add specific tests for that, like
    @tensorclass
    class MyDataNest:
        X: torch.Tensor
        v: str
    @tensorclass
    class MyDataParent:
        W: Any
        X: Tensor
        z: TensorDictBase
        y: MyDataNest
        v: str

    batch_size = [3, 4]
    if any_to_td:
        W = TensorDict({}, batch_size)
    else:
        W = torch.zeros(*batch_size, 1)
    X = torch.ones(3, 4, 5)
    X_clone = X.clone()
    td = TensorDict({}, batch_size)
    td_clone = td.clone()
    data_nest = MyDataNest(X=X, v="x", batch_size=batch_size)
    v = 'test_tensorclass'
    data = MyDataParent(X=X, y=data_nest, z=td, W=W, v=v, batch_size=batch_size)

    assert data.y.v == "x"
    data.y.v = "y"
    assert data.y.v == "y"
    data_nest.v = "x"
    assert data.y.v == "x"

(if that makes sense and it's feasible)

@vmoens  I think the set attribute updates are specific to the object and hence if you change data_nest.v = "x" , data.y.v will still be "y"

@vmoens / @apbard / @vmoens Can you please review the PR again. Changed the most of the test cases to be nested ones so that we can validate nested behavior of all the defined functions

LGTM, just a couple of things: for nested tensorclass, can you clarify the behaviour a bit? Can we add specific tests for that, like
    @tensorclass
    class MyDataNest:
        X: torch.Tensor
        v: str
    @tensorclass
    class MyDataParent:
        W: Any
        X: Tensor
        z: TensorDictBase
        y: MyDataNest
        v: str

    batch_size = [3, 4]
    if any_to_td:
        W = TensorDict({}, batch_size)
    else:
        W = torch.zeros(*batch_size, 1)
    X = torch.ones(3, 4, 5)
    X_clone = X.clone()
    td = TensorDict({}, batch_size)
    td_clone = td.clone()
    data_nest = MyDataNest(X=X, v="x", batch_size=batch_size)
    v = 'test_tensorclass'
    data = MyDataParent(X=X, y=data_nest, z=td, W=W, v=v, batch_size=batch_size)

    assert data.y.v == "x"
    data.y.v = "y"
    assert data.y.v == "y"
    data_nest.v = "x"
    assert data.y.v == "x"

(if that makes sense and it's feasible)

@vmoens I think the set attribute updates are specific to the object and hence if you change data_nest.v = "x" , data.y.v will still be "y"

Please ignore this comment. The behavior  will be as you quoted above

I think None values should allow for pre-allocation, like a missing value can be pre-allocated with TensorDict:
from typing import Any

import torch

from tensordict import TensorDict
from tensordict.prototype import tensorclass

# this works:
s1 = TensorDict({}, [4])
s2 = TensorDict(
    {"X": TensorDict({"X": TensorDict({"X": torch.randn(2)}, [])}, [])}, [])
s1[0] = s2
print(s1)

@tensorclass
class M1:
    X: Any

@tensorclass
class M2:
    X: Any

@tensorclass
class M3:
    X: Any

m1 = M1(M2(M3(X=None, batch_size=[4]), batch_size=[4]), batch_size=[4])
m2 = M1(M2(M3(X=torch.randn(2), batch_size=[]), batch_size=[]), batch_size=[])

print(m1)
print(m2)

# this breaks:
m1[0] = m2
print(m1)

pre-allocation

@vmoens  Here for m1, the X will be stored in _non_tensordict as None and _tensordict will be initialized as an empty TensorDict.
m1.X.X._tensordict: TensorDict(
    fields={
    },
    batch_size=torch.Size([4]),
    device=None,
    is_shared=False)

m1.X.X._non_tensordict: {'X': None}

m1.X.X.X: None

Now if I set m1[0] = m2
m1.X.X._tensordict: TensorDict(
    fields={
        X: Tensor(shape=torch.Size([4, 2]), device=cpu, dtype=torch.float32, is_shared=False)},
    batch_size=torch.Size([4]),
    device=None,
    is_shared=False)
m1.X.X._non_tensordict: {}
m1.X.X.X: tensor([[-1.0844,  0.5641],
        [ 0.0000,  0.0000],
        [ 0.0000,  0.0000],
        [ 0.0000,  0.0000]])

What we are doing in set_item is we set the item in _tensordict and del key-value pair from _non_tensordict to make sure that there won't be duplicate keys saved
Let me know if this is the expected behavior?

Yes that's it!

Yes that's it!

Great ! Will add a test case for pre-allocation

This is a brilliant work, I love it! Thanks for taking care of it.
dispatching logic
Many private tensor-to-tensor methods look the same to me, couldn't we reduce the amount of code by recycling the logic a bit? eg
def _do_smth(tdc, *args, **kwargs):
    tensordict = torch.do_smth(tdc._tensordict, , *args, **kwargs)
    non_tensor_dict = tdc._non_tensordict
    # Cloning nested Tensor classes if any
    for key, value in non_tensor_dict.items():
        if is_tensorclass(value):
            non_tensor_dict[key] = _do_smth(value, , *args, **kwargs)
    out = tdc.from_tensordict(tensordict, non_tensor_dict)
    return out

Wouldn't a wrapper be capable of handling that?
I'm just afraid that if we change the logic some day we'll need to manually go through every function and re-code it.
For the docstrings:
I did not do all the suggestions, I think you got the gist docstrings should look like
    """Fist line without break

    After the first line, an empty line

    Args:
        arg1 (int, optional): something to do with it.
        arg2 (TensorDictBase, optional): notice the empty line before the end.

"""

At the risk of being picky I don't see the advantage of many of these docstrings: they will not appear in the doc because they're private methods and they add little to the understanding of the file (eg the behaviour of _unsqueeze is self-explanatory when looking at the code and it won't appear in the doc). Happy to leave them of course. (in other cases, like _all_td_fields_as_str a docstring, or even simply a comment, are useful).

Added helper functions to handle non_tensor and nested logic for tensor operations. Regarding the documentation, even though "_squeeze" is self explanatory, we handle tensor and non-tensor data differently and I want to add it to that.  I am okay to add comments instead of a docstring. Let me know if you want me to change this

Let me know if you want me to change this

Docstrings are good no worry.
Is there anything outstanding?


add jsdoc linting #441

BTW jsdoc linting is disabled for compiler because we get more then 400 lint Errors wich must be resolved manually.
Therefore i created a new @qooxdoo/eslint-config-jsdoc-disable configuration.
jsdoc linting is switched on for default configuration

Merging, thank you @hkollmann !


Migrate to Androidx?

Hi is it possible for Kronos to move to useing androidx dependencies?
This is one of the only handful of libs that still require me to use jetifier.
* com.lyft.kronos:kronos-android:0.0.1-alpha09
  \-- com.lyft.kronos:kronos-java:0.0.1-alpha09
   \-- com.android.support:support-annotations:28.0.0

0.0.1-alpha10 was shipped without support dependencies, meaning that AndroidX is irrelevant for Kronos at this point.


Release v0.9.3

This updates the installer to deploy Romana v0.9.3.

Kubernetes test results:
2016-09-05 09:18:56 (ip-192-168-99-10:clustertests) Test #1: Check that Kubernetes services are running on master : PASSED
2016-09-05 09:18:57 (ip-192-168-99-10:clustertests) Test #2: Check that Romana services are running on master : PASSED
2016-09-05 09:18:58 (ip-192-168-99-10:clustertests) Test #3: Check that Kubernetes services are running on minion : PASSED
2016-09-05 09:18:59 (ip-192-168-99-10:clustertests) Test #4: Check that Romana services are running on minion : PASSED
2016-09-05 09:19:00 (ip-192-168-99-10:clustertests) Test #6: Pull docker containers used in later tests : PASSED
2016-09-05 09:19:18 (ip-192-168-99-10:clustertests) Test #8: Check namespace creation triggers romana tenant creation : PASSED
2016-09-05 09:19:19 (ip-192-168-99-10:clustertests) Test #7: Check that kubernetes can launch some pods : PASSED
2016-09-05 09:19:34 (ip-192-168-99-10:clustertests) Test #9: End-to-End test checking default-allow, isolation and policy-allow : PASSED
2016-09-05 09:18:58 (ip-192-168-99-11:clustertests) Test #3: Check that Kubernetes services are running on minion : PASSED
2016-09-05 09:18:59 (ip-192-168-99-11:clustertests) Test #4: Check that Romana services are running on minion : PASSED
2016-09-05 09:19:00 (ip-192-168-99-11:clustertests) Test #6: Pull docker containers used in later tests : PASSED

Demo script: passed.

Devstack test results:
2016-09-05 09:35:33 (ip-192-168-99-10:clustertests) Test #1: Check that openstack services are present : PASSED
2016-09-05 09:35:38 (ip-192-168-99-10:clustertests) Test #2: Check that Romana services are running on controller node : PASSED
2016-09-05 09:35:39 (ip-192-168-99-10:clustertests) Test #3: Check that Romana services are running on compute nodes : PASSED
2016-09-05 09:35:41 (ip-192-168-99-10:clustertests) Test #4: Check that VMs can be created on each compute node : PASSED
2016-09-05 09:36:00 (ip-192-168-99-10:clustertests) Test #5: End-to-End test checking ping and SSH for VMs in same segment. : PASSED
2016-09-05 09:35:39 (ip-192-168-99-11:clustertests) Test #3: Check that Romana services are running on compute nodes : PASSED

Looks ok. Does it work? :-)

Retest.
Kubernetes test result:
2016-09-08 05:47:34 (ip-192-168-99-10:clustertests) Test #1: Check that Kubernetes services are running on master : PASSED
2016-09-08 05:47:35 (ip-192-168-99-10:clustertests) Test #2: Check that Romana services are running on master : PASSED
2016-09-08 05:47:36 (ip-192-168-99-10:clustertests) Test #3: Check that Kubernetes services are running on minion : PASSED
2016-09-08 05:47:37 (ip-192-168-99-10:clustertests) Test #4: Check that Romana services are running on minion : PASSED
2016-09-08 05:47:38 (ip-192-168-99-10:clustertests) Test #6: Pull docker containers used in later tests : PASSED
2016-09-08 05:47:58 (ip-192-168-99-10:clustertests) Test #8: Check namespace creation triggers romana tenant creation : PASSED
2016-09-08 05:47:59 (ip-192-168-99-10:clustertests) Test #7: Check that kubernetes can launch some pods : PASSED
2016-09-08 05:48:12 (ip-192-168-99-10:clustertests) Test #9: End-to-End test checking default-allow, isolation and policy-allow : PASSED
2016-09-08 05:47:37 (ip-192-168-99-11:clustertests) Test #3: Check that Kubernetes services are running on minion : PASSED
2016-09-08 05:47:37 (ip-192-168-99-11:clustertests) Test #4: Check that Romana services are running on minion : PASSED
2016-09-08 05:47:38 (ip-192-168-99-11:clustertests) Test #6: Pull docker containers used in later tests : PASSED
Devstack test result:
2016-09-08 05:51:59 (ip-192-168-99-10:clustertests) Test #1: Check that openstack services are present : PASSED
2016-09-08 05:52:03 (ip-192-168-99-10:clustertests) Test #2: Check that Romana services are running on controller node : PASSED
2016-09-08 05:52:05 (ip-192-168-99-10:clustertests) Test #3: Check that Romana services are running on compute nodes : PASSED
2016-09-08 05:52:06 (ip-192-168-99-10:clustertests) Test #4: Check that VMs can be created on each compute node : PASSED
2016-09-08 05:52:26 (ip-192-168-99-10:clustertests) Test #5: End-to-End test checking ping and SSH for VMs in same segment. : PASSED
2016-09-08 05:52:05 (ip-192-168-99-11:clustertests) Test #3: Check that Romana services are running on compute nodes : PASSED


Import without asterisk

Is there any way to import npm modules without using the ES6 asterisk import and without using import fs = require("fs") ?
Example:
import * as fs from "fs"
I'd like to write:
import fs from "fs"
like with local project files.

Maybe set allowSyntheticDefaultImports is that you need.

These type of questions should be asked on StackOverflow or Gitter.

@j-oliveras allowSyntheticDefaultImports  will use ES6 export.default for every import I use, and not all of npm modules uses ES6 export.default

@kitsonk I really don't think that someone will answer this on SO

@Syderr93 Then, maybe, this is a duplicated of #16093.


Fix depcheck in CI

Fix depcheck
We're disabling depcheck in https://github.com/opencollective/opencollective-frontend/pull/9975 as it gives a seemingly unrelated error:

<EMAIL_ADDRESS>depcheck
npx depcheck

Next.js webpack configuration detection failed with the following error TypeError: Cannot read properties of undefined (reading 'distDir')
at getWebpackPluginOptions (/home/runner/work/opencollective-frontend/opencollective-frontend/node_modules/@sentry/nextjs/cjs/config/webpack.js:692:66)
at Object.newWebpackFunction [as webpack] (/home/runner/work/opencollective-frontend/opencollective-frontend/node_modules/@sentry/nextjs/cjs/config/webpack.js:381:15)
at loadNextWebpackConfig (/home/runner/.npm/_npx/d2bd3cb5801d0b99/node_modules/depcheck/dist/special/webpack.js:129:25)
at async parseWebpack (/home/runner/.npm/_npx/d2bd3cb5801d0b99/node_modules/depcheck/dist/special/webpack.js:152:27)
at async getDependencies (/home/runner/.npm/_npx/d2bd3cb5801d0b99/node_modules/depcheck/dist/check.js:119:18) Support for this feature is new and experimental, please report issues at https://github.com/depcheck/depcheck/issues
Unused devDependencies

file-loader
html-loader
markdown-loader
raw-loader
url-loader

https://github.com/depcheck/depcheck/pull/879

Fixed with a fork of depcheck in https://github.com/opencollective/opencollective-frontend/pull/10068


solved your placement issue

Should you need something else feel free to ask will be glad to help!

I really like this solution. Very elegant! Thank you for helping on this.


Fix typo

Related issues
No issues
Short description and why it's useful
This typo caused an issue with header -> https://www.dropbox.com/s/a1o1x8p43spi2nh/Screenshot 2018-09-27 09.26.48.png?dl=0
Screenshots of visual changes before/after (if there are any)
No screenshots
Screenshot of passed e2e tests (if you are using our standard setup as a backend)
No screenshots
Upgrade Notes and Changelog

[x] No upgrade steps required (100% backward compatibility)
[ ] I've updated the Upgrade notes and Changelog on how to port existing VS sites with this new feature

Contribution and curently important rules acceptance

[x] I read and followed contribution rules
[x] I read the TypeScript Action Plan and adjusted my PR according to it
[x] I read about Vue Storefront Modules and refactoring plan for them

Thanks!


Populate query from last time picker was opened

I just switched from CtrlP which I used for years, but there's one feature I miss very much. Sometimes I accidentally choose the wrong result and would be cool when this happens to be able to open picker again and prepopulate it with what I typed last time (like when I hit <C-P> second time when CtrlP is open) instead of typing it all again.
Anyway, great plugin, thanks for it 👏

I'm afraid this isn't something I want to add to vim-picker itself, as I want to keep the implementation and usage simple and intuitive (this means that ctrlp.vim or fzf.vim are better choices for some users, which is fine!). It also might not be possible to achieve with a plugin that uses an external selector, as fzy and similar print out the selected item but not the text the user entered to select it (which for example might be an arbritrary, non-contiguous substring of the selected item).

No worries, thanks for the response.


[HOLD for payment 2023-05-02] [HOLD for payment 2023-04-28] Chat - App crashes upon opening https://staging.new.expensify.com/r/2660055103772983

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Issue found when executing PR https://github.com/Expensify/App/pull/17527
Action Performed:

Go https://staging.new.expensify.com/
and login
Send yourself a message with link https://staging.new.expensify.com/r/2660055103772983
Click the link

Expected Result:
Public room should be open
Actual Result:
App crashes
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

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

Version Number: <IP_ADDRESS>
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://user-images.githubusercontent.com/93399543/233671732-9d3a7a03-7dfd-433e-834c-4e6b28a63a63.mp4
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
View all open jobs on GitHub

Triggered auto assignment to @sophiepintoraetz (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

Bug0 Triage Checklist (Main S/O)

[ ] This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
[ ] This bug is not a duplicate report (check E/App issues and #expensify-bugs)

If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead

[ ] This bug is reproducible using the reproduction steps in the OP. S/O

If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
If the reproduction steps aren't clear and you determine the correct steps, please update the OP.

[ ] This issue is filled out as thoroughly and clearly as possible

Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.

[ ] I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

Found when executing #17527

@mvtglobally This has been fixed here https://github.com/Expensify/App/pull/17792 already and has been merged and deployed to staging! Could you retest it? Thank you!

This is fixed, thank you Rocio!

Reviewing label has been removed, please complete the "BugZero Checklist".

The solution for this issue has been :rocket: deployed to production :rocket: in version 1.3.3-2 and is now subject to a 7-day regression period :calendar:. Here is the list of pull requests that resolve this issue:

https://github.com/Expensify/App/pull/17792

If no regressions arise, payment will be issued on 2023-04-28. :confetti_ball:
After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.

[ ] External issue reporter
[ ] Contributor that fixed the issue
[ ] Contributor+ that helped on the issue and/or PR

As a reminder, here are the bonuses/penalties that should be applied for any External issue:

Merged PR within 3 business days of assignment - 50% bonus
Merged PR more than 9 business days after assignment - 50% penalty

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

[ ] [@pecanoro] The PR that introduced the bug has been identified. Link to the PR:
[ ] [@pecanoro] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
[ ] [@pecanoro] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
[ ] [] Determine if we should create a regression test for this bug.
[ ] [@pecanoro] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
[ ] [] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

No need to pay anyone! Also, this bug can only be caught once the code has been built. To avoid any future problems we might add this linter rule: https://denar90.github.io/eslint.github.io/docs/rules/no-invalid-this

The solution for this issue has been :rocket: deployed to production :rocket: in version 1.3.4-0 and is now subject to a 7-day regression period :calendar:. Here is the list of pull requests that resolve this issue:

https://github.com/Expensify/App/pull/17792

If no regressions arise, payment will be issued on 2023-05-02. :confetti_ball:
After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.

[ ] External issue reporter
[ ] Contributor that fixed the issue
[ ] Contributor+ that helped on the issue and/or PR

As a reminder, here are the bonuses/penalties that should be applied for any External issue:

Merged PR within 3 business days of assignment - 50% bonus
Merged PR more than 9 business days after assignment - 50% penalty

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

[ ] [@pecanoro] The PR that introduced the bug has been identified. Link to the PR:
[ ] [@pecanoro] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
[ ] [@pecanoro] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
[ ] [] Determine if we should create a regression test for this bug.
[ ] [@pecanoro] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
[ ] [] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:


Issue 39091 - use waitForCollectionCallback

Details

Fixed Issues

$
PROPOSAL:
Tests

[ ] Verify that no errors appear in the JS console

Offline tests

QA Steps

[ ] Verify that no errors appear in the JS console

PR Author Checklist

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

[ ] I added steps for local testing in the Tests section
[ ] I added steps for the expected offline behavior in the Offline steps section
[ ] I added steps for Staging and/or Production testing in the QA steps section
[ ] I added steps to cover 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 tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

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

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] 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 followed proper code patterns (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 the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] 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 is localized by adding it to src/languages/* files and using the translation method

[ ] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[ ] 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 followed the guidelines as stated in the Review Guidelines
[ ] 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)
[ ] 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
[ ] I verified that if a function's arguments changed that all usages have also been updated correctly
[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] 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(theme.componentBG))

[ ] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[ ] 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.
[ ] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[ ] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[ ] I verified that all the inputs inside a form are aligned with each other.
[ ] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

@tgolen @shahinyan11 I won't be able to continue this PR for another 9 hours. Feel free to leave a review and I'll run through the checklist when I'm back.

I agree. I’ll have the PR ready for a formal review this evening.
On Tue, Apr 16, 2024 at 9:06 AM Tim Golen @.***> wrote:

@.**** requested changes on this pull request.
In src/libs/ReportUtils.ts
https://github.com/Expensify/App/pull/40233#discussion_r1567424048:

         return;

     }

   const reportID = CollectionUtils.extractCollectionItemID(key);

   reportActionsByReport[reportID] = actions;

   reportActionsByReport = Object.fromEntries(Object.entries(actions).map(([key, value]) => [CollectionUtils.extractCollectionItemID(key as `reportActions_${string}`), value]));

[${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${reportID}] is the most common
pattern used in the code. Looking at IOU.ts for example and the allReports
object. All of the references look like:
iouReport = allReports?.[${ONYXKEYS.COLLECTION.REPORT}${chatReport.iouReportID}] ?? null;
I'm not able to find any waitForCollectionCallback: true instance that is
using a map(). I think that's what allows for a performance gain. Since
the code currently in this PR replaces n callbacks with a map that does n
invocations, there really isn't any performance gain.
—
Reply to this email directly, view it on GitHub
https://github.com/Expensify/App/pull/40233#pullrequestreview-2003754066,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AL7TPLKTHEODJQXQF3D2ENLY5UV7XAVCNFSM6AAAAABGHHFVXSVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDAMBTG42TIMBWGY
.
You are receiving this because you authored the thread.Message ID:
@.***>

: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.

🚀 Deployed to staging by https://github.com/tgolen in version: 1.4.63-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Ability to configure SSL certificates for LDAPS

In testing this my connection is failing, but I can connect with ldapsearch to my ldapserver.  However, ldapsearch does report that it doesn't like the certificate because the root CA is untrusted.  My speculation is that this might be happening under the hood, and it is just bubbling up to the top as a connection failure?

On further guess/investigation, it appears that the underlying erlang ldap library simply uses openldap, and /etc/openldap/ldap.conf is supported.  I'll configure things from there, but it might be good to note this somewhere in the docs.

Are you sure ? By reading the eldap source code, it seems to me that it is a full implementation of the LDAP protocol (and uses erlang's ssl module for connection and certificate validation)
Have you managed to fix your issue by modifying the ldap.conf file ?

Yes, I can verify the problem is resolved by hardwiring the certificate in ldap.conf and/or for debugging also just disabling certificate verification (TLS_REQCERT ALLOW).

I'm still a bit confused about the ldap.conf fix, but I still added the :sslopts from which you can specify a certificate to pass to Erlang's :ssl module


HIVE-26248: Add data connector authorization on HMS server-side(addendum)

What changes were proposed in this pull request?

Why are the changes needed?

Please see comment: https://github.com/apache/hive/pull/3312#discussion_r950617222
Does this PR introduce any user-facing change?

No
How was this patch tested?

cc @saihemanth-cloudera @nrg4878


Add commenting to frontend

Explain the details for making this change. What existing problem does the pull request solve?
Adds the necessary components and UI for implementing a comment system.
Components added:

Comment
CommentForm
PostComments

Components updated:

PostItem (added PostComments parent component to it)

Test plan (required)
Ran the code with mock data and tested if the event handlers were being properly called.

Code formatting
Fixed with Prettier

@JosephSemrai lets for now do it only for PostDetailView page. We can add other features later.


Broken links in Processing Unhandled Exceptions page

The document Processing Unhandled Exceptions has two links at the top, "Download Code or Download PDF", both of which are broken.
This affects both CS and VB versions.

I'll see if I can track the resources down and fix the links this evening.


Some changes leading up to 2.0.0 release

Is your plan to add support for Scala 2.13 too?

Is your plan to add support for Scala 2.13 too?

yep!  But our slack client hasn't accepted my Scala 2.13 patch after 7 months, so we need to replace it first.  That's https://github.com/SumoLogic/shellbase/pull/57


fix edit-config & get-config failed for leafref to decimal64

as the code, only decimal64 need get some information(fraction-digits) from schema when converting between sr_val_t* and char*. when type is leafref, you must get fraction-digits from the target of leafref.

I review the code, it seems LY_TYPE_BITS also need consider leafref and I push a new commit for it.

Seems still not enough - going through leafrefs, you can get into union type. It seems that having a libyang function to get correct type definition would be fine. I'll try to create something.

lyd_leaf_type() from the current libyang devel (0.11.32) should fit the needs for bits. In case of decimal64, the fraction-digits is not actually needed at all.
If you are fine with that, I will fix it on my own.

yes, it's better to fix it in libyang, thanks.


deps: alternative update of node-gyp for electron (v5 & v6), windows

node-pre-gyp seems to be falling back to node-gyp which is installed in:
C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\bin\node-gyp.js

Including node-gyp into the package does not help, neither does installing it globally with the -g flag.

The updated version however is present at
C:\Users\appveyor\AppData\Roaming\npm\node-gyp -> C:\Users\appveyor\AppData\Roaming\npm\node_modules\node-gyp\bin\node-gyp.js```

@bruce-one It's a long shot, but I could use someone to take a look at this because it's driving me crazy. This should be a simple batch change yet I can't get it right.

Well, apparently it's fixed now. Will release soon!

Awesome!
Sorry I wasn't able to offer any help...


initialize_with ignores last variable if it comes after hash

When trying to call create with a new factory, and pass in a trait containing a separate initialization, it ignores the passed in values. It could be that I'm misunderstanding the inheritance aspect of traits or I'm setting up wrong, since I'm not working within a Rails app. But it's not passing through the correct arguments to the constructor.
Here's an example of the code needed to create the problem.
# lib/some_class.rb

class SomeClass < AnotherClass
  def initialize(options = {}, do_the_thing = true)
    @option1 = options[:one] || 'Some Value'
    super(options) if do_the_thing
  end
end

# spec/factories/some_class.rb

FactoryGirl.define do
  factory :the_class, class: SomeClass do
    skip_create

    trait :with_defaults do
      initialize_with { new }
    end

    trait :skip_superclass do
      initialize_with { new({}, false) }
    end
  end
end

# spec/mylib/some_class_spec.rb

describe SomeClass do
  subject { create(:the_class, :with_defaults) }

  describe '.new' do
    context 'when initialized with nothing' do
      # do_the_thing == true
      it 'should do thing.'
    end

    context 'when initialized without triggering parent class' do
      it 'should not do thing.' do
        subject { create(:the_class, :skip_superclass) }
        # do_the_thing == true, but it should be false
        expect(subject.parent_class_value).to eq nil
      end
    end
  end
end

Thanks.

I'm not able to reproduce this locally. The bug may we in Another Class, not shown here.

Closing for now. Feel free to reopen if you can provide the full implementation of AnotherClass so I can reproduce the behavior you describe. Thanks!


Fix License Holder Detail

I just wanted to make you aware that your name and license year are not properly set which makes it harder to make sure we are correctly attributing your work.
https://github.com/areebbeigh/chato/blob/7fe55dd374e40fd64b6a792a37966ec22009943b/LICENSE#L189

Hey, thanks. Totally missed it.


Create Jenkinsfile

Enables CI for the plugin

Most likely it will fail. The plugin uses ancient parent POM

@kmadel

The code is merged but i can't install the plugin to use Configuration-as-code. How can i do that ? Specify the artifact url directly from https://ci.jenkins.io/job/Plugins/job/slack-plugin/job/master/10/artifact/target/slack.hpi ?

in advanced you can upload from a local file,
so download the hpi file from the link go to advanced in plugin centre and upload it there
and restart jenkins if you had an older version installed

Thanks for your input. I added that in my docker image. When is the plugin gonna be released ? Last release was more than a year ago (august 2017)

Pending this PR I think:
https://github.com/jenkinsci/slack-plugin/pull/406
Maybe more, @kmadel ?


can i import my private repo in bolt?

Describe the bug
i created a repo with bolt, then pushed it to my github but i can't import it back into bolt
Link to the Bolt URL that caused the error
https://bolt.new/~/github.com/ruslanshchuchkin/app-branch-gpt
Steps to reproduce
Start the repo in bolt, open it in stackblitz, connect it to your github, push to github, can't open it back tho
Expected behavior
for bolt to open my repo
Screen Recording / Screenshot
No response
Platform
Browser name = Chrome
Full version = <IP_ADDRESS>
Major version = 128
navigator.appName = Netscape
navigator.userAgent = Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36
performance.memory = {
  "totalJSHeapSize": 50577475,
  "usedJSHeapSize": 49106939,
  "jsHeapSizeLimit":<PHONE_NUMBER>
}
Username = ruslanshchuchkin
Chat ID = c2a6b94d01e6

Additional context
Error:
An unknown error occured while running an action.

Not currently supported BUT private StackBlitz.com projects ARE supported as a workaround in the meantime!


Update code example in README.md

The example was not representative of the current API.

This example is representative of the upcoming 0.20 api, however I do understand the confusion, so I'll merge this now and revert it before release. Thanks.

Ah I understand my troubles now. No need to keep this in then, it might be confusing for those building from git now :wink:

@wschella Is this non-confusing? https://github.com/tomaka/glutin/blob/068fb05f3f195358c0e0a1de0a494448bd37738f/README.md

@ZeGentzy Ah yes!


Agenda view provides weird date ranges on onRangeChange

Check that this is really a bug

[X] I confirm

Reproduction link
https://codesandbox.io/p/sandbox/react-big-calendar-example-forked-75tgxp
Bug description
It produces random start & end dates on the onRangeChange in the agenda view. It goes from the first day to last day of the month for both start & end. This happens randomly, it is unwanted and useless.
Expected Behavior
I expected to get first day of the month in start and last day of the month in end. There's also should be a way to control this as some use cases may require today to the last day of the month. or 30 days from today
Actual Behavior
No response
react-big-calendar version
1.16.3
React version
18.3.1
Platform/Target and Browser Versions
Ubuntu24.04/ Chrome 131.0.6778.85 (Official Build) (64-bit)
Validations

[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
[X] Make sure this is a react-big-calendar issue and not an implementation issue

Would you like to open a PR for this bug?

[ ] I'm willing to open a PR

@apuatcfbd I think I have created an example that does what you're looking for:
codesandbox link where the start and end date within the agenda view are clamped to a month.
To clarify some of the changes I made here, I'm now controlling the currentDate passed in via date={currentDate} and onNavigate for handling when this changes.
The other more challenging piece to find within the docs is the length prop this

Determines the end date from date prop in the agenda view date prop + length (in number of days) = end date.

const App = () => {
  const [currentDate, setCurrentDate] = useState();

  const handleRangeChange = (range, view) => {
    if (!("start" in range)) return;
    const startDate = moment(range.start).startOf("month").toDate();
    setCurrentDate(startDate);
  };

  return (
      <Calendar
        date={currentDate}
        length={moment(currentDate).daysInMonth()}
        onRangeChange={handleRangeChange}
        onNavigate={(e) => setCurrentDate(e)}
      />
  );
};

@apuatcfbd I'm not sure I'm seeing the same issue that you are, here is a screen capture of me clicking the next button > 10 times.
The start date stays at the first of the month the entire time and the next button continues to work. This video was recorded on this codesandbox which is a fork of the one you provided so our react-big-calendar's version should be the same. It is set at "latest" in the package.json.
I am wondering if our differing experiences with the back and next button are related to us being in different timezones 🤷

Your codesandbox agenda navigation seems to be functioning as expected. Unless specified; The next and back buttons will add or subtract the length prop in days as handled by the chosen localizer. This defaults to 30 source code here.
Agenda.navigate = (
  date,
  action,
  { length = DEFAULT_LENGTH, localizer }
) => {
  switch (action) {
    case navigate.PREVIOUS:
      return localizer.add(date, -length, 'day')

    case navigate.NEXT:
      return localizer.add(date, length, 'day')

    default:
      return date
  }
}

It seems like you want non-default behavior from the agenda view which requires a non-uniform length prop because months have different lengths.


Update setup script to deploy the test-resources ARM template instead…

… of directly using CLI commands

Sorry to bother again but commit message update please :)


stdenv: implement most of #33599

Motivation for this change
See #39463. This is from the same patchset that implements #33599. This subpatchset implements the main feature needed to implement #33599: checkTarget autodetection.
Note that this is independent from #39463 because this does not set doCheck to true by default.
Also note that applying this to master changes nothing (except it causes a mass-rebuild). This makes #33599 trivial to implement, however.
This now has everything you need to have #33599. Just set config.doCheckByDefault = true and behold how many more failed tests there are. I will PR a huge bunch of fixes for those bugs later (after I rebuild everything myself on top of this version).
Things done

[X] When combined with other patches in the series the system builds.
[X] Fits CONTRIBUTING.md.

Success on x86_64-linux (full log)
Attempted: stdenv
Partial log (click to expand)
shrinking /nix/store/6xnnwblimc9pdwllz119k54npqgl8hv5-findutils-4.6.0/libexec/code
shrinking /nix/store/6xnnwblimc9pdwllz119k54npqgl8hv5-findutils-4.6.0/libexec/bigram
gzipping man pages under /nix/store/6xnnwblimc9pdwllz119k54npqgl8hv5-findutils-4.6.0/share/man/
strip is /nix/store/d1prcspbh2qsviipvnaxizcj8l3g7fpw-bootstrap-tools/bin/strip
stripping (with command strip and flags -S) in /nix/store/6xnnwblimc9pdwllz119k54npqgl8hv5-findutils-4.6.0/libexec  /nix/store/6xnnwblimc9pdwllz119k54npqgl8hv5-findutils-4.6.0/bin
checking for references to /build in /nix/store/6xnnwblimc9pdwllz119k54npqgl8hv5-findutils-4.6.0...
shrinking RPATHs of ELF executables and libraries in /nix/store/slrm1xv0sb8wyqr60rnxwy8mar0w2fmb-findutils-4.6.0-info
strip is /nix/store/d1prcspbh2qsviipvnaxizcj8l3g7fpw-bootstrap-tools/bin/strip
checking for references to /build in /nix/store/slrm1xv0sb8wyqr60rnxwy8mar0w2fmb-findutils-4.6.0-info...
building '/nix/store/2kn3am97iq2r4jhmxwasgz14sdhv3vh4-stdenv-linux.drv'...

Success on aarch64-linux (full log)
Attempted: stdenv
Partial log (click to expand)
shrinking /nix/store/l380pczq5y1l4rbairiq8x3s6cfc3php-findutils-4.6.0/bin/find
gzipping man pages under /nix/store/l380pczq5y1l4rbairiq8x3s6cfc3php-findutils-4.6.0/share/man/
strip is /nix/store/gfgczbs0cy0blibb0acv39cayq7qbplg-bootstrap-tools/bin/strip
stripping (with command strip and flags -S) in /nix/store/l380pczq5y1l4rbairiq8x3s6cfc3php-findutils-4.6.0/libexec  /nix/store/l380pczq5y1l4rbairiq8x3s6cfc3php-findutils-4.6.0/bin
checking for references to /build in /nix/store/l380pczq5y1l4rbairiq8x3s6cfc3php-findutils-4.6.0...
shrinking RPATHs of ELF executables and libraries in /nix/store/5ikaxdddw47vpxfc766g0gydhqc9d2p6-findutils-4.6.0-info
strip is /nix/store/gfgczbs0cy0blibb0acv39cayq7qbplg-bootstrap-tools/bin/strip
checking for references to /build in /nix/store/5ikaxdddw47vpxfc766g0gydhqc9d2p6-findutils-4.6.0-info...
building '/nix/store/hs5i64d6gq40l2fwlcwvwwbd504jqfaw-stdenv-linux.drv'...
/nix/store/y8yzlxjada4rh72wb9ggiibaqqh0b5qv-stdenv-linux

Since #39463 got merged I pushed the rest of the infrastructure here. Feel free to play with this.

Do I understand correctly that for Python packages it unconditionally changes the default to true?

Given «nobody» reads the afterglow of merged PRs:
@Ekleog @Profpatsch @shlevy @grahamc

I generally like it, but will try to read it again.

Failure on aarch64-linux (full log)
Attempted: stdenv
Partial log (click to expand)
cannot build derivation '/nix/store/gqj4f3ndvqkf5b742akvph2k95xsvikw-gnutar-1.30.drv': 2 dependencies couldn't be built
cannot build derivation '/nix/store/195ry64n1q9y7ycxih8mqp2d0bnndddw-lzip-1.20.drv': 2 dependencies couldn't be built
cannot build derivation '/nix/store/krwgh8xv2v8f0w0yqs9x1jp8v83cbp0r-binutils-wrapper-2.30.drv': 4 dependencies couldn't be built
cannot build derivation '/nix/store/4qzxj0cr9c1fl3hz8gml9zz9kdbjfh3n-diffutils-3.6.drv': 3 dependencies couldn't be built
cannot build derivation '/nix/store/2n4750yd7fvy2akybvi80ai9vi74p2sf-ed-1.14.2.drv': 2 dependencies couldn't be built
cannot build derivation '/nix/store/0al95qv0i3w7br6h93kjd19jqh7vjlg3-findutils-4.6.0.drv': 2 dependencies couldn't be built
cannot build derivation '/nix/store/qddq5p0j1b7a7smbmsl3lmy655azq36q-gcc-wrapper-7.3.0.drv': 5 dependencies couldn't be built
cannot build derivation '/nix/store/5l59kccx3q9yd0g47vw1srydlwhxiyvr-patch-2.7.6.drv': 2 dependencies couldn't be built
cannot build derivation '/nix/store/pg7629bbv8h9nr3ygy3ysi3v2d6770i7-stdenv-linux.drv': 25 dependencies couldn't be built
error: build of '/nix/store/pg7629bbv8h9nr3ygy3ysi3v2d6770i7-stdenv-linux.drv' failed

All nitpicks fixed.
@7c6f434c @Ekleog the python change didn't really matter because builder-specific python builders (like for setup.py, wheel, etc) explicitly set doCheck and most packages use those, but I agree that it looks violent. Let's change it later.

This doesn't close 33599 since we still do cross specific things though, right?

Right. Changed the title.

Success on aarch64-linux (full log)
Attempted: stdenv
Partial log (click to expand)
/nix/store/l6gqww4gk0g72ah025pvgzj8xj4h75ia-stdenv-linux

Success on aarch64-linux (full log)
Attempted: stdenv
Partial log (click to expand)
/nix/store/l6gqww4gk0g72ah025pvgzj8xj4h75ia-stdenv-linux

Success on x86_64-linux (full log)
Attempted: hello
Partial log (click to expand)
make[1]: Leaving directory '/build/hello-2.10'
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/dq8mgw310ysassv8h94gd4jfsd0yj01c-hello-2.10
shrinking /nix/store/dq8mgw310ysassv8h94gd4jfsd0yj01c-hello-2.10/bin/hello
gzipping man pages under /nix/store/dq8mgw310ysassv8h94gd4jfsd0yj01c-hello-2.10/share/man/
strip is /nix/store/6b33m5sgzbcj4rbsk2iipd4np13a2wml-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/dq8mgw310ysassv8h94gd4jfsd0yj01c-hello-2.10/bin
patching script interpreter paths in /nix/store/dq8mgw310ysassv8h94gd4jfsd0yj01c-hello-2.10
checking for references to /build in /nix/store/dq8mgw310ysassv8h94gd4jfsd0yj01c-hello-2.10...
/nix/store/dq8mgw310ysassv8h94gd4jfsd0yj01c-hello-2.10

@Ericson2314 do you thing the current state is ok? If yes then I will squash the last patch into the previous ones and it should be ready.

Rebase done.

Success on aarch64-linux (full log)
Attempted: stdenv
Partial log (click to expand)
/nix/store/l6gqww4gk0g72ah025pvgzj8xj4h75ia-stdenv-linux

Success on x86_64-linux (full log)
Attempted: stdenv
Partial log (click to expand)
stripping (with command strip and flags -S) in /nix/store/waw47w7ar0xkj7s7r27frqxk0igb6q56-binutils-2.30/bin
checking for references to /build in /nix/store/waw47w7ar0xkj7s7r27frqxk0igb6q56-binutils-2.30...
shrinking RPATHs of ELF executables and libraries in /nix/store/i312ym69ljwchszigiihprgc3cpn0nh9-binutils-2.30-info
strip is /nix/store/d1prcspbh2qsviipvnaxizcj8l3g7fpw-bootstrap-tools/bin/strip
checking for references to /build in /nix/store/i312ym69ljwchszigiihprgc3cpn0nh9-binutils-2.30-info...
shrinking RPATHs of ELF executables and libraries in /nix/store/xj5gn1ilip82kz9y6iplqp3kn425hhcg-binutils-2.30-man
gzipping man pages under /nix/store/xj5gn1ilip82kz9y6iplqp3kn425hhcg-binutils-2.30-man/share/man/
strip is /nix/store/d1prcspbh2qsviipvnaxizcj8l3g7fpw-bootstrap-tools/bin/strip
checking for references to /build in /nix/store/xj5gn1ilip82kz9y6iplqp3kn425hhcg-binutils-2.30-man...
/nix/store/zpz5va07y02f6wnjls61mqkz4apr4ll8-stdenv-linux

Success on x86_64-linux (full log)
Attempted: stdenv
Partial log (click to expand)
  /nix/store/5z3nj2r1l7fkdinvb0kgqq6jpvl5wh5h-binutils-2.30.drv
  /nix/store/fhh73fyf1mf7rlycy1gmc5rssw35rgz0-diffutils-3.6.drv
  /nix/store/v3d0gyd3kdzw9wa3h7xzlzysrxb5cfrf-binutils-wrapper-2.30.drv
  /nix/store/hixf6xzc993b70xwf6vv1fvld48yy68i-gcc-wrapper-7.3.0.drv
  /nix/store/q7vsy0ykx12h8q1jfsvp4jwhfmy1l8rk-lzip-1.20.drv
  /nix/store/m5mxhwfxlic8qn53qbfkq2823xrlp2j7-ed-1.14.2.drv
  /nix/store/j170v41m13c25hxcrini1131lar9sqwd-patch-2.7.6.drv
  /nix/store/jbc443g8s87x6rvadw7li18ayk53gc5w-stdenv-linux.drv
waiting for locks or build slots...
/nix/store/zpz5va07y02f6wnjls61mqkz4apr4ll8-stdenv-linux

Success on x86_64-linux (full log)
Attempted: stdenv
Partial log (click to expand)
  /nix/store/hixf6xzc993b70xwf6vv1fvld48yy68i-gcc-wrapper-7.3.0.drv
  /nix/store/q7vsy0ykx12h8q1jfsvp4jwhfmy1l8rk-lzip-1.20.drv
  /nix/store/m5mxhwfxlic8qn53qbfkq2823xrlp2j7-ed-1.14.2.drv
  /nix/store/j170v41m13c25hxcrini1131lar9sqwd-patch-2.7.6.drv
  /nix/store/m74239nydr9p7dhw99prz21akpl74nqd-patchelf-0.9.drv
  /nix/store/s07v5qikiwjfg7jqnmfyw4zrc6rmrrqq-bzip2-<IP_ADDRESS>.1.drv
  /nix/store/xxxzwgmn4cxjpbif8xakschzd561zj03-gnused-4.5.drv
  /nix/store/jbc443g8s87x6rvadw7li18ayk53gc5w-stdenv-linux.drv
waiting for locks or build slots...
/nix/store/zpz5va07y02f6wnjls61mqkz4apr4ll8-stdenv-linux

Success on x86_64-linux (full log)
Attempted: stdenv
Partial log (click to expand)
shrinking /nix/store/wy2jq4zrrihg6275lhzah7ybipd0fbym-findutils-4.6.0/libexec/code
shrinking /nix/store/wy2jq4zrrihg6275lhzah7ybipd0fbym-findutils-4.6.0/libexec/bigram
gzipping man pages under /nix/store/wy2jq4zrrihg6275lhzah7ybipd0fbym-findutils-4.6.0/share/man/
strip is /nix/store/d1prcspbh2qsviipvnaxizcj8l3g7fpw-bootstrap-tools/bin/strip
stripping (with command strip and flags -S) in /nix/store/wy2jq4zrrihg6275lhzah7ybipd0fbym-findutils-4.6.0/libexec  /nix/store/wy2jq4zrrihg6275lhzah7ybipd0fbym-findutils-4.6.0/bin
checking for references to /build in /nix/store/wy2jq4zrrihg6275lhzah7ybipd0fbym-findutils-4.6.0...
shrinking RPATHs of ELF executables and libraries in /nix/store/kskmgg7x0pmmfhd7xkyzpdvhymprl5f9-findutils-4.6.0-info
strip is /nix/store/d1prcspbh2qsviipvnaxizcj8l3g7fpw-bootstrap-tools/bin/strip
checking for references to /build in /nix/store/kskmgg7x0pmmfhd7xkyzpdvhymprl5f9-findutils-4.6.0-info...
building '/nix/store/jbc443g8s87x6rvadw7li18ayk53gc5w-stdenv-linux.drv'...

Heh. I think we just witnessed a bug in nix: waiting for locks doesn't count towards timeouts in nix-build.
This then suggests a way to force @GrahamcOfBorg to make long rebuilds multiple times: you can push several dependent changes one-by-one and all but the very first one would hang waiting for lock, but then the first one timeouts the next one immediately picks up where the previous one left and extends the timeout.
/cc @grahamc

I think this should be merged and doCheckByDefault set by default ASAP, look what bugs it can find: https://github.com/NixOS/nixpkgs/pull/28029#issuecomment-385164346

ping!


Feature request: replot to pools

Official pooling protocol wil be released soon™. I'd like the feature to automatically replot from the old plots to the new ones (delete the old format plot, create a new one in it's place, repeat).

let's get pool support added first (when it comes out next week).  Then will need to workout how to detect old vs new plot format.

Unfortunately portable plots have the same file names. The only idea I have is to analyze the plot creation time in the file name and replot files that are older than the defined date.

how about just do a simple one, we create a new folder in the same drive for new plot
in the json option files, let us specify the old plot path and new plot path
once a new plot nearly done, delete one of the old one and start copy the new one

my current thinking is to allow the user to specify a cutoff date in the config.json and PlotNG will look at the filename of the plot files and anyone before the cutoff date is then a candidate for deletion to make room for new plots.  However, it will need to make room before the plot starts.


TBD As a dev using the ref. impl., I want to set restrictions and limitations for specific apps (including API keys if set up).

[ ] #114

Which apps can use the API keys

Which chains should be accessible using the API keys

How many requests (in total and per second/minute/hour/day) can be made using these API keys.

more restrictions TBD

Consists of the following rules:

[ ] #177
[ ] #178
[ ] #179
[ ] #180
[ ] #181

Some seed rules have been done (very basic functionality). Database is structured accordingly.

same as #37

endpoints are merged but unsure whether there are UI components for it yet. @memosys is working on components now

added hooks and endpoints, as well as working on the ux to add and remove a rule

@plor is doing the proxy side of things. @memosys what are format and value of the app rule?

Pushed app rules implementation to proxy side

This can probably be closed now @benedictvscriticus


semanticdb.semanticidx does not play nicely with incremental compilation

Steps to reproduce https://github.com/olafurpg/semanticdb-zinc/commit/60ac13efe7604c2177a3d4fc6523210fa3007615
We need to figure out how to make semantic.semanticidx handle incremental compilation.

Seems the best testing strategy for bugs like this is to use the sbt scripted framework https://www.scala-sbt.org/1.0/docs/Testing-sbt-plugins.html this enables us to reproduce longs chains of actions and write assertions in plain scala code.

Another idea is to depend on bloop as a library and write unit tests that write .bloop/*.json files with configuration and programmatically trigger bloop compile <id>. This would run faster than scripted tests as part of testsJVM/test. Maybe it's possible to do the same directly with zinc, but I have no experience with zinc.

Sure, let's give it a try.


Result not found in qr_code_scanner

in console showing message code scaned in 8s like that
please help me how can i print result on my test widget

Currently we've not completed support for QR Code scanning.
Closing this issue


Add functionality for reading sensewear xlsx files as externally derived epoch data

Fixes #974

As you will see I am loading the METs column from the xlsx file as our main 'metric' for PA analysis, because we can use actual MET levels as thresholds to define LIPA and MVPA thresholds. However, I store MET under the metric name "ExtAct" (external activity), because I think it is not practical to have a new metric name for every external epoch datatype. GGIR would then become too much cluttered with terminology specific to uncommon data types. By storing it as "ExtAct", we can use "ExtAct" for all movement indicators from external software to be derived in the future if they do not overlap with existing metric names.
Similarly I use "wake_sleep" as column name in the part 1 milestone data to make it align with previous work on utilising externally derived sleep classifications (project with Kalaivani and her Python based sleep classifier). So, also there I tried to make it generic and not Sensewear specific.

Checklist before merging:

[x] Existing tests still work (check by running the test suite, e.g. from RStudio).
[x] Added tests (if you added functionality) or fixed existing test (if you fixed a bug).
[x] Updated or expanded the documentation.
[x] Updated release notes in inst/NEWS.Rd with a user-readable summary. Please, include references to relevant issues or PR discussions.
[ ] Added your name to the contributors lists in the DESCRIPTION file, if you think you made a significant contribution.

I tried this with also an updated version of excel file (.xlsx instead of .xls) and it works well. Should the documentation mention that the code works with .xls and .xlsx? Just in case any user think they should reformat all their files before using GGIR.

Thanks, now addressed in 91d1831

In g.part5_initialise_ts, the code scales the external activity metric by 1000 as it would be a g unit metric. Line 5 of this functions should include ExtAct to avoid this behavior: scale = ifelse(test = grepl("^Brond|^Neishabouri|^ZC|^ExtAct", params_general[["acc.metric"]]), yes = 1, no = 1000)

Thanks, now addressed in b4c53ff

I had to use argument acc.metric = "ExtAct" to avoid an error in part 5 when initialising the time series. I think this should be mentioned in the documentation.

I have now circumvented this by auto-setting acc.metric = "ExtAct" in check_params: 8ae4cc2.

And this made me think whether we should give the option to the users to give a name to the external metric they might be using with an argument like: ExtAct_name which defaults to "ExtAct".

I am not in favour of this, because:

If we want the metric names to be more intuitive then it would be best to choose it ourselves inside GGIR rather than to let each individual user decide as that will complicate comparisons and interpretation of variable names. For example, when they come to use with an error and show us output with column names we are not familiar with or when they want to merge datasets across studies.
If we want to facilitate more old sensor brands then there will be a growing number of output metric names, all of which then have to be accommodated in the GGIR code, increasing code complexity, while the beneficial value of working with these older and hardly used data types is limited. Note: Making the metric name more specific to each branch requires that part 1, 2 and 5 code need to be expanded.
MET as metric name could give the impression that GGIR estimates METs, so we would need a name that reflects that not GGIR but Sensewear estimated the METs, but then that variable name would be longer. ExtAct has the advantage that we can re-use it for all exotic metrics from all external brands and acknowledge in the documentation what is being used from the sensor output for each of those brands.


pip-compile doesn't add "via" for GitHub commit dependencies

I need a package's specific commit. This package has some requirements. Pip-compile doesn't show where these requirements come from.
Steps to replicate

Add a GitHub commit dependency to requirements.in, e.g. -e git+https://github.com/JelteF/pylatex.git@aa5aa1ea13d548e3a598544f49ceb6fcc80f6b36#egg=PyLaTeX
Run pip-compile

Expected result
This specific example requires ordered-set. The line containing this package in requirements.txt should say   # via PyLaTeX or something along those lines.
Actual result
In actuality, it only shows ordered-set, which caused me to search through my entire codebase and Git history searching for usages of this package, without result. I finally discovered the problem when hacking some print statements into piptools' resolver code.

Hello @basvdheuvel,
Thanks for the issue! It duplicates #293.


Use API in drops

What happened?
Currently drops are hardcoded and it would be nice to use API
Please reproduce in steps

Open /drops
See nothing

Expected Behavior
It would be nice to dynamically fetch the data from Squid API.
Which collections are drop? those with type Public and HolderOf
I will expand once the issue is done
What browsers are you seeing the problem on?
No response
At which address did you encounter bug?
No response
Are you logged in?
None
Which wallet you are using?
No response
Screenshots
Blocked by - https://github.com/kodadot/stick/issues/88
Relevant log output
No response
Payment link for reward
https://kodadot.xyz/ksm/transfer/?target=<My_Kusama_Address_check_https://github.com/kodadot/nft-gallery/blob/main/CONTRIBUTING.md#creating-your-ksm-address>
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Please reproduce in steps

Open /drops
See nothing

It has been fixed on the canary env based on the current implementation.  https://canary.kodadot.xyz/ahk/drops
ref: https://github.com/kodadot/nft-gallery/pull/6994

Expected Behavior
It would be nice to dynamically fetch the data from Squid API.

Anyway, this solution is better to avoid similar issues in the future.

Soon, waiting for kodadot/stick#194


feat(server-renderer): support for non-Node.js Environments

Previous version of this package (vue-server-renderer) had support for non-Nodejs (see https://ssr.vuejs.org/guide/non-node.html).
It continued working on vue-next but regressed when this PR was merged: https://github.com/vuejs/vue-next/pull/1197 because stream is node only.
This PR proposes to create, like existed on vue@2, a "basic" version of server-renderer without node only requirements.
Please appreciate and review.
This PR likely fixes #3111 root cause

Here are the steps to test this proposed change
git clone git@github.com:ferdinando-ferreira/vue-next.git --single-branch vue-next-basic-renderer
cd vue-next-basic-renderer
yarn
yarn build

This builds (using the current source with this PR merged) the vue packages, including the newly created
/src/basic.ts → packages/server-renderer/dist/server-renderer.basic-cjs.prod.js...

This repo has one extra folder: usecase, with webpack configurations for both SSR and non SSR simple vue projects. To test it:
cd usecase
npm install
npm run build

The end result, in the distfolder, will be four folders

dist/web: regular non SSR version, can be viewed on the browser by opening the index.html or with npm run start:web
dist/node: node SSR, can be viewed with npm run start:node

Then there are two non node SSR versions, compiled as some other target so it can be used with php-v8:

dist/phpv8/current: compiled with @vue/server-renderer as it exists today
dist/phpv8/proposed compiled with @vue/server-renderer aliased as ../../packages/server-renderer/dist/server-renderer.basic-cjs.js

Testing
The requirements to test these two php-v8 SSR versions are:

php installed and in the path
The extension v8js available for this php install

Here is the result of both tests
npm run start:phpv8-current results in
><EMAIL_ADDRESS>start:phpv8-current
> php dist/phpv8/current/index.php

Fatal error: Uncaught V8JsScriptException: V8Js::compileString():19027:
No module loader in usecase\dist\phpv8\current\index.php:8

Stack trace:
#0 usecase\dist\phpv8\current\index.php(8): V8Js->executeString('/******/ (() =>...')
#1 {main}
  thrown in usecase\dist\phpv8\current\index.php on line 8

And npm run start:phpv8-proposed results in
><EMAIL_ADDRESS>start:phpv8-proposed
> php dist/phpv8/proposed/index.php

    <title>Test node</title>
    <meta charset="utf-8">
    <meta name="keyword" content="vue,ssr">
    <meta name="description" content="vue srr demo">
  <link href="assets/index.css" rel="stylesheet">

Hello World! 0
<input type="button" value="Click me">

With the only difference between the two versions being the use of the newly created packages/server-renderer/dist/server-renderer.basic-cjs.prod.js version of the server-renderer, which is the desired effect of the proposed change.

Testing without php
Even without php and v8js it is possible to analyze the output of the proposed solution.


unintended replacements in remove_needless_u_specifier example

I gave undebt a try using remove_needless_u_specifier.py and noticed some instances where it replaced more than expected when a string ended with a u character:
     try:
         subprocess.check_call(('mysql',
-                               '-u', 'test_user',
+                               '-', 'test_user',
…)

 TITLE_LABELS = {
     "en": ("Subject", ),
-    "ru": ("Тема", ),
+    "r": ("Тема", ),
     "fr": ("Objet", "Sujet"),
…

Yes, it seems like the grammar in remove_needless_u_specifier should be made to only look for unquoted us.


Fix Classification seeding :parent_id has been removed

Broken by #18656
https://github.com/ManageIQ/manageiq/pull/18418 removed :parent_id: 0

thanks guys


Add support for Nextcloud Mail

Fixes false positives with the Nextcloud Mail client

I just noticed that marker END-NEXTCLOUD-ADMIN was never used so let's remove it - pls delete line SecMarker "END-NEXTCLOUD-ADMIN" at the end of the file. Thanks.

Merging, thank you!


notebook updates

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.1%) to 47.534%

Totals

Change from base Build<PHONE_NUMBER>:
0.1%

Covered Lines:
299

Relevant Lines:
565

💛  - Coveralls


Error: No named parameter with the name 'collection'.

Error: No named parameter with the name 'collection'.

Could you please provide a bit more information? What are you trying to do, where do you get this error?

Hi,
I used the following code
getDataInArea(
collection: locationCollection,
area: Area(center, radiusInKm),
locationFieldNameInDB: 'position',
mapper: (doc) => FbLocation.fromJson(doc.data),
locationAccessor: (item) => item.position,
// The distancemapper is applied after the mapper
distanceMapper: (item, dist) {
item.distance = dist;
return item;
}
);

///////
collection and item.distance not exist in getDataInArea method


Introduce active-passive controller

#169117521
This controller reconciles on events from Quarksstatefulsets instances
The main logic around this controller is that it will execute a probe
based on a container name per pod. When the probe cmd executions succeeds,
it will label the pod with a pod-designation key, with a true value.
For pods, where the probe fails, if the label exists, it will be removed.
This PR contains the following:

Adds a new controller to the Manager
Adds a new active-passive controller under the kube/controllers/quarkstatefulset dir
Adds a new active-passive reconciler for the above controller.
Updates quarksstatefulset types

Introduces a new field call ActivePassiveProbe, which holds a value of the type
map[string]*corev1.Probe, which basically reuses the existing k8s Probe functionality
The Probe PeriodSeconds field, will determine how often the active-passive controller
will be reconciling.

Update quarksstatefulset generated fake files

Due to new field for the CRD struct

Adds only integration tests for this controller

New set of supportive funcs for the Machine interface
This includes:

logic for events lookup
pod cmd execution in containers
ability to patch pods

added a new quarks_statefulset_active_passive_test.go

holds different scenarios to validate the crd behaviour.

Adds a new sample document, with a ActivePassive Probe

@viovanov I addressed all your comments, asking to re-review my PR


[pigeon] implement nullsafe generics

Right now all type arguments have to be nullable for generic type arguments.  We should support non-null arguments.

Does this include using enums as a type? We've seem to be struggling with having non-null enum types, but it might be a different issue.

@marianhlavac better enum support is on our radar, there should be an issue for it.  That'd probably be implemented separately though.


Create tooling API model for native domain

As the native plugins are getting closer to be stable, more are more users will rely on ways to query the native model to extend or use it either through plugins or the tooling API.
Expected Behavior

Users should be able to query all information about the choice Gradle made during configuration without relying on internal API.
Current Behavior

No tooling API model exists for the native domain. Some information is unavailable to query such as the toolchain tool executable name configuration, while others require more processing like includes path as nothing prevent a user from specifying them as compiler flags.
Contract

[ ] Query components (C++ library or application)
[ ] Query buildable targets for each components

[ ] Query compiler details for each targets

[ ] User header search paths (CppCompile#getIncludes(), -I flags, -iquote` flags)
[ ] System headers search paths (CppCompile#getSystemIncludes() -isystem flags)
[ ] Framework search paths on macOS only (-F)
[ ] Defines and undefines (CppCompile#getMacros(), -D flags, -U flags)
[ ] Extra compiler flags outside of the macros, framework search path, and header search paths)
[ ] Compilation Gradle task path
[ ] Compiler tool path used for the compilation as well as the working directory. Note: the user could probably infer the working directory as the getParentFile() of the compiler tool File.
[ ] Compilation units for the target (CppCompile#getSources())
[ ] Output location for each source file
[ ] Headers for the target (public and private)

[ ] Query linker/create details for each targets. Most importantly executables, then shared libraries and finally maybe of less importance static libraries.

[ ] Linked or created file location (AbstractLinkTask#getLinkedFile() or CreateStaticLibrary#getBinaryFile())
[ ] Link or create Gradle task path

[ ] Component name (CppBinary#getBaseName())
[ ] Variant name (CppBinary#getName()). Note: this name maybe best without the target name from above included in.
[ ] Target type (executable, shared library or static library)

@lacasseio can you add what's needed for the model here?

"Should we explicitly deny users from passing compiler/linker flags when a strong model exists? Or should we allow both configurations to coexists with a single query method?" There is always a need for an "escape" mode which could used to match situation not supported/planned by the strong model.

Good question @zosrothko. In general, we avoid providing escape hatch and prefer an use case centric solution. This may block unsupported/unplanned situation, however, we have to keep in mind that in Gradle, everything we allow a user to do needs to have tested and be supported. Escape hatch adds a lot of implicit burdens when it comes to maintenance. In our experience, Gradle is flexible enough that you can workaround most limitation in face of an unplanned situation. The best example is the native samples. They offer possibilities around common cases that aren't in the core of Gradle but are still able to make them work.
This issue is centered around the tooling API which allows us to provide a stable API over a less stable model.

I updated the description to include what information the tooling API model should be looking at providing.

Could you also expose the information about mapping of source file(*.cpp) and target object(*.o, *.obj) file?
It's planned to be used by CLion to provide visualized output when -fstack-usage compiler option is set.
https://youtrack.jetbrains.com/issue/CPP-13257
(https://gcc.gnu.org/onlinedocs/gnat_ugn/Static-Stack-Usage-Analysis.html)
The current experimental builder uses CompilerOutputFileNamingSchemeFactory project service to obtain the mappings, see details at
https://github.com/JetBrains/intellij-community/blob/0f09427c9e82ed399fbe08f040ac461c109425aa/plugins/gradle/native/tooling/src/builder/CppModelBuilder.java#L163-L184

PR https://github.com/gradle/gradle/pull/6195 adds an initial C++ tooling model plus integration with the new C++ plugins (but not the software model plugins). I think the PR covers most of the stuff listed above.
Something this PR does not handle is any custom compiler args attached to compile tasks. For example, the tooling model builder does not handle extracting the -I compiler args and including the result in the user header path. This is because this isn't well supported in general in the new C++ plugins yet. I've added https://github.com/gradle/gradle-native/issues/803 so that we can fix this for up-to-date checks and caching as well as the IDE integration, rather than just adding a tooling model specific solution.
@vladsoroka would you mind taking a look at the new model and letting us know whether this will work for you? The model will be included in the Gradle 4.10 release but will be incubating. We can make whatever changes you need for 4.11 and we can look at making the APIs stable.
The new model types are here: https://github.com/gradle/gradle/tree/release/subprojects/tooling-api/src/main/java/org/gradle/tooling/model/cpp
The tests are exercising it here: https://github.com/gradle/gradle/tree/release/subprojects/tooling-builders-native/src/crossVersionTest/groovy/org/gradle/language/cpp/tooling/r410

I've closed this issue. We will add new issues for any changes or fixes we need to do.

reopening until the CI coverage for the new project has been set up.

Cool! I'll check the new API asap!

This is done now.

@adammurdoch I've tested the new api using the local dev CLion builds and it looks fine to me. Thank you so much! I will update bundled gradle tooling jars for IDEA/CLion 2018.3 nightly builds when the Gradle 4.10 release will be shipped.


integration tests: Various updates

Switches to charmed-kubernetes/actions-operator@main, which now has support for microk8s-addons option.
Increases the connectivity check timeout as it can be a bit too short for nodes with fewer resources.

Everything is green now.


Add capability to use array_map

https://github.com/infinyon/fluvio-client-wasm/blob/8d9547ce0dc52a3f70aebeccd862d79997e290d6/src/consumer.rs#L20
https://github.com/infinyon/fluvio-client-wasm/blob/8d9547ce0dc52a3f70aebeccd862d79997e290d6/src/consumer.rs#L67
https://github.com/infinyon/fluvio-client-wasm/blob/8d9547ce0dc52a3f70aebeccd862d79997e290d6/src/consumer.rs#L88

also filter_map


Please Whats the problem with this :(

Expected behavior
To open up normally
Actual behavior
not opening/working/running up
Information about the Issue
"There seems to have been an unexpected error with Kitematic"

The information about the Issue is not exactly what we need here, what you should get is an output like this:
`There seems to have been an unexpected error with Kitematic
Custom setup error description
Retry Setup`
We need this custom message to dig further into the issue.


Buffer overflow while logging

Trying to log results in a buffer overflow immediately after starting the process.
mavlink-routerd -l . /dev/ttyTHS2:921600
Open UART [4] /dev/ttyTHS2 *
UART [4] speed = 921600
Open TCP [5] <IP_ADDRESS>:5760 *
Logging target system_id=1 on 02021-2017-06-12_23-58-43.ulg
*** buffer overflow detected ***: mavlink-routerd terminated
Aborted
I'm running it on an Nvidia TX1 with Ubuntu 16.04.2 LTS (arm64)
g++ --version
g++ (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609

Hi @nkhoit,
Do you have a core dump file? Or could you please run mavlink-routerd on valgrind or gdb? So we could get more information on this issue
Thanks

Valgrind:
valgrind ./mavlink-router/mavlink-routerd -l . /dev/ttyTHS2:921600
==20435== Memcheck, a memory error detector
==20435== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==20435== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==20435== Command: ./mavlink-router/mavlink-routerd -l . /dev/ttyTHS2:921600
==20435==
Open UART [4] /dev/ttyTHS2 *
UART [4] speed = 921600
Open TCP [5] <IP_ADDRESS>:5760 *
Logging target system_id=1 on 00002-2017-06-13_20-50-29.ulg
==20435== Syscall param epoll_pwait(sigmask) points to unaddressable byte(s)
==20435==    at 0x4B10240: epoll_pwait (epoll_pwait.c:42)
==20435==    by 0x40E59F: Mainloop::loop() (mainloop.cpp:292)
==20435==    by 0x40296B: main (main.cpp:805)
==20435==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==20435==
20435 *** memcpy_chk: buffer overflow detected ***: program terminated
==20435==    at 0x48479CC: ??? (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==20435==
==20435== HEAP SUMMARY:
==20435==     in use at exit: 95,055 bytes in 17 blocks
==20435==   total heap usage: 34 allocs, 17 frees, 132,896 bytes allocated
==20435==
==20435== LEAK SUMMARY:
==20435==    definitely lost: 0 bytes in 0 blocks
==20435==    indirectly lost: 0 bytes in 0 blocks
==20435==      possibly lost: 0 bytes in 0 blocks
==20435==    still reachable: 95,055 bytes in 17 blocks
==20435==         suppressed: 0 bytes in 0 blocks
==20435== Rerun with --leak-check=full to see details of leaked memory
==20435==
==20435== For counts of detected and suppressed errors, rerun with: -v
==20435== ERROR SUMMARY: 400 errors from 1 contexts (suppressed: 0 from 0)

Can you try again with master branch. This is the most common case we test so it would be surprising if it's not working for you

I tried again on master and I get the same problem on my Nvidia TX1.
I decided to try on my x86-64 Ubuntu 16.04 desktop and got a buffer overflow as well but a different valgrind output.
valgrind ./mavlink-routerd -l ~ /dev/ttyACM0
==27205== Memcheck, a memory error detector
==27205== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==27205== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==27205== Command: ./mavlink-routerd -l /home/nkhoit /dev/ttyACM0
==27205==
==27205== Invalid read of size 1
==27205==    at 0x40D84A: strlist_to_ul (main.cpp:268)
==27205==    by 0x40D84A: add_uart_endpoint(char const*, unsigned long, char const*, char const*) (main.cpp:327)
==27205==    by 0x4024F2: parse_argv (main.cpp:481)
==27205==    by 0x4024F2: main (main.cpp:790)
==27205==  Address 0x5ab6e7d is 0 bytes after a block of size 13 alloc'd
==27205==    at 0x4C2DB8F: malloc (vg_replace_malloc.c:299)
==27205==    by 0x545D489: strdup (strdup.c:42)
==27205==    by 0x40D4E0: split_on_colon(char const*, char**, unsigned long*) (main.cpp:118)
==27205==    by 0x4024A0: parse_argv (main.cpp:465)
==27205==    by 0x4024A0: main (main.cpp:790)
==27205==
Open UART [4] /dev/ttyACM0 *
UART [4] speed = 115200
Open TCP [5] <IP_ADDRESS>:5760 *
Logging target system_id=1 on 00003-2017-06-30_13-23-34.ulg
27205 *** memcpy_chk: buffer overflow detected : program terminated
==27205==    at 0x4C3085C: VALGRIND_PRINTF_BACKTRACE (valgrind.h:6816)
==27205==    by 0x4C3544A: __memcpy_chk (vg_replace_strmem.c:1564)
==27205==    by 0x412B07: memcpy (string3.h:53)
==27205==    by 0x412B07: ULog::write_msg(buffer const) (ulog.cpp:143)
==27205==    by 0x40E2D5: Mainloop::write_msg(Endpoint, buffer const) (mainloop.cpp:122)
==27205==    by 0x40E3B7: Mainloop::route_msg(buffer*, int, int, int, int) (mainloop.cpp:143)
==27205==    by 0x40A6BB: Endpoint::handle_read() (endpoint.cpp:77)
==27205==    by 0x40F61D: Mainloop::loop() (mainloop.cpp:282)
==27205==    by 0x40255E: main (main.cpp:806)
==27205==
==27205== HEAP SUMMARY:
==27205==     in use at exit: 95,108 bytes in 18 blocks
==27205==   total heap usage: 38 allocs, 20 frees, 134,529 bytes allocated
==27205==
==27205== LEAK SUMMARY:
==27205==    definitely lost: 0 bytes in 0 blocks
==27205==    indirectly lost: 0 bytes in 0 blocks
==27205==      possibly lost: 0 bytes in 0 blocks
==27205==    still reachable: 95,108 bytes in 18 blocks
==27205==         suppressed: 0 bytes in 0 blocks
==27205== Rerun with --leak-check=full to see details of leaked memory
==27205==
==27205== For counts of detected and suppressed errors, rerun with: -v
==27205== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Both of these are running PX4 on Stable 1.6.3 on a pixracer. Is there anything on the PX4 side that could be different?

@nkhoit This should fix the buffer overflow that you pointed out when running on your X86 machine. https://github.com/01org/mavlink-router/pull/102

Added another patch to fix the 'Invalid read of size 1'.

I tried your branch. It didn't fix the buffer overflow in particular.
It did fix the problem with the whole colon baudrate thing. Here's an exact valgrind on my x86 machine connecting to a Pixracer.
valgrind ./mavlink-routerd -l ~ /dev/ttyACM0
==31670== Memcheck, a memory error detector
==31670== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==31670== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==31670== Command: ./mavlink-routerd -l /home/nkhoit /dev/ttyACM0
==31670==
Open UART [4] /dev/ttyACM0 *
UART [4] speed = 115200
Open TCP [5] <IP_ADDRESS>:5760 *
Logging target system_id=1 on 00005-2017-06-30_16-08-56.ulg
31670 *** memcpy_chk: buffer overflow detected : program terminated
==31670==    at 0x4C3085C: VALGRIND_PRINTF_BACKTRACE (valgrind.h:6816)
==31670==    by 0x4C3544A: __memcpy_chk (vg_replace_strmem.c:1564)
==31670==    by 0x412F4C: memcpy (string3.h:53)
==31670==    by 0x412F4C: ULog::write_msg(buffer const) (ulog.cpp:152)
==31670==    by 0x40E2E5: Mainloop::write_msg(Endpoint, buffer const) (mainloop.cpp:122)
==31670==    by 0x40E3C7: Mainloop::route_msg(buffer*, int, int, int, int) (mainloop.cpp:143)
==31670==    by 0x40A75B: Endpoint::handle_read() (endpoint.cpp:77)
==31670==    by 0x40F62D: Mainloop::loop() (mainloop.cpp:282)
==31670==    by 0x40257B: main (main.cpp:807)
==31670==
==31670== HEAP SUMMARY:
==31670==     in use at exit: 95,108 bytes in 18 blocks
==31670==   total heap usage: 38 allocs, 20 frees, 134,529 bytes allocated
==31670==
==31670== LEAK SUMMARY:
==31670==    definitely lost: 0 bytes in 0 blocks
==31670==    indirectly lost: 0 bytes in 0 blocks
==31670==      possibly lost: 0 bytes in 0 blocks
==31670==    still reachable: 95,108 bytes in 18 blocks
==31670==         suppressed: 0 bytes in 0 blocks
==31670== Rerun with --leak-check=full to see details of leaked memory
==31670==
==31670== For counts of detected and suppressed errors, rerun with: -v
==31670== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Fixed in #102


Incompatible with schema_plus

It appears as if this gem has problems when also used with schema_plus and when both have options for the same column.  I'm not sure which gem has a bug; so I also posted an issue over there.
See https://github.com/lomba/schema_plus/issues/170
Also see that issue for additional details and examples.

With newer versions of Schema Plus, specifically SchemaPlus/schema_monkey#6, db:load/db:reset and friends will cause an infinite recursion. I hypothesise it's due to alias_method_chain being called to early, @ronen and I are looking into this; if that is indeed the problem, would switching over to module includes be okay with you?
If that doesn't work (hence the use of alias_method_chain), would requiring Ruby 2.0 for Module.prepend be an acceptable solution?

I'm all for moving to Ruby 2.0 to keep the code lean, and that would include removing alias_method_chain in favor of prepend or the like.  That would require a small rewrite, and that is indeed the plan.  However, I don't have a timeline on this yet (although now more motivated ;) ).
For the time being, I don't see how using Module includes would solve the problem.  Can you possibly provide a sample of such code that demonstrates this?

I'm not sure of the exact priority rules for prepend vs include (but I vaguely remember that it's prepended modules last prepended first, then the class, then included modules last included first).
So if a class has a method that is implemented only in a module, including a new module does replace the existing implementation, with the old implementation accessible via super. So it's like a prepend.
ActiveRecord does this, so it might not require a prepend.

@pinnymz, @lowjoel: confirming it's a small rewrite to change from alias_method_chain to override & super, I went through that in schema_plus and it wasn't a big deal.
Personally I'd recommend using prepend rather than trusting subtleties of include order and method definition location.   Though that would mean dropping support for ruby 1.9.3 -- but since ruby 1.9.3 is itself no longer supported that doesn't seem too onerous.  I took the advice of several people and did that for schema_plus and nobody has complained.
But...
@pinnymz Another thing to consider if you were interested:  Re-implement migration_comments on top of schema_plus's infrastructure: schema_plus_core and schema_monkey I think it would fit right in.  Those take care of all the monkey patching to provide an extension API for rails, letting you drop in enhancements like this as middleware without needing to do all that monkey patching yourself.
It'd of course be a bigger change to the code base, which would doubtless give you pause.  But once changed there'd actually be much less code, and you'd get upwards-compatibility with future releases of ActiveRecord "for free" when schema_plus_core updates accordingly.
If that's something you're interested in, I'm happy to answer any questions you may have.

I think I can push a PR to move this to prepend and super, breaking 1.9 compatibility. @pinnymz would you be okay with it?
If you'd like to use the schema_monkey and schema_plus_core gems, with stuff written using modules+prepend should make it easier to migrate too anyway.

@ronen I am giving serious consideration to implementing on top of the schema_plus infrastructure, and I'd like to see what you think this would entail.  I think we should take this conversation to another forum.
cc: @lowjoel

OK, let me know how it goes.

@pinnymz we never did have that conversation... still interested?

@ronen this now seems to be moot, as Rails 5 will be supporting comments.  Thanks for the offer, though.

@dmeranda #30 uses prepend and should play nicely with other extensions, can you try this out and let me know?

Note that as per SchemaPlus/schema_monkey#13 these gems are compatible but they need to be required in the proper order.


github login is necessary to download packages?

I tried to install NeoMake via NeoBundle "penekastah/neomake" then running nvim.  It prompts me to decide if I want to install NeoMake, if I say yes I get a pop up asking for my github username and password.
Why would I need to login to github to download something?
Furthermore, the GUI box steals focus which is really bad design.
I am running NVIM 0.1.2 and the latest neobundle.

Okay, I found the error: It should be NeoBundle "benekastah/neomake", not NeoBundle "penekastah/neomake" -- notice the b becomes a p in the wrong version.
Still, that is a weird effect for such an error.

neobundle development is done.
it is wired error though.
I will fix it in dein.vim

Furthermore, the GUI box steals focus which is really bad design.

Please read f flag in :help guioptions.


[GCM] Sugar syntax suggestion for local index declaration

(cc @thomashartmann )
IMHO, it could be cool to allow this (in addition to the current declaration):
class A {
   att name: String

   index idxA using name
}

The default local index type could be the class type in which it is declared

I think this is too dangerous, and only useful when you want to have a tree hierarchy (folders for instance).

I am sorry but I have difficulties to get you point :/
Why it could be dangerous?

Dangerous in the sens that, if the type is not mandatory, developers might get troubles finding why the index is not generated properly (in the case they just forgot the Type)
It can moreover be Ambiguous.
Consider this
class A {
   att name: String
   index idxA using name
}
class B extends A {

}

What would be the type of objects in the index in Class B ?
Another point is that you want to "locally" index instances from another class in the general case.
For simplicity (of grammar and checkers) and uniformity, I would not recommend this feature.


When in "Edit Mode," right-clicking counts as a mousedown event (and causes unexpected dragging)

This can be seen even in the demo.

Draw a Rectangle or Polygon
Enter "Edit Mode"
Right-click on the Polygon (which should bring up the default web browser context menu)
Right or left click somewhere on the opposite end of the map
The shape jumps (and then propagates normal click behavior)

EXAMPLE:

This isn't a huge deal by iteself, but creates a lot of unexpected behavior for complex use-cases.
For example, I've bound a 'right-click' event in my application to delete a shape while in "Edit Mode." Because the 'right-click' counts as a mouse down for the purposes of dragging, it deletes the shape, but leaves the guide dots (as it still thinks it's "dragging" the shape, too)

Is it expected behavior for right-click to count as a "mouse-down" event? I can look at changing my application instead, if that's the case!
EDIT:
It appears the weirdness is exacerbated for Polygons. Right-clicking and then zooming with the mousewheel causes a similar issue, wherein the guide dots are still bound, but the polygon itself is not:

I do have a fix for this (that seems to work), but I won't PR if right-click-to-drag functionality is expected or desired.

hey @adamtLICOR. Let me get back to you on this on friday evening / saturday.


update slow description

Update mocha doc to have more details on the "slow" configuration

Nitpicky, but suggest moving the default value reference from end of line to its inline reference.
Reworded slightly for verb agreement.
Many reporters will display test duration and flag tests that are slow (default: 75ms), as shown here with the "spec" reporter:

Honestly think most of this textual description should be replaced with a single line bar graph image with markers [0, slow/2, slow, timeout] with the colors [green, yellow, red]. It would communicate same thing far more clearly.

thanks!


Ability to rerun relationship create job

small refactors to the create relationship job to make rerunning a relationship create easy.

post merge approval. ✅


[Obsolete]continuous muscle fiber activity hereditary, MONDO_0022857

Mondo term (ID and Label)
continuous muscle fiber activity hereditary, MONDO_0022857
Reason for deprecation
duplicate
Suggested replacement or term to consider
hereditary continuous muscle fiber activity,  MONDO_0019943

This is coming from Orphanet, however, the name at OMIM seems to be more accurate
Orphanet:972
https://omim.org/entry/160120 (I think that the disease being refered to by the Orphanet entry is Isolated Myokymia 1, which is "included" In this OMIM entry, which also includes episodic ataxia).
The latter is this MONDO entry
https://www.ebi.ac.uk/ols/ontologies/mondo/terms?iri=http%3A%2F%2Fpurl.obolibrary.org%2Fobo%2FMONDO_0008047&viewMode=All&siblings=false
See also this for Myokymia https://en.wikipedia.org/wiki/Myokymia
I am not sure how best to model this in Mondo @cmungall @mellybelly @nicolevasilevsky  ??

It looks like this term: continuous muscle fiber activity hereditary, MONDO_0022857
is coming from GARD and the webpage is down, so maybe this has been obsoleted in GARD?
@GARDinfocenter

@pnrobinson are you suggesting that MONDO_0019943 'hereditary continuous muscle fiber activity' should be renamed to Myokymia 1
and we should remove the related synonyms on MONDO_0008047 'episodic ataxia type 1'?
cc @ana-rath-orphanet

@nicolevasilevsky That is correct. We had replaced continuous muscle fiber activity hereditary with “hereditary continuous muscle fiber activity” (as per Orphanet) and had also added the synonym “Episodic ataxia type 1. We'll research Peter's suggestion and get back to you.

From Gioconda:
Hi!  This one is very confusing because of the different names and terms used in all the sources.   I think that I will use the GeneReview as our main source which states that other names for episodic ataxia type 1 are:
Acetazolamide-responsive periodic ataxia
Continuous muscle fiber activity
Episodic ataxia with myokymia
Familial paroxysmal kinesigenic ataxia and continuous myokymia
Isaacs-Mertens syndrome
Hereditary paroxysmal ataxia with neuromyotonia
The only one that uses hereditary continuous muscle fiber activity is Orphanet, a page that was reviewed in 2013.  The condition, I believe, originated from an article published back in 1984 where some members of the same family presented with continuous muscle fiber activity https://onlinelibrary.wiley.com/doi/abs/10.1002/ana.410150104 which is known as “Isaacs syndrome” (GARD: https://rarediseases.info.nih.gov/diseases/6793/isaacs-syndrome   NINDS:  https://www.ninds.nih.gov/Disorders/All-Disorders/Isaacs-Syndrome-Information-Page   synonyms:  neuromyotonia, Isaacs-Mertens syndrome, continuous muscle fiber activity syndrome, and quantal squander syndrome, Peripheral nerve hyperexcitability).
For now, this is what I propose:
Retire hereditary continuous muscle activity syndrome
Add the term “episodic ataxia type 1” with the synonyms from GeneReviews (which basically are the same stated in OMIM)
Keep Isaac’s syndrome for now (I think that the cases that are being included in episodic ataxia 1 are the hereditary cases but not the acquired cases)
Contact Orphanet and ask for them to review this terms
Please let me know if you agree with this and we can make the same changes.


Refactor FalcorRouter and db

The FalcorRouter and db.js files are over 1000 lines long. We could split them up into separate files, each handling methods of individual tables. Another refactoring suggestion is to choose a consistent naming style for the methods (e.g. use either "create" or "add" but use only one).

This is correct but closing in favor of other issues, some of this has also already been done