"global state" design

Provide the design for the "global state", which will contain the instantaneous state of all cloud resources monitored by SlipStream.

Similarly as is currently done, the "global state" will be created and maintained by the "collector" running "describe-instance" over the managed clouds. The global state will consist of collections of CIMI resources, where each document contains the information related to a single resource.
The collector would have to perform the following actions:

Collect all information for each credential/cloud combination.
For each identified resource (e.g. a specific VM) not currently in the global state, the collector must insert a new document for that resource in Elasticsearch. The information from the cloud must be augmented with run and service offer references, where possible.
For each resource that already has an entry, nothing needs to be done, although if the given entry is missing run and/or service offer references, it may try to complete them.
For resources within the global state that are no longer active, the associated document must be removed from the database.

The core functionality and actions are already available in the existing collector implementation, although this must be extended to provide the Elasticsearch documents, probably in addition to the current entries in the VM table in hsqldb.
However, the current implementation should be replace for several reasons: it is quite complicated with clojure, java, and python components, can't be distributed, and is unlikely to scale well. A new implementation should consider a python-based service (as the interface the cloud is actually in python) and direct insertion of records into Elasticsearch.

To keep things as simple as possible initially, the only resource that will be monitored are virtual machines (as is done now).  The proposed schema is similar to the ones already proposed for the ES accounting record and for the VM record.
The proposal is the following.
{
  "id": "virtual-machine/867876-8768",
  "resourceURI": "http://sixsq.com/slipstream/1/VirtualMachine",

  "updated": "2017-08-15T10:00:00.0Z",
  "created": "2017-08-15T10:00:00.0Z",

  "name": "short name",
  "description": "short description",
  "properties": {
    "a": "one",
    "b": "two"
  },

  "instanceID": "aaa-bbb-111",
  "state": "Running",
  "ip": "<IP_ADDRESS>",

  "cloud": {
    "href": "credential or connector/0123-4567-8912",
    "roles": ["realm:cern", "realm:my-accounting-group"]
  },

  "serviceOffer": {
    "href": "service-offer/e3db10f4-ad81-4b3e-8c04-4994450da9e3",
    "resource:cpu": 1,
    "resource:ram": 1024,
    "resource:disk": 10,
    "resource:instanceType": "Medium"
  },

  "run": {
    "href": "run/aaa-bbb-ccc",
    "user": {
      "href": "user/test"
    }
  },

  "acl": {
    "owner": {
      "principal": "ADMIN",
      "type": "ROLE"
    },
    "rules": [
      {
        "principal": "realm:accounting_manager",
        "type": "ROLE",
        "right": "VIEW"
      },
      {
        "principal": "test",
        "type": "USER",
        "right": "VIEW"
      },
      {
        "principal": "cern:cern",
        "type": "ROLE",
        "right": "VIEW"
      },
      {
        "principal": "cern:my-accounting-group",
        "type": "ROLE",
        "right": "VIEW"
      }
    ]
  }

}

The first set of attributes (id-properties) are standard CIMI metadata.  The optional attributes may or may not be used, but would appear in the formal schema.
The second set (starting with instanceID) are specific attributes of VMs that may be useful (and are collected currently).
The cloud is a reference to the cloud credential or connector.  It would initially be a reference to the connector and eventually be replaced by the cloud credential once they are available.  The roles are intended to provide optional grouping for the accounting, independently of a particular cloud or credential. These are intended to be copied values from the credential itself (or potentially another document).
 This may or not be available for a given virtual machine.
The ACL provides the following rights:

ADMIN: owner of the resource and full management rights
"test": view rights for the user, if one has been identified
"cern:cern", "cern:my-accounting-group": rights given to those with correct cloud/roles

More rights could be added, if necessary.
The current prototype provides all the information in the above proposal, except the run.  The run information can be obtained without too much effort.

There are three clients of the global state (possibly more):

"Real-time" dashboard,
Quota enforcement, and
Metering (accounting).

For the virtual machine part of the dashboard, the information would be a query/search over all of the virtual machine documents visible to a particular user.  Specific information about those virtual machines can be pulled directly from the document. Those tied directly to a user (as opposed to a group or role) can be selected by the existence of the run/user/href attribute.
For the quota enforcement, three pieces of information are required:

Instantaneous "use" of resources for the quotas,
Quota definitions, and
Requested resources in a provisioning request.

Given this information, a determination can be made if any of the quota values would be exceeded by a particular provisioning request.
Of the three types of information, only the first item is generated from the "global state". In this case, the information can be obtained by again querying/searching over the resources and applying the correct aggregation to a parameter (e.g. count for numbers of VMs or sum for RAM).
The last client is the metering. Given that the accounting record is nearly identical to the above virtual machine document, the following would need to be done for each metering interval and for each virtual machine document:

Copy the virtual machine document and
Add a timestamp field identifying the metering interval.

For the proposed metering interval of 1 minutes, this is logically a copy of the entire global state each minute. We can probably get away with a naive, brut-force implementation initially, but should look to see if there are better ways to achieve this with Elasticsearch, perhaps copies of indexes or snapshots.

It seems to me that in the proposed design the "collector" implementation can follow on from the current implementation and that all of the "clients" can be implemented using searches over the database to extract the correct information efficiently. The proposed record also contains enough information to provide subviews of information by credentials, groups, roles, and users as appropriate.  Comments welcome.

Looks good to me
A minor thing... if the cloud credentials are tied to a cloud connector instance, then the collector would only have to iterate over credentials.  This will come as we define the cloud credentials schema.

nothing to add. The metering mechanism just needs some investigation

Looks also good to me, with the same concern as above regarding the need to investigate how to make frequent copies with minimal footprint with Elasticsearch

LGTM.

I've added #1170 and #1171 to track the work on the collector.  #1171 brings the need to have a distributable collector, which means we need a scheduling and coordination mechanism.

Looks Ok.
Just a question: Currently we do the describe per user per cloud so a VM can be represented multiple times in the global state (one per user who share cloud resources or share credentials).
How it should work with the new schema ?
Should we do the same as it is now or should we try to merge them and add all users that can see the same VM in the ACL ?

The idea is to drop the user and only rely on credential (and connector if credentials are not tied to a cloud, but I think they should).  Then who sees what VM is just a matter of ACL.

As discussed yesterday, it is also important that all deployment actions go via SlipStream, including auto-scaling, such that quota enforcement is always performed.

Even if we describe per credential as you suggested it is still possible that two credentials can see the same Cloud resources.
If I understand your comment correctly we should go with the 2nd solution:
try to merge them and add all users that can see the same VM in the ACL
Correct ?

What do we do with "unknown" VMs ? Are they part of the Global State ?
I think they should.

They should be treated like all other VMs.  The only difference is that they won't have a run and hence no associated user.

What do we do with "unknown" VMs ? Are they part of the Global State ?
I think they should.

Also, we'll have to infer the service offer.


FATAL: when looking for log file format, can't open file -

Hey! I recently migrated from version 7 (that's what's in the official repositories for ubuntu/xenial) to 10 and noticed a script stop working.
Simplified, the line that worked for v7 was:
docker logs $CONTAINER 2>&1  | pgbadger --prefix "%m [%p]" -v -f stderr -

But now it's throwing a fatal error:
DEBUG: Output 'html' reports will be written to out.html
DEBUG: waiting for log entries from stdin.
FATAL: when looking for log file format, can't open file -, No such file or directory

It's entirely likely something has changed in the API, but I'm reporting this just in case.
I've worked around this by first dumping the logs to a file and then passing the file to pgbadger, but it would be cool to have the old functionality back.
Let me know if you need any more info!

Got it, commit 1e650ef might solve the issue.

Yep, that fixes it. That was fast, thanks!

Thanks for the feedback, a new release is coming the incremental mode is totally broken.


[TS-migration] Migrate 'AddPaymentMethodMenu.tsx' to TypeScript

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/25073
PROPOSAL:
Tests

[ ] Go to the wallet page (/settings/wallet route)
[ ] Click Add bank account button
[ ] Popover menu with available options should be visible.
[ ] Both options should be clickable.
[ ] Add debit card should show a component for entering debit card details.
[ ] Personal bank account should redirect to Plaid.

Offline tests

[ ] Repeat the Tests section and make sure it works the same with only one difference. Clicking on Personal bank account should display LHP with You appear to be offline. message.

QA Steps

Same as tests
PR Author Checklist

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

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

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

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

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

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] 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:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] 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)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

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

[x] 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

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

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

[x] 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.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] 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.
[x] If the PR modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label so the design team can review the changes.

[x] 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.
[x] 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
https://github.com/Expensify/App/assets/60450261/30cd83e6-4ce4-4234-a145-d0b6e8b0428d

Android: mWeb Chrome
https://github.com/Expensify/App/assets/60450261/d61c0cd1-a861-476f-870a-de21f7999ea5

iOS: Native
https://github.com/Expensify/App/assets/60450261/42bc2bde-c58f-45c9-8a87-00a9dd83a0cd

iOS: mWeb Safari
https://github.com/Expensify/App/assets/60450261/e4bd6786-1d1c-4beb-bd9b-9aa5e15e1334

MacOS: Chrome / Safari
https://github.com/Expensify/App/assets/60450261/a47bbdfb-14e2-402d-bc59-0dc4ecebee83

MacOS: Desktop
https://github.com/Expensify/App/assets/60450261/d56d66f7-ea36-4b4b-aa4e-9fc0f97e1d50

I have read the CLA Document and I hereby sign the CLA

recheck

All above comments are addressed (can't resolve them 🤷)
I've also tested updated BaseKYCWall component
Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

Overall changes look good, are we going to address?

I believe I've addressed it here

Reviewer Checklist

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

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

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

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[x] I verified proper code patterns were followed (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] 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)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

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

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

[x] If any new file was added I verified that:

[x] 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

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

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

[x] 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.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] 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.
[x] 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:

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

[x] 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.
[x] 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.
[x] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native
https://github.com/Expensify/App/assets/3069065/e8883f83-7986-4e63-8da9-68dceef16b43

Android: mWeb Chrome
https://github.com/Expensify/App/assets/3069065/a582ccb9-bc88-433b-9426-878cc4c6b866

iOS: Native
https://github.com/Expensify/App/assets/3069065/ab1a7b39-a18b-4dcc-9f63-dd1c3e879e2b

iOS: mWeb Safari
https://github.com/Expensify/App/assets/3069065/fba0329a-36a0-4cae-988a-0b303d18dc2d

MacOS: Chrome / Safari
https://github.com/Expensify/App/assets/3069065/a75d22c9-dbdf-45f3-aaff-6f351bbe55ce

MacOS: Desktop
https://github.com/Expensify/App/assets/3069065/55cd6b09-78e0-485b-b6a2-ca9dfcc1fef5

@MariaHCD Should we merge now, or we are waiting on something? 😄

We're waiting on the offline tests to be added to the PR description :)

We're waiting on the offline tests to be added to the PR description :)

@MariaHCD I added offline tests

Works as expected offline:

The reassure performance test failed 🤔
🛑 Error while parsing file: .reassure/current.perf [
  {
    "code": "custom",
    "message": "Your performance result file contains records with duplicated names.\n    Please remove any non-unique names from your test suites and try again.",
    "path": []
  }
]
Error: Process completed with exit code 1.

Asked here: https://expensify.slack.com/archives/C05LX9D6E07/p1711436202175639

That did it, thanks!

Not an emergency, all tests passed

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


Feat pr comment

Please answer these questions before submitting a pull request

Why submit this pull request?

[ ] Bugfix

[ ] New feature provided

[ ] Improve performance

[ ] Backport patches

Related issues

Bugfix

Description

How to fix?

New feature or improvement

Describe the details and related test reports.

Please add the corresponding test cases if necessary.

Backport patches

Why need to backport?

Source branch

Related commits and pull requests

Target branch

Codecov Report

Merging #11 (4a88eb4) into master (abaddcd) will decrease coverage by 17.00%.
The diff coverage is 42.85%.

@@             Coverage Diff             @@
##           master      #11       +/-   ##
===========================================
- Coverage   68.69%   51.69%   -17.01%
===========================================
  Files          48       39        -9
  Lines        3038     2600      -438
===========================================
- Hits         2087     1344      -743
- Misses        712     1082      +370
+ Partials      239      174       -65

Impacted Files
Coverage Δ

api/internal/core/store/storehub.go
0.00% <0.00%> (-70.41%)
:arrow_down:

api/internal/handler/plugin/plugin.go
72.72% <100.00%> (-13.94%)
:arrow_down:

api/internal/utils/version.go
0.00% <0.00%> (-100.00%)
:arrow_down:

api/internal/filter/request_id.go
0.00% <0.00%> (-100.00%)
:arrow_down:

api/internal/core/entity/entity.go
0.00% <0.00%> (-100.00%)
:arrow_down:

api/internal/filter/cors.go
0.00% <0.00%> (-66.67%)
:arrow_down:

api/internal/filter/schema.go
0.00% <0.00%> (-55.47%)
:arrow_down:

api/internal/utils/consts/api_error.go
0.00% <0.00%> (-50.00%)
:arrow_down:

api/internal/handler/data_loader/route_import.go
27.41% <0.00%> (-37.50%)
:arrow_down:

api/internal/handler/server_info/server_info.go
57.14% <0.00%> (-33.34%)
:arrow_down:

... and 29 more

Continue to review full report at Codecov.

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


Do something to (only) range currently being changed?

I am struggling (admittedly an intermediate js programmer) to implement range index to target specific ranges. For example, what would be the correct syntax if I wanted the range being changed to be red during changing and green when done changing. This does it to ALL the ranges, but I'd like to narrow it to only the range currently being dragged/changed:
$(RangeBar).on( "changing", function() {
		$(this).find( ".elessar-range" ).css( "background", "red" )
	}).on( "change", function() {
		$(this).find( ".elessar-range" ).css( "background", "green" )
});

The event handler function gets passed extra arguments: the event, the current value, and the range that is currently being changed. The events are fired on the rangebar object itself as well as on the element. You can access a range's element using .$el. So your example would look like:
rangeBar.on( "changing", function(ev, val, range) {
        $(range.$el).css( "background", "red" )
    }).on( "change", function(ev, val, range) {
        $(range.$el).css( "background", "green" )
});

It's working for the 'on change' but strangely not for the the 'on changing' ... i.e. when I let go of the mouse it becomes green but does not turn red during the drag/change. Here's my full init:
$(function() {
$("#rangebar").prepend(RangeBar({
min: moment().startOf("day").format("LLLL"),
max: moment().startOf("day").add(1, "day").format("LLLL"),
valueFormat: function(ts) {
return moment(ts).format("h:mm a");
},
valueParse: function(date) {
return moment(date).valueOf();
},
htmlLabel: true,
label: function(a) {
return '' + a[0] + '' + '' + a[1] + 'duration' + 'index of this range var';
},
snap: 1000 * 60 * 15,
minSize: 1000 * 60 * 30,
bgLabels: 4,
}).$el).on("changing", function(ev, val, range) {
    $(range.$el).css("background", "red");
}).on("change", function(ev, val, range) {
    $(range.$el).css("background", "green");

});

});

Does it work if you attach the handlers directly to the rangebar? I.e.:
$(function() {
    $("#rangebar").prepend(RangeBar({
      ...
    }).on("changing", function(ev, val, range) {
        $(range.$el).css("background", "red");
    }).on("change", function(ev, val, range) {
        $(range.$el).css("background", "green");
    }).$el);
});

p.s. for future reference, you can mark up code segments on Github with triple backticks:
```javascript
function() {}
```

Yeah, that didn't work, BUT my broader code is a little more complex so I'm certain it's my error. Ultimately however, I am  trying to prepend rangebars in about a dozen divs (with unique IDs) using each() to iterate through. Like thus:
$(function() {
    $(".elessar-ui").each(function() {
        var newRange = new RangeBar({
            min: moment().startOf("day").format("LLLL"),
            max: moment().startOf("day").add(1, "day").format("LLLL"),
            valueFormat: function(ts) {
                return moment(ts).format("h:mm a");
            },
            valueParse: function(date) {
                return moment(date).valueOf();
            },
            htmlLabel: true,
            label: function(a) {
                return '' + a[0] + '' + '' + a[1] + 'Duration: (need h:mm duration of range here... moment.duration(val[1].diff(val[0])).humanize(); doesnt seem to work)
' + '$.07';
            },
            snap: 1000 * 60 * 15,
            minSize: 1000 * 60 * 30,
            bgLabels: 4,

        });
        // attach a rangebar to each div.elessar-ui (each of which has a unique id)
        $(this).prepend(newRange.$el)
            .on("changing", function(ev, val, range) {
                $(range.$el).css("background", "red");
            })
            .on("change", function(ev, val, range) {
                $(range.$el).css("background", "green");

            });

    });
});

That's a perfectly fine way of doing that.

Many thanks. I'll troubleshoot why .on("changing", ...)  isn't catching... surely a small, silly typo.

So... ditching the .$el worked. i.e., changing this:
$(range.$el).css("background", "red");

... to this...
$(range).css("background", "red");

did the trick. Not sure why...

Oops, yeah, sorry

Here's my mostly-working version.
http://k1r.com/elessar/
Final fixes I'm working on are:

duration-- to display eg. 4 hours 15 minutes (where it currently returns "a few seconds")
when you click a gear icon, then the "Delete Range" button, to delete that range
clear the entire schedule when you click the Clear Schedule button under the rangebar


Command line version for scripting/macros?

I've been searching for a way to connect Bluetooth audio devices using macros/scripts and this seems to be by FAR the closest implementation of such a utility. Thank you very much for your contribution!
Is there any chance you would consider adding the ability to connect to a Bluetooth audio device by providing its name (or another applicable identifier) as a command line argument?
Thank you once again for your work.

Hi @mihalski, currently I don't have a plan to add command line support, but if you are able to compile the project, it should be trivial to add a command line interface. Use the BluetoothAudioDeviceEnumerator to get all the connectors, and then you can get their device names or change connection states.

My fork is a CLI version: https://github.com/shunf4/ToothTrayCli

My fork is a CLI version: https://github.com/shunf4/ToothTrayCli

Hello, your program works fine with command line, thanks! Could you make an x32 version of the program?

My fork is a CLI version: https://github.com/shunf4/ToothTrayCli

Hello, your program works fine with command line, thanks! Could you make an x32 version of the program?

@meloman27 try the latest pre-release.

try the latest pre-release.

Wow!!! Thank you very mutch! Everything works fine, everything works on Windows 10 32 Bit too! It was required only to install Microsoft Visual C ++ 2015 Redistributable, as I needed a file VCRгntime140.dll


Unlisted dependency

From what I can tell, @babel/runtime/helpers/esm/extends is a dependency but is not listed as a dependency or peer dependency in the package.json.

Thanks!

@all-contributors please add @brandonkal for bugs

:tada: This issue has been resolved in version 4.0.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Add a function for checking if strkey is compatible with Soroban

What problem does your feature solve?
A generic way for clients to verify that a given strkey is not just valid for generic Stellar transactions, but is also valid for Soroban. Soroban host could also use that function to ensure consistency in case if we ever need to reduce the address space.
What would you like to see?
A function that for a given Strkey object returns whether it's also a valid Soroban address (i.e. G-account or contract currently).
What alternatives are there?
Implement rules manually on the client side - that doesn't guarantee consistency in case if Soroban is updated.

Support in Soroban is somewhat broad concept. It might be more useful to make the address concept more specific and to add a type that parses strkeys that are addresses, so it'd support G and C addresses.
Would that help with the situation this is for? Could you tell more about hte situation?

It might be more useful to make the address concept more specific and to add a type that parses strkeys that are addresses,

That's an option as well, my initial suggestion requires minimal amount of work, but probably using a separate type would be more clear.

Would that help with the situation this is for? Could you tell more about hte situation?

Currently there is no good way to tell if a strkey is a valid Soroban address. While one could manually check that it starts with G/C today, there is no guarantee that we won't support new address types in the future. Which is why it is useful to have the validation in strkey library, given that it's already necessary to just parse the strkey. The use case that motivated this issue is validation performed by the bridges - they need to sanity check the strkey in the cross-chain message that comes from a different chain.

there is no guarantee that we won't support new address types in the gvdhggughiojrepogufeioghtriusgh trioukhjtilrjht5u4iowtu45iwotu54oiw;v

a
khfgcjklbdrgfjxvblnk, fhmxb

Ah, so if someone wants to figure out if a strkey is a valid Soroban Address, then they can already do that by using the ScAddress type in the stellar-xdr lib.
ScAddress::from_str("G/C....")

The type implements the stdlib FromStr trait, which returns either an ScAddress, or an error.

Cool, I wasn't aware of that function. Yes, it seems like a more appropriate solution here.


Question about the pre-trained data?

Is the model pre-trained on the entire miniImageNet (100 classes) or on the meta-training set (64 base classes)?
Besides, why the parameter --num_classes is 200 in io_utils.py?
Thank you very much!

Hi @ztf-ucas , the model is pre-trained on the meta-training set (64 base classes). For --num_classes=200, you can ignore it if you do not use that parameter.


Works on more compilers

I took a different approach to part of this in PR #8 ... not sure which one is better!


Fix Guardian.Plug.EnsureAuthenticated so it uses default ErrorHandler

According to the documentation, the Guardian.Plug.EnsureAuthenticated plug's :handler option should default to Guardian.Plug.EnsureAuthenticated.  If you currently try to use the plug without the :handler option, it raises an error saying "Requires a handler module to be passed".
In addition to updating the default value I also:

Removed references to old on_failure method
Refactored tests so options passed into EnsureAuthenticated.call are generated by EnsureAuthenticated.init method instead of being hard coded at the top of the file.
Added tests for the init method

The only thing that I see as a potential issue is when you run the tests, one of Guardian' deprecation warnings is printed out. I wrote a test to ensure the :on_failure argument continues to work even though it's deprecated. Any tips on how to not have the deprecation warning go into the test output would be greatly appreciated.

This is awesome :D I just saw that missing default the other day too, great timing!

@hassox Just rebased, and the build is green.

:metal:


SWS-227 Add status endpoint

Add /api/status endpoint to return map of server-side status info
Let /api return the same info

removed temporary "demo" info from root handler as swsui now provides
the information

Here is an example of the returned JSON:
{
  "SWS console version": "0.2.10-SNAPSHOT.200",
  "SWS core commit hash": "2f232b9deb83c1f2cee87ac451e16d476466554b",
  "SWS core version": "0.0.1.Final-SNAPSHOT",
  "SWS state": "running"
}

@jmazzitelli I got rid of the unused status.  please re-approve and merge


Support port forwarding for privileged ports (1-1023)

On macOS, listening on <IP_ADDRESS>:80 requires root while <IP_ADDRESS>:80 does not require root.
For such ports, the hostagent launches "pseudoloopback" forwarder that listens on <IP_ADDRESS>:80 but rejects connections from non-loopback src IP.
Fix #45

cc @jandubois @mattfarina


Revert changes in release 2.0.2, it causes too much other failures

Fixed in ee68b5d96de1a22f3085b30c0bc7654586c13043


Show both prediction & GT boxes in one figure

I try to use
python tools/test.py {CONFIG.py} {CHECKPOINT} --show-dir ./ --show

to show both prediction and GT boxes in one image on validation dataset, but I found in mmdet3d.models.detectors.single_stage_mono3d.py there is
show_multi_modality_result(
    img,
    None,
    pred_bboxes)

How to use test.py to show both my model prediction and GT bboxes in one figure?

The source code of show_multi_modality_result is here. It supports visualizing both prediction and GT bboxes together, you need to use gt_bboxes = data['gt_bboxes_3d']._data.tensor to extract the gt bboxes.


Could not find 'php'. The program may not be installed.

See php installation instructions at https://github.com/Glavin001/atom-beautify#beautifiers or go to http://php.net/manual/en/install.php
You can configure Atom Beautify with the absolute path to 'php' by setting 'Executable - PHP - Path' in the Atom Beautify package settings.
Your program is properly installed if running 'where.exe php' in your CMD prompt returns an absolute path to the executable.
Error: Could not find 'php'. The program may not be installed.
at Function.Executable.commandNotFoundError (file:///C:/Users/Dokolko-pc/.atom/packages/atom-beautify/src/beautifiers/executable.coffee:277:10)
at HybridExecutable.Executable.commandNotFoundError (file:///C:/Users/Dokolko-pc/.atom/packages/atom-beautify/src/beautifiers/executable.coffee:269:18)
at file:///C:/Users/Dokolko-pc/.atom/packages/atom-beautify/src/beautifiers/executable.coffee:197:22
at tryCatcher (C:\Users\Dokolko-pc.atom\packages\atom-beautify\node_modules\bluebird\js\release\util.js:16:23)
at Promise._settlePromiseFromHandler (C:\Users\Dokolko-pc.atom\packages\atom-beautify\node_modules\bluebird\js\release\promise.js:512:31)
at Promise._settlePromise (C:\Users\Dokolko-pc.atom\packages\atom-beautify\node_modules\bluebird\js\release\promise.js:569:18)
at Promise._settlePromise0 (C:\Users\Dokolko-pc.atom\packages\atom-beautify\node_modules\bluebird\js\release\promise.js:614:10)
at Promise._settlePromises (C:\Users\Dokolko-pc.atom\packages\atom-beautify\node_modules\bluebird\js\release\promise.js:690:18)
at _drainQueueStep (C:\Users\Dokolko-pc.atom\packages\atom-beautify\node_modules\bluebird\js\release\async.js:138:12)
at _drainQueue (C:\Users\Dokolko-pc.atom\packages\atom-beautify\node_modules\bluebird\js\release\async.js:131:9)
at Async._drainQueues (C:\Users\Dokolko-pc.atom\packages\atom-beautify\node_modules\bluebird\js\release\async.js:147:5)
at Async.drainQueues (C:\Users\Dokolko-pc.atom\packages\atom-beautify\node_modules\bluebird\js\release\async.js:17:14)
at
at process._tickCallback (internal/process/next_tick.js:188:7)
I have 0.33.1 version installed

You need to have php installed and the path set in Atom Beautify's settings.  Settings > Executables > PHP > Path


question about map size limit

i have been experimenting with map limit seeing if i can raise it higher, and while it mostly works as in compile works and stuff ingame its a bit broken  as if theres an issue with visibility but theres not, it seems related to frustum rendering as making bsp not init frustum fixes it altho that doesnt work cuz of course lights and way more things need frustum this is vid showing it i have looked through code and cant figure out why that could be happening so i thought only person to ask is owner itself, i did find that bsp format had int16 for some 'min' and 'max' stuff so i changed them to int32s and still didnt fix (cuz from what i know int16 only works up to 65536)
https://github.com/TheOverfloater/pathos-public/assets/80889633/acbb5c38-b54b-4911-a068-6ab0d79b3820

side note only brushes disappear vbm/mdls still show including dlights on them so it seems only a brush  issue
https://github.com/TheOverfloater/pathos-public/assets/80889633/92877b4b-0fcf-48c5-8fa6-2e7c12dfd277

I have been looking through the frustum code, but there I haven't been able to identify anything that would explain this. However the int16 variables you mentioned in the bsp file's structs are my only guess so far. To be honest I never really considered it likely that anyone would have any reason to go outside the +/- 32768 range when making maps, so I kind of designated that the "limit" for Pathos's maps. For me personally not even my largest maps go outside +/- 8192 even. Another reason is that precision issues show up if you go too far outside 4096 with smaller texture scales on surfaces, making it extremely ill-advised to go that far from 0 0 0. Regardless, did you make sure to edit the VHLT for Pathos as well to use the new 32-bit integer types and recompiled the map with the new binaries?

I have been looking through the frustum, as well as other engine code, but there I haven't been able to identify anything that would explain this. However the int16 variables you mentioned in the bsp file's structs are my only guess so far. To be honest I never really considered it likely that anyone would have any reason to go outside the +/- 32768 range when making maps, so I kind of designated that the "limit" for Pathos's maps. For me personally not even my largest maps go outside +/- 8192 even. Another reason is that precision issues show up if you go too far outside 4096 with smaller texture scales on surfaces, making it extremely ill-advised to go that far from 0 0 0. Regardless, did you make sure to edit the VHLT for Pathos as well to use the new 32-bit integer types and recompiled the map with the new binaries?

i have for vhlt tho i havent changed int16 in dbspv1node_t cuz i cant figure out where the similar int16 is for the vhlt, im pretty much trying to make engine be more openworld  pretty much since im making my own engine based on pathos, i will see about int16 at dbspv1node_t however

yup it wasnt the dbspv1node_t being int16 as i just figured out where it was located in csg.h

commenting out r_setfrustum here fixes issue  so its 90% frustum issue, thing is i checked every param inputed into frustum and it seems correct

I am going to look into this deeper, but at the moment I am struggling with ill health so it'll take a bit longer. In the meantime please send me your latest BSP file with the increased integer types for the mins/maxs to<EMAIL_ADDRESS>so I can check on it.

I am going to look into this deeper, but at the moment I am struggling with ill health so it'll take a bit longer. In the meantime please send me your latest BSP file with the increased integer types for the mins/maxs to<EMAIL_ADDRESS>so I can check on it.

was gonna send but decided to recompile map to be sure and now it doesnt work and it happens with every map very strange i have never had this before

well i somehow managed to break even bsp textures loading in my branch past the map limit so at this point its probably not even worth it and i agree on map limit i guess its just not worth it


Side menu container view shadow

One should be able to change side menu container view shadow.
Either make sideMenuContainerView public property or add some instance methods that would allow this kind of change.

oh, thanks for pointing to this!


Expose chain_id to Stan programs

Summary:
expose chain id as variable to Stan programs
Description:
In some applications it would be useful to have the chain id available in a running Stan program. Essentially this allows to create a big, single data set and select in the Stan program a sub set of the input data to be processed in a given chain.
Reproducible Steps:
Currently one has to copy the data set for each started chain and include the chain number as data. This is a nasty workaround as it results in many copies of the data.
Current Output:
Its not there yet.
Expected Output:
Have a variable "chain_id" defined in the Stan program which is the chain id.
Additional Information:
Current Version:
v2.10.0

We are not going to expose new variables.  It would be a function chain_id()

If we have the transformed data vary according to chain ID, then we'll still have to copy everything.  The data is stored as member variables in the model class, and if it needs to vary across chains, we'll have to copy everything anyway.

allow in transformed data or not; including it in transformed data means no multi-threading because we can't share a single instantiated model among threads

I really don’t like exposing chain_id in the models as it breaks
the encapsulation of the model and the surrounding algorithms.
If data needs to be separated that really should be done
externally in the interfaces and then run in separate calls
to Stan.
On Jul 21, 2016, at 4:52 PM, Bob Carpenter<EMAIL_ADDRESS>wrote:

We are not going to expose new variables. It would be a function chain_id()
If we have the transformed data vary according to chain ID, then we'll still have to copy everything. The data is stored as member variables in the model class, and if it needs to vary across chains, we'll have to copy everything anyway.
allow in transformed data or not; including it in transformed data means no multi-threading because we can't share a single instantiated model among threads
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@bob-carpenter : A function would be just fine. I intent to use S draws for each chain. For that I generate a matrix S x C (as data) when C is the maximum number of chains I run. In each given chain I just select the correct column. This way I get S draws which are different from chain to chain.
@betanalpha Not sure if I get this point... I would just like to avoid copying data around. How about enabling multiple input files for cmdstan instead? This would also solve the problem elegantly by allowing to specify a data-file which is the same across all chains and a chain specific one in addition. Is that better?
Maybe we discuss this next Stan meeting.

Multiple input files would be the easiest thing to do. In order to provide
the chain id as a function, we'll need to pass that info around somehow.
It's not a property of the Stan program. It can be done, but it'll take
some effort, I think.
Daniel
On Fri, Jul 22, 2016 at 8:47 AM, wds15<EMAIL_ADDRESS>wrote:

@bob-carpenter https://github.com/bob-carpenter : A function would be
just fine. I intent to use S draws for each chain. For that I generate a
matrix S x C (as data) when C is the maximum number of chains I run. In
each given chain I just select the correct column. This way I get S draws
which are different from chain to chain.
@betanalpha https://github.com/betanalpha Not sure if I get this
point... I would just like to avoid copying data around. How about enabling
multiple input files for cmdstan instead? This would also solve the problem
elegantly by allowing to specify a data-file which is the same across all
chains and a chain specific one in addition. Is that better?
Maybe we discuss this next Stan meeting.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/stan/issues/1968#issuecomment-234534470, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAZ_F-Xoj832y9cSe7cxffL9sV2r3Fcuks5qYLvcgaJpZM4JRgHE
.

When we run multiple chains, we copy all the data anyway.  It'd
require a cross-platform multi-threading solution to avoid copying
data.  And that would slow down autodiff by about 20% based on our
early evaluations, but that was many compiler versions ago.  The
only way I know how to do this is to make the global autodiff
stack thread local.
I'm also sympathetic to Michael's point, which is that the
abstraction of the model class right now does not depend on
the chain ID.  Every time we add more bells and whistles like
this, we break simple invariants on the classes, which makes
everything harder to reason about and adds long-term maintenance
overhead to all of the internals and interfaces.  So I'd rather
avoid that if all possible

Bob

On Jul 22, 2016, at 9:29 AM, Daniel Lee<EMAIL_ADDRESS>wrote:

Multiple input files would be the easiest thing to do. In order to provide
the chain id as a function, we'll need to pass that info around somehow.
It's not a property of the Stan program. It can be done, but it'll take
some effort, I think.
Daniel
On Fri, Jul 22, 2016 at 8:47 AM, wds15<EMAIL_ADDRESS>wrote:

@bob-carpenter https://github.com/bob-carpenter : A function would be
just fine. I intent to use S draws for each chain. For that I generate a
matrix S x C (as data) when C is the maximum number of chains I run. In
each given chain I just select the correct column. This way I get S draws
which are different from chain to chain.
@betanalpha https://github.com/betanalpha Not sure if I get this
point... I would just like to avoid copying data around. How about enabling
multiple input files for cmdstan instead? This would also solve the problem
elegantly by allowing to specify a data-file which is the same across all
chains and a chain specific one in addition. Is that better?
Maybe we discuss this next Stan meeting.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/stan/issues/1968#issuecomment-234534470, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAZ_F-Xoj832y9cSe7cxffL9sV2r3Fcuks5qYLvcgaJpZM4JRgHE
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

As discussed during the meeting there appears not to be any use case by others. As I can work around this by some scripting, I am closing this issue.


Add sdk attribute

@getsentry/python
Refs getsentry/sentry#2599

lgtm.

After upgrade raven, we got this error in Sentry (version 8.3.2):
There was 1 error encountered while processing this event

Discarded invalid parameter 'sdk'

{
  "name": "sdk"
}

SDK is new in 8.4. You can ignore this warning.


Misaligned indentation

The Title property in the Book class from step 2 was one space misaligned.

Thank you for your help.


Adds support for subtitles

Support for playing subtitles alongside your video files. Note that this only works if you have CORS enabled both on your server where the subtitles and the video files are stored.
I have not figured out yet how to change the subtitles while the video is still playing

Looks good. One minor comment and you have a few trailing whitespaces (see build errors). Can merge when both addressed.

Alright, pushed :+1:

Still linting build errors…

Sorry, was not looking closely enugh

Looks good 🐬


Remove Sequential.model deprecation warning

Description:
Sequential.model has a deprecation warning. This removes said warning:
"UserWarning: `Sequential.model` is deprecated. `Sequential` is a subclass of `Model`, you can just use your `Sequential` instance directly."
This is more important for tf.keras because it does not implement the deprecated .model property. It actually raises an exception (https://github.com/tensorflow/tensorflow/issues/18908)
Unfortunately I do not have open source approval (yet) to submit this to TensorFlow also...

Given that without the model.build() the plot looks funky, I think it's on the safer side to only remove the one dead line.


feat: README clean up on installation, menu and formatting

Issue #, if available:
Description of changes:
Changes made in this PR:

Formatting issues under Package and Deploy section
Emphasis on sam init under Usage
Rename Upgrading from... to Upgrading and inverted instruction order
Add explicit command on update preferred shell configuration under Installation
Updates menu and removes redundant info on install/troubleshooting
Separate Pyenv and other advanced installation to another section
Adds Path adjustment procedure along with installation
sam formatting issue
Removes redundant Py2.7 verification (pre-req + validation + verification)
Emphasize OSes and adds link to Docker file sharing options
Emphasis on py3 support pre-req

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@heitorlessa  Can you rebase and fix the README.rst conflict? I'd like to get this PR merged

Working on that now...

Done - Rebase and merge conflicts are now complete and pushed to this PR.
CC: @sanathkr  @jfuss

Great call Jacob - I missed those indeed.
Will we them fixed tomorrow
On Mon, 18 Jun 2018 at 22:03, Jacob Fuss<EMAIL_ADDRESS>wrote:

@jfuss requested changes on this pull request.
There are a couple spots that didn't get updated when you rebase the head
of develop here. Can you address them? They are all centered around Py2/Py3.
In README.rst
https://github.com/awslabs/aws-sam-cli/pull/452#discussion_r196205274:

@@ -818,7 +730,76 @@ host machine.

.. code:: powershell

sam local invoke --docker-volume-basedir /c/Users/shlee322/projects/test "Ratings"

$ sam local invoke --docker-volume-basedir /c/Users/shlee322/projects/test "Ratings"

+Advanced installations
+----------------------
+
+Build From Source
+~~~~~~~~~~~~~~~~~
+
+First, install Python(2.7) on your machine, then run the following:
Shouldn't this now be 2.7 or 3.6?
https://github.com/awslabs/aws-sam-cli/blob/develop/README.rst#build-from-source
In README.rst
https://github.com/awslabs/aws-sam-cli/pull/452#discussion_r196206014:

+1. TLSV1_ALERT_PROTOCOL_VERSION:
+
+If you get an error something similar to:
+
+::
+

Could not fetch URL https://pypi.python.org/simple/click/: There was a problem confirming the ssl certificate: [SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:590) - skipping

+then you are probably using the default version of Python that came with
+your Mac. This is outdated. So make sure you install Python again using
+homebrew and try again:
+
+.. code:: bash
+

$ brew install python@2

Can we just push to use brew install python instead? Given the 2.7
deprecation path (yes still a year and a half away but...), it might be
best to just push installation to Py3? At very least, we should call out
just doing brew install python (which is what we already have:
https://github.com/awslabs/aws-sam-cli/blob/develop/README.rst#mac-issues)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/awslabs/aws-sam-cli/pull/452#pullrequestreview-129714769,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADL4BBT5vLEuO-HxaH46KQlln7DpenOCks5t-AefgaJpZM4UWyCo
.


feaLib source debugging

This PR is not entirely serious. It's a terrible hack and probably breaks all kinds of abstraction boundaries. But I am using it in my work and it's extremely helpful, so maybe there's a germ of an idea in here worth discussing.

Implement the non-standard Debg table, a reverse-DNS namespaced JSON dictionary for holding debugging metadata.
For each lookup built by feaLib.builder, add an entry into the Debg dictionary with the original lookup name (if any), feature name / script / language combination (if any), and original source filename and line location.
Annotate the ttx output for a lookup with the information from the Debg table.

The end result is ttx files that look like this:
      <!-- ybmkmk: features.fea:84:1 in mkmk (arab/dflt) -->
      <Lookup index="39">
        <LookupType value="6"/>
        <LookupFlag value="2"/><!-- ignoreBaseGlyphs -->
        <!-- SubTableCount=1 -->

This PR is not entirely serious.

That's what draft mode PR's are for ;-) Conversion link under the Reviewers in the sidebar.

In theory... in practice, draft mode means "everybody else ignore this until I'm done."

This is now as good as it needs to be technically (IMO), but I am still not sure it should be done!
The positive is some very helpful debugging information, which can also be used by other applications (again, I'm already doing this); the cost is that it introduces a new[1] non-standard and undocumented[2] OT table and creates a complicated special-case in the serialization of lookups.
I'd like to make sure that people are OK with that cost, so would like opinions from others before merging. @justvanrossum, @dscorbett, @brawer?

The reason I didn't use meta is that the intent for Debg is that it can be stripped to produce a production font, while meta should be retained.
And undocumented, although I can easily fix that in CommonType.

I think it’s okay to introduce a non-standard table, as long as it is opt-in and its tag is neither all uppercase nor all lowercase. The cost of an undocumented table is especially low: if there is no documentation, there are no backwards compatibility constraints.
As for the special-case cost for developers, I don’t think it’s too bad, because it is so very useful, but perhaps it could be less of a special case while still being as useful. What if instead of having special code in LookupList.toXML2 (and any other tables for which debugging information is added), the structure of the stored JSON reflects the nested table structure? The XML writer could know that for every structure it writes, it should check the 'Debg' table for nested keys based on the position of that structure (e.g. {"GSUB": {"LookupList": ["features.fea:4:5 in ccmp (DFLT/dflt)", ...]}}). That would make it no longer specific to feaLib. It would also mean that feaLib would have to format the lookup name, tag, script, and language into a string instead of an array, because a generic mechanism wouldn’t know what to do with an array. Maybe this is too complex to bother doing. As long as there’s no documentation, or the documentation makes few guarantees, it can be done later.
table_D__e_b_g.toXML can produce invalid XML, but that’s not a problem specific to this table.
It is unfortunate that LOOKUP_DEBUG_INFO_KEY should begin with “com.github.fonttools” instead of “io.github.fonttools”, since only the latter is a reversed domain name controlled by the fontTools organization. For consistency with ufoLib I guess it’s okay.
FontForge has its own debug table: 'PfEd'. It might have some good ideas for future extensions to 'Debg'.

I don't like the storage of the 'feature identification' attribute for lookups.  If I understand correctly, the intention is that for each lookup there will be stored a triple of (source location, lookup name, feature identification).  Feature is primarily a triple of {script, language, feature) - I presume the last is the 4-letter tag.
When a font supports multiple languages with distinctive rendering, most lookups will be used for most of the languages.  Looking at the code, it seems that the (script, language, feature) combination stored will be the last one.  One way round this is to have different lookups for different combinations of script, language and feature.  At the source code level, this would be bad to inconvenient, depending on how it was implemented.  (Commonality could be maintained by use of include files, but even so.)  However it was implemented, it would require debug data to be stored for each new lookup, with at the very best extra maps from lookup to offset of the lookup definition.
A better solution would be to  store a list of 3-element feature identifications.  This would require less debug storage than multiplying lookups, and would avoid increasing complexity in the compilation or encoding of a font.
However, I'm not sure why one needs to store this feature identification in the debug table.  The information is already stored in the GSUB and GPOS tables.  Is it just to speed up access?  The lookup name and source location are, however, useful.

One way round this...

I'm not sure why you don't like the storage, or what the problem is that you're trying to get around, so my responses below might not be addressing the problem you're talking about. Can you explain what it is that seems wrong about this?

A better solution would be to store a list of 3-element feature identifications.

Such a list would be indexed by lookup ID, right? Isn't that what this patch does - links lookup IDs to 3-element feature identifiers?

This would require less debug storage than multiplying lookups, and would avoid increasing complexity in the compilation or encoding of a font.

It certainly wouldn't be correct for debugging annotations to change the way that lookups are laid out, but even if it was, in a debugging build, I don't think that how much extra storage the debugging info takes up should be a consideration. Just strip it out if you want an optimized file.

I'll give a real example not crafted by me.  In the DejaVu Sans font (book, Version 2.30),  substitution lookup 2 occurs in the feature ccmp in the Latin script for the default language and the languages ISM, KSM, LSM, MOL, NSM, ROM, SKS and SSM.  I think that with the current code, if one recompiled the font (preserving functional equivalence), as is legal, that will end up as being recorded as saying that GSUB lookup 2 is used by the combination ["Latn", "SSM ", "ccmp"], with no mention of the other Saami languages, let alone the default.  I don't see any use in recording that in the debug table.  (I'm writing arrays for fixed lists of fields.)  In full, the record would be something like.  That it pertains to lookup 2 is recorded by its being the third element in the array of 'lookup locations'.
What I'm suggesting as a way of recording the lookup location in a programmer-friendly way would be something like:
["location":"dejavusans.txt:7123:3", "name":"slkp2", "feature":[ ["Latn", "default", "ccmp"], ["Latn", "ISM ", "ccmp"], ["Latn", "KSM ", "ccmp"], ["Latn", "LSM ", "ccmp"], ["Latn", "MOL ", "ccmp"], ["Latn", "NSM ", "ccmp"], ["Latn", "ROM ", "ccmp"], ["Latn", "SKS ", "ccmp"], ["Latn", "SSM ", "ccmp"]]]
In a more limited fashion, substitution lookup 0 occurs in feature locl but only for the Romanian and Moldavian languages, in the Latin script.
Or have I badly misread the code, and you are doing this already?
Storing the data this way is no more excessive than any other way of doing it.
Releasing code with debugging information helps others investigate any problems for one.  As there are no trade secrets in my fonts, my only objection to documenting them is the effort it takes.  I'd rather release a font with the debugging information in it.

I'm not sure that what you're saying is correct. We can distinguish between "preamble" lookups and "feature" lookups in AFDFO syntax:
# Preamble lookups here

# lookup 0
lookup thing {
  ...
} thing;

feature ccmp {
    # Feature lookups here
    sub foo by bar; # lookup 1

    script arab
    language URD;
    sub baz by quux; # lookup 2

    script arab;
    language ARA;
    lookup thing; # reference to lookup 0
};

Preamble lookups don't get a feature identification entry in the debug tuple, but feature lookups do: so lookups 1 and 2 will have such entries, 0 will not. And 0 will be the lookup that is shared, potentially between many features.
In other words, the debug info stores information about where the lookup is defined, not where it is "used".

OK.  The way I allocate lookups to features, everything would be a preamble lookup.  Moreover if you want to know what features a lookup is in, you have to use the GSUB/GPOS tables.

Well, this PR is specifically a feaLib debugger! Still, you can use tools based on it if you persuade your compiler to place relevant values in the right places in the Debg table. If they’re all shared lookups, then leave the third member of the tuple empty.


Port Calcite's tests to run with MSQ

Description
Calcite's test framework has been revamped recently to reduce the dependence on statically created objects and inject the dependency via Guice. This unlocks the ability to inject MSQ-specific dependencies and test out the existing Calcite's tests using the MSQ engine.
Changes accomplished in the PR:

Inject MSQ's specific objects using Guice so that the code path to run the tests via Guice exists.
Refactor the existing test runner
a. Run steps are now chained together so that one run step can use the results obtained from the previous run step and the final run step's results are used in the verification
b. The query context is now not taken into account while verifying the queries
c. Add the support to add custom verifications
The MSQ has an extract step that allows the query results to be extracted from the reports before they are verified.

Key changed/added classes in this PR

MSQTestBase
CalciteSelectQueryTestMSQ
QueryTestRunner

This PR has:

[ ] been self-reviewed.

[ ] using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)

[ ] added documentation for new or modified features or behaviors.
[ ] a release note entry in the PR description.
[ ] added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
[ ] added or updated version, license, or notice information in licenses.yaml
[ ] added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
[ ] added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
[ ] added integration tests.
[ ] been tested in a test Druid cluster.

One issue with the tests being written in sql module and the MSQ-related stuff being in the druid-multi-stage-query module has been that we are not able to setup the MSQ-related stuff in the sql module as sql does not contain MSQ as a dependency. After an offline discussion with @paul-rogers and @cryptoe, documented below are the few approaches that we can take up.

Remove the dependency of sql on druid-multi-stage-query by breaking the coupling, add druid-multi-stage-query as a dependency of sql and proceed as mentioned above. However since currently MSQ is present as an extension, this dependency of MSQ on sql seems slightly weird. This approach however would be pretty clean.
Use one of the test case definitions like the one proposed in https://github.com/apache/druid/pull/13106 to make the test cases independent from the execution which would also help the PR. This would also help prevent the duplication of tests in the Druid Catalog.
Add the druid-multi-stage-query as a runtime dependency to sql (not sure how this would have worked out, just an idea at this point).
Inherit the tests from the sql in the druid-multi-stage-query, override the methods that will help add the msq tests and add the plumbing. The only drawback of this approach is that debugging the individual test cases would be difficult since there won't be a run configuration corresponding to them. However that's a minor dev discomfort. Therefore going down with this approach.


diablo II ran with the d2dx wrapper fails to create a vulkan 1.1 instance

d2dx is a glide-wrapper than turns diablo II into a well behaved directx 11 window. when ran with the latest dxvk release and the latest dxvk-bin from the aur, the game does not launch and instead shows a d2dx error and crashes.
Software information
Diablo II ran with glide (3dfx) through the d2dx wrapper
System information

GPU: NVIDIA GeForce GTX 680
Driver: 465.31
Wine version: wine-staging 6.11
DXVK version: 1.9 and 1.8.1

Apitrace file(s)
trace.tar.gz
i don't know if this is traceable. it says that it never used the dxgitrace.dll but here's the one i got out of it just in case.
Log files

d3d11.log: Game_dxgi.log
dxgi.log: Game_d3d11.log

That's some sort of setup issue on your end.

thank you. i was missing lib32-nvidia-utils.
now i can get the game working through d2dx without dxvk, but it doesn't work with reshade. if i add in reshade then a lot of the game's textures are missing and it's not playable. and since the game works just fine with wine3d, i can't get an apitrace.
if i run it through dxvk, reshade or not, i get:

err:   DxvkSubmissionQueue: Failed to sync fence: VK_ERROR_DEVICE_LOST
err:   DxvkSubmissionQueue: Command submission failed: VK_ERROR_DEVICE_LOST

d3d11.log: Game_d3d11.log
dxgi.log: Game_dxgi.log

driver crash, could be all sorts of things. Really need an apitrace to debug that, and if it works fine with wined3d then I don't see why you couldn't get one.

maybe i'm doing it wrong, but when i launch an apitrace, the game runs like normal and once i close it there's no game.trace and it says:
apitrace: unloaded from C:\Program Files\Diablo II\ProjectD2\Game.exe
warning: C:\Program Files\Diablo II\ProjectD2\apitrace-10.0-win32\bin\..\lib\wrappers\dxgitrace.dll was never used: application probably does not use this API
i launch the apitrace with this command:
wine apitrace-10.0-win32/bin/apitrace.exe trace -a dxgi Game.exe -3dfx
and i have added and replaced the neccesary dlls from apitrace (d3d11.dll, dxgi.dll, and dxgitrace.dll), as well as the dll overrides for these. i've tried both -a dxgi and -a d3d11 with the same results.

do you have the DLL overrides for d3d11 and dxgi set to native,builtin? If so, that should work.

that was it, the dll overrides were missing. i think i forgot to add them back when i reset the prefix while troubleshooting
though now the game crashes when i run the apitrace correctly so i don't know if it'll be useful.
trace.tar.gz

sigh, no, not useful since it looks like it somehow managed to crash during device creation for some reason.
You don't happen to have access to a Windows machine to do the whole trace thing on?

yes i do! here's the apitrace from windows
Game.zip

Thanks. Does the commit above fix the issue? Build should be available here in a few minutes.

yes it does, everything works perfectly now, thank you so much!


Subscription Based API

Hey @falood, I wanted to get your feedback on this so far

I created a subscription-based API to ExFSWatch.Worker, so you can now subscribe to get messages from it.
I rewrote the Module based API to spawn a process that subscribes to events and calls the callbacks accordingly
I added a behaviour for ExFSWatch.Backend

Questions:

Do we need a supervisor still? Should subscription clients get a supervised worker or just spawn_link it directly?
Should we move subscribe/1 and spawn_link/1 to the main ExFSWatch module for a friendlier API?

TODO:

[ ] Write tests for both subscription & module based api.

@mveytsman Thank you for your great job!
I think it's better to move subscribe/1 and start_link/1 to main ExFSWatch module 🙂
For the supervisor, I think we should keep it, at least we need it for the child_spec now, but we can remove it after we change the package name.
btw, is there a recommend name?

close this issue, move to #26


Fix Invalid layout for (number) <RCTView

This fixes the issue, should be merged. Thanks @rezof

Thanks!


Added parenthesis around size to make it possible to use addition and…

… subtraction in expression when allocating array.

This would fix #878.

This was fixed by https://github.com/fasterthanlime/rock/commit/a1a3fd5646e4499525cb63eceb4fa1da1d4c335e. @fredrikbryntesson, this can be closed.

Ah, apologies @fredrikbryntesson, completely missed that pull request. Fixed in master!


Add prvExerciseTaskHeapAllocationStats() to the MSVN Win32 and MPS2 Q…

Description
Add prvExerciseTaskHeapAllocationStats() to the MSVN Win32 and MPS2 QEMU IAR demos to exercise the function that track memory allocations on a task by task basis as introduced by https://github.com/FreeRTOS/FreeRTOS-Kernel/pull/353.
Test Steps
Run "full" build of the MSVN Win32 demo and MPS2 QEMU IAR demos.
Related Issue
https://github.com/FreeRTOS/FreeRTOS-Kernel/pull/353
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Closing this one as we have closed the related kernel PR.


List::classify &as documentation missing.

For lists it is possible to map classified value by using "as" option
say (1,2,3).classify( {  }, :as{  })

And while this is well documented in Hash::classify-list https://docs.perl6.org/routine/classify-list#:&as_value_modifier it should also be documented under List::classify here https://docs.perl6.org/routine/classify .

.classify is actually a method on Any and Supply, not List, so that would need to be amended as well. It's probably best to document it in a way where we can just tell the reader to go read .classify-list docs, since .classify basically just reorders the args and forwards to .classify-list.
Raking through Rakudo's source I see it takes :into arg that is also undocumented. I'm unsure whether that's part of the spec or not


Update index.md

Just removing an excessive word. Spell correction.

@EirikHaughom : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Looks good; thanks.


Option to disable scroll into view on Item selection

I have used chrono by hiding the cards , on item selection , i am manually loading a div below the horizontal timeline , without using the card.
Issue  : The scroll position of the container div gets lost on click.
I think it is due to focus Js , is there any way to just disable the focusing functionality ?

currently there is no way to disable auto focus. i am planning to include a prop to disable this behavior.

use disableAutoScrollOnClick  to disable the auto scrolling.


feat: add document retries

~Blocked by https://github.com/elastic/go-docappender/pull/100 (to make testing easier)~
~Add document retries logic. Followup to https://github.com/elastic/go-docappender/pull/91 (important to understand how the compression logic changed)~
~### Compression off:~
~In this case we simply iterate over the array and submit the failed events to the buffer. We can count them using newlines.~
~### Compression on:~
~Retrieve the offset of the failed event and decompress the "gzip container". Loop over the array and submit the failed event to buffer.~
Testing
This PR adds tests to cover as mush edge cases as possible: one event for each gzip container, multiple events per gzip container, all events in a gzip container. Tests also verify the retry logic twice to ensure there are no conflicts between flushes.
Update:
Changes:
the approach was simplified: iterate over the array and resubmit the failed events to the buffer. For gzip we read in batches to avoid decompress the whole request.

The bench-diff check is green, but looking at the logs, some benchmark errors happened; please take a look and either fix the issue or loop in the automation team, in case it's not legit errors.

Also, have you run some benchmarks using the tilt environment and monitoring how the metrics look? I think it's worth doing so before merging.

I only run benchmarks using the appender benchmarks in the repo but can you clarify this so we are aligned ? Are you asking to test the performance of the retry code or the overhead on the "normal operation" (requests succeed) ?

I do not want to speak for Marc, but IMO we should have some numbers on how this impacts overall performance. I would expect

no performance change if there are no retries
retry behavior to add only a reasonable amount of overhead, but slowing down the processing of new events

Testing this e2e under load in a dev environment is essential before starting the promotion process.

@simitt, that's right.
@kruskall, I'll leave it up to you whether you want to test this as part of the dependency update or as part of the PR. If we go the dependency promotion path, we may approve the PR without any regression testing. I understand the retry behavior is opt-in rather than opt-out, but that's what regression testing is for.


Updated language of CODE_OF_CONDUCT.md

Title and Issue number

Title : Updated language of CODE_OF_CONDUCT.md
Issue No. :
Code Stack :
Close #<issue_no>

Checklist:

[] I have mentioned the issue number in my Pull Request.
[] I have commented my code, particularly in hard-to-understand areas
[] I have created a helpful and easy to understand README.md
[] I have updated the Index.html file for my contribution

Code of conduct is generated by Github. Why are we modifying it?


docs: Explain Python 2/3 virtualenvs.

This adds a brief explanation on how to switch Python versions using the virtualenvs.
Came across this myself, and as Tim pointed out it might be useful to have it documented.

Merged, thanks @YagoGG!


[Datagrid]: using MultiSelect filtering with instant update is broken

Package
Carbon for IBM Products
Description
i discovered this after discussing a separate issue from slack:

in order to be more aligned with carbon functionality MultiSelect should be passing the entire event object to the consumer and not just { selectedItems }

while investigating i also discovered these:

using MultiSelect with batch filtering throws a console warning: Warning: Cannot update a component ('FilterFlyout') while rendering a different component ('MultiSelect'). To locate the bad setState() call inside 'MultiSelect', follow the stack trace as described in...
using MultiSelect with instant filtering breaks the app a.filter is not a function

Component(s) impacted
Datagrid
Browser
Chrome
@carbon/ibm-products (previously @carbon/ibm-cloud-cognitive) version
2.47
Suggested Severity
Severity 1 = The design is broken in a critical way that blocks users from completing tasks or damages the brand. Affects major functionality, no workaround.
Product/offering
ibm products
CodeSandbox or Stackblitz example
https://carbon-for-ibm-products.netlify.app/?path=/story/ibm-products-components-datagrid-filtering-panel--panel-instant&globals=viewport:basic
Steps to reproduce the issue (if applicable)
for the broken instant update:
go to the storybook, open the filter, and select an option under one of the multi select drop downs.
for the batch update warning:
this only appears locally. run storybook locally and open the batch update story. select an option from one of the multi select drop downs.
Release date (if applicable)
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct
[X] I checked the current issues for duplicate issues

@AlexanderMelox If you self-assign, make sure to add to backlog and add estimate. :)


dr s, sh 8

case: dr s, sh 8
actual: dr -> 20, shaman -> 1
expected: dr -> 20, shaman -> dead

This would be fixed by embedding splash management into the combat calculation, right? @ibratoev

This is actually not a real bug. Tested in Polytopia and the result was the actual here. So it is not really a bug.
@veerjd Close it?

The calc changes 'fixed' it

The calc changes 'fixed' it


Incomplete usage (requirements) description

The project requires base-4.12 package which is provided for ghc-8.6.x according to https://wiki.haskell.org/Base_package.
It would be useful to provide required ghc version in the README.md or the link above to help the user figure out target ghc version.

@milochadam I mentioned the expected version of GHC in README. Plus I configured stack build which automatically downloads the required version of GHC for you.
Please check it out and close the issue if your concern was addressed appropriately.

Looks good to me! :+1:
Thank you for your contribution!


code and token needed for google plus

Hello again. I successfully have this working with Google, but the problem is that the access token expires in an hour. To get around this problem, Google recommends a hybrid server-side flow "where a user authorizes your app on the client side using the JavaScript API client and you send a special one-time authorization code to your server". However, to implement, I need the access code returned by Google and this library only returns the token.
Thanks again for your help and excellent open source libraries.

I've set ngCordova to use implicit grants whenever possible since it adheres to the client side guidelines.  This results in a token that expires after time and cannot be refreshed without signing in again.
If you need more information in the request to make it work with your third party tools, I suggest you fork this repository.
Regards,

Also, access code probably is the same as access token.
All other tokens such as request tokens would be useless to keep.
Regards,


Center loss, Regularization loss, Cross Entropy is strange.

I train the facenet with center loss on MS Celeb 1M.
I put center and regularization loss log with cross entropy.

training parameters is --weight_decay 5e-5 --center_loss_factor 5e-5 --center_loss_alfa 0.9.

Is useful center loss? I show the center loss value is very small in total loss.
Is not strange the regularization loss?

Closing this for now. Reopen if needed.


jitsi-meet-electron: init at 2.0.0

Motivation for this change
Fixes https://github.com/NixOS/nixpkgs/issues/84082
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

I tried to package $pname but I am stuck at the point where running the binary ends up with the following:
Error launching app
Unable to find Electron app at /nix/store/kr1wxwv7j8r0nz8vcy5lbzal1gapbw7f-jitsi-meet-electron-2.0.5/share/jitsi-meet-electron

Cannot find module '/nix/store/kr1wxwv7j8r0nz8vcy5lbzal1gapbw7f-jitsi-meet-electron-2.0.5/share/jitsi-meet-electron'
Require stack:
- /nix/store/3cbprqw7nvnp8imp8y5ih24d8x556vpn-electron-8.0.0/lib/electron/resources/default_app.asar/main.js
-

Maybe someone with more Electron experience can help me here?

I tried to package $pname but I am stuck at the point where running the binary ends up with the following:
Error launching app
Unable to find Electron app at /nix/store/kr1wxwv7j8r0nz8vcy5lbzal1gapbw7f-jitsi-meet-electron-2.0.5/share/jitsi-meet-electron

Cannot find module '/nix/store/kr1wxwv7j8r0nz8vcy5lbzal1gapbw7f-jitsi-meet-electron-2.0.5/share/jitsi-meet-electron'
Require stack:
- /nix/store/3cbprqw7nvnp8imp8y5ih24d8x556vpn-electron-8.0.0/lib/electron/resources/default_app.asar/main.js
-

Maybe someone with more Electron experience can help me here?
The directory under ..../share/jitsi-meet-electron contains the following:
./resources/app.asar
./locales/*.pak

Your  --add-flags in the wrapper needs to be directly to the asar archive file.

I fixed the issues and the PR is ready for review.

@prusnak Not wrapping in this app would make this package dependent on https://github.com/NixOS/nixpkgs/issues/84913 being fixed. I reccommend just adding a todo and reference to the issue in code, and in the thread.

The package works for me as is without any problems.
If there is a need to wait for #84913 to be merged before this goes in, I am more than fine to wait.

Works fine for me :+1:

Likely your environments are polluted by wrapped programs. If it has any sort of file chooser it will likely crash without the gtk schema.

It seems there are not native dialogs in the app, that's why I was not able to cause a crash.

Result of nixpkgs-review pr 84981:
1 package marked as broken and skipped:

hyper-haskell

11 package built:

electron
electron_5
electron_6
electron_7
electron_8
nix-tour
rambox-pro
riot-desktop
stretchly
teleprompter
typora

I've tried the file open dialog (through "upload file") in the resulting riot-desktop application and it works fine. (I assume file open dialog is a native dialog, isn't it?)

Thanks @prusnak :sparkles:


Add volumeClaimTemplate as a Workspace volume source

Changes
An existing PersistentVolumeClaim can currently be used as a Workspace
volume source. There is two ways of using an existing PVC as volume:

Reuse an existing PVC
Create a new PVC before each PipelineRun.

There is disadvantages by reusing the same PVC for every PipelineRun:

You need to clean the PVC at the end of the Pipeline
All Tasks using the workspace will be scheduled to the node where
the PV is bound
Concurrent PipelineRuns may interfere, an artifact or file from one
PipelineRun may slip in to or be used in another PipelineRun, with
very few audit tracks.

There is also disadvantages by manually creating a new PVC before each PipelineRun:

This can not (easily) be done declaratively
This is hard to do programmatically, because it is hard to know when
to delete the PVC. The PipelineRun can not be set as OwnerReference since
the PVC must be created first

This commit adds 'volumeClaimTemplate' as a volume source for workspaces. This
has several advantages:

The syntax is used in k8s StatefulSet and other k8s projects so it is
familiar in the kubernetes ecosystem
It is possible to declaratively declare that a PVC should be created for each
PipelineRun, e.g. from a TriggerTemplate.
The user can choose storageClass (or omit to get the cluster default) to e.g.
get a faster SSD volume, or to get a volume compatible with e.g. Windows.
The user can adapt the size to the job, e.g. use 5Gi for apps that contains
machine learning models, or 1Gi for microservice apps. It can be changed on
demand in a configuration that lives in the users namespace e.g. in a
TriggerTemplate.
The size affects the storage quota that is set on the namespace and it may affect
billing and cost depending on the cluster environment.
The PipelineRun or TaskRun with the template is created first, and is used
as OwnerReference on the PVC. That means that the PVC will have the same lifecycle
as the PipelineRun.

How it works
When using a volumeClaimTemplate workspace on a PipelineRun:

Before the first TaskRun is created; a PVC from the template is created - with the PipelineRun as OwnerReference.
The volumeClaimTemplate workspace is translated to a PersistentVolumeClaim workspace when creating TaskRuns.
Whenever the PipelineRun is deleted, the PVC is also deleted.

When using volumeClaimTemplate workspace on a TaskRun not initiated from a PipelineRun:

Before the Pod is created; a PVC from the template is created - with the TaskRun as OwnerReference.
The volumeClaimTemplate workspace is translated to a PersistentVolumeClaim workspace when creating the Pod.
Whenever the TaskRun is deleted, the PVC is also deleted.

Example usage:
apiVersion: triggers.tekton.dev/v1alpha1
kind: TriggerTemplate
metadata:
  name: pipeline-template
spec:
  resourcetemplates:
  - apiVersion: tekton.dev/v1beta1
    kind: PipelineRun
    metadata:
      generateName: simple-pipeline-run-
    spec:
      pipelineRef:
        name: simple-pipeline
      workspaces:
      - name: ws
        volumeClaimTemplate:
          metadata:
            name: ws-pvc
          spec:
            accessModes: ["ReadWriteOnce"]
            resources:
               requests:
                  storage: 1Gi

Related to #1986
See also:

#2174
#2218
https://github.com/tektoncd/triggers/issues/476
https://github.com/tektoncd/triggers/issues/482
https://github.com/kubeflow/kfp-tekton/issues/51

Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:

[x] Includes tests (if functionality changed/added)
[x] Includes docs (if user facing)
[x] Commit messages follow commit message best practices

Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.
Release Notes
Add volumeClaimTemplate as a Workspace volume source

When using volumeClaimTemplate as volume source for a PipelineRun, the
tekton-controller will create a PersistentVolumeClaim using the template,
and be seen as a PersistentVolumeClaim for all TaskRuns in the Pipeline.
The PersistentVolumeClaim will be deleted when the PipelineRun is deleted.

/ok-to-test
/hold
Thanks very much for the PR, it's exciting to see this come together!  I'm adding the hold just so that we can raise this with the Working Group on Wednesday and share it more widely for any feedback.

There were a few lint errors, which is why pull-tekton-pipeline-build-tests failed:
I0405 12:36:03.429] ===============================
I0405 12:36:03.429] ==== RUNNING GOLANGCI-LINT ====
I0405 12:36:03.429] ===============================
I0405 12:37:09.781] pkg/reconciler/volumeclaim/pvchandler.go:4: File is not `goimports`-ed (goimports)
I0405 12:37:09.781] 	"fmt"
I0405 12:37:09.782] pkg/reconciler/volumeclaim/pvchandler_test.go:4: File is not `goimports`-ed (goimports)
I0405 12:37:09.782] 	"fmt"
I0405 12:37:09.782] pkg/reconciler/volumeclaim/pvchandler.go:54:59: S1019: should use make(map[string]*corev1.PersistentVolumeClaim) instead (gosimple)
I0405 12:37:09.782] 	claims := make(map[string]*corev1.PersistentVolumeClaim, 0)

The integration tests look like they timed out.  Re-running to check if this reproduces.
/test pull-tekton-pipeline-integration-tests

/test pull-tekton-pipeline-build-tests

/retest

I think the integration is failing because of https://github.com/tektoncd/pipeline/issues/2337 at the moment.  This is something I'd like to fix for the next point release, which is supposed to happen tomorrow.  Will try to get this resolved asap.

/hold cancel
Thanks for presenting to the WG!  Am going to work on fixing these integration tests and then will get back to this review.

Tried everything out locally and it worked like a charm!

/test pull-tekton-pipeline-integration-tests

Thanks for adding this @jlpettersson !! I'm really excited to try it out :D

@bobcatfish yes, I could improve the docs. I'll have a look tomorrow.
There is one example in v1beta1 pipelineruns: https://github.com/tektoncd/pipeline/blob/master/examples/v1beta1/pipelineruns/workspace-from-volumeclaimtemplate.yaml

@bobcatfish yes, I could improve the docs. I'll have a look tomorrow.
In addition to the example in the PR-description, there is one example in v1beta1 pipelineruns: https://github.com/tektoncd/pipeline/blob/master/examples/v1beta1/pipelineruns/workspace-from-volumeclaimtemplate.yaml

404 Page not found...


Fixed the issue #108 (quality of generated code), reduced the generated file size

Now, All the temps in the generated code is defined in this way:
float temp = ....;

instead of :
float temp;
temp = ....;

Reduce the file size.

Rebase+merge

python examples/tti_benchmark.py test -a -d 20 20 20 -n 5" exited with 139
tt_benchmark.py test only failed for OSX case.
Any idea what caused the problem？
I don't have a osx machine now.

Seems to have been a sporadic failure, but travis is now green. So merging...


⚠ Bofrost.be has degraded performance

In 1a894c8, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 2046 ms

Resolved: Bofrost.be performance has improved in 077ee5b.


Logo Change?

Hey Everyone,
So I'm going to tread very carefully here as I know that this may be quite controversial...
I went to change the logo on twitter earlier to not be the duke anymore and @karianna told me to change it back to the duke because

the Duke has a special meaning to Java developers

Everyone that I have spoken to from outside projects has expressed how pleased they are to not see "dated" java websites that have been dragged out of the 90's. I think that https://adoptopenjdk.net/ is great because it looks like a modern website and it looks like the sort of place that you would expect a good binary to be hosted.
SO...
@Joe-Brady decided to design a new logo (that is already in use on the website) and you can also see it in use on twitter as the cover picture now. The logo looks like this:

I propose that we remove the (slightly tired in my opinion) duke and replace it with a new refreshing logo that matches our website.
You can see how much better it looks on twitter here:

I appreciate that some people may be very fixed on keeping the duke and that's fine but I wanted to get the opinion of everyone in the organization before giving up and throwing the idea away
CC @AdoptOpenJDK/getopenjdk

I wonder if this gets to the heart of the split between the Adopt OpenJDK programme as a whole vs this more specific effort (which @tellison originally labelled "getopenjdk").  Maybe it is time to try something completely new - more thoughts welcome!

I possibly agree @karianna I understand that this organization has been around for a while so I don't want to come and trample all over it forcing change on people. I'm just interested to see what other members of the org want

Just to confirm, this issue isn't necessarily about saying that the new logo is the one, It's more about me saying that perhaps the existing one isn't right anymore

Just to add my 2 cents, to reiterate that this 'logo' was the result of 30 minutes' experimenting, and was originally intended as a stop-gap while we waited for a final logo and brand to be decided upon.
It seems to have stuck for the time being, and I do actually think it's a decent logo that does have some meaning in the 'several blocks/options forming a bigger block/selection' metaphor, but if there's something better that can be produced that everyone is happy with, then I am 100% behind that!

https://cloud.githubusercontent.com/assets/20224954/25402181/dcf51fde-29ef-11e7-832f-9b2168e38fc7.png - brings old memory back :+1: :cry:

AIUI the issue with the duke is that the style is seen as somewhat dated, and the issue with @Joe-Brady 's design is that it loses the duke theme.
So maybe a refreshed version of the duke that looks new and shiny but also maintains the brand recognition would be best.

I would also prefer to somehow bring the duke into the todays world instead of just dropping him.

I'm happy to go around a talk to some logo designers to see if any of them would be interested in providing us with a "sponsored" logo

I have access to designers as well (at the LJC) but I don't want to step on @Joe-Brady's toes if he wants to get his creative on first :-).

@Joe-Brady Website & Logo Design Hursley ;)

I think this is probably a bit beyond my design skills (and design software - I'm surviving on free tools), so please go ahead! No toes being stepped on over here :smile:

Calling in @kerryk!


text tokenizer max_length=35?

I found that in inference_rank(), you set the max_length for text tokenizer to 35, which means that all the text input longer than 35 will be truncated to 35 characters only? I was wondering if it's the same setting as during training, and what's the intuition behind that. Since 35 characters are actually pretty short and lots of user prompts are longer than that and the truncation may cause information loss so that the truncated text may not contain all the important elements

Seconded, I believe the normal limit is 77 tokens, so I'm wondering why it was halfed as well

Calling the tokenizer with max_length=35 is just to keep the same as settings of BLIP at https://github.com/salesforce/BLIP/blob/main/eval_retrieval_video.py#LL49C59-L49C59, it's worth trying relaxing the limit.


update cats entry

now that they merged 2.12 support
note that we are still using a fork, because of the POM issue (see
comment). but I did also bring the fork up to date with their current
master
fyi @non @adelbertc

passing locally. merging

POM issue PR: https://github.com/typelevel/cats/pull/1426


Some attributes can't be attached

Hi, I can't attach attribute type to an nft, it's always ignored.
I guess it would be cool to see the list of ignored attributes on the page where I create nft.
Thanks.

#339

@maelswarm ?

@maelswarm ?

Hey

@maelswarm is it relevant to the problem I've described? I just haven't found in common 🤔

I'm going to close it, since no feedback was given 🤓


Best model checkpoint

When using BestModelCheckpoint, the message shown Model improved from _ to _   has same value in both places. Ideally, I would expect previous val_loss and the current improvement.

on it


Add support for cluster membership changes

This is section 6 of the Raft paper. We need to stop assuming that the cluster configuration is fixed and add support for nodes joining / leaving the cluster. Implementing this implies adding support for joint consensus.

This should be done after https://github.com/andreev-io/little-raft/pull/32 goes out.