Fix Discord output's Prometheus metrics

Signed-off-by: KeisukeYamashita<EMAIL_ADDRESS>
What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area build

/area config

/area outputs

/area tests

/area helm

What this PR does / why we need it:
I found that there was a bug in Discord's Prometheus output which will mess Azure Event Hubs and Discord metrics output.
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

@KeisukeYamashita: The label(s) area/outputs cannot be applied, because the repository doesn't have them

In response to this:

Signed-off-by: KeisukeYamashita<EMAIL_ADDRESS>What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area build

/area config

/area outputs

/area tests

/area helm

What this PR does / why we need it:
I found that there was a bug in Discord's Prometheus output which will mess Azure Event Hubs and Discord metrics output.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign nibalizer after the PR has been reviewed.
You can assign the PR to them by writing /assign @nibalizer in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: cb98ffc645e6fd5d883922aae1cb93125f699e40

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Issif
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Issif]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


[AIRFLOW-1564] Add docs about default logging

The logging sub-section under Configuration does not mention
anything about the potential caveats of storing logs as ISO-8601
timestamps. In addition to this, it doesn't give any hints on how
to override the default config class.

@chribsen ... any updates? this PR will be closed in a week if there is no activity. You can ignore the travic-ci errors.

I know that @NielsZeilemaker was experiencing the same issue, he opened a pull request to fix this. Niels, can you shed a light on this?

It's the : characters, they are illegal on ntfs. I'm replacing them by a dot in our deployment

@Fokko: The PR submitted by @NielsZeilemaker makes it possible to override the default log path using jinja2 (with one obvious purpose being to make it compatible with a windows fileshare). Unfortunately, the current documentation doesn't mention this anything about this caveat.

Ideally ISO-8601 timestamp with illlegal characters substituted with _ should be used as filenames by default. Unfortunately, we still need to override this using a custom config class (for backward compatibility I guess?)

why dont we use slugify for these dates? It is already in use as part of nvd3

@chribsen @bolkedebruin Next steps!

I'm a little confused here.  As far as i  understood, the jinja2 templating isn't an actual solution for Windows, because the format of the ts variable is always in isoformat.  Given that the default is this:
FILENAME_TEMPLATE = '{{ ti.dag_id }}/{{ ti.task_id }}/{{ ts }}/{{ try_number }}.log'
What could a Windows user realistically replace this with? Perhaps:
FILENAME_TEMPLATE = '{{ ti.dag_id }}/{{ ti.task_id }}/{{ try_number }}.log'
In which case you lose the timestamp altogether.  If there is support from airflow devs, i would like to submit a PR around adding an additional variable, for example safe_ts which strips illegal NTFS characters from the string.  Perhaps it could be:
FILENAME_TEMPLATE = '{{ ti.dag_id }}/{{ ti.task_id }}/{{ safe_ts }}/{{ try_number }}.log'
Cheers

Hi Dan,
I'm actually using:
FILENAME_TEMPLATE = '{{ ti.dag_id }}/{{ ti.task_id }}/{{ ts |
replace(":",".") }}/{{ try_number }}.log'
seems to work fine on windows/ntfs.
Niels
2018-05-24 13:46 GMT+02:00 Dan Chowdhury<EMAIL_ADDRESS>
I'm a little confused here. As far as i understood, the jinja2 templating
isn't an actual solution for Windows, because the format of the ts
variable is always in isoformat. Given that the default is this:
FILENAME_TEMPLATE = '{{ ti.dag_id }}/{{ ti.task_id }}/{{ ts }}/{{
try_number }}.log'
What could a Windows user realistically replace this with? Perhaps:
FILENAME_TEMPLATE = '{{ ti.dag_id }}/{{ ti.task_id }}/{{ try_number }}.log'
In which case you lose the timestamp altogether. If there is support from
airflow devs, i would like to submit a PR around adding an additional
variable, for example safe_ts which strips illegal NTFS characters from
the string. Perhaps it could be:
FILENAME_TEMPLATE = '{{ ti.dag_id }}/{{ ti.task_id }}/{{ safe_ts }}/{{
try_number }}.log'
Cheers
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/incubator-airflow/pull/3179#issuecomment-391684910,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADmkMSWD3fWdWEe62Q0OsnpBkuwa4FdUks5t1p2XgaJpZM4TCoCg
.

What is the status of this PR?


Extend the request builder to generate contract, marketplace name, product name

Connect request can have a contract sections with this structure:
"contract": {
    "id": "CNT-000-000",
    "type": "distribution",
    "name": "Contract Name"
}

Also the marketplace section, on the levels of the request, asset and tier configuration should include marketplace name:
"marketplace": {
    "id": "MP-123123",
    "name": "Marketplace Name"
}

And the asset product definition also has to include a name:
"product": {
    "id": "PRD-000-000"
    "name": "Product",
    "status": "published"
}

Solved in #42


Add a flag to list branches

Hello, thanks for the wonderful tool.
Would be great if there were a way to list branches other than master/main (regardless of status).
e.g.
mgitstatus --branches

./foo: ok
./bar: my_stale_feature_branch_here

Hey Jon,
Not sure what you mean by this. Mgitstatus already shows branches other than master/main if the require any action. For example, a branch stale which has not been pushed to upstream:
./multi-git-status-test: Needs upstream (stale)

I have just added a -b switch to show the currently checked out branch in the output:
./fboender/multi-git-status (master): Needs push (master) Uncommitted changes

Awesome, ya I think I was looking for somthing like that so I could see which repos locally were not on master.  Thanks for the update and keep up the good work 💪


WIP: factor out leader election code into core module

VERY WORK IN PROGRESS

@sttts did a first pass. I think this is the right direction. Added a couple of comments.

PTAL @gkleiman

@sttts I haven't started the review yet, but mesosphere.marathon.integration.LeaderIntegrationTest failed, it might be worth taking a look into that.

@gkleiman I am on that now


PopupMenu doesn't hide when user clicks outside it

Godot version
3.4.2.stable.official [45eaa2daf]
System information
Windows 10
Issue description
The PopupMenu node doesn't hide when I click outside it. As I understand it, it's supposed to hide by default, unless you set popup_exclusive to true, which I haven't done. Changing this property either way doesn't actually seem to change the behaviour.
Clicking inside the popup does hide it.
https://user-images.githubusercontent.com/74183296/153832734-324ac4b4-1915-4d56-8f17-d075caf2a5ee.mp4
Steps to reproduce

Create a PopupMenu node.
Run the scene
Click outside the node

Minimal reproduction project
PopupBugReport.zip

For Popups to work correctly, popup() has to be used instead of plain-old show().


documented Async .optimize method doesn't work

System stats:
OS: Win 7 Pro 64bit
Node: v7.7.1
SVGO: @0.7.2

Issue:
The Node module example listed at https://github.com/svg/svgo/blob/master/examples/test.js#L15 does not work as documented:
svgo
    .optimize(svgstr)
    .then(function(res) { ... })
    ;

The above snippet throws an error message: TypeError: callback is not a function.
This is because the .optimize method specifies an svgstr arg, and a callback arg, and does not return a Promise for .then to be used.
The working snippet should be:
svgo
    .optimize(content, function(res) {
        console.log(res);
    })
;

I suspect this is an oversight in the API design implementation, which I would expect is true as the promise based approach documented in the examples seems like a logical feature.

..likely because examples refers to a unreleased version. Also, #750.

Fair enough, though I would expect master to be the current stable release available on NPM. Unreleased features seem like a dev branch workflow to me.

I'm not the maintainer, but linking to a file in the "master" branch shouldn't encourage you to make the assumption that latest release is on par. With that said I would love to see more regular releases!

You should never release an unstable version to master.


Sprint event can't be cancelled

Hello, I just tested the sprint event and it won't cancelled. In the console I get "Event cancelled!"

This is a Spigot/clientside issue. If the player is holding down their sprint key, you can't stop them from sprinting without setting their food_level to 6 or below, or using other clever means like potion effects.

Ok, thank you for the clarification


Circular dependencies in Volto

src/actions/content/content.js -> src/helpers/Content/Content.js -> src/config/index.js -> src/config/Widgets.jsx -> src/components/manage/Widgets/AlignWidget.jsx -> src/helpers/index.js -> src/helpers/AuthToken/AuthToken.js -> src/actions/index.js -> src/actions/content/content.js
src/actions/index.js -> src/actions/content/content.js -> src/helpers/Content/Content.js -> src/config/index.js -> src/config/Widgets.jsx -> src/components/manage/Widgets/AlignWidget.jsx -> src/helpers/index.js -> src/helpers/AuthToken/AuthToken.js -> src/actions/index.js
src/actions/querystringsearch/querystringsearch.js -> src/config/index.js -> src/config/Widgets.jsx -> src/components/manage/Widgets/AlignWidget.jsx -> src/helpers/index.js -> src/helpers/AuthToken/AuthToken.js -> src/actions/index.js -> src/actions/querystringsearch/querystringsearch.js
src/actions/vocabularies/vocabularies.js -> src/config/index.js -> src/config/Widgets.jsx -> src/components/manage/Widgets/AlignWidget.jsx -> src/helpers/index.js -> src/helpers/AuthToken/AuthToken.js -> src/actions/index.js -> src/actions/vocabularies/vocabularies.js
src/actions/workflow/workflow.js -> src/config/index.js -> src/config/Widgets.jsx -> src/components/manage/Widgets/AlignWidget.jsx -> src/helpers/index.js -> src/helpers/AuthToken/AuthToken.js -> src/actions/index.js -> src/actions/workflow/workflow.js

@tiberiuichim is there a way to automatically detect those circular dependencies? If so we could add this as a check to our CI.

@tisto Sorry, this ticket is a bit misleading, Victor and I are trying to see if we can revive Storybook and solving the imports problem is a must. I've added a webpack plugin that automatically detects and logs warnings about such dependencies. The current situation in Volto is such that it's difficult to avoid circular imports (for ex a widget uses a helper that needs settings, which is defined in ~/config which bootstraps the widgets, so you have a circular import).

I've added the plugin integrated in Volto here: https://github.com/plone/volto/tree/circular_deps_plugin


Epic: English translation of documentation

A large number of users from countries that speak English (either natively or as a major language) use evcc, and rely on translating the documentation using Google Translate or other machine learning tools. However, this results in a number of issues and bad translations (especially surrounding configuration blocks).
This Epic targets a full British English translation of the documentation.
Steps to take:

[x] Activate i18n mode in Docusaurus

https://github.com/evcc-io/docs/pull/420

[x] Translate root pages including home and sponsorships

https://github.com/evcc-io/docs/pull/420

[x] Translate Installation section

https://github.com/evcc-io/docs/pull/421

[x] Translate Guides (tips & FAQ) section

https://github.com/evcc-io/docs/pull/426

[x] Translate Reference section

https://github.com/evcc-io/docs/pull/425

[x] Set up generation of devices section

https://github.com/evcc-io/docs/issues/429
https://github.com/evcc-io/docs/issues/432

[x] Remove references to DE only in project description needs organisation manager
[x] Capture new English images (screenshots, etc)

https://github.com/evcc-io/docs/issues/422

Closed by https://github.com/evcc-io/docs/pull/503

Some pages still need translation. But I think the epic is done. Thanks @duckfullstop for pushing this 🙌


Mobile app container

See issue #446 .
Implements the following for mobile:

AboutDialog
ExceptionDialog (with details)
FeedbackDialog
ImpersonationBar
LockoutPanel
LoginPanel
UpdateBar
VersionBar

Also adds a number of enhancements to the mobile toolkit:

Configurable AppMenu with standard items
Onsen button wrapper which adds support for icons
XH.app.isMobile flag
Mobile Messages, used via XH.alert(), XH.confirm() etc
Mobile Toasts, used via XH.toast()
Improved dropdown menus on mobile
New mobile fields TextAreaField && SelectField

These new mobile components will require some minor changes to client mobile apps, but otherwise are pretty self-contained. There are, however, a couple of things that will affect existing desktop apps and require review:
This changes removes ToastManager in favour of the cross-platform XH.toast(). Apps should update to use XH.toast(). Desktop can show several toasts at once (nicely stacked in the region), whereas mobile will queue toasts and show them one at a time.
Also note that impersonation bar visibility has been lifted up IdentityService, to help power the mobile implementation and give us a central place to determine visibility & check HoistAdmin permissions. This shouldn't require any changes to existing apps, but it does change the existing desktop ImpersonationBar.

If it makes it easier to review, I can split this into 2 pull requests - the new mobile components, and the framework changes required to support them (XH.toast(), IdentityService, etc). The framework changes may not make as much sense outside of the context of the mobile components, but may be easier to review.

Big change -- looking at it now.  One quick concern I have is with moving the visibility state of the impersonation bar to the service.
Have been increasingly looking at any references to GUI state within services as an anti-pattern.
I think services are easier to understand as above the level of the actual GUI/platform/etc.

Closing this in favor of amended one I just opened on a child branch of this one.


Note metadata and tag schemas

Currently, note metadata consists of 3 elements: sender, tag, and num_assets. num_assets will be removed as a part of #281, but we'll need to add note type to metadata and also come up with a methodology for specifying tags. Possible approaches for both of these are described below.
Note type
To properly propagate notes through the network and also to properly process them in the transaction kernel, we need to know some basic info about what kind of a note it is. Specifically, we can categorize notes as follows:

Off-chain notes - where the network knows only note hashes.
Encrypted notes - where the network knows encrypted note data.
Public notes, where the network knows all note detail. These further sub-divide into:
a. Notes intended for local execution.
b. Notes intended for network execution.

We need just 2 bits to represent these 4 possible types and these could be encoded into a single field element within the VM. For now, these won't affect much except that we'd only allow off-chain notes (i.e., the transaction kernel will raise an error if we are trying to create either a public or an encrypted note). We'll lift these limitations in the future.
Note tags
We use note tags primarily for routing/discovery purposes. That is, the user can query the node for a set of tags, and the node will return all notes which match the specified tags (the way the state_sync endpoint is currently implemented in the node, we actually don't query for the entire tag, but only for a 16-bit prefix of a tag - but let's put this aside for now).
The size of a tag is one field element (i.e., 64 bits).
For the 3 standardized scripts we currently have, we set the tags as follows:

P2ID and P2IDR - the tag is set to the target account's ID.
SWAP - the tag is set to $0$.

There are a few things we can improve about the above approach:
First, we can reduce the tag size from 64 bits to 32 bits. This reduces size of the note commitment without really impacting anything (i.e., we probably don't really need 64 bits for any type of tag).
Second, while we can't (and shouldn't) enforce rules on how users define tags, we can recommend some basic schemas. For example, we could categorize notes as follows:

Notes sent to a specific account.
Notes sent to many (or any) accounts.

Then, we can say that, by convention, tags that start with 0 are intended for notes sent to specific accounts, and tags which start with 1 are indented for notes which are sent for many (or any) accounts. Or more concretely, tag formats could be:

Notes sent to specific accounts: 0 + 15-bit account prefix (this can be increased in the future to increase the level of privacy).
Notes sent to any account: 1 + 15-bit use case ID + 16-bit tag payload. The 16-bit payload could be defined differently for a specific use case.

Applying these formats to our standardized scripts could look as follows:

For P2ID and P2IDR we'd use the first format - so, the tag would be: 0 + 15 most significant bits of target account ID + 16 zeros.
For SWAP we'd define use case ID as $0$ - so, the tag would be: 1 + 31 zeros.

We could also make the SWAP tag a bit more sophisticated. For example, to let people filter notes more easily, we could define the tag payload as: 8 bits of the faucet ID of the requested asset + 8 bits of the faucet ID of the offered asset. This way, if we provided the capability to query notes by the full tag, the users will really be able to narrow down the set of returned notes. But also, maybe we are running a bit too far ahead with this.

Thanks for the write-up! One question:
Note type

to properly process them in the transaction kernel, we need to know some basic info about what kind of a note it is

Can you elaborate on why the transaction kernel needs to know where the note data is being stored? The executing account/user would always need to provide the note data to the transaction kernel, right? Or do you plan to change the transaction kernel in the future?
Note tags
I love the tags idea, especially to encode the asset into the tag. In the future, I expect users to create their own note scripts. So maybe, we can note down the tag schema in the docs and provide a small script in the client or wallet to create a tag?

Can you elaborate on why the transaction kernel needs to know where the note data is being stored? The executing account/user would always need to provide the note data to the transaction kernel, right? Or do you plan to change the transaction kernel in the future?

There are two primary reasons for this:

We need to ensure that the note type is valid. Technically, this could happen outside of the kernel as well, but inside the kernel is cleaner.
In case of encrypted notes, we will need to encrypt the note contents in the kernel. So, basically, there will need to be an if-else statement in the prologue: if a note is an encrypted note, then encrypt and hash its contents; otherwise, just hash the contents (as it works now).

I love the tags idea, especially to encode the asset into the tag. In the future, I expect users to create their own note scripts. So maybe, we can note down the tag schema in the docs and provide a small script in the client or wallet to create a tag?

Yes, this should go into the docs - but we should settle on this first. One other option is to reduce tags to 16 bits rather than 32 bits. But there are pros and cons for each.

For a public note querying over the public inputs and code hash should be enough.

This could work, but as the number of different note types grows, so will the number of potential combinations of script hash + public inputs (e.g., filter for notes where script_root = x and (inputs[0] = y or inputs[3] = z)). This may require us to support a mini-query language to specify relevant conditions - which, in my opinion, is probably too complex. With tags, we tags, we offload this tasks to the users.

For off-chain notes its hash would serve the function of the tag.

This could also work, but would probably end up being just as complex as we'd need to support some kind of "fuzzy matching" on note hashes to provide some degree of privacy.

the same for encrypted notes

I'm actually not sure how this will work for encrypted notes. For these notes, the recipient does not control the note hash and note script/inputs are encrypted - so, I'm not sure what can be a meaningful filter here.
Overall, I think tags are a pretty simple solution which can be applied uniformly to all cases we need to support. Getting rid of them will probably result in more complexity.

@bobbinth which component will determine the note type? For example, the encrypted note, will it be encrypted inside the VM? Or will it be encrypted by the host?
To give some context: I'm asking because I need to know where the type is set, after the transaction is executed and when the executed transaction is being created. Or when parsing the transaction output. One approach will also need changes to the kernel, whereas the other is rust only.

I think inside the VM makes the most sense. The reasons for this are:

Note type would need to be a part of note metadata and note metadata gets defined inside the VM.
For encrypted notes, we'll need to do the encryption within the VM.

There are more considerations for encrypted notes - e.g., we'd also need to make sure that the commitment to encrypted notes is a commitment to the encrypted data. But this is a separate issue and I don't think we should enable support for encrypted notes just yet.

To support the above, we'll probably need to modify create_note kernel procedure. Or maybe create several variants of this procedure - e.g., create_offchain_note, create_network_note etc.

What about network transactions? It seems odd that a user can send a tx script to the network which calls create_offchain_note. That will add some code validation requirements, that maybe we can get away without if the note type is defined outside of the VM.
Do we need to verify the note type inside the VM? Shouldn't this be a detail decoupled from the kernel, and isolate exclusively as a transport related detail?

What about network transactions? It seems odd that a user can send a tx script to the network which calls create_offchain_note. That will add some code validation requirements, that maybe we can get away without if the note type is defined outside of the VM.

For network transactions, the user would not send a tx script to the network. Or at least the way I'm thinking of network transactions now is that the node would pick a set of notes to be applied to a given account and create a transaction from them - and this would be done without any input from the user.
I think you are right though that when a network transaction is executed, we need to handle special cases. Specifically, if such a transaction results in an on-chain note, the node needs to know all the note details.
So, maybe for now we should limit the scope of this to only offchain and local notes - and tackle network notes separately.

Do we need to verify the note type inside the VM? Shouldn't this be a detail decoupled from the kernel, and isolate exclusively as a transport related detail?

I don't think we can decouple these. The main reason is that the transaction needs to commit to the note type - otherwise, a malicious node could change the type of the note (e.g., pretend that a note is offchain while it is supposed to be onchain).

I don't think we can decouple these. The main reason is that the transaction needs to commit to the note type - otherwise, a malicious node could change the type of the note (e.g., pretend that a note is offchain while it is supposed to be onchain).

Is it useful to discern the two though? A malicous node can circumvent the check by consuming the note with a local transaction. I think we should rely exclusively on the note's script for security w.r.t. execution.

A malicous node can circumvent the check by consuming the note with a local transaction

hmmm - I'm not sure how this would work.
In general, the issue this is aiming to prevent is during transaction relay between nodes. For example, if node A sends a transaction to node B, node B needs to have a way to determine the type of every of the note produces by the transaction. If node A is free to manipulate the note type, they could say that all notes are off-chain while some of them may be on-chain. And this would lead node B to accept a transaction with malicious data.
The only way I can think of to avoid this is to commit to note type as a part of transaction output - i.e., by putting note type into note metadata (which I think is also the right place for it anyway).

Note: I'm using network notes for the fungible asset distribute and the basic wallets' send_asset

Note: I'm using network notes for the fungible asset distribute and the basic wallets' send_asset

I think these would be local notes (i.e., public notes, but intended for local consumption). Though, this makes me think if we overcomplicated note types a bit. Maybe we should just have 3 types: off-chain, encrypted, and public, and whether a note is intended for network or local execution would be determined solely by its tag.

Here is some additional context, based on a conversation I had with @bobbinth :
The problem space is big, but it can be split as follows:

Where/How is the data stored? How is data availability guaranteed?
By whom/when can a note be consumed?

Where/How is the data stored?
First we have to clarify what data. Here we have:

Account details. This includes the account's vault, code, and storage
Note details. This includes the note's vault, code, inputs, tag, serial_num/nullifier

For both input and output notes

The data can be store:

off-chain
on-chain
on-chain encrypted

How is data availability guaranteed?
This is important for:

Smart contract accounts, which state changes are needed by the operators
Output notes, which the details are needed by the receivers to consume the note

By whom/when can a note be consumed?
This is important for every actor in the system. Every actor needs a mechanism to tell if they can consume a note, i.e. they are the target. And when they can consume the note, i.e. should this note be discarded now, or held until a condition is met which allows it to be consumed?

Expanding a bit on the pervious comment:
I think we can assume that an input note (or transaction script) with results in a creation of an on-chain note should be responsible for producing all data related to this note. There are two questions related to this:

How does the VM (or more specifically, the user executing the transaction) learn about this data?
How does the input note ensure that the user cannot modify the output public note in any way?

For the first question, there could be several approaches:

All public data could be expected to be somewhere in memory.
All public data could be expected to be in the advice provider.
All public data can be communicated to the host via events.

I think the event-based approach is probably the more flexible one. It could work as follows: when a note is created (via create_public_note procedure), the VM emits an event about the note being created. By that time, there should be enough data in the VM (whether on the stack, the memory, or the advice provider) for the host to be able to construct the Note object for the created note. If there is not enough of such data, the VM panics. We'll need to define the exact way in which the host will look for the note data - but I think that shouldn't be too difficult.
For the second question, everything except for the note script should be pretty straight forward. Note ID unambiguously commits to note inputs, note assets, and serial number. However, the commitment to note script is somewhat ambiguous. Meaning, knowing the script root does not tell us exactly how much of the script should be included with the note. So, in addition to the script root, we need to include some other data with the note which would unambiguously define the note script.
The most straight-forward way to do it is to include a sequential hash of the script. So, in effect, every public note would have 2 commitments to the script: script root and script hash. While this works, it is quite inelegant and probably will cause various complications. But so far, I wasn't able to find a better solution.

Is it a solution that in this case we don't allow hiding parts of the script and we always provide the full script? We can always enable this feature (hiding partial note scripts) if required.

Is it a solution that in this case we don't allow hiding parts of the script and we always provide the full script?

This won't quite work because putting the entire script on chain would be prohibitively expensive in many cases. For example, if I make a call to sha256 procedure, ideally, I won't have to put the actual code of this procedure on chain.

Ok, but if we don't force Alice to put the entire script on-chain, how can we ensure that Bob can execute it? At the point of note creation, Alice doesn't know which parts of the note script Bob will execute, right?
Is it a solution that we put all parts of the scripts on-chain that do not have a known root in miden-lib. That would mean, we only need any custom part of the script. This could be done via a simple lookup table and it can easily be checked by the VM quite efficiently.

Is it a solution that we put all parts of the scripts on-chain that do not have a known root in miden-lib. That would mean, we only need any custom part of the script. This could be done via a simple lookup table and it can easily be checked by the VM quite efficiently.

Yes, this could be a solution - though, we'd need to include procedures from both miden-lib and stdlib in the set of "well-known" procedures. To make this work, we'd need two things:

Build a list of MAST roots of procedures exported from these libraries. This should naturally come out from the package format being discussed in https://github.com/0xPolygonMiden/compiler/pull/129.
Have a simple way to check if a given note scripts makes calls only to external procedures defined in these libraries. This should be pretty straight forward once we migrate to the MAST-based serialization format (discussed in https://github.com/0xPolygonMiden/miden-vm/issues/1226.

One note: we'd need to keep track of procedures defined across all versions of these libraries (being able to mark some procedures as deprecated might be a good thing to have here cc @bitwalker).
The obvious downside of this overall approach as that users would not be able to hide any custom parts of scripts for public notes - but maybe that's something we can tackle later (I think when we'll need to figure this out by the time we get around to encrypted notes anyways).

If we go for this approach, what else is missing to be able to start?

We can easily check (outside of the VM) if a given note script s results in the same root. However, s is not unique because we can "hide" portions of a script. So, there could be another note script t which also results in root r. Now, both s and t encode exactly the same program - so, that's not an issue from verification standpoint.

Is this correct? My understanding is that just because you elide certain subtrees of the MAST, the hash doesn't change, because the proxy node for that part of the tree contains the hash of the callee, and proxy nodes are "transparent", i.e. the hash of the callee is used as the hash of that node, so it's no different than if the full tree was present. Maybe it is only the case that we can rely on this after my assembler refactoring that ensures a program is always compiled so that all callees are by MAST root, but in any case, I'd very much like to understand why hiding a portion of a program would change its hash, since that seems to break some of the nice properties of MAST.

You are correct, hiding a portion of the program does not change the MAST root. The issue here is different. If we only know MAST root, we don't know how much of a given program is meant to be public. So, if I, as a user, send a public note and include some public program $s$ with it, a malicious operator would be able to transform this program $s$ into program $p$ by replacing some of the subtrees with proxy nodes. This would not change the MAST root, but it would alter the script that I wanted to put on chain in a way that would not be detectable by anyone but me.

We can easily add this in the assembler (we already have facilities for this in the compiler), the only thing we'd probably need to discuss here is some way of representing structured attributes/metadata in Miden Assembly syntax. I think we probably want to avoid doing something like parsing doc comments for certain keywords or something, and instead have concrete syntax for things like this, e.g. @deprecated or #[deprecated(since = "..", "note about deprecation")].

Agreed! I was also thinking that we should make provisions for this in the package format.

If we go for this approach, what else is missing to be able to start?

There are 3 open (or at least somewhat open) questions here:

How do we ensure that the script included with the public note is the same as the script the user wanted to send with it? For this, we can use the solution discussed above and then refine it later on.
How do we build the output Note objects for public notes (and maybe for some off-chain notes as well)?
How do we structure tags and note types to cover what we need for now, but at the same time leave enough flexibility to extend the structure later without breaking too many things.

The second question is really about how do we populate output_note_details in the ProvenTransaction struct. More specifically, this data should probably be also present in the ExecutedTransaction struct (maybe as a separate field, or maybe as a part of TransactionOutputs struct) and the place where it should be extracted from the VM is in the build_executed_transaction() function.
The main question here is how does this data get injected into the VM. As I mentioned in https://github.com/0xPolygonMiden/miden-base/issues/402#issuecomment-1999141087, we probably want do do this via events intercepted by the host. It would also be nice if we could do something generic where the process works both for public and off-chain notes (this would simplify things on the client side). So maybe we should do the following:

Add a field to the TransactionHost to track output notes created by the transaction. This could keep track of all notes, or only the ones where the Note object could be constructed.
When create_public_note or create_offchain_note procedures are executed, we'd fire some events which would indicate that notes are being created.
The host would intercept these events (e.g., here), look up the relevant data in the VM, and try to build a Note object for the created note. For public notes, if the Note object cannot be built, the execution should fail. For off-chain notes, failure to build a Note object should not affect execution.
a. In the VM, we could still keep track of only the commitments to things like script_root, inputs_root etc. The actual values for these could exits only in the advice provider.
After the transaction is complete, we would be able to extract the created notes from the host and put them into the ExecutedTransaction object.

The 3rd question is about how to reconcile information carried by note type vs. note tag. I've described one approach in the original post (4 note types and note tag schemas). But it is not clear to me that this is the right way to go about it. In general, we want to use note metadata to answer the following questions:

Where the note is coming from? For this we have the sender field.
What data should be attached to the note? i.e., is this a public note, encrypted note, or off-chain note?
Who the note is indented for? Here we have two different use cases:
a. The client should be able to figure out which notes are intended for them.
b. The operator should be able to figure out which notes are intended for network execution, and which account they should be executed against.
When the note can be executed against the intended account? This one we can solve a bit later - but also if there is a good solution we come across now, we should use it (or at least make provisions for using it in the future).

Some more concrete questions:

If we have 3 note types as is implemented in #515. How do we indicate if a note is intended for network or local execution? Is that just another flag? If so, we could have an inconsistent combination of flags (e.g., off-chain note cannot be intended for network execution). Should we go back to having 4 note types?
a. Can info about the destination account be used to infer if a note is intended for network execution? If so, how can this be determined?
Which notes would the client get when requesting notes by tag? All notes matching this tag? Or only notes intended for local execution? Or maybe that's another parameter in the state sync request?

Maybe, instead of note type, we define two additional properties for a note:

Storage mode: off-chain, public, on-chain.
Execution mode: local, network.

And we encode this info using 2 bits as described in the original post (this way, invalid combinations of these would be impossible).

...if I, as a user, send a public note and include some public program $s$ with it, a malicious operator would be able to transform this program $s$ into program $p$ by replacing some of the subtrees with proxy nodes. This would not change the MAST root, but it would alter the script that I wanted to put on chain in a way that would not be detectable by anyone but me.

I think this is the part that is tripping me up. My understanding was that changing the tree in any way should change the MAST root. The only way to replace a subtree with a proxy node without changing the MAST root would be if the proxy refers to the exact hash of the subtree it replaced, which doesn't actually change anything. The caveat to that I suppose is if one is finding hash collisions, but for any given program that's probably impractical while also achieving the malicious goal, e.g. stealing funds.
I think maybe the critical detail here I'm missing is in the private/public part, but I would've thought that either way the MAST roots ensure the tree is tamper proof.

The only way to replace a subtree with a proxy node without changing the MAST root would be if the proxy refers to the exact hash of the subtree it replaced, which doesn't actually change anything.

This does not change the program - but it does change how much of the program is "available" (in this scenario, I send a note to the operator and rely on the operator to provide this note in its entirety to whoever wants to consume the note). For example, if I want all of the note script to be publicly available, specifying just MAST root is not sufficient because the operator could replace some subtree with an equivalent proxy node and effectively hide this subtree from everyone else. The issue here is not so much that the operator can do this (they can do this in any setting), but that without some extra info nobody would know that the script I published was supposed to have everything public.

IMO we should forbid hiding parts of the MAST for on-chain executable notes.
If we don't have all the code available, we will need to keep the notes in the pool, in case the revealed bit of code happens to make it executable in the future. Meaning the pool will have to keep notes for undetermined time for this feature to work properly. I guess in the future we can relax this constraint, such that bits of the MAST can be hidden behind a proxy, if it is not necessary for the note consumption, but I think we should wait for a use case before going over the effort.

Documenting a proposal I shared with bobbin: I think we should use the note's code to determine when it can be consumed, instead of adding metadata fields. The rationale is that metadata can express all conditions for the note's execution.
For example, something like a simple order book, where a note should be executed only if the user's order criteria are matched, we can't possibly define a fixed set of values that determine when a note can be consumed, that is to say, the set of conditions is open and we can't predict what it will look like. Example 1: a new asset is added to the rollup and the note is against it, here the set of possible values is open. Example 2: A token sale is being done, the token has some internal price curve, and the note wants to execute if a given criteria matched, here the set of tests is open.
Issues

Note lifetime

The motivation example above is a order note. Well, if the conditions are just price based, it could well be the case the note will never be executable. So the question becomes how long should the note be kept around.

Consumability test

The next issue, is how to determine if a note can be consumed. Would we need to have a pool of notes, and on every new block re-execute every note to check if they became consumable?
Possible solutions

Note lifetime

I think we can't fix this issue, the system is so open that a note code could be buggy, it will always hit an assert and the note will never be consumable. So the solution here is just to allow the issue to happen and document it, notes would be added to the pool, and kept for an undetermined operator defined time prior to being dropped if they are not consumable.
The alternative is to restrict what can be done with notes.

Consumability test

I think the simplest solution here is just to have a priority queue of notes that failed a consume test, and the node would after a new block pop the highest priority to recheck, if the check fails the note is put back into the queue with a lower priority until its pool lifetime expires.
We could be a bit more clever, and track which trees the note is reading during its execution, and only retry the checks if given roots change. But this seems very, very, brittle, and I think it should be delayed until it really is needed

IMO we should forbid hiding parts of the MAST for on-chain executable notes.

This is the plan for now.

If we don't have all the code available, we will need to keep the notes in the pool, in case the revealed bit of code happens to make it executable in the future. Meaning the pool will have to keep notes for undetermined time for this feature to work properly. I guess in the future we can relax this constraint, such that bits of the MAST can be hidden behind a proxy, if it is not necessary for the note consumption, but I think we should wait for a use case before going over the effort.

I think it is important to distinguish here between:

Public notes intended for local execution.
Public notes intended for network execution.

In the first case, the network doesn't care about note scripts as it will not need to execute them (but the scripts still need to be on chain). But in both cases, allowing users to hide a part of a note script would be quite valuable (both for privacy and performance reasons).
Let's take P2IDR note as an example. A user may wish to create a public note with this script, but may want to hide the "recall condition". That is, in the "happy path" all data required to execute the note is on-chain. But after certain block height, the user could execute a hidden program to recall the note (the optimization benefit here is the recall part of the program does not need to be on-chain, thus saving some space).

@hackaugusto can you note down our common understanding in here?

We need the on-chain bit to detect operator misbehavior, without it off-chain and on-chain notes look the same. Misbehavior means, the note was created as on-chain but the operator did not provide the data. Open questions:
a. How is the data published?
b. What are the user actions?
A mechanism to read out Notes from the VM, the procedure is described above.
The execution flag is an optimization. Assumption is the majority of the notes are for local execution, well behaved nodes will set the flag properly, attacks still need to be handled.
The note script is not handled inside the VM, open question on how to decode MAST. For now just set the bits.
Whitelisting of MAST code for libraries waits for the packaging effort

For execution mode, one option to consider is just making this a part of the tag. For example, setting the first bit of the tag to 0 for local execution and 1 for network execution. The second bit can be used to indicate whether the note is intended for a specific account or for some use case (e.g., swap). To summarize, we'd have the following tag formats:

00 + recipient_prefix: note is intended for local execution by a specific account. Recipient prefix here could be based on an account ID, but it could also be anything else that may be used to identify the recipient of the note (e.g., prefix of a public key, or even some random value). One suggested way to set the prefix could be to use first 16 bits of account ID followed by 14 zeros.
01 + use_case_id + use_case_metadata: note is intended for local execution for a specific use case (e.g., swap). Everything beyond 01 should probably be discussed separately, but I'm thinking use_case_id could be 14 bits and use_case_metadata could be 16 bits.
10 + account_id_prefix: note is intended for network execution against a specific account. The account is defined by the account_id_prefix (could be first 30 bits of account ID). The account must be a public account. That is, the 3rd bit of account ID should be 0 (it may make sense to re-define layout of account ID to move this bit up so that this tag prefix is always 100). Also, note storage mode must be "public".
11 + use_case_id + use_case_metadata: similar to the 01 case but now the note is intended to be processed by the network, and so note storage mode must also be "public". The details of how this would work we can leave for the future - i.e., notes with tag prefix 11 would not be allowed for now).

Some benefits of this scheme:

All tags can be encoded in 32 bits and all 32 bits are used for filtering.
The scheme is pretty easy to use from the client perspective: to request notes intended for a given account, the client uses 00 + 16_bit_account_prefix + 14 zeros for the tag and this filters out all irrelevant notes (e.g., notes intended for networks execution).
For the 01 case, the inclusion of additional metadata into the tag could help with filtering. For example, for the swap note, the 16 bits of metadata would be used as: 8 bits to identify requested asset and 8 bits to identify the offered asset (in both cases these could be 8-bit prefixes of corresponding faucet IDs). This should really help narrow down a set of relevant notes.
On the node side, we don't need to filter by additional things (e.g., execution mode) when serving the client. Also, we only need a single index for tags (we index on the full 32-bit value).
For the 10 case, it will be pretty easy for the operator to identify relevant notes and accounts against which these notes are to be executed.
a. The operator will still need to do additional work to figure out if the note is actually executable against the specified account (and when it can be executed) - but that's a separate problem. For now, we can be very strict and say that if the note cannot be executed immediately, it is deemed unexecutable.

Some downsides:

Instead of 16 bits, the client would now need to send 32 bits per tag during state sync request. I'm not sure this matters though.
There is no easy way to request only public notes for a specific use case. For example, the client cannot say: "give me all public swap notes".
a. One potential way to address this is to add one more bit to the 01 case. Specifically: 010 Could imply the that note must be public and 011 could imply that the note must not be public (and we can enforce these checks in the kernel).
Since we shrink tag size to 32 bits, we reduce the amount of additional metadata that can be associated with a note.
a. To address this, we can probably just add another element to metadata which could carry 64 bits (or maybe more) of arbitrary data.
There is some validation we need to do in the transaction kernel to ensure that the tag is not malformed - but I don't think that's a big deal.

To summarize, the new metadata struct could look as follow:
pub struct NoteMetadata {
    sender: AccountId,
    mode: StorageMode,
    tag: u32,
    aux: Felt, // this is the additional arbitrary data
}

Actually, there is no reason why we can't call storage mode NoteType (and keep what we already have in #515). So, then metadata would look like so:
pub struct NoteMetadata {
    sender: AccountId,
    note_type: NoteType,
    tag: u32,
    aux: Felt,
}

pub enum NoteType {
    OffChain,
    Encrypted,
    Public,
}

And to summarize tag validation rules:

For off-chain notes:

The tag must start with either 00 or 011.

For public notes:

The tag must start with 00, 010, or 10
If the tag starts with 10, the 5th bit of the tag (the 3rd bit of account ID) must be 0. If we were to modify account ID encoding scheme by moving the storage mode bit upfront, this rule would go away and the only rule we'd have is that the set of allowed tags prefixes for public notes would be 00, 010, and 100.

For encrypted notes, we won't support them for now, but in general:

The tag must start with 00.

If we do modify the account ID schema so that the first bit of the ID is 0 for public accounts and 1 for off-chain accounts, we could simplify things a bit. Specifically, we could give the following meaning to tag prefixes:

00: local execution for specific recipient.
01: local execution for a use case, off-chain note.
101: local execution for a use case, on-chain note.
100: network execution for specific account.
11: network execution for a use case.

Tag rules then become:

For off-chain notes: first tag big must be 0.
For public notes: second tag big must be 0.
For encrypted notes: first two tag bits must be 00.

But maybe I'm overthinking things :)

Ok, that sounds great.
The first question that comes to my mind is, is there a reason why we need to encode everything in the tag using bits? We could also have more fields in the Note metadata.
pub struct NoteMetadata {
    sender: AccountId,
    note_type: NoteType,
    execution: ExecutionType,
    aux: Word,
    use_case: UseCaseType,
    tag: u32,
}

pub enum NoteType {
    OffChain,
    Encrypted,
    Public,
}

pub enum ExecutionType {
    Network,
    Local,
}

pub enum UseCaseType {
    Swap,
    P2ID,
    LimitOrder,
}

The notes might become bigger, but as far as I understood, we don't plan to store them on Ethereum. That way, the schema might be way more usable and easier to understand. In the aux field, ppl can store 4 Felts for their respective use case, which might be the intended recipient, the assets to swap, or whatever.
I like your schema's aux field. We need to allow for future use cases, and people can develop their own schema and encoding in this field.
But I don't see a particular downside to your approach either. It might only overcomplicate things.

@bobbinth do you want these account id changes implemented? That is the only thing pending AFAIU (the storage bits are already implemented by https://github.com/0xPolygonMiden/miden-base/pull/515)

And one additional point @bobbinth @hackaugusto can we put the idea of encrypted notes aside for now? No Pioneer is asking for it so far and we can save time if we don't implement it now.

Yes, we are not implementing the encrypted notes for the time being.

The first question that comes to my mind is, is there a reason why we need to encode everything in the tag using bits?

The main reason is that the tag is a queryable field - i.e., this is the field the client can filter on during state sync request. So, by putting these bits into the tag we effectively allow the users to say something like "i'd like to get all the public notes intended for a specific use case", or "I'd like to get all the notes intended for local execution by a specific account".
But we can still get something similar to what you described like so:
pub struct NoteMetadata {
    sender: AccountId,
    note_type: NoteType,
    tag: u32,
    aux: Felt,
}

pub enum NoteType {
    OffChain,
    Encrypted,
    Public,
}

pub enum ExecutionMode {
    Network,
    Local,
}

impl NoteMetadata {
    pub fn execution_mode(&self) -> ExecutionMode {
        let first_bit = self.tag >> 31;
        let first_3_bits = self.tag >> 29;

        if first_bit == 0 || first_3_bits == 101 {
            ExecutionMode::Local
        } else {
            ExecutionMode::Network
        }
    }
}

@bobbinth do you want these account id changes implemented? That is the only thing pending AFAIU (the storage bits are already implemented by #515)

I guess it depends on the amount of work it would take. If this is just a few hours - I'd go for it, but if it is a much bigger refactoring, maybe it makes sense to do it later. I believe it should be the former - but I didn't look into it closely enough to know for sure.

I guess it depends on the amount of work it would take. If this is just a few hours - I'd go for it, but if it is a much bigger refactoring, maybe it makes sense to do it later. I believe it should be the former - but I didn't look into it closely enough to know for sure.

Sounds good, will give it a try

@hackaugusto, @Dominik1999 - I've created a few more specific issues (i.e., #538, #539, and #540) based on the above discussions. So, this issue can be closed as soon as https://github.com/0xPolygonMiden/miden-base/pull/515 is merged.
I think once all these 4 issues are closed, we should also be able to close #403.

Closed by #515. The rest of this issue will be addressed in separate issues as mentioned in the comment above.


Picker translation goes wrong when picker grows

I everyone,
When changing month and if the picker is above the input, if the days moves from n lines to n+1 lines, the picker is "translating" wrong. The bottom of the picker component should not move: it should stay statically at the top of the input.
Thanks

#361


Perform deep analysis of simulation computation time benchmark, this can guide prioritization of package refinment.

This can surface bottlenecks to tackle first like.
Does exposing the data takes too much time?
Is the trading logic of the template the biggest bottleneck?
What is the performance achieved under similar logic using Zipline?
We should be at least as fast as them.
What about running the same thing in Zorro, reaching them would be ideal, as it will match our speed with C.

Not sure which milestone this would correspond to, nor how it prioritize against other stories. Will leave in the parking lot in the meantime


Training results don't match Deepmind implementation

In principle, there should be no significant algorithmic differences between this implementation and the Deepmind code.  This code was developed to be consistent with the description from Nature paper.  Where the paper was ambiguous, I've looked into their torch/lua code for clarification.  All of the default parameters are set to match those described in the Nature paper.
For some unknown reason(s) the learning dynamics for this implementation don't match the reference lua implementation.  In general, the current code seems to learn well for a while, then the quality of the policy drops off with continued training.

How bad is it? I mean, did you have a chance to test different games? What's the difference in terms of rewards per epoch? Results of deep_q_rl can't match paper results or even DQN tests that you run locally?
I haven't run full 200-epoch tests on the initial algorithm assuming that it would be identical to the paper. Yet with my implementation there were also issues with convergence after some 35-50 epochs.
Additionally, are there any ideas what could be wrong? What tests should we do in order to find the bug? What can I do to help? I mean there is no other Theano implementation of DQN that I'm aware of, so we have to make this one work. I'm currently researching the possibilities to improve DQN algorithm and it's hard exaggerate the importance of being able to match the published results. :)

But we don't really know the shape of their curves, right? I mean, when they report their results they use the best agent along all the epochs, so the story could still be consistent, they learn until a certain point and they use that agent, regardless of all the rest... Also, notice that recent papers report DQN results and they present two columns: (1) their obtained results with DQN and (2) the results reported in Nature.

@Ivanopolo   This thead on the mailing list has some work on quantifying the difference in rewards/epoch on Breakout.  I haven't tried other games with the latest version of the code.
https://groups.google.com/d/msg/deep-q-learning/K2zo-9I5pM8/fthhQqF7GgAJ
I agree that matching the performance from the Nature paper is important.  Unfortunately, I don't know of an easy way to find the bug.  Some ideas:

Write code for loading saved weights from the torch implementation into Theano, then test with those weights.  This would help confirm that the testing code, preprocessing etc. are consistent.
Perform identical initialization of all weights in both deep_q_rl and the Deepmind code (all set to .1 or something), then perform a weight update with identical inputs. The inputs could be synthetic, it wouldn't be necessary to try to get matching game screens.  Instrument both implementations to print intermediate values from the weight updates.
Someone with time on their hands good take a good systematic look at both implementations.  I've spent some time on this, but someone with fresh eyes might catch a difference.

@mcmachado We can get a look at the curves by running the Deepmind Torch code. The way that implementation reports results seems to be consistent with the way we are reporting results.  They store the best agent across all epochs, but rewards are printed for each epoch.  Follow the link here to see the differences on Breakout:
https://groups.google.com/d/msg/deep-q-learning/K2zo-9I5pM8/fthhQqF7GgAJ

Any updates about this strange bug? Hope we could find the reason as soon as possible..

#46 probably explains some of this discrepancy.

It looks like issue #46  was the culprit here.  The issue is addressed in PR #47.  Thanks @davidsj  for the fix.


implemented MCCLoss and albumentations

@nishaq503 I have implementation changes in the plugin. Let me know if it is compatible with plugin. Feel free to contact me if you have any questions

ignore this pull request


Implement client library

We need to enable users to get direct ssh access to env containers.
Users must be able to ssh into containers from standard system shell or via scripts
See the discussion here https://docs.google.com/document/d/1X65DynlmdXqsU23Su-1vFun4UVX7PtRHQ2BsbhzQfN8

Will not be implemented on CC


Minor improvements to TypeInformationCalculator

Fix a bug with type info of contracts where it didn't throw an error
Always throw an error when there is type() case which is not being handled

Got some .any type warnings in there.

Got some .any type warnings in there.

They are from unrelated code. I would suggest a separate PR for fixing those.


Can't send the TemplateGUID on a Pingpong bot setup

Hi guys ! Trying to use the API here to create a pingpong bot and I get a funky error on the haasome.customBotApi.setup_ping_pong_bot() call.    I sent the 11 param needed which doesn't include a templateGuid.
And the response is:
Parameter missing: templateGuid
EnumErrorCode.INVALID_PARAMETER
interestingly enough, the scalperBot has a param to set the template, and I have no issue with that endpoint.
And finally, when you look at the API doc on haasonline, we see 12 param, which require a templateGuid, but no word on where to find the definition of those "template"
https://help.haasonline.com/api/api-endpoints/custom-trade-bot-api#setup-pingpong-bot
Repro Step
    accountGuid = "xxxx-zzzz-yyyy"
    newPingPong = haasome.customBotApi.new_custom_bot(accountGuid, EnumCustomBotType.PING_PONG_BOT,"MS25 - PP Bot", "BNB", "BTC", "")
    pingPongEdited = haasome.customBotApi.setup_ping_pong_bot(accountGuid, newPingPong.result.guid, "MS25 - new name", "BNB", "BTC",  "", 0.0, EnumBotTradeAmount.STATIC, 0.3, "BTC", 0.2)

Result
Parameter missing: templateGuid
EnumErrorCode.INVALID_PARAMETER

Fixed with merge #10


Workflow jobs no longer run

As of the past few days, any workflow jobs I've setup no longer run. In particular, the last successful run was on Tuesday of this week. I hadn't run any workflows since then, but as of today, nothing will run. I was originally on v2.2.0 and upgraded to v2.2.2, but that didn't make the workflows start running.
Here's some things I've observed:

Runs-On will create logs stating that it sees the workflow, it parses the desired EC2 config successfully, and even states "Runner scheduled successfully" and "Successfully deleted message from the SQS queue".

EC2 instances do get spun up, but after a minute or two, they're terminated without ever having run the workflow.

That's all I'm able to discern from the CloudWatch logs. Let me know if there's any further logs that can assist with figuring this out.

Hello, can you send your logs to<EMAIL_ADDRESS>Thanks!

I've just sent you the Runs-On application logs filtered down to a workflow run that I just attempted. If it helps make it clearer, there's three testing workflows as part of this job, and all three are stuck waiting for a runner to run them.

For what it's worth, my team is seeing this same thing.

@pvande the underlying issue was an incorrect custom image definition. What are you seeing in your case? Can you send logs or screenshots to<EMAIL_ADDRESS>?

I'll be happy to when I get a chance; I've been away from work for the last week and a half.

Ok, I added a video showing how to view the logs in CloudWatch - https://runs-on.com/guides/troubleshoot/#view-the-application-logs
I’m closing this for now, we’ll continue in private.

@pvande if your runners are using a custom or non-full image, it might be due to the runner binary being out of date. This will be fixed in #78 but in the meantime I would encourage you to use ubuntu22-full-[x64|arm64] instead.


打包后的样式和开发环境不一致

[ ] I'm sure this does not appear in the issue list of the repository

Basic Info

Package Name And Version<EMAIL_ADDRESS>Framework version: Vue 3.3.4
Browser: chrome<IP_ADDRESS>
Reproduction Link: https://github.com/Charles7c/continew-admin

What is expected?
打包后的效果和开发环境保持一致

开发环境效果：

打包后效果：

我初步排查是增加了类似这些样式。

类似问题，似乎是因为按需导入插件引起的，注释掉哪一块：

https://github.com/arco-design/arco-design-pro-vue/issues/256
https://github.com/arco-design/arco-design-pro-vue/issues/72


reverse sort list before playing it back

A bad bug here, if you are merging in two or more edits into Storage of the same message, the oldest edit wins!

I'll add a test later.

It should already be sorted coming into MergeHelper, but it's in the reverse order that updateAllSupersededBy needs. I think maybe my last change made this start showing up, but it's probably been in here forever.


Create v3.0.0 Release

Change Log
From v2.1.1 to v3.0.0
Fixes

Fixed random seeds to give reproducible results. Each dataset is initialized with a
single random state (either from the constructor or a random number generator) which
is used in all subsequent random operations. Each model is initialized with a single
random state as well: it uses the random state from the dataset, unless it's overriden
in the constructor. When a dataset is saved to a file so is its random state, which is
used by the dataset when the dataset is reloaded.
fixed error with serialization of the DNNModel.params attribute, when no parameters
are set.
Fix bug with saving predictions from classification model
when ModelAssessor.useProba set to False.
Add missing implementation of QSPRDataset.removeProperty
Improved behavior of the Papyrus data source (does not attempt to connect to the
internet if the data set already exists).
It is now possible to define new descriptor sets outside the package without errors.
Basic consistency of models is also checked in the unit test suite, including in
the qsprpred.extra package.
Fixed a problem with feature standardizer being retrained on prediction data when a
prediction from SMILES was invoked. This affected all versions of the package higher
or equal to v2.1.0.
Fixes to the  fromMolTable method in various data set implementations, in particular
in copying of the feature standardizer and other settings.
Fixed not working cluster split and --imputation from data_CLI.py.
Fixed a problem with ProteinDescriptorSet.getDescriptors returning descriptors in
wrong order with Pandas <v2.2.0.

Changes

The model is now independent of data sets. This means that the model no longer
contains a reference to the data set it was trained on.

The fitAttached method was replaced with fitDataset, which takes the data set
as
an argument.
Assessors now also accept a data set as a second argument. Therefore, the same
assessor
can be used to assess different data sets with the same model settings.
The monitoring API was also slightly modified to reflect this change.
If a model requires initialization of some settings from data, this can be done in
its initFromDataset method, which takes the data set as an argument. This method
is called automatically before fitting, model assessment, and hyperparameter
optimization.

The whole package was refactored to simplify certain commonly used imports. The
tutorial code was adjusted to reflect that.
The jupyter notebooks in the tutorial now pass a random state to ensure consistent
results.
The default parameter values for STFullyConnected have changed from n_epochs =
1000 to n_epochs = 100, from neurons_h1 = 4000 to neurons_h1 = 256
and neurons_hx = 1000 to neurons_hx = 128.
Rename HyperParameterOptimization to HyperparameterOptimization.
TargetProperty.fromList and TargetProperty.fromDict now accept a both a string and
a TargetTask as the task argument,
without having to set the task_from_str argument, which is now deprecated.
Make EarlyStopping.mode flexible for QSPRModel.fitDataset.
save_params argument added to OptunaOptimization to save the best hyperparameters
to the model (default: True).
We now use jsonpickle for object serialization, which is more flexible than the
non-standard approach before, but it also means previous models will not be compatible
with this version.
SklearnMetric was renamed to SklearnMetrics, it now also accepts an scikit-learn
scorer name as input.
QSPRModel.fitDataset now accepts a save_model (default: True)
and save_dataset (default: False) argument to save the model and dataset to a file
after fitting.
Tutorials were completely rewritten and expanded. They can now be found in
the tutorials folder instead of the tutorial folder.
MetricsPlot now supports multi-class and multi-task classification models.
CorrelationPlot now supports multi-task regression models.
The behaviour of QSPRDataset was changed with regards to target properties. It now
remembers the original state of any target property and all changes are performed in
place on the original property column (i.e. conversion to multi-class classification).
This is to always maintain the same property name and always have the option to reset
it to the raw original state (i.e. if we switch to regression or want to repeat a
transformation).
The default log level for the package was changed from INFO to WARNING. A new
tutorial
was added to explain how to change the log level.
RepeatsFilter argument year_name renamed to time_col and
arugment additional_cols added.
The perc argument of BorutaPy can now be set from the CLI.
Descriptor calculators (previously used to aggregate and manage descriptor sets) were
completely removed from the API and descriptor sets can now be added directly to the
molecule tables.
The rdkit-like descriptor and fingerprint retrieval functions were removed from the
API because they complicated implementation of customized descriptors.
The apply method was simplified and a new API was clearly defined for parallel
processing of properties over data sets. To improve molecule processing,
a processMols method was added to MoleculeTable.

New Features

The qsprpred.benchmarks module was added, which contains functions to easily
benchmark
models on datasets.
Most unit tests now have a variant that checks whether using a fixed random seed gives
reproducible results.
The build pipeline now contains a check that the jupyter notebooks give the same
results as ones that were observed before.
Added FitMonitor, AssessorMonitor, and HyperparameterOptimizationMonitor base
classes to monitor the progress of fitting, assessing, and hyperparameter
optimization, respectively.
Added BaseMonitor class to internally keep track of the progress of a fitting,
assessing, or hyperparameter optimization process.
Added FileMonitor class to save the progress of a fitting, assessing, or
hyperparameter optimization process to files.
Added WandBMonitor class to save the progress of a fitting, assessing, or
hyperparameter optimization process to Weights & Biases.
Added NullMonitor class to ignore the progress of a fitting, assessing, or
hyperparameter optimization process.
Added ListMonitor class to combine multiple monitors.
Cross-validation, testing, hyperparameter optimization and early-stopping were made
more flexible by allowing custom splitting and fold generation strategies. A tutorial
showcasing these features was created.
Added a reset method to QSPRDataset, which resets splits and loads all descriptors
into the training set matrix again.
Added ConfusionMatrixPlot to plot confusion matrices.
Added the searchWithIndex, searchOnProperty, searchWithSMARTS and sample
to MoleculeTable to facilitate more advanced sampling from data.
Assessors now have the split_multitask_scores flag that can be used to evaluate each
task seperately with single-task metrics.
MoleculeDataSets now has the smiles property to easily get smiles.
A Docker-based runner in testing/runner can now be used to test GPU-enabled features
and run the full CI pipeline.
It is now possible to save PandasDataTables to a CSV file instead of the default
pickle format (slower, but more human-readable).
New RegressionPlot class  WilliamsPlot added to plot Williams plots.
Data sets can now be optionally stored in the csv format and not just as a pickle
file. This makes it easier to debug and share data sets, but it is slower to load and
save.
Added ApplicabilityDomain class to calculate applicability domain and filter
outliers from test sets.

Removed Features

The Metric interface has been simplified in order to make it easier to implement
custom metrics. The Metric interface now only requires the implementation of
the __call__ method, which takes predictions and returns a float. The Metric
interface no longer requires the implementation
of needsDiscreteToScore, needsProbaToScore and supportsTask. However, this means
the base functionality of checkMetricCompatibility, isClassificationMetric
and isRegressionMetric are no longer available.
Default hyperparameter search space file, no longer available.

Fixes #8


Remove Auth0 from backend stack

There is a significant delay populating the dashboard with the user's data after logging in caused by the time taken for Auth0 to fetch user data from the existing database. Most users today expect quick/reliable access to their accounts across many different platforms with minimal delay. The same should be true for this application.

 Replace Auth0 authentication with Passport.js

 Remove Auth0

Implment passportjs in a graphql api was deemed too much technical debt. Adjusting to removing Auth0 from authentication system.

Resolved in #45


How to handle functions with multiple arguments ?

I am trying to build this plugin but it errors out
use extism_pdk::*;
use serde::Serialize;

#[derive(Serialize)]
struct Mesh {
    pub f_vertex_indices: Vec<u32>,
    pub nverts: Vec<u32>,
    pub verts: Vec<f64>
}

#[plugin_fn]
pub fn uv_sphere(n_stacks: u32, n_slices: u32) -> FnResult<Json<Mesh>> {
    let mut nverts: Vec<u32> = vec![];
    let mut f_vertex_indices: Vec<u32> = vec![];
    let mut verts: Vec<f64> = vec![];

error message from cargo build
   Compiling wasm_sphere v0.1.0 (/data1/nyue/projects/extism/hou_plugins)
error[E0061]: this function takes 2 arguments but 1 argument was supplied
  --> src/lib.rs:11:1
   |
11 | #[plugin_fn]
   | ^^^^^^^^^^^^ an argument of type `u32` is missing
   |
note: function defined here
  --> src/lib.rs:11:1
   |
11 | #[plugin_fn]
   | ^^^^^^^^^^^^
12 | pub fn uv_sphere(n_stacks: u32, n_slices: u32) -> FnResult<Json<Mesh>> {
   |                  -------------  -------------
   = note: this error originates in the attribute macro `plugin_fn` (in Nightly builds, run with -Z macro-backtrace for more info)
help: provide the argument
   |
11 | #[plugin_fn](#[plugin_fn], /* u32 */)
   |             +++++++++++++++++++++++++

For more information about this error, try `rustc --explain E0061`.
error: could not compile `wasm_sphere` (lib) due to previous error

I think I need to use/implement something call FromBytes so that the argument is a single item which represent my two values.
The examples all have single argument, is there one which shows how I can use fromBytes to map multiple arguments to a single value ?

@nyue - due to the way Extism works, and the goal of providing a universal ABI supported in every language, you actually don't pass any arguments into these functions. The rust-pdk macros combined with the extism-convert crate traits, make it appear that you are handling arguments, but in reality this is more of a convenient bit of magic.
Under the hood, the #[plugin_fn] expands into some code that calls extism_pdk::input() for you. And so long as your input argument to your export function implements the FromBytes trait, it will handle deserializing this data from the host for you.
To answer your question, the solution is to combine your input arguments into a new structure that implements FromBytes as you mentioned. This can be done easily via a struct that derives serde::Deserialize or any of the pre-supported encodings in the extism-convert crate. You can also implement support for your own types too.
The easiest path would be to do something like:
use your_library::{A, B, YourOutput};
use serde::Deserialize;
use extism_pdk::*;

#[derive(Deserialize)]
struct CombinedInput {
  pub a: A,
  pub b: B,
}

#[plugin_fn]
pub fn my_export(Json(input): Json<CombinedInput>) -> FnResult<Json<YourOutput>> {
  // do something with input.a

  // do something with input.b

  // ...
}

Note, this assumes YourOutput has a derive for serde::Serialize. But you don't have to use the Json conversion utility here, just adding for demonstration.

Closing as I feel like these answer the question, but feel free to re-open if you're not satisfied yet!


JWT Authorization

Is it possible to use JWT Authorization in the securitydefinitions annotations so we can authorize the client before using the API?
It seems that Swagger is implementing this via bearerAuth: https://swagger.io/docs/specification/authentication/bearer-authentication/
For OAuth2 this would look like the following:
// @securitydefinitions.oauth2.implicit OAuth2Implicit
// @authorizationurl https://example.com/oauth/authorize
// @scope.write Grants write access
// @scope.admin Grants read and write access to administrative information

I have not tested it, but it seems like this is already possible

SWAGER is OAS2 spec so the Authentication doc is located here.


Revert TypeScripting dropzone-widget (infinite render issue)

Purpose
Infinite rendering issue
Summary of Changes
Side Effects / Testing Notes
Ticket
https://openscience.atlassian.net/browse/EMB-
Reviewer Checklist

[ ] meets requirements
[ ] easy to understand
[ ] DRY
[ ] testable and includes test(s)
[ ] changes described in CHANGELOG.md

Coverage increased (+0.6%) to 30.55% when pulling 5d1f9e08878b991ef63d0a8211c3dd9eef2ca44a on binoculars:fix/dropzone-widget into 45826536cf99bf97b444617c445cb1a807447055 on CenterForOpenScience:develop.


removed unnecessary fmt.Sprintf

just a tiny cleanup

Thanks @simonkern -- please sign the CLA if you have not done so.

done


After clicking btn, the tabs are gone

扩展版本 (extension version): Version: 1.4.2 (Already the latest version)
浏览器版本 (browser version): Version 0.59.35 Chromium: 72.0.3626.81 (Official Build) (64-bit)
操作系统 (operating system): macOS 10.14.3 (18D42)
问题描述 (problem description):
After clicking btn, the tabs are gone

实际行为 (actual behavior):
期望行为 (expected behavior):
Store all tabs in current windows
重现步骤 (reproduce step):
Always occur.

Thank you for your reports. Did you turn on the option Open the tab list when store all tabs? If not, it may be because of the browser closed after storing all tabs so the code for writing the storage not executed. I'll try to perform writing storage firstly when all windows were closed.

Thank you for your reply. Yes, I turned on the option Open the tab list when store all tabs
The same issue happened in my
──Firefox 65.0 (64-bit)
──Firefox Nightly 67.0a1 (2019-02-07) (64-bit)
Strange things are


Changing custom cursor position on Linux can crash without errors.

Using a 64-bit build on Ubuntu 18.04.1 LTS with v3.1.alpha.custom_build.6ead007.
When trying to set the cursor position with Input.set_custom_mouse_cursor(texture, cursor, position) and the position exceeds some distance, it will crash without any useful information, unless I'm overlooking something.
A sample project to demo this:  Moving Cursor Bug.zip
@guilhermefelipecgs Hoping you may have some insight into this one.
Works fine on Windows 10 as far as I can tell.

It's seems on Linux we can't create a position (hotspot) bigger than the image size.
typedef struct _XcursorImage {
        XcursorDim    size;        /* nominal size for matching */
        XcursorDim    width;        /* actual width */
        XcursorDim    height;        /* actual height */
        XcursorDim    xhot;        /* hot spot x (must be inside image) */
        XcursorDim    yhot;       /* hot spot y (must be inside image) */
        XcursorPixel    *pixels;    /* pointer to pixels */
    } XcursorImage;

still crashes for negative values ;-)
print(x)
Input.set_custom_mouse_cursor(icon, 0, Vector2(x, x))
0.936904
0.313949
-0.313956
-0.93691
-1.545089
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  139 (RENDER)
  Minor opcode of failed request:  27 (RenderCreateCursor)
  Serial number of failed request:  401
  Current serial number in output stream:  404

@capnm Nice catch, just noticed this on a retest.  Next time I rebuild I'll triple check.  Any insight into why the hotspot is so finicky for Linux?

Not really, but it makes sense to me that it shouldn't be outside the cursor shape.


[RESOLVED] High ICMP ping response time

Problem started at 13:31:14 on 2023.05.10
Problem name: High ICMP ping response time
Host: MF-FG
Severity: Warning
Operational data: Value: 762ms
Original problem ID: 20492
Event details in Zabbix: http://<IP_ADDRESS>/tr_events.php?triggerid=23132&eventid=20492

Problem has been resolved in 8m 0s at 13:39:14 on 2023.05.10
Problem name: High ICMP ping response time
Host: MF-FG
Severity: Warning
Original problem ID: 20492


Container, Containerization

Objectives:

[ ]   What is a container?
[ ]   Understand how containers work?

Containers
Linux containers are technologies that allow you to package and isolate applications with their entire runtime environment—all of the files necessary to run. This makes it easy to move the contained application between environments (dev, test, production, etc.) while retaining full functionality.
i.e. It provides a logical packaging mechanism in which applications can be abstracted from the environment in which they actually run which allows container-based applications to be deployed easily and consistently, regardless of whether the target environment is a private data center, the public cloud, or even a developer’s personal laptop.
Containers provide isolation between the application environment and the external host system, support a networked, service-oriented approach to inter-application communication, and typically take configuration through environmental variables and expose logs written to standard error and standard out.
Containers themselves encourage process-based concurrency and help maintain dev/prod parity by being independently scalable and bundling the process’s runtime environment.
Containers create consistent environments to rapidly develop and deliver cloud-native applications that can run anywhere.
Containers are also an important part of IT security. By building security into the container pipeline and defending your infrastructure, you can make sure your containers are reliable, scalable, and trusted.
Containers silo applications from each other unless you explicitly connect them. That means you don't have to worry about conflicting dependencies or resource contention — you set explicit resource limits for each service. Importantly, it's an additional layer of security since your applications aren't running directly on the host operating system.
Benefits Of Using Containers:
Portability: Apps developed in containers have everything they need to run and can be deployed in multiple environments, including private and public clouds. Portability means flexibility because you can more easily move workloads between environments and providers.
Scalability: Containers have the ability to scale horizontally, meaning a user can multiply identical containers within the same cluster to expand when needed. By using and running only what you need when you need it, you can reduce costs dramatically.
Efficiency: Containers require fewer resources than virtual machines (VMs) since they don’t need a separate operating system. You can run several containers on a single server and they require less bare-metal hardware, which means lower costs.
Increased security: Containers are isolated from each other, which means if one container is compromised, others won’t be affected.
Speed: Because of their autonomy from the operating system, starting and stopping a container is a matter of seconds. This also allows for faster development and operational speed, as well as a faster, smoother user experience.

Containerization provides a clean separation of concerns, as developers focus on their application logic and dependencies, while IT operations teams can focus on deployment and management without bothering with application details such as specific software versions and configurations specific to the app.It reinforces many of the principles from #174 The Twelve-Factor App principles, allowing easy scaling and management.
Resources

[ ] https://cloud.google.com/containers
[ ] https://gumroad.com/l/containers-zine
[ ] how-containers-work.pdf
[ ] https://gumroad.com/d/f7c267e0fbb310efbc182b545a55a7bf
[ ] https://www.docker.com/resources/what-container
[ ] https://cloud.google.com/containers
[ ] https://www.infoq.com/containers
[ ] https://github.com/lizrice/containers-from-scratch | https://www.youtube.com/watch?v=8fi7uSYlOdc, https://www.youtube.com/watch?v=GR5O3BSbkYM
[ ] Google Kubernetes Engine (GKE) description
[ ] https://wiki.aquasec.com/display/containers
[ ] https://jvns.ca/blog/2016/10/10/what-even-is-a-container/
[ ] https://platform.sh/blog/2020/the-container-is-a-lie/
[ ] https://www.redhat.com/en/services/training/do080-deploying-containerized-applications-technical-overview

Open Container Initiative (OCI)
Well, referenced from the OCI Offical Site, the Open Container Initiative (OCI) launched on June 22nd 2015 by Docker, CoreOS and other partners is a lightweight project, for the express purpose of creating open industry standards around container formats and runtime.
The OCI currently contains two specifications: the Runtime Specification (runtime-spec) and the Image Specification (image-spec). The Runtime Specification outlines how to run a “filesystem bundle” that is unpacked on disk. A “filesystem bundle” is a set of files organized in a certain way, and containing all the necessary data and metadata for any compliant runtime (eg Docker and CRI-O) to perform all standard operations against it.
At a high-level an OCI implementation would download an OCI Image then unpack that image into an OCI Runtime filesystem bundle. At this point the OCI Runtime Bundle would be run by an OCI Runtime (eg Docker and CRI-O). Now moving to Buildah.

Container Functionalities
Container Engines

#20 Docker
#97 Podman
https://linuxcontainers.org/lxd/introduction
https://cri-o.io
https://www.openshift.com/learn/topics/rkt

Image Builder

#105 Kaniko
https://buildah.io
https://github.com/moby/buildkit
https://github.com/openshift/source-to-image
https://github.com/GoogleContainerTools/jib
https://github.com/bazelbuild/bazel

Container Runtime

https://github.com/containerd/containerd; Also acts as an API facade for various container runtimes
https://github.com/opencontainers/runc
https://github.com/containers/crun

Image Inspection and Distribution

https://github.com/wagoodman/dive: A tool for exploring each layer in a docker image
https://github.com/containers/skopeo: Work with remote images registries - retrieving information, images, signing content


multiple TX-RX CSI setup

greetings,
how can we setup multiple TX-RX CSI, based on the page,  I guess we can do 1AP-multipleStations setup, so there are multiple TX-RX setup. What is the commands for establishing the AP-station links? How can we sync these stations?
Best
Jet

When configuring the esp32s (https://github.com/StevenMHernandez/ESP32-CSI-Tool#configuration-esp-idf) the ESP32 CSI Tool Config > **** configuration options will allow you to set each STA to connect to a single AP. Make sure both STAs are flashed with the same SSID/Password so that they can connect to the same AP.
We want more help to make the multi-TX/RX system more robust! Any additional help is always appreciated!


fix missing logs in grafana

Ensure that Grafana and Prometheus are indeed deployed in HA (kill nodes one by one)

Fix prometheus/prometheus agents (runs in docker on ctl0{1,2,3})

Add alerts that will trigger when this happens again

Integrate /etc/kolla/prometheus-server/replacer.sh into playbooks/hooks


Link in README does not work (installation)

I just wanted to read the installation instructions in the README-File.
I wanted to click on the following content:
See [installation manual](https://trusted-cgi.reddec.net/installation)
Unfortunately the link did not work. Where can I find the  detailed installation instructions?
Thanks for updating.

My bad https://trusted-cgi.reddec.net/administrating/installation/

fixed

That was fast. Thanks.


[Frontend] Check if still logged in on component load

When two tabs of the application are opened on the user's device, logging out in one of them doesn't automatically log them out of the other tab (until they perform a reload of the page, which isn't necessary to use the application since it's a SPA). This can be a security problem for logged-in admins on public PCs.

Fixed in PR #56


Remove leading and trailing whitespace from variable names in PlainText reader.

I was reading some csv data using the PlainText reader and noticed that the variable names were grouped strangely. I believe this is because the variable names include leading and trailing whitespace. A sample of the file that demonstrates this is:
coords/x, coords/y, coords/z, d/c0, domain_id, vertex_id
2, 0, 0, 2, 0, 0
2.1, 0, 0, 2.1, 0, 1
2.2, 0, 0, 2.2, 0, 2
2.3, 0, 0, 2.3, 0, 3

Be aware that the PlainText reader does permit whitespace as a separator (it might only be tabs but not spaces, I don't honestly know) and that potentially complicates handling leading/trailing whitespace in variable names.


I used helm2 so maybe these are not needed in helm3

It looks like this PR is changing Helm 3 commands to Helm 2 commands. This shouldn't be necessary because the older version of the docs with the Helm 2 commands are retained here: https://rancher.com/docs/rancher/v2.x/en/installation/options/helm2/


Modulized library

Single commit as requested.

Shall I merge this as 0.1.9?

Hey @sgen, Sorry about the delay. I got caught up with work. All good now. Spot on.


resizeHandle prop does nothing

The resizeHandle prop (as mentioned here) doesn't appear to exist on the ReactGridLayout component. It does seem to be implemented on the GridItem component and ReactGridLayoutPropTypes, however.
Also, I noticed that this example is producing a 404: https://strml.github.io/react-grid-layout/examples/17-resizable-handles.html

version with this changes not released yet https://github.com/STRML/react-grid-layout/pull/1303

🤦 my bad. Well, I'll patiently wait for the release. Thanks!!

shouldn't appear on readme.md if the changes not released 😡

Any news?  resizeHandle is doing nothing
resizeHandle: resizeHandle={axis => {
return <TdIcon axis={axis} medium iconName={'arrowDown'} />;
}}

+1, a new release with this feature would be much appreciated. Thanks guys!