intel_adsp_cavs25: tests/kernel/timer/timer_behavior/kernel.timer.timer FAILED Timeout

Describe the bug*
The tests/kernel/timer/timer_behavior/kernel.timer.timer fails.
INFO    - 2329/2454 intel_adsp_cavs25         tests/kernel/timer/timer_behavior/kernel.timer.timer  FAILED Timeout (device: tgl, 60.528s)
INFO    - <path_to>/twister-out/intel_adsp_cavs25/tests/kernel/timer/timer_behavior/kernel.timer.timer/handler.log

To Reproduce
Steps to reproduce the behavior:
scripts/twister -W -p intel_adsp_cavs25 --device-testing --hardware-map <path_to>/cavs/cavs.map -T tests/kernel/timer/timer_behavior/kernel.timer.timer -v

Logs and console output
<path_to>/twister-out/intel_adsp_cavs25/tests/kernel/timer/timer_behavior/kernel.timer.timer/handler.log
INFO:cavs-client:REMOTE HOST: <host> PORT: <port>
INFO:cavs-client:Monitor process
INFO:cavs-client:Sent:     start_log
INFO:cavs-client:Receive: start_log
INFO:cavs-client:Start to monitor log output...

Environment:

OS: Linux
Commit SHA or Version used: zephyr-v3.5.0-4625-g114548ef607a

Can't reproduce, the logs above show that the test did not run at all, so there most be something with loading the test into the device.
EBUG   - DEVICE: INFO:cavs-client:REMOTE HOST: admin-fmos.hf.intel.com PORT: 59142
DEBUG   - DEVICE: INFO:cavs-client:Monitor process
DEBUG   - DEVICE: INFO:cavs-client:Sent:     start_log
DEBUG   - DEVICE: INFO:cavs-client:Receive: start_log
DEBUG   - DEVICE: INFO:cavs-client:Start to monitor log output...
DEBUG   - -- west flash: using runner intel_adsp
-- runners.intel_adsp: Starting Intel ADSP runner

DEBUG   - DEVICE: --
DEBUG   - DEVICE: *** Booting Zephyr OS build zephyr-v3.5.0-4677-g4ce0555d90a2 ***
DEBUG   - DEVICE: Running TESTSUITE timer_jitter_drift
DEBUG   - DEVICE: ===================================================================
DEBUG   - DEVICE: START - test_jitter_drift_timer_period
DEBUG   - DEVICE: periodic timer behavior test using built-in restart mechanism
DEBUG   - DEVICE: collecting time samples for approx 10 seconds
DEBUG   - DEVICE: periodic timer samples gathered, calculating statistics
DEBUG   - DEVICE: timer clock rate 38400000, kernel tick rate 50000
DEBUG   - DEVICE: period duration statistics for 10000 samples (0 rollovers):
DEBUG   - DEVICE: expected: 1000 us,       	38400.000000 cycles


Support more data types and fix a operator error for hudi table

What type of PR is this：

[x] bug
[ ] feature
[ ] enhancement
[ ] others

remove useless codes in HiveTable
fix a rule transform exception of hudi operator in some code path due to typo
support datetime and binary data type

run starrocks_fe_unittest

[FE PR Coverage check]
:disappointed: fail : 1 / 5 (20.00%)
file detail

path
covered line
new line
coverage

:large_blue_circle:
com/starrocks/sql/optimizer/operator/physical/PhysicalHudiScanOperator.java
0
1
00.00%

:large_blue_circle:
com/starrocks/sql/optimizer/operator/logical/LogicalHudiScanOperator.java
0
1
00.00%

:large_blue_circle:
com/starrocks/catalog/HudiTable.java
1
3
33.33%


Missing international characters in the bundled font

For this adoc file I get my national letters stripped out of my name, because:
"Asciidoctor PDF uses custom fonts. When I created the font files that are bundled in the gem, I did not include all international characters in the font (something I've been meaning to fix)." (see issue #69 )
= Hello World
Michał Kołodziejczyk<EMAIL_ADDRESS>1.0.0, 2014-12-10

Hello world!

I see the international characters working with Asciidoctor PDF

It's highly dependent on which characters. When I produced the current Noto
Serif fonts, I included a broad range of characters, but not Cyrillic and
the CJK characters are not part of that font. That's the change that's
being requested.

Got it. Noto is a custom font? I see two options. I'm happy to help with extending the font with Easter European - if possible.
Or a way to configure some other (less pretty fonts) - for the time being.

I subsetted the font to make the gem smaller because at the time we had
lots of different fonts. Now we have room to include the full font, so it's
just a matter of swapping it in. I'll better document those steps when I do
so it's clear what the situation is.

:+1:

I want to clarify that we still have to process the font because Prawn
requires that we rewrite the kerning information to a separate table in the
font.

@goeh Actually this is slightly different because you're pointing out missing characters in the code font. This is separate from the body font. I intentionally subsetted the code font to only include ASCII to keep the size of the gem down. While the fallback font will catch these now, we still may want to reconsider that decision as code can have non-ASCII characters (comments, strings, etc). Let's tackle that in a separate issue.

@goeh You will no longer be missing characters in monospaced text, but those characters will be coming from the fallback font atm.

With the proposed pull request (#281), I think we're in a much better position to support a broad range of languages out of the box. We now include Cyrillic (for Russian, etc), Vietnamese characters and Latin Extended-A (for Polish, Czech, Turkish, etc) in the subsetted Noto Serif font. There really isn't much we are leaving out that the main Noto Serif font doesn't provide. The fallback font will catch Japanese characters as well as missing glyphs in literal text.
The only glaring void that remains is Chinese because we aren't yet bundling a font that has offers a complete set of glyphs (only those used in Japanese too). I think the right solution for that problem is a separate gem, which has already been setup.
Of course, we simply can't cover all languages with a single font...which is why I think the right long-term solution is to have gems for each language group that isn't covered by the fonts shipped in Asciidoctor PDF core.

I'm going to document somewhere under docs the character ranges that are included in the bundled fonts. I'll also document why we subset / regenerate the fonts and how to do it for your own font.


Web links not suport with port numbers

Microsoft PowerToys version
0.33.1 0.49.1 =<
Running as admin

[ ] Yes

Area(s) with issue?
PowerToys Run
Steps to reproduce
https://imgur.com/a/Xq5ODCi/
✔ Expected Behavior
Link's Opening with default web browser
❌ Actual Behavior
it asks which application to open
Other Software
No response

When you click your link, https://imgur.com/a/Xq5ODCi, it redirects to: https://github.com/microsoft/PowerToys/issues/url instead of the actual image.

if you do foo.com:80 it throws up an "find app" dialog.
Wonder if this is a Win11 regression, thought this worked

verified with 0.49.1

@crutkas In this case, I believe Windows think the foo.com is the application scheme and the 80 is the address (parameters to the application). I think this will be hard to fix after the supports of the application URI is fixed.

why not showing two results in this case? One for browser and one for app?

Still happening with PT 0.58.0

I'm currently trying to figure out this issue.
It seems to be a problem with UrlBuilder (or maybe it's a feature?). For anything that is formatted in URL:port, URLBuilder treats the URL part as schema, and the port part as the path/host.

This could be resolved with a few more checks, but is this a correct fix?

Linking https://github.com/dotnet/runtime/issues/73521 as the issue raised with the dotnet team

@crutkas @jaimecbernardo considering on the UriBuilder side, they confirmed this is intended behaviour, do we just assume otherwise for this use case?


[KBM] Allow repeated modifiers

📝[Keyboard Manager] Allow repeated modifiers

What is the expected behavior of the proposed feature?  What is the scenario this would be used?
Seeing as Alt is the easiest modifier key to press, I was hoping to add an extend layer on LeftAlt + RightAlt + Key (e.g. LAlt + RAlt + U => PgUp)
To improve this even further, maybe allow any key to be used as a modifier (e.g. LAlt + Space + U => PgUp), or optimally even on its own (Tab + U => PgUp)?

Thank you for your hard work on PowerToys

If you'd like to see this feature implemented, add a 👍 reaction to this post.

I know that this is a dup. But I can't find the original issue.

I know that this is a dup. But I can't find the original issue.

I was surprised that nobody had requested it but I did try a search, to no avail

this may be possible but could cause some quirks.

I actually think this is multiple issues.  The first is allow Left and Right of the same key.  I think the second one is allow me to do a shortcut combo without a modifier.
correct?

Be aware that things like this may trip on dead keys or various other properties of keyboard layouts.

I actually think this is multiple issues. The first is allow Left and Right of the same key. I think the second one is allow me to do a shortcut combo without a modifier.
correct?

I wouldn't disagree with that - in fact, I added the first issue, then tried the second idea as a workaround only to discover that didn't work either so added it in an edit

I know that this is a dup. But I can't find the original issue.

I was surprised that nobody had requested it but I did try a search, to no avail

https://github.com/microsoft/PowerToys/issues/5722 some months before...

@jczanfona
this issue is for a different feature compared to what you asked in #5722

Hmmm... I kind of like the idea of a <modifier> (Left)+<modifier> (Right)+<key> option for keyboard shortcuts.  The Keyboard Manager PowerToy can already distinguish between left and right modifier keys, so you can set one thing to Alt (Left)+<key> and something else to Alt (Right)+<key>, but it may not always be easy to remember which Alt key to press for which function.  Anyway, I don't know how easy/difficult it would be, but being able to add four whole new layers of potential for key customization with double Alt, double Ctrl, double Win and double Shift would be awesome, especially since I'm not aware of any existing software that uses this approach, so this would be a great way to avoid choosing key combos that are already expected to do something else.
Also, the second suggestion in the OP, shortcuts using all non-modifier keys would be the same as #17555, which was incorrectly closed as a duplicate of a request for... basically the exact opposite idea, shortcuts using only modifier keys.


Fix full-refresh and vars for retry

resolves #9327 and #9112
This patch restructures retry so that it resolves all flags and config first, then does the parsing and execution.
It also changes to only load the last run results since that's the only thing needed for retry.

https://github.com/dbt-labs/dbt-core/pull/9391


Possible Memory Leak ?

If it possible that the kafka.consumer.ZookeeperConsumerConnector watcher executor thread is started but not stopped ?
It get following in my log:
[frontend] INFO    2015-01-06 01:16:14,504 [default_XXXXXX-1420503374061-2286bb4a_watcher_executor] kafka.consumer.ZookeeperConsumerConnector   - [default_XXXXX-1420503374061-2286bb4a], starting watcher executor thread for consumer default_XXXXXX-1420503374061-2286bb4a

And if i shutdown my tomcat 8:
Exception in thread "default_XXXXXX-1420503374061-2286bb4a_watcher_executor" java.lang.IllegalStateException: Can't overwrite cause with java.lang.IllegalStateException: Illegal access: this web application instance has been stopped already.  Could not load kafka.consumer.ZookeeperConsumerConnector$ZKRebalancerListener$$anon$1$$anonfun$run$4.  The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
	at java.lang.Throwable.initCause(Throwable.java:457)
	at org.apache.catalina.loader.WebappClassLoaderBase.checkStateForClassLoading(WebappClassLoaderBase.java:1306)
	at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1186)
	at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1147)
	at kafka.consumer.ZookeeperConsumerConnector$ZKRebalancerListener$$anon$1.run(ZookeeperConsumerConnector.scala:360)
Caused by: java.lang.ClassNotFoundException
	at org.apache.catalina.loader.WebappClassLoaderBase.checkStateForClassLoading(WebappClassLoaderBase.java:1305)
	... 3 more

I use the Milestone 2 from the Maven Repo
Thanks

This happens, if i connect to a kafka topic, which one is not available.

Hi @marcelalburg !
Looking to the Kafka source code we have: https://github.com/apache/kafka/blob/0.8.1/core/src/main/scala/kafka/consumer/ZookeeperConsumerConnector.scala#L339
where that internal Thread relies on the isShuttingDown state, which is changed from the shutdown() to die.
The Spring Integration Kafka does something like this:
KafkaConsumerContext.destroy() -> ConsumerConfiguration.getConsumerConnector().shutdown() -> ZookeeperConsumerConnector.shutdown().
Since KafkaConsumerContext is DisposableBean, its destroy() should be invoked on the ApplicationContex.close().
You can observe server logs for the message like this:

Invoking destroy() on bean with name ...

when you switch on DEBUG for the org.springframework.beans.factory.support category.
Of course, if you do that manually, you have to take care about that ZookeeperConsumerConnector.shutdown() yourself.
Let us know how it is for you now. I don't see any issues in the Framework code.

Hello,
thanks for the fast anwser.
i created an example project wich shows the error on my system.
https://github.com/marcelalburg/spring-integration-kafka-memory-leak
you can see the debug log in the Readme.md
Thanks

Thank you for such a comprehensive feedback!
What I see in your code:

The inputFromKafka is a DirectChannel without any subscriber for that. Just make it as a <queue> and we get rid off with some issues.
How does it work if you don't use task-executor="kafkaTaskExecutor" for the <poller>?
Whould you mind minimizing your app more (without MVC, Spring Session etc.) to localize the issue with SI Kafka adapters (if it is there, of course).

I need some time to build something similar with Spring Boot to see how does it work with Embedded Tomcat...

Hey,
i just copy some code lines to this example project and because of that, threre a some unnecessary lines of code.
But i changed the github repo and remove (hopefully) all unnecessary dependencies and code lines (but i connot remove the webmvc).
Thanks for your help.

No problem!
I've just composed some simple test-case with Spring Boot and I really see some issue on the stop:

15:30:00.693 WARN  [Thread-1][org.springframework.beans.factory.support.DisposableBeanAdapter] Invocation of destroy method failed on bean with name 'consumerContext': java.lang.ExceptionInInitializerError

Where the roo is:

java.lang.IllegalStateException: Shutdown in progress

Unfortunatelly I don't see more info in the logs, but when I inject KafkaConsumerContext to the test-method and destroy() it manually in the end, the Tomcat stops without any issues. Maybe it is really an issue with ClassLoader...
Investigation how to see more in the logs with Spring Boot...

What did you mean exactly? Because i try this too (take a look in https://github.com/marcelalburg/spring-integration-kafka-memory-leak/blob/master/src/main/java/org/example/kafkamemoryleak/listener/KafkaConsumerStarter.java#L38) but doesn't works for me - because of that i comment it out.

Well, after switching on logging.level.org.springframework=DEBUG I see this in logs:

15:37:27.033 WARN  [Thread-1][org.springframework.beans.factory.support.DisposableBeanAdapter] Invocation of destroy method failed on bean with name 'consumerContext'
java.lang.ExceptionInInitializerError
at kafka.metrics.KafkaMetricsGroup$class.newGauge(KafkaMetricsGroup.scala:43)
at kafka.server.AbstractFetcherManager.newGauge(AbstractFetcherManager.scala:29)
at kafka.server.AbstractFetcherManager.(AbstractFetcherManager.scala:36)
at kafka.consumer.ConsumerFetcherManager.(ConsumerFetcherManager.scala:40)
at kafka.consumer.ZookeeperConsumerConnector.createFetcher(ZookeeperConsumerConnector.scala:151)
at kafka.consumer.ZookeeperConsumerConnector.(ZookeeperConsumerConnector.scala:115)
at kafka.javaapi.consumer.ZookeeperConsumerConnector.(ZookeeperConsumerConnector.scala:65)
at kafka.javaapi.consumer.ZookeeperConsumerConnector.(ZookeeperConsumerConnector.scala:67)
at kafka.consumer.Consumer$.createJavaConsumerConnector(ConsumerConnector.scala:100)
at kafka.consumer.Consumer.createJavaConsumerConnector(ConsumerConnector.scala)
at org.springframework.integration.kafka.support.ConsumerConnectionProvider.getConsumerConnector(ConsumerConnectionProvider.java:34)
at org.springframework.integration.kafka.support.ConsumerConfiguration.getConsumerConnector(ConsumerConfiguration.java:220)
at org.springframework.integration.kafka.support.KafkaConsumerContext.destroy(KafkaConsumerContext.java:85)
at org.springframework.beans.factory.support.DisposableBeanAdapter.destroy(DisposableBeanAdapter.java:258)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroyBean(DefaultSingletonBeanRegistry.java:538)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingleton(DefaultSingletonBeanRegistry.java:514)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.destroySingleton(DefaultListableBeanFactory.java:831)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingletons(DefaultSingletonBeanRegistry.java:483)
at org.springframework.context.support.AbstractApplicationContext.destroyBeans(AbstractApplicationContext.java:923)
at org.springframework.context.support.AbstractApplicationContext.doClose(AbstractApplicationContext.java:897)
at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.doClose(EmbeddedWebApplicationContext.java:141)
at org.springframework.context.support.AbstractApplicationContext$1.run(AbstractApplicationContext.java:811)
Caused by: java.lang.IllegalStateException: Shutdown in progress
at java.lang.ApplicationShutdownHooks.add(ApplicationShutdownHooks.java:66)
at java.lang.Runtime.addShutdownHook(Runtime.java:211)
at com.yammer.metrics.Metrics.(Metrics.java:21)
... 22 more

But looks like it isn't related to your concern...
From other side does it make so much sence if you see that blocking Thread issue only on the Tomcat shutdown?

First, i like to develop without memory leaks ;) and at this time, i develop a new application and i've to start and stop the tomcat quite a lot ... and normaly, the tomcat shutdown takes half a second, but with the memory leak, it takes more than 10 seconds. it's not so nice.
Do you have an workaround ? That's ok for me .. for the developmenttime.

Would you mind sharing this in the Kakfa mailing list (http://kafka.apache.org/contact.html) to involve more people?
I was able to run some app in the standalong Tomcat 8 and see only this isue:

06-Jan-2015 18:09:00.128 WARNING [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [kafka_gh10-0.5.0] appears to have started a thread named [localhost-startStop-2-SendThread(localhost:2181)] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:
java.lang.Thread.sleep(Native Method)
org.apache.zookeeper.ClientCnxn$SendThread.cleanup(ClientCnxn.java:1261)
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1211)

From other side: share please an expiriance how to configure Tomcat to get more logs, like in your StackTrace shown above.
Thanks you!

Hello,
i just import this project into my eclipse and configure the deployment properties and run it on a local Tomcat (configured in Eclipse).
The default settings are the "verbose" logging.
I'll write an E-Mail to this list and link this email to this issuse.
Thanks

Well, thanks for more info. Now I can reproduce it with Tomcat Plugin from IDEA. But I don't see the same with the Embedded and Standalone one...

Hi, i get one answer from the list.

Please call shutdown on https://github.com/apache/kafka/blob/0.8.1/core/src/main/scala/kafka/javaapi/consumer/ConsumerConnector.java#L69 in cleanup method and also find out who is staring "kafkaTaskExecutor-1-SendThread" thread and interrupt or kill it in destroy method.  It does not look like a Kafka thread.  It seems to be your application thread problem.  Since, this is not a daemon thread (and from the executor thread pool).  I think your tomcat is not even shutting down gracefully.  Most likely, this is not a Kafka related bug.
Thanks,
Bhavesh
But i think, that you (spring-integration-kafka) is calling shutdown on the connector ....
Marcel

Merged to master

Hey,
i saw this patch and try it - the tomcat stops normal without the errors above. Great work.
Now i've just a small issue:
starting ...
[frontend] INFO    2015-01-08 22:30:44,529 [default_Marcels-MacBook-Pro.local-1420752644064-c4f47dde_watcher_executor] kafka.consumer.ZookeeperConsumerConnector   - [default_Marcels-MacBook-Pro.local-1420752644064-c4f47dde], starting watcher executor thread for consumer default_Marcels-MacBook-Pro.local-1420752644064-c4f47dde

stopping....

WARNUNG: The web application [adminfrontend] appears to have started a thread named [default_Marcels-MacBook-Pro.local-1420752644064-c4f47dde_watcher_executor] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:
 sun.misc.Unsafe.park(Native Method)
 java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2163)
 kafka.consumer.ZookeeperConsumerConnector$ZKRebalancerListener$$anon$1.run(ZookeeperConsumerConnector.scala:348)
...
Exception: java.lang.IllegalStateException thrown from the UncaughtExceptionHandler in thread "kafkaTaskExecutor-1-SendThread(<IP_ADDRESS>:2181)"
Jan 08, 2015 10:30:53 PM org.apache.coyote.AbstractProtocol stop
INFORMATION: Stopping ProtocolHandler ["ajp-nio-8010"]
Jan 08, 2015 10:30:54 PM org.apache.coyote.AbstractProtocol destroy
INFORMATION: Destroying ProtocolHandler ["http-nio-8085"]
Jan 08, 2015 10:30:54 PM org.apache.coyote.AbstractProtocol destroy
INFORMATION: Destroying ProtocolHandler ["ajp-nio-8010"]
Exception in thread "default_Marcels-MacBook-Pro.local-1420752644064-c4f47dde_watcher_executor" java.lang.IllegalStateException: Can't overwrite cause with java.lang.IllegalStateException: Illegal access: this web application instance has been stopped already.  Could not load kafka.consumer.ZookeeperConsumerConnector$ZKRebalancerListener$$anon$1$$anonfun$run$4.  The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
	at java.lang.Throwable.initCause(Throwable.java:457)
	at org.apache.catalina.loader.WebappClassLoaderBase.checkStateForClassLoading(WebappClassLoaderBase.java:1306)
	at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1186)
	at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1147)
	at kafka.consumer.ZookeeperConsumerConnector$ZKRebalancerListener$$anon$1.run(ZookeeperConsumerConnector.scala:360)
Caused by: java.lang.ClassNotFoundException
	at org.apache.catalina.loader.WebappClassLoaderBase.checkStateForClassLoading(WebappClassLoaderBase.java:1305)
	... 3 more

Thanks for the great work
Marcel

@marcelalburg , do you need something else from us on the matter?
Do be honest we use this our spring-integration-kafka in the Spring XD extensively and there is no yet any concerns around it.
Let us know how to be with issue. Can we just close it as resolved ?

Yeah, you can close it. Thanks.

how did you solve the problem?


Is there any way to enable captions through cc_load_policy?

Hi, I've tried looking through the codebase and it looks like it's not possible to pass the cc_load_policy parameter through to the player & get it to play captions.
Does anyone know how to do this?

Anyone else looking for this, I've got it working on iOS here: https://github.com/oldtinroof/react-native-youtube/tree/addCaptions.
I'll submit a PR once I can work out how to do it in Android!

@oldtinroof  Were you ever able to get this to work on Android?

@eazeye sorry, no I gave up as the android player seemed a lot more restricted, and my client didn't want to pay for the time.


Finish OWNERS implementation

Described here:
https://github.com/kubernetes/contrib/pull/474#issuecomment-226249631
cc @eparis @davidopp @philips @mike-saparov @hongchaodeng @kubernetes/contributor-experience
@philips Please add your suggestions here.

Copying from #474:
Previous workflow:

a reviewer, who didn't necessarily have write access (and therefore label access), would be assigned
the reviewer would eventually type "LGTM" into a comment
the author would (often) squash commits and/or rebase
the reviewer would then apply the lgtm label if they had label access, or would notify someone in kubernetes-maintainers to do that if they did not; the author could self-apply lgtm if they had label access

Proposed workflow:

a reviewer, who isn't necessarily an approver, would be assigned
the reviewer would eventually type "LGTM" into a comment
the author would (often) squash commits and/or rebase
the reviewer would then type I approve if they were an approver, or would notify an approver to do that if they were not; the author could self-approve if they were an approver

It's pretty much the same, except that it bypasses github ACLs.
We've already taken direct merge powers away from most people in kubernetes-maintainers.
On approvers vs. reviewers:
We're bottlenecked on review bandwidth. We need to grow the reviewer pool, but we also need to move to multi-phase PR reviews in order to take load off of bottleneck people.
A reviewer just has to be someone who could provide constructive feedback on a PR review -- someone who understands our project's coding conventions, ideally the code of that component, etc. We should be more liberal with inclusion in the reviewers list.
An approver is someone with the authority to determine whether a PR should be merged or not.
We'll want a progression by which we can grow contributors into reviewers and reviewers into approvers.
A PR might have a single primary reviewer but require multiple approvers (e.g., an API approver and a Kubelet approver, for a Node API change), or multiple reviewers (e.g., people familiar with different parts of the repo) and a single approver (e.g., me).
As an example, I want to be removed from the PR auto-assigner, but would like to retain my approval powers -- I should be an escalation point, not on the front lines of reviews.
We should find a home for this:
https://github.com/coreos/findowner

@hongchaodeng @xiang90 Do you have any more questions about this?

@bgrant0607
No questions from me so far. Will try to get this done by next Monday.

Here's a follow-up to the proposed workflow:

a reviewer, who isn't necessarily an approver, would be assigned

The findowner program will generate owners for each package. Do you want me to assign according to the new owner list in the implementation?

the reviewer would eventually type "LGTM" into a comment

PR (https://github.com/kubernetes/contrib/pull/1428) will enable munger to look for 'LGTM' comment from reviewer and apply an 'lgtm' label.
I will try to implement a notifier to notify relevant approvers.
Q: What's the policy for multiple reviewers?

the reviewer would then type "I approve" if they were an approver, or would notify an approver to do that if they were not; the author could self-approve if they were an approver

PR (https://github.com/kubernetes/contrib/pull/1429) will enable munger to look for approver's "I approve" comment and apply "approved" label.
I will try to modify the submit-queue logic to look for approval label.
Q1: What's an approver? How can I know if someone is an approver?
Q2: Multiple approvers policy?

@hongchaodeng FYI, I filter all email that doesn't mention "bgrant0607", so I didn't notice your update. I'll try to respond later today.

@hongchaodeng
The bot implementation will be in contrib. The updates of OWNERS needs to happen in the kubernetes repo. These can occur relatively independently. As a starting point, current reviewers should be moved to approvers, and we could use findowner for lists of reviewer candidates. Due to how old the original reviewers lists are and to how much refactoring we do, I imagine we'll need to iterate on both lists. There is also a list of area owners in https://github.com/kubernetes/kubernetes/wiki .
Policy on multiple reviewers: Github now supports multiple assignees. For PRs touching multiple directories, rather than assigning reviewers from the nearest common ancestor in the source tree, for scalability, I think we should assign reviewers from the leaves, perhaps randomly selecting 2 from each directory and then choosing the least loaded review-wise (The Power of 2 Choices). In the case of multiple assignees, it would be up to them to coordinate the review of the whole thing, though eventually it would be desirable for the bot to confirm LGTM coverage of all directories touched before applying the lgtm label. I'm open to other policies, and we can also refine it over time.
For approvers, I think we should assign/notify an approver from the nearest common ancestor but, again, transitive coverage of directories touched should gate application of the approved label. So an approver in the root OWNERS file could approve any PR.

I know most of the talk about repo-splitting was in the main repo, but...
Any objections to breaking off a new repo for "autobots" and putting all
automation and bots etc there?  In the vein of making the bots more
generic, a whole distinct repo might help.
On Mon, Jul 25, 2016 at 9:40 PM, Brian Grant<EMAIL_ADDRESS>wrote:

@hongchaodeng https://github.com/hongchaodeng
The bot implementation will be in contrib. The updates of OWNERS needs to
happen in the kubernetes repo. These can occur relatively independently. As
a starting point, current reviewers should be moved to approvers, and we
could use findowner for lists of reviewer candidates. Due to how old the
original reviewers lists are and to how much refactoring we do, I imagine
we'll need to iterate on both lists. There is also a list of area owners in
https://github.com/kubernetes/kubernetes/wiki .
Policy on multiple reviewers: Github now supports multiple assignees. For
PRs touching multiple directories, rather than assigning reviewers from the
nearest common ancestor in the source tree, for scalability, I think we
should assign reviewers from the leaves, perhaps randomly selecting 2 from
each directory and then choosing the least loaded review-wise (The Power of
2 Choices). In the case of multiple assignees, it would be up to them to
coordinate the review of the whole thing, though eventually it would be
desirable for the bot to confirm LGTM coverage of all directories touched
before applying the lgtm label. I'm open to other policies, and we can also
refine it over time.
For approvers, I think we should assign/notify an approver from the
nearest common ancestor but, again, transitive coverage of directories
touched should gate application of the approved label. So an approver in
the root OWNERS file could approve any PR.
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/contrib/issues/1389#issuecomment-235161164,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVIi6tJMbGnHgSZ0-w2bCMCaNZu7Qks5qZY_XgaJpZM4JPSZY
.

@thockin I agree, but could we please not discuss it on this issue?

ACK.  Is there an issue for this topic or should I open one?
On Mon, Jul 25, 2016 at 11:07 PM, Brian Grant<EMAIL_ADDRESS>wrote:

@thockin https://github.com/thockin I agree, but could we please not
discuss it on this issue?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/contrib/issues/1389#issuecomment-235171716,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVMr17wOkjQIh4ZqjDneAAqiqDAUSks5qZaQ0gaJpZM4JPSZY
.

There is actually a doc:
https://github.com/kubernetes/kubernetes/blob/master/docs/devel/owners.md

@kubernetes/contributor-experience
In order to implement the approval munger, I need to define approver and implement some helper function to "get" approver.
Is there any work around it currently? Let me know if any.
My implementation plan follows the comment:

For approvers, I think we should assign/notify an approver from the nearest common ancestor but, again, transitive coverage of directories touched should gate application of the approved label. So an approver in the root OWNERS file could approve any PR.

@bgrant0607 One question. What does it mean by "transitive coverage of directories touched should gate application of the approved label."

@hongchaodeng A user listed as an approver in an OWNERS file applies to files in that directory and in all subdirectories of that directory, so someone in the root OWNERS file could approve all PRs.

Interesting to have this! Tracking!

If you need more inspiration, here's a similar product:
https://about.pullapprove.com/features/
FWIW, we have looked at pullapprove, but the functionality is a subset of what we need for our PR workflow in general, and the legal process to get it approved could well drag out for a really long time.

@hongchaodeng If we are regenerating updated owners for the main repository, we may be able to leverage the code at https://github.com/foxish/findowner/tree/foxish-edits, which I used to generate owners for contrib. It has a few modifications to the original coreos/findowner code, and some of those changes may be reusable.

@hongchaodeng can we get a status update on this?  Do you need any help or input on the implementation?

For the code it's done in https://github.com/coreos/findowner
We are still coordinating. Hopefully will be able to discuss it again on Thur's meeting.

Approver handler impl: https://github.com/kubernetes/contrib/pull/1727

PRs adding reviewers to OWNERS files:

[ ] https://github.com/kubernetes/kubernetes/pull/36115
[ ] https://github.com/kubernetes/kubernetes/pull/36116
[ ] https://github.com/kubernetes/kubernetes/pull/35833
[ ] https://github.com/kubernetes/kubernetes/pull/35715

More to come ...

PRs that can't be merged before each owners file is merged, and are properly tested in a different repo:

https://github.com/kubernetes/contrib/pull/2018
https://github.com/kubernetes/contrib/pull/2002
https://github.com/kubernetes/contrib/pull/1923

@apelisse thanks for doing this work. What is your target date for getting them all merged?

I think @apelisse is out for a while - does someone need to take this over?
On Tue, Nov 29, 2016 at 10:27 AM, Brandon Philips<EMAIL_ADDRESS>wrote:

@apelisse https://github.com/apelisse thanks for doing this work. What
is your target date for getting them all merged?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/contrib/issues/1389#issuecomment-263655323,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVAP55jG_6OR4LH1zbJogy_bc_heMks5rDG6ogaJpZM4JPSZY
.

@thockin How long is he out? We have been working on this since July and I want to get it done done.

Long enough that you'll be unhappy.  Can we find an alt owner?
On Tue, Nov 29, 2016 at 10:43 AM, Brandon Philips<EMAIL_ADDRESS>wrote:

@thockin https://github.com/thockin How long is he out? We have been
working on this since July and I want to get it done done.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/contrib/issues/1389#issuecomment-263659690,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVGZrQ-ftYS8Lq3bwnqFvHGmItvjtks5rDHJjgaJpZM4JPSZY
.

I've been working on it as well.  I can follow up with directory owners for getting their updates to their OWNERS files.  And we have a PR out for testing this against contrib that gates on the approved and lgtm label and finds/notifies relevant owners.
PR is currently waiting for review/lgtm.

Well after long last all the PRs to the various OWNERS files in kubernetes:kubernetes have been merged! @bgrant0607 what is the next thing that you'd like tacked with respect to this issue or are we at a point of closing this issue and creating new issues for those next steps? Thanks for all hard work @apelisse and @grodrigues3!
cc: @philips

I'll send an email out to kubernetes-dev shortly that details the approvers process and the timeline.  In short, we'll start running it on the main repo next week and we'll use contribx mailing list for feedback.

Thanks for all of the hard work @grodrigues3 @apelisse and @calebamiles. For those that missed it the kubernetes-dev thread is here: https://groups.google.com/forum/#!topic/kubernetes-dev/aCuaL0DZZvI

Thanks @philips. it might be time to close this issue :-)

We are fixing issues and addressing feedback here: https://github.com/kubernetes/test-infra/issues/1678

Closing this issue now.


Corrected velocity vector

I think velocity vector must point from thingToMove to next waypoint. Otherwise it will be constant no matter where thingToMove is

I've never done a pull request before but looks fine to me. Thank you for checking the code and helping :) I really appreciate it. 👍

It's the first one for me too. Happy to help :-)


Images are saved as grayscale

Hi Nikhil,
thank you for the project. I reproduced the results, everything went well till the end. But I have got the original as a grayscale image at the end in the results folders. I don't know why. Your help will be appreciated in this regard.
Thanks,
Asif Ahmad

I think the CVC-ClinicDB dataset has been updated with grayscale images. Working with grayscale image should not have any issue. You can use another colonoscopy dataset like Kvasir-SEG https://datasets.simula.no/kvasir-seg/

I think the CVC-ClinicDB dataset has been updated with grayscale images. Working with grayscale image should not have any issue. You can use another colonoscopy dataset like Kvasir-SEG https://datasets.simula.no/kvasir-seg/

Thank you, NikhI. I just cross checked the images, they are colorful (RGB). I am trying the code on Google Colab.


styling custom timer form

can you please add the ss of the ui change

https://github.com/avinash201199/stopwatch/assets/111856910/bc97fdb3-a683-4ca4-9140-055bb4184d43

Thank you for your contribution :)


Rank Up & Awards | Discord Notifications

Is your feature request related to a problem? Please describe.
No.
Describe the solution you'd like
So, it could be great to have a discord notification for rank-up & award awarded. In the same way that is done for the pirep notifications.
Describe alternatives you've considered
Using the same way that is done for pirep & new user notification. Emeded.
Additional context
Nothing to add

@nabeelio With the discord notifications function working now, Can this now be easily implemented?

Yes, I'll take a look soon

We may need to close this one @nabeelio


Add customisation options for individual profiles

Add accent color for the user profile. So they can change the badge color.
Add a config key to the JSON which takes a nested object with properties such as:
"config": {
  "background": "#ffffff",
  "fontColour": "#000000",
  "badgeColour": "#123456"
  }

Then the client should be updated to use these values if present, or default values as a fallback.

What do you mean by badge colour?
I'm all for customisation, but what are we customising here? 😅

Answered my own question - this is the badge in question:

Good

@nhcarrigan can you assign me this issue?

Done 🙂


Roadrunner Autonomous

[x] Deadwheels on the robot.
[x] #25.
[ ] Left and right side autonomous modes.
[x] MeepMeep for auto simulation #22.

Currently blocked. I am going to update my current parking code with roadrunner pathing but I cannot make my idea auto that depends on left and right sides until we get our arm fully assembled.

Still blocked but for a different reason. We need to significantly improve our drive train and our deadhead encoder setup before I can actually do this. We have too many small errors that are causing roadrunner to get confused.

Our drive train has been improved however we are still blocked as we cannot attach the arm at this moment.


Add Track Request functionality

This commit adds an additional function which will generate a file with all the charmhub tracks that need to be available for a certain release. It will not yet check with charmhub if these tracks already exist.
It also will upload this file as an artifact when the github action is executed.

Closing this PR as it might be better to keep the logic of track request and branch creation isolated.


🐛 Bug:  Cloning Issue

Is there an existing issue for this?

[x] I have searched existing issues

What happened?
Every time i try to clone it throughs me this error.
Can anyone help me with this.

What was the expected behavior?
No response
Steps To Reproduce
No response
Relevant log output
No response
Anything else?
No response

@Sahillather002 It appears the problem was an empty file named Icon, presumably due to the lack of file extension and the Windows operating system with particular characters, referenced here. Let me know if the issue persists.


Flexibility to format value in the axis pointer tooltip[Feature]

What problem does this feature solve?
Looking for a way to format value in  axis pointer tooltip along with label

Axis Pointer Value Formatter
What does the proposed API look like?
A valueFormatter in axis pointer
label:{
formatter: ()=>{
return 'custom label'
}
valueFormatter:()=>{
return  'custom formatter value'
}
}

Hi,
Any update on this issue?

With reference to the above image we are able to modify the label in the tooltip using axisPointer on the xAxis along with the label we also want to modify the data/values that are being displayed beneath it i.e email: 90, union adds 270 etc... we only want to display the info related to the series which is hovered.

Hi, any update on this issue?


[RFC] Entity Links

Status: Open for comments
This is a formal proposal for a discussion on discord
Need
It is common to have existing external information or references related to entities in the catalog. These could often be represented as hyperlinks to some external reference when no related well known annotation or plugin exists. Some examples of this might be.

Deployed website, demo site, etc.
Admin dashboard for a service/website
External documentation, API references, storybooks, etc.
External team README page
Runtime dashboards, etc.
Various SasS integrations
... and the list goes on and on

Having the ability to attach this information to entities would open the world for providing a common Links card component on each entity page. These links could contain some basic context in order to indicate their semantic purpose (e.g. admin-dashboard, or api-docs, etc.)

Proposal
Provide a lightweight and quick way to extend an entity with an optional list of basic links to external information & references. This new field could be support some well-known links, org specific links, or specific entity instance links. The list of links could then be managed by entity owners or possibly automatically appended through catalog processors.
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: petstore
  links: # optional
    - url: https://admin.petstore.com  # required
      rel: admin-dashboard # optional but recommended to provide semantic meaning
      label: Admin Dashboard # optional and could be inferred by rel if omitted
spec:
  type: website
  ...

It would also be nice to have the ability to associate icons to links. This could be done through the rel attribute or perhaps more appropriately an optional icon field (or both with rel as a fallback if provided). The icon value could be an enum value that maps to a icon library such as iconify.
metadata:
  links:
    - url: https://admin.petstore.com
      label: Admin Dashboard
      icon: dashboard-icon

It might be possible to have a short form string version that might be expanded to it's constituent parts. However escaping might be a concern that makes this less feasible. For example:
metdata:
  links:
    - http://admin.petstore.com # just a url
    - url=http://admin.petstore.com,rel=admin-dashboard # a inline map
    - { url: 'http://admin.petstore.com' } # inline yaml object

Alternatives
Links could probably be modeled as annotations:
metdata:
  annotations:
    # Format: [links.backstage.io/${rel}]: [value]
    links.backstage.io/admin-dashboard: https://admin.petstore.com

However, since annotations are typically single values the ability to provide additional context of a label & icon, etc. could be harder to maintain.
Risks
The concept of links can overlap with the existing entity annotations and possibly tags. They also could be modeled by extended either of these existing concepts. Also the concept of links is quite subjective and could mean anything making it a bit abstract and difficult to define when you would use a link versus an annotation.
Forcing people to use annotations to model a simple external reference could mean they don't attach this useful information as it requires additional setup for a specific case. On the flip side having a quick to use links field could be used as a dumping ground and therefore deter people from modelling proper annotations when appropriate. However, these potential points of confusion can be reduced through guidance and documentation.

Great summary!
As we said in the chat, I think the url + rel form that you mentioned above is a good balance between easy enough to type and still extensible.

@freben - I'd be happy to take this one on. Assuming there are no high level objections to the idea. Any details can be ironed out as part of a PR.

@Rugvip @benjdlambert Opinions? Is the concept of links wise enough, and is the concept scoped correctly? I want them to primarily be informational and drive a links collection in the frontend. My main worry is whether there's an unclear overlap with annotations, or if this for some reason isn't the right place for the data or the right time to introduce it.

I wonder if it's a good idea to allow "any" icon. That would cause a lot of icons to be included and tree shaking not to work. I think it would be better if the backstage instance (configurable) provides a list of support relations and sets the icon there. That would also make the annotation alternative easier to implement. Sure that would limit how free teams can choose their relations.
Bessie that, I would love to see this feature!

I'm a bit wary of icons too. Same with labels probably. People will want their own symbology and i18n or whatnot and I agree that it's probably something that, in practice, needs to be stitched up in the app using some facility for that.

I've viewed both label and icon as optional. For icons I figured it would be up to the app integrator to both define the mappings and setup the frontend to do so. There could be a separate plugin or utility API to help with this. I think labels should be less controversial. Some URLS could be very long and or non descriptive, so I see it mowing needed in many cases.

Aha, so icon in the form of enum-to-be-mapped rather than actual identifier into an icon lib. Sounds good.

Although, I suppose rel could likely accomplish this for any standardized links. Anything custom per entity might require at minimum a label in some cases.

My feedback on this links:
I feel that there is a lot of overlap with annotations to justify this. While a link is more clear as to that this is a link (URL mostly), this can still be managed by an annotation.
If a complex type is needed to be stored as a value of for an annotation it can be serialized into a string during storage and de-serialized later (in fact, i believe this approach is already used by some plugins).
The biggest advantage of Links seem to be that it can provide a rel that can be used to fetch the right icon to display on the frontend. My argument is that the name of the annotation provides the exact same functionality (backstage.io/managed-by-location?, as an example).
As to a reference to an icon, I believe that this a leaky abstraction of how the frontend should display a value, seeping into the backend and thus the data model.  Assuming rel to be the type of an icon, there 2 assumptions that I consider might be quite flimsy.
a. That the enum of all modelable ref's might be very large (and doesn't make sense to enumerate)
b.  All frontend's use the same library (iconify for example) as the icons.
While The service catalog working along with the backstage frontend is the standard mode of deployment, I would generally not make assumptions about what exact icon is used by the frontend, to seep into the backend (and thus rel doesn't make sense).
It is possible that a user might use a different icon library where the names are completely different, or might have to continue using existing icons that might not have a iconify equivalent. In such cases the ref becomes meaningless.
I hope my argument is coherent and understandable.

Hey, thanks for pitching in!

I feel that there is a lot of overlap with annotations to justify this. While a link is more clear as to that this is a link (URL mostly), this can still be managed by an annotation.

Yes, there is a potential overlap as mentioned above. However, the way we tend to think about the purpose of annotations is possibly not well aligned with these links. I think the discussions in this issue (especially the linked comment) may be informative. We should make a separate docs page with these considerations clearly outlined.
Annotations risk becoming a "catch-all" for all kinds of info, and I think we should use them judiciously. We could have encoded labels, some parts of spec, even description, as annotations if we had felt compelled to, but it would probably have been unwise.
It's still not 100% clear cut though, and we are very open to listening to these perspectives.

If a complex type is needed to be stored as a value of for an annotation it can be serialized into a string during storage and de-serialized later (in fact, i believe this approach is already used by some plugins).

Sure, but we really REALLY want to avoid encoding things like this, because humans are writing these files :) Hand-encoding data, and getting it right, is a burden placed on every person in the org that wants to make use of Backstage.
We've talked about relaxing the core schema to let annotations contain any JSON data, not just strings. But no decisions yet.

The biggest advantage of Links seem to be that it can provide a rel that can be used to fetch the right icon to display on the frontend. My argument is that the name of the annotation provides the exact same functionality (backstage.io/managed-by-location?, as an example).

Absolutely. Assuming we'll be happy with rel+url (which is a decent assumption) for this, encoding them as annotations is not a problem as such.
But is the shape of annotations a good fit, or the purpose of annotations?

As to a reference to an icon, I believe that this a leaky abstraction of how the frontend should display a value, seeping into the backend and thus the data model. Assuming rel to be the type of an icon, there 2 assumptions that I consider might be quite flimsy.

Right - but the assumption is that the icon string would be a small set of semantic enum values, along the lines of "docs" and "source" or so, nothing tied into visual representation. Sure the rel could be mapped directly as well, but the same icon would likely be used for several rels (e.g. perhaps the docs icon for both runbook and system diagrams and end user docs etc).
One may say, that the main benefit of the rel+icon split could be that the mapping in the app is potentially smaller to set up for the person installing Backstage. I don't think the set of possible rels will be so large that it's a significant factor though.

Thanks, read through the issue. I think some of my comments about links are still valid

Annotations risk becoming a "catch-all" for all kinds of info, and I think we should use them judiciously. We could have encoded labels, some parts of spec, even description, as annotations if we had felt compelled to, but it would probably have been unwise.

This is in some ways, unavoidable. Abstractions such as Entity, Component etc do not fit universally and some amount of hacks in implementation is to be expected, especially when migrating existing systems to Backstage. Users will try to use some "catch-all" mechanism to shoehorn existing information. With annotations there will be only one possible mechanism of adding extraneous information , whereas if we were to add links, there are possibly 2 ways of now adding extra information.

Sure, but we really REALLY want to avoid encoding things like this, because humans are writing these files :) Hand-encoding data, and getting it right, is a burden placed on every person in the org that wants to make use of Backstage.

I think it might be also be a hybrid model , wherein some sections/entities might end up being hand-written and others auto-generated. For example, A scaffolder plugin might auto generate a lot of fields for the user when the Entity is being created, so that the YAML description doesn't have to be filled in by hand (or a processor might convert existing models -> Entity definitions).
But most importantly, I want to look at the real purpose driving behind links - What are we trying to link to ?

If they are backstage entities - they can be already linked via relations.
External components (dashboard, monitoring, metrics, etc) - This seems like the use case.

Addressing 2:
We will endup showing icons that link to external components, on say, the Catalog Component.  To me, as it stands, it looks like the ONLY location where links could be potentially used is in the Catalog UI, to show a  list of links to some external components.
In such a case, why not have these links encoded as annotations ? Curently, the Catalog UI uses an annotation to show a link to the Source code and to Tech Docs on the overview page. We also use an annotation to enable an Icon to the CI/CD Tab. We can thus allow plugins to show other visual information using the same mechanism.
In the future, the same annotations can be re-used by other plugins as well. For example, instead of linking to an external metrics dashboard, if the same were to be implemented as a frontend plugin within Backstage, the annotation can be used directly by the Dashboard plugin to provide a dashboard for the Entity in the same SPA.
I don't see non-standardized annotations as an issue. The nice thing about annotations are that they are arbitrary and opt-in (that is feature / plugin X is not activated unless annotation A exists). Plugins can simply ignore the annotations that they do not care about.
You can have an arbitrary number of links to external entities, but I doubt that most PMs, Designers, front-end devs would  want to show all of them in an uncontrolled fashion. Most likely there will be certain UI components rendered based on a certain rel
or a label. If that is the case, then annotations are just as suitable, and as per @Rugvip 's comments the intended usecase for annotations.

The links are in my mind primarily scoped to human, informative (not normative), display. To me, their current intended model is so weak, that they could almost be intentionally left inside description or as part of the README.md of components if we made it possible to ingest and display that. I expect the main consumer of this information is a person that wants to know more about a component that is foreign to them, or for the owners of a component to have a convenient hotlink to monitoring interfaces etc.
It could be a case of an org telling their teams that "Hey please put a runbook link in all of your components, it helps our OPS team to find it more easily".
Note that the links is data that is meant to be written and then read verbatim, just like for example description. Relations are output-only data that could be generated from any other type of input. The links data is super simple and scope-limited when compared to any relation-generating field.
A monitoring related annotation could for example hold some app ID string only. This is great for plugins and other consumers to be able to shape requests to other systems, or form an auto generated entity tab with some helpful default graphs based on requests to your TSDB, etc etc. A link however, could point to your exact main grafana dashboard that you hand crafted and use on your on-the-wall-in-your-team-area monitoring screen.

I don't see non-standardized annotations as an issue. The nice thing about annotations are that they are arbitrary and opt-in (that is feature / plugin X is not activated unless annotation A exists). Plugins can simply ignore the annotations that they do not care about.

This is quite right.

The links are in my mind primarily scoped to human, informative (not normative), display. To me, their current intended model is so weak, that they could almost be intentionally left inside description or as part of the README.md of components if we made it possible to ingest and display that. I expect the main consumer of this information is a person that wants to know more about a component that is foreign to them, or for the owners of a component to have a convenient hotlink to monitoring interfaces etc.

It could be a case of an org telling their teams that "Hey please put a runbook link in all of your components, it helps our OPS team to find it more easily".

This sums up my feelings as well. I do not think that they are strong enough yet to warrant being added to the core model of entities.
How much interest is in the rest of the community for a feature such as this ? If there isn't much, then perhaps this can be avoided for now ? Or , as an alternate maybe links can be added to the model and documented as an experimental entry in the alpha versions and based on usage, feedback modified or removed later ? As owners you will have to make a decision on this :)

Some good points here for sure.
One strong reason for proposing some sort of links structure is to enable entities to become the central knowledge base for all related things to that entity. A backstage instance will likely gain higher adoption if it can centralize as much information as possible in a single place. There are many things that could be related to an entity / component that are external to backstage and have a low ROI on integrating them into backstage proper. This is where links come into play. They provide a simple way to extend the entity with useful information about the entity and therefore making backstage more useful.
Icons & custom labels are not a necessity, but they do provide a strong UX addition imo. Icons provide a meaningful visual landmark that is easy to parse visually. I think a strict combination of just a rel key & url could be used to model external links and potentially support icons and custom text. The rel key in this case would need to be semantic and meaningful by itself. If this is the case it could be modeled through annotations or a new metadata.links field. However the annotations option would be less extensible and require encoding JSON, etc. which would not be human friendly for maintaining.
As for custom icons, the team maintaining an orgs backstage instance, could setup and provide the appropriate mapping for icons & text. I can see this being necessary from a UX perspective. Take for instance a link an operational dashboard. The rel might be apm-dashboard, which could be might be more meaningful to end users to show a grafana icon in some cases or datadog in others. Also, the terminology for apm-dashboard might be different. Now that I think of this a little more, I'm not sure this use case is specific to this RFC. There will be many links throughout backstage and within various plugins. Having the ability to customize icons and text for more general concepts will pose a similar concern around consistency and customization and tailoring for a specific org. Perhaps this warrants an additional RFC around a potential core API that plugins use which can allow each backstage instance to customize terms, icons, etc.?
A completely different approach to links, could be to create a new entity type and then use an entity relationship to map the entity to the links provider entity. This approach could potentially be a way to extend the entity with arbitrary metadata (not just for links). However, this high level idea feels a little wonky, but I thought I'd just toss it into the discussion.

A completely different approach to links, could be to create a new entity type and then use an entity relationship to map the entity to the links provider entity. This approach could potentially be a way to extend the entity with arbitrary metadata (not just for links). However, this high level idea feels a little wonky, but I thought I'd just toss it into the discussion.

IMHO, this would simply be replicating the relationship in a new High level entity  that duplications the relations field. I think having one place to model relationships would be preferable.

There will be many links used throughout backstage and within various plugins. Having the ability to customize icons and text for more general concepts will pose a similar concern around consistency and customization and tailoring for a specific org. Perhaps this warrants an additional RFC around a potential core API that plugins use which can allow each backstage instance to customize terms, icons, etc.?

I am not a frontend dev, but I assume that to display a certain icon for a link, Backstage UI devs would be writing specific components for a url + rel combo,  or a generalinzed Link component that knows exactly which img / svg to fetch based on the rel.

IMHO, this would simply be replicating the relationship in a new High level entity that duplications the relations field. I think having one place to model relationships would be preferable.

Agreed. I only brought this up for completeness in exploring options.

I am not a frontend dev, but I assume that to display a certain icon for a link, Backstage UI devs would be writing specific components for a url + rel combo, or a generalinzed Link component that knows exactly which img / svg to fetch based on the rel ? If that is the case, then I do not see a lot of value around standardized icons and terms as there will be PMs and designers doing the very same (feel free to counter this in case I missed something ).

I think my point may have been unclear here. I was implying the opposite of standardizing icons and text, but making it possible to customize them per backstage instance. This is somewhat related to #3560, but in this case would apply to various labels and icons used throughout the app & plugins. To your point, doing so would require the team maintaining the backstage instance to use some sort of API that allows customization or text and icons throughout the app. In the case of an EntityLink component it might be providing a provider interface that maps rel to a react icon component. Then of course there would be a a fallback (perhaps a material-ui globe icon). The same pattern could be applied to text labels as well. There are of course other ways to accomplish this. I see this as a possible related extension of this RFC.

How much interest is in the rest of the community for a feature such as this ? If there isn't much, then perhaps this can be avoided for now ? Or , as an alternate maybe links can be added to the model and documented as an experimental entry in the alpha versions and based on usage, feedback modified or removed later ? As owners you will have to make a decision on this :)

It seems the concern here is not around the conceptual idea itself, but more about how they are modeled in to the catalog. I'm open to modeling links as annotations using the links.backstage.io/[rel]: [url] pattern if we feel this is more appropriate. The caveat is that the rel key will be the only semantic identifier since annotation values in their current form do not handle complex structures in a human friendly way.
Having links for our company is essential to helping backstage become more widely adopted and useful. We need a quick way to associate custom links to entities without the ceremony of adding a full fledged backstage integration. We can definitely do this as a custom extension of the entity model, but would prefer to have community accepted solution to this.

Throwing in that I'd vote for going with, and adding support for, some version of
metadata:
  annotations:
    backstage.io/links:
      - url: ...
        title: ...
        rel: ...
      - url: ...
        title: ...

I do think having a simple way to add a couple of links is important, it's very widely used in the internal version

@Rugvip - So you are suggesting that annotations be extended to support native objects rather then just JSON encoded strings?
I think this could be useful for other means as well. There is already a case that we ended up encoding a JSON string value for a custom annotation. However, the annotation in that case is populated via a catalog processor so its never manually edited.
I think it would be nice to have a short form string version where only rel + URL is provided though. This is one nice thing about the rep being embedded into the key. However there could also be a short form version with a separator to accomplish a similar result.
Would that also mean that certain annotation keys could have their own schemas and validated as such?

@andrewthauer yep, had a couple of cases where it would be useful to allow any JSON value as annotation value. Wanna do that change along with removing any way to query annotations by value from the catalog :>
String format would be fine too, but modelling it as multiple annotations is still gonna get pretty meh. You'll have to both figure out enumeration, which is prolly easy enough, but also ordering. Someone that is adding the links will usually want to have the order intact, which JSON processing may or may not do ^_>

Still not sure what "makes" this an annotation. It's a pretty special concept. What makes it not go directly in metadata, and how is it different from e.g. description and tags?

Still not sure what "makes" this an annotation. That's a pretty special concept. What makes it not go directly in metadata, and how is it different from e.g. description and tags? Does it match your list of criteria for what goes where?

I'll rule out 2 of these based on the following:

Tags are typically used for categorization, which is not the intent here
Description is a summary or explanation of the entity so it's unusable or practical for modelling links

Annotations, as described in the backstage docs seem to fit the closest of the these. The fact they are non identifying and can be references to external systems seems to match the majority of use cases for links.
I can't see a super strong reason for having them as their own top level metadata vs annotations. Especially if annotations are to be extended to support JSON values. Having them as annotations seems to be the more natural for that doesn't require introducing something completely new.

Oh yeah I didn't mean to use tags or description to model links; I meant that to me, links feel like the exact same class of information as those.
The root of the metadata blob is open for extension and I expect people to throw in more metadata-like things there for their own purposes. But labels and annotations are very specific fields with specific purposes, limitations and semantics. So to me the annotations don't feel like a place to just throw things into or a catch-all; they feel lite something to only pick consciously for a sorbitol subset of things.
That's what led me to wonder what makes links special.

Essentially,
A well defined application ID/slug that's used to enable plugins/features in the frontend, and which is used to form queries into third party systems -- sounds like an excellent candidate for an annotation, or actually even a label since you may want to query on a bag of entities related to an application
A random bag of links to various stuff, only used in an informative sense for people to click on -- definitely not annotation like
In my mind :)

The thinking that these are not slugs or identifiers which sets them apart from annotations resonates with me. Therefore, to avoid confusion with typical annotations then perhaps modeling them as a new optional metadata field makes most sense. Especially if metadata is mean to be open for extension. We could simply start out with:
metadata:
  name: foobar
  links: # optional
    - rel: admin-dashboard
      url: https://admin.example.org
    - rel: confluence # maybe this is also optional?
      url: https://confluence.example.org/foobar

Maybe the term relatedLinks (or something else) instead of just links might be more meaningful as well?
metadata:
  name: foobar
  relatedLinks:
    - rel: admin-dashboard
      url: https://admin.example.org

Are there any major downsides to adding this as an optional field to metadata besides potentially the risk of people misusing the fields for things that should be more appropriately annotations? I think there will always be potentially the confusion with annotations, but the rationale of them not being slugs or identifiers is a strong case of distinction.

Any additional feedback on this? Based on the last couple of comments, there could be a clear distinction of what a link is and why it may not make sense to model as an annotation. cc @freben, @Rugvip, @GoWind?

Any additional feedback on this? Based on the last couple of comments, there could be a clear distinction of what a link is and why it may not make sense to model as an annotation. cc @freben, @Rugvip, @GoWind?

Not from me. My mind is pretty set on metadata.links.[].{rel,url} at this point :) I'd vote to go ahead and implement, and then extend in the future if we find that we want to decide icons and labels and stuff.

Not from me. My mind is pretty set on metadata.links.[].{rel,url} at this point :) I'd vote to go ahead and implement, and then extend in the future if we find that we want to decide icons and labels and stuff.

By the way, to be clear, @andrewthauer are you looking to do the actual work to add this?

By the way, to be clear, @andrewthauer are you looking to do the actual work to add this?

Or shall we make a help-wanted issue with the details

Or shall we make a help-wanted issue with the details

Feeling pretty strongly that we should have some proper real-world use-cases to that uses rel if we want to add it. If we want to use it so select where the links go, then let's have some idea of how. If we want to use it for icons we should get that system in place first imo, an app-wide catalog of icons tied to identifiers that people can use, probably accompanied by an icon-browser-plugin for users to use to discover icons.
Even at that point there should be some got reasons to use rel instead of icon, which was also mentioned in the original proposal. We shouldn't forget that these links are gonna be typed out and read by humans and all kinda of disciplines and tech savviness, leaning on established web terminology might make sense for us, but perhaps not for a data scientist.
I actually think the original proposal looks good:
metadata:
  name: petstore
  links: # optional
    - url: https://admin.petstore.com  # required
      rel: admin-dashboard # optional but recommended to provide semantic meaning
      label: Admin Dashboard # optional and could be inferred by rel if omitted

Just that we should drop the rel for now until there's some clear usage. Then I'd open up for a quick debate whether we should go with something else than label as it has potential to be confused with a less human readable concept, kinda like tags. Calling it e.g. title would make it clear that it is for display only, assuming that is what we want.
When it comes to short form it's possible that we could allow just the URL by itself, but tbh we'd only be saving a couple of url: 's. Internally we have a '[Admin Dashboard](https://admin.petstore.com)' form, let's not do that. I think the object form is short enough tbh, typically you wouldn't want too many links anyway as it just clutters the page.
Regarding metadata vs annotation, I'm still sticking to my opinion that we should only be consuming annotations and other labelled data buckets in plugins, to allow for long-term evolution. The links can go in metadata.links, but we'd move them to an annotation in the standard entity processor. Not something that should be blocking this issue though, so happy with just putting and consuming them from metadata for now.

Feeling pretty strongly that we should have some proper real-world use-cases to that uses rel if we want to add it. If we want to use it so select where the links go, then let's have some idea of how. If we want to use it for icons we should get that system in place first imo, an app-wide catalog of icons tied to identifiers that people can use, probably accompanied by an icon-browser-plugin for users to use to discover icons.
Even at that point there should be some got reasons to use rel instead of icon, which was also mentioned in the original proposal. We shouldn't forget that these links are gonna be typed out and read by humans and all kinda of disciplines and tech savviness, leaning on established web terminology might make sense for us, but perhaps not for a data scientist.
I actually think the original proposal looks good:
metadata:
  name: petstore
  links: # optional
    - url: https://admin.petstore.com  # required
      rel: admin-dashboard # optional but recommended to provide semantic meaning
      label: Admin Dashboard # optional and could be inferred by rel if omitted

Just that we should drop the rel for now until there's some clear usage. Then I'd open up for a quick debate whether we should go with something else than label as it has potential to be confused with a less human readable concept, kinda like tags. Calling it e.g. title would make it clear that it is for display only, assuming that is what we want.
When it comes to short form it's possible that we could allow just the URL by itself, but tbh we'd only be saving a couple of url: 's. Internally we have a '[Admin Dashboard](https://admin.petstore.com)' form, let's not do that. I think the object form is short enough tbh, typically you wouldn't want too many links anyway as it just clutters the page.
Regarding metadata vs annotation, I'm still sticking to my opinion that we should only be consuming annotations and other labelled data buckets in plugins, to allow for long-term evolution. The links can go in metadata.links, but we'd move them to an annotation in the standard entity processor. Not something that should be blocking this issue though, so happy with just putting and consuming them from metadata for now.

By the way, to be clear, @andrewthauer are you looking to do the actual work to add this?

@freben - Yes, I was thinking of tackling this yes. Would probably be split into at least 2 or 3 PR's starting with extending the entity model and then providing a component that can be used as a widget in the entity overview page.

Feeling pretty strongly that we should have some proper real-world use-cases to that uses rel if we want to add it. If we want to use it so select where the links go, then let's have some idea of how. If we want to use it for icons we should get that system in place first imo, an app-wide catalog of icons tied to identifiers that people can use, probably accompanied by an icon-browser-plugin for users to use to discover icons.

@Rugvip  - I'm viewing rel as more of a slug or type. They would be used to semantically identify what the link represents (e.g. admin-dashboard, logs, storybook, etc.). It would be optional and used similarly to how component.spec.type is meant to tailored to an org. The most concrete use case of consuming this would be to define a icon mapping resolver in which the team maintaining backstage could provide a registry that maps this rel identifier to an icon of their choice which in turn is use by an EntityLinks component. If none is provided it fallback to something generic link a globe icon. Roughly speaking it might boil down to something like:
{links.map(link => {
  const { text, icon, href } = linkRegistry.resolve(link);
  return (<EntityLink text={text} href={href} icon={icon} />);
}}

To your point, maybe rel and label are not the most intuitive names. Perhaps title and type might be more clear?
metadata:
  name: petstore
  links: # optional
    - url: https://admin.petstore.com  # required
      type: admin-dashboard # optional
      title: Admin Dashboard # optional

We could leave out rel/type for now, but I actually feel like it might be more useful and succinct then title. If the org chooses to support a set of well known rel/types then it's easier to maintain consistency and provide context for what the link represents.

Regarding metadata vs annotation, I'm still sticking to my opinion that we should only be consuming annotations and other labelled data buckets in plugins, to allow for long-term evolution. The links can go in metadata.links, but we'd move them to an annotation in the standard entity processor. Not something that should be blocking this issue though, so happy with just putting and consuming them from metadata for now.

Agreed. Metadata links should not be used to drive anything in plugins. We can provide a builtin component to display them as a card widget, but beyond that they should not be used for anything but purely informational purposes.

By the way, to be clear, @andrewthauer are you looking to do the actual work to add this?

@freben - Yes, I was thinking of tackling this yes. Would probably be split into at least 2 or 3 PR's starting with extending the entity model and then providing a component that can be used as a widget in the entity overview page.

Feeling pretty strongly that we should have some proper real-world use-cases to that uses rel if we want to add it. If we want to use it so select where the links go, then let's have some idea of how. If we want to use it for icons we should get that system in place first imo, an app-wide catalog of icons tied to identifiers that people can use, probably accompanied by an icon-browser-plugin for users to use to discover icons.

@Rugvip  - I'm viewing rel as more of a slug or type. They would be used to semantically identify what the link represents (e.g. admin-dashboard, logs, storybook, etc.). It would be optional and used similarly to how component.spec.type is meant to tailored to an org. The most concrete use case of consuming this would be to define a icon mapping resolver in which the team maintaining backstage could provide a registry that maps this rel identifier to an icon of their choice which in turn is use by an EntityLinks component. If none is provided it fallback to something generic link a globe icon. Roughly speaking it might boil down to something like:
{links.map(link => {
  const { text, icon, href } = linkRegistry.resolve(link);
  return (<EntityLink text={text} href={href} icon={icon} />);
}}

To your point, maybe rel and label are not the most intuitive names. Perhaps title and type might be more clear?
metadata:
  name: petstore
  links: # optional
    - url: https://admin.petstore.com  # required
      type: admin-dashboard # optional
      title: Admin Dashboard # optional

We could leave out rel/type for now, but I actually feel like it might be more useful and succinct then title. If the org chooses to support a set of well known rel/types then it's easier to maintain consistency and provide context for what the link represents.

Regarding metadata vs annotation, I'm still sticking to my opinion that we should only be consuming annotations and other labelled data buckets in plugins, to allow for long-term evolution. The links can go in metadata.links, but we'd move them to an annotation in the standard entity processor. Not something that should be blocking this issue though, so happy with just putting and consuming them from metadata for now.

Agreed. Metadata links should not be used to drive anything in plugins. We can provide a builtin component to display them as a card widget, but beyond that they should not be used for anything but purely informational purposes.

After talking a bit yesterday I also was swayed in favour of actually having a title in there after all. My initial idea of rel being able to express essentially both title and icon won't work out in practice; it'll just dilute the rel/type into needing a ton of different possible values.
If we leave the title optional too, I'm not sure how we would draw the actual link in the frontend :)

After talking a bit yesterday I also was swayed in favour of actually having a title in there after all. My initial idea of rel being able to express essentially both title and icon won't work out in practice; it'll just dilute the rel/type into needing a ton of different possible values.
If we leave the title optional too, I'm not sure how we would draw the actual link in the frontend :)

My thinking was title would resolve using link.title | customTitle(link) | link.url. So the fallback would be the URL if it's optional. I see no problems supporting title as per the original proposal but don't see a strong need to make it required (although it would be recommended to have it). That a as said, I can go either way.
Are we suggesting supporting title along with rel/type or just URL & title?

My thinking was title would resolve using link.title | customTitle(link) | link.url. So the fallback would be the URL if it's optional. I see no problems supporting title as per the original proposal but don't see a strong need to make it required (although it would be recommended to have it). That a as said, I can go either way.
Are we suggesting supporting title along with rel/type or just URL & title?

required url, optional type, optional title sounds good to me - @Rugvip?

required url, optional type, optional title sounds good to me - @Rugvip?

@andrewthauer @freben yeah was also thing just show the URL itself if the title isn't set.
Regarding type I again think it should be driven be a clear and conrete need. If it's only for icons I think an icon field would be better, but if it's also for deciding how and where to display the link then we should have some ideas for how that would actually be reflected in the UI.

@andrewthauer @freben yeah was also thing just show the URL itself if the title isn't set.
Regarding type I again think it should be driven be a clear and conrete need. If it's only for icons I think an icon field would be better, but if it's also for deciding how and where to display the link then we should have some ideas for how that would actually be reflected in the UI.

Perhaps icon might be more appropriate since it really is the main use case. I never had the intention for these links to be filtered or selectively used as a subset based on the type. One could still resolve the title based on the icon key if desired, but this would potentially be a misuse of icon. So ...
metadata:
  name: petstore
  links: # optional
    - url: https://admin.petstore.com  # required
      title: Admin Dashboard # optional
      icon: admin-dashboard # optional

Are we ok having the icon value as a key like string? The intention being any components displaying links would have the option of using this icon key to map to an appropriate react icon. This approach would provide the most flexibility but would put more work on the maintainers of backstage. Although, I suspect it could be extended to make this easier and more automatic.

Perhaps icon might be more appropriate since it really is the main use case. I never had the intention for these links to be filtered or selectively used as a subset based on the type. One could still resolve the title based on the icon key if desired, but this would potentially be a misuse of icon. So ...
metadata:
  name: petstore
  links: # optional
    - url: https://admin.petstore.com  # required
      title: Admin Dashboard # optional
      icon: admin-dashboard # optional

Are we ok having the icon value as a key like string? The intention being any components displaying links would have the option of using this icon key to map to an appropriate react icon. This approach would provide the most flexibility but would put more work on the maintainers of backstage. Although, I suspect it could be extended to make this easier and more automatic.

@andrewthauer Yep! As long as we also include at least a rudimentary icon system in the initial PR, perhaps with just a couple of hardcoded icons, but with some clear IDs of how to expand and making them configurable.

@andrewthauer Yep! As long as we also include at least a rudimentary icon system in the initial PR, perhaps with just a couple of hardcoded icons, but with some clear IDs of how to expand and making them configurable.

@Rugvip 2 years later, any chance for a extended icon system? why it's not possible to load any MUI icon by name?

We've talked recently (after #17474) about how it might make sense to introduce something like an iconsApi or similar. Nothing promised or designed yet, though. Loading MUI icons by name could be one of those implementations, but I'm not sure how that would work in practice. Drawback of that is that now you forcibly package the entire huge MUI icons library in your bundle, no matter how few of them are used in practice. Maybe some allowlist or so then? I don't know.


中英文无法切换

默认英文界面，但是点选简体中文之后原窗口关闭，出来的新窗口依然是英文。

That is because you installed Yixin-Board to the system directory (Program Files folder), and any changes to that directory require administrator privileges.  So if you would like to modify its settings, you need to run Yixin-Board with administrator privileges, or you should install Yixin-Board to non-system directory.


Tags and Recursion should suspend effects

When a tag or recursion on an Actor is not selected, then any active effects on the tag/recursion should be suppressed (set the effect to "suspended")

Done in 1.2.0


Need guidance for Defender for Endpoint customers to turn on Endpoint DLP

Under Settings>Device onboarding>Devices in the compliance portal, there is a "Turn on Windows device monitoring" button that enables the Endpoint DLP functionality.  For customers who start out with Defender for Endpoint and want use Endpoint DLP, it's not mentioned in this page that this master switch needs to be turned on.  Can you please add a screenshot and bullet that indicates this option must be enabled?

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

ID: 820cb23f-f33d-241d-5ce2-1d824bcd3747
Version Independent ID: 36d24f60-27b6-f2c1-ccda-1b49a1d4f073
Content: Learn about Microsoft 365 Endpoint data loss prevention - Microsoft 365 Compliance
Content Source: microsoft-365/compliance/endpoint-dlp-learn-about.md
Service: o365-seccomp
GitHub Login: @chrfox
Microsoft Alias: chrfox

@msbemba

@jmmowrer Thank you for your feedback. We have made changes to the document via PR#https://github.com/MicrosoftDocs/microsoft-365-docs/pull/7398
Once the author approves, the document will be updated.
Thanks
Sri

@msbemba Thank you very much for the contribution and updating the documentation with PR. @jmmowrer Hope this update is helpful for you. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


TransactionCost::SimpleVote doesn't report correct number of sigs for two-sig votes

Problem
TransactionCost has two cases in the enum; SimpleVote and Transaction. A SimpleVote is defined by these things:
https://github.com/anza-xyz/agave/blob/11aa06d24f22f9f464bf46edcf82d684b3c26bf2/cost-model/src/transaction_cost.rs#L8-L10
Note that a SimpleVote can contains 1 or 2 signatures, but TransactionCost::num_transaction_signatures() reports a fixed value of 1 for simple votes:
https://github.com/anza-xyz/agave/blob/11aa06d24f22f9f464bf46edcf82d684b3c26bf2/cost-model/src/transaction_cost.rs#L95-L100
This doesn't affect actual fees or CU's in the way things are currently written, but for the sake of accurate counting, it is incorrect.
Proposed Solution
Update SimpleVote to track the number of signatures:
https://github.com/anza-xyz/agave/blob/11aa06d24f22f9f464bf46edcf82d684b3c26bf2/cost-model/src/transaction_cost.rs#L15
and populate that field here:
https://github.com/anza-xyz/agave/blob/11aa06d24f22f9f464bf46edcf82d684b3c26bf2/cost-model/src/cost_model.rs#L40-L42

Not super high priority to fix at the moment, one of us will pick it up eventually

Just want to clarify here for later - transactions are still charged the correct fee, for 2 signatures, it is just not properly accounted for by cost-model.


Some improve for youtube stream

Add options to download function
Some optimization for stream download

Just use split then sometimes we can get this error
SyntaxError: Unexpected token ; in JSON at position 7079
    at JSON.parse (<anonymous>)
    at Object.getVideoInfo (/home/ubuntu/bot/node_modules/youtube-scrapper/dist/functions/getVideoInfo.js:14:23)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async download (/home/ubuntu/bot/node_modules/youtube-scrapper/dist/functions/download.js:12:19)

@Rubenennj
I add some major change of download and search. Can you review and merge this PR?

However "speaker" does not support Node.js 15.x.x and 16.x.x.
So we should change test code that use "speaker" module.
Is there any good solution?


Is there a possibility to support Storybook 7 (beta) ?

It would be nice to be able to use your addon with Storybook 7.
Would you be able to do it or you're going to wait until Storybook 7 will release a stable version ?

Hello, to be honest I don't have much time until at least mid-march, and there is already some work to do in order to support data router.
I don't know what needs to be done to support storybook v7 and don't have time to investigate. If you have some insight and/or can make a PR I'm more than willing take a look and merge it.

Ok thanks for the quick response, I completly understand, no problem.
I'll look into it if I have a bit of time too :wink:

just bumping some package versions seems to not be causing any obvious issues for me - i'll continue to look into it too 🕵
 @storybook/addon-essentials  ^6.4.0  →  ^7.0.0-beta.45
 @storybook/react             ^6.4.0  →  ^7.0.0-beta.45
 react-router                 ^6.3.0  →          ^6.8.1
 react-router-dom             ^6.3.0  →          ^6.8.1

It's working with the v7. I have those following versions:
    "storybook": "^7.0.0-rc.6"
    "storybook-addon-react-router-v6": "^0.3.4"

One issue that I have, but not sure if related to Storybook v7 or if it was already there in v6: I cannot update props automatically using the UI if withRouter is set in the decorators.

I've started to take a look into v7. Indeed the addon is not impacted directly.
I will still create a new version for SB7 in order to move away from now deprecated APIs, but also in order to harvest the new typescript support !

I found a problem with a peer dependency on<EMAIL_ADDRESS>I get this conflict:
<EMAIL_ADDRESS>from<EMAIL_ADDRESS><EMAIL_ADDRESS>from<EMAIL_ADDRESS>

I'll publish the new version next Thursday

@JesusTheHun I tried but I got an issue on a story with a NavLink component with the following error : Error: useLocation() may be used only in the context of a <Router> component

@bastiengrignon can you share your story ? This is very likely an issue with your story

Maybe you should ask on SO ? I don't mind helping but this place is for issues you have identified with the add-on.

Support for Storybook 7 has been added with version 1.0.0


[BUG] task-fractional tomspunt

Which module is this from?

beh
What is the issue?

the onset of the blocked questions are incorrect
What was your expected behavior?

The onset of each keyword presentation would be different. However, they are the same across 8 trals
Any additional context?

The original behavioral files might be incorrect
This is not a critical error, because the keywords are short and we ignore them from the model.
If the onset of each keyword is unrecoverable, I will plan to discard them from the events.tsv in general

Resolved via 340678e
Removed redundant block onset recordings


<IP_ADDRESS> Not importing HDR Master Display

I recently tried <IP_ADDRESS>.   I had been using <IP_ADDRESS>.  The settings are the same.  I am missing HDR info after encoding with <IP_ADDRESS>.   <IP_ADDRESS> is not automatically importing the Master Display like <IP_ADDRESS> did.

MediaInfo has changed, It longer outputs all Color Coordinates, Due to this allot of data reading had to be changed. StaxRip currently only supports HDR10  Standards. The ColorSpace must be BT.2020 If it reads anything else it will reject the MasterDisplay data.
HDR10 = BT.2020 & ST.2084 or BT.2100.

I updated StaxRip <IP_ADDRESS> to MediaInfo 18.08.1 and it stopped importing the Master Display data, so I guess MediaInfo is causing this.
I rip all my 4K UHD disc with MakeMKV, and with almost all of my UHD disc rips the ColorSpace is YUV, the Color Primaries is BT.2020, and the Mastering Display Color Primaries is Display P3.
I could manually input the P3 coordinates and Mastering Display Luminance, but that seems like an awful amount of work when it used to import automatically.  Or, is that information not really needed?  I am only concerned with maintaining the HDR10 which is the disc standard and not HDR10+ or DolbyVision, none of which my TVs support anyways.
In the meantime, I guess I will go back to using <IP_ADDRESS> as I was happy with the results and it maintained all of the information.  I have seen the Mastering Display Luminance vary greatly from disc to disc and my thought is that they wouldn't include that if it wasn't needed.

MediaInfo removed The color Coordinates which directly ties to MasterDisplay VUI Import function.
Old MediaInfo Was always reporting improper Color Matrix, No matter what version your going to use, It will not import all the proper data.
It's just going take some time to add additional functions to cover all the different HDR formats.
FYI, old version doesn't inject the remain HDR10 metadata, Which new version does.
HDR10+ is another giant PIA. Which hasn't not been fully added to x265. Dolby Vision requires double layer container.


feat: init project & namespace

This PR addresses #204 .
Changes
This PR introduces a new command to initialize Optimus client config interactively.
optimus init

For this PR to be merged, this PR and this PR should be merged.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 74.405%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
5596

Relevant Lines:
7521

💛  - Coveralls


NVIDIA GPU Int8 Support

Wrap CUDNN Int8 Operators @reminisce

[ ] fully connected
[ ] conv
[ ] pooling (max, avg)
[ ] activation (relu)

Pascal Int8 Operators @reminisce
Volta Int8 Operators @Laurawly

Please feel free to edit and extend the details. @reminisce @Laurawly

we only have a single gpu, tesla p4, supporting int8 well. let's just focus on it.

close due to stale state, will open a new issue when there is ongoing int8 ops


Conversions not handling boolean Value correctly

Conversions not handling boolean Value correctly
does not call toBoolean on Value

I am pretty sure I fixed this.