Fixed the skipping of download links by screen reader

Fixes #1015
Changes:

I think aria-labelledby is supported for interactive content elements such as links and buttons by a screen reader but skipped for static elements. So, I removed the aria-labelledby attribute from the unordered lists which makes the screen reader works fine now.
Screenshots of the change:

NA

@lmccart Please review this PR 🙂

I think the issue actually might be that the lists have css property list-style: none so what we actually need here is roles set: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/List_role

@lmccart Thanks. Although lists have a role="list" by default still I tried adding role="list" to the ul and role="listitem" to li but the screen reader skipped it.

@Rahulm2310 ah ok. I'm good to merge your fix then, but are you able to provide any link that explains what's happening and how this fixes it? I just want to understand better. And to confirm, though you're removing the aria-labeledby tags, the headings are still staying attached to the lists from the screen reader perspective?

@lmccart removing the aria-labeledby tag is a work around but not a solution.

I think the issue actually might be that the lists have css property list-style: none which also hides it from screen readers.

Not sure if this is related to list-style:none as bottom list is also skipped by screen reader.
.
You can try running the chrome screen reader to know the actual problem. You can also try removing the aria-labelledby tag from chrome developer tools and try running the screen reader again to see if the problem is fixed or not. 🙂

@Rahulm2310 yes this was my understanding as well. That's why I thought adding the role="list" should address the issue, see references:
https://www.scottohara.me/blog/2019/01/12/lists-and-safari.html
https://gerardkcohen.me/writing/2017/voiceover-list-style-type.html

are you able to provide any link that explains what's happening

What's happening
Suppose this list :

Now when screen reader reads it, it just announces "Top Cakes, list with three items". It doesn't announces the list items Red Valvet, Coconut, Angel Food. But when I remove the aria-labelledby attribute from the ul then the list items are read by the screen reader.

Thank you. I was asking for a link that explains why using aria-labeledby prevents reading of lists.

Thanks @Rahulm2310 for working on it. I'm inviting this year's GSoC Web Accessibility contributor @katlich112358 and mentors @paulaxisabel @calebfoss to take a look at this, so we can decide how to move forward with this PR.

@Rahulm2310 I just checked how the screen reader examines this list on the Download page, and the chrome screen reader was able to read each individual list item (with the aria-labelledby applied). The NVDA also reads this list as well with the aria-labelledby applied.
Quickly scrubbing through the CSS styling, there's the chance that someone since this PR was opened has changed the list-style for this specific list (and overwritten the default list-style: none applied to all ul's)?

Quickly scrubbing through the CSS styling, there's the chance that someone since this PR was opened has changed the list-style for this specific list (and overwritten the default list-style: none applied to all ul's)?

I believe this is part of the change done by @davepagurek to normalize some styling of lists in webgl related reference.

Right, those changes were in https://github.com/processing/p5.js-website/pull/1368 and https://github.com/processing/p5.js-website/pull/1377 so that list-style: none is now applied to specific cases rather than being the default for uls.

@limzykenneth @davepagurek awesome, thank you! That means this issue can be closed, correct?


tracer.Apply only supports the default http Transport

Currently it uses http.DefaultTransport when it should do one of the following:

Use the clients existing Transport
Allow the user to pass a parameter into Apply which specifies the Transport to use

https://github.com/djcass44/go-tracer/blob/master/tracer/client.go#L42

Closed by #4


Compile fails on latest master

error: ‘WILD_NOERROR’ undeclared (first use in this function) pops op when compiling latest master (also on CI, for example: https://travis-ci.org/vim/vim/jobs/600128838#L772).
Seems there is a change missing in the latest master.

Fixed by 8.1.2188


Release v4.5

Branch off release/v4.5.x from release/v4.4.x.
Bump ics23 to v0.10.0 in release/v4.5.x
Bump ics23 to v0.9.1 (release of v0.9.x with this PR) in release/4.5.x.
Run compatibility tests.
Tag release.

Bumping this -- would it be possible to tag a release soon?

@hdevalence We had some issues integrating ics23 v0.10.0 into the v4 release line last week because v0.10.0 also migrated from gogo/protobuf to cosmos/gogoproto. We discussed this morning a work around and we are going to try to cherry pick and backport the prehash_compare_key PR into the release/v0.9.x of ics23. If I have a branch or tag this evening, would you be able to integrate into in some test environment and let us know if it works? Thank you!

Sure, we'd be happy to assist any way we can. Thank you!

I was able to pull this commit into an osmosis localnet, using this replace directive in go.mod
replace (
	// osmosis-patched wasmd.
	github.com/CosmWasm/wasmd => github.com/osmosis-labs/wasmd v0.31.0-osmo-v16
	// Security patch for wasmvm. See https://github.com/CosmWasm/advisories/blob/main/CWAs/CWA-2023-002.md
	github.com/CosmWasm/wasmvm => github.com/CosmWasm/wasmvm v1.2.3

	// dragonberry
	//	github.com/confio/ics23/go => github.com/cosmos/cosmos-sdk/ics23/go v0.8.0
	// Our cosmos-sdk branch is:  https://github.com/osmosis-labs/cosmos-sdk, current branch: osmosis-main. Direct commit link: https://github.com/osmosis-labs/cosmos-sdk/commit/05346fa12992
	github.com/cosmos/cosmos-sdk => github.com/osmosis-labs/cosmos-sdk v0.45.0-rc1.0.20230908065430-05346fa12992

	// N.B. v0.19.5 contains a breaking change to the IAVL API
	github.com/cosmos/iavl v0.19.5 => github.com/cosmos/iavl v0.19.4

	// TEST 4.5
	github.com/cosmos/ibc-go/v4 => github.com/cosmos/ibc-go/v4 0f799562aef00c60cd611e3d849fc5a07a0e62ee

	// use cosmos-compatible protobufs
	github.com/gogo/protobuf => github.com/regen-network/protobuf v1.3.3-alpha.regen.1

	// Informal Tendermint fork
	github.com/tendermint/tendermint => github.com/informalsystems/tendermint v0.34.24
	// use grpc compatible with cosmos protobufs
	google.golang.org/grpc => google.golang.org/grpc v1.33.2
)

(note that i commented out the replace for ICS23, since i think the cherrypicked commit includes the dragonberry fix. please verify this)
I ran the osmosis localnet with the make localnet-* osmosis scripts, funded a hermes relayer, and used our hermes relayer fork with the PrehashKeyBeforeComparison: true proofspec. I was able to successfully open channels, where before the handshake would fail due to an unknown field.

Thank you for testing, @avahowell. Happy to hear that this is working!

since i think the cherrypicked commit includes the dragonberry fix. please verify this

Yes, the release/v0.9.x branch of ics23 includes the dragonberry fix.
I will proceed to tag the releases. We should have v4.5 ready by the end of the week.

Green compatibility tests before RC0.

Awesome! Thanks for your work on this.

Closed by https://github.com/cosmos/ibc-go/releases/tag/v4.5.0.


Migrate content generation to be able to use transactions

Things like BlockBuilder and BlockProvider are organized around &mut Universe. It should be possible to use transactions instead for all the same functionality, so that they can be done asynchronously within an existing session.

This has been fixed. The remaining &mut Universes are internal to the content and UI crates, so they can be removed as needed but don't affect API.


fix: update marketplace list help command

What this PR is for?
This PR removes a duplicated FLAGS into miactl marketplace list --help command

LGTM


Fixed broken tests, bad merge, regression in RC guid calculation (ProjectedRuntimeClass attrib), and made vector view GRCN more reliable

thanks!!!


Show error in the folder

VSCode Version: 1.6.0-insider 25b370a
OS Version: Windows 10

--Sorry for the English, I used Google Translator --
Steps to Reproduce:

When you open a folder VSCode it wrong in that inside the folder.
If we click it shows each location of the error.

If we click on an error, it shows other error concerning that file.

But we do not have the option to go back to see the other errors.
And when you close the tab related to the error even clean all design errors.

**This is the Bootstrap files.

I think this works as designed. The message when there are no problem is confusion though, it should say that no problems were detected in the selected files/folder or similar.

@chrmarti I believe he is not showing any errors that exist within the folder.
I made a change in npm.js taking parenthesis ')'. Reload Window. See that it only showed the css error. Opening the separate js file in a new window it showed the error that was not displayed when you open the entire folder.

@Tekbr Current strategy of reporting errors is

they are generated when you open a file
they are cleaned when you close the file

I am a bit surprised with the initial state of yours that shows problems when a folder selected. Can you please let me know if you have any extension installed that generated problems?

I own these installed extensions.
You mean that this function not originally exist in vscode? So it would be interesting to show the same errors that may exist in my folder? Be css, js among others?

--Sorry for the English, I used Google Translator --
@sandy081 I believe that is not a problem but a resource of HTML CSS Class Completion extension.
I close this issue and open another requesting similar feature that makes this extension, but for all files, making reference to this case? (Or if you prefer you create a new issue explaining better this question - my English is not very good)
The is at the discretion of you:

be a native form and allow the user to choose or not which file types should be checked the errors and warnings.
or an official extension to allow the user to choose or not which file types should be checked the errors and warnings.

What do you think?

@Tekbr Closing this issue since as you said it is due to HTML CSS Class Completion extension. I think the current out of the box functionality is good enough. Like the other extensions, this functionality can be implemented in an extension. So not filing a feature request for that.
Thanks

@sandy081 If I understand correctly there is a feature request for this, so you mean?
Sorry for the little understanding of English.

@Tekbr No there is no feature request yet. What I meant was generating errors / warnings on a folder is not an intended behaviour to me. You can always write a new extension for doing that.

@sandy081 Thanks for the answer. Yes, I said in a suggestion of extension or natively, but configured according to the user.


More than a Homepod Mini

Hello,
I would like to know is it possible to integrate more than one Homepod / or Airplay-er ?
If so, how does that work ?
{
"platform": "HomepodRadioPlatform",
{ "name": "Homepod Radio",
"model": "BBC - Radio 1",
"homepodId": "FIRST-ID, SeCOND-ID",
"radioUrl": "http://stream.live.vc.bbcmedia.co.uk/bbc_radio_one"
}

Hi, technically should be possible - for each HomePod plugin can start separate atvremote streaming pipe...
I could add support for multiple devices later, once other issues polished with single HomePod implementation (streaming process potential crashes, and/or cases when HomePod starts playing from other device)

Hi all,
Depending on your application, I have a working around that I am testing at the moment.
My use case is that I want to use 2 x homepods and 6 x JBL airflys (airplay1) to sound an internal siren around the house as part of my alarm system trigger.
I have set up according to the instructions, and have a common siren mp3 sound file on localhost.
I have multiple HomePodPlatform instances in my homebridge configuration, each with a different port number, and each with a different 'radio' name, but all pointing to the same directory and siren mp3 file.
Each instance shows as a separate button in Homekit.
Then I set up a dummy button (from [https://github.com/nfarina/homebridge-dummy]) and set up an automation to trigger each of the speaker buttons from the HomePodPlatform instances.
I found that you set the speaker automation to 'resume' audio (if you use 'play' it wants you to set an Apple Music sound which is not what we want here).
Now I just need to hit the 'dummy' button and the siren plays on each of the speaker instances I have set up.  There is a separate delay for each speaker (unfortunately), so they are not syncronised - but for my use case that is not a problem.
Will be great if we can one day stream to multiple speakers from the one instance in homebridge, but this work around might help a few.
Take care,
Justin.


More EuropePMC errors

https://elifesciences.slack.com/archives/C01GMPQC8NS/p1629669534015300
TImebox investigation to 1 hour.

There seem to have been 13 instances of us not being able to parse responses from EPMC over last 30 days: https://sciety.grafana.net/explore?orgId=1&left=["now-30d","now","grafanacloud-sciety-logs",{"expr":"{app_kubernetes_io_name%3D\"sciety\",app_kubernetes_io_instance%3D\"sciety--prod\"}\n| json | __error__%3D\"\"\n| level %3D \"error\" | message%3D\"Could not parse response\""}]

Reproducible at first on:
http://localhost:8080/search?query=COVID-19&category=articles&cursor=AoJwgNTA/oCKDQ0MjUxOTgw&page=11
but not when getting at page 11 through the link on page 10:
http://localhost:8080/search?query=COVID-19&category=articles&cursor=AoJwgJn6jvsCKDQ0MjkwNzQ4&page=11

https://www.ebi.ac.uk/europepmc/webservices/rest/search?query=("2019-nCoV"+OR+"2019nCoV"+OR+"COVID-19"+OR+"SARS-CoV-2"+OR+"COVID19"+OR+"COVID"+OR+"SARS-nCoV"+OR+("wuhan"+AND+"coronavirus")+OR+"Coronavirus"+OR+"Corona+virus"+OR+"corona-virus"+OR+"corona+viruses"+OR+"coronaviruses"+OR+"SARS-CoV"+OR+"Orthocoronavirinae"+OR+"MERS-CoV"+OR+"Severe+Acute+Respiratory+Syndrome"+OR+"Middle+East+Respiratory+Syndrome"+OR+("SARS"+AND+"virus")+OR+"soluble+ACE2"+OR+("ACE2"+AND+"virus")+OR+("ARDS"+AND+"virus")+or+("angiotensin-converting+enzyme+2"+AND+"virus"))+(PUBLISHER%3A%22bioRxiv%22+OR+PUBLISHER%3A%22medRxiv%22)+sort_date%3Ay&format=json&pageSize=20&resultType=core&cursorMark=AoJwwLadh%2FsCKDQ0MjcwMzkw
has a %2F in the cursor, but it works.

Most recent example: https://sciety.grafana.net/explore?orgId=1&left=["now-2d","now","grafanacloud-sciety-logs",{"expr":"{app_kubernetes_io_name%3D\"sciety\",app_kubernetes_io_instance%3D\"sciety--prod\"}\n| json | __error__%3D\"\"\n| payload_requestId %3D \"0ac67810-0f1d-11ec-90cf-1353783449b7\""}]

2021-09-06T14:16:35.089Z is the timestamp of page 16, the failing one. We can reproduce this locally, as expected.

By running:
https://sciety.grafana.net/explore?orgId=1&left=["now-2d","now","grafanacloud-sciety-logs",{"expr":"{app_kubernetes_io_name%3D\"sciety\",app_kubernetes_io_instance%3D\"sciety--prod\"}\n| json | __error__%3D\"\"\n| payload_url %3D~ \"%2Fsearch%3Fquery%3DC.%2520elegans%26category%3Darticles%26cursor%3D[^%26]%2B%26page%3D16\""}]
we found page 16 was loaded successfully a couple of hours later:
2021-09-06T17:59:38.031Z
and the cursor, 2 days later, still works:
http://localhost:8080/search?query=C. elegans&category=articles&cursor=AoJwgL2W5/UCKDQyNjM5MjUx&page=16

We think page 15 was loaded 30 seconds before the failing page 16:
https://sciety.grafana.net/explore?orgId=1&left=["now-2d","now","grafanacloud-sciety-logs",{"expr":"{app_kubernetes_io_name%3D\"sciety\",app_kubernetes_io_instance%3D\"sciety--prod\"}\n| json | __error__%3D\"\"\n| payload_url %3D~ \"%2Fsearch\\\\%3Fquery%3DC.%2520elegans%26category%3Darticles%26cursor%3D[^%26]%2B%26page%3D15\""}]
2021-09-06T14:16:05.520Z

Confirming pages 15 and 16 were requested by the same client https://sciety.grafana.net/explore?orgId=1&left=["now-2d","now","grafanacloud-sciety-logs",{"expr":"{app_kubernetes_io_name%3D\"ingress-nginx\"}\n|json\n| request %3D~ \"GET %2Fsearch\\\\%3Fquery%3DC.%2520elegans%26category%3Darticles%26cursor%3D[^%26]%2B%26page%3D1(5|6) .*\""}]

When we now load page 15 with the original url /search?query=C.%20elegans&category=articles&cursor=AoJwgM7P3fYCKDQyODkxNDY3&page=15:

it still works
the cursor it returns for page 16 within /search?query=C.%20elegans&category=articles&cursor=AoJwgP+ir/YCKDQyNzg1Mjky&page=16 is the same as the broken one that started this investigation, and it's still broken.

Page 15: https://www.ebi.ac.uk/europepmc/webservices/rest/search?query=C.+elegans+(PUBLISHER%3A"bioRxiv"+OR+PUBLISHER%3A"medRxiv")+sort_date%3Ay&format=json&pageSize=20&resultType=core&cursorMark=AoJwgM7P3fYCKDQyODkxNDY3
Page 16: https://www.ebi.ac.uk/europepmc/webservices/rest/search?query=C.+elegans+(PUBLISHER%3A"bioRxiv"+OR+PUBLISHER%3A"medRxiv")+sort_date%3Ay&format=json&pageSize=20&resultType=core&cursorMark=AoJwgP+ir%2FYCKDQyNzg1Mjky

Followed up on https://groups.google.com/a/ebi.ac.uk/g/epmc-webservices/c/7B-gzP5xcPE giving this to Europe PMC as a reproducible bug.

Still an error to be investigated after our fix was already deployed:
Today at 1:21 AM
{
    "errors": [
        "Invalid value undefined supplied to : { hitCount: number, nextCursorMark: Option<string>, resultList: { result: Array<{ doi: DoiFromString, title: string, authorList: { author: ReadonlyArray<({ fullName: string } | { collectiveName: string })> }, bookOrReportDetails: { publisher: (\"bioRxiv\" | \"medRxiv\") } }> } }/hitCount: number",
        "Invalid value undefined supplied to : { hitCount: number, nextCursorMark: Option<string>, resultList: { result: Array<{ doi: DoiFromString, title: string, authorList: { author: ReadonlyArray<({ fullName: string } | { collectiveName: string })> }, bookOrReportDetails: { publisher: (\"bioRxiv\" | \"medRxiv\") } }> } }/resultList: { result: Array<{ doi: DoiFromString, title: string, authorList: { author: ReadonlyArray<({ fullName: string } | { collectiveName: string })> }, bookOrReportDetails: { publisher: (\"bioRxiv\" | \"medRxiv\") } }> }"
    ],
    "url": "https://www.ebi.ac.uk/europepmc/webservices/rest/search?query=C.+elegans+%28PUBLISHER%3A%22bioRxiv%22+OR+PUBLISHER%3A%22medRxiv%22%29+sort_date%3Ay&format=json&pageSize=20&resultType=core&cursorMark=AoJwgNqD+%2FQCKDQyMzYwMDg4",
    "requestId": "fc6c7690-11cc-11ec-8346-fbf8e30d3db3"
}

Also failing:
https://www.ebi.ac.uk/europepmc/webservices/rest/search?query=%28%222019-nCoV%22+OR+%222019nCoV%22+OR+%22COVID-19%22+OR+%22SARS-CoV-2%22+OR+%22COVID19%22+OR+%22COVID%22+OR+%22SARS-nCoV%22+OR+%28%22wuhan%22+AND+%22coronavirus%22%29+OR+%22Coronavirus%22+OR+%22Corona+virus%22+OR+%22corona-virus%22+OR+%22corona+viruses%22+OR+%22coronaviruses%22+OR+%22SARS-CoV%22+OR+%22Orthocoronavirinae%22+OR+%22MERS-CoV%22+OR+%22Severe+Acute+Respiratory+Syndrome%22+OR+%22Middle+East+Respiratory+Syndrome%22+OR+%28%22SARS%22+AND+%22virus%22%29+OR+%22soluble+ACE2%22+OR+%28%22ACE2%22+AND+%22virus%22%29+OR+%28%22ARDS%22+AND+%22virus%22%29+or+%28%22angiotensin-converting+enzyme+2%22+AND+%22virus%22%29%29+%28PUBLISHER%3A%22bioRxiv%22+OR+PUBLISHER%3A%22medRxiv%22%29+sort_date%3Ay&format=json&pageSize=20&resultType=core&cursorMark=AoJwgNTA%2FoCKDQ0MjUyMDA3

which is a very elaborate query.

Reproducing locally on:
/search?query=%20%28%22membrane*%22%20OR%20%22protein*%22%29%20AND%20%28%22membrane%20protein*%22%20OR%20%22ion%20channel*%22%20OR%20%22transporter*%22%20OR%20%22pump*%22%20OR%20%22gpcr*%22%20OR%20%22ligand*%22%20OR%20%22exchange*%22%20OR%20%22uniport*%22%20OR%20%22symport*%22%20OR%20%22antiport*%22%20OR%20%22solute%20carrier*%22%20OR%20%22atpase*%22%20OR%20%22atp%20synthase*%22%20OR%20%22rhodopsin%22%20OR%20%22patch*%22%20OR%20%22voltage*%22%20OR%20%22single-channel*%22%20OR%20%22anion*%22%20OR%20%22cation*%22%20OR%20%22gating%22%20OR%20%22activat*%22%20OR%20%22inactivat*%22%20OR%20%22selectiv*%22%29&category=articles&cursor=AoJwwKu+n/kCKDQzNzA0Mzkw&page=31

which happened this morning.

This looks like a bot refreshing its cached pages rather than something legitimately scrolling through search. Can only find two request logs for this query rather than 31 pages:
{
  "time_local": "21/Sep/2021:05:42:14 +0000",
  "remote_addr": "<IP_ADDRESS>",
  "request": "GET /search?query=%20%28%22membrane*%22%20OR%20%22protein*%22%29%20AND%20%28%22membrane%20protein*%22%20OR%20%22ion%20channel*%22%20OR%20%22transporter*%22%20OR%20%22pump*%22%20OR%20%22gpcr*%22%20OR%20%22ligand*%22%20OR%20%22exchange*%22%20OR%20%22uniport*%22%20OR%20%22symport*%22%20OR%20%22antiport*%22%20OR%20%22solute%20carrier*%22%20OR%20%22atpase*%22%20OR%20%22atp%20synthase*%22%20OR%20%22rhodopsin%22%20OR%20%22patch*%22%20OR%20%22voltage*%22%20OR%20%22single-channel*%22%20OR%20%22anion*%22%20OR%20%22cation*%22%20OR%20%22gating%22%20OR%20%22activat*%22%20OR%20%22inactivat*%22%20OR%20%22selectiv*%22%29&category=articles&cursor=AoJwwKu+n/kCKDQzNzA0Mzkw&page=31 HTTP/1.1",
  "http_referrer": "",
  "http_user_agent": "Mozilla/5.0 (compatible; BLEXBot/1.0; +http://webmeup-crawler.com/)",
  "status": "503",
  "proxy_upstream_name": "default-sciety--prod--frontend-http",
  "upstream_status": "503",
  "upstream_response_time": "0.420",
  "ingress_name": "sciety--prod--frontend",
  "namespace": "default"
}
{
  "time_local": "21/Sep/2021:05:42:11 +0000",
  "remote_addr": "<IP_ADDRESS>",
  "request": "GET /search?query=%20%28%22membrane*%22%20OR%20%22protein*%22%29%20AND%20%28%22membrane%20protein*%22%20OR%20%22ion%20channel*%22%20OR%20%22transporter*%22%20OR%20%22pump*%22%20OR%20%22gpcr*%22%20OR%20%22ligand*%22%20OR%20%22exchange*%22%20OR%20%22uniport*%22%20OR%20%22symport*%22%20OR%20%22antiport*%22%20OR%20%22solute%20carrier*%22%20OR%20%22atpase*%22%20OR%20%22atp%20synthase*%22%20OR%20%22rhodopsin%22%20OR%20%22patch*%22%20OR%20%22voltage*%22%20OR%20%22single-channel*%22%20OR%20%22anion*%22%20OR%20%22cation*%22%20OR%20%22gating%22%20OR%20%22activat*%22%20OR%20%22inactivat*%22%20OR%20%22selectiv*%22%29&category=articles&cursor=AoJwgOrnu/kCKDQzNzU1NjU3&page=29 HTTP/1.1",
  "http_referrer": "",
  "http_user_agent": "Mozilla/5.0 (compatible; BLEXBot/1.0; +http://webmeup-crawler.com/)",
  "status": "200",
  "proxy_upstream_name": "default-sciety--prod--frontend-http",
  "upstream_status": "200",
  "upstream_response_time": "3.032",
  "ingress_name": "sciety--prod--frontend",
  "namespace": "default"
}


fix: fee calculation for evm transactions

https://app.clickup.com/t/2chjkyx

Was tested on moonbeam and polkadot networks ✅


Create eslint rule to prevent the use of ByServerRelativeUrl API

Let's add an eslint rule to prevent some SP APIs from being used. We should avoid ByServerRelativeUrl API endpoints because they don't support files and folders with # and % characters in their name.
Following API endpoints should be avoided

GetFileByServerRelativeUrl
GetFolderByServerRelativeUrl

Instead, we should use:

GetFileByServerRelativePath
GetFolderByServerRelativePath

This issue is on hold until these issues are closed:

#5328
#4968

Awesome idea to create an eslint rule for this situation so we can prevent it from getting back into our codebase.

Moved from on hold to help wanted.


Add owner of shard to last_seq of changes response

Prior to this commit, there was a bug where the response of a changes
query would include epoch information for every change, but not for the
last sequence. Subsequent shard changes queries would rewind from zero
if the last_seq field was used in the clustered changes query and any
shard had previously been moved.

+1.

+1 Nice find.

Merged.


events link leads to a dead end

The events and media page in the community menu leads to a dead end: https://www.tremor.rs/community/EventsAndMedia.md

fixed with #91


I keep getting broken html links, no matter what case

Links keep on breaking when inserted into the iframe, no matter what I try
Test_text = http://www.laravel.io is a great place to learn
Copy and paste output: http://www.laravel.io">http://www.laravel.io is a great place to learn
Using the link builder button output: http://laravel.io">laravel.io is a great place to learn
Typing it by hand output: http://laravel.io">http://laravel.io is a great place to learn
complete html of problem area: \

http://laravel.io">http://laravel.io is a great place to learn

Fixed it myself

Care to explain? Was this a problem with wysihtml or your project setup? If the cause was in wysihtml, can you share your fix for others?


Added NOTICE.md files next to dockerfiles

This PR serves to help keep our project aligned with the TRGs and other open-source policies.
In this case, we have created and added the NOTICE.md files, to the build folder, next to the dockerfiles.
fix #39

@SebastianBezold updated


update binaries

Updates the calico resource building script to pull in new binaries and the charm to use them properly. Passes dashboard, microbot, & e2e.

:+1: Done and tested, thanks for the review @Cynerva


Extend section about complementary extensions

I will also add the embark package and add setup instructions for it on the wiki when #95 is handled.

No need to be sorry, thanks!


Integration with Zenodo

Add a new option inside "storage configuration" (ModuleTrain) that has two alternatives to import a Zenodo dataset. The first one has:

Select field to choose a zenodo dataset
Select field linked to the previous one to select the dataset's version

The second one has:

Input field to write a record ID from Zenodo

Both of them use:

Slide toggle to select if you want to force pull or not

Additional requirements:

check that if the user has defined zenodo_record_id it has also specified all rclone_* variables, otherwise the task won't launch.


Downgrade to CCS811 Old Firmware v1.0.0

Hi guys!
I've modified my chinesse CSS811 board and soldered a 10k SMD NTC and a 10k SMD Resitor (R3 and R4 in original schematic) in orther to get Temperature readings.
The fact was that I had this board updated to firmware version 2.0.1 and it wasn't impossible to get temperature readings with this firmware.
So after a lot of searching Internet, I've found the old firmware to get temperature readings.
And of course downgraded it with success.
Here you have that firmware.
ccs811_fw_app_1v0p0.bin.zip
Hope it will serve to somebody.

Thanks. I'll add it to the repo. Where did find it?

https://github.com/ryankurte/efm32-base/blob/master/hardware/kit/common/bsp/thunderboard/ccs811_fw_app_1v0p0.bin

Here you can see R3 qnd R4

And here my updated CSS811 board.

Nice!
I didn't realize the board had the mounting pads already,
Thanks for the 1.0.0 bin file; I have added it to the repo.
I've also changed the python script. The old one was still working for me, so I'm not sure what was the problem for you. It now uses f-strings.

Thanks to you for your contribution.


BREAKING feat(core): use human readable abis

Description
Make the type used by EVMts human readable abis
Testing
Explain the quality checks that have been done on the code changes
Additional Information

[ ] I read the contributing docs (if this is your first contribution)

Your ENS/address:

Current dependencies on/for this PR:

main

PR #486   👈

This comment was auto-generated by Graphite.


OpenStreetMap API instead of Bing

I know this is called leaflet-control-bing-geocoder but anyway I want to say that there is also a OpenStreetMap API for that. https://nominatim.openstreetmap.org/search/<query>?format=json... With this you don't need an access token and it is based on the same data like map itself.
If you don't consider that as a good idea, it would be better if you change http to https...
https://github.com/sa3m/leaflet-control-bing-geocoder/blob/master/Control.BingGeocoder.js#L78

@dscso see also https://github.com/perliedman/leaflet-control-geocoder, which is a fork of this plugin, but with support for a lot of geocoding services, Nominatim is one of them.


The first sample doesn't pass parameters by ref

Type of issue
Typo
Description
It looks like the included sample may have been duplicated and modified based on updates in another article.
Page URL
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/ref
Content source URL
https://github.com/dotnet/docs/blob/main/docs/csharp/language-reference/keywords/ref.md
Document Version Independent Id
4f413bcc-90e7-d971-fe75-b4876124e75d
Article author
@BillWagner
Metadata

ID: 3d67349b-72bc-b7cf-f754-fa62d1fb592d
Service: dotnet-csharp
Sub-service: lang-reference

Duplicate of #42499


A path base can only be configured using IApplicationBuilder.UsePathBase()

https://docs.microsoft.com/en-us/aspnet/core/tutorials/getting-started-with-nswag?view=aspnetcore-2.2&tabs=visual-studio
System.InvalidOperationException:“A path base can only be configured using IApplicationBuilder.UsePathBase().”

Can you provide more context? When does this show up? Do you have an example code?

sorry ,my code wrong!in launchSettings.json i lost "applicationUrl"


Changes to Application View

As an Admin I want to view candidate character information on the application view so that access the candidate information.

Not required

Not required


The Hardware environment

Hello, could you please tell me what the minimum hardware requirements are for running this project? For example, memory size, video memory size, etc., because it crashed directly when I tried to run it on my 16g computer.

The minimum requirements vary based on the chosen model and task. For example, training a simple model like LeNet on a basic dataset such as MNIST requires relatively modest computational resources.
Maybe you can provide more information about your hardware and software specifications.


Bump cosign to v2.0.0

What type of PR is this?
/kind cleanup
What this PR does / why we need it:
The script should now work with cosign 2, so we can update it.
Which issue(s) this PR fixes:

None
Does this PR have test?
None

Special notes for your reviewer:
None
Does this PR introduce a user-facing change?

None

/test pull-security-profiles-operator-test-e2e

@kubernetes-sigs/security-profiles-operator-maintainers PTAL


Appstudio update test-component-pac-dqzt

Pipelines as Code configuration proposal
To start the PipelineRun, add a new comment with content /ok-to-test
For more detailed information about running a PipelineRun, please refer to Pipelines as Code documentation Running the PipelineRun
To customize the proposed PipelineRuns after merge, please refer to Build Pipeline customization

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

StatusDurationName

✅ Succeeded
7 seconds
init

✅ Succeeded
19 seconds
clone-repository

✅ Succeeded
28 seconds
build-container

✅ Succeeded
17 seconds
inspect-image

✅ Succeeded
17 seconds
deprecated-base-image-check

✅ Succeeded
11 seconds
clair-scan

✅ Succeeded
34 seconds
clamav-scan

✅ Succeeded
8 seconds
sbom-json-check

✅ Succeeded
15 seconds
label-check

✅ Succeeded
6 seconds
show-sbom

✅ Succeeded
8 seconds
show-summary


[Question] 'Today' ValueObject? Is it possible? (Default Immutable values?)

Hello!
I would like to know if ValueObjects with a 'default' (pre-assigned) value type is possible.  Such as for example:
Ideally these can also be readonly / immutable types

// Would be nice to have option of struct or record
[ValueObject<int>]
public partial struct MinimumAge{}

var minAge = new MinimumAge();

// should pass
Assert.Equal(18, minAge)

Or perhaps an easier example:
[ValueObject<DateTime>]
public partial   record Today { }

var today = new Today();

// should pass
Assert.True(DateTime.Today, today)

I read the documentation, and tried some samples locally and could not figure out how to do the above ^^ actions.
Is it possible?

Hi @jeffward01 - currently, it's not possible. new and default are prohibited; the only way to create one is via the From method, or via a predefined 'instance:
[ValueObject]
[Instance("MinimumAge", 18)]
public partial struct Age { }

You can then use: Assert.Equal(Age.From(18), Age.MinimumAge). But that doesn't sound like what you want; what you want is a default value if you don't provide a value. But in Vogen, the biggest constraint it has is that it's very difficult for someone to not provide a value.

@SteveDunn Thanks for getting back to me -

it's very difficult for someone to not provide a value.

This is good to know, this was my second question.

For my first question - What I am also trying to ask (sorry for not mentioning it earlier) is implicit equality operators.
Something like this:

It might implement some interface (internally within Vogen) like this:
public interface IOperators<in TSelf, in TOther, out TResult>
where TSelf : IOperators<TSelf, TOther,TResult>

{
    static abstract TResult operator ==(TSelf self, TOther other);
    static abstract TResult operator ==(TOther self, TSelf other);
    static abstract TResult operator !=(TSelf  self, TOther other);
    static abstract TResult operator !=(TOther self, TSelf other);

}

The goal in my question is not really to protect against an empty value (but that is a very important thing to protect for). The goal is to compare an object such as DateOnly against a property like someCustomer.Birthday.
The customer can have a valueObject of Birthdate (this is simply a DateOnly value wrapped in a Vogen ValueObject.
   public class Customer
    {
        public string FullName { get; set; }

       // 'Birthdate' is a Vogen ValueObject using 'DateOnly'
        public Birthdate DateOfBirth { get; set; }

    }

Then I can compare the Birthdate Vogen ValueObject to DateOnly as an example like this:

        var someListOfCustomers = new List<Customer>();
        var today = DateOnly.FromDateTime(DateTime.Today);

        foreach (var someListOfCustomer in someListOfCustomers)
        {
            if (someListOfCustomer.DateOfBirth == today)
            {
                // Wish them a happy birthday
                // Process something....
            }
            else
            {
              // skip
            }
        }

is it possible to compare Vogen ValueObjects to their implemented underlying type? Such as int and Age where Age is a vogen value type?

is it possible to compare Vogen ValueObjects to their implemented underlying type? Such as int and Age where Age is a vogen value type?

Yes, Vogen will always generate the IEquable code to compare the Value of the ValueObject to the primitive type it wraps, enabling things such as:
            (Age.From(18) == 18).Should().BeTrue();
            (18 == Age.From(18)).Should().BeTrue();

It might implement some interface (internally within Vogen) like this:

There's nothing like that, but it does implement, as above, IEquatable, and adds Equals(ValueObject<DateOnly>) and Equals(DateOnly).
Also, if the underlying type is IComparable, then it generates the equivalent code to compare the Value of the Value Object to the primitive type that it wraps. Note that this only solves the problem of 'I need my Value Objects in a sortable collection'. It doesn't provide comparable operators < and >.

For my first question - What I am also trying to ask (sorry for not mentioning it earlier) is implicit equality operators.

It sounds like everything you need is available. But on the subject of implicit operators, some expect Value Objects to implement implicit cast operators. But these just cause confusion and weaken contracts. I documented that here: https://github.com/SteveDunn/Vogen/issues/14
Let me know if there's anything further I can help with to get what you want working.

Thanks for this! This helps a lot, I really appreciate your advice on this and the library! seriously some of the best in the C# community. really appreciate you. Thanks @SteveDunn


Define goal of a Standard Readme

This project readme sais:

Standard Readme is designed for open source libraries. Although it’s historically made for Node and npm projects, it also applies to libraries in other languages and package managers.

My goal, why i contribute here, is to have one ressource i can recommend to people that ask how to write great readmes. (right now i started an initiative to standardize the readmes of projects in my company)
I think a spec will not be that ressource, but it is a strong foundation to build on. I would compare it to the CommonMark spec, that probably most people who use Markdown on GitHub (that is actually not even CommonMark but GFM based on CommonMark) havn't read.
Some people might like a CLI generator programm, i would prefer an interactive website.
So i would like to define the goal wider, something like:

Provide a standardized readme template for open source projects.

It should be usable for most projects on github. For example:

desktop software with GUI, for example https://github.com/atom/atom
software with CLI, for example https://github.com/ansible/ansible
software libraries, for example https://github.com/requests/requests
websites, for example https://github.com/elementary/website
texts and documents, for example https://github.com/seriesseed/equity
datasets, for example https://github.com/zalandoresearch/fashion-mnist
fonts: https://github.com/theleagueof/league-spartan
3D objects, for example https://github.com/sparkfun/3D_Models

It can be questioned if following a spec makes a better readme. https://www.makeareadme.com/ for example sais "Every project is different, so consider which of these suggestions apply to yours.". A spec and badge may implies that you SHOULD follow it and might degrade people or project that don't. Maybe promoting a guide and TEMPLATE would be better to reach our goal and have the spec only in background like CommonMark?
We also need to define the audience of a readme. I think that will be users and (potential) contributors. (users of a library are probably developers, users of desktop GUI software might not)
So i invite you to state your personal goal, then we can see if it makes sense to collaborate (https://github.com/RichardLitt/standard-readme/issues/82) in a combined efforts.
@RichardLitt from https://github.com/RichardLitt/standard-readme/
@noffle from https://github.com/noffle/common-readme
@zcei from https://github.com/zcei/standard-readme
@dguo from https://www.makeareadme.com/
@PurpleBooth from https://gist.github.com/PurpleBooth/109311bb0361f32d87a2
@bevry from https://github.com/bevry/projectz
@davidbgk from https://github.com/davidbgk/open-source-template/blob/master/README.md
And everyone else who want to get involved.
(i choose this repo because it seems most complete)

A more concise definition of this project might be:

Standard Readme is an open source specification for how to structure READMEs for code modules.

This covers what I need; templating (follow the spec), and how to write a basic README. Your mileage will vary depending on your use case; this spec is meant for code packages, and generally not for things like websites, text-only repositories, and so on. I disagree that standard-readme "should be usable for most projects on github" - or, at least, that's not my goal here.
If you want a resource for how to write a better README, focusing on content instead of structure, I would look at @noffle's art of README. It's more eloquent.

The generator does that, @davidbgk: https://github.com/RichardLitt/generator-standard-readme. I've set up repo templates before, too, like this one for @orbitdb.

I disagree that standard-readme "should be usable for most projects on github" - or, at least, that's not my goal here.

great, that's exactly what i wanted to achieve with this issue. can you add the definition to the projects readme and the spec? you could than also remove "it’s historically made for Node and npm projects" from the spec and just have that information in the Background section of the readme. When you have stated the project goal clearly, you can close this issue.
Like i said, i want to work on a more general readme template for any kind of open source project, so i will mainly try to improve make-a-readme. Feel free to join the discussion there. Although i don't care following this spec, my further work heavily depend on it, so the work is greatly appreciated!

I like how it is at the moment. Thanks for your help.


put auto-merge at the bottom of the labels list

UI-wise, I like the idea of having the merge toggle in github. But I'm a bit concerned about accidentally merging because you clicked the wrong label. Definitely there needs to be a delay in merging (probably at least 20 seconds).

You could also accidentally hit the "green" merge button - it would be immediate as well.

That's not next to the "allocator" label button :wink:
Hm... a crude idea on that -- the labels seem listed alphabetically, you could make the label "ZZZ auto-merge" so they are always at the bottom.

or e.g. {automerge}
CC @schveiugy (from https://github.com/dlang/phobos/pull/4967)

Adding a label is already a 2-step process, select and confirm, so I don't think this is going to be a big issue.
But using some namesspace prefix such as pr: or z: would be fine.

Accidentally merging something wouldn't be such a huge issue either, just revert it right away.
Let's see if it's a practical problem.

Doesn't seem to be an issue for anyone -> closing.


Assessing affected data from annotation tool zoom/rotation bugs

Issues #107 (rotation) and #319 (zoom) are fixed, but the bugs were present for months, and many sources/images annotated on CoralNet during that span could have incorrect annotations as a result of the bugs.
Here are some possible actions to take:
1. Scan the database for possible affected sources/images
For the orientation issue, I believe we're looking for images that:

Had confirmed annotations added on 2020/03/24 or later, AND
Have a non-default EXIF orientation value

EXIF orientations take a while to scan for, since the image file has to be read from S3. If we were scanning ALL images in the database for this, it'd take roughly 10 days, based on a test run I did on up to 20 images per source. However, capping the annotation date to 2020/03/24 or later would hopefully narrow down the scan a fair bit.
That being said, I'm not sure how long it takes to scan for the annotation date (which generally has to be checked for all images). I'll have to try it out. We have a field for upload date, but for annotation date we'd have to dig through the annotation history entries of each image.
For the zoom problem, we'd just take the images that were annotated 2019/07/30 or later. That would actually be a superset of the images affected by the rotation problem, for what that's worth. Though the two problems are different in terms of affected browsers. Actually... now I want to confirm whether Safari had the zoom problem or not. I'd like to think the Chromium zoom thing was a bug, but it could have been an obscure design decision.
In any case: for the possibly affected images, we'd write a CSV containing the source ID, image ID, 'last annotated' date, EXIF orientation value (if 2020/03/24 or later), and image dimensions.
2. Publish a list of possible affected source and image IDs
We could attempt to go through the affected sources and images and double check their annotations ourselves. But the ecologists who annotated the images should know which browser they used and whether they were aware of the annotation tool bugs. Not to mention, they're familiar with their own labelset and reef region. So, it's probably best if we leave the double checking up to them.
One way to get them started is to publish a list (or lists) of possible affected source and image IDs, based on the criteria above. This is relatively simple on our end, but if there are hundreds of affected image IDs for a particular source, it's going to be quite tedious and error-prone for them to type in those images' URLs one by one and do the checks. So I guess we'll see how many affected images we have.
3. Add new filters on the Browse Images page: last confirmed annotation date, and/or EXIF orientation value
This would make it less tedious to browse through a large set of potentially-affected images. Instead of typing image IDs, source owners could use the 'last annotated' search filter - for example, searching for images which were last annotated 2019/07/30 or later.
This filter, along with a 'sort by last annotated' option, is likely to be generally useful anyway. It's been brought up in issue #46. The only thing is that last-annotated is likely to be a slow filter unless we add a 'last annotated' database field to track it. In which case, we have to add the field, and make sure the field is updated or nulled-out at the appropriate times. We'll also have to pre-populate the field with a data migration, perhaps prioritizing recent sources in the short term if it's a slow operation. Nothing too scary, but requires a reasonable effort to make sure it's implemented correctly and in a time-sensitive manner.
An EXIF orientation filter (and database field - again, too slow otherwise) could also help identify potentially-affected images, particularly for people who are sure they used Firefox or Safari. Additionally, we'd probably need this database field if we implement a source-level 'respect EXIF orientation' option (will make a separate issue on this). Otherwise, though, it seems like a less useful field compared to annotation date. Arguably, it's as nice to have as some of our other metadata fields like camera model and water quality. And it would be relatively easy to maintain - just set at image upload time, and we're done. Not sure if that's enough to justify the addition though.
4. Make it easier to double check existing annotations in the annotation tool
I believe we've had a few ideas and requests of this nature over the years (#194 is related). Maybe this is the time to implement a couple of simpler ideas, now that we are directly asking people to double check their annotations. Or not. I suppose we'll see where we are on time after the previous items are addressed to satisfaction.
Idea 1: Have a setting that colors annotated points by functional group (matching the label buttons' colors) instead of by annotation status. For example, purple hard coral, red other invertebrates, yellow algae. The 'unannotated' and 'selected' colors (already customizable) would still be there with their usual meanings, but annotated unselected points (whether 'confirmed' or not) would be colored by functional group. If an image has been fully annotated, then all the colors should only indicate functional groups.
Idea 2: Have a setting that writes label short codes (perhaps up to X characters, X being another setting) next to the points, instead of writing point numbers next to the points. So instead of "1" "2" "3", you'd see "CCA" "Turf" "Porit" next to the points. Or "CCA" "Tur" "Por" if limiting to 3 characters. If you use this in tandem with the above idea of coloring by functional group, it could become much easier to verify the annotations at a glance.

Hey. Sorry for brevity— on my phone.
An alternate route for 2&3 is:
Publish affected sources to the users.
Ask users to email us if they want to check their source.
If so: generate and share a google doc with links to each possibly affected
image, ordered by annotation date. The user can then click on the links,
one after one, and they will open in a browser tab where they can verify
them.
That way we don’t have to make a bespoke exif filter function that isn’t
really useful going forward.
We could also pre-generate such lists for each source in a g-doc and
pre-share With everyone (one source per tab). Should be secure but maybe
not best practice.
The other improvements in 3 and 4 are nice to have a bit not really needed
for this IMO.
On Sat, Jun 13, 2020 at 13:00 StephenChan<EMAIL_ADDRESS>wrote:

Issues #107 https://github.com/beijbom/coralnet/issues/107 (rotation)
and #319 https://github.com/beijbom/coralnet/issues/319 (zoom) are
fixed, but the bugs were present for months, and many sources/images
annotated on CoralNet during that span could have incorrect annotations as
a result of the bugs.
Here are some possible actions to take:

Scan the database for possible affected sources/images

For the orientation issue, I believe we're looking for images that:

Had confirmed annotations added on 2020/03/24 or later, AND
Have a non-default EXIF orientation value

EXIF orientations take a while to scan for, since the image file has to be
read from S3. If we were scanning ALL images in the database for this, it'd
take roughly 10 days, based on a test run I did on up to 20 images per
source. However, capping the annotation date to 2020/03/24 or later would
hopefully narrow down the scan a fair bit.
That being said, I'm not sure how long it takes to scan for the annotation
date (which generally has to be checked for all images). I'll have to try
it out. We have a field for upload date, but for annotation date we'd have
to dig through the annotation history entries of each image.
For the zoom problem, we'd just take the images that were annotated
2019/07/30 or later. That would actually be a superset of the images
affected by the rotation problem, for what that's worth. Though the two
problems are different in terms of affected browsers. Actually... now I
want to confirm whether Safari had the zoom problem or not. I'd like to
think the Chromium zoom thing was a bug, but it could have been an obscure
design decision.
In any case: for the possibly affected images, we'd write a CSV containing
the source ID, image ID, 'last annotated' date, EXIF orientation value (if
2020/03/24 or later), and image dimensions.
2. Publish a list of possible affected source and image IDs
We could attempt to go through the affected sources and images and double
check their annotations ourselves. But the ecologists who annotated the
images should know which browser they used and whether they were aware of
the annotation tool bugs. Not to mention, they're familiar with their own
labelset and reef region. So, it's probably best if we leave the double
checking up to them.
One way to get them started is to publish a list (or lists) of possible
affected source and image IDs, based on the criteria above. This is
relatively simple on our end, but if there are hundreds of affected image
IDs for a particular source, it's going to be quite tedious and error-prone
for them to type in those images' URLs one by one and do the checks. So I
guess we'll see how many affected images we have.
3. Add new filters on the Browse Images page: last confirmed annotation
date, and/or EXIF orientation value
This would make it less tedious to browse through a large set of
potentially-affected images. Instead of typing image IDs, source owners
could use the 'last annotated' search filter - for example, searching for
images which were last annotated 2019/07/30 or later.
This filter, along with a 'sort by last annotated' option, is likely to be
generally useful anyway. It's been brought up in issue #46
https://github.com/beijbom/coralnet/issues/46. The only thing is that
last-annotated is likely to be a slow filter unless we add a 'last
annotated' database field to track it. In which case, we have to add the
field, and make sure the field is updated or nulled-out at the appropriate
times. We'll also have to pre-populate the field with a data migration,
perhaps prioritizing recent sources in the short term if it's a slow
operation. Nothing too scary, but requires a reasonable effort to make sure
it's implemented correctly and in a time-sensitive manner.
An EXIF orientation filter (and database field - again, too slow
otherwise) could also help identify potentially-affected images,
particularly for people who are sure they used Firefox or Safari.
Additionally, we'd probably need this database field if we implement a
source-level 'respect EXIF orientation' option (will make a separate issue
on this). Otherwise, though, it seems like a less useful field compared to
annotation date. Arguably, it's as nice to have as some of our other
metadata fields like camera model and water quality. And it would be
relatively easy to maintain - just set at image upload time, and we're
done. Not sure if that's enough to justify the addition though.
4. Make it easier to double check existing annotations in the annotation
tool
I believe we've had a few ideas and requests of this nature over the years
(#194 https://github.com/beijbom/coralnet/issues/194 is related). Maybe
this is the time to implement a couple of simpler ideas, now that we are
directly asking people to double check their annotations. Or not. I suppose
we'll see where we are on time after the previous items are addressed to
satisfaction.
Idea 1: Have a setting that colors annotated points by functional group
(matching the label buttons' colors) instead of by annotation status. For
example, purple hard coral, red other invertebrates, yellow algae. The
'unannotated' and 'selected' colors (already customizable) would still be
there with their usual meanings, but annotated unselected points (whether
'confirmed' or not) would be colored by functional group. If an image has
been fully annotated, then all the colors should only indicate functional
groups.
Idea 2: Have a setting that writes label short codes (perhaps up to X
characters, X being another setting) next to the points, instead of writing
point numbers next to the points. So instead of "1" "2" "3", you'd see
"CCA" "Turf" "Porit" next to the points. Or "CCA" "Tur" "Por" if limiting
to 3 characters. If you use this in tandem with the above idea of coloring
by functional group, it could become much easier to verify the annotations
at a glance.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/beijbom/coralnet/issues/330, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAITTF4TTVAPGXRQ5GVAX3TRWPLFTANCNFSM4N5D4C4A
.

Yeah, that Google doc idea could help - though the tabs idea could be onerous if there are a lot of sources. I guess we'll see how much affected data there is first. I'm also leaning toward not adding an EXIF-orientation filter if possible.
Also, I just looked into this:

Actually... now I want to confirm whether Safari had the zoom problem or not. I'd like to think the Chromium zoom thing was a bug, but it could have been an obscure design decision.

I tested the zoom issue in the 'Epiphany' Web browser for Linux, which is the closest thing I can get to Safari without having a Mac (Epiphany and Safari run on the WebKit engine). Epiphany doesn't have the zoom issue with the pre-Chromium-fix version of the annotation tool. So, Safari probably didn't have the zoom issue either.

Results are in for the zoom issue. I made a list of images whose latest manual annotation (not imported, robot, or alleviate) happened between 2019/07/30 00:00 and 2020/06/12 06:00. Stats:

153470 images
339 sources
Top 10 image counts from sources: 15258, 12676, 4968, 4800, 4728, 4198, 4111, 3671, 3387, 3100
Sources with 500 or more images on the list: 64
Sources with 100 or more images on the list: 142
Sources with 20 or more images on the list: 260
33393 images from 2020/03/24 00:00 or later

So yes, a lot happens in a year. I checked 16 random images from the list, all from different sources and dates, to make sure that the annotations weren't just imported, alleviate, or robot.
For the zoom issue at least, I think the high image count and source count would make the list publishing or G-doc publishing methods too cumbersome. I would favor the annotation_date Browse filter idea instead.
I'll get to analyzing the rotation issue next.

Stephen,
Can you export a list of sources numbers that are affected. I want to see
if any of these are ones that QImin has been using for
training. We've been considering removing those from the training set, and
retraining the final networks.
David
On Tue, Jun 23, 2020 at 11:40 AM StephenChan<EMAIL_ADDRESS>wrote:

Results are in for the zoom issue. I made a list of images whose latest
manual annotation (not imported, robot, or alleviate) happened between
2019/07/30 00:00 and 2020/06/12 06:00. Stats:

153470 images
339 sources
Top 10 image counts from sources: 15258, 12676, 4968, 4800, 4728,
4198, 4111, 3671, 3387, 3100
Sources with 500 or more images on the list: 64
Sources with 100 or more images on the list: 142
Sources with 20 or more images on the list: 260
33393 images from 2020/03/24 00:00 or later

So yes, a lot happens in a year. I checked 16 random images from the list,
all from different sources and dates, to make sure that the annotations
weren't just imported, alleviate, or robot.
For the zoom issue at least, I think the high image count and source count
would make the list publishing or G-doc publishing methods too cumbersome.
I would favor the annotation_date Browse filter idea instead.
I'll get to analyzing the rotation issue next.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://urldefense.com/v3/__https://github.com/beijbom/coralnet/issues/330*issuecomment-648344538__;Iw!!Mih3wA!TGZZ8K5iiA9U6P0KRoWYGrslGZPzkqqWzey1SfUleoXKqSuaCnW9gMfO--fdkawH$,
or unsubscribe
https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABKA5AJ7IWUTPKCEEKJJ3WTRYDZLJANCNFSM4N5D4C4A__;!!Mih3wA!TGZZ8K5iiA9U6P0KRoWYGrslGZPzkqqWzey1SfUleoXKqSuaCnW9gMfO-wPcK1UM$
.

Sure, I'll email you the list of affected sources.

Results are in for the rotation issue. I scanned the 33393 images that got manual annotations between 2020/03/24 00:00 and 2020/06/12 06:00. Stats:

1562 images, across 19 sources, have EXIF orientation values other than 1.

789 have a value of 8 (rotated 90 degrees right).
534 have a value of 6 (rotated 90 degrees left).
239 have a value of 3 (rotated 180 degrees).

Image distribution across the 19 sources: 426, 311, 222, 176, 161, 63, 46, 33, 30, 26, 18, 17, 16, 8, 4, 2, 1, 1, 1.
Only 4 images are nearly square, and these 4 all belong to the same source. The remaining images have an aspect ratio of 1.328 or higher (or the equivalent for portrait orientation).
2020/03/24 00:00 refers to the date when Safari could have started exhibiting the bug. For Chromium, 2020/04/07, we have only 1196 potentially affected images instead of 1562. For Firefox, 2020/06/02, we have only 63 potentially affected images.

I think the list publishing or G-doc publishing ideas would be much more feasible for this rotation issue, compared to the zoom issue, due to the smaller numbers of sources/images.
When listing the potentially affected images, we should highlight the 180 degree rotation cases and the near-square cases separately from the rest, since these cases are much harder to notice by inspection. We should also note which ones were potentially affected in Firefox. This can help people narrow down what to check, if they are certain they used Firefox.

Sorry for the long delay in following up here. I guess this issue was pretty demoralizing to begin with, and then the fact that I was also answering many questions on the side (from various people) made it harder to concentrate and ended up burning me out. I'm not even looking at this issue this week, but I'll give it another go next week. The first thing I'll do is post more details about the annotation-date Browse filter idea.

Thanks for the update. That was discouraging, but mistakes happen. I think
the actual data impact may be fairly low.
Qimin and removed all suspect images/sources from the training data and
basically got the same results as before.
David
On Thu, Jul 23, 2020 at 12:30 PM StephenChan<EMAIL_ADDRESS>wrote:

Sorry for the long delay in following up here. I guess this issue was
pretty demoralizing to begin with, and then the fact that I was also
answering many questions on the side (from various people) made it harder
to concentrate and ended up burning me out. I'm not even looking at this
issue this week, but I'll give it another go next week. The first thing
I'll do is post more details about the annotation-date Browse filter idea.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://urldefense.com/v3/__https://github.com/beijbom/coralnet/issues/330*issuecomment-663191525__;Iw!!Mih3wA!XpvEhtbVH5_R-xfTEwioHcn8JMIfp3DFeKwI3oJ_-9Nf72XsNTF8eJBPjtq4oW6R$,
or unsubscribe
https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABKA5AJZ4HXHZQS4O7CBD7TR5CFV7ANCNFSM4N5D4C4A__;!!Mih3wA!XpvEhtbVH5_R-xfTEwioHcn8JMIfp3DFeKwI3oJ_-9Nf72XsNTF8eJBPjr9TBdFe$
.

That's good to hear at least.

All right, here we go. For the proposed image-level 'annotation date' feature, I was thinking about what the exact semantics of this feature should be, so that it:

Could be used to find images affected by the zoom issue
Also can be used for other bookkeeping purposes
Isn't too complex or confusing

My idea now is that we shouldn't add a date field, but rather a foreign key field pointing to the image's latest-updated annotation.
Say we call the field last_annotation. Then last_annotation.annotation_date gives us the date of the latest-updated annotation in the image, or null if the image has no annotations. And last_annotation.user can tell us if the latest annotation was done by a robot, Alleviate, importing, or by a user on the annotation tool.
Database implementation
This last_annotation field would be updated whenever an annotation from the image is updated. It would be set to null if all of the image's annotations are deleted. So the update semantics, at least, would be fairly simple.
To implement the updating, we could probably use an Annotation post-save signal, similar to what django-reversion uses.
For deleting, there are a few cases where we delete annotations:

Updating unconfirmed annotations with the latest classifier.

Regenerating points on an image with unconfirmed annotations.

Importing new points/annotations.

Using the 'Delete annotations' button on the Image Detail page.

In each case, we delete ALL of the image's annotations at once (which means we set last annotation to null), followed by possibly adding new annotations in their place. We could maybe use Annotation post-delete signals here, as long as we don't use batch-delete operations which skip the signals.
A good test for search-query performance would be any source with a lot of annotations, such as source 372.
Finding images affected by the zoom issue
Using the field described above, to find images affected by the zoom issue, we'd search for images where:

last_annotation.annotation_date is between 2019/07/30 and 2020/06/12, and
last_annotation.user is a registered user (indicating an annotation tool save).

The idea behind the user condition is that, if ANY annotations were made by a user in the annotation tool, they almost always come AFTER other types of annotations:

When points/annotations are imported, all previous points/annotations for that image are deleted. So it's not possible to have any other type of annotations before imported ones.

Generally, if Alleviate was involved at all, Alleviate would have either come before any annotation tool work, or Alleviate would have annotated all the points. The only possible exception would be the following odd case: enter the annotation tool with a high Alleviate threshold, make some annotations, set a lower Alleviate threshold, and then re-enter the annotation tool so that Alleviate completes the annotations.

When robot annotations are updated, that means the points were not confirmed to begin with. The only way to have robot annotations updated later than confirmed annotations is to confirm a subset of the points, then let another round of robot training and classification happen. This is of course possible, but not common since users typically annotate all of an image's points in one go.

It would be more precise if you could look up images that had any annotation-tool activity saved from 2019/07/30 to 2020/06/12. Not just any annotation activity. In terms of an alternative implementation, that could either mean:

Saving a 'last annotation' field for each possible annotation method: annotation tool, Alleviate, importing, classifier. But this might be too much additional complexity.

Making it a 'last annotation by annotation tool' field instead, ignoring Alleviate, importing, and classifier activity. But this might be a little too bespoke to this use case.

Workflow for checking images affected by the zoom issue

(2): If the source owner has more info such as who used which browser when annotating, then they could limit the search to a specific annotation-tool user. Of course, if they also think only a specific set of images was affected (or they only care about a specific set), they can use the image metadata filters too.

(2): The first dropdown would have choices of Annotation Tool, Alleviate, Importing, and Classifier (Unconfirmed). The second dropdown would only appear if the first choice was Annotation Tool.

(3) Sort direction shouldn't matter as long as they're keeping track of progress accordingly.

(7) If you end up correcting some annotations, the image you're on will no longer belong to the search set, since annotations will have been updated later than 2020/06/12. This won't affect your ability to proceed with the Prev/Next links, though. The numbers will just look a bit weird. For example, clicking Next could take you from '3 of 20' to '3 of 19'.

(8) For example, if you are going in ascending-date order and the current image's annotation date is 2019/11/01, then next time you can do your step (1) search from 2019/11/01 to 2020/06/12 to continue where you left off.

Other uses of the proposed search options
To be clear, in the Search box, the rows starting with 'Last annotated' and 'Sort by' are new. Everything above that is not new.

You can view recent annotation activity in your source by sorting images by annotation date, descending (most recent first). You can further filter it to a particular kind of activity: annotation tool usage, Alleviate, importing, or the automated classifier (unconfirmed annotations).

Filtering to classifier activity can give you a slightly better idea of how fast the classifier is adding label suggestions to images, compared to just looking at the unconfirmed-image count.

If each image is generally handled by a single annotator, then the 'last annotated by' filter lets you count how many images were done by a particular annotator. Or, sorting by annotation date, you can see recent activity by that particular annotator.

The already-existing 'annotator' filter in Browse Patches also lets you count a particular annotator's work, except that you get a count of annotations instead of images.

UI concerns
Browse page

Are there enough use cases to justify the added space in the search box?

Should part of the search box be hidden by default and expandable, under text like 'More filters'?

Perhaps the sort method should be more visually separated from the filters? Or is the horizontal rule good enough.

Annotation tool

Maybe not the highest priority, but ideally, the text that shows the currently applied filters would show not only the active filter fields, but also those fields' values. For example, not just "last annotated" but "last annotated = 2019-07-30 to 2020-06-12". Clearly though, that would mean we'd be running out of room in that small horizontal space.

I think it makes sense to keep this filter display close to the Prev/Next buttons, so I'm not sure about moving this display further down the page.

We could maybe truncate the filter display and provide a "See all" button, which pops up a modal dialog with the rest of the filters.

Thanks for looking at this @StephenChan . I stand by my previous position in that we need to de-scope this detour. Yes, we made a mistake, and yes, it is possible that some data is corrupt, but frankly, I highly doubt that any user would go back and inspect 1000's or 10000's of images regardless of how easy we do it for them. So I suggest we look forwards instead and move on to other things on the laundry list.
Per my original post, I suggest we announce the mistake and publish the list of sources. If people want to check their sources they can filter on current meta-data fields or we can send them a text file with URL links to images that are in the relevant date-ranges. My guess is that few, if any, users will get back to use with a request to double-check their images.
End of the day this is a free service run by a shoe-string team and I just don't think this is the best use of our time.

Stephen,
You put a lot of thought in this.
How much effort would go into the implementation of this? Is there a
minimal implementation?
I differ from Oscar's opinion if it's not a lot of work. Producing files
with list of sources, sending them, and fielding questions may be more work
than implementing the filters. Most of this seems like describing a
workflow, rather than  an actual implementation, but I didn't follow all
the details.
One comment -- if "last_annotation.annotation_date" looks a new database
entry.  Isn't this something that can be
computed on the fly as a database query? If so, wouldn't it be better to
compute it on the fly rather than having
to maintain  and constantly update it.  I defer to your opinion  since you
know the codebase/schemas. Just trying to keep it simple and reduce
technical debt
unless it's useful elsewhere or speeds up queries elsewhere.
David
On Fri, Jul 31, 2020 at 10:03 PM Oscar Beijbom<EMAIL_ADDRESS>wrote:

Thanks for looking at this @StephenChan
https://urldefense.com/v3/__https://github.com/StephenChan__;!!Mih3wA!QbcoTFEg-pK57IicPch5kldZpjeo_YkKba2wcmtUeeXLIKCD_kDVTBHNJPtkHdqS$
. I stand by my previous position in that we need to de-scope this detour.
Yes, we made a mistake, and yes, it is possible that some data is corrupt,
but frankly, I highly doubt that any user would go back and inspect 1000's
or 10000's of images regardless of how easy we do it for them. So I suggest
we look forwards instead and move on to other things on the laundry list.
Per my original post, I suggest we announce the mistake and publish the
list of sources. If people want to check their sources they can filter on
current meta-data fields or we can send them a text file with URL links to
images that are in the relevant date-ranges. My guess is that few, if any,
users will get back to use with a request to double-check their images.
End of the day this is a free service run by a shoe-string team and I just
don't think this is the best use of our time.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://urldefense.com/v3/__https://github.com/beijbom/coralnet/issues/330*issuecomment-667470708__;Iw!!Mih3wA!QbcoTFEg-pK57IicPch5kldZpjeo_YkKba2wcmtUeeXLIKCD_kDVTBHNJMCBlxar$,
or unsubscribe
https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABKA5AKKVK6MDWDCNSRUA2TR6OOYTANCNFSM4N5D4C4A__;!!Mih3wA!QbcoTFEg-pK57IicPch5kldZpjeo_YkKba2wcmtUeeXLIKCD_kDVTBHNJE5GdT1O$
.

(Sorry for the delay again. I think I'm back for real now.)
I should mention that we had a meeting in July (which didn't fit in your schedule, Oscar) where David and I ended up discussing at length about the potential user workflow for inspecting affected images.
So my previous post did mostly focus on the workflow, and on designing features which are not too bespoke to the zoom issue.
To hopefully be more clear, here's the scope of the potential UI changes:

Two extra lines of fields in the Browse Search box:

'Last annotated' line.

'Sort by' line. We already wanted this in issue #46.

Additional 'Last annotated' detail line at the bottom of the annotation tool.

And here's the implementation burden:

Add the filters and sort method to the Browse Search UI. (This is mostly done actually. Sorry, I kind of cheated - I felt more like coding than drawing mockups.)

Actually apply the filters and sort method to the search results. (Already did a little code cleanup in preparation for this.)

Add a last_annotation database field, saved per Image. Populate the field initially with a data migration. Keep it updated with a post-save signal and a post-delete signal, maybe 5-10 lines each.

[David:] One comment -- if "last_annotation.annotation_date" looks a new database entry. Isn't this something that can be computed on the fly as a database query? If so, wouldn't it be better to compute it on the fly rather than having to maintain and constantly update it. I defer to your opinion since you know the codebase/schemas. Just trying to keep it simple and reduce technical debt unless it's useful elsewhere or speeds up queries elsewhere.

Yes, it would be a new database field that would be redundant with existing database info, but necessary for speeding up the filters.
I tried some ways of computing the date on the fly and filtering images that way, but the queries always took multiple minutes on large sources. Which certainly isn't ideal for the image search function, since you'd be waiting multiple minutes every time you click next page on Browse, or next/previous image in the annotation tool.

[Oscar:] Yes, we made a mistake, and yes, it is possible that some data is corrupt, but frankly, I highly doubt that any user would go back and inspect 1000's or 10000's of images regardless of how easy we do it for them.

Well, at that scale, I also highly doubt that to be honest. But checking a subset of images would be pretty reasonable, perhaps a dozen from each site/habitat, from each annotator, or something like that - as long as the affected images are searchable that way. If they don't spot serious problems after that, chances are they're in the clear, even if they annotated 5000 images in this time period. If they spot some bad annotations, and they're uneasy about that, then they can check more.
Part of the idea here is just that source owners can get a good overview of which data was potentially affected, and hopefully narrow down the search to a small set of suspect images. That's not so easy to do with a flat list of 1000 image IDs.

[Oscar:] I suggest we announce the mistake and publish the list of sources. If people want to check their sources they can filter on current meta-data fields or we can send them a text file with URL links to images that are in the relevant date-ranges. My guess is that few, if any, users will get back to use with a request to double-check their images.

[David:] Producing files with list of sources, sending them, and fielding questions may be more work than implementing the filters.

Okay, to be honest here, I don't think I gave this route enough thought before:

Yes, we could ask people to contact us if they wanted to see their affected images, and I could use a Python function with a source ID as input, and perhaps an HTML file of affected-image links as output. As long as we don't get too many follow-up questions, I could see myself handling request emails quickly like this.

The current metadata fields, despite not having anything about annotation date, would probably be sufficient for many source owners. I imagine many research groups have some kind of records or recollections about which sets of images were annotated when. Annotators spend a lot of time staring at these images, after all. Thus, chances are the amount of requests would indeed be smaller than we think.

If I'd realized all that a month ago, then the effort saved could very well have outweighed the inconvenience to source owners for the time being. And maybe I'd be finishing up the vision backend tests by now.
But to also be honest, the hard part is already done with the proposed extra filters. We have a DB design, UI design, workflow, and even UI implementation. The remainder of the coding doesn't require much motivation for me to finish up.
However, even if we don't add the extra filters, much of what I've done was cleanup and generalization of some old filters' UI implementation, so much of the work so far could be useful to keep either way.
By the way, the "Other uses of the proposed search options" in my previous post haven't been addressed yet. I know those uses aren't a high priority right now, but it's worthwhile to assess whether the filters are too bespoke to the zoom issue. What do you think on that front?

It sounds like you're pretty far along the implementation. And you answered
my question about computing it on the fly.
The new filtering options seem useful to me since it will give more
flexibility and oversite, especially for power users/larger institutions
with multiple annotators.
The "sort by" is something that was on my list of things to add, and I
think I had mentioned it.
So, worthwhile features.
Being so far along, it does seem like you should take it to the finish
line. And for the long term, we've got some new features.
David
On Wed, Aug 5, 2020 at 2:17 PM StephenChan<EMAIL_ADDRESS>wrote:

(Sorry for the delay again. I think I'm back for real now.)
I should mention that we had a meeting in July (which didn't fit in your
schedule, Oscar) where David and I ended up discussing at length about the
potential user workflow for inspecting affected images.
So my previous post did mostly focus on the workflow, and on designing
features which are not too bespoke to the zoom issue.
To hopefully be more clear, here's the scope of the potential UI changes:

Two extra lines of fields in the Browse Search box:
  'Last annotated' line.
  -

  'Sort by' line. We already wanted this in issue #46
  <https://urldefense.com/v3/__https://github.com/beijbom/coralnet/issues/46__;!!Mih3wA!Tx0nzQjmI3iAB4zt8LMFUiVlZsGSrzdJIEpwVTeGcnpihjt4ytKKqQujV09conbq$>
  .
  -

Additional 'Last annotated' detail line at the bottom of the
annotation tool.
And here's the implementation burden:

Add the filters and sort method to the Browse Search UI. (This is
mostly done actually. Sorry, I kind of cheated - I felt more like coding
than drawing mockups.)
Actually apply the filters and sort method to the search results.
(Already did a little code cleanup in preparation for this.)
Add a last_annotation database field, saved per Image. Populate the
field initially with a data migration. Keep it updated with a post-save
signal and a post-delete signal, maybe 5-10 lines each.
[David:] One comment -- if "last_annotation.annotation_date" looks a new
database entry. Isn't this something that can be computed on the fly as a
database query? If so, wouldn't it be better to compute it on the fly
rather than having to maintain and constantly update it. I defer to your
opinion since you know the codebase/schemas. Just trying to keep it simple
and reduce technical debt unless it's useful elsewhere or speeds up queries
elsewhere.
Yes, it would be a new database field that would be redundant with
existing database info, but necessary for speeding up the filters.
I tried some ways of computing the date on the fly and filtering images
that way, but the queries always took multiple minutes on large sources.
Which certainly isn't ideal for the image search function, since you'd be
waiting multiple minutes every time you click next page on Browse, or
next/previous image in the annotation tool.
[Oscar:] Yes, we made a mistake, and yes, it is possible that some data is
corrupt, but frankly, I highly doubt that any user would go back and
inspect 1000's or 10000's of images regardless of how easy we do it for
them.
Well, at that scale, I also highly doubt that to be honest. But checking a
subset of images would be pretty reasonable, perhaps a dozen from each
site/habitat, from each annotator, or something like that - as long as the
affected images are searchable that way. If they don't spot serious
problems after that, chances are they're in the clear, even if they
annotated 5000 images in this time period. If they spot some bad
annotations, and they're uneasy about that, then they can check more.
Part of the idea here is just that source owners can get a good overview
of which data was potentially affected, and hopefully narrow down the
search to a small set of suspect images. That's not so easy to do with a
flat list of 1000 image IDs.
[Oscar:] I suggest we announce the mistake and publish the list of
sources. If people want to check their sources they can filter on current
meta-data fields or we can send them a text file with URL links to images
that are in the relevant date-ranges. My guess is that few, if any, users
will get back to use with a request to double-check their images.
[David:] Producing files with list of sources, sending them, and fielding
questions may be more work than implementing the filters.
Okay, to be honest here, I don't think I gave this route enough thought
before:

Yes, we could ask people to contact us if they wanted to see their
affected images, and I could use a Python function with a source ID as
input, and perhaps an HTML file of affected-image links as output. As long
as we don't get too many follow-up questions, I could see myself handling
request emails quickly like this.
The current metadata fields, despite not having anything about
annotation date, would probably be sufficient for many source owners. I
imagine many research groups have some kind of records or recollections
about which sets of images were annotated when. Annotators spend a lot of
time staring at these images, after all. Thus, chances are the amount of
requests would indeed be smaller than we think.
If I'd realized all that a month ago, then the effort saved could very
well have outweighed the inconvenience to source owners for the time being.
And maybe I'd be finishing up the vision backend tests by now.
But to also be honest, the hard part is already done with the proposed
extra filters. We have a DB design, UI design, workflow, and even UI
implementation. The remainder of the coding doesn't require much motivation
for me to finish up.
However, even if we don't add the extra filters, much of what I've done
was cleanup and generalization of some old filters' UI implementation, so
much of the work so far could be useful to keep either way.
By the way, the "Other uses of the proposed search options" in my previous
post haven't been addressed yet. I know those uses aren't a high priority
right now, but it's worthwhile to assess whether the filters are too
bespoke to the zoom issue. What do you think on that front?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://urldefense.com/v3/__https://github.com/beijbom/coralnet/issues/330*issuecomment-669515551__;Iw!!Mih3wA!Tx0nzQjmI3iAB4zt8LMFUiVlZsGSrzdJIEpwVTeGcnpihjt4ytKKqQujV1jcD4AW$,
or unsubscribe
https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABKA5AMXERRQZPQENGLSJ73R7HD6JANCNFSM4N5D4C4A__;!!Mih3wA!Tx0nzQjmI3iAB4zt8LMFUiVlZsGSrzdJIEpwVTeGcnpihjt4ytKKqQujV4mTyZm9$
.

Thanks @StephenChan . Ok, sounds like you are mostly all the way there, so let's go for it :)

Sounds good. I'll continue along this path then.
Also: I've mainly been considering the zoom issue. For the rotation issue, it may still be worthwhile to offer list(s) of the 239 images that were rotated 180 degrees, and the 4 images that were nearly square. The reason is that anyone using Safari or Firefox would only have to worry about the rotation issue, not the zoom one.

This is finally done: https://coralnet.ucsd.edu/blog/annotation-tool-bug-fixes-follow-up-checking-potentially-affected-images/


Add integration with JVM Test Suite Gradle plugin

Is your feature request related to a problem? Please describe.
I would like to the contractTest source set and tasks be registered as test suite as per The JVM Test Suite Plugin
. Unfortunately, I cannot achieve that:
// build.gradle.kts
testing {
    suites {
        val contractTest by registering(JvmTestSuite::class) {
            useJUnitJupiter()
        }
    }
}

Could not create domain object 'contractTest' (JvmTestSuite)
> Could not create an instance of type org.gradle.api.plugins.jvm.internal.DefaultJvmTestSuite.
   > Cannot add a SourceSet with name 'contractTest' as a SourceSet with that name already exists.

by getting(JvmTestSuite::class) doesn't work as well since contractTest isn't registered as test suite:
TestSuite with name 'contractTest' not found.

Describe the solution you'd like
I would like Spring Cloud Contract Gradle plugin to integrate with JVM Test Suite plugin and register its contractTest source set, task etc. using JVM Test Suite plugin, for contractTest JVM test suite to be registered.

@marcingrzejszczak, this should be pretty doable. I'll see if I can't get around to it later this week.


remove the try statement in the cluster() factory method

remove try

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

Current dependencies on/for this PR:

main

PR #377

PR #380   👈

This stack of pull requests is managed by Graphite.


inconsistent field names

I have a field in my content model with id = "otherNames".
I am retrieving an entry and when I try to update this field by doing this:
setattr(entry, 'otherNames', newVal)
entry.save()
all seems to be OK, but no update happens.
When I debug the code, I see that the entry I received via the api has the field in the fields list under the en-US locale the name "other_names".
If I use setattr(entry, 'other_names', newVal), it will then work, but not if the entry had no value before the update. In that case I will get an exception that the fields is missing.
What's the right way?

Hey @iroth,
Which version of the SDK are you using?
The latest version (1.3.1) - Fixes an issue when fields with camel cased IDs that weren't present on the original entry (due to the field being manually voided or never filled) are added to the entry.
If you're on a previous version, I'd recommend you to upgrade and try again.
As for what's the proper way to update the fields:
entry = client.entries('space_id').find('entry_id')
entry.my_field = 'my value'
entry.save()

All the setters are the snake cased version of the field ID, the SDK converts it afterwards to the proper ID. If you want to look more into how this is done, the code responsible for that can be found here: https://github.com/contentful/contentful-management.py/blob/master/contentful_management/resource.py#L252RL255 and https://github.com/contentful/contentful-management.py/blob/master/contentful_management/entry.py#L89RL93
Hope that helps,
Cheers

Hi @dlitvakb - I think there is something wrong in the snake casing logic. When I look at the GUI, the id is definitely not camel cased. It appears as "otherNames".
I am using 1.3.1 which seems to improved the situation when updating entries that did not have fields populated before, but there is some issue with those double word names. I ended up creating a new field and just naming it with single word to bypass the issue

Hey @iroth,
The logic in the SDK is there in order to simplify mapping to "pythonic" properties. As camelCase is not something you often see in Python.
As of 1.3.1, updates on entries should not be an issue when dealing with any ID.
Next release will also include a fix for Content Type updates with camelCased IDs.
Cheers

This has already been fixed with the release of 1.3.2.
Cheers


3D inversion unit test

Steef, do you have inversion.pdf to hand to send to Matthias?
Sent from my iPad
On 16 Nov 2021, at 10:58, matt-frey @.***> wrote:

@matt-frey commented on this pull request.

In unit-tests/3d/test_vor2vel.f90https://github.com/matt-frey/epic/pull/247#discussion_r750421808:

                              , p1 = 0.2d0 * lz         &

                              , p2 = 0.7d0 * lz         &

                              , p3 = lz                 &

                              , q1 = 0.3d0 * lz         &

                              , q2 = 0.8d0 * lz         &

                              , q3 = lz

double precision, allocatable :: svelog(:, :, :, :), svelog_ref(:, :, :, :)
integer                       :: ix, iy, iz
double precision              :: Ahat, Bhat, xi, eta, zeta, pp, qq, ps, qs
double precision              :: z, z2, z3, dz, gam, C, zq1, zq2, zq3, zp1, zp2, zp3
double precision              :: us, vs, ws, ppp, qqq

nx = 32
ny = 32
nz = 32
lower  = (/zero, zero, zero/)

I didn't see in you notes.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/matt-frey/epic/pull/247#discussion_r750421808, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANLYB5VW5DLZEQXPZ5NVO33UMJ5R7ANCNFSM5IB75JBQ.
Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
[ { @.": "http://schema.org", @.": "EmailMessage", "potentialAction": { @.": "ViewAction", "target": "https://github.com/matt-frey/epic/pull/247#discussion_r750421808", "url": "https://github.com/matt-frey/epic/pull/247#discussion_r750421808", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { @.": "Organization", "name": "GitHub", "url": "https://github.com" } } ]


h264e: change ICQ quality factor range to [1, 51].

Change the ICQ quality factor range to [1, 51]
which aligns with the definition in VAAPI.
Change-Id: I582753964de57d0b479c1eebee42b05700f516d1

pr #866 will take care of the enabling icq in sample_encode...

The purpose of this change is to enable ICQ for AVC in sample_encode. I have removed the codes for ICQ support for Lowpower mode. @dvrogozh

Just see you submit the same PR. @dvrogozh

If MSDK still checks the value in the range of [0, 51], and doesn't have process for 0, then 0 can be transferred to media driver. At present, the valid range for ICQ quality factor in media driver is [1, 51], if 0 is set, then media driver will report error. Currently, I haven't seen there is process for 0. If I missed this process, please correct me. Thanks! @dvrogozh

0 - is default value for ICQQuality
MediaSDK sets ICQQuality to 26 in this case in SetDefaults function.

0 - is default value for ICQQuality
MediaSDK sets ICQQuality to 26 in this case in SetDefaults function.
Could you show me the code where set it to be 26?

0 - is default value for ICQQuality
MediaSDK sets ICQQuality to 26 in this case in SetDefaults function.

So I prefer iHD driver can take 0 as 26 too.  And application can have same setting for ICQ and ICQ_LA

mfx_h264_enc_common_hw.cpp: 5395
if (par.mfx.RateControlMethod == MFX_RATECONTROL_ICQ || par.mfx.RateControlMethod == MFX_RATECONTROL_LA_ICQ)
{
if (par.mfx.ICQQuality == 0)
par.mfx.ICQQuality = 26;
}

Since there is separate processing for "ICQQuality==0", cancel this PR.


Update wasmedge-go docs to 0.13.0.

Hello, I am a code review bot on flows.network.
It could take a few minutes for me to analyze this PR. Relax, grab a cup of coffee and check back later. Thanks!


Cannot disable whitespace highlighting when using vim-better-whitespace

Describe the bug
I'm using vim-better-whitespace to highlight trailing whitespaces in a buffer.
When I open lspsaga's finder, whitespaces are highlighted, and I don't seem to be able to disable them:

vim-better-whitespace allows "black listing" some filetypes using g:better_whitespace_filetypes_blacklist, which I am using and it works for other filetypes.
I tried adding lspsagafinder to the blacklist, but it's not working, and whitespaces are still highlighted
Also, if I manually disable the whitespace plugin by doing :DisableWhitespace, the highlights are gone
Steps to reproduce
Sorry, since a minimal config requires enabling LSP and everything, Please let me know if that's necessary, and I can try to create one.
Expected behavior
I expect the whitespaces to not be highlited similar to the other filetypes I have blacklisted
Neovim version (nvim -v)
0.8.3
lspsaga commit
4623173
Terminal name/version
WezTerm

read that plugin doc add lspfinder filetype into list

Thank you @echasnovski for your comment here, just to add a bit of context, originally I was having issues with vim-better-whitespace (as mentioned in the issue), but then I thought maybe it's not compatible with how the newer Lua plugins do things, so I'm trying mini.trailspace now

maybe set a buftype name instead of filetype

maybe set a buftype name instead of filetype

Not sure what you mean.
The way it works (at least in 'mini.trailspace') is through doing some bookkeeping inside appropriate autocommand. The usual way of doing this is for FileType event. How do you propose to change that?
As far as I can tell, the buffer for 'lspsagafinder' is created an managed before it is shown in target window. So, there seems to be no way of knowing in which window it will be shown, but this information is needed to disable highlighting (as it is done per window).


Unable to override custom-variables

Hi, I'm new to jekyll and the themes. I'm using v2.5.1 of minima and I created custom-variables.scss in my site's _sass/minima/ directory and none of the overrides are getting picked up. Am I missing something?

@mcpwns I believe those instructions are for the latest git version of minima and were not implemented yet in v2.5.1.
Check the doc for v2.5.1.


Fix Vanity url comments

link to demo deployment of your smk based app is
https://smk-fap-fcb-rt-b16795-dev.apps.silver.devops.gov.bc.ca
Verify that it looks good, if so merge the pull request which will trigger a prod deployment, otherwise close the pull request without merging
mentions / notifications: @GuyTheFlower, @NicoledeGreef, @franTarkenton

The Vanity URL for the Dev deploy is: https://smk-fap-fcb-api-gov-bc-ca.test.apsgw.xyz,
@GuyTheFlower, @NicoledeGreef, @franTarkenton

The Vanity URL for the Dev deploy is: https://smk-fap-fcb-api-gov-bc-ca.test.apsgw.xyz,
@GuyTheFlower, @NicoledeGreef, @franTarkenton


Access token invalid when we have JWT and Oauth2 plugins within an API

Summary
Well, I have just got a problem when I have an API and installed 2 plugins into it which are JWT and Oauth2 plugins. Then, when I try to access API using JWT credential I got an error message like this.
{"error_description":"The access token is invalid or has expired","error":"invalid_token"}
But when I remove the Oauth2 plugin from my API, everything works well.
Steps To Reproduce

Add an API
Install JWT plugin
Install Oauth2 plugin
Access API via localhost:8000/{api} -H 'Authorization: Bearer {jwt-token}', and I got this error message
{"error_description":"The access token is invalid or has expired","error":"invalid_token"}

Additional Details & Logs

Kong version 0.9.1

Note: Previously, I used Kong Version 0.8.3 and got no issue

Access API via localhost:8000/{api} -H 'Authorization: Bearer {jwt-token}', and I got this error message {"error_description":"The access token is invalid or has expired","error":"invalid_token"}

Are you passing the access token too?

@thefosk nope. I pass in only the token generated from JWT secret and key to the API

@stephennyu if you also have OAuth 2.0 installed on the API, the plugin should also expect an access token in the request. What kind of use-case are you trying to implement?

I'm implementing a use case in which an API can be accessed through several methods such as JWT and Oauth2. I will use JWT for the internal app access such as front end or mobile app and Oauth2 for the third party / partner apps.
Note that I got no problem when I was using Kong version 0.8.3. This problem arises only when I have upgraded it into version 0.9.1

@stephennyu as far as I know multiple authentications are not supported, so may very well be a bug that has been fixed in 0.9.x (related to #590) - I would expect the OAuth 2.0 plugin to always validate an access token and make sure it's being sent.
Just to double-check, can you also append a valid access token to the request and see if it works?

@thefosk tested and yes we should append an access token.I think I have been pretty clear with how it works here.
Thanks

@stephennyu i am facing the same issue now. Can you please let me know how you appended access_token with JWT token

@SyedSulaimanM you can't do so. You need to have another API to handle that.


GitHub io dev

LGTM. Next PRs will include

how the schema md's are presented
and remove the files specific to common services.

Precisely! I will remove as much of the redundant CS files as possible in the subsequent PRs


Yifany work

Codecov Report

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

@@             Coverage Diff              @@
##             master       #6      +/-   ##
============================================
- Coverage     66.09%   65.85%   -0.24%
+ Complexity      593       10     -583
============================================
  Files           108      113       +5
  Lines          3241     3309      +68
  Branches        336      340       +4
============================================
+ Hits           2142     2179      +37
- Misses         1006     1034      +28
- Partials         93       96       +3

Impacted Files
Coverage Δ
Complexity Δ

...gle/firebase/errorprone/ComponentsAppGetCheck.java
87.87% <0%> (ø)
6% <0%> (?)

...n/java/com/google/android/datatransport/Event.java
0% <0%> (ø)
0% <0%> (?)

...rorprone/NoStaticOrDefaultMethodsInInterfaces.java
80% <0%> (ø)
4% <0%> (?)

...ava/com/google/android/datatransport/Encoding.java
0% <0%> (ø)
0% <0%> (?)

...ava/com/google/android/datatransport/Priority.java
0% <0%> (ø)
0% <0%> (?)

Continue to review full report at Codecov.

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


Ui locale selection

This allows to change the locale for users.
Locales are readed by the name of the files in publishable/lang
The locale is stored in a settings column (cast to array) for future usage as suggested by @marktopper

I know this has already been merged. But if a user does not have this setting, the admin will throw an error upon login.