Some builds fail with: cannot import name 'Signature'

Details

Project URL: https://readthedocs.org/projects/progressbar-2
Build URL (if applicable): https://readthedocs.org/projects/progressbar-2/builds/6841726/
Read the Docs username (if applicable): wolph

Expected Result
A successful build
Actual Result
python /home/docs/checkouts/readthedocs.org/user_builds/progressbar-2/envs/develop/bin/sphinx-build -T -E -b readthedocs -d _build/doctrees-readthedocs -D language=en . _build/html
Running Sphinx v1.6.5
making output directory...
loading translations [en]... done

Traceback (most recent call last):
  File "/home/docs/checkouts/readthedocs.org/user_builds/progressbar-2/envs/develop/lib/python3.5/site-packages/sphinx/registry.py", line 196, in load_extension
    mod = __import__(extname, None, None, ['setup'])
  File "/home/docs/checkouts/readthedocs.org/user_builds/progressbar-2/envs/develop/lib/python3.5/site-packages/sphinx/ext/autodoc/__init__.py", line 34, in <module>
    from sphinx.util.inspect import Signature, isdescriptor, safe_getmembers, \
ImportError: cannot import name 'Signature'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/docs/checkouts/readthedocs.org/user_builds/progressbar-2/envs/develop/lib/python3.5/site-packages/sphinx/cmdline.py", line 305, in main
    opts.warningiserror, opts.tags, opts.verbosity, opts.jobs)
  File "/home/docs/checkouts/readthedocs.org/user_builds/progressbar-2/envs/develop/lib/python3.5/site-packages/sphinx/application.py", line 196, in __init__
    self.setup_extension(extension)
  File "/home/docs/checkouts/readthedocs.org/user_builds/progressbar-2/envs/develop/lib/python3.5/site-packages/sphinx/application.py", line 456, in setup_extension
    self.registry.load_extension(self, extname)
  File "/home/docs/checkouts/readthedocs.org/user_builds/progressbar-2/envs/develop/lib/python3.5/site-packages/sphinx/registry.py", line 199, in load_extension
    raise ExtensionError(__('Could not import extension %s') % extname, err)
sphinx.errors.ExtensionError: Could not import extension sphinx.ext.autodoc (exception: cannot import name 'Signature')

Extension error:
Could not import extension sphinx.ext.autodoc (exception: cannot import name 'Signature')

Note that building the same project again usually succeeds as can be seen in the build log: https://readthedocs.org/projects/progressbar-2/builds/

For the others, I had this issue with Sphinx-1.7.0 I upgraded to Sphinx-1.7.1 and the import issue went away but my python env suddenly crashed after reading sources ... downgrading to 1.6.9 then worked fine again

Setting the sphinx version to <1.7.0 appears to work indeed, but I'm not sure what's causing it.
Looking at the stacktrace it appears to be internal to Sphinx but I have no problems building it locally

This looks to be something upstream with Sphinx. The exception is on an import to a Sphinx module, from a Sphinx module. I'd raise with them if the problem exists in latest Sphinx.
You can also try wiping your build environment in the case that there are old files present.

@agjohnson how can I wipe the build environment in RTD? I've already tried both with and without a virtualenv but that made no difference.

Any updates on this? I don't fancy having to pin-down sphinx version just to allow RTD to succeed doing the build.

@WoLpH you need to go to versions and  then to edit, there is a wipe button.
@ssbarnea did you try wiping the env? Also you can have a requirements file just for rtd.

@stsewd Thanks! Finally after using the magic wipe button, I was able to successfully build it.
Does this also means that we could try to use newer versions of sphinx like 1.7.1 without problems on RTD?

Does this also means that we could try to use newer versions of sphinx like 1.7.1 without problems on RTD?

Yes, you can use the sphinx version that you need, just be aware of this Sphinx bugs https://github.com/rtfd/readthedocs.org/issues/3812, https://github.com/rtfd/readthedocs.org/issues/3769

It seems that RTD triggers two builds when I push to master and one of them is failing with the Signature error. Look at https://readthedocs.org/projects/jira/builds/
If I cleanup and retrigger the build from RTD web interface it does succeed. I already spend more than half of the weekend trying to make RTF behave,... and still out of luck :(

@ssbarnea there are two builds probably because you have activate two versions: master and latest, but master == latest, you can deactivate master. Also I see that latest is the one version that is failing, that's because you only wipe master (rtd makes a new environment for each version, doesn't matter if they are the same commit/branch). If you wipe latest probably you will no have more problems, or I hope so :)

Seems this is not an issue anymore. Closing.


Fix install button position

Add position: relative to the parent div that owns the scrollbar, so that Install button positions itself relative to it and not to the whole document.
Fixes a bug where button would get rendered on top of a scrollbar.
Before:

After:

I think you snuck in a commit there that’s not supposed to be in here

Ah, it's just an unrebased branch.

Did the "merge branch" thingy, now with Squash & Merge the extra commit shouldn't matter :)

Ping.


Issue 1

Mention H-Farm in the project ReadMe

Fixed in https://github.com/andreacaron/Animal-Crossers-/commit/e945bf10b60f6ca4d01d7b4825aa497b7a5677b2


Enhancement: Restore BrowserOp

Contact Details
No response
What features would you like to see added?
BrowserOp can be restored
More details
I use the old version, it still works fine
Which components are impacted by your request?
No response
Pictures

Code of Conduct

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

I just tested it and you're right, I'll be adding it back


Adding declared license

Type: Missing
Summary:
Adding declared license
Details:
Nuget site indicates license is MIT
Resolution:
License URL in Nuspec is also MIT
Affected definitions:

Microsoft.Bot.Schema 4.7.0

@capfei Can you resolve this conflict? Thanks.

@AE49 resolved!


native-tis-alpn feature overrides request's host header

Hello,
I have a reverse proxy service that is getting request and passing it to Reqwest to proxy to a different backend service. I want to preserve the incoming host header and have Reqwest client pass it to backend. Ex. request-> "my_service.com" -> "my_backend.com"
Both native-tls and rustls preserves the host header value, but when native-tls-alpn is enabled, host header is overridden to with reqwest's url's domain
Testing

For this simple test, I use Reqwest client to point to https://postman-echo.com/get to echo back what the client sent

#[tokio::main]
async fn main() {
    let client = reqwest::ClientBuilder::new()
        .build()
        .unwrap();

    let body = client
        .get("https://postman-echo.com/get")
        .header("host", "my_backend_service.com")
        .send()
        .await
        .unwrap()
        .text()
        .await
        .unwrap();

    println!("{}", body);
}

Using native-tis and rustls
Postman Output
  "headers": {
    "x-forwarded-proto": "https",
    "x-forwarded-port": "443",
    "host": "my_backend_service.com",
    "x-amzn-trace-id": "some_trace",
    "accept": "*/*"
  },

Can see that its using the host header I've provided
Using native-tls-alpn
Postman Output
  "headers": {
    "x-forwarded-proto": "https",
    "x-forwarded-port": "443",
    "host": "postman-echo.com",
    "x-amzn-trace-id": "some_trace",
    "accept": "*/*"
  },

Can see that host header has been overridden
Why don't you just not use native-tls-alpn?
I have a hard dependency that use Reqwest with this feature, so it gets added to my Reqwest client via feature unification
Question
Was this intended behavior for native-tls-alpn or is this some kind of bug?
Feature Request
I tried use_rustls_tls() or use_native_tls()(ref) in ClientBuilder while I have native-tls-alpn feature enabled in hopes to isolate my client, but lead to same host override behavior. I feel like these functions should isolate itself from native-tls-alpn settings. Perhaps with that isolation and newuse_native_tls_alpn() function, people can choose which specific backend to use for tls more specifically, especially when dependencies change backend tls (https://docs.rs/reqwest/latest/reqwest/tls/index.html)

Hm, I searched through reqwest, and nothing adjusts the host header other than the Url. The ALPN feature also just sets that extension for the TLS handshake. I'm not sure why you're seeing that. Is Postman changing what it thinks is the host based on the TLS SNI value it receives in the handshake?

Hey seanmonstar, thanks for reply
I used postman here as an example and I doubt that Postman looks at SNI value and overrides host header because I also tested this using other endpoints that I control with the same results. So I am fairly certain this is client behavior.

It could be something inside native-tls that gets enabled when ALPN is turned on? I've checked again, and I'm 99.9% sure that nothing else changes the actual host header. The most likely thing is something in the TLS handshake.

Actually, just after writing that: it might be that with ALPN, that means it's negotiating HTTP/2. If so, that protocol does not use the host header, it uses :authority, which is based on the URL you specified.

Thanks Sean for suggestions,
I followed up on your suggestion
Checking for HTTP2
It does indeed use HTTP2, however I don't understand that if HTTP2 does not need host header, why would client modify it? Shouldn't we still preserve the host header? Still feel like this is a bug.
TRACE hyper::client::pool: checkout waiting for idle connection: ("https", postman-echo.com)
2024-04-26T16:30:47.394596Z TRACE hyper::client::connect::http: Http::connect; scheme=Some("https"), host=Some("postman-echo.com"), port=None
2024-04-26T16:30:47.394751Z DEBUG hyper::client::connect::dns: resolving host="postman-echo.com"
2024-04-26T16:30:47.397583Z DEBUG hyper::client::connect::http: connecting to <IP_ADDRESS>:443
2024-04-26T16:30:47.468225Z DEBUG hyper::client::connect::http: connected to <IP_ADDRESS>:443
2024-04-26T16:30:47.625363Z TRACE hyper::client::client: ALPN negotiated h2, updating pool
2024-04-26T16:30:47.625553Z TRACE hyper::client::conn: client handshake Http2
2024-04-26T16:30:47.625911Z DEBUG h2::client: binding client connection
2024-04-26T16:30:47.626127Z DEBUG h2::client: client connection bound

Good news is that I tested with alpn feature on and I forced client to only use http1(ref) (hope this means use http version 1 and not http1.0 haha), and host override behavior is gone
2024-04-26T16:47:19.430144Z TRACE hyper::client::pool: checkout waiting for idle connection: ("https", postman-echo.com)
2024-04-26T16:47:19.430404Z TRACE hyper::client::connect::http: Http::connect; scheme=Some("https"), host=Some("postman-echo.com"), port=None
2024-04-26T16:47:19.430552Z DEBUG hyper::client::connect::dns: resolving host="postman-echo.com"
2024-04-26T16:47:19.445281Z DEBUG hyper::client::connect::http: connecting to <IP_ADDRESS>:443
2024-04-26T16:47:19.515330Z DEBUG hyper::client::connect::http: connected to <IP_ADDRESS>:443
2024-04-26T16:47:19.682169Z TRACE hyper::client::conn: client handshake Http1
2024-04-26T16:47:19.682322Z TRACE hyper::client::client: handshake complete, spawning background dispatcher task
2024-04-26T16:47:19.682681Z TRACE hyper::client::pool: checkout dropped for ("https", postman-echo.com)

Going forward

Short term, I think I will use http1 only to get around this issue
Long term, what are your thoughts on my feature request so Reqwest consumers are isolated from sudden Reqwest behavior change due to their dependency?


[gui2] Component demos

Pull Request Description

Closes #7916

Important Notes
None
Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:

[x] The documentation has been updated, if necessary.
[ ] Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
[ ] All code follows the
Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
All code has been tested:

[x] Unit tests have been written where possible.
[x] If GUI codebase was changed, the GUI was tested when built using ./run ide build.

note to self: will need to add custom controls to every component, not just some, so that interacting with it will reflect in the controls

it's not 100% done i don't think (keyboard-related bugs, missing the code editor i guess, lint is failing?!?!?!? - some of the failures will be fixed by the hotfix, the rest will need to be investigated)
but, it should be complete enough for code reviews to start

Note: the graph editor doesn't come with mock metadata - I think it'd make the controls too complicated, so I'm assuming we will be doing auto layout somewhere down the line, which should fix the graph editor demo as a side effect

one thing ive noticed is that our z-indices are inconsistent - usually they're 1 but we sometimes have 2, or -1, or 99999. not 100% sure whether they're all needed, I don't think the 99999 one in sql is particularly necessary but not sure whether any of the others are safe to change.

@Frizi pinging for visibility

okay, things should be fixed again

there's a weird error where gui2 prettier seems to format index.html differently to root prettier. oh well...

-_- hopefully that's the last lint issue

hmm... most things seem to be working but npm run story:build produces bad output:
specifically, the exports from codemirror.ts are undefined for some reason. when this happened on the dashboard, it's been because of circular imports, but i don't think that's what's happening here.
some threads online say it might be because of importing a subpath... but a path like @codemirror/view is a namespaced top-level import so that's probably not it.
weirdly enough, import * as cmView seems to work fine...


"M4RA" box fix, now says M4SPR

About the PR

should fix this

Changelog
:cl: JoeHammad

tweak: fixed M4SPR box name

it's a pleasure


random question

So from the screenshot is says the episode is on google drive, does moetube host all there stuff on google drive?

Probably, yeah


remove add_std from wrapper

See: https://github.com/ethereum/solidity/issues/3695#issuecomment-371685583
The --add-std flag does nothing since <0.4.11 and was removed in 0.4.21.

Closed in #64


Need help with disassembly

I'm trying to turn my connect into a walking smart home hub abomination. I need carefully taking the poor thing apart and getting inside to change a few things. Using this tutorial in case you're wondering
https://howchoo.com/g/otewzwmwnzb/amazon-echo-furby-using-raspberry-pi-furlexa

Hi @Tusskie! The tutorial you linked to is about the "original" Furby, not the Furby Connect. For taking apart Furby Connect, I suggest you take a look at this: https://www.youtube.com/watch?v=JlUDiag7i6c
Please note that turning Furby Connect into Furlexa is going to be significantly more difficult if you want to keep the eye LCDs; with Furby Connect, you can just connect the eye motors to some GPIO pins, but with Furby Connect you'd probably have to install new LCDs for the eyes to make it work. Here's a project where someone programmed custom eye animations for their Furby: https://hackaday.io/project/9386-open-furby, see also https://www.youtube.com/watch?v=u3GzCX6JvRM

Thank you. I just didn't want to damage any motors needed. I have a replacement pi if necessary :)


phpstan-rules does not works without including symplify/astral/config/services.neon but no mention about that in docs

Hello after upgrade to new phpstan-rules I spend some time trying to figure out why it does not work. There were series of weird missing service errors. I finaly found out that I must manually incliude symplify/astral/config/services.neon in my phpstan.neon too. It should be mentioned somewhere in the docs I think.

Hi, the package should be loaded with phpstan-extension installer:
https://github.com/symplify/astral/blob/8dbb484edac44f27000e1dc0f03cb3f71acb8142/composer.json#L36-L40

I see. I take extension installed as common knowledge for PHPStan users. Always use it, it will save you so much time :)

I just switched to it. We had working configuration from times when it was not yet available and it just break now after update.


HBase integration

Use HBase for DB operations
Items to close for issue closure

[x] Coding
[x] Unit tests
[x] Example
[x] Documentation

all pending issues that are just good-to-have are closed as of now.


TODO: Switch Archive to Adm-zip also

Currently using to read archives, but not create archives.
https://github.com/cthackers/adm-zip

Working


fixes final part of issue #287

the category header could be displayed in one column but the first item in the category could be in the next column
items themselves are not broken between columns
the problem is fixed by making the category header a part of the first item, which requires a modification of the HTML and correspondingly tweaking the CSS a bit.
listf-styling.scss should have been deleted when it was renamed to _listf-styling.scss patch will be visible soon on new-raku. Difference between old and new is that class listf-caption is now on a <p> not a <div>

This appears to fix the div formatting and the column breaks, thank you.


Numerical difference between trectools and trec_eval in terms of Rprec and ndcg

Hello,
I have a situation where there large differences between some metrics computed using the official trec_eval (as called from pytrec_eval) and trectools.  To reproduce, you can run the following (it will download file.qrel and file.run from gist):
Expected output:
trectools_results {'Rprec': 79.06, 'ndcg': 93.69}
pytrec_eval_results {'Rprec': 79.62, 'ndcg': 94.35}

The code:
import urllib.request
import numpy as np
from trectools import TrecQrel, TrecRun, TrecEval
import pytrec_eval

##### download qrel and run files

qrel_file_path = 'https://gist.githubusercontent.com/sergeyf/4d88da8d865ccad06cfd140b8583cf55/raw/d93a104817103e4330619aa93506c424cfd5ae16/file.qrel'
qrel_file = 'file.qrel'
urllib.request.urlretrieve(qrel_file_path, qrel_file)

run_file_path = 'https://gist.githubusercontent.com/sergeyf/4d88da8d865ccad06cfd140b8583cf55/raw/d93a104817103e4330619aa93506c424cfd5ae16/file.run'
run_file = 'file.run'
urllib.request.urlretrieve(run_file_path, run_file)

###### trectools

qrel = TrecQrel(qrel_file)
run = TrecRun(run_file)

trec_eval = TrecEval(run, qrel)

trectools_results = {'Rprec': np.round(100 * trec_eval.get_rprec(), 2),
                     'ndcg': np.round(100 * trec_eval.get_ndcg(), 2)}

###### pytrec_eval
def get_metrics(qrel_file, run_file, metrics=('ndcg', 'Rprec')):
    with open(qrel_file, 'r') as f_qrel:
        qrel = pytrec_eval.parse_qrel(f_qrel)

    with open(run_file, 'r') as f_run:
        run = pytrec_eval.parse_run(f_run)

    evaluator = pytrec_eval.RelevanceEvaluator(qrel, set(metrics))
    results = evaluator.evaluate(run)

    out = {}
    for measure in sorted(metrics):
        res = pytrec_eval.compute_aggregated_measure(
                measure,
                [query_measures[measure]  for query_measures in results.values()]
            )
        out[measure] = np.round(100 * res, 2)
    return out

pytrec_eval_results = get_metrics(qrel_file, run_file)

print('trectools_results', trectools_results)
print('pytrec_eval_results', pytrec_eval_results)

Hi Sergey,
Thanks for using this package and reporting this bug.
The problem happened when one of the topics had no relevant documents in the qrels.
It should be fixed now. Please update the package in your system to v0.0.43.
By the way, we have been looking for help to write unit tests for trectools.
Once we have all the proper tests done, we can release version 1.0.
Please feel free to help the community and grow this package!

It would be fun to help, but I'm not flush with time at the moment (job, family, etc). Sorry to say, but if I do have some time, I'll loop around and maybe make some tests!


[Enhancement] Add some necessary logs for external table

What type of PR is this：

[ ] BugFix
[ ] Feature
[x] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Which issues of this PR fixes ：

Fixes #
Problem Summary(Required) ：

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] I have added user document for my new feature or new function

run starrocks_admit_test

run starrocks_fe_unittest

[FE PR Coverage Check]
:disappointed: fail : 7 / 34 (20.59%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/connector/hive/events/DropPartitionEvent.java
0
11
00.00%
[46, 47, 48, 49, 88, 98, 99, 101, 102, 107, 108]

:large_blue_circle:
com/starrocks/connector/hive/events/AlterPartitionEvent.java
0
5
00.00%
[79, 95, 97, 113, 115]

:large_blue_circle:
com/starrocks/connector/hive/events/InsertEvent.java
0
3
00.00%
[87, 123, 124]

:large_blue_circle:
com/starrocks/connector/hive/events/MetastoreEventFactory.java
0
6
00.00%
[114, 118, 123, 125, 127, 139]

:large_blue_circle:
com/starrocks/connector/CachingRemoteFileIO.java
1
2
50.00%
[60]

:large_blue_circle:
com/starrocks/connector/hive/CachingHiveMetastore.java
2
3
66.67%
[339]

:large_blue_circle:
com/starrocks/connector/PartitionUtil.java
4
4
100.00%
[]

run starrocks_clang-tidy


Regenerate the API once the spec discriminator mapping / API is fixed

See https://github.com/aptos-labs/aptos-core/issues/1110.

Same thing for once our (Aptos') spec is fixed.


PeLoader IllegalArgumentException

Describe the bug
An IllegalArgumentException is thrown when imported the attached file. This is a variation of my InheritanceTests
To Reproduce
Steps to reproduce the behavior:

Import the attached file.

Expected behavior
No exception should occur.
Attachments
Inheritance_Tests.zip
Environment (please complete the following information):

OS: Microsoft Windows [Version 10.0.19042.928]
Java Version: 15.0.2
Ghidra Version: 10.0_DEV
Ghidra Origin: locally built

stack trace?

stack trace?

Opps. Will edit to provide later.


ACS Education level integration

Moving to backlog as we are not doing this for launch

Closing as this is not on the radar


[test] Ignore

Error output some relevant information for windows CI debugging

Try a def  - because Windows doesn't support C99 capability to use a static const as an rvalue const.


Fix bug that causes pytest logging options to be ignored (#8135)

Pull request opened by the merge tool on behalf of #8135

Merged into branches iso7 in deffe4fb56a8198a1b1f6326106e87647a099da7


bash: warning: command substitution: ignored null byte in input

After installing argcomplete I get the following warning from bash frequently. Everything still works but this is very annoying. It happens the instant I hit tab to auto-complete and it happens about 10% of the time. Any idea what's causing this?
bash: warning: command substitution: ignored null byte in input

On Ubuntu 19.10, bash 5.0.3(1)-release, I get the same error on every first non-filename and non-argcomplete complettion in a given shell.
Specific steps to reproduce:

Install argcomplete and enable global completion by activate-global-python-argcomplete --dest=- > /somewhere.bashrc and then sourcing that in my .bashrc.
Open a new terminal.
git <tab>.

Notes:

Here I use git as an example of a custom completion. I don't get warning if I do ls <tab>, also I don't get it when using ingit <tab>. Here ls is used just as an example of any filename completion, and ingit is just an example of command for which I implemented tab completion via argcomplete.
Also, after the warning is triggered once, it does not happen ever again in the same shell.
Also, even if I try some completions that don't trigger the warning before doing git <tab> (or another non-filename non-argcomplete complettion), the warning still pops up on the first of those.
Whenever the warning occurs, it is printed 2 times, e.g. on git <tab>:

$ git -bash: warning: command substitution: ignored null byte in input
-bash: warning: command substitution: ignored null byte in input

Despite the warning, completion works, just that the visuals are messed up because of the warning, e.g. on git fet<tab>:

git fet-bash: warning: command substitution: ignored null byte in input
-bash: warning: command substitution: ignored null byte in input
ch

@seanmcfeely You say "frequently" so is your case different or the same?

I've installed bash 5,0 and managed to reproduce this, although it only happens to me once, not twice. I've pushed a change that fixes it on my machine here: https://github.com/evanunderscore/argcomplete/tree/ignore-null-byte. Please try this out and let me know whether it fixes the problem for you.
Note that this is only happening to you the first time you complete something because of the way completions are registered, which is briefly alluded to here: https://github.com/kislyuk/argcomplete#common-problems. If you run complete -r git it should remove whatever completer was registered to allow you to trigger the bug again.
If my branch doesn't completely fix your issue, can you add set -x to the top of argcomplete/bash_completion.d/python-argcomplete.sh, eval the output and try again please? This will print each command before it's executed so we'll be able to see which particular command is generating the warning.

@evanunderscore I can confirm the issue and that your change fixes it for me. Can you open a PR and merge into master?

Sorry for the delay responding.
I have observed this behavior on both bash version 4.4.19(1) and version 4.4.20(1) and the first difference from what was first described for me is that the warning is only displayed once, not twice. The second difference is that I can make it happen at most twice in the same bash shell.
Finally, I installed from  @evanunderscore's and I can confirm that his change has also fixed the issue for me. I look forward to that getting merged with the upstream and making it in to the latest pip package for argcomplete. Thanks everyone!

I made a mistake and accidentally installed from @evanunderscore's master branch, which is behind the upstream master. The state of python-argcomplete.sh on @evanunderscore's master branch also fixes the issue for me.
Moreover, I correctly installed from https://github.com/evanunderscore/argcomplete/tree/ignore-null-byte and confirmed that this change also fixes the issue.
Thanks!

@evanunderscore barring any unforeseen issues, I'd like to replace head and tr with the read builtin:
[[ "$(read -r -n 1024 < make_release_checklist.sh; echo $REPLY)" =~ ^#!(.+)$ ]] && ...

read skips null characters by default, and removing subprocesses will speed this thing up. Any objections?

@evanunderscore please take a look at #280, which should solve this issue while also switching to builtins where possible in the completion hook shellcode. What do you think?

Sounds better than spawning multiple unnecessary subprocesses. I've left a couple of comments.

Released in v1.11.0, please test.

Indeed, the problem is fixed in my case after the most recent release! Thanks! Important note is that I not only needed to update the package, but afterwards also the initialization i.e. activate-global-python-argcomplete --dest=- > file.

Fixed the issue for me as well, thank you.


fixed ClassCastException when trying to cast BSONNull to BSON*

While profiling my app I saw a lot of exceptions thrown by reactivemongo, namely DocumentKeyNotFound and ClassCastException - actually I got 27500 DocumentKeyNotFounds and 10600 ClassCastExceptions in a very short period of time!
This pull request fixes the ClassCastExceptions. That one is kinda tricky because it is been swallowed by the Try and therefore never caused any visible harm. But since this exception is always thrown if a key is null, it actually has an impact (see above). For example: LastError always produces (at least?) one ClassCastException! For this fix I had to change more code than I wanted, but no public facing API has been touched. Well the returned Failure now contains a DeserializationException or a ValueIsNull exception instead of a ClassCastException.
Basically what this patch does is, return a Failure containing a ValueIsNull exception instead of throwing a ClassCastException. I created an AllowNullable trait which, if extended from, indicates that the BSONReader allow the value to be BSONNull or BSONUndefined and therefore does not throw a DeserializationException, but return a None. Now if a BSONReader cannot handle the BSONValue a DeserializationException will be thrown. All default BSONReader extend this trait, except BSONBooleanLike, because that one handles the BSONNull and BSONUndefined slightly different. Of course a few things in this patch could be further improved, but I didn't since that would break the public facing API!
What do you think?

Hi, it can be closed for now, until the BSON lib can be refactored. Best regards


Add handling for mfa_serial in ~/.aws/config

Motivation and Context
Fixes: https://github.com/awslabs/aws-sdk-rust/issues/527
Description
Adds trait and configuration machinery for supplying MFA tokens. The goal is to fit into the AssumeRole workflow in a similar way to what happens in boto3.
The default provider will just log/return an error if an MFA token is requested, but users can plug their own ProvideMfaToken implementations (e.g. to read from stdin). There are a few outstanding things I know about for the PR to be ready:

[ ] better testing
[x] doc strings

But I'd also like to get some feedback before addressing those on the general shape of the PR (I think it's about in line with what was discussed in https://github.com/awslabs/aws-sdk-rust/issues/527), and I wasn't sure on a few code structure things - in particular:

is profile::credentials::exec::AssumeRoleProvider::credentials() the right place to be calling out to users? One thing that's a little awkward about this is that by the time we get to this point in the implementation, we're already being wrapped in a (rather short) timeout for the cache... which might be a bit of a smell, if we're then pausing for user input?
is aws_config the right place for the new mfa_provider module? I notice that ProvideCredentials and friends come from aws_types - but I'm not sure that the MFA code is really "shared" between services in a way that would qualify it for the aws_types crate?
is aws_config::profile the right place? Maybe it should go beneath profile::credentials ? I'm not totally clear on the structure here.
general naming stuff - I've broadly tried to keep things similar to e.g. ProvideCredentials, is that about right?

One thing that I proposed in https://github.com/awslabs/aws-sdk-rust/issues/527 was to add a default ProvideMfaToken implementation that would read the code from stdin, analogously to how boto uses getpass. @Velfi suggested over there that it would probably be worth an RFC for something like this, and having done a rough implementation for testing, I think they were right - there are a few choices to be made for implementation (I don't think Rust has a convenient getpass that we can reach for), so a more conservative approach seems appropriate. I would think it would be convenient at some point to have parity with other SDKs here, but this initial implementation at least gives us the ability to bring our own (and maybe gives the ecosystem space to play around and find the right / minimal way of doing it).
Here's a sample implementation of ProvideMfaToken that grabs the token from stdin using the atty and rpassword crates:
impl ProvideMfaToken for ProvideMfaTokenFromStdin {
    fn mfa_token(&self, serial: &str) -> ProvideMfaFuture {
        if !atty::is(atty::Stream::Stdin) {
            return ProvideMfaFuture::ready(
                Err(MfaTokenFetchError::provider_error(ProvideMfaTokenFromStdinError::NotATty)));
        }
        match rpassword::prompt_password(format!("Enter MFA code for {}: ", serial)) {
            Err(e) => {
                ProvideMfaFuture::ready(Err(MfaTokenFetchError::provider_error(e)))
            }
            Ok(t) => {
                ProvideMfaFuture::ready(Ok(MfaToken::from(t)))
            }
        }
    }
}

Testing

[ ] to add: automated testing
Here's a sample repository that's had these changes patched in via Cargo.toml overrides (assuming smithy-rs is checked out in a neighbouring repository): https://github.com/jelford/aws_mfa_token_provider. That's what I've been using for exploratory testing, and have verified that:

A bad MFA code (randomly typed letters) results in a sensible error percolating through from the API backend
A good MFA code successfully authenticates

When not specifying a custom ProvideMfaToken implementation, a reasonably friendly error comes back to the user.

Checklist

[x] I have updated CHANGELOG.next.toml if I made changes to the smithy-rs codegen or runtime crates
[x] I have updated CHANGELOG.next.toml if I made changes to the AWS SDK, generated SDK code, or SDK runtime crates

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Thinking about the cache timeout issue more, I'm wondering if ProvideMfaToken should instead by sync with the expectation that the application either asks for an MFA token ahead of time, or continuously refreshes a MFA token in a separate thread. The challenge with that, I think, is with the mfa_serial entry in the profile credentials file since anything external wouldn't have easy access to that.
It seems like an application requiring MFA is going to need to be more aware of the overall MFA input process. For example, what is the expected behavior if the MFA token expires for the TTY input use-case? Would the user be prompted for another token? Would that interrupt something else in the TTY?
Or thinking about a GUI application that wants to run an AWS command on the user's behalf. If a dialog prompt came up asking for MFA, and the user clicked cancel, would there need to be some way to communicate that cancellation action back so that the application can handle it accordingly rather than assuming some unrecoverable error occurred?
Anyway, that's my brain dump for now. Will keep thinking about this.

Just a quick note on the topic of MFA refreshes - I think what you're saying about managing refreshes sounds very reasonable on the face of it, but at the same time, I note that boto has chosen to punt on this one.
It's hard to see how that could turn out well in a long-lived application like an IDE, though, so the topic is worth a little more thought. I wonder whether the right approach to deal with caching might be to find a way to push it "down" a level, rather than introducing a kind of complex interaction where it knows that there are certain things it just shouldn't cache (feels like a layer / encapsulation violation). I'll confess I didn't look hard at the current caching setup (I just noticed it when I hit a timeout).
I'm not sure I understand this comment:

I'm wondering if ProvideMfaToken should instead by sync

I'm not wedded to it being async by any means, but I think maybe it's orthogonal to the rest of the issue? (I mean that the next part of the sentance, asking the user ahead of time, can work just as well if it stays async, I think?)

GetSessionToken also supports MFA.

I think we have a potential solution for the timeout issue. What we can do is modify the ProvideMfaToken trait to look something like this:
pub trait ProvideMfaToken: Send + Sync + Debug {
    fn mfa_token(&self, mfa_serial: &str) -> Result<MaybeMfaToken, MfaTokenFetchError>;
}

With an enum that allows for later, timeout free, resolution of the MFA token:
#[non_exhaustive]
pub enum MaybeMfaToken {
    // The names definitely need some thinking...
    // This variant states that we believe the token will become available before the timeout
    NearTerm(future::ProvideMfaToken),
    // And this variant says we know the token likely won't be available before the timeout
    NotReady(future::WhenReady),
}

When the mfa_token function returns NotReady, we can have the AssumeRoleProvider return a CredentialsError::ProviderError with a boxed cause that has NotReady's future inside it. Then the LazyCachingCredentialsProvider can downcast the cause when it gets a ProviderError to see if it's a case where something needs to get resolved first.
The nice part about this approach is that it:

Allows us to break up the implementation so that a quicker solution can be implemented first for those that don't anticipate running into the cache timeout. By merely omitting the NotReady variant from the enum, we get half of the functionality without worrying about a breaking change later.
It's non-committal on API changes. Everything is contained in aws-config, the crate with a less stable API than aws-types.
We could potentially feature-gate it behind something like mfa-experimental to collect more feedback before deciding to stabilize it.

Downsides are:

While NotReady isn't implemented, the API is going to be obtuse since implementers will need to wrap the return value in this one-variant enum.
The downcast examination of cause in CredentialsError::ProviderError is not great. But if we need to change approach, we won't have a dead variant in CredentialsError (which is in aws-types) this way.

I'm definitely open to more ideas, but I think overall we need an RFC to examine this deeper (if for no other reason than to answer what went into our decision making). If that's something you're interested in tackling, I'm happy to help out!

Hi @jdisanti , first of all thanks for the thoughtful response on this caching / timeouts issue. I had hoped to have a bit more time on this during the week but it doesn't look like that's panned out. I'm happy in theory to look at an RFC, just with the caveat that my latency on discussions is going to be quite high over the next couple of weeks - I don't think that's a huge deal since this wasn't being worked on before (?), but if folks are keen to make progress here then I don't want to be a bottleneck.
I have two general thoughts on this topic before thinking harder about solutions though (I'm reaching for ways for it not to be a problem in the first place - I wonder whether we're over-complicating things?):

In cases where the application knows that it's likely to experience long delays in getting an MFA code, it might be acceptable just to bump the default cache-load timeout, as I've done in my own testing. Here's how I set up my credentials:
credentials::DefaultCredentialsChain::builder()
            .profile_name(&args.profile)
            .mfa_token(ProvideMfaTokenFromStdin())
            .load_timeout(Duration::from_secs(120))
            .build()
            .await;

I'm not super keen on that workflow because it requires the application to have some idea that user interaction is going to be involved - but, since implementing ProvideMfaToken is already the application's responsibility (for now...), that might not be such an unreasonable ask. The line of thinking here is:

The application already has to have some way to interact with the user
The application already has to deal with the case that auth will fail for an indefinite period / need to be retried because the user is not attentive
... therefore, the application will need its own way to handle this workflow in general (for commandline / batch-oriented apps, "handle" probably just means "crash"), and already needs to think about appropriate timeouts.

So, the "do nothing" option is to rely on the application widening the credentials cache load timeout. Do you think there's any mileage there?

I might be reading this wrong, but I think that in botocore, the way the cache wrapper works is that it doesn't enforce timeouts at the cached-load level at all. Instead, timeout decisions are delegated to whatever's going on in the underlying credentials loader (so, boto's AssumeRoleCredentialFetcher will have the normal set of timeouts applied when it actually sends a request out to sts, by virtue of going through the normal botocore.client._make_api_call flow, rather than because of anything enforced by the caching layer).

So, from the looks of it, the timeout in LazyCachingCredentialsProvider is an extra layer of timeout. If it was removed (or the application widens it), we would still have (network) timeout enforced by virtue of using `.sts_client` in `AssumeRoleProvider.
Overall, I do think the botocore approach I think the boto approach is probably about right actually - or at least, a very wide timeout set by the application at the cache level seems acceptable, given that there are timeouts at the "next level down" for anything that really needs them. That gives me a little confidence that the model suggested in 1 ("just widen the timeout on the cache") is, maybe, okay? Maybe one could go even further and allow the application to disable the cache's load timeouts entirely.
One missing piece in the "just widen the timeout on the cache" model is: the cache timeout is what's being configured with a call to DefaultCredentialsChain::load_timeout(...). I don't think there's currently a good user- accessible way to configure the timeout on the underlying sts_client, though maybe I am missing it.

So, setting aside the "just widen the timeout" idea in my previous for the time being, and engaging with the idea of having the ProvideMfaToken implementation provide some feedback to say "I need longer".
I think the basic idea of using a boxed trait to back-channel information back up to the LazyCachingCredentialsProvider is neat, and I like that this could all be kept local to aws-config, at least while API kinks are ironed out. I think MaybeMfaToken can work nicely, but there is one thing that troubles me about it: the whole reason it's needed is that the LazyCachingCredentialsProvider is imposing a timeout when it doesn't have the information to know whether a timeout is appropriate.
I wonder whether there's a way we can take your idea a step further; instead of:

Call the provider
Let it fail
Inspect the error; some errors are special
... handle the special case
Can we say directly that "some providers are special", and skip the timeout dance entirely, for certain providers?
Inspect the ProvideCredentials
If the ProvideCredentials comes with its own timeout preference, use that
Call the provider with whatever timeout logic was determined in step 2
No change to error handling

This would involve a new trait, something like this:
/// `ProvideCredentialsWithoutTimeout` implementations are not subject to the normal timeout
/// rules imposed by the `LazyCachingCredentialsProvider`.
pub(crate) trait ProvideCredentialsTimeoutCustomizer {
    /// If the provider returns its own timeout, this is what will be used in `LazyCachingCredentialsProvider`
    fn provider_timeout_override(self) -> Option<Duration>;
}

And then in LazyCachingCredentialsProvider::provide_credentials, the timeout is determined by:
let load_timeout = if let Some(timeout_customizer) = (loader.as_ref() as &dyn Any).downcast_ref::<dyn ProvideCredentialsTimeoutCustomizer>() {
    // Defer to the provider
    timeout_customizer.provider_timeout_override().unwrap_or(self.load_timeout)
} else {
    // As before
    self.load_timeout
};

The tricky part is that there's some plumbing required to make LazyCachingCredentialsProvider's loader into an Any - I think it can be done without external API changes, but it's definitely a bigger lift than your path of using the error as a back-channel, since errors already have downcast support.
If you let me know your thoughts, I'd be happy to take a stab at drafting an RFC some time over the next 2 weeks to bring all these three paths together into a coherent proposal. I find the angle that there's no timeout around this in boto quite persuasive, though presumably timeout was added to the cache layer for a good reason(!).

GetSessionToken also supports MFA.

@tschuett thanks for the note. I'm not sure whether you're suggesting a change here, or just pointing out that one can use this API as-is, since it accepts .token_code() and .serial_number() ?

There was a discussion whether AssumeRole is the only provider using MFA.
The Rust people use it:
https://github.com/rust-lang/simpleinfra/blob/master/aws-creds.py

If every implementation of ProvideCredentials is caching, then could hide the timeout.

There was a discussion whether AssumeRole is the only provider using MFA.
The Rust people use it: https://github.com/rust-lang/simpleinfra/blob/master/aws-creds.py

Ah, got it, thanks. As it happens, what I was trying to implement against the Rust SDK when I stumbled into this was extremely similar to that tool, so good to know!

If you put a MFA protected bucket policy on your S3 bucket, then AssumeRole is insufficient.
https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html#example-bucket-policies-use-case-7

@jelford - You raise some very good points, and the example of boto separating the concerns of caching and timeout is particularly intriguing. I'm definitely open to that approach so long as we figure out how that plays into the default credential provider chain and its configuration.

Can we say directly that "some providers are special", and skip the timeout dance entirely, for certain providers?

That was something I considered before arriving at the boxed back-channel error approach, but the API change to the ProvideCredentials trait is a commitment I'm not so confident about in the long term. It looks like you might be getting around that by having the additional information in a separate trait and accessing it via downcasting though. If we find a way to successfully pull off that downcasting, then that seems like another workable approach.

The tricky part is that there's some plumbing required to make LazyCachingCredentialsProvider's loader into an Any - I think it can be done without external API changes, but it's definitely a bigger lift than your path of using the error as a back-channel, since errors already have downcast support.

Yeah, I see what you mean. I spent a bit of time playing around with it in the Rust Playground and wasn't able to get from an Arc<dyn SomeTrait> into a &dyn OtherTrait. It seems like it should be possible, but it's not immediately obvious how to do it.

presumably timeout was added to the cache layer for a good reason

I don't recall there being a good reason, but @rcoh might know of one.

If you let me know your thoughts, I'd be happy to take a stab at drafting an RFC some time over the next 2 weeks to bring all these three paths together into a coherent proposal. I find the angle that there's no timeout around this in boto quite persuasive, though presumably timeout was added to the cache layer for a good reason(!).

This sounds great! I think an RFC exploring the different solutions and their pros and cons will help a lot with deciding which we want to go with. I think the biggest snag with the separation of cache and timeout will be figuring out exactly how it works in the default chain. There are lots of questions that come to mind, such as: what are the defaults? Is the timeout configurable for each individual provider in the chain? Or does the timeout become an implementation detail of each individual provider? Are there API changes? And so on...
Thanks for the great discussion so far!

Closing this as I'm not currently actively working on it. I still want to pursue MFA token support, but as discussed, there should probably be an RFC for any changes around how timeouts are handled, and I notice that RFC-0014 has landed since I was first looking at this a few months ago, so I think it's a good idea to pause and digest what's gone on there before proceeding.
I would like to come back to this, but spare time to work on things outside of work is at a premium right now. I'd be happy to chat through if anyone is eager to make progress here and wants to pick it up.


Move addon-info into addons panel

Why
Currently addon-info shows component info in the preview pane alongside each story. This behavior differs from typical addons, that display their info in the addons panel.
Modifying the behavior to use the addons panel would make the addon available for react-native. It also means that addon-info can benefit from addon panel UI improvements in future versions of storybook-ui.
EDIT: It would also make the addon compatible with storyshots
What

[ ] modify the info addon to use the addons panel
[ ] update docs

Maybe it would be better to split the addon-info features to be displayed in different panel? One for the description, one for the source, one for the propTypes? What do you think?

If you are thinking about splitting it into separate panels it starts to sound like separate addons which already exist.
There are propTypes addon, description addon, source addon.

@shilman is this a new addon?

@bigassdragon i'm proposing modifying the existing addon, but it could also be a separate addon. it seems like there are a bunch of addons that do similar things in this space, so it would be nice (i think!?) to consolidate and remove duplication of work...

@shilman is there a link to the existing addon we are talking about?
I tried looking for it but I have never seen or heard of addon-panel, I would not mind having any kind of merge just need to know what it would look like and if we can make and even more awesome addon that could incorporate a lot of slick things to make documentation better.

@bigassdragon sorry for the confusion. hopefully this clarifies?

@shilman OOOOHHHHHHH. I definitely get it now. yeah I use those.
However I thought there was an addon that already does a panel view of the documentation.
I think you might be trying to do something like this: https://github.com/mihalik/storybook-addon-markdown
However the difference is it would use the addon-info plugin so you do not need to create a bunch of markdown files.
Is that correct?

@bigassdragon AFAIK:

addon-info looks at proptypes etc. to create an API description semi-automatically
addon-markdown accepts generalized markdown?

I think this should all be simpler, cleaner, and compatible with the rest of the plugins.

@shilman correct, I was just making the comparison that you want the docs to show up in one of the panels in your picture above.

@shilman I think this idea would be awesome. I kind of thought it would be cool to have the option to have it in the panel and if we put it in the panel let's provide the user the chance to remove the blue button that shows up where you switch between documentation and example.
I think it would be really slick if we can have the ability to show the docs in a panel and also the configuration to hide the blue button because that could be redundant to show.

@shilman:
Right now there are:
Plugin for documentation: https://github.com/Gongreg/react-storybook-addon-docgen
Plugin for usage: https://github.com/Kilix/storybook-addon-jsx , https://github.com/Gongreg/storybook-usage
As far as I understand the info addon is kinda like a wrapper for these two.
I think it would be good to have simply two separate addons inside monorepo, so users could choose to op out from using one of the addons if they want to.
And then the info addon wouldn't be necessary at all.

Thanks @Gongreg that makes a lot of sense. I think part of the problem is that addon-info came first and is mentioned all over the place in the docs, so lots of people use it and don't necessarily even know about the replacements. It's a little messy/confusing right now, but I'm sure we can come up with a clean solution here.

Here's another reason this should happen:
https://github.com/storybooks/storybook-addon-a11y/issues/11

+1 really wish it worked this way

Furthermore, we should get rid of the addWithInfo(title, description, story) API because it makes it impossible for addons to interoperate. Instead, we can use the pattern used in other addons (e.g. notes).
Either:
storiesOf('MyComponent', module)
  .addDecorator(withInfo(title, description))
  .add('foo', () => <MyComponent />)
  ...

Or something like:
storiesOf('MyComponent', module)
  .add('foo', () => <WithInfo title='my title' description='my desc'><MyComponent /></WithInfo>)

+1 for the first option

@shilman yes this seems like a very easy thing to change and a good practice to establish. A lot of addons out there follow the addWithX approach probably because they are just imitating the canonical info addon.

I looked briefly into replacing addon-info with the docgen and jsx addons that @Gongreg mentioned above. The issues I ran into (which are probably why he forked them) are:

The docgen plugin doesn't seem to have been updated for 3.0 yet, and doesn't quite work.
The JSX plugin requires the use of .addWithJSX() (strictly speaking this isn't a step backwards). Still it would be good to allow the decorator pattern @shilman mentioned above.

However these issues are probably easily solved. I am happy to help with updating these packages and bringing them into core alongside deprecating the info addon if the respective authors would like that to happen (@wcastand, @mihalik?)

Hi, I wouldn't mind putting jsx into the monorepo but i'm not okay with the WithNotes pattern.
Addon for panels shouldn't be in my stories.
We know this is a issue right now and we discussing on how to change the addon API to allow this kind of patterns and avoid the overwrite of .add()

@wcastand -- do you mean you don't like the fact that the story gets "polluted" with the decorator?
Is there a specific reason you don't like it (i.e. does it stop you doing something?), or is it more a matter of style? (I don't really like it either)
I am looking at this from a short-term perspective. The issue with .addWithX() is you can only use one addon that uses it! This is a problem for adoption of addons.
Also the nice thing about the decorator pattern is you can apply it to a whole chapter or even all stories in a natural way using an API that users are familiar with.
My slightly longer term suggestion is to solve #993 and pass options in the .add() call. This avoids the decorator problem.
A new addons API would be good! But it seems a bit further off.

(It is of course possible to offer both APIs from the package)

@tmeasday You are totally right, I forked them because they were not updated.
@wcastand Why can't you reach storyFn() while using addDecorator() pattern?
The addon-usage plugin works this way.
The problem with addDecorator is that the order is important.
That allows to use intersting combinations of addons, but problem is that addons pollute storyfn().
So if user adds addDecorator(WithJSX) as a first addon, you will get same storyFN() as using addWithJsx().

It's mostly a matter of style. separation of my stories and storybook's helpers(addons, etc)
I don't mind decorators at all, i use them for thing like Redux, Fela. But decorators are for app related needs.
In my opinion, they shouldn't be used for storybook's panels.
I won't change the api of the addon JSX for a temporary fix that breaks the plugin for older version.
For solutions, like i said, i made a proposition with decorators and middleware.
@Gongreg i can access storyFn from decorators but storybook's addons are not their use in my opinion. It's what confuse people about addon in storybook. They shouldn't be in the stories at all.

I won't change the api of the addon JSX for a temporary fix that breaks the plugin for older version.

Well, like I said it is possible to offer both APIs, so it's not a breaking change.

@wcastand , so ok, we can both agree that there are problems with current addons implementation.
But having to explicitly tell in every story that you have to use your addon (addWithJsx) while limiting other addon usage is not a solution too :) Also your api doesn't allow me to say "use this addon in all the stories and I don't care about it at all anymore".
At least having as an option, to add it as a decorator would be a nice step forward.
Then you could definitely add it to monorepo, since it would be compactible with other plugins.

English is not my native langage so i'm sorry if i sound "bad", it's not the case and i don't mind discussing it (just in case :)).
@tmeasday right now, i don't think it's a good idea but if someone want to make that happen and do a PR i don't mind helping him and publish it :)
@Gongreg It's not a solution right now. That's why i started to bring the need to rework the addon API in the first place.
the API proposal that i made allow storybook wide decorators and middleware (so you can configure a redux decorator and a JSX middleware for all of your stories) Draft
Why i think it's a bad idea to make my addon and all the addon using the decorator pattern as a temporary fix for storybook ?
Because the temporary fix will probably become the permanent solution if everything work even if it means blending decorator specific to your app et decorator specific to storybook panels(middleware).
I prefer to have a none perfect solution for a while and work on a rework so we go on good basis instead of making something work right now and never change it because it works.
it's only my opinion and i get it if people doesn't agree but i work like this:

make it work
make it right
make it fast

For me storybook is 'make it work' (it works really well :D). Putting storybook in a monorepo, using a proper namespace is a way forward the make it right and a rewrite ( at least partial ) is for me the next step.
The rework of the Addon API is needed (in my opinion) because the addon API doesn't fit the use and like everyone here said : it's not clear and well defined what is a decorator or how do i make a storybook panels without polluting my stories or overwrite.add (not possible if you want to access storyFn).
I think we can agree on the api and make it quite quickly, it probably won't be perfect but we can iterate.
In short, if someone wants to make JSX works with decorators i'll help him and i'll add it to the package as a 'temporary solution' but i won't do it myself because i think it's not a good idea until we figure it out the new addon API.
i'm on storybook's slack if you want to discuss with me and avoid pollute this issue with not so related content.

I'm happy to contribute a PR. I'll send it through in the next couple of days.
I think generally I agree with you @wcastand except on one point; I would argue that .addWithX doesn't "work" (IMO) and we need to resolve that problem before we make it right :)

What about having an official addWith API, that allows you to compose different addons together:
Single Addon
story.addWith(info('Description of this component for the info addon'))(
  () => <Component />
)

Composes Multiple Addons
story.addWith(
  info('Description of this component for the info addon'),
  jsx('This is for the JSX addon')
)(() =>
  <Component />
)

Or even having that logic implemented on the existing add method.

@lucasmotta it's interesting because this is very nearly possible with the current API, you could have
story.add('name',
  info('Description of this component for the info addon')(
    jsx('This is for the JSX addon')(
      () => <Component />)));

In the current API. The only thing I would propose is to enable moving the decorators together (which ends up being similar to your idea):
story.add('name', () => <Component />), {
  decorators: [
    info('Description of this component for the info addon'),
    jsx('This is for the JSX addon'),
  ],
});

(This way treats the decorators a little less specially and allows room to grow and add other options later).

This is an old issue, and I'm not sure exactly where it stands or if it's still planned to be changed.  But as a new storybook user, I have to say that I find the current behavior very useful.  I am implementing storybook as a kind of "styleguide", and this addon allows me to easily create a "page" for each component with some vital information like a generic description, example code, and prop types.
I only bring this up to provide a voice in support of keeping this in the preview area.  I love being able to tweak knobs and see how the example component updates, while also seeing the rest of the info that this add-on provides (without having to toggle between add-on tabs).

Perhaps it should be optionally in a tab.
As it is, if you use storyshot with or without images, this addon has to be disabled.
If not, any change to your docs causes a 'change' as the snapshot has all the info in it.

Has there been any additional movement on this? I'd be interested in helping out, but I'd want to get some clear acceptance criteria before sinking time into it.

Definitely needs some docs for using the pure docgen plugin. The only one i could find for typescript I could not get to work. Whereas the info plugin works fine

I've published storybook-addon-react-docgen. It uses the docgen information just like the info addon but places the information in a Props tab in the the addons panel. It works quite well with the notes notes-addon
https://www.npmjs.com/package/storybook-addon-react-docgen

@shilman Is there plans to implement this? I'm running into this problem where the addon info button is blocking parts of my component preview and would love for this data to appear in the addons panel.

@jamesives Yeah it's been on the back burner for a long time but I have a prototype running and plan to release it in 5.1. we're putting a focus on component documentation now that 5.0 has been successfully released

Excellent! Is there an ETA for that release?

Hopefully we can get that feature  available in  prerelease by mid-April and a solid first cut by May

@JamesIves --> you can define this in the configuration of the info addon as well: e.g:
addDecorator(
    withInfo({
      styles: {
        button: {
          base: {
            fontFamily: 'sans-serif',
            fontSize: '14px',
            fontWeight: '500',
            display: 'block',
            position: 'fixed',
            border: 'none',
            background: '#14558f',
            color: '#fff',
            padding: '5px 15px',
            cursor: 'pointer',
          },
          topRight: {
            bottom: 0,
            right: 0,
            top: 'unset',
            borderRadius: '5px 0 0 0',
          }
        }
      }
    })
  );

Thanks @avrilpearl ! This is a great workaround.

Do we have any news about this @shilman?

@inspiratweb Addon-docs has been in alpha for over a month and is nearing beta. It solves a ton of problems with addon-info and adds a bunch of new features as well.
Read about it here: https://medium.com/storybookjs/storybook-docs-sneak-peak-5be78445094a
And get started here: https://docs.google.com/document/d/1un6YX7xDKEKl5-MVb-egnOYN8dynb5Hf7mq0hipk8JE/edit?usp=sharing

FYI addon-info is being superceded by addon-docs, which fixes a bunch of bugs and is easier to maintain. It’s reached release candidate (RC) status and will be properly released soon. Please give it a try! https://medium.com/storybookjs/storybook-docspage-e185bc3622bf
@kevin940726 @kohlmannj @zillding @ajwhite @ranneyd @dslounge @lucasmotta @seanking11 @jeffmicklos @igor-dv @evenchange4 @DimaRGB @levithomason @saponifi3d @L0stSoul @clementallen @louisfly @mariosanchez @tourshi @charlieclark @jalooc @nickarora @vincenthirtz @lb- @denkristoffer @mrjackdavis @zolk @patrick-gill @bmson @mindtricksdev @ruxiang05 @joshsylvester @christiannaths @keyboard-clacker @feyssericAzalead @Gidgidonihah @lslima91 @sapkra @kangax @wyattdanger @andriichumak @kylemh @ewolfe @svict4 @gautier-lefebvre @jack-sf @MihaChicken @charrondev @bradfrost @motanelu @aurerua @jmarceli @kngroo @Leko @sellsjonathan @iannbing @BenRichter @snnsnn @leoyli @Lehakos @Jimmerz28 @josephfusco @JeffersonCarvalh0 @airtonix @JasonTheAdams @JamesIves @UlanaXY @d4rekanguok @zachguo @fnhipster @maddesigns @techieshark @gwyneth-bassett @bryancuster @MarcoDaniels @DesignByOnyx @jakubriedl @inspiratweb @hsz @kaitlynhova @mthuret @will-stone @kroeder @polem @char0n @Gongreg @bigassdragon @jonyeezs @wcastand @bolonio @brunoreis @thearegee @tomhuze @tmeasday @nutgaard @UsulPro @MrOrz @otorrillas @josephdonnelly @IanVS @waynebrantley @ndelangen @strothj @Geril @hipstersmoothie @chrisvxd @3ddmoo @gehtman @storywr @Pickra @drewdecarme @CPedrini @petermooibroek @crutchcorn @binomialstew @avrilpearl @edmulraney @dmahnkopf @jpvincent @haldunanil

This is the most up-voted issue in the Storybook repo and I'm closing it. If anybody wants to pick this up, feel free to create a PR.
For those who care, here's the full explanation:

addon-docs is the successor to addon-info. For the past few months, I've been redirecting all addon-info-related issues to addon-docs.
addon-docs contains a superset of addon-info's features, and also contains many bugfixes.
addon-docs should be better than addon-info in every way. If you disagree, please feel to file an issue, and we'll do our best to fix it. It should be an attractive, painless upgrade, and if it's not it means that we're doing something wrong.

Thanks for using addon-info; please upgrade to addon-docs today!

It would be wise to redirect from the Info addon to the Docs addon in the Info page on Github, or warn about the deprecation in some sort of way there, just so that people know that the Info addon is not being supported anymore and that they should use Docs instead, and avoid wasting time trying to make it work.
FYI, installing the Info addon breaks storybook (it removes react from node_modules)

@DiegoBM done. thanks!


Add jump search

Have you read the Contributing Guidelines on Pull Requests?
Yes
(Write your answer here.)
Description
I have added an algorithm for Jump Search in C
(Write your answer here.)
Checklist

[x] I've read the contribution guidelines.
[x] I've checked the issue list before deciding what to submit.
[x] I've edited the README.md and link to my code.

Related Issues or Pull Requests
#2233
(Write your answer here.)

@muthuannamalai12 Are you working on this?

@muthuannamalai12 Are you working on this?

Yes I am working on it

Closing this because of no updates


Modify the Oppurtunities cards to look better

Kindly, assign me to this issue
Thanks

@ronitblenz Are you working under JWOC?

Yes, I am

Yeah sure, assign me

Kindly check and merge me PR

I have done the responsive thing, as directed, Plz merge my pr


Remove only delete info on index but fetch always show them

I deploy my chart
helm gcs push my-chart-0.0.1.tgz my-repo

After that i fetch it
helm fetch my-repo/my-chart --version 0.0.1

All is good.
But now i want to delete it;
helm gcs remove my-repo/my-chart

On my index, it is removed but tgz file always exist.
And fetch always see it.
is it possible to fetch chart only if it is present on index?
And add option on remove to force delete tgz?

Hi @sebglon,
I can't reproduce this issue. Does it happen every time for you?
Could you run helm gcs remove my-repo/my-chart -d please ? The -d flag is available since 0.1.3, you may need to update the plugin:
$ helm plugin gcs update
$ helm gcs version
version: 0.1.4
commit: 519b95ca3d0bde2ac1654ecb6b4995663b2a2eb5
date: 2018-03-20T22:47:57Z

Hi @nouney ,
I always have an error with fetch cmd
I want to fetch latest release.
If i list all chart version available, i can see  version 1.0.0
$ helm search akeneo-charts/onboarder -l
NAME                   	CHART VERSION  	APP VERSION	DESCRIPTION
akeneo-charts/onboarder	1.0.0          	1.0.0      	Akeneo Onboarder package
akeneo-charts/onboarder	1.0.0-PR-7     	           	Akeneo Onboarder package
akeneo-charts/onboarder	0.0.9          	           	Akeneo Onboarder package
akeneo-charts/onboarder	0.0.4-CLOUD-594	0.0.22     	Akeneo Onboarder package
akeneo-charts/onboarder	0.0.3-CLOUD-594	0.0.22     	Akeneo Onboarder package
akeneo-charts/onboarder	0.0.2-CLOUD-594	0.0.22     	Akeneo Onboarder package
akeneo-charts/onboarder	0.0.1          	0.0.24     	Akeneo Onboarder package

But when i want to fetch latest chart release, i have an error if i not set --version
$ helm fetch akeneo-charts/onboarder --debug
Error: storage: object doesn't exist
Usage:
  helm-gcs pull gs://bucket/path [flags]

Flags:
  -h, --help   help for pull

Global Flags:
      --debug                    activate debug
      --service-account string   service account to use for GCS

Error: plugin "pull.sh" exited with error


GEODE-5960: Add test to verify JDBC gfsh commands load properly

Added a new test to the JDBC connector project to verify that the list
of commands loaded via the scanner and the command marker match the list
of commands found via these two sources. This is to avoid
errors/warnings due to commands which appear in Command Marker files but
don't have available source code.
Co-authored-by: Ben Ross<EMAIL_ADDRESS>Co-authored-by: Darrel Schneider<EMAIL_ADDRESS>Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

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

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

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

[ ] Does gradlew build run cleanly?

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

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. If you need help, please send an
email to<EMAIL_ADDRESS>

I am not sure what this test is for. the commandManager actually uses the package scanner to scan the classpath to compose its list of commands, so the test is just reiterates what the commandManager is doing. So if a command did not implement CommandMarker, this test would still pass, I believe.

@dschneider-pivotal now I see that this test is to make sure all commands defined in the commandMarker file is able to load, then you don't need to scan the packages to get a list of all the commands at all, you can just get the list of commands loaded by service loader and make sure they exists in the command manager, this can make your test a lot shorter. Something like this:
ServiceLoader loader =
ServiceLoader.load(CommandMarker.class, ClassPathLoader.getLatest().asClassLoader());
loader.reload();
Iterator iterator = loader.iterator();
List<Class>
    allCommandClass = commandManager.getCommandMarkers().stream().map(CommandMarker::getClass).collect(
    Collectors.toList());
while (iterator.hasNext()) {
  Class<? extends CommandMarker> commandClass = iterator.next().getClass();
  assertThat(allCommandClass).contains(commandClass);
}


Consider sorting components in palette for consistent display

Is your feature request related to a problem? Please describe.
With threading now implemented to read and parse component definitions, the order in which the components are rendered may change depending on the order in which threads execute.
Describe the solution you'd like
Discussion is needed to determine where the sorting should be done.
Describe alternatives you've considered
We can also consider just leaving it as-is as a visual for when components are updating.

Seems now broken in master:

I believe sorting is currently performed in a case sensitive manner, whereas it should not. e.g. 'load data' == 'load dATA'


Custom environment creation in AML with build-arg

Is your feature request related to a problem? Please describe.
According to the docs of creating an env. from a docker build context

Instead of defining an environment from a prebuilt image, you can also define one from a Docker build context

from azure.ai.ml.entities import Environment, BuildContext
env_docker_context = Environment(
    build=BuildContext(path="docker-contexts/python-and-pip"),
    name="docker-context-example",
    description="Environment created from a Docker context.",
)
ml_client.environments.create_or_update(env_docker_context)

Meanwhile, in the specified Dockerfile, build-time arguments cannot be passed in like what we do with docker build --build-arg.  This blocks using CI-JOB-TOKEN inside CI jobs to authenticate for e.g., installation from private package registries using poetry and any other settings requiring credentials.
Describe the solution you'd like
Add --build-args to the class BuildContext so that we can pass in respective built-time arguments.
Describe alternatives you've considered
Include all credentials in the Dockerfile, but this is apparently a bad idea.
Additional context
Add any other context or screenshots about the feature request here.

Thank you for the feedback @ZhiliangWu . We will investigate and get back to you asap.
cc @azureml-github

@kashifkhan Thanks for your reply. I think technically this shouldn't be a big implementation as you are under the hood using docker build to build the images. I really hope to see some progress on this.

We'll look into that. That is a pretty big feature unless we don't care about security aspect of exposing the secrets/tokens. Otherwise with the same success you can hardcode them into context. Other aspect is reproducibility, assuming we store just a reference to user secrets/parameters, how to make sure that we invalidate the cache once the value is changed.

We'll look into that. That is a pretty big feature unless we don't care about security aspect of exposing the secrets/tokens. Otherwise with the same success you can hardcode them into context. Other aspect is reproducibility, assuming we store just a reference to user secrets/parameters, how to make sure that we invalidate the cache once the value is changed.

Hi @vizhur, thanks for your reply.
It would be a really necessary feature for CI jobs from my perspective.
For GitLab CI jobs, the security issue is not that big, as the CI/CD job token is only valid during the pipeline time. That's why we need to be able to assign it dynamically instead of hard-code them in the DOCKERFILE.  The reproducibility remains as long as we build the environment using the same CI setup.
Apart from that, there are also several use-cases within an enterprise environment. I.e., we can use --build-arg to pass some (dynamic) enterprise proxy information into the docker build process. Otherwise, we must hard-code this information in the DOCKERFILE.

@ZhiliangWu it is indeed a very useful feature. We'll look into that and try to prioritize, can't promise any short-term solution though. We'll create a feature request on our end.


Ts-jest is failing to locate the tsconfig when being run from inside yarn workspace (or lerna)

Issue
ts-jest is failing to locate the tsconfig when being run from inside yarn workspace (or lerna)

More info:
ts jest is looking for tsconfig from the node_modules he is installed it and up.
In yarn workspace/lerna usually it will be hoisted to the top level directory of the project.
See:
https://github.com/kulshekhar/ts-jest/blob/7b15180e4a6f1f7903ff1e5fcefb40dbc52a9370/src/utils.ts#L116-L129

jest is also get hoisted, but still it manage to find the correct package.json

Expected behavior

ts-jest should be able to pick up the tsconfig inside it

Link to a minimal repo that reproduces this issue

https://github.com/Bnaya/issues-repros/tree/ts-jest-and-monorepo
clone
run:
yarn install
yarn workspace foo test
or
cd packages/foo; yarn test;

@Bnaya I've sent a PR to the repo (differences)
Let me know if this works for you

it will work, but beats the propose, i don't want to create tsconfig for tests
ts-jest should be able locate the tsconfig.json

More research:
Jest is using process.cwd() as his starting point to look for the package.json
https://github.com/facebook/jest/blob/d62a7e0edfec556758e1c0e23158e4ce4ac84e91/packages/jest-runtime/src/cli/index.js#L60-L68
https://github.com/facebook/jest/blob/e04e45102b3ebe486462d45db656f9b47f0e70e1/packages/jest-config/src/index.js#L18-L26

Here are some issues:

Node doesn't understand import/export so it during testing, we need to use commonjs module. If module isn't set explicitly in tsconfig, ts-jest sets it to commonjs. However, if it is set, ts-jest doesn't override it - you'll have to do so using a custom tsconfig. We can't blindly override it to commonjs because, iirc, the babel related stuff that was added a while back needs it.

In a mono repo, when ts-jest is installed  at the root and not in the sub packages, I'm not sure how to find the relevant tsconfig unless it is set in package.json via tsConfigFile.

If there are PRs or suggestions on how this can be improved, they're very welcome. However. as things stand, I think this is the best solution.

@kulshekhar see my last comment, we can mimic jest behaviour

@Bnaya if your suggestion is to use process.cwd() to modify how getStartDir behaves, it sounds good to me. I'd welcome a PR for that.
However, that still doesn't address the first issue I mentioned in my comment above

I'm not 100% sure, but it seems to have introduced a regression on how ts-jest locate tsconfig on normal npm projects.
I have got the following error with<EMAIL_ADDRESS>"Cannot read file '/tsconfig.json': ENOENT: no such file or directory, open '/tsconfig.json'."

After seeing this issue I tried downgrading to<EMAIL_ADDRESS>and everything is working fine now.

@simbas can you open a new issue with a minimal repo that reproduces this? If this can be confirmed, I'll revert this change and take a look at it again

@simbas i made this branch and its seems to work ok
|https://github.com/Bnaya/issues-repros/tree/ts-jest-regular

+1 - experiencing this exact issue right now.

@Bnaya thanks for making that branch.
@simbas @GantMan Without a minimal repo, it'll be hard to understand the exact issue you're facing. New issue(s) with a minimal repo would go a long way in helping debug/fix your issues

@kulshekhar - I have a small repo, but not minimum.  Let me see if I can present my open source project as a litmus test.  I just recently switched it over to 100% TS for proper coverage.
Here's my CI failing:  https://semaphoreci.com/ir/solidarity/branches/feature-upgrade_solidarity_rules/builds/4
I then added this code, which seems redundant:
https://github.com/infinitered/solidarity/pull/83/commits/c11460bff4ae9fc47ac205e972dc84520ad8f329
Here's my CI passing: https://semaphoreci.com/ir/solidarity/branches/feature-upgrade_solidarity_rules/builds/6
Things worth noting

it's non-deterministic when this starts to fail
I'm working on two different OSX machines, both of which have this issue at times with this project
I have --no-cache to be extra sure
Travis CI passed these two builds I linked above.  It was only Semaphore that failed.

@GantMan thanks for sharing that. I was able to reproduce this issue using your repo.
I've pushed in a fix (#350) but will have to wait for someone to review and approve it before it can be published. I'm reopening this issue in the meanwhile.

@GantMan you are changing the working directory in your code, this is why it fails
https://github.com/infinitered/solidarity/blob/master/__tests__/integration/solidarity-check/check-invalid.ts#L7
beforeAll(() => {
  const tempDir = tempy.directory()
  process.chdir(tempDir)
})

Try adding cleanup step and change the working directory back

@Bnaya thanks for pointing that out. If that's the only reason then the PR is not needed.
@simbas Do your tests change directories too? If not, would it be possible for you to create a minimal repo with your setup?

@kulshekhar IMO this bug is about yarn workspace projects, and this issue is resolved and can be closed.
If the fix have caused a regression, it should be reported as a new issue, with a reference to this one, and the PR

If the fix have caused a regression, it should be reported as a new issue, with a reference to this one, and the PR

fair enough

@kulshekhar - That's not the only reason.  With or without that test the issue exists.  I believe I only recently added that test.


Gracefully fallback when no internationalization/duration features needed

We need to remove hard dependency on external scripts like moment, humanize duration etc.. We should gracefully fallback or warn if those features are requested/used without including those scripts.

bower_components/momentjs/min/moment.min.js
bower_components/momentjs/min/locales.min.js
bower_components/humanize-duration/humanize-duration.js

Update comment

@polomarcus - Let me know what you think of this issue.

Good idea, I will try to work on this soon.

Hi @siddii,
TL;DR : we should keep momentjs dependency at anytime and we can make humanize duration dependency optional
Why?
For MomentJS
If we do this, I can see 2 options :

We get rid of the MomentJS dependency. We would have to use Date, like before everywhere moment() is called. Example : https://github.com/siddii/angular-timer/blob/master/app/js/_timer.js#L256
We implement a custom momentJS to keep moment().diff() inside the code when MomentJS is not available.
If a new feature using momentJS appears, we would need to write it in our custom momentJS.

I think we should not do this, but that's just my opinion:

MomentJs (158Kb) is quite light.
Using momentJS, a known library, can help future contributors writing PR.
For the retro-compatibility, the users still can uses the older versions (https://github.com/siddii/angular-timer/tree/v1.2.1) or can see the new requirements to update their project : https://github.com/siddii/angular-timer#requirements

For Humanize Duration
The variables secondUnit, minuteUnit etc. containing the translated duration will not be initialized when Humanize Duration is not available.
This line will contain an if(humDurationHere) to initialize them or not
https://github.com/siddii/angular-timer/blob/master/app/js/_timer.js#L205
FYI, The i18nService.js with Humanize Duration can be momentJS free.
Pro :

Can be done pretty easily
Con :
It might upset users to make them install bower install humanize-duration manually if they need it
Very light (12Kb)

Do not hesitate to discuss about this

@polomarcus - Thanks for the write-up!
I think the biggest thing I am trying to avoid here is not to have 3 installs (or script includes) (angular-timer, momentjs, humanize-duration) to start using this module. My understanding is that we can make HumanizeDuration optional(?) easily, whereas momentjs is not that straight forward.
OK, I'll throw out something & see what you think... How about we build a distribution script called angular-timer-all.js which includes all the dependencies (obviously checking if moment exists provide one, so as humanize duration etc.) and its up-to the developers to choose whether they want to pull just the angular-timer or not. In that way, we can have a simple integration rather than three different includes.
Let me know...

@siddii,
This solution would be great for people using manually downloads. We cannot have a choice between angular-timer-all.js and the other file when we use bower install angular-timer, don't we?
When doing a bower install, the users would still need to include the angular-timer, momentjs, humanize-duration scripts in their build.config.js for example.
If we choose the "all" scripts in bower, the users won't be able to use their specific version of momentjs.
build.config.js example:
vendor_files: {
    js: [
      'vendor/angular/angular.min.js',
      'vendor/moment/min/moment-with-locales.min.js',
      'vendor/humanize-duration/humanize-duration.js',
      'vendor/angular-timer/dist/angular-timer.min.js',
    ]

The only affected files would be Gruntfile.js


Proposal to Add a Data Prevention Chat App Using BERT for Real-Time Nudges

Hello, I would like to contribute an app to the awesome-llm-apps repository. This app is a Data Prevention Chat App designed to safeguard against unintentional data leaks during conversations. Key highlights include:

Purpose: The app monitors chat content in real-time and uses a fine-tuned BERT model to classify and detect sensitive information.
Features: When potentially confidential data is detected, the app triggers real-time digital nudges to the user, promoting better data awareness and security.
Technology: Built with Python using Streamlit for an interactive front-end and BERT for NLP classification, ensuring efficient and scalable data processing.
Value: This app aligns with the repository's focus on practical LLM applications by demonstrating a real-world use case of NLP models for proactive data protection and user education.

If this aligns with the goals of the repository, I am ready to create a pull request with the full code and a detailed README.md file.

This sounds interesting and super valuable.
Would love to see it in action and happy to add that to this repo and share it with the wider audience.
@Madhuvod from the Unwind AI team can help you with any questions you have or incase you need a partner to brainstorm.

yes definitely, @krishkpatil let me know if you're still down to make the contribution

Hi @Madhuvod inspired by the projects on this repository I had created a project for a hackathon submission, I'd love foor you to check it out link


Add quantization support for BackboneWithFPN

🚀 The feature
Add quantization support for BackboneWithFPN.
Motivation, pitch
Currently, it is possible to use from torchvision.models.detection.backbone_utils.resnet_fpn_backbone/BackboneWithFPN in order to produce a backbone fpn network, given some sort of network that can produce features.
While the original resnet/other base networks you want to use (ex. efficientnet), have quantized variants supported (with pretrained weights too), it would be nice to support QAT in the context of FPN networks, to speed up the detectors even more.
Alternatives
No response
Additional context
No response

@ntakouris Thanks for the recommendation. Yes that's true, we should provide better support for it.
The PyTorch core team has recently changed the API for quantization (FX-based see here). The feature is still new, so hopefully on the near future once it becomes more stable we can dedicate time to investigate and provide a solution.

The other thing that would be good to have, would be to ensure that those new quantized models can actually be exported to ONNX/TensorRT efficiently (with int8 weights).
I am not sure if this is out of scope/too much to ask, as this functionality would be dependent on any possible breaking change at onnx/nvidia's side.


No 'scan' button if you go through walletConnect -> Sequence

instead of social log in, go through WalletConnect, and either click 'Sequence' or search for Sequence, and then, no scan button on top level of Glo App

Thanks for reporting @setgree ! Unfortunately, however, this is intentional and a side-effect of how walletconnect works. This cannot be changed.


WIP: Perform Edugain related tasks via API

Support need tech to SSH into this service on a semi-regular basis to run simple rake tasks. This doesn't suit either team. It creates needless double-handling and longer feedback loops.
This PR improves the situation by exposing the relevant logic via API. Rather than drop the appropriate info into a ticket, support can pass it to curl and bypass the middlemen.
Works towards https://github.com/ausaccessfed/stockpile/issues/91
Adoption
Shipping a few endpoints without telling anybody won't be much help. Once deployed, we'll need to do some followup:

Generate API credentials for support and put them in 1pass
Document the new endpoints
Next time a relevant ticket is assigned to us, work with support to resolve it via API
Improve documentation
Repeat 3 and 4 until we're no longer needed

@trsau where would be a good spot to drop docs for this?


feat: Added common tasks for installing operators

feat: Updated dep versions and added CreateNamespace common function.
Added TaskBuilder functions for some common tasks.
Added start of pipeline with installing operators.

Fixes #

Does "export * from './commonpipelines';" need to be added to the index.ts?
It couldn't find InstallFromIBMOperatorPipeline when I tried it locally.

Does "export * from './commonpipelines';" need to be added to the index.ts?
It couldn't find InstallFromIBMOperatorPipeline when I tried it locally but I might have done something wrong getting it set up.

No, let me get the instructions for testing finished up. I'll post them in the comments here. Thanks, @David-M-IBM !


Improve docs for custom login theme feature

Purpose
This PR improve docs for custom login theme feature

Closing this PR to WIP as the changes have been committed to master branch with https://github.com/wso2/docs-apim/pull/879


version 1.0.2 fails where 1.0.1 is working

Hi, this library is great and is working well for me. However, version 1.0.2 has stopped working. 1.0.1 was fine for me. The symptoms are a blank area where there used to be a chart when viewing this page:
https://github.com/the-james-burton/atacama/blob/master/app/scripts/controllers/direct.js
Sorry this is a bit vague but I don't have much more information at this stage.
A rollback to 1.0.1 (as the only change) and it starts working again.

I'm having a similar issue. Looking at the release notes, it looks like this might be causing it:

Set deepWatchData to false by default
Added deepWatchOptions and deepWatchConfig properties

I should add, that I went to 1.0.3 and solved this by re-enabling full refresh
<nvd3 data="..." options="..." config="{refreshDataOnly: false}" />

Interesting. I will give it a go, thanks.

Yes, I got on to 1.0.3 with your help, thanks! For me it was this in the config that did it...
    $scope.config = {
      deepWatchData: true,
      refreshDataOnly: false
    };


[Select] Support event target value

closes https://github.com/mui/material-ui/issues/36946

[ ] I have followed (at least) the PR section of the contributing guide.

See https://github.com/mui/material-ui/issues/36946#issuecomment-1532051678


Spevacus: Watch camdotietkiem.vn

Spevacus requests the watch of the watch_keyword camdotietkiem\.vn. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

camdotietkiem\.vn has been seen in 2 true positives, 0 false positives, and 0 NAAs.

Approved by Makyen in Charcoal HQ


Camera 2D Framed issue #372

Actualizing _follow_framed_offset when on only one side of the frame.

Looks good to me!
Thanks for the PR :tada:


Tell users to try with '--reset' when we can't find apps, orgs, or stores

WHY are these changes introduced?
We store information about apps using conf. But if the user deletes their app from the local filesystem and from the partners portal, they can get in weird situations where the api key that we cached is no longer valid.
WHAT is this pull request doing?
Tell users that they can retry their command with --reset which should solve their problem.
How to test your changes?

Create a new app and run pnpm dev
Press p to preview it
Now go to your partners portal and delete the app
Run pnpm dev and you should see a message that tells you to rerun the command with --reset

Measuring impact
How do we know this change was effective? Please choose one:

[x] n/a - this doesn't need measurement, e.g. a linting rule or a bug-fix
[ ] Existing analytics will cater for this addition
[ ] PR includes analytics changes to measure impact

Checklist

[x] I've considered possible cross-platform impacts (Mac, Linux, Windows)
[x] I've considered possible documentation changes
[x] I've made sure that any changes to dev or deploy have been reflected in the internal flowchart.

Fixes https://github.com/Shopify/cli/issues/1544


Update the document, ignore the IDE files

Thanks for your suggestions. @feeblefakie Please take a look when you have time.

@thongdk8 Thank you for creating the PR.
Please set the appropriate name to the PR. (Update is definitely not good since we can't know what the PR is about :) )

@feeblefakie Thanks for your suggestions. I'll fix it.

Thank you!


Exam: Fix individual student exam working time update setting an incorrect duration

Checklist
General

[ ] I tested all changes and their related features with all corresponding user types on a test server.
[x] This is a small issue that I tested locally and was confirmed by another developer on a test server.
[x] Language: I followed the guidelines for inclusive, diversity-sensitive, and appreciative language.
[x] I chose a title conforming to the naming conventions for pull requests.

Client

[x] I followed the coding and design guidelines.
[x] I added multiple integration tests (Jest) related to the features (with a high test coverage), while following the test guidelines.

Motivation and Context
Bug noticed by @FlorianGlombik in https://github.com/ls1intum/Artemis/pull/4535#pullrequestreview-838805920.
Description
The current form saves the working time in minutes, but it is actually in seconds. Therefore, the displayed duration was wrong.
Steps for Testing
Prerequisites:

1 Exam

Go to a student exam.
Change the working time. It should be displayed correctly after the update as hours and minutes.
Optional: Also check the network traffic when refreshing the page for the JSON with the student exam (API-endpoint /api/courses/$courseId/exams/$examId/student-exams/$studentExamId). The workingTime field there contains the total number of seconds of working time. This should match the values displayed in the UI.

Review Progress
Code Review

[ ] Review 1
[ ] Review 2

Manual Tests

[ ] Test 1
[ ] Test 2

Test Coverage
unchanged
Screenshots

In the student exams review the Working time should be displayed in a different way in the Student exams view. It is still shown in the minutes and seconds format.

@FlorianGlombik Thanks for the review.
All the other dates displayed are done so by using the duration pipe. Therefore, the seconds are shown as well. I now updated the form when setting the working time to enable setting the seconds as well to stay consistent.
Before #4234 the duration could be set in minutes and seconds. This ability has now been added back in with the additional bonus of conveniently setting (the probably more frequently needed) hours.

Can we add a second option to edit the working time? In our university, students typically get an extension in % of the normal working time, e.g. 50%. It would be easier for the instructor to enter this value. The correct working time could then be calculated automatically based on the percentage value.
We should offer both ways next to each other. Changing one value will automatically update the other value. In the database, we finally store the time and not the percentages, so no change of the database would be necessary.
This percentage value could then also be displayed on other pages, e.g. in the student exams page after the working time, e.g. when the normal working time is 30min.

45 min (+ 50%)
30 min
48 min (+ 60%)
15 min (- 50%)

(the last one is only a theoretical example, which we should support, but which will probably never occur in reality)
Could you add this in this PR? Or should we add it in another one?

Can we add a second option to edit the working time? In our university, students typically get an extension in % of the normal working time, e.g. 50%. It would be easier for the instructor to enter this value. The correct working time could then be calculated automatically based on the percentage value.
We should offer both ways next to each other. Changing one value will automatically update the other value. In the database, we finally store the time and not the percentages, so no change of the database would be necessary.
This percentage value could then also be displayed on other pages, e.g. in the student exams page after the working time, e.g. when the normal working time is 30min.
* 45 min (+ 50%)

* 30 min

* 48 min (+ 60%)

* 15 min (- 50%)

(the last one is only a theoretical example, which we should support, but which will probably never occur in reality)
Could you add this in this PR? Or should we add it in another one?

I’d like this PR to only contain the bugfix for the broken input and then add the new feature separately, as at the moment the functionality to set individual working times for student exams is broken completely. That way the bugfix can be merged as soon as possible.


patch: Updated bank list from pocket

There's a format of the json and what you are adding is a different format thus won't work. Can you please check that out and help fix?

@imadu you kept the 6 digit codes for banks that have 3 digit code

@imadu you kept the 6-digit codes for banks that have 3 digit code

@uncoooloj  The six-digit codes are the NIP standard code from VFD and Bankly. Like for instance GT bank is 000013 for NIP but 058 on flutterwave and paystack. I was assuming we were going to make the codes NIP standard

Let's create bankCode and treat it separately from nipCode then


[GEP-18] Adapt seed cluster CA secret to new secrets manager

How to categorize this PR?

/area security
/kind enhancement
/merge squash
What this PR does / why we need it:
This PR adapts the seed cluster's CA secret to the new secrets manager.
Which issue(s) this PR fixes:
Part of https://github.com/gardener/gardener/issues/3292#issuecomment-1036058890
/invite @timebertt @BeckerMax
Release note:

NONE

/test all

@rfranzke How could I test this PR locally to verify the changes? I read GEP-18, but it's not immediately clear to me what part of the GEP this PR covers and how it could be tested.

When reconciling an existing seed with this PR the ca-seed secret in the garden namespace should get the labels for the secrets manager. Also, it should be marked as immutable and the certificate itself in the data should NOT be regenerated.

When reconciling an existing seed with this PR the ca-seed secret in the garden namespace should get the labels for the secrets manager. Also, it should be marked as immutable and the certificate itself in the data should NOT be regenerated.

After testing I can confirm the above is the case:
apiVersion: v1
data:
  ca.crt: ...
  ca.key: ...
immutable: true
kind: Secret
metadata:
  labels:
    checksum-of-config: "13464072588732984944"
    managed-by: secrets-manager
    manager-identity: gardenlet
    name: ca-seed
  name: ca-seed
  namespace: garden
  ...
type: Opaque