UI - Loading Bar

Changes:

Added a loading bar that tracks progress when the graph data is being loaded in chunks. It does not display when the graph is loading "normally" without chunks.

I'm starting to wonder if we would always be better off loading the data through chunks, because it does seem to be faster, and then we can just get rid of the option to load either normally or chunked.

Disabled drawing while chunking and waiting till all data is loaded.

I talked with @rwhite226 and @winder487 today and it seems that we're better off not drawing the graph as chunks come in, and just wait until all the data comes over before drawing the graph. I did some quick runtime comparisons and it does seem that we're better off doing it this way, because the physics engine isn't running in the canvas and that eliminates the extra waiting time when the graph is stabilizing.

Styles.js is a file for generic JS objects holding style objects for CSS. Write new style objects in here if you need extra CSS for stuff and reference it in whatever you're writing - see LoadingBar.js for examples. This seems to be the easiest way to do CSS within the confines of React.

+1

+1
On Thu, Feb 25, 2016, 11:57 AM Richard White<EMAIL_ADDRESS>wrote:

+1
—
Reply to this email directly or view it on GitHub
https://github.com/rwhite226/Graphalyzer/pull/25#issuecomment-188904603.

+1

+1


Update ClientConfig record to latest

Purpose
Client initialization of the generated connectors only includes auth and secureSocket configurations as below.
    public type ClientConfig record {
        http:BearerTokenConfig|http:OAuth2RefreshTokenGrantConfig authConfig;
        http:ClientSecureSocket secureSocketConfig?;
    };
    public isolated function init(ClientConfig clientConfig, string serviceUrl = "https://api.zoom.us/v2") returns error? {
        http:ClientSecureSocket? secureSocketConfig = clientConfig?.secureSocketConfig;
        http:Client httpEp = check new (serviceUrl, { auth: clientConfig.authConfig, secureSocket: secureSocketConfig });
        self.clientEp = httpEp;
    }

Other than these configurations there are set of other configurations provided through Ballerina http:ClientConfiguration record.
This PR will update all the existing OpenAPI connectos with http or OAuth2.0 authentication mechanism to latest changes in connector configuration.
Security checks

Followed secure coding standards in http://wso2.com/technical-reports/wso2-secure-engineering-guidelines? yes
Ran FindSecurityBugs plugin and verified report? no
Confirmed that this PR doesn't commit any keys, passwords, tokens, usernames, or other secrets? yes

Test environment

Java JDK 11

Closing the PR since the PR build has failed.


Release 0.7.0

Codecov Report

Merging #58 (30ab2e6) into main (39163e7) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main      #58   +/-   ##
=======================================
  Coverage   94.46%   94.46%
=======================================
  Files          24       24
  Lines         867      867
=======================================
  Hits          819      819
  Misses         48       48

Impacted Files
Coverage Δ

...antUMLFramework/Configuration/ElementOptions.swift
96.87% <100.00%> (ø)

...s/SwiftPlantUMLFramework/Configuration/Theme.swift
93.33% <100.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


when I tried to check in code it asked me to sign both pzou1974 and pzou

URL to the linked Repo/Org:
https://github.com/keikoproj/addon-manager/pull/14
Steps to reproduce the problem:

go to https://github.com/keikoproj/addon-manager/pull/14
I used user pzou1974 and it is signed but I still got blocked.
not sure why pzou is related to pzou1974

What is the expected result?
What happens instead?

Hi @pzou1974, I just reviewed the pull request and it looks like there are commits like test checkin from pzou account as well. And the commits from this account pzou are not recognised by GitHub because you need to add the email address you used for the commit in your local git configuration.


NIFI-4853: Fixed PutMongoRecord handling of nested records

Thank you for submitting a contribution to Apache NiFi.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[x] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?

[x] Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

[x] Has your PR been rebased against the latest commit within the target branch (typically master)?

[x] Is your initial contribution a single, squashed commit?

For code changes:

[x] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
[x] Have you written or updated unit tests to verify your changes?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?
[ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
[ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

For documentation related changes:

[ ] Have you ensured that format looks appropriate for the output in which it is rendered?

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.

Ran fine on my end. LGTM. Thanks

+1, merging to master, ran some tests on a local Mongo, all looks good. Thanks!


Update readline syntax file with some new options

Simply updates the syntax file with some newer readline options. Should be pretty uncontroversial :)

Codecov Report

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

@@            Coverage Diff             @@
##           master    #1795      +/-   ##
==========================================
- Coverage   75.11%    75.1%   -0.02%
==========================================
  Files          76       76
  Lines      125130   125090      -40
==========================================
- Hits        93990    93947      -43
- Misses      31140    31143       +3

Impacted Files
Coverage Δ

src/if_py_both.h
75.31% <0%> (-0.71%)
:arrow_down:

src/if_xcmdsrv.c
85.18% <0%> (-0.19%)
:arrow_down:

src/window.c
81.42% <0%> (-0.07%)
:arrow_down:

src/gui.c
45.64% <0%> (+0.05%)
:arrow_up:

src/undo.c
81.71% <0%> (+0.06%)
:arrow_up:

src/message.c
68.57% <0%> (+0.45%)
:arrow_up:

Continue to review full report at Codecov.

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

please discuss with the syntax script maintainer

Already tried to get in touch with the maintainer but never got a response sadly. Assuming this syntax file has no active maintainer given there's only a "Previous Maintainer" listed.

so would you volunteer to become the new maintainer?

What does being a syntax file maintainer entail? I'm not opposed to it, but I'm also not a readline developer, nor do I consider myself a Vim expert.

Any chance this could be merged? It's a trivial patch.

Nikolai gave up maintenance.  I'll include this change for now.  Hopefully a real maintainer comes forward.


enable complete barcode support, test data pending

clang-format once again reordered my headers, but otherwise this enable propagation of:

ReadGroupInfo BarcodeData
"bc" and "bq" tags for barcode assignments and barcode quality, respectively
bailing out if the data doesn't hold to the contract of same calls and quality for each subread from a ZMW

Looks good, this will also require an update to README.md

Let me update the PR with a commit for the CHANGELOG and the README

Now with documentation!

@evolvedmicrobe waiting your review

Looks good to me, I probably would have mentioned the field numbering changes in the readme, but they are on different commits so I think it's okay.


added documentation for get_standard_gate_name_mapping

Summary
Added documentation for the function get_standard_gate_name_mapping() in the Standard Gates section here.
#Closes #13108
Details and comments
I have added the necessary details about the function with code examples in the documentation.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>5
Details

0 of 0   changed or added relevant lines in 0 files are covered.
12 unchanged lines in 3 files lost coverage.
Overall coverage increased (+0.02%) to 88.845%

Files with Coverage Reduction
New Missed Lines
%

qiskit/transpiler/passes/synthesis/unitary_synthesis.py
2
88.26%

crates/qasm2/src/lex.rs
4
92.98%

qiskit/synthesis/two_qubit/xx_decompose/decomposer.py
6
90.91%

Totals

Change from base Build<PHONE_NUMBER>5:
0.02%

Covered Lines:
74013

Relevant Lines:
83306

💛  - Coveralls

Thanks! My understanding of the OP message in the issue is to extend qiskit.circuit.library.standard_gates.get_standard_gate_name_mapping docstring. I think it makes sense to mention it too at module level.

I did not understand what you mean by that. Do I need to add this documentation somewhere else?

Do I need to add this documentation somewhere else?

Yes. The documentation should go under def get_standard_gate_name_mapping in qiskit/circuit/library/standard_gates/__init__.py.

Okay. I will move it there.
Thank you

@Mergifyio backport stable/1.3


Add missing  header

Otherwise the compiler will compiain:

error: aggregate std::array<unsigned char, 5000> buffer has incomplete type and cannot be defined
error: data has incomplete type

I test with 3 versions of gcc. This error only occur in gcc12.

gcc version 12.2.0 : NG
gcc version 11.4.0 : OK
gcc version 11.3.0 : OK


Add the ability to display line mode on the left side of the pane.

yazi --debug output
Yazi
    Version: 0.3.3 (Arch Linux 2024-09-16)
    Debug  : false
    OS     : linux-x86_64 (unix)

Ya
    Version: 0.3.3 (Arch Linux 2024-09-16)

Emulator
    Emulator.via_env: ("foot-extra", "")
    Emulator.via_csi: Ok(Foot)
    Emulator.detect : Foot

Adapter
    Adapter.matches: Sixel

Desktop
    XDG_SESSION_TYPE           : Some("wayland")
    WAYLAND_DISPLAY            : Some("wayland-1")
    DISPLAY                    : Some(":0")
    SWAYSOCK                   : Some("/run/user/1001/sway-ipc.1001.288373.sock")
    HYPRLAND_INSTANCE_SIGNATURE: None
    WAYFIRE_SOCKET             : None

SSH
    shared.in_ssh_connection: false

WSL
    WSL: false

Variables
    SHELL              : Some("/bin/bash")
    EDITOR             : Some("nvim")
    VISUAL             : Some("nvim")
    YAZI_FILE_ONE      : None
    YAZI_CONFIG_HOME   : None

Text Opener
    default: Some(Opener { run: "${EDITOR:=nvim} \"$@\"", block: true, orphan: false, desc: "Edit with nvim", for_: None, spread: true })
    block  : Some(Opener { run: "${EDITOR:=nvim} \"$@\"", block: true, orphan: false, desc: "Edit with nvim", for_: None, spread: true })

Multiplexers
    TMUX               : false
    tmux version       : 3.4
    ZELLIJ_SESSION_NAME: None
    Zellij version     : 0.40.1

Dependencies
    file             : 5.45
    ueberzugpp       : No such file or directory (os error 2)
    ffmpegthumbnailer: 2.2.3
    magick           : 7.1.1-38
    fzf              : 0.55.0
    fd               : 10.2.0
    rg               : 14.1.1
    chafa            : 1.14.2
    zoxide           : 0.9.5
    7z               : 17.05
    7zz              : No such file or directory (os error 2)
    jq               : 1.7.1

Please describe the problem you're trying to solve
The current layout for displaying filenames with corresponding information on the opposite side of the pane may not be optimal on large, high res screens and tilling window managers.
Would you be willing to contribute this feature?

[ ] Yes, I'll give it a shot

Describe the solution you'd like
The ability to display line mode to the left of the filename would make eye tracking much easier in the above cases.
Additional context

Validations

[X] I have searched the existing issues
[X] The latest nightly build of Yazi doesn't already have this feature

With https://github.com/sxyazi/yazi/pull/1667, you can achieve it by overwriting the Current:render() method with the following code:
-- ~/.config/yazi/init.lua
local current_render = Current.render
function Current:render()
  local t = current_render(self)
  if #t < 2 then
    return t
  end

  local area, width = t[1]:area(), t[2]:max_width()
  t[1] = t[1]:area(ui.Rect { x = area.x + width, y = area.y, w = math.max(0, area.w - width), h = area.h })
  t[2] = t[2]:align(ui.Paragraph.LEFT)
  return t
end

Set linemode to mtime:

Set linemode to permissions:

Set linemode to owner:

Thank you! Is it possible to right align?

It's possible, just a small change based on https://github.com/sxyazi/yazi/issues/1656#issuecomment-2364234167
-  t[2] = t[2]:align(ui.Paragraph.LEFT)
+  t[2] = t[2]:area(ui.Rect { x = area.x, y = area.y, w = math.min(width, area.w), h = area.h })

Yazi offers a rich layout API, allowing you to implement just about any functionality you want. Check out the layout API doc here: https://yazi-rs.github.io/docs/plugins/layout


Update index.d.ts

The API call is actually in the opposite order, which might cause a little confusion by Typescript users

Thanks so much, @akivab! You're totally right — the TypeScript type signature got it backwards. Merging this now.


Extract NMEA messages from this package

@kriskozak says:

While work is going on to add support for new messages, I would recommend looking into moving some or all of the messages out of this package. At the very least, the NMEA messages don't really belong here -- they have occasionally gotten used by other GPS drivers. Perhaps they should be added to https://github.com/swri-robotics/marti_messages

There's a pending PR to add the NMEA messages to nmea_msgs: https://github.com/ros-drivers/nmea_msgs/pull/5
Once I accept that, we can remove those messages from this package.

Fyi @pjreed -- Looks like this is done.


File is not closed on XML object destruction

If you do:
results = Nmap::XML.new('/tmp/tmp.xml')
results = nil

The file is kept open in lsof. If you are analysing hundreds of results, it keeps hundreds of files open :(
$ lsof -n | grep -i tmp.xml
ruby2.3    18083               deployer   14r      REG                8,1        0    1131267 /tmp/tmp.xml
logger.rb  18083  18097        deployer   14r      REG                8,1        0    1131267 /tmp/tmp.xml
spawner.r  18083  18102        deployer   14r      REG                8,1        0    1131267 /tmp/tmp.xml
spawner.r  18083  18103        deployer   14r      REG                8,1        0    1131267 /tmp/tmp.xml
spawner.r  18083  18104        deployer   14r      REG                8,1        0    1131267 /tmp/tmp.xml
spawner.r  18083  18106        deployer   14r      REG                8,1        0    1131267 /tmp/tmp.xml
ruby-time  18083  18108        deployer   14r      REG                8,1        0    1131267 /tmp/tmp.xml

Any solution?

Off the top of my head open(path) { |file| @doc = Nokogiri::XML(file) }. I want to avoid loading the full file contents into memory, as some nmap XML files can get quite large. Nokogiri appears to support streamed parsing of IO objects under the hood. https://github.com/sparklemotion/nokogiri/blob/7f8b7b2bf55829e02cd11c2eb25814c3ed458676/ext/nokogiri/xml_document.c#L219-L267

Fixed in 24a99ebf7e3a48fa37251b6ee5babce970e10064. Releasing 0.9.2 shortly.


adjust styling to align columns between header and content on pages

align search bar with middle two columns on home page and main column on article reader pages and static content pages

fixes: https://github.com/participedia/usersnaps/issues/499
@jesicarson here are a bunch of screenshots of the different breakpoints. i can do a screenshare with you if you'd like, or let me know if you want to see other breakpoints/screens

@jesicarson this is the only screen width where the search column doesn't stretch to fill the width of the center 2 columns (on the home page only). i had to reduce the width of the center column to accommodate the quick submit/login buttons on the right.

@ascott Columns look much better aligned thanks! In some of the screenshots I see the language drop down appearing in the homepage search results - is that a screenshot glitch or?

@jesicarson thanks jesi! on the homepage, that's just a screenshot i used for an article to test something, sorry it's a bit confusing!


move process related logic to system dir

Signed-off-by: Tianle Huang<EMAIL_ADDRESS>Description
move process terminate logic to system dir. During the review of this PR https://github.com/opensearch-project/opensearch-build/pull/845, there is a comment to create a separate PR for moving process terminate logic.
Test
Since this PR just adds a utility function, we only test by adding a unit test and run the following test command.
opensearch@81f24e989d16 opensearch-build]$ pipenv run pytest tests/tests_system/test_process.py
.                                                                                [100%]
1 passed in 0.02s

Issues Resolved
https://github.com/opensearch-project/opensearch-build/issues/852
Check List

[ x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #853 (a33e5bd) into main (3787942) will decrease coverage by 0.63%.
The diff coverage is 67.50%.

@@            Coverage Diff             @@
##             main     #853      +/-   ##
==========================================
- Coverage   91.60%   90.96%   -0.64%
==========================================
  Files          81       82       +1
  Lines        2250     2290      +40
==========================================
+ Hits         2061     2083      +22
- Misses        189      207      +18

Impacted Files
Coverage Δ

src/system/process.py
67.50% <67.50%> (ø)

src/system/temporary_directory.py
82.75% <0.00%> (-13.80%)
:arrow_down:

src/system/os.py
92.30% <0.00%> (-7.70%)
:arrow_down:

Continue to review full report at Codecov.

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

You need to go further in refactoring this, and also change the code that uses it in the same PR.

modified the local test cluster logic as well as its tests.

could we ignore pyc file
refer to https://stackoverflow.com/questions/32110126/should-i-put-pyc-files-under-version-control

could we ignore pyc file refer to https://stackoverflow.com/questions/32110126/should-i-put-pyc-files-under-version-control

Sure. removed them and also updated gitignore

1. Re-implement tests for timeout expired, stderr and stdout. We had those and refactoring should be adding more tests, not less.

2. If I call `Process#start` twice I lose track of the process. Raise an exception if that happens. Add tests.

3.  Raise an exception, add tests.

4. Add a `started()` method and use `if not process.started()` instead of `process.pid is None`.

5. In the test execute something that doesn't return, e.g. `bash`, so we can see that termination works.

6. Rebase.

Thanks for the detailed instruction. Just try to think from the caller's perspective. The OpenSearch and OpenSearchDashboards will have their own instance of Process class. Thus we will not try to reuse the instance and call start twice. Also the exception handling about TimeoutExpired does not impact the caller's behavior. Thus to have a MVP feature working soon, I am proposing a tentative plan to use kill() directly and remove the exception handling, test the happy case, rebase and backlog all other items to issues.
A side question is for # 5, I do not quite get the idea. Could you help elaborate more?

Thanks for the detailed instruction. Just try to think from the caller's perspective. The OpenSearch and OpenSearchDashboards will have their own instance of Process class. Thus we will not try to reuse the instance and call start twice.

You can't rely on user to do the right thing for a class that should stand on its own. A developer can easily make a mistake in the future, so guard the code from it.

Also the exception handling about TimeoutExpired does not impact the caller's behavior. Thus to have a MVP feature working soon, I am proposing a tentative plan to use kill() directly and remove the exception handling, test the happy case, rebase and backlog all other items to issues.

Let's see that PR.

A side question is for # 5, I do not quite get the idea. Could you help elaborate more?

In your tests you call "ls". That process finishes before you know it, so you don't get to actually test termination. Instead, call read -n1 ans that blocks until someone presses a key, or bash, which will start a new shell and hang out there.

Thanks for the detailed instruction. Just try to think from the caller's perspective. The OpenSearch and OpenSearchDashboards will have their own instance of Process class. Thus we will not try to reuse the instance and call start twice.

You can't rely on user to do the right thing for a class that should stand on its own. A developer can easily make a mistake in the future, so guard the code from it.

Also the exception handling about TimeoutExpired does not impact the caller's behavior. Thus to have a MVP feature working soon, I am proposing a tentative plan to use kill() directly and remove the exception handling, test the happy case, rebase and backlog all other items to issues.

Let's see that PR.

A side question is for # 5, I do not quite get the idea. Could you help elaborate more?

In your tests you call "ls". That process finishes before you know it, so you don't get to actually test termination. Instead, call read -n1 ans that blocks until someone presses a key, or bash, which will start a new shell and hang out there.

For # 5, I have experienced some issues about inconsistency behavior in my local AL2 machine and the Ubuntu check on PR.
process_handler.start("read -n1 ans", ".") is working fine in AL2. However, when running from Github Action, it will fail the PR check "python-tests / test (ubuntu-latest) (pull_request) " with error about invalid option "-n1". I have tried multiple commits to fix it
https://github.com/opensearch-project/opensearch-build/pull/853/commits/0b2d1ac5724c5131bb66d564a07cbf09c57a9d48
https://github.com/opensearch-project/opensearch-build/pull/853/commits/4f3b59a8732110a5578563ca9dc6100176393445
and none of these will pass the "python-tests / test (ubuntu-latest) (pull_request) ".
Eventually the following way makes it work by running from a shell.
process_handler.start("./tests/tests_system/data/wait_for_input.sh", ".")

All checks have passed. Addressing dblock@'s remaining comments.

All checks have passed. Addressing dblock@'s remaining comments.

You also need a test that shows that you're correctly reading stdout and stderr.

You also need a test that shows that you're correctly reading stdout and stderr.

Added the validation for these. Let me know if this is enough.

This is good. Thanks for hanging in here. Do you want to take care of my suggestions below before/after the merge?

Let me quickly address your new comments as part of this PR.

This is good. Thanks for hanging in here. Do you want to take care of my suggestions below before/after the merge?

Let me quickly address your new comments as part of this PR.

Addressed the new comments about the Exception class.


update check button feature

This pull request addresses issue #38
Before:

After:

Works as expected @atmaram-kambli. Congratulations on your first contribution to Minglr 🎉

Thank You for the opportunity✌


New version: UniversityofLjubljana.Orange version 3.35.0

Pull request has been created with Komac v1.6.0 :rocket:
Microsoft Reviewers: Open in CodeFlow

Manual Validation failed after 2.2 hours due to an out of memory situation causing the validating terminal to be closed. Will retry tomorrow.

Manual Validation failed after 2.2 hours due to an out of memory situation causing the validating terminal to be closed. Will retry tomorrow.

Installed and launched properly for me in sandbox -
--> Installing WinGet
Tip: you can type 'Update-EnvironmentVariables' to update your environment variables, such as after installing a new software.

--> Configuring Winget
Admin setting enabled.Admin setting enabled.

--> Installing the Manifest 3.35.0

Found Orange [UniversityofLjubljana.Orange] Version 3.35.0
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://download.biolab.si/download/files/Orange3-3.35.0-Miniconda-x86_64.exe
  ██████████████████████████████   523 MB /  523 MB
Successfully verified installer hash
Starting package install...
Successfully installed

--> Refreshing environment variables

--> Comparing ARP Entries

DisplayName                                   DisplayVersion Publisher      ProductCode
-----------                                   -------------- ---------      -----------
Miniconda3 py39_4.12.0 (Python 3.9.12 64-bit) py39_4.12.0    Anaconda, Inc. Miniconda3 py39_4.12.0 (Python 3.9.12 64-bit)
Orange 3.35.0 (64 bit)                        3.35.0                        OrangeCanvas

Machine scope validation completed in 1.09 hours. User scope validation still underway.


Restart agent on SIGPIPE (journald restart)

We had an issue where the agent failed to restart on SIGPIPE, which turns out to be a thing when systemd and journald restart.
Similar to https://github.com/influxdata/telegraf/pull/2716.

RestartForceExitStatus= option was not added until systemd 215, but from what I can see the version is 219 in the latest Amazon Linux 2. Fingers crossed!


New Hero variant - Navy Blue

What is the context of this PR?
ONSDESYS-163....
Created new Hero variant as per the Figma.
Prototype link
How to review this PR
Check that new example-hero-navy-blue in Hero component matches the figma design
Checklist
This needs to be completed by the person raising the PR.

[x] I have selected the correct Assignee
[x] I have linked the correct Issue

For mobile the spots aren't supposed to be shown according to the prototype but I can see that in figma they are shown, this may need to be checked which one is correct

For mobile the spots aren't supposed to be shown according to the prototype but I can see that in figma they are shown, this may need to be checked which one is correct

This still needs to be addressed

For mobile the spots aren't supposed to be shown according to the prototype but I can see that in figma they are shown, this may need to be checked which one is correct

This still needs to be addressed

I had a chat with Joe regarding this, we need to keep the circles when display is set to mobile. According to him, this correlates with data in the website. As we further go into the website number of circles will decrease.


AttributeError: <class 'qiime2.core.type.grammar.UnionExp'> object has no attribute 'decode'

Bug Description
I am using decode_parameters to decode the inputs to a plugin action. For some plugins this works as expected, however, for others it fails.
Steps to reproduce the behavior
The following fails:
import qiime2
PLUGIN_MANAGER = qiime2.sdk.PluginManager()

method = PLUGIN_MANAGER.plugins["feature-classifier"].actions["classify_sklearn"]

job_params = {
    "reads_per_batch": "auto",
    "n_jobs": "1",
    "pre_dispatch": "2*n_jobs",
    "confidence": "0.7",
    "read_orientation": "auto",
}

method.signature.decode_parameters(**job_params)

---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-3-a4066188cdc2> in <module>
     21             job_params[parameter["parameter_name"]] = parameter["value"]
     22     print(job_params)
---> 23     _ = method.signature.decode_parameters(**job_params)
     24     print(job_params)

~/miniconda3/envs/kamino/lib/python3.8/site-packages/qiime2/core/type/signature.py in decode_parameters(self, **kwargs)
    318                 params[key] = None
    319             else:
--> 320                 params[key] = spec.qiime_type.decode(kwargs[key])
    321         return params
    322

~/miniconda3/envs/kamino/lib/python3.8/site-packages/qiime2/core/type/grammar.py in __getattr__(self, name)
     55             return getattr(self.template, name)
     56
---> 57         raise AttributeError("%r object has no attribute %r"
     58                              % (type(self), name))
     59

AttributeError: <class 'qiime2.core.type.grammar.UnionExp'> object has no attribute 'decode'

Other actions work without issue, for example:
job_params = {
    "trunc_len_f": 0,
    "trunc_len_r": 0,
    "trim_left_f": 19,
    "trim_left_r": 20,
    "max_ee_f": 2.0,
    "max_ee_r": 2.0,
    "trunc_q": 2,
    "pooling_method": "independent",
    "chimera_method": "consensus",
    "min_fold_parent_over_abundance": 1.0,
    "n_threads": 1,
    "n_reads_learn": 1000000,
    "hashed_feature_ids": "true",
}

method = PLUGIN_MANAGER.plugins["dada2"].actions["denoise_paired"]
method.signature.decode_parameters(**job_params)

Expected behavior
I expect method.signature.decode_parameters to return a dictionary of parameters that can be passed into the method call
Computation Environment

Ubuntu 20.04.2 LTS
QIIME 2 Release 2021.4.0

Comments
I'm not sure I understand what is happening behind the scenes enough to understand why parameters are being assigned to different types behind the scenes. Perhaps this is expected, but I am misudnerstanding the use of decode_parameters?
I saw this same error referenced in the forum but don't know if it was ever resolved

Whoops, no that's on us, decode_parameters should probably be updated, but most of our interfaces use parse_primitive from qiime2.sdk.util instead, which should handle this correctly.
It used to be the case that a single expression only ever had a single type, and so a decode made sense. This isn't true anymore with things like Int % Range(...) | Str % Choices(...), and parse_primitive was added to handle this in a more complete way.
Also as a heads up, this helper can be given ASTs instead of expression strings, which are useful if a type variable exists in your expression (as the only way we have to produce the complete context of those is via the AST)

@ebolyen Thanks for the quick response! I was not aware of parse_primitive as far as I can tell it is working how I would expect


Link to lambda blog post

Suggesting to update the link "Implement lambda pipelines on Azure" to point to the new blog post https://azure.microsoft.com/en-us/blog/the-emerging-big-data-architectural-pattern/

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

ID: fdcc897a-d6df-3305-e9cb-01889a3c5d4f
Version Independent ID: 739a9fc7-3782-a860-ac6d-4194fd1ce2e8
Content: Working with the change feed support in Azure Cosmos DB
Content Source: articles/cosmos-db/change-feed.md
Service: cosmos-db
GitHub Login: @rafats
Microsoft Alias: rafats

@algattik Thanks for the feedback! I have assigned the issue to the author to investigate and update as appropriate.

Thanks for the suggestions, we will look into it. #please-close


Terminal crashes when graphics cards timeout and graphics driver does soft reset

When the graphics cards do a soft reset, the terminal crashes. I need to make sure the DX code is more robust.
Also lol at getting my own issue closed for an empty description.

FWIW, this does not reproduce using CTRL+SHIFT+WIN+B


Native Editor - saving an unrun file results in invalid json

Open an ipynb file
Modify it
Save it without running anything
Start jupyter
Open the notebook
You get an error saying a bunch of the fields are invalid

I can't repro this anymore. Maybe it's been fixed.


Work without root user

Hello. Is there any way to run the application not under root user? Unfortunately, sudo nvm does not work by default and is not recommended.

Hello, you can launch it. But I don’t answer at the expense of performance, since commands are used that require sudo/root access. For example, blocking via ufw


Bug in Connectivity for both UWP and WinPhone

Hi
I might be wrong but there's a bug in the connectivity implementation for both Windows platforms:
var avail = NetworkInterface.GetIsNetworkAvailable();
        if (avail)
            this.InternetReachability = ConnectionStatus.NotReachable;
        else { ....

If the network is available the InternetReachability will be always NotReachable.....

This is fixed in v4-beta1.  Give it a try on nuget


Auto-generate a GIT_SSH wrapper from a ssh_key attribute

I added an ssh_key attribute to the scm resource that will use the git-ssh-wrapper gem to auto-generate the necessary temp files for the GIT_SSH wrapper. It would allow you to have the following resource:
git "/srv/foo" do
  repository 'git@github.com:foo/bar.git'
  reference 'master'
  ssh_key node[:deploy_key]
  action :sync
end

This patch is pretty rough, i'm looking for feedback on how i can improve on this to get it merged in the future.

Thank you for supporting Chef! Our process has a couple prerequisites before we can merge your contribution. We need to ensure you've completed a Contributor License Agreement (CLA) and a ticket on our ticket tracker for the release workflow. Please take a moment to review the below wiki page for the appropriate steps:
http://wiki.opscode.com/display/chef/How+to+Contribute
The Opscode Team


internal_ci: rename grpc_xds_k8s to psm-security as part of tech-debt cleanup and name clarity (backport 1.39.x) (#28034)

@srini100 this one needs to be merged by an authorized user.


Clarify that overwrite only overwrites the local filesystem.

What type of PR is this?
/kind documentation
What does this PR do / why we need it:
Clarify the intent of the overwrite functionality.
Have you updated the necessary documentation?

[X] Documentation update is required by this PR.
[X] Documentation has been updated.

Which issue(s) this PR fixes:
Fixes #?
How to test changes / Special notes to the reviewer:

/approve
/lgtm


Differences between lumaku and cornerfarmer implementations

First of all marvelous piece of work done here! Thanks @lumaku , your continued participation in ASR projects as well is invaluable!!
I had a query regarding differences between the implementation and features exposed by this repo and the repo at cornerfarmers repo.
Are there any differences wrt implementation? What about

Performance? GPU computability - I understand the algo is not meant for the GPU and instead better on a strong single core CPU unit, but mentions of using RNN instead confuse me. Perhaps that's only for getting the logits? This part confused me a little, as well as trying to search for such a suitable pretrained RNN+ctc based character outputting STT implementation.
Working with longer audio files
Any other interfaces exposed or features provided

I understand that this repo is based off on the cornerfarmer one, as that is the code for the paper (DOI: 10.1007/978-3-030-60276-5_27), but would like to ask the author @lumaku if there are any insights to be gained here.
Of particular use would be for my use case of force aligning long form audio using ctc-segmentation using ASR-generated transcripts. Any insights regarding this would be appreciated as well, otherwise I can create a new topic if that is more acceptable!
Thanks again @lumaku !

This repository contains a python package that is adapted for and integrated into several toolkits: Espnet 2, Speechbrain and Nemo. You can download one of these toolkits and start aligning.
The cornerfarmer repository archives the code of our paper - it is organized in the form of a recipe (as in, a kaldi recipe). The original recipe-style is still available in the ESPnet 1 toolkit. However, the toolkits mentioned above provide a direct Python command line interface that makes it more user-friendly.
About working on longer audio files: If the text fits to the audio, then alignment should not take longer than a second, even on a few-hours long audio file. If the text is garbage, it might take up to a few seconds until it reports a failed alignment (which is not the case here). This process is parallelizable, and basically limited by the RAM usage.
Usually ASR inference consumes most resources. Therefore, my recommendations about RNN/Transformer are only regarding the inference network to obtain the CTC activations: Today, RNNs are a bit outdated and Transformer-based networks are the standard. Without and additional tricks, Transformers are extremely resource-hungry for longer sequences. You don't need to train an RNN for your long audio files, it is possible to split the audio files into smaller parts. There a point about this in the FAQ. I recommend that.
In comparison to the archived implementation from our paper, there is an additional feature that improves alignment speed and reduces memory consumption: Directly aligning from tokens. However, this is best used with a character-based ASR model, e.g. ["A", "B", "C", ...]; it may reduce accuracy if used with a model with many and longer tokens. Most ASR toolkits provide those character-based models. This also helps for longer audio files.
I think that aligning your own inferred text is an interesting idea. Maybe the per-utterance confidence score is useful. You would still need to find a good way to separate utterances in a meaningful way, as most ASR models don't have punctuation and sentence endings in their token dictionaries. Or, you could just align the words....
If you plan to use the same model for aligning and inference, you could directly store the CTC logits during inference for the alignment afterwards. The CTC segmentation interfaces of Speechbrain and ESPnet 2 may give you inspiration of how to implement this (see the get_lpz() function). Running the alignment in parallel would not use that much more resources.


Keep previous settings by default?

Thanks for the "Fire" module discover, I'll give it a try, much more straightforward than "Click" I used so far.
https://github.com/tloen/alpaca-lora/blob/88e1130cb552916eab36d0b5e1a19df4685c1e99/finetune.py#L45
I would suggest keeping the previous settings as default:
train_on_inputs: bool = False
group_by_length: bool = False
I did not check all params, but these two seem important enough to be enabled only if you really want them, not by default.

That's reasonable. I'll set group_by_length to default false and cutoff_len to default 256 next time I'm at my computer. Train_on_input=true preserves the old behavior.

Just to clarify, because I read several questions around this and I'd like to understand the rational behind it:
Before this commit
https://github.com/tloen/alpaca-lora/commit/b12c3b90f808e7d62709aad104d4fac1fbc880eb
the prompt was masked in the labels. There was no switch, loss/learning was just on the response part of the sequence.
If I understand it right, the full alpaca training also masks out the input in the labels.
That's the version of the tokenisation I still use for now (with the missing EOS appended to the labels).
After this commit, it became non masked by default.
What is the reason for the change? Is there a quality improvement? Was the masking just not required from the start?
Maybe I missed some relation discussions; could you point me to more details?

The prompt wasn't previously masked, actually; my earlier attempts at masking became a no-op because of the DataCollatorForLanguageModeling at the bottom. My mistake here was leaving this non-functional code in the repo for a few days, which misled people as to what it was actually doing.

Hi @tloen ,I would like to confirm that in the original lora finetune, you train on input?

May I ask: when run fine-tuning, the setting should be: train_on_inputs: bool = False , right?

Same question ^^


EKF: Fix bug that prevents use of flow sensors without gyros

The handling of invalid flow data when on ground is performed in controlOpticalFlowFusion() where it is able to handle the case of flow sensors that don't publish gyro data. By handling the on-ground with invalid flow data case in the interface before data is pushed into the buffer, the change introduced by commit a53ad9c removed the ability to handle flow sensors that publish NAN for gyro data. This was not picked up in testing because the SITL model does nor simulate that type of sensor.
Testing
Testing performed was on SITL with 'make posix gazebo_iris_opt_flow' target
Default test log with flow sensor gyro data: https://logs.px4.io/plot_app?log=ca849660-3d78-4a60-833e-84d1ad9dd63e
The simulator_mavlink.cpp file was then modified to set the published flow gyro integral data to NAN
//rotate_3f(flow_rot, flow.gyro_x_rate_integral, flow.gyro_y_rate_integral, flow.gyro_z_rate_integral);
flow.gyro_x_rate_integral = NAN;
flow.gyro_y_rate_integral = NAN;
flow.gyro_z_rate_integral = NAN;

https://logs.px4.io/plot_app?log=0dbf3ee3-cf69-4094-b305-1862f5c145ba

@mhkabir any news on this testing?

@EliaTarasov this works fine, and is a part of #503. Please test that PR.


cannot start collaboration session it does not detect authentication.

Product and Version [VSCode]:
OS Version [Windows]:
Live Share Extension Version:
Target Platform or Language [ Node.js]:
Steps to Reproduce / Scenario:

install vs live share
click start collaboration session
authenticate
vs code never detects authentication.

Looks like a proxy issue. @brianrreed can you take a look at https://github.com/MicrosoftDocs/live-share/issues/1317 and see if the workaround there helps?


Feat: cairo verify tool

Close #189
Following our discussion in #209, here's a first version of a simple CLI tool (named cairo-verify).
Change to mdbook-cairo
The mdbook-cairo is no longer a backend. It's now a mdbook preprocessor that only removes the // TAG lines in code blocks.
!! Install it again !!
cargo install --path mdbook-cairo

cairo-verify
The cairo-verify tool is designed to wrap all cairo and starknet plugins for quickly verifying cairo programs.
Setup
cargo run --bin cairo-verify

Or full install:
cargo install --path cairo-verify

Usage
The tool scans for all *.cairo files in the specified directory and performs the following actions:
For a Starknet contract:

starknet-compile
If it has tests: cairo-test --starknet

Cairo program:

If it has a main function: cairo-run
Else, cairo-compile
If it has tests: cairo-test
cairo-fmt

To specify which tests to run, you can add a comment at the top of your file with the following format:
// TAG: <tag1>
// TAGS: <tag1>, <tag2>

Here is a list of available tags:

does_not_compile: don't run cairo-compile/starknet-compile
does_not_run: don't run cairo-run
ignore_fmt: don't run cairo-fmt
tests_fails: don't run cairo-test/cairo-test --starknet

You can skip and ignore a specific test by adding the corresponding flag:
$ cairo-verify --help

Usage: cairo-verify [OPTIONS]

Options:
  -p, --path <PATH>    The path to explore for *.cairo files [default: ./listings]
  -v, --verbose        Print more information
  -q, --quiet          Only print final results
  -f, --formats-skip   Skip cairo-format checks
  -s, --starknet-skip  Skip starknet-compile checks
  -c, --compile-skip   Skip cairo-compile checks
  -r, --run-skip       Skip cairo-run checks
  -t, --test-skip      Skip cairo-test checks
      --file <FILE>    Specify file to check
  -h, --help           Print help
  -V, --version        Print version

In CI, it's preferable to reduce output, so run cairo-verify with the --quiet flag.
CI Change:
We have to run cairo-verify -q, but it rely both on rust and cairo so we can't use the cairo docker image anymore.

@enitrat @glihm, could you please provide some feedback on this?

Amazing PR @julio4 🙃

@julio4 i'm modifying the cairo files to ensure that everything runs accordingly to how it should, and I make some modification to the rust files, don't forget to pull my changes when I push

feature request: if something is marked with does_not_compile, or does_not_run, then we should still run it and verify that indeed it does not compile / does not run

@glihm should we cargo install or cargo run --bin in our GH action? what's the fastest?

I usually see cargo install with the --locked as @julio4 did. :+1: It's totally fine IMHO.


expose basic prometheus metrics

related: https://github.com/juicedata/juicefs-csi-driver/issues/832
TODOs:

assign prometheus scrape annotations to node service
change listen port to a "stable" one, rather than 6060 but might increase due to port++
define more useful metrics
fix tests at last

Please fix the ci test

close in favor of https://github.com/juicedata/juicefs-csi-driver/pull/852


LF/CR terminated data from serial port is send to broker immediately even if buffer size is specified.

Motivation
If 'size' parameter is set in INI file, fuji-gw serial port read process waits until buffer is filled by the size of data.
But when some irregular length of data, such as error report or command result, etc. comes, buffered data is out-of-sync. Then, never recover.
Solution
Most of the cases, irregular length of data is terminated by 'new-line' character.
In serial port read process, if LF/CR terminated data is received, it is send to broker immediately even if buffer size is specified.

Thank you for this PR. It is very useful. However, This implementation always sends a message when \n or \r exists.  This becomes unexpected behavior sometimes, could you add a enable/disable configuration?
I close this PR at this time. If you update, please PR again.
Thank you!


Pass EXTRA_PKGS var to docker to build rootfs

Fixes #74
Signed-off-by: Harshal Patil<EMAIL_ADDRESS>

Good catch @harche ! ;)
Again, please can you add a "subsystem" tag ("rootfs" would work well here) to your commit as described in https://github.com/kata-containers/community/blob/master/CONTRIBUTING.md#patch-format.
Once done,
lgtm.

@jodh-intel done.

Ta!

lgtm


splunk_hec generator requires acks, should not

If a splunk_hec generator peer does not respond back with an AckID -- as the protocol does not seem to require -- then the lading generator will fail, crashing the emission task but not lading. It should not be the case that lading's send task crashes when an ack ID is missing.

See discussion on https://github.com/vectordotdev/vector/pull/15063

This is a misunderstanding on my part. In that experiment we have vector set to not ack, lading set to ack. This is a bug in the experiment.


ObjectDisposedException during network error

[2016-05-14 09:20:00.7733] [Error] C7 IO error - System.ArgumentException: length of response is too small
Parameter name: response
at NsqSharp.Core.Protocol.UnpackResponse(Byte[] response, FrameType& frameType, Byte[]& body) in d:\Projects_github\NsqSharp\NsqSharp\Core\Protocol.cs:line 104
at NsqSharp.Core.Conn.readLoop() in d:\Projects_github\NsqSharp\NsqSharp\Core\Conn.cs:line 554
[2016-05-14 09:20:09.9268] [Error] C7 IO error - System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'System.Net.Sockets.NetworkStream'.
at System.Net.Sockets.NetworkStream.Write(Byte[] buffer, Int32 offset, Int32 size)
at NsqSharp.Utils.TcpConn.Write(Byte[] b, Int32 offset, Int32 length) in d:\Projects_github\NsqSharp\NsqSharp\Utils\TcpConn.cs:line 127
at NsqSharp.Core.Command.WriteTo(IWriter w, Byte[] buf) in d:\Projects_github\NsqSharp\NsqSharp\Core\Command.cs:line 164
at NsqSharp.Core.Conn.WriteCommand(Command cmd) in d:\Projects_github\NsqSharp\NsqSharp\Core\Conn.cs:line 344
[2016-05-14 09:20:09.9268] [Error] C7
error sending CLS - System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'System.Net.Sockets.NetworkStream'.
at System.Net.Sockets.NetworkStream.Write(Byte[] buffer, Int32 offset, Int32 size)
at NsqSharp.Utils.TcpConn.Write(Byte[] b, Int32 offset, Int32 length) in d:\Projects_github\NsqSharp\NsqSharp\Utils\TcpConn.cs:line 127
at NsqSharp.Core.Command.WriteTo(IWriter w, Byte[] buf) in d:\Projects_github\NsqSharp\NsqSharp\Core\Command.cs:line 164
at NsqSharp.Core.Conn.WriteCommand(Command cmd) in d:\Projects_github\NsqSharp\NsqSharp\Core\Conn.cs:line 351
at NsqSharp.Consumer.StopAsync() in d:\Projects_github\NsqSharp\NsqSharp\Consumer.cs:line 1528

Most likely caused by a call to Write after Close


Row values without quotes don't import correctly.

If the rows of the csv do not have quotes around the values, they will not be separated.
e.g.
col1,col2,col3
a,b,c
will end up with:
col1 = a,b,c
col2 =
col3 =

Please find(2.0.1) the latest version.


pythonPackages.svgwrite: init at 1.1.6

Did you check whether the correct test runner is used?

I'm not sure what to check for, but the Travis CI build output confirms that the tests are being run.

Indeed it does. Thanks!


test: disable tcp_connect6_link_local on android

The test fails with ENETUNREACH on CI, presumably because the Android image doesn't support link-local traffic.

Maybe (hopefully) #4490 invalidates this PR so I'll wait until that one is merged, then rebase this one.


refactor: nextjs-example page.tsx code refactored for better readability

Refactored the Card Component Rendering in page.tsx
Issue: The Card component was instantiated multiple times to render multiple content.
Solution: Implemented a more favorable approach by creating a 'cards' array of objects and utilizing the map function to render each Card component. This not only reduces code redundancy but also improves the maintainability and readability.

I tried earlier but had some issues and fixed that, but now there's one issue that persists and am not sure if this will work. Am sorry, didn't mean to do it twice. I've mentioned the issue in #93

I don't think the indirection is an improvement. Nothing wrong with the existing code. I'll leave this open for a bit in case you want to submit just the typo fixes though

Uhh okay, no probs. i fixed the typo on my new code. do you want me to revert it back to original or this works?

Yes revert the changes please


Markdown Reference Page

Resolves #36.
What is Included
I have included the following topics:

What is Markdown?
Getting Started
Where and how we use Markdown on Sailbot

I also linked to the necessary resources for tutorials on Markdown and references for the different flavors of Markdown that we use.
Other Comments
Markdown Linting and Checks
I chose not to include a section on the .json files in the repository related to Markdown. I feel like these topics are more appropriate for either the section on MkDocs or VS Code. Let me know what your thoughts are.
VS Code Extensions
I briefly considered talking about some helpful VS Code extensions for Markdown, but I was not sure if it was particularly relevant. We also don't use extensions for Markdown in the Sailbot Workspace if I recall correctly. What do you think? I was thinking of the following extensions:

Markdown All in One
Markdown Preview GitHub Styling

We already link to the documentation for Material for MkDocs. It is probably fair to say that this PR also closes #27.

@patrick-5546 I added the following additional sections to the Markdown page:

Rendering Markdown Locally
Markdown Linting


🐛 Is there an API to manually switch the displayMode of the Navigation Pane？

Describe the bug
Is there an API to manually switch the displayMode of the Navigation Pane？Because I set the menuButton property.

You can simply define PaneDisplayMode in a variable and change it
return NavigationView(
  pane: NavigationPane(
    header: headerWidget,
    displayMode: PaneDisplayMode.open, // <-------------
    size: paneSize,
    selected: paneIndex,
    onChanged: paneChanged,
    items: panesItem,
  ),
  content: NavigationBody(
    index: paneIndex,
    children: panes,
  ),
);


Need Hyperlink option in Marks/Toolbar

Is your feature request related to a problem? Please describe.
Need Hyperlink optior in the Toolbar
Describe the solution you'd like
Can able to select text and add hyperlink from Toolbar
Describe alternatives you've considered
Right now selecting the text and pasting (ctrl + v) the url does the trick. It would be easy for user to select if we have the option in the Toolbar itself

Added @yoopta/link-tool package  into default toolbar


refactor: remove redundant key creation

As checked with drei library the key parameter is already generated within the shaderMaterial function, so do we really need to create it again?
https://github.com/pmndrs/drei/blob/17eb192955f2fa93ce86aefbdf6c40a7965a6f8f/src/core/shaderMaterial.tsx#L56
  material.key = THREE.MathUtils.generateUUID()
  return material

Good catch! Thanks


Pokemon card added

You only need to add the pokemon in either index.html or pokemon.js. Including them in both will mean it will appear twice


treeview: addNode

Dear Mr, Atatansov, I´m using the configuration of your addNode Test in a actual project.
There is a bug. addNode add ever 2 new nodes with the same internal data (e.g. id, text, parentId)
Please fix this problen as soon as possible!
Thanks for all!

It happen, wenn you insert a record via ajax call which will give back a new ID before you call the content of the ADD function. The sample alone without ajax is working.

Please publish an example with a ajax post (insert new record) in the database!?

My configuration is ...
var tree = $('#tree').tree({
			primaryKey: 'id',
			uiLibrary: 'bootstrap',
			selectionType: 'single',
			dragAndDrop: true,
			dataSource: 'http://myserver/app/public/category/lazy',
			iconsLibrary: 'fontawesome',
			lazyLoading: true,
			parentId: 'pid',
			dataBound: function (e) {
				// do somewhat
			}

		});

Everything seems to work fine. You can see my example at https://gijgo.com/Temp/64a6aed3-cd98-44d3-b18c-22d55952f5fc.html

Closing. Please reopen if you can provide better replication steps.


RFC: Crate changelogs

Rendered
This RFC proposes addition of changelog support to cargo and crates.io.
The main proposal is to add changelog field to [package] section of Cargo.toml which can point either to changelog file supplied with the crate, or to external resources. (e.g. GitHub releases or custom websites)
In the first case, changelog file should follow the minimal set of rules. Also this RFC specifies additional check for cargo publish, so crate authors will not forget to update changelog before publishing the new version.
Changelog rendering on the crates.io can be done through additional link on top bar:

This proposal initially also included a multi-file approach to handling changelogs. (most of the initial comments discuss this part) While I believe it would be good for ecosystem to define stricter conventions around changelogs with enhanced machine readability, but based on response, I've moved this part to a separate (closed) RFC.

I'm not professional enough to write changelogs. Will cargo and/or crates.io be able to automatically generate an API diff from one version to the next and spit out that as the change log?

@Lokathor
Certainly not as part of this RFC. But this functionality can be introduced by subsequent RFCs in the form of additional cargo changelog subcommands.

Glad my post could help get this discussion going! :)
I don't think that having a changelog be a commit diff is a good idea. There's lots of irrelevant messages from commits like with merge commits.
@lokathor If you don't believe you're professional enough to write a changelog, open an issue to ask for help with it. The issue will bring attention to the lack of changelog to people who see the repo.

How should a changelog address a project that has been deprecated in favor of another project?
And if not in favor of another, it should address that the author may not have enough time to support it. Or maybe the project had unsafe effects (accidental malware?) that people want to study rather than used in legitimate software?

@nvzqz Wouldn't that sort of stuff just go in the README? Changelogs (as promoted by keepachangelog) don't usurp readmes.

@boustrophedon the changelog described has an Unreleased section. It would just be a message stating that no more releases should be expected.

I'm uncomfortable with Rust tooling taking an opinionated view towards changelogs, especially when that opinion marginalizes a project like clog that's been part of the Rust ecosystem for a long time now. I can definitely see why people would prefer the keepachangelog.com approach, but I don't think Cargo should make that decision for project authors. This would be especially galling to any project that has put the time and effort into maintaining a conventional commit history.
This is an area where there are multiple specifications and whatever Rust tooling gets built should allow project authors to choose whichever approach they prefer.
For anyone unfamiliar, here is the spec for the conventional commit method of handling changelogs and here are the Angular commit guidelines on which its based.

I think changelog support would be awesome, but I don't get the need for the custom split-file format. As stated in the RFC, this deviates from the norm. I don't know if anyone would think to look for a changelog folder. I certainly wouldn't want to have one in my repo because I prefer the single file changelog.
I like everything about adding the changelog link to crates.io and I'm in favor of having the key for that in Cargo.toml, but I'm not sold on the split changelog thing. I don't see why the changelog needs be generated at all.
I know maintaining a changelog by updating it's links and adding new sections can be a pain, so maybe an external tool that makes that awesome would be a good idea. Just working on changelogs doesn't seem like something that should be part of cargo.
Thanks for making the RFC! I'm glad someone is talking about this. :)

I like the intent to add a changelog to crates.io and to Cargo.toml. I even agree with requiring certain format (it makes sense, if it needs to be rendered somewhere).
However, I very much dislike the split into files. I keep changelogs with my crates (at least once the API settles a bit), but I prefer having all the changes in one file. It's easier to search for something. And when I download a repository (or open it at github), having to either generate the changelog locally or searching multiple files feels like a lot of added work for no real gain (and keeping a generated file in git is also wrong). Also, having to be online for generating the changelog feels somewhat inconsistent with the fact that almost everything cargo does works offline (except when adding and downloading dependencies).
What work is actually saved by that split? Adding the dates? Moving the lines from unreleased section to the current version? If the changelog has a standardized format (MD with the given sections), any tooling should be able to handle it in a single file as well.

:+1: on prescribing a general format as loose as possible

Headers with version/date
Bullet lists with updates
Bullet lists can be optionally categorized

I'd like to define the layout enough that we could do this on crates.io but no more.
I strongly dislike the tool that generates a changelog from a folder structure being officially part of Rust. I'd rather see that tool compete with clog as separate crates.

I'm not really a fan of adding yet another folder. One file should be enough IMO. If I look at the changelog I keep for my lewton crate, I see some releases with only two bullet points. Making a file for only one or two bullet points is a waste IMO.
Generally I think we should be as liberal as possible with the changelog format, and not dictate one.

I agree with @est31. From the author's perspective, a file per release is neat and simple. From the user's perspective, when I look at a change log, I am probably reading it like a timeline: I'm going to read everything from some point and up until the current state, so I'll read through multiple releases, and a single file is then much easier to read.
Of course for big enough projects, splitting the change log per release again becomes reasonable.

+1 for keeping changelogs in a single file. Also I think a changelog needs to be written by hand to include information curated and prioritized.
In recent version of handlebars, I put unreleased changes in an Unreleased section, when the change is merged into master. And I configured cargo-release to replace Unreleased with new version number. Then the changelog is ready.
I knew a lot effort has been put into changelog auto generation. But this is my best workflow by far.
Sent from my Google Nexus 9 using FastHub

+1 for keeping changelogs in a single file. Also I think a changelog needs to be written by hand to include information curated and prioritized.

+1

I have mixed feelings about this. What about just inserting a changelog link on crates.io that shows the rendered CHANGELOG{.md} if present?

It looks like the consensus so far is that a single file is preferred over multiple files. What the format of that file should be is less clear.

It could be strictly specified, which can be useful for machine readability, but which would force a format onto projects that might not be suitable for them.
Projects could be free to choose the format which makes sense for them, just like they can with a readme.

I would prefer the second option. What a good changelog looks like depends a lot on the size, release schedule, and purpose of the project.

I'd love to have the changelog rendered, but I'd rather it just be "we will render any of these paths in crates.io" and how it gets there is uncared about (additional tooling is fine). I really don't like the type:  prefix specs because I feel it wastes precious subject space (I prefer area:  prefixes because they are easier to sort/skim on).
The way I usually do release notes is that each PR which needs one drops a new file in a specified directory and at release time, they get collated into a single file and deleted. This stops conflicts from happening, supports cherry-picking into backport branches easily with no change in process, and allows for the maintainer to collate and group release notes as necessary or wanted.

Thank you for your responses!
While it was not my intention I think emphasis on a new multi-file approach was too strong. I've moved it into a separate RFC and updated this one to a minimal version.
One thing which I think is very important is to have at least minimal degree of machine readability and safety check in cargo publish based on that. So cargo will be able to help library authors to remember to update their changelogs.

The changelog field in the Cargo manifest should just be a URL like the documentation field. It doesn't make sense to impose any particular mechanism for change logging. As proposed in the RFC, this would not be useful to me because I use GitHub's releases page instead of a file in the repository. I've also seen some projects use detailed commit messages on Git tags instead of a file. I don't think users really care what format the change log is in, just that there is one and that they can find it.

@jimmycuadra
I don't agree with your position, I think it's quite important to have a coherent way of showing, instead of using links to a dozen of external resources. Also projects which would like to use a different approach always can specify it in the readme.
But either way I will mention your proposal as an alternative solution.

My comment on your other changelog RFC is also valid for this one :) https://github.com/rust-lang/rfcs/pull/2131#issuecomment-325199451

I don't think external links are a good idea. Changelogs in the repository are useful both for their offline access and for the interface options they allow. Crates.io could gain nicer rendering with a standard format in the future with files, but that requires using GitHub/GitLab/wherever's API and constantly tracking changes for each platform we support for external links.

SGTM! For another point of reference, the VSCode marketplace takes a similar approach, but always looks for CHANGELOG.md, i.e., you can't specify a filename. It also doesn't do any fancy processing of the file, it just renders the markdown. That seems fine to me, having formatting requirements seems to make things more complex without bringing a lot of benefit to users.

I would think we should do the same thing we do for readmes: if there's a file called CHANGELOG.md, render it (but in this case, on a secondary page calle changelog). That makes this an entirely crates.io feature and any existing crates with a CHANGELOG.md will automatically start displaying a changelog on crates.io.
I don't understand the portions of this that are opinionated about formatting.

Actually, READMEs do require a readme key. Let's just do that, then; a key for your changelog file and we'll render it using the same rules for READMEs.

@withoutboats
I believe changelog should be structured and it's correctness should be checked by cargo/crates.io. In future we could want to do fancier things compared to a simple rendering, e.g. filtering out older or pre-release versions, showing only minor/major version changelogs. AFAIK proposed rules are fully compatible with most common formats used in the wild. (contr-examples are welcome!)

I have a use-case for machine-readable changelogs — display a list of breaking changes when a Cargo dependency is upgraded.

I have a use-case for machine-readable changelogs — display a list of breaking changes when a Cargo dependency is upgraded.

This sounds pretty cool, but I wonder, is there a situation where a short message would be used where the entire changelog wouldn't suffice? I get that it's a little more convenient maybe to see just a single version or something, but if we render the entire changelog, we can see all the changes in all the versions as we go. No need for any special files or commands.
In the comment you linked to, you described a use case where someone jumps from 1.0 to a 2.0 release and with each release from then on they see some sort of small message summarizing the changes. That sounds like it would work to display the contents of the changelog for that specific version. However, as it's been pointed out, it would also work and be easier and be more customizable to display the whole thing. The effort being saved to scroll a bit to find what you're looking for or to have to click on a link or open a file doesn't seem to providing very much benefit.
Maybe I just don't see it yet?

Importance of changelog entries varies a lot, so I think filtering is critical.
For patch releases the changelog is going to be only non-actionable trivialities. This doesn't have to be displayed unless someone asks for it (if they're just fans of the project and curious how it's getting along).
But once in a while the changelog is going to contain list of breaking changes for a major version, and user will need to pay attention. Do they use the broken API? Do they need to migrate their code/config/data files?
I think displaying actionable information for major breaking changes will be helpful. Users will see exactly what they need to see, at the right time, right when they update the project.
Compare:
cargo update

Upgraded db to 2.0: switched to a new config file format

vs
cargo update

Upgraded db to 2.0:

improved speed of foobar routine
switched to a new config file format
added Hungarian translation of user manual
fixed compatibility with GNU/Hurd

In the first case you see something happened, and you can decided whether to do something about it. In the second case more text turns it into "yada, yada, yada, tl;dr".

@sunjay @pornel
Even more compelling is we could have cargo update --interactive which could let us see those changes easily before we say "yes, update please".

BTW, Debian is quite serious about their changelogs, and they have years of practice and tooling around them. Some interesting bits:

Urgency: https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Urgency
Updates, regardless of semver, can be marked as as critical. There are cases when an urgent security fix is also technically a breaking change (e.g. disables vulnerable feature). In such situation my Debian servers automatically e-mail me the changelog entry! (but never spam me with low urgency changelogs).

Changelogs can grow big: https://www.debian.org/doc/debian-policy/ch-docs.html#s-changelogs

these files should be installed compressed using gzip -9, as they will become large with time even if they start out small.

Also look at Node's changelog: https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V8.md#8.3.0

@pornel
I would be happy to add additional requirements and structure to changelog, but as you can see even the minimal set of rules have been met with some push-back.
Regarding your use case, I think this RFC enables it, as cargo will be able to filter out only major version changelogs (or minor for 0.*.*). As for default rendering on crates.io, should we render everything or only important parts, this RFC does not specify it, so I guess we'll start with plain rendering without any filtering, which we will be able to change in future.
One idea to enhance changelogs would be to add changelog-format with default simple value which will correspond to format described in this RFC, possible examples would be:

simple:gzip for compressed simple format
keepchangelog for format specified by the website (fixed headline style and grouped changes)

So it will allow to use stricter formats, but it will introduce additional complexity to cargo and I don't believe it's a good solution.
Other solution would be to define hooks to installable cargo changelog tools. (with default tool which will parse CHANGELOG.md files) But I think it will require to split changelog from the rest of crate on crates.io, as tool can work without explicit changelog file. Also it rises many question about how crates.io will work with different formats produced by such tools. Obvious solution would be to define single (machine readable) format to which those tools will have to convert changelogs, but I am not sure if such approach will be welcomed by community.

I reckon introducing a changelog key – be it a file, a path, or an url – to the Cargo manifest format is all that should be done, at least for now. Perhaps Cargo could lint for missing changelog keys, especially if the crate version is above 1.0. That I would fully support.
Beyond that, it feels premature to mandate or speculate on rules – let alone machine-readable formats – at a time where changelogs are yet to become common practice amongst Rust projects; current conventions are too few and too loose to make them into obligations for library developers.

@tapeinosyne
Could you please provide examples of changelog formats used in the wild by crates and which do not fall under rules described in the RFC? (well, except of github releases, which are kind of changelog)
Problem with not specifying any basic requirements for changelog format is that when we'll want to enhance tooling around changelogs, we'll have to break backward compatibility (be it in cargo or/and crates.io), which is always not a fun thing.

at a time where changelogs are yet to become common practice amongst Rust projects

As I see it, this argument works better in a backward direction. If it's not a common practice yet then we can establish a good standard, which people will be able to follow, because they'll start to keep changelog after introduction of this feature.

We don't have to break backwards compatibility to provide more enhance dfeatures. We just only provide those features if you conform to whatever format we require to enable those features. e.g. if your section headers are version numbers, we will hide the yanked ones; if they're not, we don't.

@withoutboats
But it means we'll have a significant incoherence in the ecosystem, some will support this feature, others will not. It will make working with changelogs harder, as tools will have to know about different features and their combinations. So in result I think it will make overall experience of using changelogs significantly worse.

I don't think the changes would be so significant. I don't expect most people to make wildly different changelogs. Most changelogs I've seen seem to be fairly regular. Many people adopt the keepachangelog format. I imagine that it would work something like this:

We add a changelog key, people start to see and like having changelogs on crate pages (just like with READMEs)
People copy the changelog formats they like and use them on their projects
After a few months or years (whenever the need arises for more features), we look at the most popular formats and start to add lints

At this point we have a lot of information so we can decide on a format that fits most people and makes upgrading not terribly hard

People upgrade whenever they want to the new format

I agree with @tapeinosyne that having a strict format right now seems very premature. It makes a lot of sense to see what people start to use and then base the format off of that. Basic support is really important, but I still don't see the need for the standard format.

@sunjay
Why wait anything if we can go and see crates which keep changelog right now? From what I've seen they fall under minimal rules (don't know why you call them "strict", I wouldn't even call it a "standard format") described in this RFC. At least no one provided contr-examples yet. And people who don't yet keep changelogs will have no problems to follow them.
I believe it's better to make it more or less right with the first try, then later try to deal with consequences of overly relaxed rules.

At least no one provided contr-examples yet.

I haven't been following this thread closely, but does this follow the format? https://github.com/BurntSushi/ripgrep/blob/master/CHANGELOG.md

@BurntSushi
Yes, it does. It's just that instead of #  you use underline style to define headlines. (probably should mention in the RFC that it's fine to use both methods)

I'd like to see at least the following minimally specified:

Consistent level markdown headings must start with a semver. To parse, check the first heading of each level for valid leading semver. When found, assume that level is our "version level".

# Anything goes here

Anything goes here.

## 1.2.3

Anything goes here.

## 0.2.3

Anything goes here.

## 0.0.3

Anything goes here.

or
# 1.2.3

Anything goes here.

# 0.2.3

Anything goes here.

# 0.0.3

Anything goes here.

or
### 1.2.3

Anything goes here.

#### Bug Fixes

More anything goes here.

### 0.2.3

Anything goes here.

### 0.0.3

Anything goes here.

I don't think we should try and specify the format inside each chunk. I just want crates.io to be able to extract a version chunk and show it.

@mehcode
I've tried to define exactly that you've demonstrated in your examples. Probably wording was not clear enough. Later I will update RFC with your examples.

But it means we'll have a significant incoherence in the ecosystem, some will support this feature, others will not. It will make working with changelogs harder, as tools will have to know about different features and their combinations.

We've already established that breaking changes are a no go, which means the guarantees in this RFC are all the guarantees we could enforce. The guarantees in this RFC are that headers begin with a version number. Can you explain how having crates on crates.io which don't follow this format will make it hard for tools to process change logs?
At minimum they can just report an error on those crates - unfortunate but not a big loss. At maximum they can accept slightly more inputs. For example, a more liberal tool might accept headers that containing a semver version in their header, possibly not in the initial position, to handle people who might write "Release 1.2.0" or " (2.0.0)" in their headers.
Moreover, this RFC defines the changelong syntax in terms of markdown. While today crates.io only renders markdown, there are feature requests to render other formats types, such as asciidoc. I feel quite strongly that, at least as far as crates.io is concerned, any features should be based on the header tags in the rendered HTML output, not in the syntax of the source text.

I agree with the goals of this RFC, in that making changelogs more visible will encourage more people to keep them!
I'd like to suggest, however, that the changelog key in Cargo.toml could go to a URL or to a file in the .crate package. In both cases, if this key was present, we would show a link on a crate's page to changelog. If the changelog key specifies a file, crates.io would render that using the same mechanisms/support as we recently added for readmes, and the link would go to that file. If the key was a URL, it would be a normal external link.
This would support the case that @jimmycuadra raised of using Github's releases page as the changelog, and would also support people who have a whole website for their crate of which changelogs is one part.
I would be in favor of this proposal if that change was made, but currently I'm skeptical of the (lack of) flexibility the current proposal has.

Could you please provide examples of changelog formats used in the wild by crates and which do not fall under rules described in the RFC?

Excepting the prohibition of Unreleased or similar, I expect that most projects would fall under the proposed rules. However, there aren't very many in the first place, and "most" of "not many" is not enough, in my eyes, to warrant standardization as a leading step.  Standards are expensive demands, and direct experience is valuable. We can draw ideas from other communities, but we need more insight into our own before doing anything so bold as demanding.

As I see it, this argument works better in a backward direction. If it's not a common practice yet then we can establish a good standard, which people will be able to follow, because they'll start to keep changelog after introduction of this feature.

I agree that newly recommended practices should come with guidelines, but not a standard; not for something like changelogs, where needs and wants can vary considerably across projects, as others already remarked.
I also have a scruple: changelogs, like readmes, are traditionally authored in plaintext. From plaintext I expect freedom of form. For a tool to mandate plaintext but demand adherence to external conventions, however reasonable they may be, would be a small treachery: the failure to meet long-established expectations. (Markdown is valid plaintext, at least for the purpose of this comment.) Perhaps the tool could offer conventions which guarantee additional capabilities – much like GitHub may render commit hashes as links in release notes without demanding anything much of maintainers. Again, however, I am not persuaded we should lead with that.

I've updated RFC and added ability link to changelogs published on external resources. Hope this will address most of the concerns regarding perceived strictness of the rules, as it will provide additional flexibility if desired. But I believe that rules for explicitly provided changelog files and basic cargo publish support should be left as described.

I think the current set of rules makes some kind of sense. I mean, changelog is technically free form and every author can do whatever they like, but:

It can hardly be called a changelog if it is not separated by versions.
The rules need to be followed only if you want your changelog to be rendered on crates.io. If you want to link to it (then you provide an url), have it as a .bmp image in your repository (then you don't provide the changelog key), etc, you're free to do that, only crates.io won't provide the service of rendering and hosting it. And if you ask it to render it for you, it is sane to provide a format it understands.
It is always possible to relax the rules in the future.

There's only the question of the unreleased section. On one hand, it makes sense, because at the time you publish the crate, nothing is unreleased, so that's a lint you forgot to move the entries to specific version. On the other hand it might make sense to keep it there in the meantime, not delete and recreate it every time a release is made. There's the possibility of allowing only empty unreleased section, but that feels a bit adhoc.
Also, I was wondering, could cargo new crate an empty changelog, as a hint that it's a good idea to have one?

On the other hand it might make sense to keep it there in the meantime, not delete and recreate it every time a release is made.

Good point, I will add it to unresolved questions. Personally I do not like that much idea to keep it, as I think initially changelog will be rendered in the same way as readme, so it will be strange to see "unreleased" section in it. Or we'll need to add filtering which will feel even more adhoc.

Also, I was wondering, could cargo new crate an empty changelog, as a hint that it's a good idea to have one?

I think it сould be done as a separate RFC. Because for example currently cargo new does not create empty readme file, while arguably good readme is more important than changelog, especially for potential crate users.

Some existing crates have a changelog in a different format (restructuredtext) so anything that allows such things are a plus to me. It's not required that it can render it, but it requires that non-markdown isn't forced through a markdown renderer.

@bluss
As I wrote in the RFC it's definitely possible to extent number of supported markup languages. But to simplify the process I think it should be done through issues for cargo and crates.io after implementation of this RFC using MarkDown. If we'll support validation it will be logical to synchronously add rendering support to crates.io as well.

As the author of the first linked blogpost I very much approve of this RFC in general :) I have a few remarks though.
In my opinion some things in this RFC are too strict:

As a consequence of the last requirement changelog must not contain "Unreleased" section

I think that's overly strict and that Cargo should not add such a requirement. It will only result in workarounds, like not adding a heading for the unreleased changes.

All crate versions listed in the changelog must have been published earlier on crates.io, except the first entry

Why is that? It only makes it harder for projects that have had a few releases before their first crates.io release to publish. I see no advantage in adding this restriction.
In general, I'd either go for a specification that makes the format machine readable (to make it easier for automated tooling), or keep the format unspecified (except for markdown, so it can be rendered). I tend to favor the second approach. It can also be a gradual approach, where advanced rendering is done if the format corresponds to certain rules. As others in this thread have written, we could wait until some conventions form and until some tooling exists. If - for example - cargo would start to show changes on package updates, people would probably automatically start to format their changelogs in a way that they're supported by the tooling.
Oh, and I like the fact that you can link an external changelog, as an escape hatch for people that don't want to conform to the rules required for an explicit changelog file.
Regarding one of the unresolved questions:

Should we check correctness and/or availability of URL in the changelog field?

I would definitely do a check and warn the user if the URL isn't reachable (e.g. if a status code different than 2xx or 3xx is returned). But I'd provide a way to publish even if that URL is (temporarily?) unavailable.
(PS: I found two typos: additionall -> additional and externall -> external)

I feel we should open another RFC for the sole introduction of the changelog key. That much is uncontroversional, indisputably useful, and there is a strong precedent in readme, whereas detailed changelog formats require far more discussion. If we can agree that any guidelines can be established incrementally as conventions emerge, instead of enforcing a standard from the start, there would be no risk of breaking changes; even then, stabilization could still be delayed.

@dbrgn

I think that's overly strict and that Cargo should not add such a requirement. It will only result in workarounds, like not adding a heading for the unreleased changes.

I don't think it makes much sense to have "unreleased" section in the changelog for published crate, especially if changelogs will be initially rendered as readme without any post-processing.

Why is that? It only makes it harder for projects that have had a few releases before their first crates.io release to publish. I see no advantage in adding this restriction.

Hm, you are right, I haven't considered cases when crate can be initially developed without getting published on crates.io. I've removed this requirement.
@tapeinosyne
This "detailed changelog format" currently essentially boils down to "headline must start with the version", plus a safeguard to help crate authors remember to update their changelogs before publishing new crate version, which can be disabled if needed. As I see it, what you propose is to have the second readme, which seriously hinders any attempts to develop tooling around changelogs. And no, I don't think such approach will result in emergence of conventions of any sort.
Also it's always useful to keep in mind that: "nothing is more permanent than the temporary".

I don't think it makes much sense to have "unreleased" section in the changelog for published crate, especially if changelogs will be initially rendered as readme without any post-processing.

Hm, that's a good point. Some workflows will need to change, as some people add the unreleased section at the same time they release the previous version. But that change can just as well be done after the release commit.

We discussed this RFC in the Cargo team meeting, and we feel like we probably don't want to move forward with this at this time. There are some points, such as the proposal for a single format that could be machine-readable that we think may be a little too strict. If the proposal then reduces to just a link that will be displayed, then it seems to not bring much value over placing a link within a README.
We acknowledge that there is a desire to encourage crate authors to provide a changelog, and to make it easier to access that information. We thank everyone for their work and discussion. There may be some solution to improve communication of release notes, but it's not clear what that would look like.
@rfcbot fcp close

@rfcbot reviewed

@rfcbot reviewed

@rfcbot reviewed

@rfcbot reviewed
On Sun, Sep 22, 2019, 1:56 PM Sven Marnach<EMAIL_ADDRESS>wrote:

@rfcbot https://github.com/rfcbot reviewed
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rfcs/pull/2129?email_source=notifications&email_token=AALVMK367NYFUMMJNQ4GXLTQK7EV3A5CNFSM4DYOUGE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7JN3NI#issuecomment-533913013,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AALVMK6EUFCPYS3L72GLYVDQK7EV3ANCNFSM4DYOUGEQ
.

@rfcbot reviewed
While I do agree that crates with more than one release should probably have a changelog, I don't think enforcing them like that is something we should do. If we built some sort of rating system into crates.io that judges the quality of a crate we could consider it as part of the metric though.

@rfcbot reviewed

@rfcbot reviewed

Hmm, this is disappointing. The fact that so many crates don't provide any changelog is my number one frustration with the Rust ecosystem. As someone who only sporadically writes Rust, it tends to be that I come back to the language every few months, bump a load of dependencies, then spend ages trying to work out exactly what broke all of my code. I just need a migration guide!
I haven't read all of the above (it's a long discussion!), but would it be fair to say that there was significant support here for the idea that Cargo should encourage crate authors to write human-readable changelogs, but that that got lost amid a lot of bikeshedding about requiring a more precise format? If so, is anyone willing to submit a minimal version of the proposal?

If so, is anyone willing to submit a minimal version of the proposal?

IMO, I think "use markdown", "use one of these blessed filenames (CHANGELOG, CHANGELOG.md, etc.)",  and "use the version number as a top-level heading (maybe with a v prefix)" is about as structured as anyone is going to agree on.


DPP 0.20 Updates

Issue being fixed or feature implemented

What was done?

How Has This Been Tested?

Breaking Changes

Checklist:

[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have added or updated relevant unit/integration/functional/e2e tests
[ ] I have made corresponding changes to the documentation

For repository code-owners and collaborators only

[ ] I have assigned this pull request to a milestone

branch name is wrong, should be dpp-0.22


Datastore help

Is this how you intended it to function? See screenshot:

Let me know if it's not...
Freddie

I think your problem was the way you were storing the data as an array. Also I've edited your query select to use document.getElementById(example).value.

OK @FreddieN  thanks alot this is how i wanted it to be

Great!
On Thu, 6 Dec 2018 at 22:12, Joeloedinho<EMAIL_ADDRESS>wrote:

OK @FreddieN https://github.com/FreddieN thanks alot this is how i
wanted it to be
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Joeloedinho/sugarizer/pull/1#issuecomment-445048810,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AH1d596HimoqzZ5-AYI8tVG8SVQoXWpHks5u2ZZRgaJpZM4ZHZbF
.

--
Sent from Gmail Mobile. Sorry for any errors.

you have really helped me today
On Thu, Dec 6, 2018 at 11:33 PM FreddieN<EMAIL_ADDRESS>wrote:

Great!
On Thu, 6 Dec 2018 at 22:12, Joeloedinho<EMAIL_ADDRESS>wrote:

OK @FreddieN https://github.com/FreddieN thanks alot this is how i
wanted it to be
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/Joeloedinho/sugarizer/pull/1#issuecomment-445048810
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AH1d596HimoqzZ5-AYI8tVG8SVQoXWpHks5u2ZZRgaJpZM4ZHZbF
.

--
Sent from Gmail Mobile. Sorry for any errors.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/Joeloedinho/sugarizer/pull/1#issuecomment-445054442,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Af8MzwXSd79iWxnxWfUUfgS6gk9CEiSgks5u2ZsngaJpZM4ZHZbF
.


Any sleep or wait in tests should be preceeded by log statement

https://github.com/fedimint/fedimint/pull/1781#discussion_r1119029229

Hi I'd like to work on this issue.

Assigned you @PaarthAgarwal. Feel free to make a small draft PR before you're finished and we can give you some feedback.

@justinmoon I read through the comment and understood the issue but what do you mean by "log statement"? Is there something specific you want to print?

To enforce this, can we forbid sleep in test and instead define a sleep_in_test(comment: impl AsRef<str>) utility method that will do the right thing (tm)?

To enforce this, can we forbid sleep in test (using semgrep) and instead define a sleep_in_test(comment: impl AsRef<str>) utility method that also logs the sleep?

This is better option as It will always bind developers to have log statement before any sleep line as compared to one manually writting them.

I'm going to work on this. All of the testing locations appear to be:
  - fedimint-testing/
  - fedimint-wasm-testing/
  - fedimint-wasm-tests/
  - fedimint-load-test-tool/
  - modules/fedimint-dummy-tests/
  - modules/fedimint-wallet-tests/
  - modules/fedimint-ln-tests/
  - modules/fedimint-mint-tests/
  - gateway/ln-gateway/tests/
  - fedimint-client/src/backup/tests.rs
  - devimint/src/tests.rs

The following is the addition I'm making to .config/semgrep.yaml:
- id: avoid-direct-sleep-in-tests
  patterns:
    - pattern: sleep($X)
    - pattern-not-inside: sleep_in_test($X, $Y)
  paths:
    include:
      - fedimint-testing/
      - fedimint-wasm-testing/
      - fedimint-wasm-tests/
      - fedimint-load-test-tool/
      - modules/fedimint-dummy-tests/
      - modules/fedimint-wallet-tests/
      - modules/fedimint-ln-tests/
      - modules/fedimint-mint-tests/
      - gateway/ln-gateway/tests/
      - fedimint-client/src/backup/tests.rs
      - devimint/src/tests.rs
  message: "Direct use of sleep in tests is discouraged. Use sleep_in_test instead."
  languages: [rust]
  severity: WARNING

Since they span a few different crates, I would like to create a new library crate called testing_utils and place the sleep_in_test function inside. Then, each crate that requires the sleep_in_test function would add the crate as a dependency in it's cargo.toml. Right now, the only one that would need it is fedimint-testing

Why do you need a new crate? Can this function just go in fedimint-testing?

Ah, I see that the following crates do depend on fedimint-testing:

modules/fedimint-dummy-tests
modules/fedimint-wallet-tests
modules/fedimint-ln-tests
modules/fedimint-mint-tests
gateway/ln-gateway
devimint

But these crates do not:

fedimint-wasm-tests
fedimint-load-test-tool
fedimint-client

fedimint-wasm-tests contains tests, but it doesn't use the fedimint-testing crate.
fedimint-load-test-tool looks like it might just be tooling for tests, not tests itself so it might not need to be included in the semgrep.
There are tests in crate fedimint-client in fedimint-client/src/backup/tests.rs, but fedimint-client doesn't use the crate fedimint-testing.
Since so many of the crates already depend on fedimint-testing, I see now that it could make sense to put the sleep_in_test function in that crate. But what do we do about the crates that contain tests that don't add fedimint-testing as a dependency, such as fedimint-wasm-tests and fedimint-client?

Maybe we can just put sleep_in_test into fedimint_core::task? fedimint_testing depends on fedimint_client, so we cannot depend on it there or it would be a circular dependency.


Stepper: improves hotkeys; fixes #1751

Description

Type of change

[x] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update
[ ] Code quality improvements

How to test

Checklist

[x] I have tested this code
[ ] I have updated the documentation

Added hotkeys:
a: Move to the first step
e: Move to the last step
f: Move to the next step
b: Move to the previous step

Pull Request Test Coverage Report for Build 957602547

0 of 5 (0.0%)  changed or added relevant lines in 1 file are covered.
237 unchanged lines in 6 files lost coverage.
Overall coverage decreased (-0.001%) to 30.086%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/commons/sideContent/SideContentSubstVisualizer.tsx
0
5
0.0%

Files with Coverage Reduction
New Missed Lines
%

src/commons/sideContent/SideContentSubstVisualizer.tsx
1
1.62%

src/commons/utils/JsSlangHelper.ts
3
62.0%

src/pages/academy/sourcereel/Sourcereel.tsx
35
5.33%

src/pages/sourcecast/Sourcecast.tsx
35
6.1%

src/commons/sagas/WorkspaceSaga.ts
46
74.52%

src/pages/playground/Playground.tsx
117
2.06%

Totals

Change from base Build 957608250:
-0.001%

Covered Lines:
3216

Relevant Lines:
9853

💛  - Coveralls


Add Resource Request: DataCite

What is the resource called?:
DataCite
What is the link to the resource?:
https://datacite.org/
Please provide a short description of the resource (1-3 sentences):
ensure that research outputs andDataCite ensures that resources are openly available and connected
Which step of the research cycle does the resource belong to?:
Dissemination
If possible, please provide the exact path where you want this resource to go?:
Closed (i.e. you have to pay or subscribe to use the resource)

Added


defender-admin-client next release

Hello there 👋,
many thanks for work you're doing here.
I was wondering when the new version of the defender-admin-client package could be available to use? I was looking forward to start using this newly added feature  to the admin apis 🚀
Thanks in advance and have a nice day :)

Hello @olich97 🙌
It has been released just now!

Hi @BjMrq 👋,
sorry to bother you again 🙏
I was wondering if it possible to retrive transaction data related to the proposal thought open zeppelin admin api.
I guess on Open Zeppelin Admin dashboard its possibile to view that information: dashboard ui uses https://api.defender.openzeppelin.com/admin/contracts/{contractId}/proposals/{proposalId} and in the response is present a transaction object (very useful for us) similar to:
"transaction": {
    "isSuccessful": true,
    "isExecuted": true,
    "data": "hex",
    "executionTxHash": "tx hash",
    "safe": {
      "txHash": "tx hash",
      "operationType": "call",
      "txGas": "0"
    },
    "to": "address",
    "confirmations": [
      {
        "owner": "address",
        "signature": "sig"
      },
      {
        "owner": "address",
        "signature": "sig"
      }
    ],
    "nonce": 11,
    "value": "0",
    "isReverted": false
  }

Do you know if it will be possible to obtain the same object using client api endpoint https://defender-api.openzeppelin.com/admin/contracts/{contractId}/proposals/{proposalId}?
Many thanks in advance 😀

Hey again @olich97 it should be included in one of the next releases 🏗 !

Hey again @olich97 it should be included in one of the next releases 🏗 !

Cool! 😃 can you perhaps give me some hints on when its scheduled for?

Should be sometime this week!

Thanks @BjMrq. Looking forward to this 😃


apply for BP

Server location: Shanghai, China.
Organization: EOSeco
Node domain: jungle.eoseco.net
Port(http): 8888
Port(p2p): 9876
Producer name: hummingbird
Public Key: EOS85fDTxvb2P6cXuz5nQyaDwTPbemwcw6KyVDmHHZaGFNog5fBCK

@qiushaoxi  I want to connect the jungle‘s testnet , but it always shows  some words like " received a go away message from dev.cryptolions.io  reason = wrong chain ". Can you help me？