ProductId guidance is incorrect, should be the StoreId

This API (and perhaps the other Xbox One analytics APIs for XDP-published titles?) appears to require the StoreID, not the XDP product id.

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

ID: 5f41781d-fe03-611f-689a-f39f18299bb4
Version Independent ID: bc2cdfdc-bdaf-f302-7ea5-a9e0d97aa494
Content: Get error reporting data for your Xbox One game - UWP app developer
Content Source: windows-apps-src/monetize/get-error-reporting-data-for-your-xbox-one-game.md
Product: uwp
GitHub Login: @Xansky
Microsoft Alias: mhopkins

Hi billyrayxbox,
The page says the API takes the applicationId, which it describes as the "product ID." Are you suggesting that this description should be changed to say "store ID?"
~ Mark

I see it now, I'll make this update. Thanks!

Hi billyrayxbox,
I checked with the engineering team and they told me that product ID is the correct term because it applies universally.
Thanks,
~ Mark

Hi,
Couple of problems here:

The other analytics API docs use the term Store ID when referring to the applicationId parameter.
ProductId is familiar to our Xbox partners as a big guid style Id they see in XDP.
The documentation for applicationId tells the partner to go and get it from XDP.  This is incorrect.

The same wording as other analytics APIs seems like the right way to go, per this page:
https://github.com/MicrosoftDocs/windows-uwp/blob/docs/windows-apps-src/monetize/get-error-reporting-data.md
Although I'm not completely clear if the route to getting the StoreId is the same for XDP-published titles.
Thanks,
Will.

Thanks for the info, I've updated the topic. It should be published tomorrow. Thanks!


Node: fix examples in docs

Fix small mistake in examples in docs for JSON module.
Thanks @jbrinkman for finding that!

Good to go.  Let's merge this after the release.


Call to undefined method Weblee\Mandrill\Mail::message()

Any idea why this would be happening? Sending via Facade with the code
\MandrillMail::message()->sendTemplate($template_name, $template_content, $message);

i'm sure that it should be messages() not message()
take a look at
weblee\mandrill\src\Mail.php

@mcblum see the answer by @Spycomb he's right. Using messages() is the way to go. It's probably a typo in the docs at https://github.com/weblee/Mandrill

Forgot to say thanks for the answer! I hate it when people don't reply after they've been helped by the community.

Glad it helped you out! Thanks to @mcblum for spotting the issue.


How to convert the .pdb file into the graph.

I am looking for the script to preprocess my protein data i.e. '.pdb' file. Can you provide me with the exact file in the GitHub repo for the process?
Thank you for your help.

Hi @Rajratnpranesh,
Thanks for the question. The code to preprocess the protein data is complex and involved several third party software programs, so we opted to exclude it for cleanness and instead include the postprocessed data sets themselves. So there is no code in this repo which will preprocess new .pdb files.
However, I have documented the preprocessing steps in detail in Appendix A of my MS thesis, which can be found here. Feel free to take a look and let me know if you have any questions about the process. Sorry for the inconvenience.
Alex.


AttributeError: 'Response' object has no attribute 'print_response_stream'

Version
v0.6.16.post1
Description
Flowing the official document: Demo-ChatGPT, printing this error at response.print_response_stream()

Same issue found at https://github.com/jerryjliu/llama_index/issues/3366, but no useful solution.

Problem solved. It is not a "response" related reason, but that I loaded an empty document by mistake...


Improve the gas cost for users at sale time

IMPORTANT. This issue focuses on gas cost for the execution of the user, as measured here:
https://github.com/RareSkills/RSA-presale-allowlist/blob/main/test/rsa.test.js#L182
Although we welcome suggestions to improve the other gas costs, this is the one relevant to the gitcoin bounty.
"Clever but sketchy" gas optimizations don't qualify. This is intended to be used for production. You may not introduce security or reliability vulnerabilities. Restructuring the code to accomplish the same thing in a better way is acceptable. You are not required to follow the current structure of the code.
Bounty sponsored by RareSkills

@RareSkills Hello
when is the deadline because Im confused as to why we can't apply until 3 days before it?

@RareSkills Hello when is the deadline because Im confused as to why we can't apply until 3 days before it?

please answer

The requirements will be posted on Twitter

Is this bounty closed?

Please see the terms in the description
On Fri, Jan 20, 2023 at 1:48 AM SurroundingArt64 @.***>
wrote:

Is this bounty closed?
—
Reply to this email directly, view it on GitHub
https://github.com/RareSkills/RSA-presale-allowlist/issues/8#issuecomment-1397448082,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A3IJURO4EYWN5LJSRIRRJ33WTGD7XANCNFSM6AAAAAASVJGQVM
.
You are receiving this because you modified the open/close state.Message
ID: @.***>

The requirements will be posted on Twitter

Really messy this bounty. Twitter for requirements?

This is a Twitter contest. The bounty is the award.
On Fri, Jan 20, 2023 at 8:33 PM abebeos @.***> wrote:

The requirements will be posted on Twitter
Really messy this bounty. Twitter for requirements?
—
Reply to this email directly, view it on GitHub
https://github.com/RareSkills/RSA-presale-allowlist/issues/8#issuecomment-1398398927,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A3IJURND4XYRXJ7SYALRF43WTKH2DANCNFSM6AAAAAASVJGQVM
.
You are receiving this because you modified the open/close state.Message
ID: @.***>


Update broken link in readme

oops, didn't see #59. closing!

Codecov Report

Merging #61 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master    #61   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files          30     30
  Lines         243    243
=====================================
  Hits          243    243

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 64c7ca8...9c1cd55. Read the comment docs.


Fix shm free concurrent problem

Issues associated with this PR
Your PR should present related issues you want to solve.
Sign the CLA
Make sure you have signed the CLA
Solutions
You should show your solutions about the issues in your PR, including the overall solutions,
details and the changes. At this time, Chinese is allowed to describe these.
UT result
Unit Test is needed if the code is changed, your unit test should cover boundary cases, corner cases, and some exceptional cases.
And you need to show the ut result.
Benchmark
If your code involves the processing of every request, you should give the Benchmark Result
Code Style

Make sure Goimports has run
Show Golint result

Codecov Report

Merging #819 into master will decrease coverage by 0.12%.
The diff coverage is 48.33%.

@@            Coverage Diff             @@
##           master     #819      +/-   ##
==========================================
- Coverage   55.56%   55.43%   -0.13%
==========================================
  Files         232      232
  Lines       23625    23692      +67
==========================================
+ Hits        13127    13134       +7
- Misses       9302     9356      +54
- Partials     1196     1202       +6

Impacted Files
Coverage Δ

pkg/metrics/shm/zone.go
69.23% <ø> (+3.37%)
:arrow_up:

pkg/log/errorlog.go
79.01% <0%> (-15.11%)
:arrow_down:

pkg/network/transfer.go
0% <0%> (ø)
:arrow_up:

pkg/server/adapter.go
64.7% <0%> (-1.97%)
:arrow_down:

pkg/xds/v2/adssubscriber.go
0% <0%> (ø)
:arrow_up:

pkg/stream/http/stream.go
10.24% <0%> (-0.12%)
:arrow_down:

pkg/admin/server/apis.go
40.56% <100%> (+4.85%)
:arrow_up:

pkg/admin/server/server.go
89.65% <100%> (+0.36%)
:arrow_up:

pkg/network/filtermanager.go
16.94% <100%> (ø)
:arrow_up:

pkg/upstream/cluster/cluster_manager.go
63.63% <100%> (+0.37%)
:arrow_up:

... and 17 more

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 a34f2e6...d76a34f. Read the comment docs.


Getting Logged Out On Page Refresh

My Setup

Operating System: Linux Manjaro
App Version: 3.0.7
Installation type: AUR (maintainer: matthias.lisin)

[x] I have tested with the latest version
[x] I can simulate the issue easily

Description

When forcing a reloading of the Electron application (via Ctrl + R) I get logged with the error message:
Invalid user [error-invalid-user] and get immediately logged out.
After logging in again I get a shortly visible message:
No user with username <base64 string or something similar> was found!
Current Behavior

Getting logged out.
Expected Behavior

Not getting logged out.

Strange, in my case logoff is only on Shift+Ctrl+R
https://github.com/RocketChat/Rocket.Chat.Electron/issues/1864#issuecomment-722870350

I'm not entirely sure why, but I guess I just have a different key mapping. I will close this then due to being a duplicate.


Add functions for vectors

It's easy to add, but it is strange that these functions no.
I understand that it is easily implemented in GDscript, but sometimes I just don't want to clutter up the scripts short functions.

Find the sum of distances of all vectors in PoolVector2Array / PoolVector3Array.

# GDScript 3.0
func _ready():
	var pv3a = PoolVector3Array ()

	pv3a.append(Vector3(13,7,3))
	pv3a.append(Vector3(32,3,1))
	pv3a.append(Vector3(44,3,7))
	pv3a.append(Vector3(89,6,4))

	print (get_distance(pv3a)) # 78.135186

func get_distance(arr): # This function
	var arr_dist = 0
	for i in arr.size() - 1:
		arr_dist += arr[i].distance_to(arr[i + 1])
	return arr_dist

Vector3 to Vector2 and vice versa.

# GDScript 3.0
func _ready():
	print (to_vector2(Vector3(30, 10, 0))) # Vector2(30, 10)
	print (to_vector3(Vector2(24, 3))) # Vector3(24, 3, 0)

func to_vector2(vec):
	return (Vector2(vec.x, vec.y))

func to_vector3(vec):
	return (Vector3(vec.x, vec.y, 0))

(Yes it's not ideal, but probably there is an option to add a selection of axes.)

+1 to vector3 to vector2 and back.

Or support swizzling

Isn't to_vector almost as long to type as what it does ?
I don't know what is the policy of the engine on such "ease-of-use" functions. I could try implementing them if it was decided to be necessary, that will teach me how binding functions to GDScript works :)

possible duplicate of #6861

The Vector3 to Vector2 part is a duplicate of #6861 indeed. Rewording the title to focus on the first proposal (please make separate issues for each proposal next time).


$? ($CHILD_ERROR) is not set properly

$? ($CHILD_ERROR) is not set properly.  It needs to be shifted 8 bits left.

Fixed in v1.027


Check concurrency issue

Related to https://github.com/OrchardCMS/OrchardCore/issues/7449 and https://github.com/OrchardCMS/OrchardCore/issues/7545
Repro

Save a given entity with checkConcurrency to true
Do a first session query non related to the above entity => FlushAsync()
Do at least a 2nd session query => FlushAsync()
...
Save again the same entity with checkConcurrency to true
CommitAsync()

On the first FlushAsync() a SaveEntityAsync() is done that enlists a CreateDocumentCommand() that is then executed, finally the entity is added to state.Tracked and removed from state.Saved. On the second FlushAsync(), because the entity is in state.Tracked, UpdateEntityAsync() is called where, because of the checkConcurrency, the version is incremented but, because the entity is tracked and its content has not changed yet, the related UpdateDocumentCommand is not enlisted, so not executed through the current flush.
Then when the entity is saved again, it is removed from state.Tracked and added to state.Updated, so when the session is committed, through the final flush that recalls UpdateEntityAsync(), the version is incremented again and, because the entity is no more tracked (and its content may have been updated), an UpdateDocumentCommand is enlisted and then executed. So the document version is incremented twice but only one UpdateDocumentCommand is executed, so there is a version missmatch resulting in a false ConcurrencyException
So here,  if the entity is tracked and its content has not changed yet, i revert the document version update.
Update:
I built YesSql locally and made packages in a local feed, so i could try my YesSql updates, I can confirm that it fixes the related OC issue. Note: To be able to build OC in this context i needed to do some adaptations as currently we don't reference the last dev of YesSql. E.g. StoreFactory.CreateAsync() replaced by StoreFactory.CreateAndInitializeAsync().
Update: I found a temporary fix on OC side, defining a Version property in our Document base class prevents a version missmatch, this because the version of the tracked object is also incremented, so its serialized content becomes different and then the related UpdateDocumentCommand is enlisted.

Thanks! I might steal this PR and do a unit test first, to be sure we don't regress, and understand how it's happening to be sure there is no better solution than call -- which scares me. Like is there any way that the version could be incremented more than once?

Like is there any way that the version could be incremented more than once?

Yes, on a first flush for a saved object that is then marked as tracked, then in a 2nd flush because it is tracked, but if its content was not changed the related update command is not enlisted. So in the last commit there is a version mismatch.
As said i found a fix on OC side by adding a Version property to our Document base class. So in this case this property is also incremented, so we see that the document content has changed and then the related update command is enlisted.

But doing this results in more sql cmds for tracked objects (if multiple flushs), that will be fixed with this PR and removing the Version property on OC side, but i also thought about objects for which people still want to have a version property
So, and only for a tracked object, maybe comparing the newContent with oldDoc.Content before incrementing the version, but i didn't go further because if the content are not equal, we would need a 2nd serialization after incrementing the version.


Updated fetch.go to correct a typo in the -no-recurse flag

Fixes #246
Changing -no-recurse flag to simply be called -recurse given that the default behavior is to fetch recursively unless explicitly disabled.

Thanks for fixing this, i mistook how boolean flags in go worked.
The flag needs to be called -no-recurse so that the default invocation is
 gb vendor fetch $PKG

and the flag is invoked like
 gb vendor fetch -no-recurse $PKG

So the simplest way to do this is change the flag to be
 var norecurse
flag.BoolVar(&norecruse, "no-recurse", false, "...")

Then after flag parsing
recurse := !norecurse

Thanks

Thanks for responding so quickly Dave. I'll make the suggested edits and update the PR.

Please also update the documentation,
% cd gb/cmd/gb-venfor
% go install
% go generate
% go fmt

@davecheney which documentation? The usage blurb? I thought I updated that in 6c0d2c5. If there's another spot that I missed I'll be glad to update that as well.

cmd/gb and cmd/gb-vendor have documentantion auto generated using go
generate in alldocs.go. Just run those steps I outline and it'll work out
fine.
On Tue, Jun 30, 2015 at 10:55 AM, Will Madison<EMAIL_ADDRESS>wrote:

@davecheney https://github.com/davecheney which documentation? The
usage blurb? I thought I updated that in 6c0d2c5
https://github.com/constabulary/gb/commit/6c0d2c5b0edcbb9cc5afd9c30dae517c9a7244e9.
If there's another spot that I missed I'll be glad to update that as well.
—
Reply to this email directly or view it on GitHub
https://github.com/constabulary/gb/pull/247#issuecomment-116893978.

Thanks for that tip @davecheney. I ran that sequence of commands but the documentation was unaffected. I think the no-recurse flag's references in all other places were correct so the documentation was rendered correctly.

@wmadisonDev yes, you were right, i keep getting confused with the flags in the long doc comment and the flags package flags.


Add hasTextColor matcher

Missing matcher to check text color

It will be added little bit later. Probably in september after compose release.
For now you can create hasTextColor by your own as extension for Ultron framework.
You need to add a matcher(1) and describe an assertion(2).
See an example of drawable assertions

https://github.com/open-tool/ultron/blob/master/ultron/src/main/java/com/atiurin/ultron/custom/espresso/matcher/ResourceDrawableMatcher.kt
https://github.com/open-tool/ultron/blob/master/ultron/src/main/java/com/atiurin/ultron/custom/espresso/assertion/DrawableAssertion.kt

Done.
Release - https://github.com/open-tool/ultron/releases/tag/2.0.4


Add roles

How can I add roles later in an application? Where should I make adjustments anywhere?

Are you talking about adding user roles in generated application (manually, without meteor kitchen) ?
Depending on what you want to do (what you want to restrict) with roles... I suggest you to generate one empty application that uses roles (create one dummy input file for meteor kitchen, add collection and set roles_allowed_to_read, roles_allowed_to_update, set "roles" array in some pages, etc.), generate application and then search generated code for "roles" - you'l see where and how it is used.


"ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()"

Receiving this error when running the datawrangler based lambda function:
[ERROR] ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()
Traceback (most recent call last):
  File "/opt/python/lib/python3.9/site-packages/codeguru_profiler_agent/aws_lambda/profiler_decorator.py", line 52, in profiler_decorate
    return function(event, context)
  File "/opt/python/lib/python3.9/site-packages/codeguru_profiler_agent/aws_lambda/lambda_handler.py", line 91, in call_handler
    return handler_function(event, context)
  File "/var/task/lambda_function.py", line 75, in lambda_handler
    wr.opensearch.index_df(client=OS_client,df=df,index=os_index,bulk_size=6000)
  File "/opt/python/awswrangler/opensearch/_write.py", line 433, in index_df
    return index_documents(client=client, documents=_df_doc_generator(df), index=index, doc_type=doc_type, **kwargs)
  File "/opt/python/awswrangler/opensearch/_write.py", line 520, in index_documents
    documents = list(documents)
  File "/opt/python/awswrangler/opensearch/_write.py", line 82, in _df_doc_generator
    yield {k: _deserialize(v) for k, v in document.items() if notna(v)}
  File "/opt/python/awswrangler/opensearch/_write.py", line 82, in <dictcomp>
    yield {k: _deserialize(v) for k, v in document.items() if notna(v)}END RequestId: c04929d3-b0b7-4760-8f32-75aed2d41e2f

Updated to version 8 of the Datawrangler lambda layer and confirmed  v2.16.1
Note: Not a programer...(there are probably some very ugly things in there)
import awswrangler as wr
import pandas as pd
from datetime import datetime
import json
import logging
import boto3

logger = logging.getLogger()
logger.setLevel(logging.INFO)
os_endpoint="https://search-aes-siem-htycyka7g5xv54tjdlukq5zrx4.us-east-1.es.amazonaws.com/"

OS_client = wr.opensearch.connect(
    host = os_endpoint,
    region = 'us-east-1'
)

#default index incase no category in log and used for testing
os_index = "demoindex915"

def lambda_handler(event, context):

    # retrieve bucket name and file_key from the S3 event
    if event['source'] == 'aws.s3' and event['detail-type'] == 'Object Created':
        # s3 notification from EventBridge
            bucket_name = event['detail']['bucket']['name']
            file_key = event['detail']['object']['key']
            bucket_file = "s3://"+bucket_name+"/"+file_key
            logger.info('Reading {} from {}'.format(file_key, bucket_name))

    #use our own creds
    #df = wr.s3.read_parquet(bucket_file,use_threads=True,path_suffix="gz.parquet",validate_schema=True)

    #use AssumeRoleCred
    sts_connection = boto3.client('sts')
    datalake_creds = sts_connection.assume_role(
        RoleArn="arn:aws:iam::956801307635:role/Moose-01afd9dd-c103-48c7-b5d0-d527e4f9ebb7-DO-NOT-DELETE",
        RoleSessionName="cross_acct_lambda"
    )

    ACCESS_KEY = datalake_creds['Credentials']['AccessKeyId']
    SECRET_KEY = datalake_creds['Credentials']['SecretAccessKey']
    SESSION_TOKEN = datalake_creds['Credentials']['SessionToken']

    datalake_s3 = boto3.session.Session(
    aws_access_key_id=ACCESS_KEY,
    aws_secret_access_key=SECRET_KEY,
    aws_session_token=SESSION_TOKEN
    )

    df = wr.s3.read_parquet(bucket_file,use_threads=True,path_suffix="gz.parquet",validate_schema=True,boto3_session=datalake_s3)
    #uncomment after testing
    #os_index = "moose-"+(df['category'].iloc[0]).replace(" ", "_").lower()

    if "answers" in df.columns:
        df = df[df['answers'].map(lambda d: len(d)) > 0]
        df = df.explode('answers')

    wr.opensearch.create_index(client=OS_client,index=os_index,
            mappings={
                    "dynamic":"runtime",
                    "strings" : {
                        "match_mapping_type" : "string",
                            "mapping" : {
                            "type" : "keyword"}
                        }
            }
    )

    df.to_json(orient="table")
    logger.info('Writing {} to {}'.format(file_key, os_endpoint))
    wr.opensearch.index_df(client=OS_client,df=df,index=os_index,bulk_size=6000)

To add onto what Anton said, while you wait for AWS to update the managed layers with 2.17.0, you can still use the new version of the layer by specifying the ARN. You can find the appropriate layer ARN for your region and Python version here.

Used the ARN. Bug is fixed!
Thank you very much!
Ross Warren
From: Leon Luttenberger @.>
Reply-To: aws/aws-sdk-pandas @.>
Date: Thursday, September 22, 2022 at 11:14 AM
To: aws/aws-sdk-pandas @.>
Cc: "Warren, Ross" @.>, Author @.***>
Subject: Re: [aws/aws-sdk-pandas] "ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()" (Issue #1625)
To add onto what Anton said, while you wait for AWS to update the managed layers with 2.17.0, you can still use the new version of the layer by specifying the ARN. You can find the appropriate layer ARN for your region and Python version herehttps://aws-sdk-pandas.readthedocs.io/en/latest/layers.html.
—
Reply to this email directly, view it on GitHubhttps://github.com/aws/aws-sdk-pandas/issues/1625#issuecomment-1255163549, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKY432CU4PVBSTEDMF6BEO3V7RYZPANCNFSM6AAAAAAQRPRZSY.
You are receiving this because you authored the thread.Message ID: @.***>


Create azure.yml

https://github.com/MicrosoftDocs/azure-docs/commit/df30f05b3b3dd43c73d6de229a5a928a7f0b9df4

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

whats this for?
review-team-triage

Hi @UnsnappedKhan8 - Thanks for your pull request submission. A member of the content team will review it shortly.

@SyntaxC4 - Could you review the proposed workflow addition or recommend someone suitable to review it? Thanks.

Well thats alright


docs: optimal-cluster-size -> 2.0/admin_guide

/cc @robszumski

Can we move over this entire section? https://github.com/coreos/etcd/blob/master/Documentation/optimal-cluster-size.md#odd-active-cluster-size

LGTM


Freeze dependency versions

openai has deprecated ChatCompletion. Freezing the dependences for now

https://github.com/castorini/rank_llm/pull/44 includes version updates. closing this PR


[BUG?] Client not telling server to close, server not detecting "close" event.

Can you please guys give me a hand here?
https://github.com/ryo-ma/deno-websocket/issues/16
My Deno WebSocketServer dispatches the "close" event with the Javascript built-in WebSocket when I close the HTML page.
But not with the AS3WebSocket lib when I close the NativeWindow. I even tried listening to the NativeProcessErrorEvent.ERROR event and force the websocket to close manually. The other events dispatch ok (new message  and new client connection).
Thanks, cheers.

is there any NativeWindow events that can help you like "closing"?
https://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display/NativeWindow.html#event:closing

is there any NativeWindow events that can help you like "closing"?
https://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display/NativeWindow.html#event:closing

Thanks for the fast response.
Yeah, I guess I can listen to the Event.CLOSE event on the NativeWindow and call websocket.close(). But now I'm thinking... if in HTML/Javascript I don't have to listen to any UI event to make the client websocket let the server know it's being closed, why would I have to make it in an AIR application? The websocket should automatically close when the window is closed and the WebSocketServer would immediately know that the client was closed and the "close" event would be being dispatched.
This is my JavaScript WebSocket client code:
const ws = new WebSocket("ws://localhost:3555");

// Register event listeners for the open, close, and message events
ws.onopen = () => {
  console.log("WebSocket ready!");
  ws.send("Hello World!");
};

ws.onmessage = (message) => {
  console.log("Received data:", message.data);
};

ws.onclose = () => console.log("WebSocket closed!");
ws.onerror = (err) => console.log("WebSocket error:", err.error);```

See? I'm not handling any UI event on the HTML window when it "closes", and the Javascript WebSocket class still let the server know that the client is not connected anymore.

So I think this may be a bug in the AS3WebSocket library. I never had issues with these events in any other language like Dart or Python. All the events are dispatched correctly.  Also, using the Socket class in AS3 and using a non WebSocket server in NodeJS for example, all events dispatch correctly too.

First of all, how do you use the AS3 websocket if it's not in an AIR app?
the NativeWindow has a "CLOSING" event,  "CLOSE" is another event. "CLOSING" is fired just before the window closed.

Whoa.... people are still using this? I'm genuinely surprised, given that Flash is pretty much dead!

I developed this library for a browser-based web app, and haven't ever tested it in an Air context or on Android, so I'm not really familiar with these NativeWindow events you're talking about, but watching for them and then manually closing any open connections sounds likely to be the right approach with least effort. You could fork and update the library if you want to hook into those things under the hood. I'll accept a PR if you do, but I am generally considering this library to be obsolete and unsupported at this point.

First of all, how do you use the AS3 websocket if it's not in an AIR app?
the NativeWindow has a "CLOSING" event, "CLOSE" is another event. "CLOSING" is fired just before the window closed.

I get your irony. I'm aware Flash Player died, so no more Flash Player on the web.  I was just being specific about my environment to have a better clue at what's happening.
I know it's Event.CLOSING, it was just a typo for all the times I've wrote the word "close".
I was just having a nostalgia moment, trying Deno for the first time, and decided to use an AIR app as the client to test it.
But I'm not using any of this in production of course.
Although, there are still many AS3/AIR developers out there using the AIR SDK that Harman owned from Adobe.
Others like me moved on to other technologies (ReactNative/TypeScript, Xamarin/C#, Fluttert/Dart). And a very few others moved to Haxe and OpenFL.
But I didn't intend to turn this thread in a debate about AS3/AIR/Flash obsoleteness.  Just wanted to know why this AS3WebSocket lib isn't telling the server that it disconnected when closing the NativeWindow.
Cheers. Stay safe.

nothing is dead on computer, it's just an illusion for the sheep following the matrix...
Java is not dead, and people said 10 years ago it's dead for the web, Flash is the same
and the next couple of months/years it will rebirth as a phoenix with WASM. (check ruffle-fs)
with wasm, I'm pretty sure javascript will also die... and the sheep will jump from the cliff, believing they understood everything from their masters matrix.


[Big Data Model Overview] Box plot data for classification probabilities from SDK endpoint

This PR adds /model_overview_probability_distribution REST API call.
Description
To support big data scenarios, we need to make REST API calls to SDK side and retrieve model overview probability distribution for each selected cohort. This PR adds /model_overview_probability_distribution REST API call.
UI Gif:

The unit tests are adding in progress.
Checklist

[x] I have added screenshots above for all UI changes.
[ ] I have added e2e tests for all UI changes.
[ ] Documentation was updated if it was needed.

Codecov Report

Merging #1689 (f6a083b) into main (0ebfb88) will increase coverage by 6.38%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1689      +/-   ##
==========================================
+ Coverage   78.93%   85.31%   +6.38%
==========================================
  Files          19       58      +39
  Lines        1315     3031    +1716
==========================================
+ Hits         1038     2586    +1548
- Misses        277      445     +168

Flag
Coverage Δ

unittests
85.31% <ø> (+6.38%)
:arrow_up:

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

Impacted Files
Coverage Δ

raiutils/raiutils/models/model_utils.py
100.00% <0.00%> (ø)

...ranalysis/erroranalysis/_internal/cohort_filter.py
87.04% <0.00%> (ø)

...is/erroranalysis/_internal/process_categoricals.py
100.00% <0.00%> (ø)

...re_flask/environments/local_ipython_environment.py
88.88% <0.00%> (ø)

erroranalysis/erroranalysis/_internal/__init__.py
100.00% <0.00%> (ø)

...ai_core_flask/environments/azure_nb_environment.py
73.52% <0.00%> (ø)

..._core_flask/rai_core_flask/environment_detector.py
53.33% <0.00%> (ø)

...i_core_flask/environments/public_vm_environment.py
88.88% <0.00%> (ø)

raiutils/raiutils/webservice/__init__.py
100.00% <0.00%> (ø)

..._flask/environments/credentialed_vm_environment.py
100.00% <0.00%> (ø)

... and 29 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Thanks for adding unit tests :)


Cluster config not persistent

Hello!
Due to zookeeper has no storage, and cluster config is applied only once on creation via job, cluster list is not persistent and will disappear after every CMAK pod recreation.
There is 2 possible ways to solve this:

Add persistent storage to Zookeeper.
Run cluster population script in an initContainer.
Thanks.

Thnx for opening a bug. I am still thinking about proper fix for the issue.

Ya this is a pretty big bug as it just makes the tool unusable. Perhaps adding an option to the chart to either add a disk or init is a flexible solution.

PRs are welcomed, btw.

I am making one don't worry, I just was giving you the two approaches I may
take. I just made changes in my flux repo. If it works as expected I will
add as a PR.
Would you also be receptive to having a toggleable ingress?
On Wed, 18 Nov 2020, 15:09 Ievgenii Shepeliuk<EMAIL_ADDRESS>wrote:

PRs are welcomed, btw.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/eshepelyuk/cmak-operator/issues/2#issuecomment-729701365,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AG6KEUMKUBRIS5PWQWIZSFLSQPIQDANCNFSM4TNHZNGA
.

Would you also be receptive to having a toggleable ingress?

Absolutely, I'd just prefer to have it in the different PR

I will test it over the next day or two. If it keeps working I will submit my changes as a PR. I will also submit a separate one for the ingress then as well.
To get the initcontainer approach to work I had to split the zk and cmak deployments into two with separate services because the cmak job needs zk running or it won't execute. The job runs as an initcontainer to cmak-ui and watches for zk service to be active then runs and it all boots.

Do you still need k8s Job while using initContainer for putting config into ZK ?
I suppose, don't.
initContainer should be added to ZK, not to cmak-ui.
Since the data disappeares when ZK container restarts.
Well, if you think about recinciliation, then it is not an initContainer approach, but a separate deployment should be created that reconciles ConfigMap to ZK if the data disappers.

Maybe I just misunderstood the approach, i am open for further design discussion.

Okay so you were 100% correct putting it as an init container for the UI wouldn't work longterm. I instead went for an approach where the zookeeper pod has an init container that creates the setup job from a mounted configmap. This way on each reboot the job will run until the zookeeper is up. So far it seems to work. If it has no issues I will try and have a PR this week.

Good news @sharkymcdongles , thanks

@sharkymcdongles any news on this?

Sorry I took the week off for Thanksgiving. It seems to work though as I
heard no complaints after making the change. I will submit a PR for the job
tweak first then the ingress separate. I hope to do it Monday or Tuesday.
On Sat, 28 Nov 2020, 16:54 Alexey T<EMAIL_ADDRESS>wrote:

@sharkymcdongles https://github.com/sharkymcdongles any news on this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/eshepelyuk/cmak-operator/issues/2#issuecomment-735247993,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AG6KEUOJAK6H6JOPELOUG2LSSEMJ5ANCNFSM4TNHZNGA
.

Please take a look at PR #3

@sharkymcdongles @lexasoft123 released 0.7.0
Please give it a try.


A reentrancy attack using NFTs

https://etherscan.io/tx/0x05d65e0adddc5d9ccfe6cd65be4a7899ebcb6e5ec7a39787971bcc3d6ba73996
Tenderly debug: https://dashboard.tenderly.co/tx/mainnet/0x05d65e0adddc5d9ccfe6cd65be4a7899ebcb6e5ec7a39787971bcc3d6ba73996

Hi @htadashi, thanks for your participation. The community and our team all benefit from your partaking.
You may have noticed that we are working on a complex transaction analyzer. Here is the link to the tool parsing the tx you submitted.
The analyzer link

This tool is still in the private test phase that only opens to a few users.
You are more than welcome to join the specified discord channel for it. We look forward to your suggestions on features, bugs, and improvements. C'mon in!
https://discord.gg/kmjNKFvV

@DataFi-EigenPhi it was a pleasure, as I love your work. And I also will be delighted to experiment this new tool :)

Thanks! I sent you a message there :)


Refactor Bidi Streaming Write to Buffer Entities before writing

Refactors the Bidi Streaming write (the saveAll() operation) to buffer the incoming entities before writing.
Fixes #1813.
Note that I wasn't able to generalize this solution to put it in ObservableReactiveUtils... It is getting complex and it felt to me that the generalization would be harder to understand than just keeping the code here.

Can you also ask Mark to take a look at this? Thanks!

@mp911de - Hey Mark, could we get your counsel on Reactive in this PR? We just specifically have a question about this method: saveAll.
It is basically us trying to wrap a bi-directional stream into Reactive patterns. We have a requestStream that we send elements into, and a responseStream that outputs responses for each batch of elements we submit to the requestStream. And from every response that we get from the responses stream, there is a stream token; we take the most recent stream token we got and attach it to the next request that we send to requestStream. We would appreciate your input!

As discussed offline with Chengyuan, I decided to keep the bidi code in the ObservableUtils class since this is going to be reused by delete and other batch operations. Modified it so that it is able to return the original flux of inputted elements and also added setter for batch size. PTAL.

I've been on vacation lately, so sorry for my late response. I'm not sure I understood your question.
In general, saveAll should mirror the store's (or driver's) semantics. If it is the most efficient way, to stream element by elements as save stream, then that is a great way to solve your requirement.
In MongoDB, we have also a batch insert but Mongo's approach is to take a materialized batch of documents and then insert them in a single command (see ReactiveMongoOperations.insertAll(Mono<? extends Collection<? extends T>>).
For Cassandra, insert-all issues a series of individual commands.
Let me know if you need to revisit that topic.


TimePicker moves to minute mode after hour selection

Description
Adds a feature of the native Android Time Picker to our Material Time Picker. When the user selects an hour, it automatically switches to minute mode.
This is a merging of two pull requests:

Code changes from @sdolski https://github.com/flutter/flutter/pull/24677
Tests from @lucaslcode https://github.com/flutter/flutter/pull/29876

Thanks to both of you for your contributions!
Related Issues
Fixes #17276, #29600
Tests
The following tests were added from @lucaslcode:
'tap-select switches from hour to minute'
'drag-select switches from hour to minute'
to time_picker_test.dart.
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I signed the CLA.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I updated/added relevant documentation (doc comments with ///).
[x] All existing and new tests are passing.
[x] The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require Flutter developers to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (Please read Handling breaking changes). Replace this with a link to the e-mail where you asked for input on this proposed change.
[x] No, this is not a breaking change.

How do I set it to no show the minutes (like t was before) ?


use filp/whoops ^2.0

composer update after composer create project got filp/whoops == 2.0.0 not found, fill with ^2.0 should make it works.

Actually, this won't work.
filp/whoops 2.0 requires a minimum PHP version of 5.5.9; we've specified ^5.5, which means if you're on an earlier version, specifying ^2.0 means it cannot be installed.
Additionally, the version in composer.json is only for testing the installer scripts themselves; the installer lets composer autoselect the version, which works fine as 1.1 and 2.0 are compatible for the use cases we have in Expressive.
I'll merge, but I'm going to change it to ^1.1 || ^2.0.


Tom Clancy's: The Division

I finally got The Division working. It's so awesome @doitsujin thanks for all your work.
I'm running:
CPU: Ryzen 2700
GPU: Nvidia GTX 1070
Nvidia: 396.45
Wine: 3.13 Staging (latest ArchLinux wine-staging)
DXVK: 0.62
There is a small issue with playing videos and the game itself. Maybe it is just because of shader compiling on the first start - not sure, but I just want to let you know, that every time the following info log is shown, the game stutters/hangs:
info:  DxgiVkPresenter: Recreating swap chain:
  Format:       VK_FORMAT_B8G8R8A8_UNORM
  Present mode: VK_PRESENT_MODE_FIFO_KHR
  Buffer size:  1920x1080

Sometimes there is an additional msg:
[0811/171637.219:WARNING:PushPullFIFO.cpp(182)] PushPullFIFO: underflow while pulling (underflowCount=1, availableFrames=0, requestedFrames=480, fifoLength=12288)

If there is a chance to fix this, this would be nice. Possibly it is just a small issue

The swap chain message only pops up when the game actually has to re-create the Vulkan swap chain, either because it enables/disables Vsync, changes the color format, or resizes the window. This is a somewhat expensive operation, but cannot be avoided
Not sure what the other message means or where it even comes from, but it's not related to dxvk.
Anyway, whatever the issue is, I can't do anything about it, especially with this little information given.


Memory leak on exit - CONF_modules_load through RAND_status

OpenSSL 3.2.2
Shows the following mem leak with libsanitizer.
#include <stdio.h>
#include <openssl/rand.h>
#include <openssl/crypto.h>
#include <openssl/conf.h>

int main(int a, char ** b) {

    RAND_status();
    // throwing anything I know at it.
    CONF_modules_finish();
    CONF_modules_free();
    CONF_modules_unload(1);

    OPENSSL_cleanup();

}

Not sure whether I'm missing a clean-up, but this seems to have popped up just recently.
[vps@druid]~/tmp$ gcc -o 1 -fsanitize=leak 1.c -lssl -lcrypto
[vps@druid]~/tmp$ ./1

=================================================================
==479154==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 32 byte(s) in 1 object(s) allocated from:
    #0 0x7f75336c28d7 in malloc (/lib64/libasan.so.8+0xc28d7) (BuildId: 5294bd2731fcae07af92dfea7808576c57d53bc9)
    #1 0x7f7533128a10 in CRYPTO_malloc (/lib64/libcrypto.so.3+0x128a10) (BuildId: 037844d4052a7d85e7642620f7fa8ed37436bb0f)
    #2 0x7f7533128ac4 in CRYPTO_zalloc (/lib64/libcrypto.so.3+0x128ac4) (BuildId: 037844d4052a7d85e7642620f7fa8ed37436bb0f)
    #3 0x7f75334f085f  (/usr/lib64/libasan.so.8.0.0+0x13f85f)
    #4 0x7f7533137719 in provider_activate (/lib64/libcrypto.so.3+0x137719) (BuildId: 037844d4052a7d85e7642620f7fa8ed37436bb0f)
    #5 0x7f7533137c3e in ossl_provider_activate (/lib64/libcrypto.so.3+0x137c3e) (BuildId: 037844d4052a7d85e7642620f7fa8ed37436bb0f)
    #6 0x7f7533138f6e in provider_conf_activate (/lib64/libcrypto.so.3+0x138f6e) (BuildId: 037844d4052a7d85e7642620f7fa8ed37436bb0f)
    #7 0x7f7533139360 in provider_conf_load (/lib64/libcrypto.so.3+0x139360) (BuildId: 037844d4052a7d85e7642620f7fa8ed37436bb0f)
    #8 0x7f7533139a2a in provider_conf_init.lto_priv.0 (/lib64/libcrypto.so.3+0x139a2a) (BuildId: 037844d4052a7d85e7642620f7fa8ed37436bb0f)
    #9 0x7f7533070004 in CONF_modules_load (/lib64/libcrypto.so.3+0x70004) (BuildId: 037844d4052a7d85e7642620f7fa8ed37436bb0f)
    #10 0x7f75330705a7 in CONF_modules_load_file_ex (/lib64/libcrypto.so.3+0x705a7) (BuildId: 037844d4052a7d85e7642620f7fa8ed37436bb0f)
    #11 0x7f7533127ea7 in ossl_init_config_ossl_ (/lib64/libcrypto.so.3+0x127ea7) (BuildId: 037844d4052a7d85e7642620f7fa8ed37436bb0f)
    #12 0x7f7532683a0a in __pthread_once_slow.isra.0 (/lib64/libc.so.6+0x75a0a) (BuildId: 91788144d53e5cfc0caf97896b43c60e978cffc1)
    #13 0x7f7532683a78 in __GI___pthread_once (/lib64/libc.so.6+0x75a78) (BuildId: 91788144d53e5cfc0caf97896b43c60e978cffc1)
    #14 0x7f7533134a3c in CRYPTO_THREAD_run_once (/lib64/libcrypto.so.3+0x134a3c) (BuildId: 037844d4052a7d85e7642620f7fa8ed37436bb0f)
    #15 0x7f7533128982 in OPENSSL_init_crypto (/lib64/libcrypto.so.3+0x128982) (BuildId: 037844d4052a7d85e7642620f7fa8ed37436bb0f)
    #16 0x7f753321eebf in ossl_engine_table_select.isra.0 (/lib64/libcrypto.so.3+0x21eebf) (BuildId: 037844d4052a7d85e7642620f7fa8ed37436bb0f)
    #17 0x7f75331620a4 in RAND_get_rand_method (/lib64/libcrypto.so.3+0x1620a4) (BuildId: 037844d4052a7d85e7642620f7fa8ed37436bb0f)
    #18 0x7f7533162cc1 in RAND_status (/lib64/libcrypto.so.3+0x162cc1) (BuildId: 037844d4052a7d85e7642620f7fa8ed37436bb0f)
    #19 0x401189 in main (/home/vps/tmp/1+0x401189) (BuildId: 9429e36aa665f2f88cf4ab3671d806f4b4019dbe)
    #20 0x7f7532611247 in __libc_start_call_main (/lib64/libc.so.6+0x3247) (BuildId: 91788144d53e5cfc0caf97896b43c60e978cffc1)
    #21 0x7f753261130a in __libc_start_main_impl (/lib64/libc.so.6+0x330a) (BuildId: 91788144d53e5cfc0caf97896b43c60e978cffc1)
    #22 0x4010b4 in _start (/home/vps/tmp/1+0x4010b4) (BuildId: 9429e36aa665f2f88cf4ab3671d806f4b4019dbe)

SUMMARY: AddressSanitizer: 32 byte(s) leaked in 1 allocation(s).
[vps@druid]~/tmp$ rpm -qa | grep -e openssl-devel -e liblsan
openssl-devel-3.2.2-9.fc41.x86_64
liblsan-14.2.1-3.fc41.x86_64

I was not able to reproduce the problem, neither with the packaged openssl-version on fedora rawhide nor with the openssl-versions 3.2 and 3.5 from git.
I also found another hint in the man page (CONF_MODULES_FREE(3SSL)):
HISTORY
       CONF_modules_free() was deprecated in OpenSSL 1.1.0; do not use it.  For
       more information see OPENSSL_init_crypto(3).

I'm not sure, if this is relevant for your example. But maybe it helps to remove this call.

can you share your openssl.cnf? I'm not able to trigger the leak with my default openssl.cnf.
however in my case the CONF_modules_load() function is not executed at all (break point did not fire).
thanks.

@holger-dengler  @Sashan
It's the presence of pkcs11 provider that triggers this. Thank you for the pointers. Without the pkcs11-provider F41 package there is no leak.
The config is a hot modular mess, I can paste all the bits, let me know if it'd still be helpful considering the below.
/lib64/libcrypto.so.3+0x137719 is provider_core.c:967. At which point the stack trace from sanitizer output doesn't make sense to me, as it's provider_init(), not provider_activate(). But maybe this is effects of optimization.
It does break for me even without the pkcs11 provider, on ossl_default_provider_init()
It's unclear (to me) what is at 0x7f75334f085f (from libsan trace).
I've set a break point at provider_core.c:967, got to the PKCS11 provider invocation, then bp'ed CRYPTO_zalloc() with num==0x20. There is a bunch of those, but all with some additional stack frames, like OSSL_LIB_CTX_new(), and so on.
The only one that had a "short" call stack that resembles what the sanitizer reports is:
#0  CRYPTO_zalloc (num=num@entry=0x20, file=file@entry=0x7ffff77d30e8 "../src/provider.c", line=line@entry=0x9c) at crypto/mem.c:219
#1  0x00007ffff77c4860 in context_add_pool (ctx=0x415de0) at ../src/provider.c:155
#2  OSSL_provider_init (handle=<optimized out>, in=<optimized out>, out=0x7fffffffd418, provctx=0x7fffffffd420) at ../src/provider.c:1624
#3  0x00007ffff7b3771a in provider_init (prov=0x415830) at crypto/provider_core.c:967

So, looks like I need to go talk to the pkcs11 provider folks instead, right?
P.S. Re: CONF_modules_free() - yeah, I've been just trying to throw things at it to see if any stuck, but its presence doesn't matter.

@veselov yes, please report the issue to the pkcs11-provider project [1]. You may link the issues in both projects, just for the case, that the pkcs11-provider just triggers a bug in openssl.
For the issue, it would be worth if you could provide a minimal configuration which triggers the memleak.
[1] https://github.com/latchset/pkcs11-provider

@veselov thank you for bringing up the issue. The bug seems to be somewhere in pkcs11 provider. no further information is necessary provide those details to pkcs11-provider team.
thanks a lot.

For posterity:
[vps@druid]~/tmp$ OPENSSL_CONF=$(pwd)/1.cnf ./1a

=================================================================
==634856==ERROR: LeakSanitizer: detected memory leaks
...
SUMMARY: LeakSanitizer: 32 byte(s) leaked in 1 allocation(s).
[vps@druid]~/tmp$ cat 1.cnf
openssl_conf = openssl_init

[openssl_init]
providers = provider_sect

[provider_sect]
pkcs11 = pkcs11_sect

[pkcs11_sect]
activate = 1
[vps@druid]~/tmp$

pkcs11.so needs to be present in the proper modules location.


about code

Thank you for your excellent work. When will the code be released?

I'm sorry that it will be released after I finish my examination

I'm sorry that it will be released after I finish my examination. (not too late)

It doesn't matter. Good luck😊

@leafy-lee Gentle Reminder !
Can you please release the code ?

@leafy-lee Could you please release the code?

Thx for reminding. Updated scratch version for variable usage.


LFS-911: Refactor lfs:Subject and lfs:SubjectType nodes to use a tree structure instead of parent references.

Jira link
This mostly changes the backend for all subjects and subjectTypes. You can see the difference in composum, as parentage is now displayed as a tree structure, like below:

To test: Just need to verify that this change didn't break anything -- the biggest changes have affected the creation of subjects and subject types.
TO DO:

[x] upload variants page displays a 404 error
[x] deleting subjects and subject types doesn't work
[ ] uploading variants doesn't work

Found an issue:

Subjects table on the dashboard does not show existing Tumor and Tumor Region subject, but does show existing Patients

Found an issue:

Subjects table on the dashboard does not show existing Tumor and Tumor Region subject, but does show existing Patients

Right, all the tables that display subjects now need to be adapted to the new paths.

@acrowthe

Found an issue:
* Subjects table on the dashboard does not show existing Tumor and Tumor Region subject, but does show existing Patients

Fixed in 188f263 :heavy_check_mark:

@marta-

Tumor and Tumor region need to be declared in separate JSONs

Fixed in e23333db :heavy_check_mark:
@sdumitriu

Now the comment above is no longer accurate...

Fixed in e2175e4 :heavy_check_mark:

Variants upload fails

What is the difference between parents and ancestors?
Why do we use parents, not parent, as we only show the first direct ancestor here?

@sashaandjic

Variants upload fails

Fixed in f5c1393 :heavy_check_mark:

patient link on tumor chart does not work

@sdumitriu

Recursive deletion needs to also check for referenced nodes for each child: create a Chemotherapy form for a Tumor, then try to delete the parent Patient.

Fixed in 9e21cbc :heavy_check_mark:

@sdumitriu

* Subjects created through the Variants Uploader are not properly nested, they are all children of /Subjects. This is not a critical bug, but would be nice to have it fixed.

Fixed in 7459bbf


Register v1.1

@JuliaRegistrator register
Release notes:
What's Changed

Update ReefModEngine.jl for RME v1.0.28 by @ConnectedSystems in https://github.com/open-AIMS/ReefModEngine.jl/pull/3
set_seeding_deployments() now set_outplant_deployments!() to align with ReefMod Engine terminology
Added result store type
Added tentative support for larval enrichment interventions (untested)

New Contributors

@ConnectedSystems made their first contribution in https://github.com/open-AIMS/ReefModEngine.jl/pull/3

Full Changelog: https://github.com/open-AIMS/ReefModEngine.jl/commits/v1.1

Registration pull request created: JuliaRegistries/General/103839
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v1.1.0 -m "<description of version>" cf208244aac901b6f841358636ef75c56fce9c5c
git push origin v1.1.0


Compiling CUDA operators？

Compiling CUDA operators的cd models/dino/ops python setup的时候报错torch.cuda.OutOfMemoryError: CUDA out of memory.  该怎么解决？
torch.cuda.OutOfMemoryError: CUDA out of memory. Tried to allocate 7.50 GiB (GPU 0; 14.75 GiB total capacity; 7.50 GiB already allocated; 7.13 GiB free; 7.50 GiB reserved in total by PyTorch)

调小batch/numwork

When are you getting this error? While running the model or during training?

When are you getting this error? While running the model or during training?

I got the same error while compiling cuda operators. To be exact, it's while executing python test.py command

Did anyone find a solution to this?


[webpubsub] fix jwt token + reverse proxy endpoint

While the GA code worked for a while after release, it's no longer working. It seems that the service now needs the JwtToken sent in the authentication header to be the original endpoint + specific method url, instead of proxy endpoint + specific method url.
This PR first reproed the issue, then updated the JwtToken policy to replace the proxy url with the original url when encoding for the authorization header
https://dev.azure.com/azure-sdk/internal/_build?definitionId=3297&view=runs (python - webpubsub - tests)
https://dev.azure.com/azure-sdk/internal/_build?definitionId=3716 (python - webpubsub - tests-weekly)

/azp run python - webpubsub - ci


[Bug] FCF Marker

FCF marker is gone once the fleet is proceeding to the next node:

Both Amatsukaze and Bismarck was turning white after being sent home using FCF, but turned to normal like shown in SS above after entering the following node.

@ethrundr are you using webstore version?

My latest pull when submitting this was 35d4f79
Haven't test it after that due to resource shortage :cry:

@ethrundr that commit precedes my fix for the FCF (43cb9e). Make sure you pull the latest commit  xD

tested this one, and as @bamboo3250 said, this has been fixed.
closing the issue now~


Awake on working day schedule

Description of the new feature / enhancement
The Awake powertoy should include a mode option that allows the user to select a time range and day range option to keep the PC awake during eg. a working day... 08h00 to 17h00 from Mon to Fri.
Scenario when this would be used?
The feature would be invaluable for people working from home that need their PC awake during the working day.
Supporting information
Pretty obvious requirement.

/dup #27790
/dup #28283
/dup #28815


Block efact message creating for timeout or failed to fetch

Fixes https://github.com/antoinepairet/medispring/issues/1953

@gpiroux


Unable to type tab character in the middle/end of text

Line indents instead.

We should maybe have a preference item for this. But why are you doing this? Maybe use clang-format instead (control-shift-i)?

Simple usage:
int x = 2;<<\t>>// set to the smallest prime number

I still would setup clang-format to do this for me actually. Doing such things manually feels a bit old-fashioned. See for instance http://clang.llvm.org/docs/ClangFormatStyleOptions.html and its AlignTrailingComments.


HMAC should work with non-provided digests

Fixes #12839

Checklist

[ ] documentation is added or updated
[ ] tests are added or updated

Travis is happy.

This pull request is ready to merge

Merged. Thanks!


The first time the dashboard loads, it's scrolled down halfway

I've noticed this a few times: when the dashboard loads the first time after signing up (not logging in), it's scrolled halfway down the page (so the "Welcome to the Couchers.org Beta!") isn't visible.

Closing this, can't reproduce on chrome both desktop/android. Feel free to reopen if problem still exists.


French email templates not being used for French user.

We now have French templates for all email, but they don't seem to be picked up for French language users.

Title is in French, but template is not used:

@dottorer: none of the french templates were pushed from Mailchimp to Mandrill.

I pushed all of the french templates and verified in my local dev that french templates work.

@phil-monroe sorry totally my bad, i forgot about the mandrill push when I cloned the templates - duh!


chore: README typo

Hee hee hee! It looks like I'm one of those annoying hacktoberfest people, but I'm not.
I'm copy-pasting the docs into the @types/needle package and noticed this typo (🧙).

Thanks mister!


Add a way to update a thing installed by cargo install

See https://bugzilla.mozilla.org/show_bug.cgi?id=1336555 for backstory. It would be nice to have a way to update a tool installed by cargo install to the latest available version of that tool. e.g. running cargo install --update cargo-vendor would download and install the latest version of cargo-vendor, but only if your version is out-of-date.

Dupe of  #3496 and #2082

Indeed, I'm going to close in favor of https://github.com/rust-lang/cargo/issues/2082


Allow the site to be generated using data from a TAXII server

As a user of the ATT&CK website, I want to ensure that my local copy of the data is up-to-date. By connecting to the ATT&CK TAXII server, I can make sure every build uses the latest data.
Allow the user to build using data from the TAXII server instead of local files in data/stix. The TAXII server configured (default should be the ATT&CK TAXII server) should also be used for documentation generated for #137. The configuration for this can be formatted like it is on the ATT&CK Navigator.

Closing due to inactivity - may re-open if further interest in this topic is brought up in the future


Gauge installation should fail if install commands fail

Gauge runs a few commands to install plugins. If a plugin installation fails or post installation commands fail, gauge should fail the installation.
Dev Notes :
To fix this, Gauge should unzip the plugin in OS temp directory, run the installation commands. Only if installation is successful, it should copy over the files to the Gauge plugin folder.

Fix should be available in nightly >= 2018-05-09

Actual behavior
The directory contains gauge project related folders even when initialization is incomplete
d-----        5/14/2018   1:11 AM                env
d-----        5/14/2018   1:11 AM                logs
d-----        5/14/2018   1:11 AM                Properties

Expected behavior
Should contain gauge project files/folders only when the initialization succeeds
Steps to replicate

gauge init csharp when offline


chore(ci): add image pull with retry

This is another in a series of PRs which have been proposed for #502 .
My thought is to identify areas in build_image which have spurious failures and fix them if reasonable within our scripting, or otherwise address issues, like this one.
The idea here is we fix the spurious failures pulling our (very large) base images, by pulling them to the build runner before using the buildah action.

This still won't catch all issues, and it doesn't even try to pre-pull akmods or config image layers ... but we have other efforts in flight to address those concerns by moving to a dnf/yum repo instead.

The failure on this currently is a kernel version incompatibility between a kmod and image kernel. Shouldn't block merging of this.


chore(sdk): Pin Importer polars dependency

Description

What does the PR do? Include a concise description of the PR contents.

[x] I updated CHANGELOG.md, or it's not applicable

Testing
How was this PR tested?

@andrewtruong could you confirm that it is ok, to have the version pinned meaning that polars wouldn't be updated for new versions?

I think it's ok for now -- import is usually a 1-time thing so I think it's reasonable to spin up a new env with pinned dep.
Longer term, we should un-pin and fix


Fixed vertical overflow on whole screen and added scroll bar styling and

Fixes Issue
Closes  #99

Changes proposed
When the events list overflows, the scrollbar is added to the parent element of the events list, and the map, I have now hidden the overflow and added custom styling to the scrollbar for the events list.

Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[ ] My change requires changes to the documentation.
[ ] I have updated the documentation accordingly.
[ ] All new and existing tests passed.
[x] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.

Screenshots

Note to reviewers

Looks great! On resize it will add a horizontal scroll too which isn't needed, but this is part of the issue of needing to overhaul the site to be responsive so no changes needed for now on that.  There's already another issue open.


dart2js infers bad type for provided list

In the following example, dart2js somehow gets the type for x wrong.
int foo([List _methods = const []]) {
  final methods = new List.from(_methods);
  for (int i = 0; i < 3; i++) {
    methods.add((int x) => x + i);
  }
  return methods[0](499);
}

main() {
  print(foo());
}

Interestingly, just changing the initialization of methods "solves" the problem:
int foo([List _methods = const []]) {
  final methods = []..addAll(_methods);
  for (int i = 0; i < 3; i++) {
    methods.add((int x) => x + i);
  }
  return methods[0](499);
}

main() {
  print(foo());
}

Initializing it with _methods.toList() is also buggy.
Running dart2js with --disable-type-inference also leads to correct results. This is clearly an issue with the type inference...
/cc @rakudrama
thanks to @hermanbergwerf for finding this issue.

any updates on this?

This is what I think is going on:
During type propagation, summary edges are added from the inputs at a call site to the parameters of the target, bypassing the call. There is no node representing an argument at the call - the ssa value is used, in the case of the methods.add call, the closure.
During tracing, isAddedToContainer and isParameterOfListAddingMethod work together to decide if (1) a value flows into a container and process the flow, or (2) if it flows into the function to be handled 'normally'. It is busted because isAddedToContainer is used at the call site where the receiver type is checked, and isParameterOfListAddingMethod is tested on the parameter (reached by the summary edge), independent of the call site or state of the receiver.  Thus it is possible for isAddedToContainer be false (the type returned by List.from is not a container type since we forgot to add List.from to the special rules for allocated lists) and isParameterOfListAddingMethod to be true (for JSArray.add's value parameter), preventing flow into the body. Tracing stops, leaving the closure both uncalled and unescaped, so the parameter type is .
The processsing of calls should probably be changed so that the decision on argument-to-parameter flow for the special cases occurs at the call site, where the parameter(s) of the targets satisfying isParameterOfListAddingMethod are explicity enqueued.

Fix available: https://codereview.chromium.org/2762493002/


bgv : Add a verifier for Rotate

I believe there should be a check ensuring that the dimension of the ciphertext, which serves as the operand of rotation, is two.
Justification:

SEAL throw an error when the above condition is violated:
https://github.com/microsoft/SEAL/blob/206648d0e4634e5c61dcf9370676630268290b59/native/src/seal/evaluator.h#L1046
There's a bug in OpenFHE when the above condition is violated:
https://github.com/openfheorg/openfhe-development/issues/575

However, due to my lack of HE knowledge, I don't know why the rotation doesn't work when the dimension of ciphertext is greater than 2. Let me know if anyone knows!

I will summarize the work needed to do this here, in case you are looking to dip your feet into the coding. A high-level explanation of how verifiers work is here.

Add let hasVerifier = 1; to the BGV rotate op in BGVOps.td
Add a new implementation of a function with signature LogicalResult RotateOp::verify() { ... } to BGVDialect.cpp
Add a lit test in tests/bgv that uses --verify-diagnostics to assert the appropriate error message is reported when verification fails. A good example is here

Let me know if anyone knows!

While I don't think it's theoretically impossible to apply a galois rotation on a length 3 ciphertext, I think the reason both implementations avoid doing so is because the Galois Keys are computed to switch the ciphertext from being encrypted from a key (1, s^i) to a (1, s). If the ciphertext has length 3, then I'm not sure why there aren't static size checks, but the key switching matrix would only apply to the first two polys of the ciphertext and then probably leave an incorrect result.

@j2kun @asraa Thank you for the pointers and explanations!
Before I start writing verifiers, I believe it's essential to establish the specification of the operations.
Based on this issue and this conversation, it's challenging to determine which inputs are valid for each operation of the HE schemes. For instance, should we reject cases where c1.dim != 2 in mult(c1, c2) and rotate(c1)?
One viable option is to follow the lead of existing libraries.
For rotations, to the best of my knowledge, SEAL, OpenFHE, and Lattigo all prohibit the case where c.dim != 2. Would it be acceptable to create a verifier based on these criteria?

I think prohibiting c.dim != 2 is acceptable. And generally speaking, my philosophy of software design is that it's better to start with a strict definition and relax it or generalize it only once you have a good reason to.

Thanks again @Maokami! Please let me know if there is any other topic you want to work on in the project. I'm happy to help.


EO Bands recommendations / clarifications

I'm working on updating examples, and also working on adding eo:bands to Planet data.
But I'm unsure on the recommendations / best practices, and I think we should improve the text to be a little more clear on how you apply things (in some combination of the extension itself and/or in best practices).

Should I include the full bands in the properties object?
Should I also include the full bands object in each asset?
If I just have one asset (like an rgb or bgrn), should I just have the same band object in both places?
We say: 'their primary use now is only to advertise a set of bands that may be available in some of the Assets in this Item'  Does this mean having it in the properties imply that the asset uses the same? How can you know if an asset is using that band order? Like is there an assumption that if 'bands' isn't specified in an object it is defined by the property level bands? If this is true that probably means we need to force people to be explicit on bands in like UDM / QA - but I'm not sure if our band object is rich enough to describe that?
Is band order implied? Like if I put bands in a certain order does that mean that the asset's bands are of that order? (I think yes, since it's a list, but I think we should be clear about it, and want to confirm that is our intent)
What is 'name' vs 'common name'? When should I use name? What should I put there? We say: e.g., "B01", "B8", "band2", "red". Why would I use 'red', when that's the common name? Why would I call it b01 vs b8 vs band2 (I'm coming from Planet, where we don't have a strong definition of this)

I think most of these probably have a straightforward answer that we just need to clarify. But the crux I think is 'what is the purpose of eo:bands' in properties, vs in an asset. When would I do one or the other? And if I define in properties is that actually meaningful information about the assets?
It seems like at the very least it may make sense to give assets some way to say 'I'm using the band information as defined at the property level'. To differentiate from 'band objects don't really make sense for this asset'.
I'm happy to update the spec once we reach a good answer on this.

We've been quite active creating STAC items out of several EO missions and we often run into that question as well.
There's one case where eo:bands definitely have to exist at Asset level:

an XS geotiff with multiple bands
a pan geotiff
My two cents to your questions:

Not really. If it's available in the Assets, that is fine and IMHO more useful
Yes, there's one case (among others) where eo:bands definitely have to exist at Asset level:

an XS geotiff with multiple bands
a pan geotiff

I'd be happy with enforcing people to be explicit on bands. As EO processing services developers, this is where we look for the information for using the assets correctly
We do rely on the band order. I don't see another way of being sure to have the right asset
As EO processing services developers, we always check the "common name" since the name is not a controlled dictionary. We often use name=common name but that's just to ease things.

Hope that helps

We've been quite active creating STAC items out of several EO missions and we often run into that question as well.
There's one case where eo:bands definitely have to exist at Asset level:

an XS geotiff with multiple bands
a pan geotiff
My two cents to your questions:

Not really. If it's available in the Assets, that is fine and IMHO more useful
Yes, there's one case (among others) where eo:bands definitely have to exist at Asset level:

an XS geotiff with multiple bands
a pan geotiff

I'd be happy with enforcing people to be explicit on bands. As EO processing services developers, this is where we look for the information for using the assets correctly
We do rely on the band order. I don't see another way of being sure to have the right asset
As EO processing services developers, we always check the "common name" since the name is not a controlled dictionary. We often use name=common name but that's just to ease things.

Hope that helps

@fabricebrito - thanks for sounding in!
I've been thinking about this last night, and I feel like we just need to tighten the spec up a bit. Right now I feel like we're conflating two slightly different things, without providing clear guidance. 1) Inform about the bands that this item / scene has, and 2) describe the bands and band order in each asset.
I think you and @matthewhanson have been focused on 2), and I think it's the 'more' useful thing - indeed I know many cases where eo:bands has to exist at the asset level (and less where it really has to at the properties level). But the extension right now is ambiguous as to the use cases it solves. I could see us just saying 'eo bands belongs at the asset level' - it precisely describes the bands of actual assets.
I think the only thing that doesn't really work with that is that 'summaries' potentially get a bit weird. They are the other useful bit for eo bands - you can look at the collection and it will tell you what bands this collection has. I guess for the 'collection only' use case (no items) it's fine - you can have a summary of bands. It just feels a bit weird to have the summary of a real collection of items not actually be a summary of the properties, but some implied roll-up of the bands that are used in the assets.
We could explicitly say 'eo bands at the property level is just informative', and that asset level is where it 'matters'. But that does feel like it'd often be duplicative.
The other idea that would make sense to me would be to bring back the eo:bands reference array. Like in 0.9 and before you could say "eo:bands": [0] in the asset, referring to the index of the array of the bands object in properties. That used to often be in a 'merging' paradigm - I think we'd not bring the merging back - each item would need to list its full eo:bands object, but it wouldn't need to replicate it every asset. Going this route would help me in some of my assets - as Planet tends to have 5-8 assets that are all 3 or 4 band data, so it'd a lot of replicating the same band info in each asset.
Sorry for the long message, just trying to think through all this together. I see two main options:

Require eo bands at the asset level, as they are more useful there, to decrease the confusion as to where they put them and what exactly the property level implies for the assets. Only issue is it 'feels' a bit weird with summaries.
Require eo bands at the property level, and bring back the asset reference array.

Thoughts from others? I'm sure there's other ideas than those two options, but those seem the best to me, and would give me a clear path of what to do.

@fabricebrito - thanks for sounding in!
I've been thinking about this last night, and I feel like we just need to tighten the spec up a bit. Right now I feel like we're conflating two slightly different things, without providing clear guidance. 1) Inform about the bands that this item / scene has, and 2) describe the bands and band order in each asset.
I think you and @matthewhanson have been focused on 2), and I think it's the 'more' useful thing - indeed I know many cases where eo:bands has to exist at the asset level (and less where it really has to at the properties level). But the extension right now is ambiguous as to the use cases it solves. I could see us just saying 'eo bands belongs at the asset level' - it precisely describes the bands of actual assets.
I think the only thing that doesn't really work with that is that 'summaries' potentially get a bit weird. They are the other useful bit for eo bands - you can look at the collection and it will tell you what bands this collection has. I guess for the 'collection only' use case (no items) it's fine - you can have a summary of bands. It just feels a bit weird to have the summary of a real collection of items not actually be a summary of the properties, but some implied roll-up of the bands that are used in the assets.
We could explicitly say 'eo bands at the property level is just informative', and that asset level is where it 'matters'. But that does feel like it'd often be duplicative.
The other idea that would make sense to me would be to bring back the eo:bands reference array. Like in 0.9 and before you could say "eo:bands": [0] in the asset, referring to the index of the array of the bands object in properties. That used to often be in a 'merging' paradigm - I think we'd not bring the merging back - each item would need to list its full eo:bands object, but it wouldn't need to replicate it every asset. Going this route would help me in some of my assets - as Planet tends to have 5-8 assets that are all 3 or 4 band data, so it'd a lot of replicating the same band info in each asset.
Sorry for the long message, just trying to think through all this together. I see two main options:

Require eo bands at the asset level, as they are more useful there, to decrease the confusion as to where they put them and what exactly the property level implies for the assets. Only issue is it 'feels' a bit weird with summaries.
Require eo bands at the property level, and bring back the asset reference array.

Thoughts from others? I'm sure there's other ideas than those two options, but those seem the best to me, and would give me a clear path of what to do.

Is band order implied?

I thought this was already implied by the spec but I agree since it's a list the order of eo:bands should definitely match the order of the bands within the asset.

What is 'name' vs 'common name'?

To me 'name' just refers to "any user-friendly name", whereas 'common name' gives band information in a much more developer-friendly way than parsing the center_wavelength and full_width_half_max manually.

eo:bands reference array

I'm not opposed to the idea of a reference array. To me, it's not hard to check if the value is an integer, and if it is, grab its index from the item-level eo:bands object. Python pseudocode:
item_bands = item['properties']['eo:bands']
asset_bands = item['assets'][asset_name]['eo:bands']
new_bands = []
for band in asset_bands:
	if type(band) == int:
		new_bands.append(item_bands[band])
	else:
		new_bands.append(band)

# use new_bands

in a 'merging' paradigm

I don't quite understand what the merging support was, but I agree it doesn't sound necessary.

each item would need to list its full eo:bands object

That would just be eo:bands: [2, 3, 4]? That's so tiny I don't know why not to put that on every asset.

Is band order implied?

I thought this was already implied by the spec but I agree since it's a list the order of eo:bands should definitely match the order of the bands within the asset.

What is 'name' vs 'common name'?

To me 'name' just refers to "any user-friendly name", whereas 'common name' gives band information in a much more developer-friendly way than parsing the center_wavelength and full_width_half_max manually.

eo:bands reference array

I'm not opposed to the idea of a reference array. To me, it's not hard to check if the value is an integer, and if it is, grab its index from the item-level eo:bands object. Python pseudocode:
item_bands = item['properties']['eo:bands']
asset_bands = item['assets'][asset_name]['eo:bands']
new_bands = []
for band in asset_bands:
	if type(band) == int:
		new_bands.append(item_bands[band])
	else:
		new_bands.append(band)

# use new_bands

in a 'merging' paradigm

I don't quite understand what the merging support was, but I agree it doesn't sound necessary.

each item would need to list its full eo:bands object

That would just be eo:bands: [2, 3, 4]? That's so tiny I don't know why not to put that on every asset.

Is band order implied?
I thought this was already implied by the spec but I agree since it's a list the order of eo:bands should definitely match the order of the bands within the asset.

Yeah, I just want to make it explicit in the spec, and was asking to confirm.

To me 'name' just refers to "any user-friendly name", whereas 'common name' gives band information in a much more developer-friendly way than parsing the center_wavelength and full_width_half_max manually.

Makes sense, it's like the 'title' - the thing that would be displayed in the UI? I can add a bit more language on the spec. Though hrm, if that's what it's for maybe we just use 'title', since that's what it is everywhere else in the spec.

each item would need to list its full eo:bands object

That would just be eo:bands: [2, 3, 4]? That's so tiny I don't know why not to put that on every asset.

Sorry, I wasn't clear here. I was meaning if we didn't use the array thing then you'd need to list the full bands object each time. The array thing was the idea for the smaller thing that is much more reasonable to put on every asset. I agree the requirement if we went this route would be for each asset that has an eo band use the eo band reference object.

Is band order implied?
I thought this was already implied by the spec but I agree since it's a list the order of eo:bands should definitely match the order of the bands within the asset.

Yeah, I just want to make it explicit in the spec, and was asking to confirm.

To me 'name' just refers to "any user-friendly name", whereas 'common name' gives band information in a much more developer-friendly way than parsing the center_wavelength and full_width_half_max manually.

Makes sense, it's like the 'title' - the thing that would be displayed in the UI? I can add a bit more language on the spec. Though hrm, if that's what it's for maybe we just use 'title', since that's what it is everywhere else in the spec.

each item would need to list its full eo:bands object

That would just be eo:bands: [2, 3, 4]? That's so tiny I don't know why not to put that on every asset.

Sorry, I wasn't clear here. I was meaning if we didn't use the array thing then you'd need to list the full bands object each time. The array thing was the idea for the smaller thing that is much more reasonable to put on every asset. I agree the requirement if we went this route would be for each asset that has an eo band use the eo band reference object.

Yes, band order was meant to be implied. As name is not required (e.g. for hyperspectral), the order is actually important as otherwise you would have no clue at all.
We removed the band "indexes" due to the fact that it was error prone and (without software) easy to understand. We also found that duplication is not that big of a deal with assets that are often 1GB+, while the STAC item is just some kilobytes.
I don't think we had any merging in tooling. Most tooling did (mostly?) ignore eo:bands in assets, I think.
Common name is - as said - an easy way to get the right band in an interoperable way without needing to check wavelengths, proprietary band names etc. For us a very important aspect!
I'm pretty happy with how it works at the moment, but it likely needs better descriptions. eo:bands in properties if bands are the same across data assets. eo:bands in assets if bands are different across assets. (All per item) You can still duplicate in properties if you want to give an overview as the properties basically get "overruled" by the asset entries.

Yes, band order was meant to be implied. As name is not required (e.g. for hyperspectral), the order is actually important as otherwise you would have no clue at all.
We removed the band "indexes" due to the fact that it was error prone and (without software) easy to understand. We also found that duplication is not that big of a deal with assets that are often 1GB+, while the STAC item is just some kilobytes.
I don't think we had any merging in tooling. Most tooling did (mostly?) ignore eo:bands in assets, I think.
Common name is - as said - an easy way to get the right band in an interoperable way without needing to check wavelengths, proprietary band names etc. For us a very important aspect!
I'm pretty happy with how it works at the moment, but it likely needs better descriptions. eo:bands in properties if bands are the same across data assets. eo:bands in assets if bands are different across assets. (All per item) You can still duplicate in properties if you want to give an overview as the properties basically get "overruled" by the asset entries.

Yes, band order was meant to be implied. As name is not required (e.g. for hyperspectral), the order is actually important as otherwise you would have no clue at all.

Cool, I'll work to clarify the spec.

Common name is - as said - an easy way to get the right band in an interoperable way without needing to check wavelengths, proprietary band names etc. For us a very important aspect!

Yeah, common name I get is super important. I question the value of 'name', that is similar but used 'however'? What do you think about calling it 'title'? Or does it serve other purposes than just display?

I'm pretty happy with how it works at the moment, but it likely needs better descriptions. eo:bands in properties if bands are the same across data assets. eo:bands in assets if bands are different across assets. (All per item) You can still duplicate in properties if you want to give an overview as the properties basically get "overruled" by the asset entries.

Ok, I think this explanation is the key thing that I was missing, as it wasn't in the spec at all. I think if we just make this clear then it can be ok - I don't need to push for the indexes. Let me try to summarize in my own words:

eo:bands in properties is the 'default' bands. If your assets all have the same bands just use this.
if your bands across assets are different then just put eo:bands in assets. (recommendation to leave them off the properties?)
If there is bands in properties and bands in an asset then the asset 'overrules' - clients should use the asset.

I think I like this, and it mostly works for me - the spec itself does not yet make clear the 'overruled'/default stuff. My use case is 5 assets with bgrn, 1 with rgb and 1 UDM ('qa') band. So it sounds like I can set bgrn in properties, and then it's the default for my 5 assets. My 1 rgb asset I should have a bands object with the proper order.
I think the one question I have is with the UDM geotiff. It has 1 band, that is not bgrn. It seems like in the current scheme a client would reasonably assume on opening that geotiff that it uses the 'default' band order (bgrn in my case). And we don't have a 'QA' band (perhaps we should). But even if we had that particular QA band what if I have a geotiff of like land classification from ML in 3 'bands' (that aren't based on physical properties).
It feels like we need a way to explicitly say 'I use the bands as described in properties'. Or else clients wouldn't know if a particular asset reflects that, or is just some other geotiff, or even something else entirely. Like how do you actually know that 'bands' applies to the asset. The 'index' would do this, but I get that it's overly complicated and duplication doesn't really matter. But it seems like just eo:bands=true or something at the asset level to indicate 'yes this asset is multiband data that is described by the 'default'.
If this isn't clear let me know and I can prep some explicit examples and we can discuss on monday.

Yes, band order was meant to be implied. As name is not required (e.g. for hyperspectral), the order is actually important as otherwise you would have no clue at all.

Cool, I'll work to clarify the spec.

Common name is - as said - an easy way to get the right band in an interoperable way without needing to check wavelengths, proprietary band names etc. For us a very important aspect!

Yeah, common name I get is super important. I question the value of 'name', that is similar but used 'however'? What do you think about calling it 'title'? Or does it serve other purposes than just display?

I'm pretty happy with how it works at the moment, but it likely needs better descriptions. eo:bands in properties if bands are the same across data assets. eo:bands in assets if bands are different across assets. (All per item) You can still duplicate in properties if you want to give an overview as the properties basically get "overruled" by the asset entries.

Ok, I think this explanation is the key thing that I was missing, as it wasn't in the spec at all. I think if we just make this clear then it can be ok - I don't need to push for the indexes. Let me try to summarize in my own words:

eo:bands in properties is the 'default' bands. If your assets all have the same bands just use this.
if your bands across assets are different then just put eo:bands in assets. (recommendation to leave them off the properties?)
If there is bands in properties and bands in an asset then the asset 'overrules' - clients should use the asset.

I think I like this, and it mostly works for me - the spec itself does not yet make clear the 'overruled'/default stuff. My use case is 5 assets with bgrn, 1 with rgb and 1 UDM ('qa') band. So it sounds like I can set bgrn in properties, and then it's the default for my 5 assets. My 1 rgb asset I should have a bands object with the proper order.
I think the one question I have is with the UDM geotiff. It has 1 band, that is not bgrn. It seems like in the current scheme a client would reasonably assume on opening that geotiff that it uses the 'default' band order (bgrn in my case). And we don't have a 'QA' band (perhaps we should). But even if we had that particular QA band what if I have a geotiff of like land classification from ML in 3 'bands' (that aren't based on physical properties).
It feels like we need a way to explicitly say 'I use the bands as described in properties'. Or else clients wouldn't know if a particular asset reflects that, or is just some other geotiff, or even something else entirely. Like how do you actually know that 'bands' applies to the asset. The 'index' would do this, but I get that it's overly complicated and duplication doesn't really matter. But it seems like just eo:bands=true or something at the asset level to indicate 'yes this asset is multiband data that is described by the 'default'.
If this isn't clear let me know and I can prep some explicit examples and we can discuss on monday.

I think I like this, and it mostly works for me - the spec itself does not yet make clear the 'overruled'/default stuff. My use case is 5 assets with bgrn, 1 with rgb and 1 UDM ('qa') band. So it sounds like I can set bgrn in properties, and then it's the default for my 5 assets. My 1 rgb asset I should have a bands object with the proper order.

One question with this: what happens if one of the assets has "unknown" bands? Then bands set Item-wide would need to be overruled to be "null". The asset could have an empty "eo:bands": [], but that could be interpreted as that asset having 0 bands? (Though that doesn't really make sense).

I think I like this, and it mostly works for me - the spec itself does not yet make clear the 'overruled'/default stuff. My use case is 5 assets with bgrn, 1 with rgb and 1 UDM ('qa') band. So it sounds like I can set bgrn in properties, and then it's the default for my 5 assets. My 1 rgb asset I should have a bands object with the proper order.

One question with this: what happens if one of the assets has "unknown" bands? Then bands set Item-wide would need to be overruled to be "null". The asset could have an empty "eo:bands": [], but that could be interpreted as that asset having 0 bands? (Though that doesn't really make sense).

Yeah, common name I get is super important. I question the value of 'name', that is similar but used 'however'? What do you think about calling it 'title'? Or does it serve other purposes than just display?

It's similar and we've discussed this before. Title is misleading as it's something human-readable usually ("Sentinel-10 launched"), but name (or maybe id) is better as it is more an identifier ("B01_NDVI"). I guess we also had a reason not to take id, but can't remember clearly. Anyway, this feels like bike-shedding and I wouldn't break things just for a name change here. I mean it's the name for the (provider-specific) band and common_name is commonly used name.

* eo:bands in properties is the 'default' bands. If your assets all have the same bands just use this.

* if your bands across assets are different then just put eo:bands in assets. (recommendation to leave them off the properties?)

* If there is bands in properties and bands in an asset then the asset 'overrules' - clients should use the asset.

To be clear: That is my just understanding and what I remember from the discussions. I'm not sure whether that is what we actually agreed on. Especially the overruling thing I'm not sure about.

My use case is 5 assets with bgrn, 1 with rgb and 1 UDM ('qa') band. So it sounds like I can set bgrn in properties, and then it's the default for my 5 assets. My 1 rgb asset I should have a bands object with the proper order.

Sounds right, although I'm not sure we actually decided on the overruling or whether we agreed on just put all bands into assets in this case and don't specify in properties. @matthewhanson can you remember? Or did we actually agree that in properties you have the union of all unique bands and the order doesn't matter in this case? I think I remember something like that now...

One question with this: what happens if one of the assets has "unknown" bands? Then bands set Item-wide would need to be overruled to be "null".

I'd say don't use item-wide bands in this case. But as said above, not sure about the overruling thing. Maybe it was actually the case that we agreed on that eo:bands in properties is always just a summary of the bands in the assets. Let's wait for @matthewhanson to sound in, maybe he can remember better. But the longer I'm thinking about it, the more I think it was the summary thing.
Then Chris' summary would be:

eo:bands in properties (optionally) specifies the union of all bands available in assets as a set (i.e. unique values). If your assets all have the same bands just use this. No need to repeat in assets it applies to all if no asset has eo:bands.
if your bands across assets are different then just put eo:bands in assets and summarize in properties.

Yeah, common name I get is super important. I question the value of 'name', that is similar but used 'however'? What do you think about calling it 'title'? Or does it serve other purposes than just display?

It's similar and we've discussed this before. Title is misleading as it's something human-readable usually ("Sentinel-10 launched"), but name (or maybe id) is better as it is more an identifier ("B01_NDVI"). I guess we also had a reason not to take id, but can't remember clearly. Anyway, this feels like bike-shedding and I wouldn't break things just for a name change here. I mean it's the name for the (provider-specific) band and common_name is commonly used name.

* eo:bands in properties is the 'default' bands. If your assets all have the same bands just use this.

* if your bands across assets are different then just put eo:bands in assets. (recommendation to leave them off the properties?)

* If there is bands in properties and bands in an asset then the asset 'overrules' - clients should use the asset.

To be clear: That is my just understanding and what I remember from the discussions. I'm not sure whether that is what we actually agreed on. Especially the overruling thing I'm not sure about.

My use case is 5 assets with bgrn, 1 with rgb and 1 UDM ('qa') band. So it sounds like I can set bgrn in properties, and then it's the default for my 5 assets. My 1 rgb asset I should have a bands object with the proper order.

Sounds right, although I'm not sure we actually decided on the overruling or whether we agreed on just put all bands into assets in this case and don't specify in properties. @matthewhanson can you remember? Or did we actually agree that in properties you have the union of all unique bands and the order doesn't matter in this case? I think I remember something like that now...

One question with this: what happens if one of the assets has "unknown" bands? Then bands set Item-wide would need to be overruled to be "null".

I'd say don't use item-wide bands in this case. But as said above, not sure about the overruling thing. Maybe it was actually the case that we agreed on that eo:bands in properties is always just a summary of the bands in the assets. Let's wait for @matthewhanson to sound in, maybe he can remember better. But the longer I'm thinking about it, the more I think it was the summary thing.
Then Chris' summary would be:

eo:bands in properties (optionally) specifies the union of all bands available in assets as a set (i.e. unique values). If your assets all have the same bands just use this. No need to repeat in assets it applies to all if no asset has eo:bands.
if your bands across assets are different then just put eo:bands in assets and summarize in properties.

Yeah, common name I get is super important. I question the value of 'name', that is similar but used 'however'? What do you think about calling it 'title'? Or does it serve other purposes than just display?

It's similar and we've discussed this before. Title is misleading as it's something human-readable usually ("Sentinel-10 launched"), but name (or maybe id) is better as it is more an identifier ("B01_NDVI"). I guess we also had a reason not to take id, but can't remember clearly. Anyway, this feels like bike-shedding and I wouldn't break things just for a name change here. I mean it's the name for the (provider-specific) band and common_name is commonly used name.

Cool, sorry for rehashing, that explanation makes sense. But I think we need to get better at explaining what we actually decided in the text. We just say The name of the band (e.g., "B01", "B02", "B1", "B5", "QA"). No guidance as to what this is for, that's why I brought it up (and is what leads to bike-shedding). I can't say I'm clear enough on what it is actually for with this explanation. It's like an id? It's what the provider names the band? In this case I'm the provider and we don't have strong 'names' for our bands, so I'm still not sure what I should put here, and how it will be used. Should I just not use it if the 'common_name' works for me?

To be clear: That is my just understanding and what I remember from the discussions. I'm not sure whether that is what we actually agreed on. Especially the overruling thing I'm not sure about.

Cool, let's talk on monday. The overruling makes sense to me, but there was nothing in the spec clarifying either way. The union of unique bands makes some sense too. With my planet provider hat on the former is a bit better for me, but I think either is probably fine.

Yeah, common name I get is super important. I question the value of 'name', that is similar but used 'however'? What do you think about calling it 'title'? Or does it serve other purposes than just display?

It's similar and we've discussed this before. Title is misleading as it's something human-readable usually ("Sentinel-10 launched"), but name (or maybe id) is better as it is more an identifier ("B01_NDVI"). I guess we also had a reason not to take id, but can't remember clearly. Anyway, this feels like bike-shedding and I wouldn't break things just for a name change here. I mean it's the name for the (provider-specific) band and common_name is commonly used name.

Cool, sorry for rehashing, that explanation makes sense. But I think we need to get better at explaining what we actually decided in the text. We just say The name of the band (e.g., "B01", "B02", "B1", "B5", "QA"). No guidance as to what this is for, that's why I brought it up (and is what leads to bike-shedding). I can't say I'm clear enough on what it is actually for with this explanation. It's like an id? It's what the provider names the band? In this case I'm the provider and we don't have strong 'names' for our bands, so I'm still not sure what I should put here, and how it will be used. Should I just not use it if the 'common_name' works for me?

To be clear: That is my just understanding and what I remember from the discussions. I'm not sure whether that is what we actually agreed on. Especially the overruling thing I'm not sure about.

Cool, let's talk on monday. The overruling makes sense to me, but there was nothing in the spec clarifying either way. The union of unique bands makes some sense too. With my planet provider hat on the former is a bit better for me, but I think either is probably fine.

Ok, I think we reached consensus on this. Summary is:

If you are using eo:bands then you must have at least one at the asset level.
eo:bands used in properties should be considered a 'summary' of what is in the assets. It should be the 'union' of all possible bands in assets.
Thus you should not use eo:bands in properties unless there is at least one asset that has it.
The 'name' field can be thought of as an optional 'id' - if the same band is represented more than once in multiple assets then they should all use the same 'name' (along with the rest of the fields). It is also what clients are recommended to display when representing a particular band.

So there is no over-ruling / default - everything must be explicitly set in an asset. There will be duplication in Items that have multiple assets with the same band order, and that is ok, as the size of the file is small, and as the ecosystem evolves most people should view using tools instead of reading json directly.