[$500] iOS -  Receipt replace popup camera click button is overlapping with home bar

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

Action Performed:

Create a request by scanning a receipt.
Go to created receipt.
Open the receipt details report.
Click on receipt image.
Click 3 dots menu icon and click replace.

Expected Result:
Camera click button should not overlap with native home bar.
Actual Result:
home button interfering with UI.
Workaround:
Unknown
Platforms:

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

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

Version Number: <IP_ADDRESS>
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/93399543/c4af3581-3380-44b1-a37e-4d60200afa7e
https://github.com/Expensify/App/assets/93399543/df659a1e-85df-4b30-89dc-b246d623466c
Expensify/Expensify Issue URL:
Issue reported by: @parasharrajat
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1695376096559109
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~0191bee1b0a882677e
Upwork Job ID:<PHONE_NUMBER>003328000
Last Price Increase: 2023-10-02

Proposal
Please re-state the problem that we are trying to solve in this issue.
iOS: Receipt replace popup camera click button is overlapping with home bar
What is the root cause of that problem?
We don't include safe area padding bottom to this screen
https://github.com/Expensify/App/blob/5aa7f6da94ddb1c8ca55a6cce714555f819c1dd0/src/pages/EditRequestReceiptPage.js#L31-L32
What changes do you think we should make in order to solve the problem?
We need to include safe area padding bottom by one of:

surround DragAndDropProvider content with <View style={[styles.flex1, safeAreaPaddingBottomStyle]}> like money request page do here to ensure DragAndDropProvider work fine in full screen height

<ScreenWrapper
    includeSafeAreaPaddingBottom={false}
>
    {({safeAreaPaddingBottomStyle}) => (
        <>
            <HeaderWithBackButton/>
            <DragAndDropProvider>
                <View style={[styles.flex1, safeAreaPaddingBottomStyle]}>
                    <ReceiptSelector/>
                </View>
            </DragAndDropProvider>
        </>
    )}
</ScreenWrapper>

Alternative simply remove prop includeSafeAreaPaddingBottom={false}

What alternative solutions did you explore? (Optional)
remove prop includeSafeAreaPaddingBottom={false}

drag and drop not cover the header will fix here https://github.com/Expensify/App/issues/28014

@mananjadhav do you agree? ^^

@laurenreidexpensify @mananjadhav
Why we will close this issue, I think it should fix.

drag and drop not cover the header will fix here https://github.com/Expensify/App/issues/28014

I am replying here to esh-g's proposal, not saying this issue will fix in other.
Sorry for not being clear.

@laurenreidexpensify
It would be great if you answered me here https://github.com/Expensify/App/issues/28145#issuecomment-1743468494
Thanks!

@laurenreidexpensify
This issue need to reopen again because it is different issue, and
https://github.com/Expensify/App/issues/28014 is already merged, but it is not including any fix for this issue.

@mananjadhav friendly bump.

Apologies for the confusion on closing the ticket. I was expecting the linked issue will resolve this change as well.
@ahmedGaber93's proposal looks good to me.
🎀 👀 🎀 C+ reviewed.

@NikkiWines bump please review and assign thanks

Agreed, @ahmedGaber93's proposal looks good!!

@mananjadhav PR https://github.com/Expensify/App/pull/29617 is ready for review.

Payment Summary:

C+ @mananjadhav does not require payment in Upwork ($500) (Eligible for Manual Requests)
Code Fix - @ahmedGaber93 payment in upwork ($500)
Bug report - @parasharrajat  does not require payment in Upwork ($50) (Eligible for Manual Requests)

Agreed @laurenreidexpensify. This is eligible for the urgency bonus.

$750 payment approved for @mananjadhav based on BZ summary.

@mananjadhav please complete checklist so we can close, thanks

We added EditRequestReceiptPage in this commit in this PR.
I've added a comment here. I don't think we need a regression test for this one.

$50 approved for @parasharrajat


Website "https://open-runtimes.com/" gives ERR_CONNECTION_REFUSED

Greetings
When I try to connect to the website https://open-runtimes.com I have an error ERR_CONNECTION_REFUSED.
Is that only for me?
Regards

The website is still not up yet, we just own the domain.

@eldadfux, it is a little weird to link our repo to a site that doesn't exist though. Perhaps we can have some sort of landing page? Or redirect it back to https://github.com/open-runtimes

@stnguyen90 agree, removed the link for now.


Pathology bundle update

Description
It fixes the log print in inference and update README.
Status
Ready/Work in progress/Hold
Please ensure all the checkboxes:

[x] Codeformat tests passed locally by running ./runtests.sh --codeformat.
[x] In-line docstrings updated.
[x] Update version and changelog in metadata.json if changing an existing bundle.
[x] Please ensure the naming rules in config files meet our requirements (please refer to: CONTRIBUTING.md).
[x] Ensure versions of packages such as monai, pytorch and numpy are correct in metadata.json.
[x] Descriptions should be consistent with the content, such as eval_metrics of the provided weights and TorchScript modules.
[x] Files larger than 25MB are excluded and replaced by providing download links in large_file.yml.
[x] Avoid using path that contains personal information within config files (such as use /home/your_name/ for "bundle_root").

/build

Hi @drbeh ,
Is this PR ready to review now?
Thanks for the quick update.

Hi @Nic-Ma, yes it is.


Character save is lost

Did RCON commands enable me to see all players' Steam IDs and unique identifiers? My friend's character encountered an issue, so I need to inquire about it."

Running showplayers through rcon will allow you to see all active player's name, playeruid, & steamid.

Thank you for your answer. Is there any way to see the steamid of inactive players? I only found this at the mount point of the Docker server. For example, I want to see the complete steamID of player 76205 even if he is not online.


Required parameters for a command does not exit.

I am returning promises for a command.

OK, so it goes into the prompt. How can I make it exit the prompt too?

Ctrl + C?
On Wed, 14 Dec 2016, 23:54 Gaurav C<EMAIL_ADDRESS>wrote:

OK, so it goes into the prompt. How can I make it exit the prompt too?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/dthree/vorpal/issues/202#issuecomment-267194053, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AK_dlPoaH1a6dqxhV6WeTjijq93xuz5Aks5rIIGagaJpZM4LNioa
.

This is related to https://github.com/dthree/vorpal/pull/200 cc @Shakyamuni177te


RBD resize implementation

Fixed some bugs while creating RBD.
RBD resize implemented

Signed-off-by: kamleshKumarVerma<EMAIL_ADDRESS>

@cloudbehl Please review it

it has too many conflict . going to send new pr for this implementation


feat(Examples): Update default TFT in KWS20_DEMO to use Adafruit 3315 instead of NewHaven for MAX78002

Pull Request Template
Description
The MAX78002EVKIT ships with Adafruit 3315 TFT as per default, which the PR takes into account.
Change: uncomment line 16 (TFT = ADAFRUIT) in project.mk
Checklist Before Requesting Review

[x] PR Title follows correct guidelines.
[x] Description of changes and all other relevant information.
[-] (Optional) Link any related Github issues using a keyword
[-] (Optional) Provide info on any relevant functional testing/validation.  For API changes or significant features, this is not optional.

Hi @oledreessen, actually the new production boards ship with the NewHaven TFT display.  There are still some older kits with the Adafruit display circulating around, but that display has gone out of stock.  So we'll want to leave the default set to the NewHaven display


npm ERR! Failed at the<EMAIL_ADDRESS>install script.

System information

node version: 8.11.4
npm or yarn version: 5.6.0
OS/version/architecture: macOS Monterey 12.3.1
Applicable nodegit version: ??

Trying to install some npm modules for job, and I am constantly getting this error. Any help?

I've heard some ppl saying about incompatibility between old node version (in my case 8.11.4) and Mac M1, and for that they solved changing the arch of terminal from arm64 to i386. Anyway, I've tried to install nodegit in both architectures, but no success.

Log below:

2022-04-15T20_35_17_595Z-debug.log

<EMAIL_ADDRESS>is very old, try the latest alpha and see if you get the same issue.


Natasha

Updated shopping list button to display on a new window, added a counter to how many ingredients are on the list,  update the name that will display from checking the check box

I am not sure if the print is too small for the "Check to add to shopping list" but I did not want the words to be too big either.


Add playwright integration testing to the app

This PR allows us to code playwright integration tests that can potentially replace some of our manual tests and allow us automated testing of the app itself.
Current technical limitations:

No app level keyboard simulation support (e.g, zoom in, zoom out, etc.)
No code coverage support, so even though we are testing the app, the code coverage does not reflect this fact

All comments should be addressed now.

@TheCleric looks dope; merged. Thanks, that's extra awesome stuff. Always glad to have more tests, especially when it replaces manual tests.

@TheCleric looks like there's a Playwright test that is either flaky or never ends, can you take a look at it? See https://github.com/nativefier/nativefier/runs/6118520796?check_suite_focus=true for the last run (run 3) that had been running for 2h before I cancelled it, and the top-right dropdown to access the previous runs (1 & 2) that failed.

Bizarre. I can't seem to reproduce it locally (and nothing really changed that should cause this). I'll try some things and see what may be going on.


Add setting to disable markdown rendering

For those clients such as emacs that do not support it.

This would also be relevant for Neovim/Vim and its LSP support.


OutOfMemory and various CreationError s don't implement Error trait

Short info header:

GFX version: 0.4.0
OS: Any
GPU: Any

We aren't implementing Error for anything at the moment. Could you describe the use case that requires it?

@kvark Amethyst needs upcasting to dyn Error


Add dummy implementation to work this as a danger plug-in

Danger has errored
[!] Invalid Dangerfile file: undefined local variable or method suggestion for #<Danger::Dangerfile:0x00000002a16f10>
 #  from Dangerfile:1
 #  -------------------------------------------
 >  suggestion.lint
 #  -------------------------------------------

  Generated by :no_entry_sign: Danger

Danger has errored
[!] Invalid Dangerfile file: undefined local variable or method suggestion for #<Danger::Dangerfile:0x00000003688ca8>
 #  from Dangerfile:1
 #  -------------------------------------------
 >  suggestion.lint
 #  -------------------------------------------

  Generated by :no_entry_sign: Danger


Storage account client with TokenCredential hangs

My changes https://github.com/Azure/azure-sdk-for-rust/pull/757 seem to cause a hang in Vector when managed identity is used. It hangs when requesting the token from the IMDS: https://github.com/Azure/azure-sdk-for-rust/blob/490d34b7a51af853ec2c39eb5820fae0a44dcc4d/sdk/identity/src/token_credentials/imds_managed_identity_credentials.rs#L125
The log "starting new connection:" is the last thing I see before it hangs: https://github.com/seanmonstar/reqwest/blob/8b37ae4b15f668e3e3f9b8cf43b547fc4f95e444/src/connect.rs#L560
I think this has something to do with that Vector calls it from a async method, which calls a sync method (prepare_request of sdk), which call a async function again (get_token of sdk).
Example call in Vector: https://users.rust-lang.org/t/simplest-possible-block-on/48364/29
This seems to be problematic according to this post: https://users.rust-lang.org/t/simplest-possible-block-on/48364/26
But I couldn't verify it's actually the case.
To verify it I tried to remove block_on by making prepare_request async but I'm running into compile errors here: https://github.com/yvespp/azure-sdk-for-rust/blob/86ebddbbb80f4527cd6d99c40b714957ff2d6a68/sdk/storage_blobs/tests/blob.rs#L380
generator cannot be sent between threads safely
the trait `Sync` is not implemented for `dyn Fn(http::request::Builder) -> http::request::Builder`rustc
blob.rs(330, 42): required by a bound in `requires_send_future`

And also while compiling Vector:
make build
cargo build --release --no-default-features --features default
   Compiling vector v0.23.0 (/home/azureuser/vector)
error: generator cannot be sent between threads safely
  --> src/sinks/azure_common/service.rs:43:9
   |
43 |         Box::pin(async move {
   |         ^^^^^^^^^^^^^^^^^^^ future created by async block is not `Send`
   |
   = help: the trait `std::marker::Sync` is not implemented for `dyn std::ops::Fn(http::request::Builder) -> http::request::Builder`
   = note: required for the cast to the object type `dyn futures_util::Future<Output = std::result::Result<AzureBlobResponse, Box<(dyn snafu::Error + std::marker::Send + std::marker::Sync + 'static)>>> + std::marker::Send`

error: could not compile `vector` due to previous error
make: *** [Makefile:172: build] Error 101

The branch with my changes is here: https://github.com/Azure/azure-sdk-for-rust/compare/main...yvespp:storage_account_TokenCredential_async_fix2
It would be nice if you coud give me some pointers on how to go forward with this?
I also thought about using a blocking method from tokio instead of futures::executor::block_on but that would bind the sdk to tokio which is probably not wanted.

@bmc-msft maybe you have some input on how to fix this?

Sorry for the delay!
I'm having a little bit of trouble following the issue here. It seems most of the links you posted are not permalinks. The links point to a branch rather than a specific commit and those branches have drifted since you posted this.
Calling a synchronous function from an async function is absolutely fine as long as that sync function does not block for a very long time (which prepare_request does do I believe).
Can you update your post to include permalinks to the relevant code? That would really help.

The links still pointed to what they should but I now updated them to permalinks.
There were a lot of changes in the sdk, I'll try to update vector to use the latest version to see if it still hangs.

@rylev @cataggar @bmc-msft with the removal of block_on the hang in Vector is gone!
I opened a pull request to update the SDK in Vector: https://github.com/vectordotdev/vector/pull/13453
It would be nice if some of you could look at it and give feedback on the SDK usage.


After the deployment of Linkis starts, the deployment starts Scriptis, which cannot be accessed after login

Search before asking

[X] I searched the issues and found no similar issues.

Linkis Component
linkis-commons
What happened + What you expected to happen
linkis部署启动后，部署启动scriptis，登入后无法访问。
After the deployment of Linkis starts, the deployment starts Scriptis, which cannot be accessed after login.
界面报如下错（linkis版本1.0.2，scriptis版本0.7.1）
The error appears as follows：GET http://<IP_ADDRESS>:9110/api/rest_j/v1/application/getBaseInfo 404 (Not Found)

nginx  deploy：

Relevent platform
nothing
Reproduction script
nothing
Anything else
This question comes from the QA documentation of the Linkis community
QA Doc Link：https://docs.qq.com/doc/DSGZhdnpMV3lTUUxq
Are you willing to submit a PR?

[X] Yes I am willing to submit a PR!

前端请使用单独的DSS，单独的Scriptis0.7.1版本不兼容Linkis1.0版本
Please use independent DSS for the front end， independent scriptis 0.7.1 is not compatible with linkis1.0 .


Crash on killing entity

Created a new world, summoned a zombie with commands, and killed it while in Creative Mode with a Vile Sword.  Add that.


bessctl TypeError: Couldn't build proto file into descriptor pool: duplicate file name

Tracked here: https://github.com/grpc/grpc/issues/31641

Use these specific package versions otherwise the generated python code will not allow bessctl/bessctl to run:
pip install --user protobuf==3.20.1 grpcio==1.46.0 grpcio-tools==1.46.0


JSON no diagnostics

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.74.0
OS Version: macOS

This problems exists from 1.68.0. in 1.67.0 everything seems to be fine.

Extension code to reproduce:

// most probably you want to register it to some command
const testContent = '{test: 5}'

vscode.workspace
    .openTextDocument({
        content: testContent,
        language: 'json',
    })
    .then(async doc => {
        await vscode.window.showTextDocument(doc)
    })

Run this code twice

Actual: First editor has diagnostics and second not
Expected: Both editors have diagnostics
The second call can also open file instead. This was happening to me in stable builds me in some cases without any extensions, but the only consistent way I found to reproduce is this ext code.
Attaching gif:

Text changes doesn't produce diagnostics in these editors. Of course, after reload diagnostics will be there.

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.73.1. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

No diagnostic pull request is send here.
openTextDocument triggers openFeature.onNotificationSent, but matches is false as the document is not visible at that time. https://github.com/microsoft/vscode-languageserver-node/blob/205a43a011713e8d5d668f76d1b666d40dfc1ede/client/src/common/diagnostic.ts#L903
The when the text document is shown, this doesn't trigger anything (tabs.onOpen is not listened to)


chore(deps): update terraform terraform-ibm-modules/key-protect/ibm to v2.8.5

This PR contains the following updates:

Package
Type
Update
Change

terraform-ibm-modules/key-protect/ibm (source)
module
patch
v2.8.4 -> v2.8.5

Release Notes

terraform-ibm-modules/terraform-ibm-key-protect (terraform-ibm-modules/key-protect/ibm)
v2.8.5
Compare Source
Bug Fixes

deps: update terraform terraform-ibm-modules/cbr/ibm to v1.27.0 (#615) (97d259c)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

/run pipeline


Mesh isotropy

Hello,
I did a test using the remesher tool on a quite simple mesh, but it leads to bad triangle fact aspect, and isotropy is not so good (very sharp facets, larger triangle area locally,..):

Is it possible to tune this ?
thank you

This is less a production quality tool than experimental code. It was inspired by reading in a paper that decent remeshing was possible by performing (approximate) Lloyd iterations on the vertices and then performing edge flips to improve minimum angle. I haven't looked at it in nearly a decade and it wasn't state of the art then. If you need very good quality I would recommend the CGAL remeshers.
That said: from the image, it looks like your edges are not subdivided as finely as your mesh. You could try tuning the edge-threshold, the element size or adjusting the code to fix this. I also tested this only on manifold meshes so if your mesh has open boundaries this may be part of the root cause and not well handled by the current implementation.


Add scots gaelic (gd) support

This PR is to add Scots Gaelic (gd) support to moment.js

[x] modifies parser to accept Gaelic months
[x] include Scots Gaelic Language file
[x] includes Scots Gaelic unit tests

@jonashdown looks good. I'll merge in next release. Can you please remove the .gitignore additions. You can use .git/info/exclude for non-commitable git exclude patterns. There are thousands of editors out there, I don't want a line for each one in the .gitignore.

@ichernev This is good news. I have removed the extra entries in the .gitignore file as requested. Will you inform me when the merge goes ahead as so my team can switch back to using the official version ?

Monitor https://mobile.twitter.com/momentjs

Merged in 0a01d890b471508fd4d3a7d4cccac0d254393518


[Bug]Not anchored to Savage chain, this can't be #SAF

🐛 Bug

To reproduce
its easy, because its not anchored to the SAF blockchain, anything can happen.
** Code snippet to reproduce **
# Your code goes here
# Please make sure it does not require any external dependencies

** Stack trace/error message **
// Paste the output here

Expected Behavior

System information
Please complete the following information:

Additional context
Add any other context about the problem here.

Any reputable coin is anchored to the Savage chain, SMH Zuck...

@DarkRavenDev what exactly is the issue you are experiencing?

@kphfb believe this is a duplicate of #217


Update to lwaftr to SnabbSwitch Olive

Update lwaftr_nutmeg to SnabbSwitch olive (v2015.10)
After that, there will be a remote branch lwaftr_olive and new PRs should be rebased to lwaftr_olive.

There's no PR for this issue. lwaftr_olive is now available as a remote branch:
$ git br -r | grep olive
igalia/lwaftr_olive

Until we decide whether to force update igalia/master with lwaftr_olive, rebase your new PRs against lwaftr_olive instead of lwaftr_nutmeg. cc @kbara @andywingo @aperezdc
All tests passed successfully. All snabb-lwaftr commands are working fine (tested a transient and run in a Snabb machine with cards).


should parse when used in a vm in strict mode

fixes #60, at least @yoshicarroll 's issue

ok will merge this latter if I don't hear any objections.


Docs minor fixes

Broken note
A typographic quote in
`Include`’s

seems to have broken the parsing of backticks. You may see that the text between Includes is wrapped into monospace code section, and the second backtick of the second backtick on the last Includes is missing.

We have had this issue with regular single quotes, that's why we've used a typographic one here. But the problems either affects both, or it started to with Antora version update.
Broken sub-department cops docs
If you go to https://docs.rubocop.org/rubocop-rspec/2.0/upgrade_to_version_2.html, links to the second-level cops docs are broken. The last one is correct, https://docs.rubocop.org/rubocop-rspec/2.0/cops_rspec.html, while others have anchors, e.g. https://docs.rubocop.org/rubocop-rspec/2.0/upgrade_to_version_2.html#cops_capybara.adoc. This is probably due to cops_docs.adoc vs cops_docs/ name clash.
Suspect: https://docs.antora.org/antora/2.3/page/page-id/#important
Ideally, we would generate cops_rspec_capybara.adoc instead of cops_rspec/capybara.adoc.
I've tracked it down to this method in RuboCop:
      def department_to_basename(department)
          "cops_#{department.downcase}"

Any suggestions? I've sent a PR to RuboCop to update this to change downcase to downcase.tr('/', '_').
Other RuboCop extensions don't seem to make use of sub-departments, and will be unaffected by this change.
Docs in the second commit are generated using the patched RuboCop.

Before submitting the PR make sure the following are checked:

[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[-] Added tests.
[x] Updated documentation.
[-] Added an entry to the CHANGELOG.md if the new code introduces user-observable changes.
[-] The build (bundle exec rake) passes (be sure to run this locally, since it may produce updated documentation that you will need to commit).

Corresponding RuboCop PR is merged. After its release:

the build will become green
in development, we won't have to point to github: inGemfile.local
...
and the doc will be fixed!

This PR should not be merged until the next version of RuboCop has been released, right?

This PR should not be merged until the next version of RuboCop has been released, right?

We can merge it, but that would cause complication for contributors.
In any case, contributors with the checked-out rubocop-rspec would have to bundle update --conservative rubocop to use the fixed task. Or we would have to bump our dependency again. I don't have a preference here, maybe it would make sense to bump the dependency and make everyone's live simpler.

A new version of RuboCop was released today – I have rerun our CI, and everything is green.
If a contributor runs into tests failing because of an old version of RuboCop, I think they will quickly find the cause. If not, we’re here to help (if they ask).
I don’t think this is enough cause to bump the gem’s requirement of RuboCop.


[Task] Add unit test cases for EmojiButton component

Task Description:
Currently, we run unit tests using jest which can be found here.
However, the test cases are not yet comprehensive enough and work can be done to cover more grounds. Specifically for this issue, we hope to add test cases for the EmojiButton component.
Deliverable(s):
New unit test cases that cover the testing of the EmojiButton component.
Additional Context:

Button components can be found here
An example for AudioButton can be found here which may serve as a good source for reference

I will work on this.

I will work on this.

Go for it!

Hey @heinthetaung-dev, a PR has just been opened for this issue: https://github.com/tjtanjin/react-chatbotify/pull/154
Given that you are first to indicate your interest for it and also assigned the issue, I think it's only fair to give you the priority in deciding. Here are 2 possible ways to proceed:

If you have not started and are willing to let the other developer have the issue, I can merge the current PR and explore other alternative issues with you.
If you have already started, I can reject the PR from the other developer (I can still mark the PR as hacktoberfest-accepted, which hopefully means the PR efforts are not wasted).

Let me know which option works out for you!

@tjtanjin no worries. Thanks for letting me know. I haven't started yet so you can merge the other PR.

@tjtanjin no worries. Thanks for letting me know. I haven't started yet so you can merge the other PR.

Thank you for your kind understanding 🥹 I'll be happy to help you explore other issues if you wish to (possibly via discord). Feel free to connect!

No problem. I will also take a look at other unit test issues.

@tjtanjin no worries. Thanks for letting me know. I haven't started yet so you can merge the other PR.

Thank you for your kind understanding 🥹 I'll be happy to help you explore other issues if you wish to (possibly via discord). Feel free to connect!

No problem. I will also take a look at other unit test issues.

Hey @heinthetaung-dev, it's been 3 days since the PR was opened and I haven't been able to get a response. I usually tend to wait a longer period but seeing as this was originally your issue, I think it's reasonable to close the existing PR and return the issue to you. Let me know if you're still keen, or I can re-open this to others as well 😄

Hey @heinthetaung-dev, it's been 3 days since the PR was opened and I haven't been able to get a response. I usually tend to wait a longer period but seeing as this was originally your issue, I think it's reasonable to close the existing PR and return the issue to you. Let me know if you're still keen, or I can re-open this to others as well 😄

@tjtanjin I'll be glad to work on this issue. 😄  Please assign this to me.

Hey @heinthetaung-dev, it's been 3 days since the PR was opened and I haven't been able to get a response. I usually tend to wait a longer period but seeing as this was originally your issue, I think it's reasonable to close the existing PR and return the issue to you. Let me know if you're still keen, or I can re-open this to others as well 😄

@tjtanjin I'll be glad to work on this issue. 😄 Please assign this to me.

The assignment never left you 😝

Hey @heinthetaung-dev, it's been 3 days since the PR was opened and I haven't been able to get a response. I usually tend to wait a longer period but seeing as this was originally your issue, I think it's reasonable to close the existing PR and return the issue to you. Let me know if you're still keen, or I can re-open this to others as well 😄

@tjtanjin I'll be glad to work on this issue. 😄 Please assign this to me.

The assignment never left you 😝

I will work on it.


RenderEditable leaks its gesture recognizers

RenderEditable creates gesture recognizers on creation, and never disposes them. It should create them on attach, and dispose them on detach.

I've open a PR to fix this @Hixie let me know what you think :)


i added a link for a free boot camp

I added a link to a free bootcamp to learn a basic introduction to software development and product design aimed at complete beginners, which anyone can join

please delete the repo and fork again to do your changes


Lazy http instantiation

Move Client.http to a cached property to allow lazy instantiation of the HTTPClient to the first use of it. This fixes discohook issues on serverless providers like Vercel which run the app in a pre-existing asyncio event loop. Deferring instantiation to the handling of the first request causes the aiohttp.ClientSession to re-use the event loop from the platform rather than creating its own which causes conflicts

Apologies that this pull request is 3 small and dumb edits. I was doing this on the web UI. It would be best to merge this pull request squashed as a single commit

This will not work well in Vercel if the app is kept alive between requests because each request will be run in a new event loop, therefore the second request will throw an error because ClientSession is kept with the old event loop

This wasn't going to work. Please see this pull request https://github.com/jnsougata/discohook/pull/50 which does fix the issue and it's been working well in a couple of bots I run


test: aria-current end-to-end tests (#3213)

End-to-end tests for #3213.
Edit: Not sure why the autofix.ci decided to kick in here but that CI setup probably should be done with the original pull request that introduce this to have a clean slate for this pull request to apply to.

@metatoaster It ran because it found a redundant match in your PR, I believe it runs cargo clippy on PRs now

The redundant match is in code other than this PR, so I'm not sure why it wasn't caught at some other point, but the other CI did pass on the PR and on the version with the fix. I will merge them as separate commits.

(Oh and thanks very much for adding the tests!)


Cannot build Dockerfile (with latest ODBC client)

Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package unixODBC-dev

(from https://github.com/keboola/db-extractor-snowflake/blob/master/Dockerfile#L7)
Correct package name is unixodbc-dev and it seems to be case-sensitive.

Selecting previously unselected package snowflake-odbc.
(Reading database ... 13375 files and directories currently installed.)
Preparing to unpack /tmp/snowflake-odbc.deb ...
Unpacking snowflake-odbc (2.16.1) ...
dpkg: dependency problems prevent configuration of snowflake-odbc:
 snowflake-odbc depends on unixodbc; however:
  Package unixodbc is not installed.

dpkg: error processing package snowflake-odbc (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 snowflake-odbc
ERROR: Service 'dev' failed to build: The command '/bin/sh -c dpkg -i /tmp/snowflake-odbc.deb' returned a non-zero code: 1

yes, it should be same as here https://github.com/keboola/ex-snowflake-parameters/blob/master/Dockerfile#L13
unixODBC-dev was working in previous version of PHP base images.

fixed a while ago


Representing trials in elephant

This pull is meant to initiate a discussion on a central topic in the design of
elephant: How to represent trials (for analysis functions that are trial based)
using the neo framework, and how to efficiently and flexibly deal with trials
from the user's and method-programmer's perspective.
In previous discussions, it was stimulated that trials could be represented as
Segments. This PR contains code to propose one approach to deal with such a
trial representation by introducing a class (NeoInfo) that allows to access and
interpret trials stored in such a fashion.
Of course, other approaches are equally possible. E.g., trials could be encoded in
lists or dictionaries, or simply as EpochArrays accompanying a Block, Segment
or AnalogSignal. All of such representations are useful, and we believe it is
probably good to allow for some of these possibilities to coexist. The idea was
that something like the NeoInfo class could be used to unify access to trials
stored in these various representations, e.g., to have something like (in
pseudo code):
x <- object # object containing trials represented in a supported way
analogsig <- NeoInfo(x).get_analogsignal_trial(1)
(Currently, NeoInfo only supports trials as Segments).
A Fano factor function is supplied as a simple use case of the class for
illustration (see provisional test case in test_statistics.py, fano_TestCase).
The code in this PR is still "raw" in many ways, but is meant to serve as a
basis for discussion for a perspective on how trials may be represented.
We realize that some of the functionality in this PR has overlap with some of the new functionalities of Neo and neo_tools.py introduced recently.

I am closing this PR now.


Add clause for non-binary template names in AppsignalPhoenix.View

Closes https://github.com/appsignal/appsignal-elixir-phoenix/issues/5.
Closes https://github.com/appsignal/appsignal-elixir/issues/588.
Phoenix.View.render/2 can be called with a module name as the first argument,
causing the call to be redirected to Phoenix.View.render/3. This patch makes
sure we let the call go through unchanged, which prevents double
instrumentation from happening and fixes the reported dialyzer issues.
This is planned to be released as 2.0.1

I was having the same issues, and I've tested this with this branch –
      {:appsignal_phoenix, github: "appsignal/appsignal-elixir-phoenix", branch: "non-binary-templates"},

Everything works! This has been a blocker for us getting AppSignal set up in our Elixir app as we happened to sign up a few hours after 2.0.0 was released. Looking forward to this being released!

Hey @matthewlehner,
Thanks for helping us test this! We’ve released this as :appsignal_phoenix 2.0.1 yesterday. This should be fixed If you switch your dependency back and run mix deps.update appsignal.
  defp deps do
    [
      {:appsignal_phoenix, “~> 2.0"},
    ]
  end

Thanks again! Please let us know if you run into anything else.


DBZ-6999 Fix multi-column add alter table statements

https://issues.redhat.com/browse/DBZ-6999

Applied to main (=2.5), 2.4, and 2.3.


Write the Heroes Journey Story

@raboley the puzzle #52 is still not solved.

@raboley the puzzle #53 is still not solved; solved: #52.

@raboley the puzzle #54 is still not solved; solved: #52, #53.

@raboley 2 puzzles #54, #55 are still not solved; solved: #52, #53.

@raboley the puzzle #54 is still not solved; solved: #52, #53, #55.

@raboley 2 puzzles #54, #56 are still not solved; solved: #52, #53, #55.

@raboley the puzzle #56 is still not solved; solved: #52, #53, #54, #55.

@raboley all 5 puzzles are solved here: #52, #53, #54, #55, #56.


invalid CIDR when using whereabouts

when i apply net def with host-local
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: macvlan-conf
spec:
  config: '{
    "cniVersion": "0.3.0",
      "type": "macvlan",
      "master": "enp104s0f1",
      "ipam": {
        "type": “host-local",
        "subnet": "<IP_ADDRESS>/28"
      }
    }'

pod with above cni works well. but when using whereabouts pods fail to create
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: macvlan-conf
spec:
  config: '{
    "cniVersion": "0.3.0",
      "type": "macvlan",
      "master": "enp104s0f1",
      "ipam": {
        "type": “whereabouts",
        "subnet": "<IP_ADDRESS>/28"
      }
    }'

Failed to create pod sandbox: rpc error: code = Unknown desc = [failed to set up sandbox container "311bde3aa7701ac58741679e058e91d851aca1f41e
│ 01ee095027e19aeebb04d7" network for pod "ubuntu": networkPlugin cni failed to set up pod "ubuntu_default" network: [default/ubuntu/:macvlan-conf]: error adding container to network "macvlan-conf": invalid CIDR : i
│ nvalid CIDR address: , failed to clean up sandbox container "311bde3aa7701ac58741679e058e91d851aca1f41e01ee095027e19aeebb04d7" network for pod "ubuntu": networkPlugin cni failed to teardown pod "ubuntu_default" ne
│ twork: delegateDel: error invoking DelegateDel - "macvlan": error in getting result from DelNetwork: invalid CIDR : invalid CIDR address: ]

The correct key to specify the subnet is named range - not subnet.
This is reflected on our docs and examples.
Please open another issue if you can reproduce it when using the correct key to specify the range.


Move toward a "black box" component library model for packages/ui

At the moment, our @penumbra-zone/ui package contains components whose appearance can be highly customized by the devs using them, particularly through the use of the className prop.
Ideally, a component library should be much less customizable. In the same way that an API exposes specific endpoints rather than allow any client to make SQL queries directly against its database, a component library should have a specific set of "endpoints" (in the form of component props) that allow them to be customized in pre-defined, rather than ad-hoc, ways.
The idea is that developers shouldn't generally be making design decisions when working on a given UI ticket, as that leads to poor UX decision-making. Designers are the ones responsible for making sure that an app has visual unity, and that each user flow is optimized to make it as painless and intuitive as possible. Developers, meanwhile, are generally focused on making a feature work, even if it comes at the expense of those two design concerns. Thus, if the design of an app is led by developers, its visual unity will gradually disintegrate over time, as each developer tweaks designs to their own tastes. And, common workflows will often suffer without a designer's research and expertise.
Thus, I am suggesting the following:

Develop a component library + design system in e.g., Figma.

This should include enough components that nearly all UI tickets can be completed by combining existing components, rather than creating new ones.
The system should be extremely specific. For example:

It should specify base layout and spacing units (such as 4px for spacing and e.g., a 12-column grid).
Each component should have its internal spatial relationships defined. (External spatial relationships are always determined by the container, not be the component itself. e.g., a button should never have external margins, as those should be set by their containing elements to avoid CSS override hell; but it is permitted to have internal padding.)

The system should specify shared values like border radii, brand colors, typefaces, etc. along with what each is used for.

Implement this component library in @penumbra-zone/ui.

Customization of these components, beyond what is specified in the Figma designs, should be disabled. For example, if Figma calls for a button with several "variants" like primary, secondary, and icon — each of which have different background colors and sizes — these can be specified via the <Button /> component's variant prop, NOT via a className prop that allows customization of colors and sizes.
Most, if not all, of these components should be built from scratch, rather than on top of an existing UI component library. In my experience with component libraries (both off-the-shelf ones, as well as the custom one I implemented from Figma designs for my previous employer), trying to build brand-compliant components on top of existing UI component libraries is unnecessarily painful, with tons of overrides/etc. required to get components to look how they should. It's much simpler and cleaner to build these components from the ground up. The only exception to this rule is when complex accessibility and/or interactivity concerns are at play, such as with a floating dropdown menu.

Sunset our use of Tailwind.

Tailwind is designed to make it easy for developers to customize the appearance of components — AKA, exactly what I'm suggesting we don't want.
Tailwind classes make it hard to reason about what styles a given element has, as it forces developers to inline all styles for elements, usually in a single line. For example: https://github.com/penumbra-zone/web/blob/main/packages/ui/components/ui/dialog.tsx#L40
Instead, we should use Dripsy, an unopinionated library that makes it easy to provide various styles to components via React contexts. (I've had success using this for building a ground-up component library in the past.)

cc @grod220 per our discussion on the topic

Helpful! A few thoughts:

There will be some sizable design changes coming down the pipeline in the next few months. We likely should put off implementation of this until we have the delivered figma w/ new brand guidelines. It is also likely we'll have two brands: penumbra main and a sub-brand for the extension. This is meant to distance the extension a bit from being considered the canonical one.
The className prop is really a kind of inversion-of-control that shadcn/ui offers. It's meant to replace the need to A) wrap the component in a div w/ custom styling (like wrapping a div with position: relative) or b) add a ton of optional props for one off styling. However, in theory, one could pass a ton of styling that really should live in the UI component. So it could be abused. Worth trying to be stricter, however, if folks are constantly wrapping it, that may be an indication that className props are necessary.
Re: building all components from scratch -> I find Kent Dodd's reasoning compelling. The industry is moving toward headless component libraries. The idea is to use a UI library with first-class accessibility, but that does not come with any styles.  Shadcn/ui took this idea further and made it easier for tailwind customization of Radix components. If the component exists there already, I don't see a reason why we wouldn't use it as a starting point.
Deprecating Tailwind is a tough one to swallow. Doing so is kinda a bet against the industry. The adoption and support for it has grown substantially since it came out. The syntax definitely takes some time to get used to, but quickly becomes way faster/easier for styling. I's say Theo's journey with tailwind really echoes mine. It's not just for our UI components though, we will need to style things ad hoc anyway.

@grod220:

There will be some sizable design changes coming down the pipeline...

Yup, makes sense.

The className prop is really a kind of inversion-of-control…

The best way to avoid pain here is: anything that affects the internal elements of a component should be handled by the component itself (with the optional input of limited props like variant). Anything affecting the external relationships between the component and its surroundings should be handled by the container component.
The reason I don’t like e.g., passing position: relative directly to a component’s root element is that it can interfere with a component’s internal styling logic. Let’s say, for example, that we have a  component with rounded corners. And let’s say you want to make one specific instance of that button’s have smaller corner radiuses than the rest of the buttons, since it’s going to be a small button where larger radiuses would look weird. So you pass a rounded-sm class to it, which gets applied to the root element. Later, we get new brand guidelines that all of our buttons should have square corners, not rounded. We update the  component to have squared corners. Now, all our buttons are squared, except for the one you passed rounded-sm to. No one realizes this, because there’s no type checking or anything that ensures that we no longer round the corners of our buttons.
If we had instead created e.g., a size prop on the <Button /> component, the <Button /> would have its own internal logic to use smaller corner radiuses when size === ‘small’. (For that matter, the developer who created the <Button /> component would hopefully have been thoughtful about what exact radius to use for each size, to fit together aesthetically.) Then, when we got updated brand guidelines, we’d remove any use of border radiuses from inside the <Button /> component, and buttons would still look consistent throughout the app. That way, the domain-specific knowledge about how to render a <Button /> stays within the <Button />, rather than being distributed in random places throughout the app.
The idea is to have clear boundaries between parent and child components, in terms of styling. If a parent can modify a child’s classes, the child then has to be aware of every possible style modification that can be made to it. But if a parent can only pass in a limited set of props, the child can control exactly what it renders for every combination of props.

…in theory, one could pass a ton of styling that really should live in the UI component. So it could be abused.

I would argue that Tailwind is designed to encourage that kind of abuse.*

The industry is moving toward headless component libraries.

Yeah, I can definitely see the benefits of this — especially to your point about accessibility. I just read his post that you linked, and I hadn’t realized that ShadCN is a kind of copy-paste solution. Looks pretty cool.

Deprecating Tailwind is a tough one to swallow.

I'm open to being wrong on this. I'll take some time to study up on Tailwind so that I understand its philosophy from the inside out, rather than just judging it by its cover. (I watched the video of Theo's journey, though: while his skepticism was similar to mine, I didn’t find his conclusions particularly compelling. To be honest, it feels a bit like Tailwind was designed for people who dislike CSS, which, I mean, fair… but it’s what we have to work with, and it’s worth doing right.)
Re: it being a bet against the industry: I wouldn’t necessarily assume that its popularity means that it’s a good or responsible solution for the long-term maintenance of a web app. It’s equally possible that its popularity stems from people wanting to not have to switch between TSX and CSS files when coding, which isn’t necessarily a good reason for its adoption. That said, again, I’ll take some time to study up on Tailwind so I’m more informed on why it’s so popular.
* Big caveat to pretty much all of my arguments above: I think I’m more accustomed to working with meticulously crafted design systems in Figma, and then implementing them in code. In that context, you really don’t want developers to be making design decisions. Since we don’t currently have a super built-out design system in place, allowing more design-by-developers is the only option we have, and Tailwind certainly makes that a lot easier. (Tangentially: I might also be conflating two concerns: 1) deprecating Tailwind, and 2) keeping clearer boundaries between parent and child components. Will reflect on this more…)

@grod220 can we close in favor of #1710?

"Black box" model was described in #1406, followed by #1411 and implemented later. Closing as done
The future plans of UI package development are moved to #1710


index.html file needs no-cache headers to ensure that updated .js, .css is loaded after new deploy

Nope, I don't think this will work unless we update the vhost at deploy time to point to the new index file.

However, I think we can prevent index.html from being cached with no-cache headers, as described:
http://stackoverflow.com/questions/1341089/using-meta-tags-to-turn-off-caching-in-all-browsers/24556761#24556761

Added.


Create normal Readme

Develop new Readme.md.
Examples:

https://github.com/unfoldingWord/gateway-edit#readme.
https://github.com/unfoldingWord/translationCore#readme
Maybe something else.

https://github.com/unfoldingWord/blank-project-template


use hash func that generates deterministic result for protobuf

This PR uses hash func that generates deterministic result for proto.
Background -
When integrate envoy SDS with Istio, we found envoy sends out multiple requests for same sdsconfig(details in https://github.com/envoyproxy/envoy/issues/5744);
After some debugging, we found the issue describes in https://github.com/protocolbuffers/protobuf/issues/5668.

/cc @PiotrSikora

how about tests?

@lizan what test(s) would you like to see here? Showing that SerializeAsString() is nondeterministic and MessageUtil::hash() is? Do we have examples of such tests for other xDS services? Thanks!

To clarify, good without tests because I imagine we're talking about protobuf internal implementation details. If you happen to have a repeatable test case that can easily show this then we should add it, but I'm suspecting not.

@quanjielin could you also fix source/common/config/config_provider_impl.h?

Why are we ok without tests here? It seems like it shouldn't be very difficult to craft a case that reproduces this? Or am I missing the problem?

@mattklein123 you're asking to come up with two situations in which SerializeAsString() produces different results in the existing code base; maybe it's as simple as two back-to-back calls, but maybe it involves some stateful internals of protobuf library. If it's the former, seems totally reasonable to add a test, but the latter will have less value due to its tight coupling with a single implementation.

Ok fair enough. Please open up a tech debt issue to remove all use of serializeasstring as well as a format check to block it's use at the very least? (A stronger version of @htuch previous comment). Thank you.

(I've asked @quanjielin to force-push, due to missed DCO in previous commit)

@quanjielin also, can you avoid force pushing from now on? Please DCO as appropriate to avoid this. It makes it hard to understand the diff between reviews.

LGTM, but please add a check like https://github.com/envoyproxy/envoy/blob/master/tools/check_format.py#L393 for SerializeAsString and  some test like https://github.com/envoyproxy/envoy/blob/master/tools/check_format_test_helper.py#L194.

Not sure if we really need that, some use cases doesn't need deterministic serialization (e.g. gRPC codec, TAP writing to file.)

@lizan these an be whitelisted at a file-level. I rather play it safe with this one as we have been burned.


[#164363210] Extract extra fields from cloud_controllger_ng logs

What
Cloud Controller outputs log lines like "Started VERB /api/uri for user: name, ip". We add an extra logstash filter to extract the verb, uri, username and source ip fields from those messages. This will allow us to get a more accurate picture of how many requests each user in the system is making in a timeframe, for the purposes of working out a reasonable request rate limit.
How to review

Code review
Check the dev Logit stack where this has already been applied, and ensure that log lines matching the above format have had the relevant fields extracted

Who can review
Not @tnwhitwell or @AP-Hunt.

Applied to all environments.


Expected Performance

Are there any expected performance metrics when fuzzing mixed python/c code? I attempted to run the pillow_pcx_example.py. In order to do that, I downloaded Pillow and built it with CC=afl-gcc and CXX=afl-g++ and then installed it.
When running the fuzzer, a single instance of the fuzzer seems to always execute at 3-4 execs/second. That seems slower than what I expected, is their any numbers that you can provide as to what you see there?
Additionally, is there a way to verify that the instrumentation is working? I provided in my input directory multiple files that should cause the code to go down different paths within the C portion of the Pillow code, however the when starting the fuzzer I received a message that no new instrumentation was detected with the additional test cases. Is there something that I could be doing wrong to cause that?
Thank you.

When I'm having a target that's not giving me any new paths, most of the time I find out that it's because the reader is aborting early due to some dumb mistake. The forkserver.err and forkserver.out files produced by dummy-afl-qemu-trace may be illustrative in this - or you may have to replace pillow_pcx_example.py's exception-ignoring clause with one printing the exception for these to become useful.
For pillow_pcx_example.py I achieve about 25 execs/s on a pretty old machine. Note that it's important to use small examples as inputs (typically <1k). I also only tend to use afl-clang-fast for binary instrumentation - it's significantly better than the older gcc hack. But this is all just standard afl stuff.


Fix the problem with early isContractDeployed checking in step9

As this tutorial is going to work for the folks that have just created their wallets, obviously there is not any contract deployed to their wallet yet. So checking if (!await client.isContractDeployed(wallet.address)) is a never-happening statement and no one can go further with this tutorial except if they have a wallet that had previous OUT transfers.

Thank you for this contribution!
First, the grammar and spelling fixes, if possible to do in a separate PR because I want to accept them.
The other fix of checking that the wallet exists is actually a "new" addition because many people had issues here. If the person does the entire tutorial in order, they will create the wallet in tutorial 1. The problem is that some people jump to the middle and skip and then their wallet isn't deployed. If this is the case, all outgoing transactions they have in the tutorial will fail with cryptic RPC errors that are hard to understand. We added the check if the wallet is deployed because I think it fails with a clear error immediately and then the person knows what's wrong, no?

Great. I will separate the PRs, but before that, I want to elaborate on the problem a little more as I think it's different that the way you described.
I did the entire tutorial in order, and I had that problem. Here's why:
As you've mentioned in tutorial 1 I created a wallet as you said. But the point is that although there is some money in the wallet, the contract of the wallet has not been deployed yet. Regarding the documentation, the wallet contract will be deployed when there is an outgoing transaction happens (which is going to happen in this step after this if). So the deployment of the wallet contract is going to happen in the next lines and this if won't let it happen.

Hmm.. not sure I understand. In tutorial 1 we have step 4 ("Step 4: Fund and deploy your wallet contract") which does exactly this. This step tells you to create an outgoing transaction and then see in the block explorer that your wallet contract state changed to deployed.
If I understand your issue is in step 9, which means you've already completed step 4. Or am I missing something?


Add a new gradebook functionality: Minimum score

Instructors are interested in having a new option in gradebook that allows them to set a minimum score. Its kind of a 'conditional release'.
Minimum score: It is the minimum score necessary to reach in the gradebook item to pass the course.
Specifications:
Add a new gradebook item field: Minimum score
If the student reaches less than the minimum score his course grade will be blank.

This is really a feature request, I tried adding a label to it 'enhacements' but I can't.

Could this be handled with the minimum score in the course grade? You could maybe use the Pass/Not Pass setting and set the applicable minimum grade that way? If not, how did you envisage it working?

I think this sound complicated with a lot of possibilities and maybe not something I'd want to see tackled right now. This is the same description as the request at https://jira.sakaiproject.org/browse/GRBK-1429.
Would this be minimum score for the course or minimum score for any individual item? The way it's described in the picture on GRBK-1429, if they got below the minimum score even on a single item they don't get a course grade, that doesn't make sense to me.
I also feel like many people would interpret this more like "this is the minimum points it's going to assign for completion". So instead of 0-100 possible points.(for 100 points) it's 60-100 possible points, no matter how badly a score it is. (Like of like a curved grade)
It seems really confusing to me when it's locking down the determination of the final course grade based on some items.

Hi Steve and Matthew,
Thanks for your comments, let me clarify it a bit more.
As Matthew is saying, it is the same issue described in GBRK-1429 (that one was intended for GB2) and since we are planning on moving from GB2 to GBNG, we will be opening github issues for all the functionality missing in GBNG, to start the discussion and prioritize functionalty with others from the community: https://confluence.sakaiproject.org/display/SG2X/Moving+from+Gradebook2+to+GradebookNG
So, back to this issue:
This is a piece of functionality that was included in our old 'custom' grading system and that Instructors at our institution still ask for. It is intended only for individual grading items, it's NOT a minimum course score, its a minimum gradebook item score that students need to achieve in order to get a FINAL GRADE. Here is simple example:
MATHS - FINAL GRADE (100%) is the sum of FINAL EXAM+LAB 1+LAB 2+LAB 3+PROJECT with a 'minimum score' condition set on the item FINAL EXAM.
- FINAL EXAM: 40% (minimun score set on 50 out of 100)
- LAB 1: 10%
- LAB 2: 15%
- LAB 3: 15%
- PROJECT: 20%
The instructor might request their students that in order to pass the course they need to get at least a 50% in the score of the final exam (this is why I said in my first comment that this might look like a conditional release).
Then, a student could have top grades in LAB 1, LAB 2, LAB 3 and PROJECT (60% of the final grade) but do bad on the FINAL EXAM and recieve just a 30% out of 100% which in is a 12% out the 40% that the FINAL EXAM is worth within the final grade. Since the 'minimun score' for the gradebook item FINAL EXAM was set to 50% and the student got a 30%, then, the final grade wont be calculated. That student will need to take that FINAL EXAM again until he gets the 50% requested by the instructor in order to pass the course.
Does it make more sense now? As I said, it is a real use case from many instructors at our institution. Right now, what they do, is that they handle the minimun score in a manual way, if the student has not reached that minimun score in a gradebook item, they don't add the FINAL GRADE to the university SIS (Student Information System) and they ask the student to re-do/re-take the gradebook item that they are missing.

To clarify just a bit more, if the minimum grade isn't met for a gradebook item, is that item excluded from the course grade calculations (so if you had 5 items and only 4 qualified, only the points from the 4 would be used) or does the course grade just not get calculated at all unless all 5 qualify?
Seems pretty simple to add a flag to each item which then contributes to the calculations, just need to make sure the priorities and community requirements are managed.

Yeah, I think that's most of my problem is the ambiguity of what "Minimum Score" would do. There's already "Drop lowest" but this might not be the lowest and it doesn't sound like he's saying he wants it dropped or not included in the calculations, he's saying he doesn't want any calculation at all. I've never heard of a grading system like this and I think it would be something you'd want to "turn off" or hide if it was implemented because it would be confusing.
In any case I'd probably expand the description from "Minimum Score" to "Minimum item score required for final grade calculation" even if it is wordy.


Just need onChange

I need more control over the state of the chosen files. I already had this situation https://github.com/Jaaneek/useFilePicker/issues/26 and fixed it also with useEffect.
    const [openFileSelector, {filesContent}] = useFilePicker({
        accept: props.fileEndings,
        multiple: Boolean(props.multiple),
        readAs: 'DataURL',
    });

    useEffect(() => {
        props.onChange(filesContent)
    }, [filesContent])

But now I want to repopulate a file selection in an edit form. But useEffect will overwrite anything with an empty filesContent due to its initializaiton.
Can there not just be an onChange within useFilePicker to use?

What do you mean by "repopulate a file selection"? Do you want to keep the previous selection or just avoid the onChange invocation with empty array?  Here are some solutions:

for keeping previous selection: https://github.com/Jaaneek/useFilePicker/issues/51#issuecomment-1262184562
If you want to avoid the initialization step, then just add an if statement to your useEffect:

useEffect(() => {
  if (filesContent.length) {
    props.onChange(filesContent)
  }
}, [filesContent])

With that check, your onChange won't be called without actual content.

Can there not just be an onChange within useFilePicker to use?

We believe it's not needed. You can read more about reasons here: https://github.com/Jaaneek/useFilePicker/issues/32#issuecomment-1010894551

Ok, we'll talk through it within the maintainers team. Thanks for the suggestion.
It is also worth noting that we're currently in the process of changing the openFileSelector function to return a promise with all the values returned from the hook, which was suggested here #56 and is currently in code review #58. We'll be releasing version 1.6.0 with that feature soon, so maybe you can use it before we implement onChange.

Turns out that we weren't able to reliably introduce promise to useFilePicker due to browser APIs, more explanation can be found here: https://github.com/Jaaneek/useFilePicker/pull/58#issuecomment-1496680066
Because of that, we decided to implement onChange handlers like you suggested @fabpico.
There is already a PR for this: #60 and we're aiming to bring this feature in the next release 1.6.0.
Thanks for your input @fabpico!

We had to do quick bump to 1.6.1, let us know if we can close this issue once you test it out @fabpico

@Jaaneek How to use it?

@fabpico just pass handlers as props to the hook.
There are 3 functions you can use, which are described in the docs:

example:
const [openFilePicker] = useFilePicker({
   onFilesSelected: (data) => {
      // your logic whenever user submits valid or invalid files
   },
})

Works so far 👍 . Thanks for the quick feedback and improvement.


privatelink.dp.kubernetesconfiguration.azure.com created but not documented

[Enter feedback here]
My customer is finding that a Private DNS Zone called "privatelink.dp.kubernetesconfiguration.azure.com" is being created, but it is not documented on this page. Is that just an oversight?

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

ID: a88af182-32aa-a8f3-359d-b92ae1cfb8c7
Version Independent ID: 01ce07fc-4bc2-def5-9ecd-a80330ad9488
Content: Azure Private Endpoint DNS configuration
Content Source: articles/private-link/private-endpoint-dns.md
Service: private-link
GitHub Login: @asudbring
Microsoft Alias: allensu

@gamullen
Thanks for your feedback! We will investigate and update as appropriate.

@gamullen , thank you for bringing this to our notice.
Looks like Azure Private DNS zone for Azure Arc is added in the list but the dp is missing before the kubernetesconfiguration.azure.com.

I checked the Arc-enabled Kubernetes clusters private link doc and also confirmed in lab that the FQDN is indeed "privatelink.dp.kubernetesconfiguration.azure.com". Hence correcting the DNS zone name in the existing table.
Refer: https://learn.microsoft.com/en-us/azure/azure-arc/kubernetes/private-link

We are closing this issue for now. If there are further questions regarding this matter, please reply and we will gladly continue the discussion.


Add SigningAuthCredentials interface, enable signing for AE credentials

This PR follows from #701:

Add SigningAuthCredentials interface
Make AppEngineAuthCredentials extend SigningAuthCredentials and enable signing on AE
Make AppEngineAuthCredentials public as other AuthCredentials classes
Change createApplicationDefaults to return ServiceAccountAuthCredentials if a service account is available
Add constructor to ApplicationDefaultAuthCredentials that takes GoogleCredentials

/cc @tmatsuo

Nice work! I really like the way you handled the default credentials.

Changes Unknown when pulling 08e23ff59a925e192665d4506dd0bb19c675db81 on mziccard:signing-auth-interface into ** on GoogleCloudPlatform:master**.

Comments fixed in 08e23ff

Looks great. Few more suggestions.

Changes Unknown when pulling 72ae3cb3113328f50ce9c1a6515c1b1f2750b7b9 on mziccard:signing-auth-interface into ** on GoogleCloudPlatform:master**.

Latest comments fixed in 72ae3cb

Looks good. One ( x 2) Javadoc fix, and I think we can fix the codacy complaint as well.
Feel free to merge after.

:+1: Thanks!


fix: incorrect mlspp namespace

Hey folks!
I was setting up your codebase locally, and it seems your mlspp related code is using an incorrect (outdated?) namespace.
The library exposes a MLS_NAMESPACE macro which I am using here to ensure the correct namespace for said library.
This issue probably arises from you guys using a specific, older version of mlspp which used the mlspp namespace over the new mls namespace. Your readme.md does not specify dependency versions, so I figured I'd address this issue. You might need to update mlspp on your end.
There were more issues I found in the codebase I will be going over gradually, such as missing header files.
To elaborate on the above, there are certain functions you're using which are only included because other std headers happen to include them, but unfortunately that is implementation-specific and on my end the code did not compile because of it.
More PRs to come, including one addressing this.
Thanks,
Tuur

https://github.com/discord/libdave/commit/6e5ffbc1cb4eef6be96e8115c4626be598b7e501 updates the README to include the -DMLS_CXX_NAMESPACE="mlspp" configuration. It also sets up CMake/vcpkg to build/test an isolated libdave and resolves some of the issues you've described that were affecting that build.


.NET Core March 2020 Updates – 2.1.17 and 3.1.3

3.1.3 Release Notes
3.1.3 Download
2.1.17 Release Notes
2.1.17 Download
Blog posts
.NET Core
Please report any issues you find with 2.1.17 or 3.1.3, either responding to this issue, creating a new issue or creating a new issue in one of the following repos:

aspnet/Home - for ASP.NET Core questions
aspnet/EntityFrameworkCore - for Entity Framework Core questions
dotnet/cli - for CLI tools and questions
dotnet/runtime - for runtime, API, or installer issues and questions
dotnet/winforms - for Winforms issues
dotnet/wpf - for WPF issues

Status of availability of 3.1.200 SDK on Linux feeds:

Distro
3.1.3
2.1.17

Ubuntu 16.04
✅
✅

Ubuntu 18.04
✅
✅

Ubuntu 19.10
✅
✅

Centos 7
✅
✅

Debian 9
✅
✅

Debian 10
✅
✅

Fedora 30
✅
✅

Fedora 31
✅
✅

OpenSUSE 15
✅
✅

SLES 12

SLES15
✅
✅

This included?
https://github.com/dotnet/efcore/issues/1833#issuecomment-603543685

This included?
dotnet/efcore#1833 (comment)

https://github.com/dotnet/efcore/pull/20279 was submitted recently. This did not make it to the current release.

Chocolatey fails for 3.1.3, need to worry or not?
You have dotnetcore v3.1.2 installed. Version 3.1.3 is available based on your source(s).
dotnetcore not upgraded. An error occurred during installation:
 The remote server returned an error: (403) Forbidden. Forbidden
dotnetcore package files upgrade completed. Performing other installation steps.
The upgrade of dotnetcore was NOT successful.
dotnetcore not upgraded. An error occurred during installation:
 The remote server returned an error: (403) Forbidden. Forbidden

Regards.

The 3.1.3 Release Notes links to an internal page for instead of https://docs.microsoft.com/en-us/dotnet/core/install/macos-notarization-issues

Thanks @mletterle - link fixed.

@fwd079 - the Chocolatey packages are community maintained and not "official". We'll check a few things on this side to make sure nothing is obviously out of sorts. After that, it will be up to the maintainers.

something went wrong on publishing the package, it seems available but you cannot download it: https://packages.chocolatey.org/dotnetcore-runtime.install.3.1.3.nupkg

Just successfully installed 3.1.3 and SDK 3.1.201 via Chocolatey. Looks like that did it. Thanks @riezebosch!
/cc @rbhanda

@fwd079 - the Chocolatey packages are community maintained and not "official". We'll check a few things on this side to make sure nothing is obviously out of sorts. After that, it will be up to the maintainers.
Update: If I run choco search dotnetcore, 3.1.2 is reported even though https://chocolatey.org/packages/dotnetcore indicates 3.1.3.
@riezebosch - any thoughts?

So it was on this side, well I am glad then, since that made sorting out a swift thing,  checked this morning and working as expected and installed.
Thanks @riezebosch for looking into it.
Regards.

The following relates to 3.1.3.
When restoring an fsproj project with SDK version 3.1.201, I am seeing this:
 /root/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-19270-01/build/Microsoft.Build.Tasks.Git.targets(16,5): error MSB4018: The "Microsoft.Build.Tasks.Git.LocateRepository" task failed unexpectedly. [foo.fsproj]
 /root/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-19270-01/build/Microsoft.Build.Tasks.Git.targets(16,5): error MSB4018: System.TypeInitializationException: The type initializer for 'Microsoft.Build.Tasks.Git.TaskImplementation' threw an exception. [foo.fsproj]
 /root/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-19270-01/build/Microsoft.Build.Tasks.Git.targets(16,5): error MSB4018:  ---> System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Build.Tasks.Git, Version=<IP_ADDRESS>001, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified. [foo.fsproj]

If I use 3.1.103, it works fine. Only 3.1.201 has the problem.
Command used was dotnet test -c Release foo.fsproj.
Is there any more information I can provide? Should I file an issue on this somewhere?
$ dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.1.103
 Commit:    6f74c4a1dd

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.18363
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\3.1.103\

Host (useful for support):
  Version: 3.1.3
  Commit:  4a9f85e9f8

.NET Core SDKs installed:
  2.1.202 [C:\Program Files\dotnet\sdk]
  2.1.402 [C:\Program Files\dotnet\sdk]
  2.1.503 [C:\Program Files\dotnet\sdk]
  2.1.508 [C:\Program Files\dotnet\sdk]
  2.2.101 [C:\Program Files\dotnet\sdk]
  2.2.104 [C:\Program Files\dotnet\sdk]
  3.0.100 [C:\Program Files\dotnet\sdk]
  3.1.103 [C:\Program Files\dotnet\sdk]
  3.1.200 [C:\Program Files\dotnet\sdk]
  3.1.201 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.16 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.16 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.16 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

[Memory Leak]
System: CentOS 7.2
SDK: 3.1.201
ex:
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Press any key to continue");
Console.ReadLine();
while (1 == 1)
{
List stdout = RunTaskAndReturnStdout("dotnet", $"--version");
}
}
}
public static List RunTaskAndReturnStdout(string fileName, string arguments, string workingDirectory = "")
{
List ret = new List();
try
{
using (Process proc = new Process())
{
proc.StartInfo.FileName = fileName;
proc.StartInfo.Arguments = arguments;
proc.StartInfo.UseShellExecute = false;
if (!string.IsNullOrWhiteSpace(workingDirectory))
proc.StartInfo.WorkingDirectory = workingDirectory;
proc.StartInfo.RedirectStandardOutput = true;
proc.Start();
while (!proc.StandardOutput.EndOfStream)
{
string line = proc.StandardOutput.ReadLine();
// Console.WriteLine(logstr);
if (!string.IsNullOrWhiteSpace(line))
ret.Add(line);
}
return ret;
}
}
catch (Exception ex)
{
return ret;
}
}

Closed in favor of https://github.com/dotnet/core/issues/4675


improvement add routine load rows check

Proposed changes
During the process of consuming Kafka, there may be a risk of data loss, and data verification needs to be added to investigate the cause of problems when they occur.


Feature Request: add spellcheck functionality

As a user I would like to have incorrectly spelled words underlined and offer suggestions to correctly spelled words.
OS: Ubuntu 18.04

Hi @jbforth4 , thank you for reporting this! It took a long time, but the app now has spellchecking as of v0.8.0 (#124 )

The spell check is great, but it is very difficult to see when using dark mode. Can the color of the underline be lighter when in dark mode for more contrast?


Relative "dita.temp.dir" makes PDF processing fail

It happens with both DOT 1.8 and 2.x.
So if the temporary directory is specified in the command line like:
  -Ddita.temp.dir=temp/pdf

at some point the indexer fails:
   D:\projects\eXml\frameworks\dita\DITA-OT2.x\plugins\org.dita.pdf2\build.xml:292: java.io.FileNotFoundException: temp\pdf\stage1.xml (The system cannot find the path specified)
at java.io.FileOutputStream.open0(Native Method)
at java.io.FileOutputStream.open(Unknown Source)
at java.io.FileOutputStream.<init>(Unknown Source)
at java.io.FileOutputStream.<init>(Unknown Source)
at com.idiominc.ws.opentopic.fo.index2.IndexPreprocessorTask.execute(IndexPreprocessorTask.java:137)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:435)
at org.apache.tools.ant.Target.performTasks(Target.java:456)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
at org.apache.tools.ant.Project.executeTargets(Project.java:1248)

I think that in such cases it should be explicitly considered relative to the basedir.

It all started with a discussion here:
http://www.oxygenxml.com/forum/post35711.html#p35711

Not sure if I want this to be implemented. The problem is that dita.temp.dir is an "internal" property and it must be absolute (otherwise we'd have to resolved it in context that doesn't have information what is a suitable base path). But, on the other hand there is not way to define the temporary directory in other way.
My vote here is :-1: and just add support for relative temporary path in dita command. Ant should be considered an advanced API and we shouldn't add convenience method/properties there.

We should probably have had two properties, one which could be set externally and could have supported relative paths and an absolute internal one used everywhere in the build files.
Anyway, does not seem to be a common problem.

Or at least add a check for the dita.temp.dir in the build files and if it is given as relative, break everything with a meaningfull error.


Filtering Annotations by ID

My goal is to load annotations and filter them by their ids so they are easy to locate. I was able to follow along here to load annotations. In your comment, you state that additional files are required to filter by annotation ids. I was wondering what these additional files are and where they need to be placed.
I have tried adding single annotation encoding files in either the directory specified by the by_id key or the spatial key. However, neither seems to have an effect.
Any help you can provide would be great, thanks!

You can associate annotations with segment ids, via "relationships".  Then after adding the annotation layer, you bind a given relationship to a segmentation layer.
This script shows how the related segments index can be written:
https://github.com/google/neuroglancer/blob/master/python/neuroglancer/write_annotations.py


Removed unused classes and added Mobile view

before:

now:

:green_heart: :blue_heart: :purple_heart: :yellow_heart: :heart:


Reproducers of python tests are not runnable with IREE tools (missing passes)

Describe the bug
Reproducers of python tests are not runnable with IREE tools. Discovered by @joker-eph
To Reproduce
Attempt to run this pipeline with iree-tf-opt or iree-opt-tflite (why do the names not match?), which comes from the test layers_dynamic_dims_tests__layer__Dot__target_backends__tflite
'func(tf-executor-graph-pruning{ops-to-preserve=}, tf-executor-island-coarsening, tf-materialize-passthrough-op, canonicalize), tf-shape-inference{max-iterations=10}, symbol-dce, func(tf-optimize, cse, tf-device-index-selector), canonicalize, tf-shape-inference{max-iterations=10}, tf-functional-control-flow-to-regions, func(tf-device-decompose-resource-ops), tfl-prepare-composite-funcs-tf, tf-region-control-flow-to-functional, inline{default-pipeline=canonicalize max-iterations=4 op-pipelines=}, symbol-dce, tfl-lower-static-tensor-list{allow-tensorlist-pass-through=false}, tf-saved-model-optimize-global-tensors, tf-shape-inference{max-iterations=10}, tfl-legalize-tf-while, inline{default-pipeline=canonicalize max-iterations=4 op-pipelines=}, func(tf-decode-constant, canonicalize, cse), symbol-dce, tf-saved-model-freeze-global-tensors{allow-mutable-tensors=false}, tf-shape-inference{max-iterations=10}, func(tf-layout-assignment{force-data-format=NHWC}, tf-move-transposes{direction=end fold-transpose-in-ops=false}, tf-move-transposes{direction=begin fold-transpose-in-ops=false}, tfl-prepare-tf{tfl-allow-bf16-and-f16-type-legalization=false tfl-unfold-batch-matmul=true}, canonicalize), tf-shape-inference{max-iterations=10}, inline{default-pipeline=canonicalize max-iterations=4 op-pipelines=}, func(tf-init-text-file-to-import, tfl-legalize-tf{run-tfl-runtime-verification=true}, tfl-optimize), tfl-optimize-functional-ops, func(tfl-raise-custom-ops), symbol-dce, func(canonicalize, cse, tfl-split-merged-operands), tfl-insert-call-once-op, tfl-while-loop-outline, func(tfl-runtime-verify)' -verify-each

Or really, just --pass-pipeline="func(tf-executor-graph-pruning{ops-to-preserve=})"
MLIR Textual PassPipeline Parser:1:6: error: 'tf-executor-graph-pruning' does not refer to a registered pass or pass pipeline
More generally, we should ensure that this can't occur, either by having the Python use the same tools that a user would use in the reproducer, or by making the registration use some shared structure so that adding something in one place means adding it the other.

Assigning to you @benvanik since I believe you just trimmed the pass registration

Names are different for legacy reasons - iree-tf-import needs to be renamed to iree-import-tf. I think Stella didn't want to break anything when initially landing the new tflite/xla tools and changing it is TODO.
It's expected that you can't run tensorflow passes with iree-opt-tflite - that's strictly for tflite.
As far as I know I didn't remove anything from iree-tf-import:
https://github.com/google/iree/commit/000d64f50538ad381731263e81008e0f02cd5e8d#diff-280436dfc64df86f44423fd6ec5585558abca70f124d14763f84a76a87652390
Did this ever work?

Yeah iree-tf-opt was my first guess, but I decided to try with the other, since this is a tflite test. Maybe it never worked.

Not seeing anything obvious here in diffs - I don't know anything about the python layer/reproducers but agree that they should provide the same input as expected to the other tools.

I still don't really understand pass registration and such, but the deps on the rules stayed the same (https://github.com/google/iree/blob/000d64f50538ad381731263e81008e0f02cd5e8d/integrations/tensorflow/iree_tf_compiler/TF/BUILD#L0-L1) during the move so if they are coming in via automagic then it's just possible these were never linked in/registered.

We don't even use tf-executor-graph-pruning, so that must be getting pulled in from some tf pass pipeline.

I just suspect no one ever set these tools up for doing anything but running our pipeline and not as generic opt tool.

Closing this as obsolete


[Forms]: Add Accordion component to Forms

Add Accordion component from our private monorepo.
@arantespp, what you think about that?

We've already had this on our backlog https://github.com/ttoss/ttoss/issues/191


Creating a sub entry is not appearing in the left navigation pane

When you create a child entry within a container entry, it's not appearing at the left navigation pane.
Alinea version: ^0.4.0-preview.30
Ex:
// News entry
export const NewsSchema = alinea.type('News', {
  title: alinea.text('Title'),
  path: alinea.path('Path', {
    hidden: true,
    readonly: true
  }),
  [alinea.type.meta]: {
    isContainer: true,
    contains: ['Newsdetail']
  }
})

// News detail entry
export const NewsdetailSchema = alinea.type('News detail', {
  title: alinea.text('Title', {width: 0.5}),
  path: alinea.path('Path', {width: 0.5})
})

When creating a news detail within the News entry, the new entry is displayed at the right detail pane, but it's not appearing at the left navigation pane. You need to refresh the page before it appears.

Fixed in 0ae47e5ea1b76017bb4ea2e9bf6f785f4c253cb2


[CI] CI random failure

[ ] Any interfaces changed?

[ ] Any backward compatibility impacted?

[ ] Document update required?

[ ] Testing done
Please provide details on
- Whether new unit test cases have been added or why no new tests are required?
- How it is tested? Please attach test report.
- Is it a performance related change? Please attach the performance test report.
- Any additional information to help reviewers in testing this change.

[ ] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/2455/

retest this please

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/2194/

Build Failed with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/971/

retest this please

retest sdv please

Build Success with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/975/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/2198/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/2467/

retest sdv please

retest this please

SDV Build Fail , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/2473/

Build Failed with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/987/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/2210/

retest sdv please

retest this please

SDV Build Fail , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/2475/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/2213/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/2476/

Build Success with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/991/

retest this please

retest sdv please

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/2215/

Build Success with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/993/

retest this please

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/2479/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/2218/

Build Success with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/996/

Build Failed with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/1000/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/2222/

SDV Build Fail , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/2482/

Build Failed with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/1006/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/2489/

retest this please

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/2238/

Build Success with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/1014/

retest this please

retest sdv please

retest this please

retest sdv please

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/2240/

Build Success with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/1016/

SDV Build Fail , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/2497/

SDV Build Fail , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/2498/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/2245/

Build Success with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/1022/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/2504/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/2519/

retest this please

retest this please

Build Success with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/1063/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/2284/

retest sdv please

retest this please

Build Success with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/1068/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/2287/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/2531/

Build Success with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/1071/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/2290/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/2533/

Build Success with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/1074/

retest this please

Build Success with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/1083/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/2299/

retest this please

Build Success with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/1095/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/2311/

retest this please

retest sdv please

Build Success with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/1096/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/2312/

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/2546/

retest this please

Build Success with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/1097/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/2313/

retest this please

Build Success with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/1099/

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/2315/

retest this please

retest sdv please

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/2555/

Build Success with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/1113/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/2329/

retest this please

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/2351/

Build Failed with Spark 2.2.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder/1134/

retest sdv please

SDV Build Success , Please check CI http://<IP_ADDRESS>:8080/job/ApacheSDVTests/2600/

LGTM


Unable to use any F1-F12 keys

Is there any option to remap these keys? They just don't work whatsoever. Or maybe there is an option to pick a character and use it as a draw character?
Im using Kitty 0.31.0-1 (xterm-kitty) on Arch Linux. None of the F1-F12 keys work and the draw/erase/color modes dont register click up or down, it instead just draws/erases/colors wherever the mouse is dragged regardless of whether the mouse is clicked or not. Really cool project btw!

Thank you for the report! I'm sorry you had issues using it in Kitty.
I have been considering patching this soon to allow esc-1 through esc-0 as alternatives to F1-F10, and your issue is making me think it's a good idea. I'm open to suggestions for alternatives to esc-1 to esc-0 if you have another idea.
Re-mapping keys is also a good idea, not supported just yet.
As for the mouse issue... I will give Kitty a try and see if I can nail it down. There is an issue #17 that can cause a symptom like what you're describing, but it is normally triggered by clicking down and dragging the mouse outside the window while keeping the mouse button down.  There might be something else going on with Kitty's xterm mouse reporting.

I'm using Kitty 0.31.0-1 (xterm-kitty) on Arch Linux. None of the F1-F12 keys work and the draw/erase/color modes dont register click up or down, it instead just draws/erases/colors wherever the mouse is dragged regardless of whether the mouse is clicked or not.

Hmm. I am having a hard time re-producing these issues in Kitty 0.31.0 in Fedora 39 (KDE Plasma). The function keys and mouse are working as expected for me.
There are a few things I would like for you to check, if you haven't already.
1: Do you have a laptop or other small keyboard that is locking the function keys to some other function, like volume and media control? On many laptops, they can be toggled with Fn-Esc.
2: Is your window manager or desktop environment using the function keys, or mapping them elsewhere? Double check your desktop environment's keyboard shortcut settings to make sure.
3: Are you having the same problems with Durdraw in other terminal emulators?
Issue #17  is quite annoying and may have been the trigger for the mouse symptom you described.  If the mouse gets stuck "as if the button is being pressed down," a single click in the canvas should "un-lock" it.
Thanks!

Hey @mizi3,
Commit 76573b2 adds esc-1, esc-2, etc. as alternatives to F1-F10.  Does this help out your situation, until a proper key mapping system is in place?
This change should be in the next major release version (0.25.0), but you can try it out now in the development branch (currenty 0.25.0-beta) at https://github.com/cmang/durdraw/tree/dev.
Thanks!

@mizi3
Durdraw 0.25.0 provides esc-1, esc-2, to esc-0 as alternatives to F1, F2, etc.
Please let me know if you're still having issues.  Thanks!


IOS App with notifications and II integration

Overview
This example includes an IOS native application that serves a dapp, can authenticate using the internet identity and can receive push notifications.
Considerations

To enable service workers the iOS app needs to have enabled support for bound domains (WKAppBoundDomains)
WebAuthn is only natively supported by web views if the domain that is making the credentials call would serve the file /.well-known/apple-app-site-association with the specified appId, and, the app has that domain set as an associated domain, otherwise, it fails with a WebAuthn error for security reasons (it does not support a wildcard value)

For this reason we've opted to use a new ASWebAuthenticationSession which opens a new window for the user and sends a callback to the native app when the user is successfully authenticated

The iOS app supports notifications, however, to test this feature you'll need to have a physical iOS device since the xCode simulator is not able to register to get a device id

Demo
https://user-images.githubusercontent.com/119848388/208689656-02a3e25e-260d-4c00-b2b0-553afa0fdfea.mov

Nice work! I'm excited to have this example


Dynamic Hub Change Part 2

Part 2 of https://github.com/aspnet/SignalR/issues/554
I changed the SocketSample Chat hub to be a dynamic hub as well.

@mikaelm12,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

Test are coming

Updated 😄

Still updating the HubEndPointTests but the functional HubConnectionTests seem to be hanging for WebSockets and SSE. SSE seems to be hanging in dispose

Updated 😄

This is ready for review


Removal of zip files in examples at the control plane layer

Description
ZIP files in a repository makes it hard to do version control, test, debug, etc. Remove the zip files and read the trainer, aggregator and the their variations directly.
Type of Change

[ ] Bug Fix
[ ] New Feature
[ ] Breaking Change
[x] Refactor
[ ] Documentation
[ ] Other (please describe)

Checklist

[ ] I have read the contributing guidelines
[ ] Existing issues have been referenced (where applicable)
[ ] I have verified this change is not present in other open pull requests
[ ] Functionality is documented
[ ] All code style checks pass
[ ] New code contribution is covered by automated tests
[ ] All new and existing tests pass

Codecov Report

Merging #408 (30a2d1b) into main (1b82098) will decrease coverage by 0.31%.
The diff coverage is 0.00%.

:exclamation: Current head 30a2d1b differs from pull request most recent head 81bcc6e. Consider uploading reports for the commit 81bcc6e to get more accurate results

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##             main     #408      +/-   ##
==========================================
- Coverage   14.85%   14.54%   -0.31%
==========================================
  Files          48       48
  Lines        2835     2894      +59
==========================================
  Hits          421      421
- Misses       2385     2444      +59
  Partials       29       29

Impacted Files
Coverage Δ

pkg/util/zip.go
0.00% <0.00%> (ø)


Undo docker pin

Don't force Docker to be kept at version 18.06 (to ensure devicemapper is available). This feature won't be re-added by Docker and remaining on an old version of Docker is not good from a security perspective.
Replace the pinning with a note pointing users at an issue which provides details of alternatives to devicemapper.
Fixes #407.
Signed-off-by: James O. D. Hunt<EMAIL_ADDRESS>

@marcov - Any thoughts on the wording for openSUSE and SLES (regarding your comment https://github.com/kata-containers/documentation/pull/374#issuecomment-460716197)? Do SUSE intend to continue to backport devicemapper beyond docker 18.09?
Ping @kata-containers/documentation.