feat: reorder artwork for sale filters on artist screen

The type of this PR is: enhancement

This PR resolves FX-3162
Description

Reorder artwork for sale filters to remain consistent with desired order.
PR Checklist (tick all before merging)

[x] I have included screenshots or videos to illustrate my changes, or I have not changed anything that impacts the UI.
[x] I have tested my changes on iOS and Android.
[x] I have added tests for my changes, or my changes don't require testing, or I have included a link to a separate Jira ticket covering the tests.
[x] I have added a feature flag, or my changes don't require a feature flag. (How do I add one?)
[x] I have documented any follow-up work that this PR will require, or it does not require any.
[x] I have added an app state migration, or my changes do not require one. (What are migrations?)
[x] I have added a changelog entry below or my changes do not require one.

Changelog updates
Changelog updates

Cross-platform user-facing changes

Reorder artwork for sale filters on artist screen for iOS and Android apps - rquartararo

iOS user-facing changes

Android user-facing changes

Dev changes

Screenshots

Diff looks good to me! Looks like there's a failing test to address before merging.

Is it appropriate here to edit the jest test to reflect the order change?


Really need a way to minimize/alter build output information

What problem does this feature solve?
We're developing an app that's behind an enterprise authentication setup (ntlm) that doesn't play well with the yarn dev server (and yes, several people on my team have tried to get around this problem, without long term success). As a result, instead of the preferred yarn serve, we use yarn build --watch during ongoing development. Unfortunately, after every update, the build process displays every chunk that has been generated, which completely pushes useful errors and warnings from the linter offscreen.
As of now, there is no way for a user to disable this build output. I've seen several requests to be able to disable/alter build logging, but it seems like the Vue-cli devs struggle to grasp a tangible example for when this would add substantial value to the user. I understand that--it is, of course, important to prioritize features based on actual value added, so I just wanted to create this issue to give a concrete example where being unable to suppress or minimize build output information substantially frustrates the dev experience. Instead of being able to leave the terminal open in a separate screen and glance at it for linting errors, I have to scroll the terminal back up a full page length every time I save to see any compilation warnings or errors.
What does the proposed API look like?
--verbosity-level none | minimal | debug | default

I assume it would be enough to make this api public?
https://github.com/vuejs/vue-cli/blob/dev/packages/%40vue/cli-service/lib/commands/build/index.js#L203

@LinusBorg, that should be sufficient, yes. Any output from webpack plugins would still be printed, correct? And linters?
The optimal solution in my case would just be a flag that toggles the log(formatStats(...)) statement. But I get that beggars can't be choosers, so I'll take what I can get 😃

If I'm not mistaken, you should be able to use --silent right now, it's just not public in the sense that it's not documented.
Report back if the kind of output you get with it is ok.

@LinusBorg Yup, looks like what I want. 👍 I can trust this option to stick around, yeah? Even though it isn't documented?

I think we can use this issue to discuss that we make it public.
It won't disappear spontaneously anytime soon either way.

Great, appreciate the prompt response, @LinusBorg !

This seems to be related: vue-cli-service serve --silent shows all tslint warnings and errors. It would be helpful to just show the errors not tslint warnings. Have tried all sorts of vue.config.js options, including those that should affect the webpack-dev-server.


Help me to Implement others Family

SummaryMetricFamily
HistogramMetricFamily
GaugeHistogramMetricFamily
InfoMetricFamily

Hi @sanjusci, I'm not sure what you're asking exactly. Can you be more specific about what you're after?


Update dependencies

Updates :

Android Gradle plugin
compile sdk version
target sdk version
support libraries
Gson
fixes the version of Mockito

And the biggest part of the update is migrating all networking code from Retrofit 1 to Retrofit 2 APIs (which implied to rework a lot of APIs internal to the SDK).
I tested the SDK on the Riot codebase, and if you update the versions of the depencies in its build.gradle, it should work seamlessly

My bad.
At one time, I tried to replace the RetrofitError with a Throwable, but this would have changed too much public APIs, so I back-tracked and ended up on Exception.
But I forgot to remove the cast.
Thanks for noticing: I updated the PR.

Replaced by #174


citation

When appropriate, add a CITATION.cff file and a citation page in docs.

Note that currently, we have a docs.bib
handling citations for us - what is the benefit of CITATION.cff? is this best saved until #107 is taken care of?

To clarify: it's where we put the citation to the multidms paper. Github will display a citation sidebar in the repo (near where license is displayed). We should also have a docs page on how to cite, with a bibtex and APA citation that can be copied.

see: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-citation-files


Added dependabot config to format commit messages

This is so we can easily merge PRs from dependabot like https://github.com/balena-io/docs/pull/1914 without having to checkout the branch and fix versionbot.
dependabot config options https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates

Never using the github merge button again...

@balena-ci retest

@balena-ci rebase

@balena-ci I self-certify

@balena-ci I self-certify!


Use frozenset for Specification.kTraitSet

What
Define the (Python) Specifications trait set using a frozenset so it can be hashed.
Why
Simplifies switching on trait set in manager implementations in Python, where a handler map is a nice way to structure code.
ACs

Generated Python Specifications use frozenset for their static kTraitSet

Re-opening due to the change being reverted in https://github.com/OpenAssetIO/OpenAssetIO-TraitGen/issues/94. This issue is blocked until we can bump the required version of pybind11 used by OpenAssetIO.


MSID: 97326 Version: 1 DOI: 10.1101/2<IP_ADDRESS>3198

MSID: 97326
Version: 1
Preprint DOI: https://doi.org/10.1101/2<IP_ADDRESS>3198
Step 1. Awaiting reviews
Editorial to post reviews via hypothesis
Useful links:

DocMap: https://data-hub-api.elifesciences.org/enhanced-preprints/docmaps/v2/by-publisher/elife/get-by-manuscript-id?manuscript_id=97326
New model tracking: https://docs.google.com/spreadsheets/d/1_fHaoOy7hjyocptKtVJRijeNpUY4hBS7Ck_aVmx6ZJk/
Reviews on sciety: https://sciety.org/articles/activity/10.1101/2<IP_ADDRESS>3198

For trouble shooting (e.g. no Docmaps available):

DocMap issue addressing: https://miro.com/app/board/uXjVNCwK6EI=/
Explore DataHub DocMaps API: https://lookerstudio.google.com/reporting/4c2f0368-babb-4beb-b5b3-497e7e7b0f08/page/ejphD
Unmatched submissions and preprints: https://lookerstudio.google.com/u/0/reporting/9f86204f-3bf7-477c-9b18-5c5ef141bf69/page/p_gxi57ha93c
Unmatched manuscripts spreadsheet: https://docs.google.com/spreadsheets/d/15QcK8w-ssB7109RQEDtFpJPZ0J5HTGxoHa_2TtpMBbg/edit#gid=1336081641

Step 2. Preview reviewed preprint
Production QC content ahead of publication
Instructions:

QC preview: https://prod--epp.elifesciences.org/previews/97326v1
Update ticket with any problems (add blocked label)
When QC OK, add QC OK label to ticket and add publication date and time to https://docs.google.com/spreadsheets/d/1amAlKvdLcaDp5W8Z8g77NmkwbMF5n_u89ArSqPMO8jg
Move card to next column
(At end of the day post link in #enhanced-preprint and ask for PDF to be generated)

Useful links:

Preprint DOI :  https://doi.org/10.1101/2<IP_ADDRESS>3198
Confirm reviews returned by EPP: https://prod--epp.elifesciences.org/api/reviewed-preprints/97326/v1/reviews
To update the MECA path in the docmap: https://docs.google.com/spreadsheets/d/1mctCQuNFBjSn97Lihy7_vBO6z7-N-oqyLv4clyi6zHg

Step 3: Awaiting search reindex
This step adds the reviewed preprint to the homepage: https://elifesciences.org
The search reindex is triggered once an hour. We need the reviewed preprint to be indexed as the search application serves the journal homepage.
Useful links:

Jenkins pipeline to reindex search can be triggered sooner or monitored here: https://alfred.elifesciences.org/job/process/job/process-reindex-reviewed-preprints/

Step 4: Published! PDF requested
Waiting for PDF to be generated
Useful links:

PDF tracking: https://docs.google.com/spreadsheets/d/106_XeDjmuBae7gexOTNzg60lapeqjl2aRn9DzupGyS8/

Step 5: Introduce PDF to data folder and git repo
Upload PDF to relevent folder in git repo https://github.com/elifesciences/enhanced-preprints-data/
Step 6: Done!

[ ] Kettle is on!

Blocked as no MECA path in the docmap

Unblocked


avoid extraneous tiles that are just outside the frame

Currently if you request a 256 x 256 tile that exactly lines up with an actual tile you will actually end up downloading 3 extra tiles because of an off by one error being used to calculate the needed tiles

I don't believe the build failures are related to this pull request

ok the build is fixed and I believe was broken ever since you upgraded the location of spherical mercator.


Fix velerobackup tests for DeepEquals

Several tests were using DeepEquals (under testify's assert.Equal) to compare a runtime.Object from the (fake) kube server to a locally-constructed expected value. This is brittle, as fields such as ResourceVersion cannot be relied on to have predictable values.
Commit c7d60527612c141f58d748b8bf2e25d72f9499d5 in #1407 worked around the problem by explicitly setting the ResourceVersion to the value set by the fake kube server in controller-runtime 0.8.x. This PR has two commits:

Revert that workaround;
Switch to a comparison that disregards ResourceVersion and TypeMeta.

Note to reviewers: Ignore the first two commits. Their PRs (#1410, #1414) are approved and pending merge, so I stacked this up to avoid a dirty rebase later.

/assign @dgoodwin

Looks great ty for cleaning this up.
/lgtm

/lgtm


Make Persist jobs write to dest directly on object store

Fix https://github.com/Alluxio/alluxio/issues/9647

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/Alluxio-Pull-Request-Builder/5666/
Test FAILed.

Jenkins, test this please

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/Alluxio-Pull-Request-Builder/5667/
Test PASSed.

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/Alluxio-Pull-Request-Builder/5711/
Test FAILed.

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/Alluxio-Pull-Request-Builder/5720/
Test FAILed.

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/Alluxio-Pull-Request-Builder/5721/
Test FAILed.

Jenkins, test this please

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/Alluxio-Pull-Request-Builder/5723/
Test FAILed.

Jenkins, test this please

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/Alluxio-Pull-Request-Builder/5725/
Test PASSed.

@apc999 I'm not sure why we want to introduce this unsafe mode, especially since the persist is async (not blocking the client).

@gpang it is indeed an unsafe mode, but I think in reality the chance for a workload hitting the unsafe part may be low if users are running ELT workloads. In addition, it takes locking resource from master and requires S3 copy. So I view this is an optimization worth providing to users if they understand their workloads.

@gpang @calvinjia change this property to be a master-side property for object store based on my discussion with Calvin.

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/Alluxio-Pull-Request-Builder/5999/
Test PASSed.

alluxio-bot, merge this please.

@apc999 - can this be merged now?


armv8m/strcpy: add arch optimize version

Summary
Assembly version of strcpy for armv8m.
Impact
Replace common strcpy if CONFIG_ARMV8M_STRCPY is enabled.
Testing
tested using a testcase designed for arch libc function, see https://github.com/apache/nuttx-apps/pull/1662
Also tested on Cortex-m33:
native C:
strcpy total(run 25 times) cpu cycles 8400
strcpy average cpu cycles 336
assembly:
strcpy total(run 25 times) cpu cycles 5750
strcpy average cpu cycles 230

you could adapt for arm32 and make it cross-arm there is no much specific ; one optim could be to unroll for less than 256 chars (90% of cases in real world).

you could adapt for arm32 and make it cross-arm there is no much specific ; one optim could be to unroll for less than 256 chars (90% of cases in real world). Then extend to strcat because that's just the same concerns.

It isn't true. armv7-a/r may use NEON, and armv8-m may use MVE, which doesn't exist on armv6-m and armv7-m.

I don't see where you use specific VLD or VST instructions here.

I don't see where you use specific VLD or VST instructions here.

Here are some examples:
a46a661b341b619ec96493df0804b8060fe42c0c
https://github.com/apache/nuttx/blob/master/libs/libc/machine/arm/armv7-a/gnu/arch_memcpy.S#L175-L197

I don't see where you use specific VLD or VST instructions here.

Here are some examples: https://github.com/apache/nuttx/blob/master/libs/libc/machine/arm/armv8-m/gnu/arch_memcpy.S#L108-L117 https://github.com/apache/nuttx/blob/master/libs/libc/machine/arm/armv7-a/gnu/arch_memcpy.S#L175-L197

yep but in strcpy precisely

I don't see where you use specific VLD or VST instructions here.

Here are some examples: https://github.com/apache/nuttx/blob/master/libs/libc/machine/arm/armv8-m/gnu/arch_memcpy.S#L108-L117 https://github.com/apache/nuttx/blob/master/libs/libc/machine/arm/armv7-a/gnu/arch_memcpy.S#L175-L197

yep but in strcpy precisely

but the implementation may change like memcpy in some day.

I don't see where you use specific VLD or VST instructions here.

Here are some examples: https://github.com/apache/nuttx/blob/master/libs/libc/machine/arm/armv8-m/gnu/arch_memcpy.S#L108-L117 https://github.com/apache/nuttx/blob/master/libs/libc/machine/arm/armv7-a/gnu/arch_memcpy.S#L175-L197

yep but in strcpy precisely

but the implementation may change like memcpy in some day.

I was kidding still it could be pound defined most of the blocks are common,
that was I was talking about loading aligned n-bytes chunk during iteration,
so unrolling, so those 6 use the exact same processing blocks and surely strstr and other like memchr, strchr, so if you already optimized iteration blocks the whole string family can reuse and benefit from it, e.g instead of going one piece at the time in an unequal writing manner.
// same as strcpy/stpncpy but pointing to null char instead of last.
char * stpcpy (char * dst, const char * src);
char * stpncpy(char * dst, const char * src, size_t n);

char * strcpy (char * dst, const char * src);
char * strncpy(char * dst, const char * src, size_t n);

char * strcat (char * s1, const char * s2);
char * strncat(char * s1, const char * s2, size_t n);

I don't see where you use specific VLD or VST instructions here.

Here are some examples: https://github.com/apache/nuttx/blob/master/libs/libc/machine/arm/armv8-m/gnu/arch_memcpy.S#L108-L117 https://github.com/apache/nuttx/blob/master/libs/libc/machine/arm/armv7-a/gnu/arch_memcpy.S#L175-L197

yep but in strcpy precisely

but the implementation may change like memcpy in some day.

I was kidding still it could be pound defined most of the blocks are common, that was I was talking about loading aligned n-bytes chunk during iteration, so unrolling, so those 6 use the exact same processing blocks and surely strstr and other like memchr, strchr, so if you already optimized iteration blocks the whole string family can reuse and benefit from it, e.g instead of going one piece at the time in an unequal writing manner.
// same as strcpy/stpncpy but pointing to null char instead of last.
char * stpcpy (char * dst, const char * src);
char * stpncpy(char * dst, const char * src, size_t n);

char * strcpy (char * dst, const char * src);
char * strncpy(char * dst, const char * src, size_t n);

char * strcat (char * s1, const char * s2);
char * strncat(char * s1, const char * s2, size_t n);

This patch follows the current style to add the new optimized routine, let's do the refine in the next step?

I don't see where you use specific VLD or VST instructions here.

Here are some examples: https://github.com/apache/nuttx/blob/master/libs/libc/machine/arm/armv8-m/gnu/arch_memcpy.S#L108-L117 https://github.com/apache/nuttx/blob/master/libs/libc/machine/arm/armv7-a/gnu/arch_memcpy.S#L175-L197

yep but in strcpy precisely

but the implementation may change like memcpy in some day.

I was kidding still it could be pound defined most of the blocks are common, that was I was talking about loading aligned n-bytes chunk during iteration, so unrolling, so those 6 use the exact same processing blocks and surely strstr and other like memchr, strchr, so if you already optimized iteration blocks the whole string family can reuse and benefit from it, e.g instead of going one piece at the time in an unequal writing manner.
// same as strcpy/stpncpy but pointing to null char instead of last.
char * stpcpy (char * dst, const char * src);
char * stpncpy(char * dst, const char * src, size_t n);

char * strcpy (char * dst, const char * src);
char * strncpy(char * dst, const char * src, size_t n);

char * strcat (char * s1, const char * s2);
char * strncat(char * s1, const char * s2, size_t n);

This patch follows the current style to add the new optimized routine, let's do the refine in the next step?

yes sure you can always refine any, but as I often say, why re-doing it a million times when you can just do it the first time.

Your suggestion isn't a simple work especially for the assembly code:

All function series(strxcat, strxcpy, memxcpy...) need be changed
Each assembly source code need be rewritten totally
Many tests need be developed to cover all corner case
All arch need be reworked

It isn't a task can't be done in one day or two days.
BTW, since the code base comes from other libc:
https://github.com/bminor/newlib/tree/master/newlib/libc/machine/arm
https://android.googlesource.com/platform/bionic/+/refs/heads/main/libc/arch-arm/
it's better to keep the same structure as the origin.
Anyway, this is an open-source project. I would suggest you take the time to rewrite the code and submit a patch.

but don't get me it wrong ; you are a company appointed committer ; you have that luxury to be pay for open-sourcing ; I have never been.


added purge count

Users will be able to purge n number of messages (from the replied message) by providing the message count in /purge command: /purge [n].
Edit: this implementation has been tested in an instance of wbb deployed locally

uh wdym "deletes unwanted messages"? There's one issue though, if the message IDs are non contiguous, the replied-to message and the sent message get deleted

uh wdym "deletes unwanted messages"? There's one issue though, if the message IDs are non contiguous, the replied-to message and the sent message get deleted

Deploy this version and invite your bot in this chat, let me show you

okie


erro

when running the plugin it just appears that I have already reinstalled either or disagree with betterdiscord and continues or even error

1. That is not how you should install plugins.
2. This is not an issue with the installer.


Appstudio update test-component-pac-ippi

Pipelines as Code configuration proposal

Pipelines as Code CI/test-component-pac-ippi-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
7 seconds
init

✅ Succeeded
17 seconds
clone-repository

✅ Succeeded
40 seconds
build-container

✅ Succeeded
19 seconds
sanity-inspect-image

✅ Succeeded
19 seconds
deprecated-base-image-check

✅ Succeeded
12 seconds
clair-scan

✅ Succeeded
2 minutes
clamav-scan

✅ Succeeded
13 seconds
sbom-json-check

✅ Succeeded
10 seconds
sanity-optional-label-check

✅ Succeeded
9 seconds
sanity-label-check

✅ Succeeded
7 seconds
show-summary

Pipelines as Code CI/test-component-pac-ippi-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
7 seconds
init

✅ Succeeded
17 seconds
clone-repository

✅ Succeeded
40 seconds
build-container

✅ Succeeded
19 seconds
sanity-inspect-image

✅ Succeeded
19 seconds
deprecated-base-image-check

✅ Succeeded
2 minutes
clamav-scan

✅ Succeeded
13 seconds
sbom-json-check

✅ Succeeded
12 seconds
clair-scan

✅ Succeeded
10 seconds
sanity-optional-label-check

✅ Succeeded
9 seconds
sanity-label-check

✅ Succeeded
7 seconds
show-summary


Remote kernel does not work after updating to Hydrogen 2.16.1

macOS Big Sur 11.2.3
Atom 1.56.0 x64
Hydrogen 2.16.1
#2094 has been addressed and updated to Hydrogen 2.16.1.
I found a bug where the connection to the remote kernel did not work properly after the update.
Rolled back Hydrogen to 2.15.3 with apm, and confirmed that it works correctly.
I will try not to update until the issue is resolved.

Could you let me know how you use a remote kernel? The settings, the kernel you use, etc.

I apologize for the lack of words as I rushed the problem out.
Here's how I'm using it
・Access the analysis server via ssh.
・Boot the Jupyter kernel using Docker on the analysis server.
・Connect to the Jupyter kernel using ATOM Hydrogen: Connect To Remote Kernel.
・Connect to the Jupyter kernel using ATOM Hydrogen: Connect To Remote Kernel (set the IP address and token in Hydrogen Settings: Kernel Gateways)
The Hydorogen version 2.15.3 recognizes the kernel and reads the token with the above operations.
With version 2.16.1, I get an error (Forbidden, 403 GET・・・・・ referer=None) when connecting the kernel and the token is not recognized.

I think I have the same issue.

Running jupyterlab 3.0.14 on remote machine.
Connect to remote kernels with Hydrogen: Connect to Remote Kernel
Have set the details of remote machine in Hydrogen Settings: Kernel Gateways

I get as far as seeing the available environments/kernels but nothing happens when I try to select(press enter) on any of them.
Same Forbidden error as @kuri54 , and jupyter logs also say '_xsrf' argument missing from POST
2.15.3 works, 2.16.1 doesn't.

The '_xsrf' argument missing from POST error itself is in ./home/jovyan/.jupyter/jupyter_notebook_config.py (if this file is not there, create it with $ jupyter notebook --generate-config).
I've tried that way, but Forbidden, 403 GET・・・・・ referer=None error could not be solved.
Either way, I think this bug is in Hydrogen as @aminya says.
There is not a day that goes by that I do not code in a remote environment myself. That's more important than exporting .ipynb files.
It looks like the cause is somewhat known, so until it is resolved, I'm waiting for an improved version to be released by rolling back using something like apm install<EMAIL_ADDRESS>

I fixed it in the latest version. Let me know if it works for you too.

Thank you for your quick response. It was very helpful.
I updated it immediately and confirmed that it works. So far it is working fine.
Thank you very much.

Thanks for the quick response @aminya , I'm happy to see some love for Hydrogen :)
However...
I could connect to existing/already running kernel session with new version, but not create a new session. Still get the '_xsrf' argument missing from POST error, and that error doesn't show with 2.15.3.
That error seems to pop up when I click enter on any of the kernels/environments in the list of kernels/environments shown after I have pasted the token and selected to start a new session.
Found this old comment https://github.com/nteract/hydrogen/issues/922#issuecomment-315665849 (thanks @kuri54 for pointing me in its direction!)
I did not have a /home/username/.jupyter/jupyter_notebook_config.py file so I generated one with jupyter notebook --generate-config.
Following the instructions in the comment linked above, I then set the c.NotebookApp.token option in that file to a non empty string ('hello' in my case) and restarted jupyterlab on the remote machine. Weirdly, I didn't have to enter a token at all with that change, but still get '_xsrf' argument missing from POST error.
So I reset c.NotebookApp.token back to default and tried instead to set c.NotebookApp.disable_check_xsrf = True and restarted jupyterlab.
Now I still don't have to enter a token when connecting with hydrogen, but can select to start a new session and kernel/environment. But the status of the kernel (bottom left in atom window) gets stuck on "reconnecting" and the jupyterlab logs say Couldn't authenticate WebSocket connection.
Which makes sense I guess since I for some reason don't have to give a token now.
I reset c.NotebookApp.disable_check_xsrf to default and restarted jupyterlab and still don't get asked for token, even after restarting atom and downgrading/reinstalling 2.16.2, so not sure what's going on here.
Downgraded to 2.15.3 and everything works fine again.

The reason for this error is that I switched to the native XMLHttpRequest when you use a token. If you select "cookies" still the old behavior is used because that is a non-standard way.

Just to be sure, I'll add my environment to the list.
First, I commented out c.NotebookApp.disable_check_xsrf in /home/username/.jupyter/jupyter_notebook_config.py.
Next, we set up the token for JupyterNotebook in the Dockerfile. (ex. CMD ["jupyter", "lab", "--ip=<IP_ADDRESS>", "--allow-root", "--no-browser", "--NotebookApp.token"])
IIn addition, by configuring the Hydrogen Kernel Gateways as [{"name": "Remote", "options": {"baseUrl": "http://mysite:8888", "token": "mytoken"}}], you will not need to enter the token every time.
After updating to 2.16.2 with this setting, it works fine.

Aha, okay, it works when I set the token in Hydrogen settings Kernel Gateways as you did @kuri54
So what I've always done before is I've just started jupyter lab, copied the auto generated token, and then used that in the interactive prompt in Hydrogen/Atom when connecting.
It seems that with the changes in 2.16.2 the interactive prompt for a token doesn't work anymore, but if I paste the auto generated token from jupyter lab into Hydrogen settings, it works fine.
Of course, it's then much easier to set the token with --NotebookApp.token option when starting jupyterlab so that I don't have to change it in Hydrogen settings every time.
So, TLDR; it works now, thanks!
@aminya Is it intended that the interactive prompt for the token doesn't work anymore?
I checked the Hydrogen docs and they actually say that one should add the token in Hydrogen settings as I've now done, so maybe my issues were just caused by me using a deprecated functionality :)

I see. I will check if the token entered in the UI is not transferred to the server correctly!

I see. I will check if the token entered in the UI is not transferred to the server correctly!

This is fixed in the latest version. Hydrogen now prompts for authentication in case it could not find a session.

Awesome, thanks again for all your work on this @aminya!


[Storage] [Typing] [File Share] _models.py and aio equivalent

:shipit:

/azp run python - storage - ci

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-storage-file-share

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-storage-file-share


STORM-2085: Remove guava from storm-core pom.

guava isn't used by storm-core.

Do we want this on any of the 1.* branches?

We shaded Guava which downstream shouldn't rely on, so I think we can apply this to 1.x if applicable.
(I'm not sure we also want to apply this to 1.0.x.)
ps. Since external modules use Guava so we still maintain the main version of Guava.

I'm +1 on this.
@revans2 @ptgoetz Could you review this as well? This is a change of dependency but removing shaded dependency. Which version line do you think we can apply?

I'm +1 on this, but I am a little nervous I may have started using guava as part of the supervisor V2.  Let me try and run some tests.

Nope I was wrong it compiles just fine and there is no guava except being pulled in by curator test.
Yes +1 for this, and +1 for pulling it into 1.x if possible.

No wait, dependency:analyze indicates that guava is used?  Not sure how it compiled though. Investigating.

Ya the supervisor does not come up with this patch.

Further inspection reveals that guava is a dependency. I'm closing this.


'Bad Request' Error

Hi there! Got this error while entering /start command
Unhandled rejection Error: TELEGRAM: 400 Bad Request: BUTTON DATA_INVALID
Could you please provide some info - is the cause of this issue and how it can be solved?
Thank you

 For now it's just a starting point

For now it's just a starting point

Thank you for your feedback.
The problem was the overflow of callback_data at some points. Released update 1.1.2. Please check your work now.

@VDS13 Works perfectly! Thank you for your prompt support.


feat: support 'test' keyring-backend for price-feeder

Description
Adds support for keyring-backend=" test".

Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...

[x] included the correct type prefix in the PR title
[x] added ! to the type prefix if API or client breaking change
[ ] added appropriate labels to the PR
[ ] targeted the correct branch (see PR Targeting)
[ ] provided a link to the relevant issue or specification
[x] added a changelog entry to CHANGELOG.md
[x] included comments for documenting Go code
[ ] updated the relevant documentation or specification
[ ] reviewed "Files changed" and left comments if necessary
[ ] confirmed all CI checks have passed

Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...

[ ] confirmed the correct type prefix in the PR title
[ ] confirmed all author checklist items have been addressed
[ ] reviewed state machine logic
[ ] reviewed API design and naming
[ ] reviewed documentation is accurate
[ ] reviewed tests and test coverage
[ ] manually tested (if applicable)

@ryan-unit410 you can just set env PRICE_FEEDER_PASS to anything  and have the
[keyring]
backend = "test"
dir = "~/.umee"

Gotcha, thank you for clarifying! I was able to get it working with your suggestion and the addition below. 🙏
docker run --env PRICE_FEEDER_PASS=thisisnotusedforanythingbutstillrequired ........


Is there big performance hit calling [F].create on every function call

Is it best practice to create a logger on every function call? I'm assuming that has a performance it though

Is there big performance hit calling [F].create on every function call

Despite that slf4j caches logger instances internally, I'd say there is some performance hit anyway.

Thanks for the answers! I'm satisfied!


add teradatasqlalchemy package

Status
Ready
Related Content Pull Request
Related PR: link to the PR at demisto/content
Related Issues
Related: link to the issue
Description
A few sentences describing the overall goals of the pull request's commits.

We're still checking this devdocker on the customer side


v3 Compatibility? and project plans? open to help?

Hi!
Wanted to check-in on the status of the project. It looks like work has frozen and the bulk update capability is sorely needed in Sanity. Will the plug-in be migrated to v3?
If the plug-in has been frozen, what is the reason? Is there an alternate plug-in? Other plans from Sanity?
If the plug-in is planning to keep living, are you open to help on this project to keep it moving?
Thanks much in advance!

Yes, an upgrade of this tool is absolutely necessary for Sanity v3!

This is one of those super-useful tools that feels like it should be part of the sanity studio already.
Would definitely love to know what the plans here are and willing to help out too.

Anything similar to this plugin for V3 maybe? Newcomer to Sanity(coming from Directus/Strapi ) and tbh I am a little confused how something similar isn't part of the core.


Suggestion: Move "Before you buy" documentation from "Troubleshooting & FAQ" to "Getting started" subcategory or to the root of the enthuisiast guide

plz someone look at this


Branch and line coverage 100%, but Statements only 98% (and no 'uncovered lines' displayed)?

Expected Behavior
To show me which lines are uncovered to result in '% Stmts' being only 98.45%? How can I have 100% line and branch coverage, yet be missing Functions or statements - i.e. see observed behaviour below?
Observed Behavior
------------------|----------|----------|----------|----------|----------------|
File              |  % Stmts | % Branch |  % Funcs |  % Lines |Uncovered Lines |
------------------|----------|----------|----------|----------|----------------|
All files         |    99.62 |      100 |    97.75 |      100 |                |
 src              |    99.59 |      100 |    97.62 |      100 |                |
  Context.js      |      100 |      100 |      100 |      100 |                |
  ContextError.js |      100 |      100 |      100 |      100 |                |
  RdfBuild.js     |    98.48 |      100 |       95 |      100 |                |
  RdfQuery.js     |      100 |      100 |      100 |      100 |                |
 src/utils        |      100 |      100 |      100 |      100 |                |
  RdfUtils.js     |      100 |      100 |      100 |      100 |                |
------------------|----------|----------|----------|----------|----------------|

Bonus Points! Code (or Repository) that Reproduces Issue
Forensic Information
Operating System: the operating system you observed the issue on.
Ubuntu 17.10
Environment Information: information about your project's environment, see instructions below:
output.txt

So, I found the problem! By configuring NYC to generate a HTML report I could see the uncovered statements, which were '.map()' statements that my tests only executed on empty map instances.
But I still think the above text report should have still indicated the line numbers of the uncovered statements. Once I saw them in the HTML report it was immediately obvious what the problem was - so I think this issue is still worth leaving open.

I had the same problem and I solved in the same way! I think report this information on the text report would be right.

@coreyfarrell I reproduced this due to a callback in my code:
async sampleFunction(records: SampleModel[], transaction: Transaction): Promise<void> {
    return await repository.insert(records, transaction, async () => {});
}

The issue was due to lack of coverage on the async () => {} callback.


Title hover effect

the tittle hover effect is not good, the way background goes shadow. I will try to improve that

i would make it perfect. Please assign this to me.

ok, @AKD-01 , I will do this.


https://developer.mozilla.org/en-US/docs/Learn/Accessibility/WAI-ARIA_basics

Request type

[x] Correction or update

Details

I noticed a typographical error in the documentation. Instead of useful, userful was written.
I hope this gets fixed.

Fixed. Thanks for reporting!


Allow CWP to be released without core tags

Currently cow won't allow for CWP to be released if the released core tags haven't been released. E.g we'd need to have a 4.3.0-alpha1 release before we could do a recipe for CWP 2.2.0-alpha1.
This is blocking the team from releasing CWP at the end of each sprint, something that would assist our processes in the lead up to the quarterly stable releases.
This issue covers the change to (from @robbieaverill): modify cow to let us require a dev version of core at a specific hash.

It'd be cool if we cool lock it to a dev constraint with a hash maybe (you can do this in composer.json even though it's terrible).
Error we get:
[plan] Invalid version 4.3.x-dev; Please enter a tag in w.x.y(-[rc|alpha|beta][z]) format

Another option is that we could inline aliases in the project composer.json like this:
"require": {
    "silverstripe/recipe-core": "4.3.x-dev as 4.2.0"
}

Cow uses custom code to parse and check the constraint:
https://github.com/silverstripe/cow/blob/master/src/Model/Release/Version.php#L60-L73
If we replaced this with https://github.com/composer/semver/ or similar we might have more flexibility for allowing constraints that composer would accept but current cow would not (like ^4.2#abc123de)

I'd agree with 'use a loose constraint instead of a tag'. i.e. silverstripe/framework: ~4.3.0 but not an explicit dev version (bad practice). Is that ok?
We'd just need to support constraints when setting release version via the plan editor. So if you type out a loose constraint it just uses that "as is" and doesn't try to do an actual release.

That sounds sensible.

@tractorcow FYI we've hit this again, needing to generate changelogs ahead of a core release available and wanting to include all commits to date. It's not currently possible, and would require a dev constraint to be allowed (or ^4.4@dev or something similar)

We've settled on an approach of tagging a core release candidate immediately prior to the CWP release candidate, and this is much less painful now that both releases are managed by the same team. The sprint-based alpha release cycle hasn't been adopted at this stage, and we have other methods of accomplishing the same objectives. On that basis, I'm going to close this one out.


What is the LICENSING for this project?

Can you add an explicit license to the project to clarify how this may be used by others?

Thanks for your concern. UPS-indel is free to use by the academic or non-profit organizations. We are working on adding a license document to this project and expecting to get it done in a week. Thanks.

MIT License added. Thanks


Swift 4

Updated to swift 4. Needed to modify some flat maps in the multiselection logic.
Untested

This is working?

Bravo Applause GIF from Bravo GIFs

Just tested this now using the demo and it seems to work fine. Perhaps there could be some unit tests or a testing methodology for future merges? :)
Thanks!

Maybe updating the ReadMe to show that swift 4 is compatible. Also the swift 4 support issue closed please.

how to use this dropdown for restAPI

Use closure and callback for the API call to populate the data source for the dropdown and use the main thread async dispatch queue for populating the data source array and calling the function on to show the dropdown menu.


question about points_to_voxel

Hi,
Thanks for your great work.
I noticed that you modified the spconv code, one of the modifications is https://github.com/open-mmlab/mmdetection3d/blob/master/mmdet3d/ops/spconv/include/spconv/point2voxel.h. This is related to the voxelization, line 73:
if (voxel_num >= max_voxels) break;
while the original code of spconv:
if (voxel_num >= max_voxels)
        continue;

Same change happens in your python version voxel_generator.py. As I understood, when we have enough number of voxels, we should stop making new voxels, but this does not mean we should stop traversing the remaining points. Because some of the remaining points can locate in the existing voxels. break will kill the entire loop and ignore those points. continue ensures  that all points can be checked and allocated in the corresponding voxels if necessary.
In my dataset, if I use break , the total number of points in my voxelized data is about 20% less than the continue version.  So I think the current version of your code generates incomplete voxelized data.

Can somebody explain this......

Hi @gillbam , thanks for your information. It seems a legacy issue because the original spconv fixed this problem with this PR. Could you please create a PR to fix it? also the python version?

Hi @gillbam , thanks for your information. It seems a legacy issue because the original spconv fixed this problem with this PR. Could you please create a PR to fix it? also the python version?

Thanks for your reply. Sure, I'll update those files later.

Close #406 via #423.

Fixed in #423


job: get_job: builder error: unsupported pair

Stacktrace: Oct 28 17:51:18.337 ERROR solana_skip_indexer::helpers::bq_utils: FATAL! builder error: unsupported pair
All we got from the client was builder error: unsupported pair
Access token was a vector of u8 with a size of 990.
The rest of the data required to execute get_job is as shown below

Rationale
The purpose of getting this fixed is not just to keep it working, but to allow users of jobs be able to check the job's status again should it be in 'RUNNING' or 'PENDING' state after awaiting for the initial 'insert' or delete' or etc. function.

Although the existing API could be simplified, you can implement what you need by following the example below.
https://github.com/lquerel/gcp-bigquery-client/blob/main/examples/bq_load_job.rs
The issue was not in the client itself but in the initial example. Instead of passing a download url, the JobConfigurationLoad object was expecting an URI (gs:///.
Let me know if everything is working now for you.


Using KNIFT feature vectors with vector similarity search?

System information
Flutter / tflite front end which performs realtime KNIFT vector feature analysis, and streams discovered vectors to a vector similarity search engine such as FAISS. Target platform is Flutter / Dart with tflite KNIFT model inference.
I am curious if there are any implementation suggestions for a realtime KNIFT classifier running on mobile, and streaming via gRPC KNIFT feature vectors to a vector similarity search engine? The goal would be realtime 3D object detection using approximate nearest neighbor search via FAISS, and with FAISS populated with previously scanned 3D object feature vectors.

Hello @pablogranolabar,
We are ending support for these MediaPipe Legacy Solutions, but upgrading the others. However, the libraries, documentation, and source code for all the MediapPipe Legacy Solutions will continue to be available in our GitHub repository and through library distribution services, such as Maven and NPM.
You can continue to use those legacy solutions in your applications if you choose. Though, we would request you to check new MediaPipe solutions which can help you more easily build and customize ML solutions for your applications. These new solutions will provide a superset of capabilities available in the legacy solutions.


All schedules are in UTC ignoring TIME_ZONE Settings.

I force checking TIME_ZONE settings for scheduling options as they are used in UTC instead of TIME_ZONE Settings

Please check this functionality and let mi know

Could you explain the problem you're trying to fix a little bit more?
It is per Django guidelines that all internal times are in UTC to prevent problems with timezone aware applications. Comparing datetimes is not affected by the timezone they are in, the comparison is always done after conversion.

When using Cron schedule, it next runtime is based on utc. not GMT -3. For example if I schedule to be run at 4:00 am GTM-3, it get schedule at 1:00 am GMT-3, because when it gets schedule coverts 4:00 am GMT-3 into 4:00 UTC and therefore when it gets schedule on next runtime it gets schedule at 1:00 am GMT -3

I think it is related to croniter, we need to pass current datetime, as you said we don't need to change Django timezone for select jobs to be run

@Koed00 did you understood the problem or need more info?

This #520  should be sufficient so closing this PR


object.reduce_ex does not exist

In what version? It seems to for me on 3.8:
Python 3.8.3 (default, Jun 27 2020, 11:30:16)
[Clang 8.0.7 (https://android.googlesource.com/toolchain/clang b55f2d4ebfd35bf6 on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> object.__reduce_ex__
<method '__reduce_ex__' of 'object' objects>
>>>

Oh, thank you. I have no idea whats happened last night.


ARROW-8885: [R] Don't include everything everywhere

Rather than #including everything in one header file and #including that in every .cpp file, this breaks out those includes to each .cpp file. There's also a more limited arrow_exports.h now that is included in the arrowExports.cpp that gets generated.
Installation/compilation time for the R bindings on my laptop (single-threaded) dropped from 130s to 90s (roughly 1/3 less, 40s total) as a result, so it seems like we were wasting a lot of CPU cycles before.
There's probably more improvements that could be made here, open to suggestion from those who understand C++ better.

@github-actions autotune

@nealrichardson the next step is probably to break arrowExport.{h,cpp} into one per file cpp file, e.g.
src/buffer.cpp
src/buffer.h
src/buffer_export.cpp
...

This will make the export file much smaller and require less headers to read, on top of allowing this to be parallelized (as opposed to a single thread for the huge file as it is). I suspect we can shave probably another 33%, the final link will still be a bottleneck.


Error in production but not in development

Current Behavior
Hello guys, How you all doing? hope you all are doing great.
I have been running into this issue for the past week and I am trying to figure out a solution for it.
I am using web3-onboard as my main wallet connector and it works completely find on development but when I push my project to production I get all sort of errors.
currently i am struggling with this error:

TypeError: Cannot read properties of undefined (reading 'version')
    at walletConnect (file:///vercel/path0/node_modules/@web3-onboard/walletconnect/dist/index.js:10:31)
    at /vercel/path0/.next/server/pages/_app.js:1522:94
> Build error occurred
Error: Failed to collect page data for /
    at /vercel/path0/node_modules/next/dist/build/utils.js:959:15
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  type: 'Error'

It happens for all pages and I cant seem to get it going away.
Next error I got is on the frontend when I try to connect to the website:
main-1a2cd11733cdaa06.js:1 TypeError: Cannot read properties of undefined (reading 'context')

main-1a2cd11733cdaa06.js:1 A client-side exception has occurred, see here for more info: https://nextjs.org/docs/messages/client-side-exception-occurred

main-1a2cd11733cdaa06.js:1 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'getInitialProps')

This error was the first error I got when I pushed my project, I dont get this error on my development environment but when I push to production I get it. I tried playing around and I got the other error but still no luck getting the wallet connector to work on production.
My setup is:
Next js 13.0.3
React: 18.2.0
Fails on Vercel deployment and AWS
Ethers: 5.7.2
not sure what other stuff I need to share.
Note:
I have succesfuully deployed this wallet connector before with Next 12 but with Next 13 I am having issues on production.
Expected Behavior
No response
Steps To Reproduce
No response
What package is effected by this issue?
@web3-onboard/core
Is this a build or a runtime issue?
Build, Runtime
Package Version
2.20.2
Node Version
16.18
What browsers are you seeing the problem on?
No response
Relevant log output
No response
Anything else?
No response
Sanity Check

[ ] If this is a build issue, I have included my build config. If this is a runtime issue, I have included reproduction steps and/or a Minimal, Reproducible Example.

Have you upgraded to the most recent version of @web3-onboard/walletconnect?
WalletConnect recently depreciated V1 and the team had to make some changes to the package

@cryptobredda is this still an issue for you after upgrading to the latest packages?

Closing due to inactivity. Please feel free to reopen with additional comments.


Use the alignment attribute under Integrity OS.

Integrity toolchain supports the attribute.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

No reason to wait any longer on this PR... merging.


A few recommendations

Cool library! I have a few recommendations that might make it less opinionated and a wee bit more customizable:

I suggest removing the wrapping nav element. It's not possible to opt out of it, and it's not really adding anything, right? Consumers can easily add that in on their own if they need to. I have a preference specify the nav markup outside of this lib.
Adopting a similar API as ReactTransitionGroup could be useful. It renders as a span unless the person specifies a component prop. This way, folks can use li, ul, div, or whatever they want.
accept a className prop to add a custom class name to the list component

I can make a PR if you think any of these are good ideas!

Thanks for wonderful recommendations!

I can make a PR if you think any of these are good ideas!

I agree with all of your recommendations and PR is always welcome :)

I would add some more recommendations :

remove the const win = window; const doc = document; as it breaks server-side rendering. Use the plain document and window variables in the code instead. This very simple fix made it work for me.

in your render() method, consider that some children can be null or an empty string when using conditional display of a menu entry, like :
{ user.isAdmin &&

 } which would render either the link or null depending on the user.

`const items = React.Children.map(this.props.children, (child, idx) => {
if (!child) return child;
`

I think all of the recommendations in this issue have been supported now.
Thanks for great recommendations :)


implement intercept publish message event on ManagedMqttClient

Discussion on this pull request can be found at @1470

It seems these are the errors:
CSC : error CS7027: Error signing output with public key from file 'D:\a\MQTTnet\MQTTnet\certificate.snk' -- Invalid public key. [D:\a\MQTTnet\MQTTnet\Source\MQTTnet\MQTTnet.csproj::TargetFramework=netstandard1.3]
CSC : error CS7027: Error signing output with public key from file 'D:\a\MQTTnet\MQTTnet\certificate.snk' -- Invalid public key. [D:\a\MQTTnet\MQTTnet\Source\MQTTnet\MQTTnet.csproj::TargetFramework=netstandard2.0]
CSC : error CS7027: Error signing output with public key from file 'D:\a\MQTTnet\MQTTnet\certificate.snk' -- Invalid public key. [D:\a\MQTTnet\MQTTnet\Source\MQTTnet\MQTTnet.csproj::TargetFramework=netstandard2.1]
CSC : error CS7027: Error signing output with public key from file 'D:\a\MQTTnet\MQTTnet\certificate.snk' -- Invalid public key. [D:\a\MQTTnet\MQTTnet\Source\MQTTnet\MQTTnet.csproj::TargetFramework=netcoreapp3.1]
CSC : error CS7027: Error signing output with public key from file 'D:\a\MQTTnet\MQTTnet\certificate.snk' -- Invalid public key. [D:\a\MQTTnet\MQTTnet\Source\MQTTnet\MQTTnet.csproj::TargetFramework=net5.0]
CSC : error CS7027: Error signing output with public key from file 'D:\a\MQTTnet\MQTTnet\certificate.snk' -- Invalid public key. [D:\a\MQTTnet\MQTTnet\Source\MQTTnet\MQTTnet.csproj::TargetFramework=net6.0]
CSC : error CS7027: Error signing output with public key from file 'D:\a\MQTTnet\MQTTnet\certificate.snk' -- Invalid public key. [D:\a\MQTTnet\MQTTnet\Source\MQTTnet\MQTTnet.csproj::TargetFramework=net7.0]
CSC : error CS7027: Error signing output with public key from file 'D:\a\MQTTnet\MQTTnet\certificate.snk' -- Invalid public key. [D:\a\MQTTnet\MQTTnet\Source\MQTTnet\MQTTnet.csproj::TargetFramework=net452]
CSC : error CS7027: Error signing output with public key from file 'D:\a\MQTTnet\MQTTnet\certificate.snk' -- Invalid public key. [D:\a\MQTTnet\MQTTnet\Source\MQTTnet\MQTTnet.csproj::TargetFramework=net461]
CSC : error CS7027: Error signing output with public key from file 'D:\a\MQTTnet\MQTTnet\certificate.snk' -- Invalid public key. [D:\a\MQTTnet\MQTTnet\Source\MQTTnet\MQTTnet.csproj::TargetFramework=net48]
CSC : error CS7027: Error signing output with public key from file 'D:\a\MQTTnet\MQTTnet\certificate.snk' -- Invalid public key. [D:\a\MQTTnet\MQTTnet\Source\MQTTnet\MQTTnet.csproj::TargetFramework=uap[10](https://github.com/dotnet/MQTTnet/actions/runs/7661927677/job/20882238981?pr=1915#step:8:11).0]


Include number of issues in summary message

The check could print "Found 44 issues", for example.

Released in v0.6.0


Traits: compute explicit implementation expressions

Consider the following code:
trait Show {
    fn show(self) -> String;
}
// Let's name this impl. `ShowStr`
impl Show for &str {
    fn show(self) -> String {
        self.to_string()
    }
}
// Let's name this impl. `ShowU8`
impl Show for u8 {
    fn show(self) -> String {
        format!("{}", self)
    }
}
// Let's name this impl. `ShowVec`
impl<T: Show, U: Show> Show for (T, U) {
    fn show(self) -> String {
        format!("({}, {})", self.0.show(), self.1.show())
    }
}

The expression (1, "a").show() is for now translated as a call to the method show of the typeclass/trait Show with argument (1, "a").
Some backends might have no typeclasses or traits, and some (like F*) have typeclasses mechanisms whose inference mechanism is not great.
Thus, we need the frontend to derive the implementation expressions (i.e. ShowVec ShowU8 ShowStr for (1, "a").show()).

Is there a good comparison between the type class implementations in F*,
Coq and lean?
https://www.fstar-lang.org/tutorial/book/part3/part3_typeclasses.html
On Wed, Apr 12, 2023 at 8:42 AM Lucas Franceschino @.***>
wrote:

Consider the following code:
trait Show {
fn show(self) -> String;}// Let's name this impl. ShowStrimpl Show for &str {
fn show(self) -> String {
self.to_string()
}}// Let's name this impl. ShowU8impl Show for u8 {
fn show(self) -> String {
format!("{}", self)
}}// Let's name this impl. ShowVecimpl<T: Show, U: Show> Show for (T, U) {
fn show(self) -> String {
format!("({}, {})", self.0.show(), self.1.show())
}}
The expression (1, "a").show() is for now translated as a call to the
method show of the typeclass/trait Show with argument (1, "a").
Some backends might have no typeclasses or traits, and some (like F*) have
typeclasses mechanisms whose inference mechanism is not great.
Thus, we need the frontend to derive the implementation expressions (i.e. ShowVec
ShowU8 ShowStr for (1, "a").show()).
—
Reply to this email directly, view it on GitHub
https://github.com/hacspec/hacspec-v2/issues/20, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABTNTTZVGIUC7TG7SM5VBLXAZFFNANCNFSM6AAAAAAW3HQ2B4
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

I believe there is some work on adding type classes to Easycrypt. Do you
happen to know more?
On Wed, Apr 12, 2023 at 8:51 AM Bas Spitters @.***>
wrote:

Is there a good comparison between the type class implementations in F*,
Coq and lean?
https://www.fstar-lang.org/tutorial/book/part3/part3_typeclasses.html
On Wed, Apr 12, 2023 at 8:42 AM Lucas Franceschino <
@.***> wrote:

Consider the following code:
trait Show {
fn show(self) -> String;}// Let's name this impl. ShowStrimpl Show for &str {
fn show(self) -> String {
self.to_string()
}}// Let's name this impl. ShowU8impl Show for u8 {
fn show(self) -> String {
format!("{}", self)
}}// Let's name this impl. ShowVecimpl<T: Show, U: Show> Show for (T, U) {
fn show(self) -> String {
format!("({}, {})", self.0.show(), self.1.show())
}}
The expression (1, "a").show() is for now translated as a call to the
method show of the typeclass/trait Show with argument (1, "a").
Some backends might have no typeclasses or traits, and some (like F*)
have typeclasses mechanisms whose inference mechanism is not great.
Thus, we need the frontend to derive the implementation expressions (i.e. ShowVec
ShowU8 ShowStr for (1, "a").show()).
—
Reply to this email directly, view it on GitHub
https://github.com/hacspec/hacspec-v2/issues/20, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABTNTTZVGIUC7TG7SM5VBLXAZFFNANCNFSM6AAAAAAW3HQ2B4
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

The F* documentation hints that they got that from Coq (dep records +
eauto proof search).
On Wed, Apr 12, 2023 at 9:01 AM Lucas Franceschino
@.***> wrote:

Mmh, so I have no idea whether there exist some comparisons, but in F* (and Coq I believe) typeclasses resolve to dependent records + special inference mechanism.
Yes, Easycrypt is about to get typeclasses (but I don't exactly know when!)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>

Oh, right, that makes sense then!

The extraction of impl expression from Rustc was done in the backend by #249


Manual migration handling multiple peak group representations

Summary Change Description
Note that this code ended up having to be more complex than I'd envisioned, mainly because mzXML files were loaded between the times that the migration (from #949) was run and this clean-up was done.  I ran it multiple times until I'd worked out all the issues.
This is not intended to be merged into main.  It is one-time use code that should be discarded after use on dev and prod, but I felt it was worthwhile to have a review.  This script:

Searches for multiple peak group represenations (there should be 1 compound peak group per sequence and sample).
Uses Michael's selections of the multiple representations to select which ones to keep and which to delete.
Moves any remaining peak groups to a single MSRunSample placeholder record and deletes the emptied one (if both peak groups have fake mzXMLs).
Does a final check to ensure all records with fake mzXML file records have been deleted.

Once this PR is approved, this branch should be checked out on dev and prod and run.
Affected Issues/Pull Requests

Resolves #974
NO MERGE - check out on dev and run

Review Notes

See comments in-line.
Checklist

This pull request will be merged once the following requirements are met.  The
author and/or reviewers should uncheck any unmet requirements:

Review requirements

Minimum approvals: 1
No changes requested
All blocking issues resolved by reviewers
Specific reviewers: @add_username_here

Review period: 2 days

Associated issue/pull request requirements:

[x] All requirements in affected issues marked "resolved" are satisfied
[x] All required pull requests are merged (or none)

Basic requirements

[x] All linters pass
[x] All tests pass
[x] All conflicts resolved

Overhead requirements

[x] New/changed method tests implemented/updated (or no change)
[ ] Updated Unreleased section of changelog.md (or no change)
[x] Migrations created & committed (or no change)

Ran this on dev.  The output is really long, so I took out the middle.
(tracebase) [tracebase@tb9-dev tracebase]$ python manage.py clean_reps --dry-run
Keeping 1 representative PeakGroup {'id': 69020, 'name': '3-Ureidopropionic acid', 'formula': 'C4H8N2O3', 'msrun_sample': 3908, 'peak_annotation_file': 171, 'compounds': [<Compound: 3-ureidopropionic acid>]}
Deleting duplicate PeakGroup {'id': 69446, 'name': '3-Ureidopropionic acid', 'formula': 'C4H8N2O3', 'msrun_sample': 3930, 'peak_annotation_file': 172, 'compounds': [<Compound: 3-ureidopropionic acid>]}
Keeping 1 representative PeakGroup {'id': 69040, 'name': '3-Ureidopropionic acid', 'formula': 'C4H8N2O3', 'msrun_sample': 3909, 'peak_annotation_file': 171, 'compounds': [<Compound: 3-ureidopropionic acid>]}
Deleting duplicate PeakGroup {'id': 69462, 'name': '3-Ureidopropionic acid', 'formula': 'C4H8N2O3', 'msrun_sample': 3931, 'peak_annotation_file': 172, 'compounds': [<Compound: 3-ureidopropionic acid>]}

...

Keeping MSRunSample and not taking the other's PeakGroups because this MSRunSample has a real mzXML file:
	{'id': 4103, 'msrun_sequence': 51, 'sample': 3879, 'polarity': 'positive', 'mz_min':<PHONE_NUMBER>79883, 'mz_max':<PHONE_NUMBER>84375, 'ms_raw_file': 380, 'ms_data_file': 413}

Keeping MSRunSample and not moving its PeakGroups because it has a real mzXML file:
	{'id': 4074, 'msrun_sequence': 51, 'sample': 3880, 'polarity': 'negative', 'mz_min': 59.100696563721, 'mz_max':<PHONE_NUMBER>03906, 'ms_raw_file': 382, 'ms_data_file': 381}

Keeping MSRunSample and not taking the other's PeakGroups because this MSRunSample has a real mzXML file:
	{'id': 4104, 'msrun_sequence': 51, 'sample': 3880, 'polarity': 'positive', 'mz_min':<PHONE_NUMBER>91309, 'mz_max':<PHONE_NUMBER>38281, 'ms_raw_file': 382, 'ms_data_file': 414}

Keeping MSRunSample and not moving its PeakGroups because it has a real mzXML file:
	{'id': 4075, 'msrun_sequence': 51, 'sample': 3881, 'polarity': 'negative', 'mz_min': 59.10432434082, 'mz_max':<PHONE_NUMBER>14844, 'ms_raw_file': 384, 'ms_data_file': 383}

Keeping MSRunSample and not taking the other's PeakGroups because this MSRunSample has a real mzXML file:
	{'id': 4105, 'msrun_sequence': 51, 'sample': 3881, 'polarity': 'positive', 'mz_min':<PHONE_NUMBER>29199, 'mz_max':<PHONE_NUMBER>11719, 'ms_raw_file': 384, 'ms_data_file': 415}

0 MSRunSample records with fake mzXML files remain.
0 ArchiveFile records with fake mzXML files remain.

Dry run completed successfully

It might be worth holding off on this until we determine the final resolution of the discussion #1191

Yeah, that makes sense.

We decided in our meeting on 9/4 to remove any duplicate representations of compounds in the same sample, so this PR should move ahead and get run in production to clean up the data.
Should we consider adding this script to the tracebase-rabinowitz-data repository since it's specific those data?

Honestly, I don't think it matters.  It shouldn't be merged anywhere.  We can just use it and close the PR as unmerged.  It has data hard-coded into it.

Honestly, I don't think it matters. It shouldn't be merged anywhere. We can just use it and close the PR as unmerged. It has data hard-coded into it.

I agree it doesn't belong in the tracebase repo, but given that it has data hardcoded into it and records decisions we made about the data in the rabinowitz repo, it would make sense to put it there. Or perhaps simply adding a file in the repo that records the compounds along with which file was ultimately used? I guess it's not that big of a deal, but it makes some sense to record this along with the study it references.

Rob drafted a proof-of-concept for the study doc excel sheet which helps the researcher select their preferred representation.  So if we use that, then the study doc maintains this record without deleting the original data.

Just FYI, I tried running this without the --dry-run flag and I encountered the following exception:
Traceback (most recent call last):
  File "/var/www/tracebase/DataRepo/models/maintained_model.py", line 343, in perform_buffered_updates
    buffer_item.save(mass_updates=True)
  File "/var/www/tracebase/DataRepo/models/hier_cached_model.py", line 189, in save
    super().save(*args, **kwargs)  # Call the "real" save() method.
  File "/var/www/tracebase/DataRepo/models/maintained_model.py", line 605, in save
    self.exists_in_db(raise_exception=True)
  File "/var/www/tracebase/DataRepo/models/maintained_model.py", line 934, in exists_in_db
    raise e
  File "/var/www/tracebase/DataRepo/models/maintained_model.py", line 931, in exists_in_db
    type(self).objects.get(pk__exact=self.pk)
  File "/usr/local/tracebase/lib/python3.9/site-packages/django/db/models/manager.py", line 87, in manager_method
    return getattr(self.get_queryset(), name)(*args, **kwargs)
  File "/usr/local/tracebase/lib/python3.9/site-packages/django/db/models/query.py", line 637, in get
    raise self.model.DoesNotExist(
DataRepo.models.msrun_sample.MSRunSample.DoesNotExist: MSRunSample matching query does not exist.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/var/www/tracebase/manage.py", line 22, in <module>
    main()
  File "/var/www/tracebase/manage.py", line 18, in main
    execute_from_command_line(sys.argv)
  File "/usr/local/tracebase/lib/python3.9/site-packages/django/core/management/__init__.py", line 442, in execute_from_command_line
    utility.execute()
  File "/usr/local/tracebase/lib/python3.9/site-packages/django/core/management/__init__.py", line 436, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/local/tracebase/lib/python3.9/site-packages/django/core/management/base.py", line 412, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/usr/local/tracebase/lib/python3.9/site-packages/django/core/management/base.py", line 458, in execute
    output = self.handle(*args, **options)
  File "/var/www/tracebase/DataRepo/management/commands/clean_reps.py", line 51, in handle
    self.clean_reps(options["dry_run"])
  File "/usr/lib64/python3.9/contextlib.py", line 79, in inner
    return func(*args, **kwds)
  File "/var/www/tracebase/DataRepo/models/maintained_model.py", line 1241, in wrapper
    fn(*args, **kwargs)
  File "/usr/lib64/python3.9/contextlib.py", line 126, in __exit__
    next(self.gen)
  File "/var/www/tracebase/DataRepo/models/maintained_model.py", line 1181, in custom_coordinator
    raise e
  File "/var/www/tracebase/DataRepo/models/maintained_model.py", line 1172, in custom_coordinator
    coordinator.perform_buffered_updates()
  File "/usr/lib64/python3.9/contextlib.py", line 79, in inner
    return func(*args, **kwds)
  File "/var/www/tracebase/DataRepo/models/maintained_model.py", line 357, in perform_buffered_updates
    raise AutoUpdateFailed(buffer_item, e, updater_dicts)
DataRepo.models.maintained_model.AutoUpdateFailed: Autoupdate of the MSRunSample model's fields [] in the database failed for record unknown.  Potential causes:
	1. The record was created and deleted before the buffered update (a catch for the exception should be added and ignored).
	2. The autoupdate buffer is stale and auto-updates are being attempted on non-existent records.  Find a previous call to a loader that performs mass auto-updates and ensure that clear_update_buffer() is called.
The triggering DoesNotExist exception: [MSRunSample matching query does not exist.].

I investigated and it makes total sense.  So when --dry-run is supplied, MaintainedModel automatically disables auto-updates.  But when you run without the --dry-run option, once the clean_reps script finishes, it runs a mass-auto-update to redo all of the fcirc calculations.  Any changes to the models whose data affects those calculations will trigger an auto-update of those calculations.
In this case, the strategy in dealing with these MSRunSample records containing fake mzxml files is to first delete duplicate peak groups of the de-selected compounds, migrate the kept peakgroups to the new placeholder MSRunSample records, and delete the MSRunSample records containing the fake mzxml's.
Here's where there is a problem:

Anytime you delete a PeakGroup record, an autoupdate is scheduled for the parent MSRunSample record.
In the case of the de-selected PeakGroups, their parent MSRunSample record is scheduled for manual deletion, later.
So during the mass auto-update, .save() is called on those deleted MSRunSample records, which raises a DoesNotExist exception, because we manually handled the deletion

So the solution is, when we delete PeakGroup records for which we know we will be deleting the MSRunSample record it links to, we should apply a MaintainedModel.no_autoupdates context manager, so the parent isn't scheduled for a auto-update.
I'm working on that solution now.  The alternative is to disable auto-updates entirely, run the script, then rebuild all maintained fields, but I'm going to see if I can get this to work quickly without needing to do that.

Success.  I was able to perform the update on dev, but I'd like another review before I run on prod.  The following is the mass autoupdate log.
0 MSRunSample records with fake mzXML files remain.
0 ArchiveFile records with fake mzXML files remain.

Auto-updated FCirc.is_last in FCirc.1559 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Sample.3765 to child FCirc.1560
Auto-updated FCirc.is_last in FCirc.1560 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from child Sample.3765 to parent Animal.369
Auto-updated Animal.last_serum_sample in Animal.369 using Animal._last_serum_sample from [exp048a_01_1440] to [exp048a_01_1440].
Propagating change from parent Animal.369 to child Sample.3766
Auto-updated Sample.is_serum_sample in Sample.3766 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3766 to child FCirc.1561
Auto-updated FCirc.is_last in FCirc.1561 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Sample.3766 to child FCirc.1562
Auto-updated FCirc.is_last in FCirc.1562 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Animal.369 to child Sample.3767
Auto-updated Sample.is_serum_sample in Sample.3767 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3767 to child FCirc.1563
Auto-updated FCirc.is_last in FCirc.1563 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Sample.3767 to child FCirc.1564
Auto-updated FCirc.is_last in FCirc.1564 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Animal.369 to child Sample.3768
Auto-updated Sample.is_serum_sample in Sample.3768 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3768 to child FCirc.1565
Auto-updated FCirc.is_last in FCirc.1565 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Sample.3768 to child FCirc.1566
Auto-updated FCirc.is_last in FCirc.1566 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Animal.369 to child Sample.3769
Auto-updated Sample.is_serum_sample in Sample.3769 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3769 to child FCirc.1567
Auto-updated FCirc.is_last in FCirc.1567 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Sample.3769 to child FCirc.1568
Auto-updated FCirc.is_last in FCirc.1568 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Animal.369 to child Sample.3770
Auto-updated Sample.is_serum_sample in Sample.3770 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3770 to child FCirc.1569
Auto-updated FCirc.is_last in FCirc.1569 using FCirc.is_last_serum_peak_group from [True] to [True].
Propagating change from parent Sample.3770 to child FCirc.1570
Auto-updated FCirc.is_last in FCirc.1570 using FCirc.is_last_serum_peak_group from [True] to [True].
Propagating change from child PeakGroup.69803 to parent MSRunSample.3909
Propagating change from child PeakGroup.69808 to parent MSRunSample.3910
Propagating change from child PeakGroup.69813 to parent MSRunSample.3911
Propagating change from child PeakGroup.69818 to parent MSRunSample.3912
Propagating change from child PeakGroup.69823 to parent MSRunSample.3913
Propagating change from child PeakGroup.69828 to parent MSRunSample.3914
Propagating change from child MSRunSample.3914 to parent Sample.3771
Auto-updated Sample.is_serum_sample in Sample.3771 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3771 to child FCirc.1571
Auto-updated FCirc.is_last in FCirc.1571 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Sample.3771 to child FCirc.1572
Auto-updated FCirc.is_last in FCirc.1572 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from child Sample.3771 to parent Animal.370
Auto-updated Animal.last_serum_sample in Animal.370 using Animal._last_serum_sample from [exp048a_02_0240] to [exp048a_02_0240].
Propagating change from parent Animal.370 to child Sample.3772
Auto-updated Sample.is_serum_sample in Sample.3772 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3772 to child FCirc.1573
Auto-updated FCirc.is_last in FCirc.1573 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Sample.3772 to child FCirc.1574
Auto-updated FCirc.is_last in FCirc.1574 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Animal.370 to child Sample.3773
Auto-updated Sample.is_serum_sample in Sample.3773 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3773 to child FCirc.1575
Auto-updated FCirc.is_last in FCirc.1575 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Sample.3773 to child FCirc.1576
Auto-updated FCirc.is_last in FCirc.1576 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Animal.370 to child Sample.3774
Auto-updated Sample.is_serum_sample in Sample.3774 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3774 to child FCirc.1577
Auto-updated FCirc.is_last in FCirc.1577 using FCirc.is_last_serum_peak_group from [True] to [True].
Propagating change from parent Sample.3774 to child FCirc.1578
Auto-updated FCirc.is_last in FCirc.1578 using FCirc.is_last_serum_peak_group from [True] to [True].
Propagating change from child PeakGroup.69833 to parent MSRunSample.3915
Propagating change from child PeakGroup.69838 to parent MSRunSample.3916
Propagating change from child PeakGroup.69843 to parent MSRunSample.3917
Propagating change from child PeakGroup.69848 to parent MSRunSample.3918
Propagating change from child MSRunSample.3918 to parent Sample.3775
Auto-updated Sample.is_serum_sample in Sample.3775 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3775 to child FCirc.1579
Auto-updated FCirc.is_last in FCirc.1579 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Sample.3775 to child FCirc.1580
Auto-updated FCirc.is_last in FCirc.1580 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from child Sample.3775 to parent Animal.371
Auto-updated Animal.last_serum_sample in Animal.371 using Animal._last_serum_sample from [exp048a_03_0240] to [exp048a_03_0240].
Propagating change from parent Animal.371 to child Sample.3776
Auto-updated Sample.is_serum_sample in Sample.3776 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3776 to child FCirc.1581
Auto-updated FCirc.is_last in FCirc.1581 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Sample.3776 to child FCirc.1582
Auto-updated FCirc.is_last in FCirc.1582 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Animal.371 to child Sample.3777
Auto-updated Sample.is_serum_sample in Sample.3777 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3777 to child FCirc.1583
Auto-updated FCirc.is_last in FCirc.1583 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Sample.3777 to child FCirc.1584
Auto-updated FCirc.is_last in FCirc.1584 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Animal.371 to child Sample.3778
Auto-updated Sample.is_serum_sample in Sample.3778 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3778 to child FCirc.1585
Auto-updated FCirc.is_last in FCirc.1585 using FCirc.is_last_serum_peak_group from [True] to [True].
Propagating change from parent Sample.3778 to child FCirc.1586
Auto-updated FCirc.is_last in FCirc.1586 using FCirc.is_last_serum_peak_group from [True] to [True].
Propagating change from child PeakGroup.69853 to parent MSRunSample.3919
Propagating change from child PeakGroup.69858 to parent MSRunSample.3920
Propagating change from child PeakGroup.69863 to parent MSRunSample.3921
Propagating change from child PeakGroup.69868 to parent MSRunSample.3922
Propagating change from child MSRunSample.3922 to parent Sample.3779
Auto-updated Sample.is_serum_sample in Sample.3779 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3779 to child FCirc.1587
Auto-updated FCirc.is_last in FCirc.1587 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Sample.3779 to child FCirc.1588
Auto-updated FCirc.is_last in FCirc.1588 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from child Sample.3779 to parent Animal.372
Auto-updated Animal.last_serum_sample in Animal.372 using Animal._last_serum_sample from [exp048a_04_0240] to [exp048a_04_0240].
Propagating change from parent Animal.372 to child Sample.3780
Auto-updated Sample.is_serum_sample in Sample.3780 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3780 to child FCirc.1589
Auto-updated FCirc.is_last in FCirc.1589 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Sample.3780 to child FCirc.1590
Auto-updated FCirc.is_last in FCirc.1590 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Animal.372 to child Sample.3781
Auto-updated Sample.is_serum_sample in Sample.3781 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3781 to child FCirc.1591
Auto-updated FCirc.is_last in FCirc.1591 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Sample.3781 to child FCirc.1592
Auto-updated FCirc.is_last in FCirc.1592 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Animal.372 to child Sample.3782
Auto-updated Sample.is_serum_sample in Sample.3782 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3782 to child FCirc.1593
Auto-updated FCirc.is_last in FCirc.1593 using FCirc.is_last_serum_peak_group from [True] to [True].
Propagating change from parent Sample.3782 to child FCirc.1594
Auto-updated FCirc.is_last in FCirc.1594 using FCirc.is_last_serum_peak_group from [True] to [True].
Propagating change from child PeakGroup.69873 to parent MSRunSample.3923
Propagating change from child PeakGroup.69878 to parent MSRunSample.3924
Propagating change from child PeakGroup.69883 to parent MSRunSample.3925
Propagating change from child PeakGroup.69888 to parent MSRunSample.3926
Propagating change from child MSRunSample.3926 to parent Sample.3783
Auto-updated Sample.is_serum_sample in Sample.3783 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3783 to child FCirc.1595
Auto-updated FCirc.is_last in FCirc.1595 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Sample.3783 to child FCirc.1596
Auto-updated FCirc.is_last in FCirc.1596 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from child Sample.3783 to parent Animal.373
Auto-updated Animal.last_serum_sample in Animal.373 using Animal._last_serum_sample from [exp048a_05_0240] to [exp048a_05_0240].
Propagating change from parent Animal.373 to child Sample.3784
Auto-updated Sample.is_serum_sample in Sample.3784 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3784 to child FCirc.1597
Auto-updated FCirc.is_last in FCirc.1597 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Sample.3784 to child FCirc.1598
Auto-updated FCirc.is_last in FCirc.1598 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Animal.373 to child Sample.3785
Auto-updated Sample.is_serum_sample in Sample.3785 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3785 to child FCirc.1599
Auto-updated FCirc.is_last in FCirc.1599 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Sample.3785 to child FCirc.1600
Auto-updated FCirc.is_last in FCirc.1600 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Animal.373 to child Sample.3786
Auto-updated Sample.is_serum_sample in Sample.3786 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3786 to child FCirc.1601
Auto-updated FCirc.is_last in FCirc.1601 using FCirc.is_last_serum_peak_group from [True] to [True].
Propagating change from parent Sample.3786 to child FCirc.1602
Auto-updated FCirc.is_last in FCirc.1602 using FCirc.is_last_serum_peak_group from [True] to [True].
Propagating change from child PeakGroup.69893 to parent MSRunSample.3927
Propagating change from child PeakGroup.69898 to parent MSRunSample.3928
Propagating change from child PeakGroup.69903 to parent MSRunSample.3929
Propagating change from child PeakGroup.70149 to parent MSRunSample.3952
Propagating change from child MSRunSample.3952 to parent Sample.3757
Auto-updated Sample.is_serum_sample in Sample.3757 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3757 to child FCirc.1551
Auto-updated FCirc.is_last in FCirc.1551 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from child Sample.3757 to parent Animal.367
Auto-updated Animal.last_serum_sample in Animal.367 using Animal._last_serum_sample from [exp048a_06_0240] to [exp048a_06_0240].
Propagating change from parent Animal.367 to child Sample.3758
Auto-updated Sample.is_serum_sample in Sample.3758 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3758 to child FCirc.1552
Auto-updated FCirc.is_last in FCirc.1552 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Animal.367 to child Sample.3759
Auto-updated Sample.is_serum_sample in Sample.3759 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3759 to child FCirc.1553
Auto-updated FCirc.is_last in FCirc.1553 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Animal.367 to child Sample.3760
Auto-updated Sample.is_serum_sample in Sample.3760 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3760 to child FCirc.1554
Auto-updated FCirc.is_last in FCirc.1554 using FCirc.is_last_serum_peak_group from [True] to [True].
Propagating change from child PeakGroup.70157 to parent MSRunSample.3953
Propagating change from child PeakGroup.70165 to parent MSRunSample.3954
Propagating change from child PeakGroup.70173 to parent MSRunSample.3955
Propagating change from child PeakGroup.70181 to parent MSRunSample.3956
Propagating change from child MSRunSample.3956 to parent Sample.3761
Auto-updated Sample.is_serum_sample in Sample.3761 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3761 to child FCirc.1555
Auto-updated FCirc.is_last in FCirc.1555 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from child Sample.3761 to parent Animal.368
Auto-updated Animal.last_serum_sample in Animal.368 using Animal._last_serum_sample from [exp048a_07_0240] to [exp048a_07_0240].
Propagating change from parent Animal.368 to child Sample.3762
Auto-updated Sample.is_serum_sample in Sample.3762 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3762 to child FCirc.1556
Auto-updated FCirc.is_last in FCirc.1556 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Animal.368 to child Sample.3763
Auto-updated Sample.is_serum_sample in Sample.3763 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3763 to child FCirc.1557
Auto-updated FCirc.is_last in FCirc.1557 using FCirc.is_last_serum_peak_group from [False] to [False].
Propagating change from parent Animal.368 to child Sample.3764
Auto-updated Sample.is_serum_sample in Sample.3764 using Sample._is_serum_sample from [True] to [True].
Propagating change from parent Sample.3764 to child FCirc.1558
Auto-updated FCirc.is_last in FCirc.1558 using FCirc.is_last_serum_peak_group from [True] to [True].
Propagating change from child PeakGroup.70189 to parent MSRunSample.3957
Propagating change from child PeakGroup.70197 to parent MSRunSample.3958
Propagating change from child PeakGroup.70205 to parent MSRunSample.3959

Note, all the autoupdates of maintained fields pertain to last serum samples, and none of that changed, so the mass autoupdate in this case is synonymous.  (It would be better if MaintainedModel had an added feature to only issue updates based on changes to specific fields so that we could surgically avoid the above autoupdates, but that's just a wishlist feature.)
The calculations are all handled by HierCachedModel-controlled methods, and the clean_reps script calls delete_all_caches which will lazily-refresh all the calculations.  Eventually, if/when we make the calculation functions to be maintained fields, their update would be handled by the mass autoupdate.

@lparsons - I am requesting a new review for the updates to the code based on the exception I encountered (and fixed) on dev, before I run this on prod.  I will also be pulling out changes from this branch of minor improvements to MaintainedModel into a new PR.  MaintainedModel's delete override functionality got some new edge-case vetting with this fix.  They are very simple improvements.

@lparsons - Just merged the changes in. Sorry, I forgot I'd created a separate branch. It's ready for review now.

The change here makes sense, so I'm approving this PR.
Related question: when the admin interface is turned on and a PeakGroup is deleted, will we run into this same issue? Or is this particular to how this script is handling things due to the "fake mzxml" records, etc.?

No.  This code used the defer_autoupdates context-manager(/decorator), which buffers updates to happen after a bunch of operations on records from multiple models, the purpose of which is to avoid repeated updates of records in intermediate states during a bunch of changes (like a load).  Part of those manipulations in this code were to delete records.  The exception was caused by those autoupdates running (once all the edits were complete) on deleted records during the changes implemented in the script.
Changes in the admin edit interface will not be inside the defer_autoupdates context manager, meaning autoupdates default to being performed immediately.  Since autoupdates are immediate in that context, there's no way for an autoupdate to run on a deleted record.
Even if what you're doing in the admin interface is a delete, it won't cause an error, because autoupdates triggered by delete operations run on related records, not the record itself.

This task is done. Nothing to merge.


[FEATURE] Enable debugging cols similar to the previous raw_generation and labelling_prompt

Is your feature request related to a problem? Please describe.
I'm testing a preference pipeline with Llama3 and the parsed outputs are weird (long lists of ratings and rationales when my number of generations is two). I'd like to have a way to automatically enable some columns in my resulting distiset to inspect:

The prompt sent by the UltraFeedback task
The raw responses parsed with the UF task

This is of course applicable to other Steps but it's more crucial when using tasks with complex prompt templates and output parsing.
Describe the solution you'd like
Something like enable debug columns when I setup the Task
Describe alternatives you've considered
Please suggest alternatives I can use in the meantime
Additional context
Add any other context or screenshots about the feature request here.

From now on, we can decide deal with this like in the example. Will update the docs accordingly!

From now on, we can decide deal with this like in the example. Will update the docs accordingly!
this looks awesome!


Add test suite for FileAccess

Currently covers #44269.
Adds CSV data file for testing purposes. FileAccessMemory could be used instead, but I don't see a reason for introducing additional complexity to the test case.

Note: currently fails, #44294 needs to be merged first.

Thanks!


Develop without recompile?

Hi, I'm experimenting with the new Razor Component features, and I'm super excited about the feature.
However, the very biggest flaw I found is that each and every HTML change requires a recompile before you can view it.  This means closing your browser and your state in the app, then getting to a new browser window and navigating back to the page and state you are working on).  I can see this adding a lot of time to development and possibly outweighing the benefit of not having to use javascript.  This is in contrast to traditional Asp.net that only requires a recompile if the code-behind changes, but html changes appear right away.
Are there any plans to not require a recompile for simple things like a CSS class change?  Are there different ways to develop that would remove this need (e.g. using a code behind rather than in-line functions)?  Are there certain types of changes that require a recompile (e.g. HTML inside a for-loop) vs changes that don't?
One thought I had is that early on in ASP.Net Core development, there was some setting I had on that auto-compiled the project after every change.  I'm not sure what it was, but I think it just monitored the folder for changes.   You couldn't debug this way, but you could keep IIS Express open and a single browser window and see the changes you made right away.
As a side question, will there be support for the Visual Studio "Browser Link" feature in the future?

Hi,
that is the same feature I miss after my testing of the new technology. Web development has become very complex (actually it always was), one really needs to play and try very often, it is impossible to program everything in advance and then run the build. Of course much can be done in Chrome, but then we need to manually copy paste the changed code to the Visual Studio, save, rebuild...
Otherwise I am very excited about the real return of C# to the web UI!

Does the development team have any feedback on this?  Our team is evaluating what we will be doing our next POC project in, and this is going to be a factor.

every HTML change requires a recompile before you can view it.

That's true, because what we're sending to the browser isn't HTML text, but rather are efficiently binary-serialized instructions that perform minimal updates on the DOM by diffing successive UI states. It is more optimized around production runtime than development time at this point.
Longer term we aim to restore the "auto recompile" feature we used to have, whereby each time you press "reload" in the browser, it automatically performs any necessary recompilation in the background. We hope to get this cycle time down to about 1 second for typical changes on typical dev machines.

This means closing your browser

You don't have to close your browser. I'd strongly recommend launching from VS using Ctrl+F5 to launch without debugging. This is faster, plus then your same browser window can remain open for as long as you want. Just reload that window after compiling any change.

Are there any plans to not require a recompile for simple things like a CSS class change?

When you edit .css files or other static assets, you can directly reload in the browser without needing any compile step.
If you mean editing a .razor file to change a CSS class reference, we will still need the same compilation pipeline in order to update the code that generates these UI update instructions. As above, our goal is to make this compilation process more convenient and faster.

One thought I had is that early on in ASP.Net Core development, there was some setting I had on that auto-compiled the project after every change. I'm not sure what it was, but I think it just monitored the folder for changes.

That's dotnet watch. You can do that with Razor Components today, but the build cycle time isn't near the standards we're aiming for. It typically takes 5-10 seconds to recompile even a small project. We aim to do much better than that with the autorebuild work.

As a side question, will there be support for the Visual Studio "Browser Link" feature in the future?

That's not something we're specifically planning for at the moment. If there are scenarios with this that are important to you, please let us know exactly what functionality you're feeling the loss of, because maybe we either might look at Browser Link in the future, or we might recreate similar capabilities in ways that better match up with our newer technology.
cc @danroth27 for any follow-up.

Longer term we aim to restore the "auto recompile" feature we used to have, whereby each time you press "reload" in the browser, it automatically performs any necessary recompilation in the background.

@SteveSandersonMS What exactly did you mean by "Longer term"? A future preview, the final release or after? There is any tracking for this feature?

What exactly did you mean by "Longer term"? A future preview, the final release or after? There is any tracking/roadmap for this feature?

@guidevnet We expect to get auto recompile back for .NET Core 3.0. It requires a tooling update though, so it will probably be a couple of months before this is available again.
/cc: @shirhatti @andrew-msft

Also, per some of the questions around syncing css and js and Browser Link support.  ASP.NET Core supports Browser Link in Visual Studio, but it's no longer on by default in the ASP.NET Core templates as we strive to make them work for all platforms since Browser Link is specific to Visual Studio.  You can enable Browser Link by following the instructions at https://docs.microsoft.com/en-us/aspnet/core/client-side/using-browserlink?view=aspnetcore-2.2
/cc: @metoly


Additional sandbox configuration to support EDX courses

The sandbox environment must additionally be configured such that:

a default quota is configured for provisioned projects
Orcid and Google IdPs are configured (the exact list to be confirmed @samuel-kerrien @adulbrich @MFSY)

The sandbox can NOT be wiped before applying the new configuration.
Provisional configuration (to be confirmed @samuel-kerrien @adulbrich @MFSY):

max-resources: 500
max-files: 500
max-file-size: 5MiB
max-size: 1GiB

Projects inactive after 3 months are automatically archived (value to be confirmed @samuel-kerrien @adulbrich @MFSY).
The tutorials presented in the documentation need to be updated to match the configured quota.
The permissions provisioned for users should include projects/archive such that they can start over if they made mistakes and are hitting the limits of the quota. (TBC @samuel-kerrien @adulbrich @MFSY)
Part of #2514.

@adulbrich @dhaneshnm @imsdu @nicwells @Stafeeva @samuel-kerrien @wwajerowicz Hey team! Can you please add your planning poker estimates with ZenHub


chore(ci): Mergify - merge Autobumps on release-*

And request review for failed autobump builds on master and release branches.
Lastly, remove Travis CI related rule. It's not used.

@mergifyio backport release-1.27.x release-1.28.x