Move json reader where it is used

Json reader is specifically made for and used by StudyUpdater

This pull request includes several changes to the CMakeLists and source files to reorganize and update the JsonXpansionReader component. The most important changes involve moving the JsonXpansionReader from the helpers module to the study-updater module, updating include paths, and adjusting related tests.
Reorganization and Updates:

File Moves and Include Path Updates:

Moved JsonXpansionReader.cpp from src/cpp/helpers to src/cpp/study-updater and updated its include paths accordingly. (src/cpp/study-updater/JsonXpansionReader.cpp, src/cpp/study-updater/LinkParametersCSVOverwriter.cpp, src/cpp/study-updater/StudyUpdater.cpp) [1] [2] [3]

CMakeLists Adjustments:

Removed JsonXpansionReader.cpp from src/cpp/helpers/CMakeLists.txt and added it to src/cpp/study-updater/CMakeLists.txt. (src/cpp/helpers/CMakeLists.txt, src/cpp/study-updater/CMakeLists.txt) [1] [2]
Updated target_include_directories to include private headers for study_updater_test. (src/cpp/study-updater/CMakeLists.txt)

Testing Adjustments:

Test File Reorganization:

Removed JsonXpansionReaderTest.cc from helpers_test and added it to study_updater_test. (tests/cpp/helpers/CMakeLists.txt, tests/cpp/study_updater/CMakeLists.txt) [1] [2]
Updated JsonXpansionReaderTest to use new paths and included it in the study_updater_test executable. (tests/cpp/helpers/JsonXpansionReaderTest.cc, tests/cpp/study_updater/JsonXpansionReaderTest.cc) [1] [2]

Removal of Redundant Entries:

Redundant Source and Header Removals:

Removed redundant entries for LinkParametersCSVOverwriter.cpp and StudyUpdateStrategy.cpp from src/cpp/study-updater/CMakeLists.txt. (src/cpp/study-updater/CMakeLists.txt)

Test Configuration:

Test Directory Addition:

Added study_updater subdirectory to the test configuration. (tests/cpp/CMakeLists.txt)

These changes are aimed at better organizing the codebase and ensuring that the JsonXpansionReader component and its related tests are correctly placed within the study-updater module.


Error [ERR_MODULE_NOT_FOUND] running "npm run relay"

I can barely comprehend a company such as OpenAI publishing a repo like this for a flagship product feature that does not work out of the box.
import { RealtimeRelay } from './lib/relay.js';

...causes a module import error.

My fault! Broke this a little over an hour ago with: https://github.com/openai/openai-realtime-console/commit/7c5a173e10e595849d00c5e7f5db41a3fe5c8704
Fixed with: https://github.com/openai/openai-realtime-console/commit/851eb3165f47d44a534a4575d53a503e425477a5
Thanks for flagging!


ESP-IDF 3.1 release date

The lack of low power mode for BLE is a major blocker for my company.
Is low power BLE supported in ESP-IDF 3.1?
Can we get an estimated release date?
#1242
#947
Thanks!

Very important for me as well. Forum threads and issues have gone unanswered on this for many weeks now, where previously it was stated that this would be available near end of February. Can we please get an update?

I contacted Espressif via email and they said April/May timeframe


Zhenyangg/frontend UI

We can't merge this into master branch. This should be a branch of it's own so others can use it out of the box.

Could you add a description to your PR please @GiorgiSheklashvili


Add Select, Radiobutton and Textarea to Form

Todo

extend <Form /> component with select, radio button and textarea
check usage and accessibility
if there are possible improvements, sync with console team

Can be closed, both were not needed in that exact form :D


The given key 'PaperSprayIonization' was not present in the dictionary

While trying out conversion of a raw file from a Thermo Fisher Scientific VeriSpray PaperSpray instrument, I noticed the exception in the title. I would have submitted a PR, but I don't know where the accession value comes from.
IonizationModeType.PaperSprayIonization, new CVParamType
{
    accession = "MS:???????",
    name = "paper spray ionization",
    cvRef = "MS",
    value = ""
}

Hi @abdelq ,
Thank you for your interest in ThermoRawFileParser. The accession is defined in PSI-MS controlled vocabulary (CV).
The vocabulary is maintained in https://github.com/HUPO-PSI/psi-ms-CV in OBO format. After a brief lookup, it seems like paper spray ionization is not present yet in the vocabulary. You can either add a new term in the vocabulary (you can just do PR there with the update), or check if some synonym already available in the vocabulary can be used instead.
As a side note, if you add a new CV term, there will be some delay between the time it will be accepted to the PSI-MS CV and the updated version of CV will reach the common software tools and libraries. For example, it might mean that the resulting files will be considered invalid by older versions of proteowizard (and all tools using it).
Just to clarify, I am fine with adding support for PaperSpray to TRFP, just want to make you aware that there might be issues with downstream analysis of the resulting mzML files.

Hi everyone, the new term is merged into the CV:
https://github.com/HUPO-PSI/psi-ms-CV/pull/100/files


Add forced update feature

This would prevent a user from using the app if the version is too old
We decided the implementation of this should be as follows:

[ ] We check for an error returned by events_register with some specific error code that means "You need to upgrade"
[ ] Additionally, we add a new small endpoint on zulipchat.com (or configurable app endpoint) that is passed the current zulip-mobile app version and returns whether it needs to upgrade or not.  Tim can quickly write the backend endpoint as soon as we're ready to work on this.

@neerajwahi @timabbott We'll treat P1 as non final, so delaying this to P2.

I think we decided the implementation of this should be as follows:

[ ] We check for an error returned by events_register with some specific error code that means "You need to upgrade"
[ ] Additionally, we add a new small endpoint on zulipchat.com that is passed the current zulip-mobile app version and returns whether it needs to upgrade or not.  Tim can quickly write the backend endpoint as soon as we're ready to work on this.

@timabbott Is the api ready for this?

Haven't worked on this yet; what do you think we should call the endpoint?  That's basically the hard part :)

@timabbott Do we intend to use both approaches? events_register and and API call?
Why we need both?
I suggest we have the call called something like 'compatibility`.
We should also do soon the code push part where we upgrade the JS without app needing update.
Additionally we should notify about the optional updates.
So stages are:

JS only updates. Silently upgrade.
Compatible upgrades. Some notifications.
Server is incompatible. Force upgrade.

BTW app version is already passed via the User-Agent headers.

Opened https://github.com/zulip/zulip-mobile/issues/257 for making the User-Agent match our other stuff.
I'll add a quick endpoint that always returns success at /compatibility.

I test-deployed https://github.com/timabbott/zulip/commit/d0d7dbfde285228aac3c465850a0a91cd172ccff to chat.zulip.org; can you verify that works @borisyankov?  You can test success as normal, and failure using ZulipInvalid/5.0 as the User-Agent.  Note that it expects the user-agent format I suggested in #257.

@borisyankov I think we need both events_register a separate API call on a fixed endpoint because they serve different use cases. The events_register endpoint lets a server admin enforce a minimum version, whereas the API call (to a fixed endpoint) allows an app publisher (for example, Kandra Labs) to force an update for all users regardless of realm.
I agree we eventually want JS only updates (with something like CodePush), but let's focus on a simple 'You need to upgrade this app' function first.

@timabbott What do you think about the last @neerajwahi comment. Is that the intent?
Do we want to differentiate between the api/register and /compatibility in that sense?

OK, after thinking about this more I think this is the actual proposal we want:

/compatibility would be queried against https://zulipchat.com to allow us as app publishers to force everyone to upgrade from e.g. a broken version.  I guess this should happen in the background on app startup.
The /api/v1/register endpoint would be queried against the actual server they're using (zulip.example.com) case would be an error code we handle in that endpoint that's about whether the app is new enough to connect to a particular server (so that a specific server or Zulip version can expect something in particular).

I will add the api call url to the config.js, on fail I'll show a screen that has no back button, telling them to upgrade.


Replace path with pathe

This is a simple way of getting rid of node path references in common and engine. I thought it best to also replace it in vscode so we don't have different implementations for path in the bundle. I guess for things like running tests and ours setup scrips then just using node path is probably fine? I could go either way.
https://www.npmjs.com/package/pathe
Checklist

[/] I have added tests
[/] I have updated the docs and cheatsheet
[/] I have not broken the cheatsheet

Totally in agreements there


(ISO 8601-1/Amd 1) Word: Approval group without subcommittee should not show double slashes in identifier

Metadata:
:technical-committee-number: 154
:technical-committee: Processes, data elements and documents in commerce, industry and administration
:workgroup-type: WG
:workgroup-number: 5
:workgroup: Date and time

Should be:
"Committee identification: ISO/TC 154/WG 5"
Not:
"Committee identification: ISO/TC 154//WG 5"

Confirm fixed, it used to be Committee identification: ISO/TC 211// in ISO 19144-2.


Add readlink util

The Windows version substantially performs its duties but does not always have responses in the exact same format as the uutils version (e.g., file not found). Also, Windows requires more elevated permissions to clean up after tests. Will have to be revisited.


Failed to train model trained by mxnet 1.0 in mxnet 2.0

i upgrade mxnet version from 1.0 to 2.0. I load the model which is trained at 1.0  in mxnet 2.0, and when i train the model, it came across the situation that it stops after 30 batches, which seems to be hanged.
can somebody help me?
Any help make me appreciate it.

@moveforever in order to others to help, you will need to provide the information for others to reproduce the problem you see. Consider using the following template.
## Description
(A clear and concise description of what the bug is.)

### Error Message
(Paste the complete error message. Please also include stack trace by setting environment variable `DMLC_LOG_STACK_TRACE_DEPTH=10` before running your script.)

## To Reproduce
(If you developed your own code, please provide a short script that reproduces the error. For existing examples, please provide link.)

### Steps to reproduce
(Paste the commands you ran that produced the error.)

1.
2.

## What have you tried to solve it?

1.
2.

## Environment

We recommend using our script for collecting the diagnositc information. Run the following command and paste the outputs below:
`curl --retry 10 -s https://raw.githubusercontent.com/dmlc/gluon-nlp/master/tools/diagnose.py | python`

# paste outputs here

Description
i upgrade mxnet version from 1.0 to 2.0. I load the model which is trained at 1.0 in mxnet 2.0, and when i train the model, it came across the situation that it stops after 30 batches, which seems to be hanged.
Error Message
(Paste the complete error message. Please also include stack trace by setting environment variable DMLC_LOG_STACK_TRACE_DEPTH=10 before running your script.)
There is no error information, and it seems to be hanged!
+ export DMLC_LOG_STACK_TRACE_DEPTH=10
+ DMLC_LOG_STACK_TRACE_DEPTH=10
+ curl --retry 10 -s https://raw.githubusercontent.com/dmlc/gluon-nlp/master/tools/diagnose.py
+ /thirdparty/bin/python3 src/train.py
INFO:root:current path is: /cephfs/group/omg-omgmobile-app-tencent-sports/qomozheng/project/mult
i_obj_opt
20
INFO:root:['dense', 'cate', 'sparse', 'field_0', 'field_1', 'field_2', 'field_3', 'field_4', 'fi
eld_5', 'field_6']
INFO:root:only use embedding model
[10:37:49] src/base.cc:51: Upgrade advisory: this mxnet has been built against cuda library vers
ion 9010, which is older than the oldest version tested by CI (10000).  Set MXNET_CUDA_LIB_CHECK
ING=0 to quiet this warning.
INFO:root:Training started ...
INFO:root:Epoch[0] Batch [0-10]        Speed: 1817.71 samples/sec      auc=0.500820    multi_log
loss=10.058306 multi_mse=0.000000
INFO:root:batch=10, forward_backward=21ms, update=174ms, update_metric=6679ms, data=15703ms, tot
al=22579ms
INFO:root:Epoch[0] Batch [10-20]       Speed: 3873.38 samples/sec      auc=0.513181    multi_log
loss=7.157333  multi_mse=0.974069
INFO:root:batch=20, forward_backward=17ms, update=185ms, update_metric=4430ms, data=5941ms, tota
l=10574ms
INFO:root:Epoch[0] Batch [20-30]       Speed: 4769.79 samples/sec      auc=0.539163    multi_log
loss=4.971608  multi_mse=0.000000
INFO:root:batch=30, forward_backward=13ms, update=121ms, update_metric=3803ms, data=4648ms, tota
l=8586ms

To Reproduce
(If you developed your own code, please provide a short script that reproduces the error. For existing examples, please provide link.)
Steps to reproduce
(Paste the commands you ran that produced the error.)

What have you tried to solve it?

Environment
cuda-9.0
gcc 8.4
centos 7.2
python 3.7
We recommend using our script for collecting the diagnositc information. Run the following command and paste the outputs below:
curl --retry 10 -s https://raw.githubusercontent.com/dmlc/gluon-nlp/master/tools/diagnose.py | python
There is no information, and it seems to be hanged.
paste outputs here

@zhreshold

I implement a DataIter through c++ mxnet source code to support multi-storage and multi-label sample as followed, and it runs well at mxnet.

@moveforever Can you provide the implementation of the DataIter?

The related code is listed in https://github.com/apache/incubator-mxnet/issues/18346.
The dataiter can be iterated. however, it appear that only iterates 20-30 batch then stops when i upgradded to mxnet2.0.


Azure Kinect Compatibility

Hello,
I have installed the Windows Binaries under https://s3.amazonaws.com/com.occipital.openni/OpenNI-Windows-x64-<IP_ADDRESS>.zip
But the applications under 'Samples' like SimpleViewer.exe cannot detect my connected Azure Kinect.
What do I have to do?
I have made modifications to OpenNI.ini by adding
Repository=OpenNI2/Drivers
and PS1080.ini
I have also tried putting the k4a .dlls inside the Drivers folder.
Any suggestions are welcome and appreciated.

Hey,
facing the same issues with my Azure Kinect and wanted to know if you came up with a solution?


Update README.md

Minor fix for the deprecated command (might be Craft 4 only?)

Thanks @sunscreem, merging this!


Add Python "slice" notation to Calc

slice(a,2) would be a[2:] and so forth

Well, first "naive" attempt to add this gives an Antler error:
error(119): Calc.g4::: The following sets of rules are mutually left-recursive [expr, builtinFunction, var]

Trying again ....

Ah, adding "slice" inside "var" makes it work. Needs much work inside LValueContext then ...

Need to test, but probably "slice" itself can now go away. Still need to add doc to the help page, and beefing up the possibility of null values would help also with understanding (like how it fits with "index" and so on).


Test: Git - optimistic updates

Refs: https://github.com/microsoft/vscode/issues/162481

[ ] anyOS @digitarald
[ ] anyOS @aeschli

Complexity: 3
Create Issue

When performing various operations in the "Source Control" view, we would execute the git command, follow which we would run various git commands (ex: git status) to update the model before refreshing the various UI elements (ex: commit input, resource list) in the "Source Control" view.
This milestone we have made changes to that the UI gets refreshed optimistically after the git command is executed. We would still run the various git commands to update the model but that happens in the background and should not result in any UI changes. The following commands should feel much snappier: state, un-stage, discard, commit.
Prerequisites

Install the latest VS Code Insiders
Ensure that git.optimisticUpdate is set to true
Clone a large monorepo (ex: https://github.com/torvalds/linux)

Testplan

Open folder/workspace that contains a git monorepo
Make changes to existing files, and add couple of new files
Switch to the "Source Control" view
Stage single file/multiple file in quick succession/all files

Confirm that changes to the resources list are immediate

Un-stage single file/multiple files in quick succession/all files

Confirm that changes to the resources list are immediate

Discard changes for a single file/multiple files in quick succession/all files

Confirm that changes to the resources list are immediate

Enter a commit message, hit the commit button

Confirm that changes to the resources list are immediate

Tested on Windows 11. Works beautifully!
BTW to check out https://github.com/torvalds/linux in Windows: https://stackoverflow.com/questions/63727594/github-git-checkout-returns-error-invalid-path-on-windows


Update dependency axios to 1.2.1

This PR contains the following updates:

Package
Type
Update
Change

axios (source)
dependencies
major
^0.27.2 -> ^1.0.0

Release Notes

axios/axios
v1.2.1
Compare Source
Changed

feat(exports): export mergeConfig #5151

Fixed

fix(CancelledError): include config #4922
fix(general): removing multiple/trailing/leading whitespace #5022
fix(headers): decompression for responses without Content-Length header #5306
fix(webWorker): exception to sending form data in web worker #5139

Refactors

refactor(types): AxiosProgressEvent.event type to any #5308
refactor(types): add missing types for static AxiosError.from method #4956

Chores

chore(docs): remove README link to non-existent upgrade guide #5307
chore(docs): typo in issue template name #5159

Contributors to this release

Dmitriy Mozgovoy
Zachary Lysobey
Kevin Ennis
Philipp Loose
secondl1ght
wenzheng
Ivan Barsukov
Arthur Fiorette

v1.2.0
Compare Source
Changed

changed: refactored module exports #5162
change: re-added support for loading Axios with require('axios').default #5225

Fixed

fix: improve AxiosHeaders class #5224
fix: TypeScript type definitions for commonjs #5196
fix: type definition of use method on AxiosInterceptorManager to match the the README #5071
fix: __dirname is not defined in the sandbox #5269
fix: AxiosError.toJSON method to avoid circular references #5247
fix: Z_BUF_ERROR when content-encoding is set but the response body is empty #5250

Refactors

refactor: allowing adapters to be loaded by name #5277

Chores

chore: force CI restart #5243
chore: update ECOSYSTEM.md #5077
chore: update get/index.html #5116
chore: update Sandbox UI/UX #5205
chore:(actions): remove git credentials after checkout #5235
chore(actions): bump actions/dependency-review-action from 2 to 3 #5266
chore(packages): bump loader-utils from 1.4.1 to 1.4.2 #5295
chore(packages): bump engine.io from 6.2.0 to 6.2.1 #5294
chore(packages): bump socket.io-parser from 4.0.4 to 4.0.5 #5241
chore(packages): bump loader-utils from 1.4.0 to 1.4.1 #5245
chore(docs): update Resources links in README #5119
chore(docs): update the link for JSON url #5265
chore(docs): fix broken links #5218
chore(docs): update and rename UPGRADE_GUIDE.md to MIGRATION_GUIDE.md #5170
chore(docs): typo fix line #856 and #920 #5194
chore(docs): typo fix #800 #5193
chore(docs): fix typos #5184
chore(docs): fix punctuation in README.md #5197
chore(docs): update readme in the Handling Errors section - issue reference #5260 #5261
chore: remove \b from filename #5207
chore(docs): update CHANGELOG.md #5137
chore: add sideEffects false to package.json #5025

Contributors to this release

Maddy Miller
Amit Saini
ecyrbe
Ikko Ashimine
Geeth Gunnampalli
Shreem Asati
Frieder Bluemle
윤세영
Claudio Busatto
Remco Haszing
Dmitriy Mozgovoy
Csaba Maulis
MoPaMo
Daniel Fjeldstad
Adrien Brunet
Frazer Smith
HaiTao
AZM
relbns

v1.1.3
Compare Source
Added

Added custom params serializer support #5113

Fixed

Fixed top-level export to keep them in-line with static properties #5109
Stopped including null values to query string. #5108
Restored proxy config backwards compatibility with 0.x #5097
Added back AxiosHeaders in AxiosHeaderValue #5103
Pin CDN install instructions to a specific version #5060
Handling of array values fixed for AxiosHeaders #5085

Chores

docs: match badge style, add link to them #5046
chore: fixing comments typo #5054
chore: update issue template #5061
chore: added progress capturing section to the docs; #5084

Contributors to this release

Jason Saayman
scarf
Lenz Weber-Tronic
Arvindh
Félix Legrelle
Patrick Petrovic
Dmitriy Mozgovoy
littledian
ChronosMasterOfAllTime

v1.1.2
Compare Source
Fixed

Fixed broken exports for UMD builds.

Contributors to this release

Jason Saayman

v1.1.1
Compare Source
Fixed

Fixed broken exports for common js. This fix breaks a prior fix, I will fix both issues ASAP but the commonJS use is more impactful.

Contributors to this release

Jason Saayman

v1.1.0
Compare Source
Fixed

Fixed missing exports in type definition index.d.ts #5003
Fixed query params composing #5018
Fixed GenericAbortSignal interface by making it more generic #5021
Fixed adding "clear" to AxiosInterceptorManager #5010
Fixed commonjs & umd exports #5030
Fixed inability to access response headers when using axios 1.x with Jest #5036

Contributors to this release

Trim21
Dmitriy Mozgovoy
shingo.sasaki
Ivan Pepelko
Richard Kořínek

v1.0.0
Compare Source
Added

Added stack trace to AxiosError #4624
Add AxiosError to AxiosStatic #4654
Replaced Rollup as our build runner #4596
Added generic TS types for the exposed toFormData helper #4668
Added listen callback function #4096
Added instructions for installing using PNPM #4207
Added generic AxiosAbortSignal TS interface to avoid importing AbortController polyfill #4229
Added axios-url-template in ECOSYSTEM.md #4238
Added a clear() function to the request and response interceptors object so a user can ensure that all interceptors have been removed from an axios instance #4248
Added react hook plugin #4319
Adding HTTP status code for transformResponse #4580
Added blob to the list of protocols supported by the browser #4678
Resolving proxy from env on redirect #4436
Added enhanced toFormData implementation with additional options 4704
Adding Canceler parameters config and request #4711
Added automatic payload serialization to application/x-www-form-urlencoded #4714
Added the ability for webpack users to overwrite built-ins #4715
Added string[] to AxiosRequestHeaders type #4322
Added the ability for the url-encoded-form serializer to respect the formSerializer config #4721
Added isCancel type assert #4293
Added data URL support for node.js #4725
Adding types for progress event callbacks #4675
URL params serializer #4734
Added axios.formToJSON method #4735
Bower platform add data protocol #4804
Use WHATWG URL API instead of url.parse() #4852
Add ENUM containing Http Status Codes to typings #4903
Improve typing of timeout in index.d.ts #4934

Changed

Updated AxiosError.config to be optional in the type definition #4665
Updated README emphasizing the URLSearchParam built-in interface over other solutions #4590
Include request and config when creating a CanceledError instance #4659
Changed func-names eslint rule to as-needed #4492
Replacing deprecated substr() with slice() as substr() is deprecated #4468
Updating HTTP links in README.md to use HTTPS #4387
Updated to a better trim() polyfill #4072
Updated types to allow specifying partial default headers on instance create #4185
Expanded isAxiosError types #4344
Updated type definition for axios instance methods #4224
Updated eslint config #4722
Updated Docs #4742
Refactored Axios to use ES2017 #4787

Deprecated

There are multiple deprecations, refactors and fixes provided in this release. Please read through the full release notes to see how this may impact your project and use case.

Removed

Removed incorrect argument for NetworkError constructor #4656
Removed Webpack #4596
Removed function that transform arguments to array #4544

Fixed

Fixed grammar in README #4649
Fixed code error in README #4599
Optimized the code that checks cancellation #4587
Fix url pointing to defaults.js in README #4532
Use type alias instead of interface for AxiosPromise #4505
Fix some word spelling and lint style in code comments #4500
Edited readme with 3 updated browser icons of Chrome, FireFox and Safari #4414
Bump follow-redirects from 1.14.9 to 1.15.0 #4673
Fixing http tests to avoid hanging when assertions fail #4435
Fix TS definition for AxiosRequestTransformer #4201
Fix grammatical issues in README #4232
Fixing instance.defaults.headers type #4557
Fixed race condition on immediate requests cancellation #4261
Fixing Z_BUF_ERROR when no content #4701
Fixing proxy beforeRedirect regression #4708
Fixed AxiosError status code type #4717
Fixed AxiosError stack capturing #4718
Fixing AxiosRequestHeaders typings #4334
Fixed max body length defaults #4731
Fixed toFormData Blob issue on node>v17 #4728
Bump grunt from 1.5.2 to 1.5.3 #4743
Fixing content-type header repeated #4745
Fixed timeout error message for http 4738
Request ignores false, 0 and empty string as body values #4785
Added back missing minified builds #4805
Fixed a type error #4815
Fixed a regression bug with unsubscribing from cancel token; #4819
Remove repeated compression algorithm #4820
The error of calling extend to pass parameters #4857
SerializerOptions.indexes allows boolean | null | undefined #4862
Require interceptors to return values #4874
Removed unused imports #4949
Allow null indexes on formSerializer and paramsSerializer #4960

Chores

Set permissions for GitHub actions #4765
Included githubactions in the dependabot config #4770
Included dependency review #4771
Update security.md #4784
Remove unnecessary spaces #4854
Simplify the import path of AxiosError #4875
Fix Gitpod dead link #4941
Enable syntax highlighting for a code block #4970
Using Logo Axios in Readme.md #4993
Fix markup for note in README #4825
Fix typo and formatting, add colons #4853
Fix typo in readme #4942

Security

Update SECURITY.md #4687

Contributors to this release

Bertrand Marron
Dmitriy Mozgovoy
Dan Mooney
Michael Li
aong
Des Preston
Ted Robertson
zhoulixiang
Arthur Fiorette
Kumar Shanu
JALAL
Jingyi Lin
Philipp Loose
Alexander Shchukin
Dave Cardwell
Cat Scarlet
Luca Pizzini
Kai
Maxime Bargiel
Brian Helba
reslear
Jamie Slome
Landro3
rafw87
Afzal Sayed
Koki Oyatsu
Dave
暴走老七
Spencer
Adrian Wieprzkowicz
Jamie Telin
毛呆
Kirill Shakirov
Rraji Abdelbari
Jelle Schutter
Tom Ceuppens
Johann Cooper
Dimitris Halatsis
chenjigeng
João Gabriel Quaresma
Victor Augusto
neilnaveen
Pavlos
Kiryl Valkovich
Naveen
wenzheng
hcwhan
Bassel Rachid
Grégoire Pineau
felipedamin
Karl Horky
Yue JIN
Usman Ali Siddiqui
WD
Günther Foidl
Stephen Jennings
C.T.Lin
mia-z
Parth Banathia
parth0105pluang
Marco Weber
Luca Pizzini
Willian Agostini
Huyen Nguyen

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 is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

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

This PR has been generated by Renovate Bot.

@balena-ci rebase


Let's use isort

We have a proposed ADR: https://adr.archivematica.org/0004-isort-import-ordering.html in general I do think it makes life easier, and it's one less thing to make CR subjective. And one less thing to introduce inconsistency across modules.
I ran pylint before and after, and the score was nice to read:

Cmd: artefactual-labs/AIPscan/AIPscan$ isort $(find * | grep .py$)
Pylint output: Your code has been rated at 7.32/10 (previous run: 6.99/10, +0.33)

Okay, sounds good. Should we run it as one repo-wide batch and merge? Too bad we don't have tests to run afterwards. I'm a little concerned about circular imports (e.g. an import being called too early/late). I ran into these when re-factoring to blueprints. But that was basically confined to this file: https://github.com/artefactual-labs/AIPscan/blob/main/AIPscan/init.py So I know where to look if things break after the isort.

Should we run it as one repo-wide batch and merge?

Perfect!
Minus __init__.py
Hehe! I can can confirm that circular imports in that file will cause a problem, but also, I think that just means initially, we can leave that particular __init__.py out of the isort mix.
I feel it would be good to get the circular imports resolved in time too. I tend to look at these as clues for improving architecture. I did have a look last night before I saw your update. I'm not familiar enough with the code yet to know the objects and the way they're being passed around to have a solution for this. I started looking at this blog which gives an SQLAlchemy example but I didn't quite complete that trail of thought before moving onto another piece. It looks like maybe the celery context manager is the only other one impacted. I'll read up a little more on the Blueprint and factory pattern.

With linting errors now resolved I had a brief look into this. It seems like the main concern is making isort compatible with Black, however, with these options the isort defaults may be good enough (should be, i.e. it is less effort to maintain and already de-facto standardised).
The output of a draft PR for this is here and it all looks fairly sensible. cc. @tw4l @peterVG

@ross-spencer I just left a review for the PR and appreciate the extra detail from your last comment here! The PR looks ready to merge to me. Nice work!

@ross-spencer I just left a review for the PR and appreciate the extra detail from your last comment here! The PR looks ready to merge to me. Nice work!

Closed via https://github.com/artefactual-labs/AIPscan/pull/105


Add checkout to saleor-platform

The goal of saleor-platform, as far as I know, is to enable booting up all the Saleor applications with one command.
Since we are introducing new applications to the Saleor suite, we should think about adding them to the saleor-platform as well.
Right now, we only boot up react-storefront on port 3001, but the application also contains:

apps/saleor-app-checkout: http://localhost:3001/
packages/checkout-storefront: http://localhost:3002/
packages/ui-kit storybook: http://localhost:6006/

Done in https://github.com/saleor/saleor-platform/pull/192

Tested by @zaiste


Form builder as StreamField block

Is it possible?

+1

:+1:

I'd be very happy to see this implemented. I suppose the big open question is how form submissions can be handled - on the existing form builder, submissions are POSTed to the page's own URL, but an individual StreamField block doesn't have a URL of its own, or anything that can persistently identify it.

+1!
Looking to implement this myself and may just give it a shot. Any feedback on the structure below?
How about setting up a FormBuilder block that, regardless of page it is rendered on, submits to a single site-wide url that takes the PK as a GET param? Much like the URL that page previews rely on, perhaps a unique sequence of symbols that would almost never be replicated would

I would let the developer decide where the form gets submitted to. In some cases, submitting to the current page itself would be appropriate - if the page has extended the Wagtail form builder base class. In other cases, submitting to a central URL, as in your example; or even a completely different page on a different domain such as a MailChimp subscription could be appropriate. Finally, the form could be AJAXified for completely different behaviour, meaning that it never gets submitted anywhere in particular.
If the developer is left to write a template that handles submitting the form, they can write the code that suits their use case very easily:
<form action="{{self.url}}" method="post">
    {{ self.stream_body }}
    <input type="submit">
</form>

<form action="/custom-search-page/" method="get">
    {{ self.custom_search_form }}
    <input type="submit">
</form>

<form action="http://email.example.com/subscribe/" method="post">
    {{ self.body_with_subscribe_fields }}
    <input type="submit">
</form>

I found myself needing this feature and so I have an implementation. Basically there is a FormFieldBlock that can be added to a StreamField. The page has to inherit from AbstractForm so that form processing happens and it must also include a mixin that pulls the FormFieldBlock "instances" out of the StreamField value to build the form. Submission then happens the same way as a normal AbstractForm. Though the way I have accomplished this may feel a bit hackish.
You can see my implementation here: https://github.com/didorothy/wagtail/tree/streamfieldforms
Some key files to look at would be:

https://github.com/didorothy/wagtail/blob/streamfieldforms/wagtail/tests/testapp/models.py around line 344 where it shows how to set up the Page child class.
https://github.com/didorothy/wagtail/blob/streamfieldforms/wagtail/wagtailforms/forms.py line 117 where the fields for the form are "discovered."

Template rendering requires a special tag, which I don't really have an example of in the code yet.There is a test case to demonstrate that the tag works but it leaves out several actual details.
I'd submit a pull request but it needs more unit tests (I think mainly to prove that form submission and template rendering work) and I need to provide some documentation for how to set things up.
I'd like to get some feedback to see if I am on the right track. If I'm headed the right direction I will try to finish up the stuff next week and submit a pull request.

I was a little later than expected but I have submitted a PR with how I propose that this can be accomplished. I am a bit new to git (though I have used SVN and Mercurial for some time) and I'm not sure I have done everything correctly for a Pull Request. Also, I ran tests with Django 1.9 and Python 3.5 on windows. I may try to set up a VM to do additional testing if needed but I would probably have to do this on another machine as the one I'm using does not have enough RAM to do so effectively.
If I need to address anything let me know.

Just realise i put my comments on a pr and not a thread so:
We also required this and have a concept to our requirements. Though very early days or more hours. We have come up with the following. Documentation is currently under way but the highlights are below an maybe useful for ideas:

Forms can be build in the cms admin and used site wide in any streamfield.
You can create your own form templates to display/submit how ever you wish to do it.
We have included a mixin which will handle the form post if it is being submitted to a wagtail page.
Forms are catagorised by their class in the cms admin for easier navigation.
Form submissions are also listed by their form which you can filter by date and are ordered by newest first.
Recaptcha can be added to a form.
You can also add site wide regex validators for use in regex fields.

https://github.com/AccentDesign/wagtail_streamforms
Stu

@stuartaccent Good work!

cheers @SalahAdDin, not 100% and def needs more work, but is a good starting point for us any road.
theres a couple of snaggs like handling errors for multiple forms of same type in same page and multiple recaptchas in same page. though not sure if there is a use case for either of these.
may help someone else out

As part of the Wagtail’s first Kickstarter campaign, I’m working on this!
https://www.kickstarter.com/projects/noripyt/wagtails-first-hatch

I’m going to close this in favour of #4485, which seems to be pretty much about the same thing, and covers the most recent changes in this area.


test PR with Github API

Please pull this in!

Docs Build status updates of commit a24afdb:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details
Dependent Files

sdp-test/index.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit 9554655:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details
Dependent Files

sdp-test/index.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit 67dc621:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details
Dependent Files

sdp-test/index.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit f4ce377:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details
Dependent Files

sdp-test/index.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit 97b8bd7:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details
Dependent Files

sdp-test/index.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit 7821998:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details
Dependent Files

sdp-test/index.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit 990e98d:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details
Dependent Files

sdp-test/index.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit ff76fe1:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details
Dependent Files

sdp-test/index.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit 9fb2d05:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details
Dependent Files

sdp-test/index.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Format string contains an unescaped latin alphabet character n in MUI date picker.

I have just copied and pasted the code from the MUI website into codesand box and i got the error Format string contains an unescaped Latin alphabet character n.
Steps to Reproduce 🕹
Steps: check this live codesandbox Check Live
Your Environment 🌎
Windows 10 and the latest chrome version.
Current MUI version,

@Ats1999
Read here
For material-ui-pickers v3 use v1.x version of @date-io adapters.
npm i<EMAIL_ADDRESS>date-fns
// or
npm i<EMAIL_ADDRESS>moment
// or
npm i -s<EMAIL_ADDRESS>luxon
// or
npm i -s<EMAIL_ADDRESS>dayjs

Also, go through this issue.
material-ui-pickers/issues/1440

Thanks.


Explicitly set window background color

Resolves issue #192

Looks good to me 👍
Ogmo really does need a dark mode though!


misspelling

@IzzySoft

Fixed with the next sync, thanks!
May I recommend setting up Fastlane structures here, so the authors themselves can control how their app is presented? I gladly provide a "starter package" with what I've set up in my repo currently – and there's always my Fastlane Cheat Sheet for guidance. Changes would then be pulled along with each new release.

@v1tzor so would you accept my offer, or consider the idea of having Fastlane established here?

I'll set up Fastlane later

OK, thanks! Please also remember to increase versionCode with each release – seems like you forgot this time:
Binary files /web/ftp/repo/fdroid/repo/ru.aleshin.timeplanner_5.apk and /web/ftp/repo/fdroid/repo/ru.aleshin.timeplanner_0.4.0-beta.apk differ

This means the current release has the same versionCode (5) as the previous one already used, so whoever already has the p installed won't receive any update notification for this release.


Razer Nari Essential Headphones not showing

only my mouse which is razer basilisk ultimate is showing

I updated to synapse 4 and it shows 50 - but not less

Hey,
Could you please share your log and your "real" battery state at the time you saved the log?
%LOCALAPPDATA%\Razer\Synapse3\Log\Razer Synapse 3.log for Razer Synapse 3
%LOCALAPPDATA%\Razer\RazerAppEngine\User Data\Logs\systray_systrayv2.log for Razer Synapse 4

thank you for the solution
it worked


[widbt] - fixes widget not showing on blue background

I didn't even think about that for screens that have more than 3bit color. What color format is the theme system using?

It uses 16bit RGB565. Even if you're not using 3 bit sometimes you might specify something non-3 bit in order to dither though. It's a hard one as I don't think I have a way of getting back to the "#RGB" format - I think your solution is ok for now.

Sounds like we need to check against a range of values close to the widget colors and if it's in that range make it use a dissimilar color.
The battery widget would also need something similar for green backgrounds.

Yes, although for the battery widget I was wondering if we should just make the BG color white/black always - so even on green it's easily visible?

Yes, although for the battery widget I was wondering if we should just make the BG color white/black always - so even on green it's easily visible?

I think that would be okay.
How about this for a concept? - A module that checks if a RGB565 color is predominantly green or blue and returns true if it is:
/*
This module provides utility functions for color analysis. Specifically, it can determine
whether a given color is predominantly green or blue.
*/

// The ColorUtils constructor function
function ColorUtils() {
}

// The isBlueHue method checks if the blue component of a color is greater than both the green and red components
ColorUtils.prototype.isBlueHue = function(color) {
  // Gets the blue component by masking the color with 0x1F
  const blueComponent = color & 0x1F;
  // Shifts 5 bits to the right (discarding blue bits) and masks with 0x3F to get the green component
  const greenComponent = (color >> 5) & 0x3F;
  // Shifts 11 bits to the right (discarding blue and green bits) and masks with 0x1F to get the red component
  const redComponent = (color >> 11) & 0x1F;
  // Checks if the color is predominantly blue
  return blueComponent > greenComponent && blueComponent > redComponent;
};

// The isGreenHue method checks if the green component of a color is greater than both the blue and red components
ColorUtils.prototype.isGreenHue = function(color) {
  // Gets the blue component by masking the color with 0x1F
  const blueComponent = color & 0x1F;
  // Shifts 5 bits to the right (discarding blue bits) and masks with 0x3F to get the green component
  const greenComponent = (color >> 5) & 0x3F;
  // Shifts 11 bits to the right (discarding blue and green bits) and masks with 0x1F to get the red component
  const redComponent = (color >> 11) & 0x1F;
  // Checks if the color is predominantly green
  return greenComponent > blueComponent && greenComponent > redComponent;
};

/** This is 'exported' so it can be used with `require('ColorUtils.js')` */
exports = ColorUtils;

And then the widbt code could look something like this:
var ColorUtils = require('ColorUtils.js');

WIDGETS["bluetooth"]={area:"tr",width:15,draw:function() {
  g.reset();
  var colorUtils = new ColorUtils();
  if (NRF.getSecurityStatus().connected) {
    if (colorUtils.isBlueHue(g.theme.bg)) {
      g.setColor("#0ff");
    } else {
      g.setColor((g.getBPP()>8) ? "#07f" : (g.theme.dark ? "#0ff" : "#00f"));
    }
  } else {
    g.setColor(g.theme.dark ? "#666" : "#999");
  }
  g.drawImage(atob("CxQBBgDgFgJgR4jZMawfAcA4D4NYybEYIwTAsBwDAA=="),2+this.x,2+this.y);
},changed:function() {
  WIDGETS["bluetooth"].draw();
}};
NRF.on('connect',WIDGETS["bluetooth"].changed);
NRF.on('disconnect',WIDGETS["bluetooth"].changed);

I think that's just too much I'm afraid.
We're still supporting Bangle.js 1 where RAM is at a real premium, and that would at least double, maybe triple the memory consumption of the default widget... And I'm not sure there are even any default apps that use a blue background?
I feel like you'd be better just having a new bluetooth widget that was a different color - for instance https://banglejs.com/apps/?id=widminbt but that was just the FG color - and then anyone who had issues could install that in a few seconds

Okay, no problem. Thanks for the explanation. I was just just having some fun experimenting

That reminds me of another thing with the Pebble++ clock, I like the way it looks with the light theme better, but I also want the menus to use the dark theme at the same time. Should there be an option for inverting one or the other? Or should I simply use the customize menu to accomplish this?
I'll be honest I haven't messed with the custom theme stuff much, but I'm going to now that I see it adds a ton of customizability to the whole experience and even my existing clock app (I'll for sure have to incorporate the custom theme settings into my clock app).

Well, you should use the normal system-wide theme settings to set what you want the menus and things to be.
But it looks like if you go Settings -> Apps -> Pebble++ you can set a custom theme just for Pebble?

I tried using the system theme option in Pebble++ but that still doesn't seem to let me set the menus dark and the clock light.
It's not a big deal, just something I noticed and thought it might be nice to have as an option. I will probably look at finding a solution.

yeah, in pebble++

system -> use whatever the system's theme is (set via Settings->System->Theme)
dark/light -> force it

Ahh! Now I understand. For some reason I was confusing myself with what those settings did 🤦♂
That indeed works exactly how I wanted it to. Thank you


Feature request: color-coded graphs for performance visualization

Gathering data from
https://pytorch.org/tutorials/recipes/recipes/profiler_recipe.html
...it would be fantastic if there was a library with a one-line API comparable to what Tensorboard previously offered with TensorFlow, for color-coded graph visualization of performance metrics per computational graph element -- namely, runtime, but also of interest, would be memory metrics... e.g. see https://branyang.gitbooks.io/tfdocs/content/get_started/graph_viz.html
The problem with Tensorboard PyTorch support is apparently it's a mess right now...
Please ping me if this is of interest to develop, I think it would greatly help ML developers to be able to both visualize graphs and visualize performance bottlenecks of the graphs...

PS probably it's obvious, by color-coding, I mean, e.g.
Gradient from Blue to Red, where the darkest blue == max seconds of processing time, darkest red == least seconds, based on a simple min/max normalization from all computed graph elements, and a best-estimate allocation of the Profile runtimes per element, shown on your graph viz...

This would be a good feature and should be possible. However, displaying profiler statistics as a color coding would clash with the highlight colors to show which node is being visualized in the right-hand panel. I'm instead envisioning something like the following mockup:

The bars on the left hand side are runtime statististics, right hand side would be memory. For runtime, black is forwards pass and gray is backwards pass. For memory, black is the memory consumed by activations and gray is memory consumed by parameters (possibly including gradients for the backwards pass?). Heights are normalized as you described.
Mouseover would provide a tooltip explaining each bar and giving the concrete value (e.g., "Fwd pass runtime: 3e-4").
In terms of implementation, I don't know much about profiling but was thinking the following.
Runtime

Add a pre forward hook / post forward hook, capture the starting time and end times with cuda.Event (if on gpu) or a regular timer (if on cpu). Have to look what to do for MPS.
After everything is run, throw in a torch.cuda.synchronize and compute all the normalized time deltas.
Similar logic for backwards pass.

Memory

This is a little trickier, as there are three ways that a module uses memory: parameters (persisted), activations (only on forwards pass, freed on backward), and parameter gradients (persisted if zero_grad is called with set_to_none=False (default))
Another wrinkle is how to handle modules that are reused in the computational graph. For example, if we use the same Conv2d submodule twice in one forward call from the parent module, the Conv2d node will show twice in the explorer graph. The forwards activation memory is pretty clear, that happens on a per-invocation basis. But the parameter memory usage is "shared" between the nodes. I'm inclined to just show the full memory usage for each repeated node, but this could have the unfortunate side effect that the sum of the memory usages of all nodes in the graph doesn't actually add up to the total memory usage.
To make the presentation similar to the runtime bars, the black bar should be the memory consumed by activations only (during to forwards pass) and the gray bar should be the memory used by the parameters (as this exact memory is what is doubled in the backwards pass to store the gradients).
For measuring the activation memory, I was thinking about using cuda.memory_allocated in the pre-forward hook and post-forward hook and measuring the difference. I expect that this should work without running into asynchronous issues? (correct me if I'm wrong)
Memory will have to include the memory used by submodules. This is a little inconsistent with the fact that we don't visualize the parameter tensors of nested submodules, but it'll have to do.

Shared details

Profiling will only happen every log_freq'th iteration. Profiling results will be updated in some kind of a running average.

Question
Does the above make sense to you / match your expectations of what you'd like to see profiled? Any other suggestions are also welcome.

Thanks @spfrommer for the super fast, detailed, and visionary reply!
I'm very happy to affirm a lot of what you describe where it makes sense to me, and also to critically propose changes where I think it would result in a more useful UX.
"...displaying profiler statistics as a color coding would clash with the highlight colors to show which node is being visualized in the right-hand panel."
I see your concern.  Consider the following...

TorchExplorer as a multi-purpose tool, which could support multiple "analysis modes".
All of your work on graphical network analysis, flow, etc. + UI elements for deep diving into the graphical network, could serve as foundational tech for other analysis modes...
Visualization of weights and biases is a primary analysis mode currently.  It's not really explicitly labeled as an option with e.g. a toggle/switch/dropdown selector, because currently it's the only main analysis mode.
Imagine a user selecting a different analysis mode, e.g besides default of "Weights & Biases Analysis", user could instantly select Runtime Analysis - Forward + Backward Pass, ... , Memory Analysis - CPU RAM, or Memory Analysis  - GPU VRAM.
Benefits of this kind of wrapper around the entire project:

TorchExplorer's sub-module View, now visualizing the detailed Weights & Biases charts / metrics, could be reused for different dedicated charts / metrics for different analysis modes.  For starters, for runtime/memory analysis, the area would be usefully and easily filled up with high-level metrics like TOTAL RUNTIME: X.XX milliseconds, TOTAL CPU RAM: Y.Y GB, TOTAL GPU VRAM: Z.Z GB...
TorchExplorer's graphical network coloring, now linking together the different sub-views of module weights/biases with the overall graphical network, could be customized for whatever is the selected analysis mode.  This makes a ton of sense, because it is unlikely that I'll be debugging weights/biases issues at the exact same time as debugging runtime. Similarly, I'd probably like to focus on debugging/visualizing just one of runtime or memory, but not both simultaneously.  This makes for a cleaner UI and follows TensorBoard.  Another nice upshot of this modularization: first we can solve development of runtime graphical visualization, and then after deploying that, can look to solve memory graphical visualization...

"...The bars on the left hand side are runtime statististics, right hand side would be memory. For runtime, black is forwards pass and gray is backwards pass. For memory, black is the memory consumed by activations and gray is memory consumed by parameters (possibly including gradients for the backwards pass?). Heights are normalized as you described."
It's a neat graphical design that you propose.  The reason why I push back and suggest doing extra gymnastics for color is because in my research and decade of work in data visualization I've found that colors are by far the most valuable tool for dealing with complexity.  I think it would be difficult to very quickly determine performance bottlenecks at a high-level across a very large computational graph for the design you propose, because the many small black/grey bars would be difficult to see when zoomed out.  I also figured it wouldn't be too hard to go with the "gold standard" of a fully coded-coded view of the graphical network...
Design proposal visualization

Above, we use the full color spectrum for visualization, following science of the Turbo colormap designed by Google.
Above is based on Python code that I just made for demo purposes here:
neural_network_turbo_color_coding.zip
"In terms of implementation..."
As I suggested, I would recommend just going after one of the profiling challenges first and trying to deploy on just that.  Between runtime vs. memory profiling, there's some pretty nice work in the right direction for memory profiling recently published by Torch maintainers, detailed here.  So, I think when it comes time to implement memory profiling, their approach should help.
For starters, the simplest and most essential task is to get runtimes for every single computational element (I figure trying to parse and post-process outputs from the Torch Profiler might get there, but not sure how well it matches up with your graphical modeling).
There's a lot more I could get into here, but hopefully above is helpful and sufficiently inspiring!  I wish I had it today for an actual profiling project I need move forward on now...

Really appreciate the detailed feedback! I agree the colors would be better for usability, and having different analysis modes is the better UI. My suggestion was mostly motivated by practical considerations with Vega. Vega has a really focused grammar: it is not designed to support fancy GUIs, and I'm really pushing the limitations of what it can do. Nevertheless, it's still probably better to just do it properly than to keep hacking additional features into one interface.
To select between the different analysis modes, I'd need an equivalent of a drop down box or a radio button. Vega supports binding inputs to html elements, but these are outside of the visualization pane and by default are ugly and uncustomizable within the json spec. Customizing them to be appropriately positioned and formatted involves custom CSS external to the spec, which would be possible on the standalone backend but not the wandb interface. I'd probably have to hack it together with a Vega legend as a radio button.
Having the panels on the right hand side be custom for each analysis mode is probably the right design choice, but would involve a significant rearchitecting of how I handle the panels in Vega.
The pytorch memory profiling tools you've linked seem to largely involve examining memory allocation over time to detect memory leaks. I think the natural thing to display on the right-hand panels for the "memory analysis" mode would be the per-module line chart for the memory usage over the forwards pass and backwards pass, with time on the x axis (how to even get this information is another complication). This would help narrow down if a specific module is leaking memory in the forwards pass (e.g., by saving intermediate tensors to the module attributes). But my feeling is that most memory leaks happen outside of the module forward invocations (i.e., with metrics logged on the module output without calling detach() first).
In summary, I really like your suggestions and I'll probably refer to our discussions when I end up implementing this. But it involves a big architectural rework for what's essentially a side project to my research--it's probably not something that I'll get around to in the near future.


"Cancel connection" does not cancel repaeted attempst and dialogs

Summary
I am connected to eactly one Mattermost server.
Today I am greeted with "Certificate error" since apparently the Let's Encrypt certificate on the server has expired -- there's nothing I can do about except waiting for the admin to do so.
Yet Mattermost keeps bugging me with the same "Warning" over and over again despite hitting "Cancel Connection" everytime.
This is pointless. If I cancel it once that has to be enough. Nagging me with an information I already have acknowledged is not helping and by hitting "Cancel Connection" I have taken action. If Mattermost insist of trying to connect until the issue is fixed and a connection ghas been established, that is fine by me -- but it must do so on its own time without bugging me again and again and .. yes, there ist is again.
Environment

Operating System: Linux Debian/SID
Mattermost Desktop App version: 4.6.2
Mattermost Server version: X.X.X

Steps to reproduce
Start MM
Expected behavior
Keep silent after the first "Cancel Connection"
Observed behavior
Warning appears over and over again, no matter how often I "Cancel Connection"
Possible fixes

@Willyfrog Let me know if you're able to help test this or if we need QA assistance.

thanks @amyblais , I'll create a ticket and discuss this with @esethna

this is a similar report to #1478
there was already a ticket for discussion but somehow it never got to be discussed, requeuing again for next week.


Change dialog type to allow it to open on core-signal.

Paper-action-dialogs were not opening when the corresponding core-signal was fired. Changing to paper-dialog fixed this.

LGTM (any idea why that was not working?)

Reviewed files:

src/generic_ui/polymer/troubleshoot.html @ r1
src/generic_ui/polymer/troubleshoot.ts @ r1

Comments from the review on Reviewable.io

Not sure, I might poke around the Polymer source code to investigate. Thanks!!


Command not found.

When i want reconnect to Discord Gateway, i get "Command 'Discord Rich Presence: Reconnect Discord Presence to Discord Gateway' resulted in an error (command 'rpc.reconnect' not found)" error. And all commands are like that.
OS: MacOS Monterey 12.2
Vscode Version: 1.63.2

And RPC console is always like that;

I also have the exact same problem @thearkxd

Please upgrade the extension and try again.

Not working...

I uninstalled and reinstalled it and worked. Thanks!


Error In Creating Payload... Exiting..

Hi i have some trouble to test this tool i got this error
Python 2.7.11+
Kali 2016 32 bit fully updated
[*] Error In Creating Payload... Exiting..
Executing wine (wineserver32) 1.8.1 on Debian Kali Linux Rolling (i386).
If something goes wrong, please rerun with "WINEDEBUG=err+all wine"
for more detailed debugging output.
291 INFO: wrote /etc/winpayloads\payload.spec
431 INFO: Testing for ability to set icons, version resources...
450 INFO: ... resource update available
476 INFO: UPX is not available.
Traceback (most recent call last):
File "/opt/pyinstaller-2.0/pyinstaller.py", line 91, in
main()
File "/opt/pyinstaller-2.0/pyinstaller.py", line 86, in main
run_build(opts, spec_file)
File "/opt/pyinstaller-2.0/pyinstaller.py", line 50, in run_build
PyInstaller.build.main(spec_file, **opts.dict)
File "Z:\opt\pyinstaller-2.0\PyInstaller\build.py", line 1625, in main
build(specfile, buildpath)
File "Z:\opt\pyinstaller-2.0\PyInstaller\build.py", line 1582, in build
execfile(spec)
File "/etc/winpayloads\payload.spec", line 5, in
hookspath=None)
File "Z:\opt\pyinstaller-2.0\PyInstaller\build.py", line 371, in init
raise ValueError("script '%s' not found" % script)
ValueError: script '/etc/winpayloads/payload.py' not found
[*] Cleaning Up
If someone are able to help it will be appreciable ,thanks.

This should have been fixed in the latest commits. Thanks


vorta: 0.7.1 -> 0.7.2

Motivation for this change
Things done

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

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

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

I noticed a segmentation fault when quitting from the tray icon. But that was already present in the previous version.

Result of nixpkgs-review pr 111413 run on x86_64-linux 1

1 package built:

vorta

Result of nixpkgs-review pr 111413 run on x86_64-linux 1

1 package built:

vorta

The segmentation fault problem still exists. Maybe some vorta user/maintainer can look into that?


[WIP] V1 read fallback for DataSource V2 tables

What changes were proposed in this pull request?
(Please fill in changes proposed in this fix)
How was this patch tested?
(Please explain how this patch was tested. E.g. unit tests, integration tests, manual tests)
(If this patch involves UI changes, please attach a screenshot; otherwise, remove this)
Please review https://spark.apache.org/contributing.html before opening a pull request.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/13963/
Test PASSed.

Test build #108889 has started for PR 25401 at commit e14d2a2.

Test build #108889 has finished for PR 25401 at commit e14d2a2.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/108889/
Test FAILed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/13965/
Test PASSed.

Test build #108891 has started for PR 25401 at commit 8cd1ac3.

Test build #108891 has finished for PR 25401 at commit 8cd1ac3.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/108891/
Test FAILed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/13968/
Test PASSed.

Test build #108894 has started for PR 25401 at commit 087ab5d.

Test build #108894 has finished for PR 25401 at commit 087ab5d.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/108894/
Test FAILed.

Test build #108898 has started for PR 25401 at commit 6cdda4a.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/13972/
Test PASSed.

Test build #108898 has finished for PR 25401 at commit 6cdda4a.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/108898/
Test FAILed.

Merged build finished. Test FAILed.

Build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/15653/
Test PASSed.


github.com/nlopes/slack/issues/216

I've observed the issue mentioned in #216 issue for a month. I can confirm this fixes the endless loop issue and the bot works fine now.

I can confirm it fixed a problem we had seen in approx. ~5% of our accounts.

lgtm

Would be great to get this merged!

@dvdplm PR Updated, per request.

@apokalyptik thanks, great work here! :)


WFCORE-681 Incorrectly timeout values in ControllerLogger method time…

…outCompletingOperation and ControllerMessages method serviceInstallTimedOut
https://issues.jboss.org/browse/WFCORE-681
Incorrectly scaled timeout value passed to org.jboss.as.controller.ControllerLogger method timeoutCompletingOperation and org.jboss.as.controller.ControllerMessages method serviceInstallTimedOut
parameter value is ms, second is expected.

Core - Full Integration Build 930 is now running using a merge of 2bec6172bc54ad616d5d293fa37b9bb7d720178d

Windows Build 1338 is now running using a merge of 2bec6172bc54ad616d5d293fa37b9bb7d720178d

Linux Build 1778 is now running using a merge of 2bec6172bc54ad616d5d293fa37b9bb7d720178d

Windows Build 1338 outcome was FAILURE using a merge of 2bec6172bc54ad616d5d293fa37b9bb7d720178d
Summary: Tests failed: 7 (7 new), passed: 3094, ignored: 66 Build time: 0:22:12
Build problems:
Failed tests detected
Failed tests
org.jboss.as.test.manualmode.management.cli.CustomVaultInCLITestCase.testWrongVaultPassword: <no details avaliable>

org.jboss.as.test.manualmode.management.cli.CustomVaultInCLITestCase.testNonExistingVaultPassword: <no details avaliable>

org.jboss.as.test.manualmode.management.cli.CustomVaultInCLITestCase.testRightVaultPassword: <no details avaliable>

org.jboss.as.test.manualmode.vault.CustomVaultInModuleTestCase: <no details avaliable>

org.jboss.as.test.manualmode.vault.VaultPasswordsInCLITestCase.testWrongVaultPassword: <no details avaliable>

org.jboss.as.test.manualmode.vault.VaultPasswordsInCLITestCase.testRightVaultPassword: <no details avaliable>

org.wildfly.core.test.standalone.mgmt.HTTPSConnectionWithCLITestCase.testTrustedCLICertificate: <no details avaliable>

Linux Build 1778 outcome was SUCCESS using a merge of 2bec6172bc54ad616d5d293fa37b9bb7d720178d
Summary: Tests passed: 3101, ignored: 66 Build time: 0:23:10

Core - Full Integration Build 930 outcome was FAILURE using a merge of 2bec6172bc54ad616d5d293fa37b9bb7d720178d
Summary: Tests failed: 1 (1 new), passed: 2867, ignored: 373 Build time: 0:52:33
Build problems:
Failed tests detected
Failed tests
org.jboss.as.test.integration.ejb.timerservice.mgmt.PersistentCalendarTimerManagementTestCase.testResourceExistence: <no details avaliable>


Add downloading links of various programming IDEs for programming like VScode, pycharm, codeblocks, etc.

This does not seem relevant here
Thank you


Build Error with Amplify CI/CD pipeline deploying

Before opening, please confirm:

[X] I have checked to see if my question is addressed in the FAQ.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

App Id
https://us-east-1.console.aws.amazon.com/amplify/home?region=us-east-1#/d3uha8rjehvj3x
Region
us-east-1
Amplify Hosting feature
Build settings
Describe the bug
When I deploy the backend to my main branch, this errors come in the pipeline build for the ci/cd. For some reason the backend build when we specified that we do not want the backend to build. This keeps happening and we don't have any problems with our backend env, we even injected the amplify.yml to have the frontend only build and it seems to be building the backend. Please help
                  at ensureAmplifyMetaFrontendConfig (/snapshot/repo/build/node_modules/@aws-amplify/cli-internal/lib/extensions/amplify-helpers/on-category-outputs-change.js:101:60)
                             at AmplifyToolkit.onCategoryOutputsChange [as _onCategoryOutputsChange] (/snapshot/repo/build/node_modules/@aws-amplify/cli-internal/lib/extensions/amplify-helpers/on-category-outputs-change.js:41:9)
                             at initializeEnv (/snapshot/repo/build/node_modules/@aws-amplify/cli-internal/lib/initialize-env.js:83:31)
                             at async onSuccess (/snapshot/repo/build/node_modules/@aws-amplify/cli-internal/lib/attach-backend.js:94:9)
                             at async attachBackend (/snapshot/repo/build/node_modules/@aws-amplify/cli-internal/lib/attach-backend.js:45:9)
                             at async Object.run (/snapshot/repo/build/node_modules/@aws-amplify/cli-internal/lib/commands/pull.js:68:9)
                             at async Object.executeAmplifyCommand (/snapshot/repo/build/node_modules/@aws-amplify/cli-internal/lib/index.js:292:9)
                             at async executePluginModuleCommand (/snapshot/repo/build/node_modules/@aws-amplify/cli-internal/lib/execution-manager.js:142:5)
                             at async executeCommand (/snapshot/repo/build/node_modules/@aws-amplify/cli-internal/lib/execution-manager.js:40:9)
                             at async Object.run (/snapshot/repo/build/node_modules/@aws-amplify/cli-internal/lib/index.js:165:13)

2022-06-16T10:37:46.563Z [ERROR]: !!! Build failed
2022-06-16T10:37:46.564Z [ERROR]: !!! Non-Zero Exit Code detected
Expected behavior
Expected: To deploy the frontend only to our Amplify environment
Reproduction steps

Commit changed to branch
merge into main
breaks on build -> backend builds and fails

Build Settings
version: 1
applications:
  - frontend:
      phases:
        preBuild:
          commands:
            - npm ci
        build:
          commands:
            - npm run build
      artifacts:
        baseDirectory: dist/rabbithole
        files:
          - '**/*'
      cache:
        paths:
          - node_modules/**/*
    appRoot: rabbithole

Additional information
No response

@M-Harty21 can you take a screenshot of your branch page ( the one with the pipeline steps).

Hi @M-Harty21 👋🏽 We are investigating this behavior. In the mean time we can try some workarounds.

Can you select the “edit” button above your app preview icon and deselect the “Enable full-stack continuous deployments (CI/CD)”. This will prevent Amplify from making updates to the backend.

You can also leverage the AMPLIFY_DIFF_BACKEND environment variable. When this is enabled, if Amplify does not detect any changes to the backend then it will skip the backend build step. See instructions here for setting this variable: https://docs.aws.amazon.com/amplify/latest/userguide/build-settings.html#enable-diff-backend

Tried number 1, didn't help will try number 2, hopefully this can be solved need to have the env deployed very soon. Amplify has been very very buggy lately

If you don't want the backend to build at all then you can set AMPLIFY_SKIP_BACKEND_BUILD to true. This will skip the backend altogether. https://docs.aws.amazon.com/amplify/latest/userguide/environment-variables.html#amplify-console-environment-variables
From docs:

If you do not have a backend section in your build specification and want to disable backend builds, set this environment variable to true.

Thanks a million!


FDG-5925 AFG Overview Hook in Data for Variables

https://federal-spending-transparency.atlassian.net/browse/FDG-5925
Line coverage: 89.75%

Getting Build Errors for Gatsby on file afg-overview-helpers.ts

Looks good, and all evergreen values are being pulled from APIs
Build successfully locally
All test passed locally


Missing parameter: -GenerateRingingWhileLocatingUser

Hi,
On the PS we are able to set:
Set-CsOnlinePSTNGateway -GenerateRingingWhileLocatingUser
But on the documentation this is not clarified at all.

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

ID: 3a99ede2-bbc2-c56d-6fb0-33db74417f54
Version Independent ID: cf4bfc0e-fd8d-d5ca-5432-798af72a8885
Content: Set-CsOnlinePSTNGateway (SkypeForBusiness)
Content Source: skype/skype-ps/skype/Set-CsOnlinePSTNGateway.md
Service: skypeforbusiness-powershell
GitHub Login: @tomkau
Microsoft Alias: tomkau

Hello @Petri-X how are you? please see here
The parameter is not present in 2.3.1

@get-itips Thank you very much for the contribution and sharing this explanation. @Petri-X Hope this comment is helpful for you. If you see a documentation update is required, please feel free to open an issue for the same. We proceed here to close it. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


going for the more straight forward approach

Factoring away the main entry point was starting to look a bit hairy, when taking into account Basquiat's main.m...

Fixes #19


Task 1 : Install networkx on your computer | Task 2 : Setup local development environment for NetworkX

Solves #2 : First Task :  Install networkx on your computer and create a PR to this repository
Solves #3 : Second Task : Setup local development environment for NetworkX

thanks @shivani6320! Could you remove the ipynb notebook from this PR?

thanks @shivani6320! Could you remove the ipynb notebook from this PR?

Ya, sure. Its removed please check..


Implement a Korok Seed Guide to help players locate all 900 Korok seeds in BOTW

Players can access different levels of hints based on the credits they spend, providing scalable assistance. This feature includes a user-friendly interface, hint tiers, and integration with in-game credit systems.

The code has been uploaded and the documentation is completed successfully.


feat: add typebox plugin types

Add plugin specific types

FastifyPluginCallbackTypebox
FastifyPluginAsyncTypebox

Discussed here

Checklist

[x] run npm run test and npm run benchmark
[x] tests and/or benchmarks are included
[x] documentation is changed or added
[x] commit message and code follows the Developer's Certification of Origin
and the Code of conduct

No script for npm run benchmark, ran npm run test all ok.


Add shared calendar

https://github.com/oscal-compass/community/issues/24 add shared calendar
When this is merged we need to make sure we update the meeting notes

Before we merge this with the new meeting details, we should ensure that meeting details are removed from the compliance-trestle repository to avoid confusion. I will submit an issue on the trestle repository for this.

Issue recorded here - https://github.com/oscal-compass/compliance-trestle/issues/1587


The user should get notifications for quota change requests

Story
As a user, I would like to get notifications as my quota increase request progresses through the system.
Description
When a user submits a quota change it works fine but they don't get any feedback as that it is accepted and when it is completed. It would be great to send an email to both the TC and PO when the request is accepted (started) and when the bots are complete.
Done When
The PO and TC get email notification when request is received and then again when it completes.

Still a relevant feature requested by PO.

In addition to users being notified of pending quota change requests, the Registry PO will now receive notifications of pending provisioning and edit requests to review in the registry dashboard.

This ticket has be completed as per PR #400


fix: add stubbed date to Calendar for Happo tests

No ticket.
Description
Multiple PRs have this fix. Decided to fix it separately quickly and force merge it.
How to test

Happo tests pass

Screenshots

Before.
After.

Insert screenshots or screen recordings
Insert screenshots or screen recordings

Development checks

[x] Ensure that tests pass
[x] Self reviewed
[x] Covered with tests

PR commands

List of available commands:

@toptal-bot run all - Run whole pipeline
@toptal-bot run build - Check build
@toptal-bot run visual - Run visual tests
@toptal-bot run deploy:documentation - Deploy documentation
@toptal-bot run package:alpha-release - Release alpha version

PR Review Guidelines

When to approve? ✅
You are OK with merging this PR and

You have no extra requests.
You have optional requests.

Add nit: to your comment. (ex. nit: I'd rename this variable from makeCircle to getCircle)

When to request changes? ❌
You are not OK with merging this PR because

Something is broken after the changes.
Acceptance criteria is not reached.
Code is dirty.

When to comment (neither ✅ nor ❌)
You want your comments to be addressed before merging this PR in cases like:

There are leftovers like unnecessary logs, comments, etc.
You have an opinionated comment regarding the code that requires a discussion.
You have questions.

How to handle the comments?

An owner of a comment is the only one who can resolve it.
An owner of a comment must resolve it when it's addressed.
A PR owner must reply with ✅ when a comment is addressed.

Tried fixing it faster. Contributor was faster than me. makes sad noises and goes into the distance reconsidering life choices


Tracked expenses are not showing in the DM

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

Version Number:
Reproducible in staging?: needs reproduction
Reproducible in production?: needs reproduction
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
Expensify/Expensify Issue URL:
Issue reported by: @puneetlath
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1719238225419399
Action Performed:

Go to self DM
Track an expense in the DM

Expected Result:
Expense should show in the chat
Actual Result:
Does not appear in the chat
Workaround:
unknown
Platforms:

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

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

Screenshots/Videos
https://github.com/Expensify/App/assets/38435837/d0f46d06-8c14-432c-8618-e721298e7928

View all open jobs on GitHub
Issue OwnerCurrent Issue Owner: @s77rt

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

I can't get track expense to work at all right now, so going to open up to the community.

Hello, I'm from Software Mansion, an expert agency, and I'll work on this issue

I'm not able to reproduce this issue on staging:
https://github.com/Expensify/App/assets/56261019/cf873e27-106b-4ce0-866d-f7b82d977707

Not reproducible on main
https://github.com/Expensify/App/assets/16493223/350fe3b3-ef03-4f58-b69f-bb69337ae9a9

Not overdue. Needs reproduction

Issue not reproducible during KI retests. (First week)

Not overdue. Same ^

Issue not reproducible during KI retests. (Second week)

Still waiting on a successful reproduction...

Same ^

Same ^

@JmillsExpensify Let's close this for now and reopen if became reproducible

Issue not reproducible during KI retests. (Third week)

Closing since issue not reproducible.


bugfix: disconnect events when layer is removed.

Closes https://github.com/napari-threedee/napari-threedee/issues/195
In this PR I try to disconnect events when the layer is removed.
It resolves the issue, but I'm not sure if it's sufficient/complete teardown.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 55.41%. Comparing base (fdfac72) to head (9263f1c).
Report is 7 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #197      +/-   ##
==========================================
+ Coverage   53.64%   55.41%   +1.77%
==========================================
  Files          93       93
  Lines        3639     3755     +116
==========================================
+ Hits         1952     2081     +129
+ Misses       1687     1674      -13

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

The mouse callbacks are disconnected using that in _on_disable:
https://github.com/psobolewskiPhD/napari-threedee/blob/9263f1cf24353750cdb8fcd31265c51e5864eb57/src/napari_threedee/manipulators/base_manipulator.py#L281-L290
Is enabled = False not sufficient to trigger that?
Or am I not following something.


Show/Hide Contents Dialog for Assembly Diagrams is Broken

Issue and tracking information
Developer's time Estimated effort to fix (hours):
Developer's Actual time spent on fix (hours)
Issue reporter to provide a detailed description of the issue in the space below
Once made visible, either by default or post-creation manual enable, it is not possible to hide Property and Attributes boxes on component assemblies on assembly diagrams.  They clutter up all diagrams with unnecessary information, get in the way of port names, and generally add information of little value to these diagrams.
Per the screenshot of a "Filters -> Show/Hide Contents" dialog invoked from a component assembly's context menu, if you uncheck the box for the example Property and Attribute on that assembly component and hit OK, they still remain visible.  Moreover, when you bring up the dialog again, the boxes are once again checked.

And closely related to this primary issue is the secondary frequent complaint that Properties created by default, such as the RegisterNaming property, are visible at all initially.  If possible, newly created Property and Attribute elements owned by a parent Component should default to NOT being visible on diagrams.

@J17359 Do you ever need to put those properties or attributes back to the diagram? The reason why I am asking is that the diagram is currently synced with the model so it cannot run mixed mode. I can hide the attributes from the diagram but you won't be able to put them back again unless you turn off the "Sync with model" option from the Appearance tab. So let me know if you really need to have the option to see these attributes from the diagram without turning off sync option then I will come up with a solution.

@ysroh Our users have never had a need to view properties or attributes on a composite structure diagram, which is almost always used only to define the run-time design of the internals of an assembly component. Don't see a problem with making it hard (or impossible?) to make them visible again once turned off (or turned off initially).

Thanks. I will hide attributes.

We've noticed that comment/documentation blocks on elements in the model may also show up on the composite structure diagrams, which is similarly undesirable.

Can you let me know how I can reproduce this? I only see comments block if I show the internal structure of the part. If that's the problem then I will hide them from the internal structure compartment.

And also presumably related, this same issue of show/hide dialog visibility checkboxes being ignored happens on the Show/Hide Compartments dialog as well.

Will/can whatever fix is appropriate take care of all of these issues related to what's visible on diagrams?

I don't think it would be an easy fix just because we might have to fix Papyrus itself if we cannot find a workaround to override base functionality. I was lucky to find a workaround for most of the problems we had so far but I am not really sure about this.
Do we know if you want to make some compartments visible all the time? I think that could be an easy fix to start with until we find a workaround so users can actually turn them off or on.
So can you please let me know which compartments you want to make visible? so I can focus on them?

After further investigation the comment/documentation blocks that show up are only in the case of adding comments to an assembly or monolithic implementation model element, vs. their parent CCMComponent element.  Comments are supposed to be applied to the CCMComponent parent, not to their child implementations.  So likely not a problem.
However, there are users that are adding a new Composite Structure Diagram to a parent CCMComponent element for whatever reason (apparently to add ports to it), at which point valid comments on the parent CCMComponent do show up in these diagrams.  But it's not clear that's a valid use case, since a composite structure diagram under a CCMComponent vs. an impl of it doesn't make a lot of sense.  In the RSA CX product composite structure diagrams were only (allowed to be) added under AssemblyImplementation elements.
As for Show/Hide Compartments, the default only has "internal structure" checked on the left column, plus the unlabeled and unexplained "Display Compartment Title" box at the bottom of the right column.  This is fine and apparently a good default.  The problem comes in when users try to turn on or change anything in the Show/Hide Compartments dialog.  Other labels and/or compartments appear on the diagram as expected, but then they cannot be gotten rid of if you go back and try to uncheck them.  This happens a lot since users are modifying all the Filter visibility settings they can find in a quest to get rid of the display of various superfluous elements like properties, attributes and comments.  But once any of these things become visible, you can never get rid of them on the diagram again.

Please see comments inline

After further investigation the comment/documentation blocks that show up are only in the case of adding comments to an assembly or monolithic implementation model element, vs. their parent CCMComponent element. Comments are supposed to be applied to the CCMComponent parent, not to their child implementations. So likely not a problem.

Understood.

However, there are users that are adding a new Composite Structure Diagram to a parent CCMComponent element for whatever reason (apparently to add ports to it), at which point valid comments on the parent CCMComponent do show up in these diagrams. But it's not clear that's a valid use case, since a composite structure diagram under a CCMComponent vs. an impl of it doesn't make a lot of sense. In the RSA CX product composite structure diagrams were only (allowed to be) added under AssemblyImplementation elements.

That's right. I don't think it makes sense to create a composite structure diagram under CCM component.
However,  I am not sure if I want to hide the comments from the diagram since it is a valid use-case to add comments on a composite diagram using the palette entry.

As for Show/Hide Compartments, the default only has "internal structure" checked on the left column, plus the unlabeled and unexplained "Display Compartment Title" box at the bottom of the right column. This is fine and apparently a good default. The problem comes in when users try to turn on or change anything in the Show/Hide Compartments dialog. Other labels and/or compartments appear on the diagram as expected, but then they cannot be gotten rid of if you go back and try to uncheck them. This happens a lot since users are modifying all the Filter visibility settings they can find in a quest to get rid of the display of various superfluous elements like properties, attributes and comments. But once any of these things become visible, you can never get rid of them on the diagram again.

I can reproduce this problem. I will work on it. Thanks.

It is not possible to override the behaviour of the existing show/hide compartment filter so I would like to add a menu to reset the compartment filter to go back to the initial setting.
Let me know if you are ok with this solution.

Sounds like a workable solution, as long as the initial defaults are OK.  For Compartments we believe they are.  For Contents probably not (e.g., properties, attributes and comments on components).

I will have the fix soon but my assumption is that the structure diagram is created under the assembly. I will create a separate ticket to disable the creation of the structure diagram from the component.

I will also hide attributes/properties/comments from the composite structure diagram created under the CCMComponent for now.

Fixed. Please verify the fix and let me know if you have any comments. Thanks

Hi, I am trying to verify this feature. Am I supposed to see this menu item? I just want to make sure I am looking for the right thing.

Yes. The menu is there to reset compartment settings. The reason is that if you enable some compartments using Show/Hide compartments menu there are some visible items that you can never get ride of. You need to verify that everything looks good in diagram after running the reset compartment menu.
One way to test this is to enable all compartments via Show/Hide compartments menu and then run reset menu to see if the diagram looks good.

We've tested and verified the fix on new models. Still doing some more testing on existing models to see if the behavior matches what we'd expect. I'll respond back when that testing is complete.

This ticket can be closed @ysroh - additional testing continued to prove that it was working. Thanks!

Thanks


Occlusion between different classes in multi modal GT-Sampling.

Hello @yukang2017 ! I notice that your FocalsConv has been supported by OpenPCDet. Congratulations!
After reading your code implementation of multi modal GT-Sampling, I think you only deal with the occlusion of objects belong to the same class on the image, which may case severe occlusion between different classes. Is it a potential bug? May it lead to suboptimal performance?

Hi! Multi-modal gt-sampling indeed will cause occlusions in images (as the image blew). It indeed leads suboptimal performance on some categories on nuScenes. You can refer to the Table S - 16 in the paper.
I currently has no idea to solve this problem elegantly. We might reply on pre-trained instance segmentation models to copy paste mask instead of boxes to relieve the occlusion. But this inevitably complicates the pipeline.


[improve] Bump project version to 3.0.0-SNAPSHOT

Motivation
https://lists.apache.org/thread/pqkh9d784krtk0jrfcs164kwrl303m7l has approved. We can bump project version to 3.0.0-SNAPSHOT
Modifications

Bump project version to 3.0.0-SNAPSHOT

Verifying this change

[x] Make sure that the change passes the CI checks.

Documentation

[ ] doc
[ ] doc-required
[x] doc-not-needed
[ ] doc-complete

Codecov Report

Merging #19573 (3e7896e) into master (e0b50c9) will increase coverage by 37.20%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##             master   #19573       +/-   ##
=============================================
+ Coverage     24.65%   61.85%   +37.20%
- Complexity      291    25595    +25304
=============================================
  Files          1591     1844      +253
  Lines        123073   135280    +12207
  Branches      13434    14875     +1441
=============================================
+ Hits          30348    83684    +53336
+ Misses        88233    43887    -44346
- Partials       4492     7709     +3217

Flag
Coverage Δ

inttests
24.66% <ø> (+<0.01%)
:arrow_up:

systests
25.22% <ø> (?)

unittests
59.02% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...service/nonpersistent/NonPersistentReplicator.java
58.41% <0.00%> (-1.99%)
:arrow_down:

...in/java/org/apache/pulsar/common/api/AuthData.java
71.42% <0.00%> (ø)

.../apache/pulsar/broker/namespace/LookupOptions.java
87.50% <0.00%> (ø)

.../apache/pulsar/common/naming/SystemTopicNames.java
55.55% <0.00%> (ø)

...apache/pulsar/common/util/SafeCollectionUtils.java
0.00% <0.00%> (ø)

...pache/pulsar/common/configuration/BindAddress.java
22.22% <0.00%> (ø)

...r/client/admin/internal/data/AuthPoliciesImpl.java
65.21% <0.00%> (ø)

...sar/common/policies/data/impl/BundlesDataImpl.java
92.30% <0.00%> (ø)

...ar/common/policies/data/InactiveTopicPolicies.java
83.33% <0.00%> (ø)

...io/kafka/connect/PulsarKafkaConnectSinkConfig.java
85.71% <0.00%> (ø)

... and 1364 more


Added support for avif.

Added support for avif format.
Avif has started getting support in browsers, currently support in chrome and opera:
https://caniuse.com/avif
Firefox:
https://bugzilla.mozilla.org/show_bug.cgi?id=1443863
And a nice article about it 😃 :
https://jakearchibald.com/2020/avif-has-landed/

@Myoxocephalus Thanks for the changes :) Merged and added in v1.6.1 🎉


Support for webdriver desired_capability in gwen.properties

There should be some mechanism/configuration to support & configure webdriver desired_capabilities.
Below links contains information on the same.
https://github.com/SeleniumHQ/selenium/wiki/DesiredCapabilities

Unfortunately the configuration of capabilities is programmatic in the selenium API and browser specific. It would therefore be difficult for us to support them all in one go. Perhaps for now if you could let us know which specific browser capability you require, we could implement it for you.

@Rahul9844, I've built a snapshot below containing support for ignoring zoom settings in IE (I believe this is what you were after).  Please test it out using the following gwen setting:
gwen.web.ignore.zoom=true
Snapshot build: gwen-web-2.14.3-SNAPSHOT.zip

Thanks. GWEN is now able to startup app in I.E browser
Earlier i use to get below error on startup
Browser zoom level was set to 114%.
Now with gwen.web.ignore.zoom=true set i am no longer getting above error.

Can you please document how the rest of the desired_capabilities are to be configured?
As I needed to set few more settings for I.E browser. (example : ignoreProtectedModeSettings)

Great to hear that the zoom ignore setting works. Regarding other settings, we need to add support for them one at a time (for reasons stated above). If you could specify which ones you need exactly please.

See also the complete list of already supported settings (in case the one you need is already support) here https://github.com/gwen-interpreter/gwen-web/wiki/Runtime-Settings#gwen-web-settings

I'm going to take a look at this again to see if I can come up with a good settings strategy. Stay tuned.

Hi, we've added a new gwen.web.capabilities setting in the snapshot below to support all the capabilities. You can use it to set one or more (comma separated) name=value capabilities for any browser.
For example:

Single setting:

gwen.web.capabilities=ignoreZoomSetting=true

Multiple settings:
gwen.web.capabilities=ignoreZoomSetting=true,ignoreProtectedModeSettings=true

Boolean, integer, and string values are supported. This setting can be used to set any browser capability. Capabilities that are not supported by a particular browser will have no effect and will be ignored.
Please try it out using the snapshot below and let us know how it goes.

gwen-web-2.14.3-4-g821d258-SNAPSHOT.zip

@Rahul9844, we've added support for capabilities. If you believe your issue is environmental or native driver related, please close this one.
Perhaps check that all security zones in IE are set to the same Protected Mode setting. Setting the Local Intranet zone's Enable Protected Mode setting to true can also solve this problem.
Seems many others are having similar issues with IE here: https://stackoverflow.com/questions/45073995/ie11-exceptions-with-iedriverserver-unable-to-get-browser


Clarification on Factory Deploy Inputs

@iainnash could you please clarify exactly what inputs we want to be passing into the "rendererInitializer" bytes param (line 40 of this the factory contract)? Was able to successfuly deploy a contract using "0x0000000000000000000000000000000000000000000000000000000000000000" as the value for this, but not actually sure what this is supposed to be.
From an initial read it looks like its supposed to be an abi.encoded string of the baseURI? Clarity would be great here so we get the factory UI running correctly
cc @salieflewis

I can add a method that leaves out some of these parameters but you can safely call this with empty bytes '' and address(0x0). This sets the renderer to the default parameters.

Should be good to close?