text:
Less than expected number of concurrent events in dispatcher

Describe the bug
Events consumption is too slow and either partitions are not being consumed concurrently or events were not being forwarded concurrently.
Expected behavior
Let's say we have a Kafka client running and consuming from 50 partitions, we should see events from 50 partitions being consumed and sent concurrently.
To Reproduce
Use a topic of more than 20 partitions and print out concurrent connections in sink and one should find out about this issue.
Knative release version
Additional context
Add any other context about the problem here such as proposed priority

@steven0711dong I think to reproduce you need sinks that are slow to consume (like a few seconds) so you can count how many concurrent connections and have them blocking dispatcher for long enough?
@pierDipi @aavarghese when number of consumers is increased in  consumergroups.internal.kafka.eventing.knative.dev is there any increase for outbound HTTP connections? It seems that on golang Sarama client we had simple consumers that had concurrent connections (up to number of Kafka topic partitions) and each maintained its own outgoing HTTP connection?

@aslom I think to reproduce you need sinks that are slow to consume (like a few seconds) so you can count how many concurrent connections and have them blocking dispatcher for long enough? ---> Yes, you need a sink that mimic a delay. I previously sent my customizedSinkDelay to our channel, you can take a look.

I tried setting maxPoolSize = 300 and it doesn't really help. Then, I also tried explicitly setting this
this.webClientOptions.setMaxPoolSize(300);

And I have not seen any increased number of connection from dispatcher to sink.

That's the maximum number, if you don't see an increase in connections, it means that the client doesn't need more connections to dispatch events.

I'm still puzzled about why we're looking at connections vs actual events

That's the maximum number, if you don't see an increase in connections, it means that the client doesn't need more connections to dispatch events.
I'm looking at connection because the speed of dispatching event does not match event consumption. I added some code in dispatcher that prints out the number of events consumed and clearly event consumption is so fast and events are just sitting in memory and dispatching event is so slow at 5 events / second.

That's the maximum number, if you don't see an increase in connections, it means that the client doesn't need more connections to dispatch events.

I'm looking at connection because the speed of dispatching event does not match event consumption. I added some code in dispatcher that prints out the number of events consumed and clearly event consumption is so fast and events are just sitting in memory and dispatching event is so slow at 5 events / second.

That's the maximum number, if you don't see an increase in connections, it means that the client doesn't need more connections to dispatch events.

I'm looking at connection because the speed of dispatching event does not match event consumption. I added some code in dispatcher that prints out the number of events consumed and clearly event consumption is so fast and events are just sitting in memory and dispatching event is so slow at 5 events / second.

That's a signal the connections aren't the problem here.

can you share a minimal reproducer that I can just run? because that's definitely not what I've seen.
Note: KafkaSource uses per-partition ordered delivery which means we can only dispatch "num partitions" events in parallel.

An ordered consumer is a per-partition blocking consumer that waits for a successful response from the CloudEvent subscriber before it delivers the next message of the partition.

Exactly, I have tested with 50 and 100 partitions on a Kafka source and the maximum concurrent events I've got is 15-20.

@steven0711dong what is the setup when you see low number of concurrent connections? Is it the same as https://github.com/aslom/reproduce-kafka-source/tree/main/duplicates1 ?
When running it after scaling kafka source to 25
k scale --replicas=25 kafkasources/kafka-src50

I see 7 concurrent connections (with 10 seconds delay for response)
k logs event-display-00001-deployment-5c844bf9bc-9pfjw -f
....
afka-src50/topic50/0/272
kafka-src50/topic50/0/273
{"level":"info","ts":1654709775.2083042,"logger":"fallback","caller":"customizeEventDisplay/evendisplay.go:171","msg":"Host: event-display-00001-deployment-5c844bf9bc-9pfjw: we have 8 concurrent connections\n"}
{"level":"info","ts":1654709775.9962575,"logger":"fallback","caller":"customizeEventDisplay/evendisplay.go:161","msg":"event-display-00001-deployment-5c844bf9bc-9pfjw rcv'd response from scraper status code: 200 content: Scraper has received kafka msg stats from sink.\n"}
{"level":"info","ts":1654709776.2086298,"logger":"fallback","caller":"customizeEventDisplay/evendisplay.go:171","msg":"Host: event-display-00001-deployment-5c844bf9bc-9pfjw: we have 8 concurrent connections\n"}
{"level":"info","ts":1654709777.2095642,"logger":"fallback","caller":"customizeEventDisplay/evendisplay.go:171","msg":"Host: event-display-00001-deployment-5c844bf9bc-9pfjw: we have 8 concurrent connections\n"}
{"level":"info","ts":1654709778.2097266,"logger":"fallback","caller":"customizeEventDisplay/evendisplay.go:171","msg":"Host: event-display-00001-deployment-5c844bf9bc-9pfjw: we have 8 concurrent connections\n"}
{"level":"info","ts":1654709779.2104332,"logger":"fallback","caller":"customizeEventDisplay/evendisplay.go:171","msg":"Host: event-display-00001-deployment-5c844bf9bc-9pfjw: we have 8 concurrent connections\n"}
{"level":"info","ts":1654709780.211316,"logger":"fallback","caller":"customizeEventDisplay/evendisplay.go:171","msg":"Host: event-display-00001-deployment-5c844bf9bc-9pfjw: we have 8 concurrent connections\n"}
kafka-src50/topic50/0/16
{"level":"info","ts":1654709780.9970222,"logger":"fallback","caller":"customizeEventDisplay/evendisplay.go:161","msg":"event-display-00001-deployment-5c844bf9bc-9pfjw rcv'd response from scraper status code: 200 content: Scraper has received kafka msg stats from sink.\n"}
{"level":"info","ts":1654709781.2123709,"logger":"fallback","caller":"customizeEventDisplay/evendisplay.go:171","msg":"Host: event-display-00001-deployment-5c844bf9bc-9pfjw: we have 8 concurrent connections\n"}
...

That's the maximum number, if you don't see an increase in connections, it means that the client doesn't need more connections to dispatch events.

I'm looking at connection because the speed of dispatching event does not match event consumption. I added some code in dispatcher that prints out the number of events consumed and clearly event consumption is so fast and events are just sitting in memory and dispatching event is so slow at 5 events / second.

That's a signal the connections aren't the problem here.

The connection I'm talking about is the concurrent events sink receives. What do you mean by signal?

When running tests I see this
kubectl -n kafka run kafka-consumer -ti --image=quay.io/strimzi/kafka:0.28.0-kafka-3.1.0 --rm=true --restart=Never -- bin/kafka-consumer-groups.sh --bootstrap-server my-cluster-kafka-bootstrap:9092 --describe  --group kafka-src50b
If you don't see a command prompt, try pressing enter.

Consumer group 'kafka-src50b' has no active members.

GROUP           TOPIC           PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG             CONSUMER-ID     HOST            CLIENT-ID
kafka-src50b    topic50         0          29              5000            4971            -               -               -
pod "kafka-consumer" deleted

So it seems like Kafka data-plane consumed all messages and disconnected and may connect later to update CURRENT-OFFSET ?

It seems there is something strange with Strimzi that it created topic but only with one partition - debugging it ...

@pierDipi to reproduce @steven0711dong test setup and see number of concurrent connections with Strimzi:
export KO_DOCKER_REPO=...
git clone https://github.com/aslom/reproduce-kafka-source.git
cd reproduce-kafka-source
ko apply -f duplicates1

Then check that all pods started and see logs and curl output
k get po
k logs duplicates1-kafkaproduce-job1-???
k logs event-display-???
kubectl run curl --image=curlimages/curl --rm=true --restart=Never -ti -- -v http://kafkascraper/stats

To see if it was data plane stuck I have killed pod and it started delivering events
k -n knative-eventing delete po kafka-source-dispatcher-0

ubectl run curl --image=curlimages/curl --rm=true --restart=Never -ti -- http://kafkascraper/stats
source kafka-src50 received: 121 messages, 125 are dups and 0 non 200s.
pod "curl" deleted

seeing about 5 concurrent connections
 k logs event-display-00001-deployment-6d55dc75bc-tb7pd | tail -20
Defaulted container "user-container" out of: user-container, queue-proxy
{"level":"info","ts":1654714031.1334,"logger":"fallback","caller":"customizeEventDisplay/evendisplay.go:171","msg":"Host: event-display-00001-deployment-6d55dc75bc-tb7pd: we have 5 concurrent connections\n"}
{"level":"info","ts":1654714032.1339068,"logger":"fallback","caller":"customizeEventDisplay/evendisplay.go:171","msg":"Host: event-display-00001-deployment-6d55dc75bc-tb7pd: we have 5 concurrent connections\n"}
{"level":"info","ts":1654714033.1339917,"logger":"fallback","caller":"customizeEventDisplay/evendisplay.go:171","msg":"Host: event-display-00001-deployment-6d55dc75bc-tb7pd: we have 5 concurrent connections\n"}
{"level":"info","ts":1654714034.1341753,"logger":"fallback","caller":"customizeEventDisplay/evendisplay.go:171","msg":"Host: event-display-00001-deployment-6d55dc75bc-tb7pd: we have 5 concurrent connections\n"}
{"level":"info","ts":1654714035.1344326,"logger":"fallback","caller":"customizeEventDisplay/evendisplay.go:171","msg":"Host: event-display-00001-deployment-6d55dc75bc-tb7pd: we have 5 concurrent connections\n"}
kafka-src50/topic50a/21/24
kafka-src50/topic50a/42/24
kafka-src50/topic50a/33/24
kafka-src50/topic50a/9/24
kafka-src50/topic50a/30/24
{"level":"info","ts":1654714035.9646325,"logger":"fallback","caller":"customizeEventDisplay/evendisplay.go:161","msg":"event-display-00001-deployment-6d55dc75bc-tb7pd rcv'd response from scraper status code: 200 content: Scraper has received kafka msg stats from sink.\n"}
{"level":"info","ts":1654714036.134995,"logger":"fallback","caller":"customizeEventDisplay/evendisplay.go:171","msg":"Host: event-display-00001-deployment-6d55dc75bc-tb7pd: we have 5 concurrent connections\n"}
{"level":"info","ts":1654714037.13519,"logger":"fallback","caller":"customizeEventDisplay/evendisplay.go:171","msg":"Host: event-display-00001-deployment-6d55dc75bc-tb7pd: we have 5 concurrent connections\n"}
{"level":"info","ts":1654714038.1361284,"logger":"fallback","caller":"customizeEventDisplay/evendisplay.go:171","msg":"Host: event-display-00001-deployment-6d55dc75bc-tb7pd: we have 5 concurrent connections\n"}
{"level":"info","ts":1654714039.136801,"logger":"fallback","caller":"customizeEventDisplay/evendisplay.go:171","msg":"Host: event-display-00001-deployment-6d55dc75bc-tb7pd: we have 5 concurrent connections\n"}
{"level":"info","ts":1654714040.1378953,"logger":"fallback","caller":"customizeEventDisplay/evendisplay.go:171","msg":"Host: event-display-00001-deployment-6d55dc75bc-tb7pd: we have 5 concurrent connections\n"}
{"level":"info","ts":1654714040.9655924,"logger":"fallback","caller":"customizeEventDisplay/evendisplay.go:161","msg":"event-display-00001-deployment-6d55dc75bc-tb7pd rcv'd response from scraper status code: 200 content: Scraper has received kafka msg stats from sink.\n"}
{"level":"info","ts":1654714041.1389263,"logger":"fallback","caller":"customizeEventDisplay/evendisplay.go:171","msg":"Host: event-display-00001-deployment-6d55dc75bc-tb7pd: we have 5 concurrent connections\n"}
{"level":"info","ts":1654714042.139247,"logger":"fallback","caller":"customizeEventDisplay/evendisplay.go:171","msg":"Host: event-display-00001-deployment-6d55dc75bc-tb7pd: we have 5 concurrent connections\n"}
{"level":"info","ts":1654714043.1399586,"logger":"fallback","caller":"customizeEventDisplay/evendisplay.go:171","msg":"Host: event-display-00001-deployment-6d55dc75bc-tb7pd: we have 5 concurrent connections\n"}

and it shows as well with offset lag for paritions
kubectl -n kafka run kafka-consumer-groups -ti --image=quay.io/strimzi/kafka:0.28.0-kafka-3.1.0 --rm=true --restart=Never -- bin/kafka-consumer-groups.sh --bootstrap-server my-cluster-kafka-bootstrap:9092 --describe  --group kafka-src50b
If you don't see a command prompt, try pressing enter.

Consumer group 'kafka-src50b' has no active members.

GROUP           TOPIC           PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG             CONSUMER-ID     HOST            CLIENT-ID
kafka-src50b    topic50a        25         0               100             100             -               -               -
kafka-src50b    topic50a        16         0               100             100             -               -               -
kafka-src50b    topic50a        28         0               100             100             -               -               -
kafka-src50b    topic50a        5          0               100             100             -               -               -
kafka-src50b    topic50a        24         0               100             100             -               -               -
kafka-src50b    topic50a        1          0               100             100             -               -               -
kafka-src50b    topic50a        6          0               100             100             -               -               -
kafka-src50b    topic50a        18         0               100             100             -               -               -
kafka-src50b    topic50a        48         0               100             100             -               -               -
kafka-src50b    topic50a        26         0               100             100             -               -               -
kafka-src50b    topic50a        38         0               100             100             -               -               -
kafka-src50b    topic50a        36         0               100             100             -               -               -
kafka-src50b    topic50a        43         0               100             100             -               -               -
kafka-src50b    topic50a        13         0               100             100             -               -               -
kafka-src50b    topic50a        29         0               100             100             -               -               -
kafka-src50b    topic50a        2          0               100             100             -               -               -
kafka-src50b    topic50a        15         0               100             100             -               -               -
kafka-src50b    topic50a        20         0               100             100             -               -               -
kafka-src50b    topic50a        32         0               100             100             -               -               -
kafka-src50b    topic50a        39         0               100             100             -               -               -
kafka-src50b    topic50a        9          29              100             71              -               -               -
kafka-src50b    topic50a        46         0               100             100             -               -               -
kafka-src50b    topic50a        35         0               100             100             -               -               -
kafka-src50b    topic50a        49         0               100             100             -               -               -
kafka-src50b    topic50a        12         0               100             100             -               -               -
kafka-src50b    topic50a        7          0               100             100             -               -               -
kafka-src50b    topic50a        31         0               100             100             -               -               -
kafka-src50b    topic50a        42         29              100             71              -               -               -
kafka-src50b    topic50a        19         0               100             100             -               -               -
kafka-src50b    topic50a        45         0               100             100             -               -               -
kafka-src50b    topic50a        8          0               100             100             -               -               -
kafka-src50b    topic50a        27         0               100             100             -               -               -
kafka-src50b    topic50a        4          0               100             100             -               -               -
kafka-src50b    topic50a        41         0               100             100             -               -               -
kafka-src50b    topic50a        34         0               100             100             -               -               -
kafka-src50b    topic50a        0          0               100             100             -               -               -
kafka-src50b    topic50a        23         0               100             100             -               -               -
kafka-src50b    topic50a        11         0               100             100             -               -               -
kafka-src50b    topic50a        30         29              100             71              -               -               -
kafka-src50b    topic50a        14         0               100             100             -               -               -
kafka-src50b    topic50a        21         29              100             71              -               -               -
kafka-src50b    topic50a        44         0               100             100             -               -               -
kafka-src50b    topic50a        37         0               100             100             -               -               -
kafka-src50b    topic50a        22         0               100             100             -               -               -
kafka-src50b    topic50a        3          0               100             100             -               -               -
kafka-src50b    topic50a        10         0               100             100             -               -               -
kafka-src50b    topic50a        17         0               100             100             -               -               -
kafka-src50b    topic50a        47         0               100             100             -               -               -
kafka-src50b    topic50a        33         29              100             71              -               -               -
kafka-src50b    topic50a        40         0               100             100             -               -               -
pod "kafka-consumer-groups" deleted

Only 5 parittions it seems are concumed

I ran the duplicates1 scenario about 3-4 times and each time with replicas eventually scaled to 50 vreplicas, I'm seeing very few duplicates (results below). I have to figure out why my environment is a bit different but the code is the same as Steven's + Alek's (main branch with CM changes to enable Rate Limiter. etc)
Time taken for each run was less an hour (about 45-50 mins)
source kafka-src50 received: 5000 messages, 0 are dups and 0 non 200s.

source kafka-src50 received: 5000 messages, 3 are dups and 0 non 200s.

source kafka-src50 received: 5000 messages, 1 are dups and 0 non 200s.

@aslom @steven0711dong can you try with a sticky partition? (Change code: https://github.com/knative-sandbox/eventing-kafka-broker/compare/main...aavarghese:incrementalassignor#diff-a792859cd3777e5daafc49222b325b03ef98c7544b8e18347d2c5a8dbb3597fcR77)

I will try it with your config..

authors: aavarghese aslom pierDipi steven0711dong

repo: knative-sandbox/eventing-kafka-broker


text:
[main] Update community files

Cron -knative-prow-robot
/cc knative-sandbox/client-writers
/assign knative-sandbox/client-writers
Produced by: knative-sandbox/knobots/actions/update-community
Details:

/verify-owners

/approve
/lgtm

/approve
/lgtm

source: gharchive/pull-request

authors: csantanapr knative-automation rhuss

repo: knative-sandbox/homebrew-kn-plugins

license_type: permissive

license_source: bigquery


text:
[main] Update actions

Cron -knative-prow-robot
/cc knative/client-wg-leads
/assign knative/client-wg-leads
Produced by: knative-sandbox/knobots/actions/update-actions
Details:

/approve
/lgtm

authors: knative-automation rhuss

repo: knative/client-pkg


text:
TestVisibility hitting a number of connection refused errors

With and without split:
--- FAIL: TestVisibility (18.02s)
    visibility_test.go:39: [visibility-elozhoiu] Using port 92
    visibility_test.go:39: [visibility-elozhoiu] Using containerPort 8090
    visibility_test.go:64: Error making GET request: Get http://visibility-abfidose.serving-tests.svc.cluster.local: dial tcp 34.71.45.97:80: connect: connection refused
    visibility_test.go:67: [visibility-lmebvknk] Using port 82
    visibility_test.go:67: [visibility-lmebvknk] Using containerPort 8097
--- FAIL: TestVisibilitySplit (97.77s)
    visibility_test.go:108: [visibility-split-bvudnwlc] Using port 79
    visibility_test.go:108: [visibility-split-bvudnwlc] Using containerPort 8058
    visibility_test.go:108: [visibility-split-jwcgooxf] Using port 57
    visibility_test.go:108: [visibility-split-jwcgooxf] Using containerPort 8020
    visibility_test.go:108: [visibility-split-xvjtxrgv] Using port 74
    visibility_test.go:108: [visibility-split-xvjtxrgv] Using containerPort 8094
    visibility_test.go:108: [visibility-split-nsnxvrad] Using port 57
    visibility_test.go:108: [visibility-split-nsnxvrad] Using containerPort 8063
    visibility_test.go:108: [visibility-split-ujvwtfyv] Using port 95
    visibility_test.go:108: [visibility-split-ujvwtfyv] Using containerPort 8034
    visibility_test.go:108: [visibility-split-msrogntp] Using port 96
    visibility_test.go:108: [visibility-split-msrogntp] Using containerPort 8005
    visibility_test.go:108: [visibility-split-rvcscqii] Using port 94
    visibility_test.go:108: [visibility-split-rvcscqii] Using containerPort 8073
    visibility_test.go:108: [visibility-split-jjmjmaej] Using port 92
    visibility_test.go:108: [visibility-split-jjmjmaej] Using containerPort 8007
    visibility_test.go:108: [visibility-split-meudfqwn] Using port 53
    visibility_test.go:108: [visibility-split-meudfqwn] Using containerPort 8096
    visibility_test.go:108: [visibility-split-gwgtbvzt] Using port 97
    visibility_test.go:108: [visibility-split-gwgtbvzt] Using containerPort 8037
    visibility_test.go:152: Error making GET request: Get http://visibility-split-jioorbfb.serving-tests.svc.cluster.local: dial tcp 34.71.45.97:80: connect: connection refused
    visibility_test.go:155: [visibility-split-ikxjnobf] Using port 79
    visibility_test.go:155: [visibility-split-ikxjnobf] Using containerPort 8034

@andrew-su are you up for taking a look (I think you added this test)?

/assign

From our investigation, when the ingress has no external traffic configured it seems to refuse connections to port 80 of the ingress.
When this is run as part of the test suite, depending on the parallel tests running there may be a publicly exposed knative ingress resource thus opening port 80 for connection. When running the test by itself, it has a much higher chance of exhibiting the above behaviour.
/cc @shashwathi

So is the problem that it doesn’t fail the way it “should”?  Isn’t this a perfectly acceptable failure mode?  Test bug?

Right, the check is not failing the way it should because we were expecting the ingress to respond with a 404 but got a connection refused. This is an acceptable failure in the eyes of the test (not handled). However, the error comes from the client being unable to connect to the envoy proxy since the proxy itself doesn't listen on port 80 if it doesn't have anything to proxy to.
The error of connection refused is difficult to detect as it is returned as a generic error similar to other http client errors; making it hard to differentiate from when we have a legit test failure.
We could parse the error message and check if it contains "connection refused" but that doesn't seem very correct.

What is the type of the error?  Infof("%T", err)?
I'm wondering if we can check for something like if _, ok := err.(*net.OpError); ok { // fine

IIUC we will need to update-deps and remove the V from our Test[^UV] line, right?

IIUC we will need to update-deps and remove the V from our Test[^UV] line, right?

Yup. (Also, what does IIUC stand for?)

If I Understand Correctly (I also use IIRC a lot, which is "Recall").  Sorry 😬

Thanks!
Closing because PR is accepted.
/close

We never removed the test skip.  Sent a PR 😅

source: gharchive/issue

authors: andrew-su mattmoor

repo: knative/net-contour

license_source: github-api


text:
Update duck/ABOUT.md

Problem
Some of the urls and methods used on the example are outdated or deprecated. Like "controller.NewImpl"
Persona:
Producers, consumers and integrators
Exit Criteria
Update the links and methods used on the file
Additional context (optional)
Here

/assign

repo: knative/pkg


text:
browser: Simplify title address extraction

This refactors the browser.address implementation to be clearer, making the following changes along the way:

The same word is no longer checked to be a valid URL twice.
Check the first word is a URL before checking the rest of the words in reverse. The suggested Firefox extension prepends the URL to the window title (and does not wrap it in brackets).
Avoid checking the empty string, in case a webpage has consecutive spaces in its title.

Thanks!

authors: auscompgeek splondike

license: MIT


text:
Add Nim hello world

Related to #1. As noted here, Nimrod is now known as Nim.

Thanks, merged.

authors: alebcay uwx

license: unlicense


text:
Question about Knopflerfish R7 compatibility for SCR

Hey :)
Sorry if I overlooked information which shows this question in your website, or if I am posting on the wrong place. I want to ask - does Knopflerfish SCR have any R7 Compendium features right now, or are they planned for the future ? If there are any, which? I saw in https://www.knopflerfish.org/kf7_osgi_r7.html that the module's R7 status is "NYI" - Not Yet Implemented.
Thank you very much!
Velitchko

Hi, there is not yet any R7 SCR in KF.
The framework is almost R7 complete, but SCR is one piece that is still missing.
An R7 release is planned. Can't commit to any date yet though ;-)
Regards,
Christer

Okay,thanks a lot for the information :)


text:
Change colors of Arrowheads & Lines in Graph when Night theme is applied

https://mermaidjs.github.io/ renders the lines & arrowheads in a graph with dark color for all themes which results in disappearing lines & arrowheads when Night theme is applied
Screenshots of both White & Night themes for reference

White Theme
Night Theme

I can raise a PR if given some direction

repo: knsv/mermaid

license: mit


text:
added two new embedding model's encoding

See: https://github.com/openai/tiktoken/pull/247

thanks for the ping, I added them and they will be available in 1.0.0

authors: paplorinc tox-p

repo: knuddelsgmbh/jtokkit


text:
global_logger + printer for non-realtime logging?

Afaict all the existing global loggers assume you are one with the uC via RTT or semihosting or similar. Are you aware of any logger, or plans for one, that would support yeeting the log frames into memory / SD card, and then decoding them later?

I have created this to eventually be used at my workplace: https://github.com/BlackbirdHQ/defmt-persist
I would be happy to see it gain some OS adoption, and are more than happy to take contributions.
It is still a WIP, and currently hangs a bit on a few blockers, main one being:

embedded-storage repo (in progress: https://github.com/rust-embedded/embedded-hal/pull/241#issuecomment-726601960)
Framing options in defmt (https://github.com/knurling-rs/defmt/issues/185)

Basically I make use of an embedded-storage trait to work as storage space (stack/heap, SD-card, file system, flash storage etc), where i implement a BIP style circular buffer on top, with the first N bytes allocated as header.
I then store each log message with a CRC checksum in a COBS encoded format, making it easy to distinguish frames from each other, and some functions to retreive the log frames afterwards (how you then transfer the frames are up to you. Could be RTT, semihosting, network, etc. In my case I am using MQTT)
I have a small static queue to make sure we can move the long running workload of writing to storage, into some low priority idle function, inspired a bit by cortex-m-funnel.
So basically:
#[global_logger] ---> queue ---> Storage ---> Transport
                              ^ In idle     ^ On request

Nice! I've started on a global logger that just puts everything into a circular buffer, with the aim that user-code will service the buffer and send it to the computer via UART. It didnt work however and I need to debug it, so I'm keen to use the queue/buffer bits of defmt-persist instead :)
My current focus is on the formatting hints PR, but let me know if theres anything I can help with I can circle back to and help out!

Yeah, i already added that to defmt-persist, but i probably should add a few examples...
If you have a look in https://github.com/BlackbirdHQ/defmt-persist/blob/master/src/stack.rs, i have basically implemented the Storage traits needed for defmt-persist on any regular &'static [u8]
I do hope we can push for the storage traits to reach some release, where i don't have to tie the crate to a git dependency

We have now published defmt-print, a command-line tool that decodes defmt frames from stdin. This should be helpful for custom defmt pipelines, including decoding log frames "post-mortem".

We have now published defmt-print, a command-line tool that decodes defmt frames from stdin. This should be helpful for custom defmt pipelines, including decoding log frames "post-mortem".

Given that all pieces you need to implement arbitrary defmt storage and transport solutions, closing this as fixed.

Given that all pieces you need to implement arbitrary defmt storage and transport solutions, closing this as fixed.

repo: knurling-rs/defmt


text:
Migrate to Jest and Github Actions

[!IMPORTANT]
This PR line diff is MASSIVE, but the bulk of it comes from including the package-lock.json

Changes and motivation
The package-lock.json
For some reason I don't fully understand the package-lock.json file was excluded from git version control. To add injury to insult: some of the devDependencies are listed as version ranges; meaning local installations of this package will result in different versions being installed.
In general it is recomended to include the lockfile into version control; so this PR includes it alongisde its removal from the .gitignore.
Jest
Currenty the repo uses mocha as its test framework and nyc to provide coverage reports. This PR drops both dependencies in favor of the latest version of jest.
Two main motivators behind this decission:

koajs/koa uses jest as its test runner; having a consistent test runner across projects helps with developer experience across packages.
Jest has native support for coverage collection; meaning we can drop nyc as a dependency and rely on one single tool for our testing needs.

Github Actions
Currenty the repo uses travis as its CI runner. This PR drops travis in favor of Github Actions.
Two main motivators behind this decission:

koajs/koa uses github actions as its ci environment. Again, the change brings consistency across projects.
I'm a huge proponent of an integrated workflow. Having code, PRs and checks in the same platform ease a lot the work when one of the checks fail.

You can find a run generated using this new config here.
Codecov coverage upload
The repo is using a now deprecated cli util npx codecov.
On the blog post regarding the deprecation they hint at using ecosystem-specific solutions; in particular they provide an official Github Action.
You can find a live version of the dashboard after the upload here.

[!IMPORTANT]
For these changes to work we will need to add a CODECOV_TOKEN secret to the repo secrets as described here

Drop official support for node10 through node17
Just following the node approach and supporting up to the last version under maintenance at the time of writing. See the node release working group schedule for reference.
What led you to doing these changes?
I attempted to include this pacakge in a project I'm working at the moment; but couldn't get it to work because it only exports a commonjs entrypoint and I'm working on a module project.
When I went looking into the repo for contributing with a change for adding module support I found a mostly out-of-date repo. So this is my first contribution of (hopefully) many in an attempt to bring this package up-to-date.

Hello @Souler, Thanks first for your contribution here. Yes, I am still maintaining the repo as much as I can.

repo: koajs/accesslog


text:
profile middleware

just a reminder to myself: use compose hook to create a profiler layer that will report durations spend in each layer

let's just solve this once in for all in koa-compose. how about something like this:
function compose(middleware, profiler){
  return function *(next){
    if (!next) next = noop();

    var i = middleware.length;

    while (i--) {
      var fn = middleware[i]
      var profile = profiler(middleware[i])
      next = function *(next) {
        profile.start()
        yield* next
        profile.end()
      }.call(this)
    }

    return yield *next;
  }
}

(Replying to https://github.com/koajs/koa/issues/196#issuecomment-192083703)
What I would like to do with profiling is to have a way to profile whole koa application, even if I am using middlewares that have already been composed in other libraries. In production, you never know where a bottleneck is going to come from so a view on other modules would be a +.
the profiling system should also have close to no impact in production if profiling is not activated.
The way I see it (I have no implementation and am not sure if it makes sense) would be something like the debug module.
a module exporting middlewares could have a profiling name a-la debug.
Then at runtime via 2 environment variables, I could

choose by name which middlewares I want to profile
define which profiler I want to use

I don't know if this makes sense to you.
Regarding the modification of koa-compose, I once proposed that we should be able to define our own composer (use koa-compose if you want no profiling, use `koa-compose-myprofiler' to have the behavior of myprofiler.
Adding the profiler variable directly to koa-compose adds some of this behavior but :

there is a systematic perf hit on the profiler mechanism even if I want no profiling
I don't see how I could profile third-party koa middlewares modules

Regarding the API, I proposed something in https://github.com/koajs/koa/issues/196#issuecomment-61021512 (maybe the code is not very clear). Basically, the idea to compose middleware was to

first map the middlewarearray to myprofiler(middleware[i])

    var myprofiler = function *myprofiler(next){
       // things to do before
       yield *gn.call(this, next);
       // things to do after
    }

and then call compose on this new array

The difference I see is that you version is synchronous (there is no way to wait on profile.start() and profile.end())
The API should probably give the user the choice of sync vs async.

I could see a usage for a "step by step" profiler/debugger where I need to click "next" at every stage.
I could also see scenarios where I could want to make sure something is logged before going to the next step even if it at a perf cost

But those scenarios are maybe far-fetched and I can live without them now.
Do we have some kind of list of applications that will be done with this profile mechanism / real world scenarios ? Do you know how the express, hapi or restify community handles profiling ?
I have heard (but never tried to confirm) that restify has done a good job for profiling via its DTrace probes - http://restify.com/#dtrace . Maybe that could be something to explore too.

:+1: on that API. Wrapping the middleware seems like the best way to provide opportunities to profile it. In addition, there would be no need to check if there are profilers every time a request is received.

oh yeah, no problem making the profiler async.
i don't think we want to integrate any specific tracing because there are just so many of them.
@jeromew would you like to make a PR to koa-compose? i think we're on the same page

though i'm not sure about the "choosing middleware by name" part. you could just use debug in the profiler as the profiler should receive the fn as an argument

What about having a app.profiler available, which Application.callback() passes to when composing?
koajs/compose/index.js (next branch)
function compose (middleware, profiler) {
  if (!Array.isArray(middleware)) throw new TypeError('Middleware stack must be an array!')
  if (profiler && typeof profiler !== 'function') throw new TypeError('Profiler needs be a function!')
  for (const fn of middleware) {
    if (typeof fn !== 'function') throw new TypeError('Middleware must be composed of functions!')
  }

  return function (context, next) {
    // last called middleware #
    let index = -1
    return dispatch(0)
    function dispatch (i) {
      if (i <= index) return Promise.reject(new Error('next() called multiple times'))
      index = i
      let fn
      if (profiler) fn = middleware[i] ? profiler(middleware[i]) : next
      else fn = middleware[i] || next
      if (!fn) return Promise.resolve()
      try {
        return Promise.resolve(fn(context, function next () {
          return dispatch(i + 1)
        }))
      } catch (err) {
        return Promise.reject(err)
      }
    }
  }
}

koajs/koa/lib/application.js#callback
  callback() {
    const fn = compose(this.middleware, this.profiler);

    if (!this.listeners('error').length) this.on('error', this.onerror);

    return (req, res) => {
      res.statusCode = 404;
      const ctx = this.createContext(req, res);
      onFinished(res, ctx.onerror);
      fn(ctx).then(() => respond(ctx)).catch(ctx.onerror);
    };
  }

example.js
app.profiler = function(fn) {
  return (ctx, next) => {
    const start = process.hrtime()[1]
    console.log(fn.name + ' > ' + start)
    return Promise.resolve(fn(ctx, next)).then(() => {
      const end = process.hrtime()[1] - start
      console.log(fn.name + ' < ' + end + ' (' + end/1000000 + ')')
    })
  }
}

app.use((ctx, next) => {
  console.log('start a')
  return next().then(() => {
    console.log('end of a')
  })
})

app.use((ctx, next) => {
  console.log('start b')
  return next().then(() => {
    console.log('end of b')
  })
})

app.use((ctx, next) => {
  console.log('start c')
  return next().then(() => {
    console.log('end of c')
  })
})

app.use((ctx, next) => {
  ctx.body = 'hello worl2d'
})

@fl0w I like the idea, I think that was the API discussed above. However, I'd prefer if it was called something more general than profiler, as the API isn't profiler specific. We should also consider if it should be an array, or just a single function.

@fl0w I think this is in line with what we are discussing (for the promise based version) but I don't know if we want a compulsory "everything-is-profiled" approach.
@jonathanong I haven't tried to push a PR because I am working on other subjects right now and even though this feature has been long standing I do not want to rush it in koa. profiling is a key feature for a mature framework and I think that options should be compared on real life scenarios - at least performance wise since wrapping every middleware is not a cheap operation.
As I see it profiling can already be done by something who accepts to wrap all its middlewares
app.use(wrap(mw1))
app.use(wrap(mw2))
app.use(wrap(mw3))

For logging purpose, I try to give names the middlewares
sometimes, I pre-compose middlewares like app.use(compose(mws)). This could be replaced by
app.use(composewrapper(mws, logger, "myname"))

which would compose a logger version of all the mws and give the name "myname" to the resulting middleware.
This gets burdensome at some point + there are probably subtleties when dealing with middlewares coming from other npm modules, or middlewares created/composed at runtime in specific branches inside a middleware.
What I would want is :

to be able to profile all the middlewares in an application or specific parts of an application ; maybe have a guideline for external modules so that they can become profileable.
with a clean API that would avoid the need to wrap every single middleware.
the profiler should be able to output an clear view of the middleware chain that the request went through

Is there already a big user-facing open source projet that use koa (like ghost or nodebb) that we could use as a testbed an say "let's add profiling to this project" ?

@PlasmaPower I agree, I used the term profiler for illustration-purposes. I think I agree the act of "wrapping" or "wrap" is more appropriate as you and @jeromew highlight.
@jeromew I think your cases are entirely possible with the proposition, but instead of hard-coding a "one size fits all"-solution, just delegate it to user space.
You could just have a wrap-mw that simulates what debug does, which listens to desired env. E.g. process.env.PROFILE=my:personal*.
One could also just not use the Koa provided app.profiler, instead opt to compose manually
app.wrap = false // default
app.use(compose(['my', 'middleware', 'stack', 'im', 'interested', 'in'], aProfilerIMade)

If I had some specific use cases or desires, I wouldn't expect Koa to solve app-specific probe:ing anyway.

Are there special quality requirements for Koa 2.0 middleware ? I mean things like tests for new features ? Maybe it could be a list of tasks ? If there is no list it would be nice if someone of the core developers give me a hint how to increase software quality from your point of view (to middleware developers). I would assume there is a feature list which should be checked whether there are use cases affecting a middleware which should cause writing a test within the middleware repository. I think also tips for processing such tasks would be helpful - for instance one could copy some tests from the core and change them by the middleware behavior.
My goal is to learn something by making the koa-sub-domain router 2.0 ... :smile:

@PlasmaPower @fl0w @jeromew sorry for not being more active. been a little busy. there's a bunch of PRs open that I haven't really looked into. here are my questions, and as long as we have a consensus on these, we should write them down somewhere in the docs and have tests for them. then, it is about implementation details, of which i prefer the simplest solution.

should mounted apps/routers wrap their middleware too?

for example, app.use(router) or app.use(anotherApp)
how do you handle apps with wrappers mounted onto another app with wrappers? parent app wrappers wrap the child app wrappers?

should every "decorator" be wrapped as well?

for example, koa-route wraps another middleware as an if-statement. should the koa-route decorator be wrapped as well the actual middleware being decorated? this allows you to debug that the routing logic was executed, but not the main logic
this could be chosen on a per-middleware basis (implementatiors will decide). we would then need some exposed function like app.wrap() or this.wrap() to make this easy for every middleware. or have middleware require a 3rd party module that calls the wrapped function

implementation questions (less important):

should we store the wrappers on app or on context? @PlasmaPower has convinced me that only having it on app would make routers more difficult since you would need to pass app to every middleware. maybe app.wrappers and have ctx.wrappers delegate to it?
should we wrap the last middleware (response)?

@koajs anyone else have questions? if someone wants to start a gist about the specs, that would be great

should mounted apps/routers wrap their middleware too?

I think everybody is assuming that yes, they should. This would be the same way as compose handles it.

how do you handle apps with wrappers mounted onto another app with wrappers? parent app wrappers wrap the child app wrappers?

I'd assume the child wrappers would get applied first, then the parent wrappers. However, I don't think you can currently mount a Koa app with use(), correct?

should every "decorator" be wrapped as well?

Yes, I think this makes the most sense and would allow for profilers to create a nice tree.

we would then need some exposed function like app.wrap() or this.wrap() to make this easy for every middleware

My newest PR implements this as app.prepareMiddleware (it also does some other stuff, hence the name). My older PR has this as it's own library.

should we store the wrappers on app or on context?

Most implementations store them in the context, but with mw._wrappers or mw.onUsed (the two most recent PRs) they can be stored in the app.

should we wrap the last middleware (response)?

I don't think any PRs currently do that, but I think we could (at least with my most recent PR, haven't checked the others). If we decide to do that, I can easily change my PR.

it seems like i'm the only collaborator really involved in this, and it's not something i want to be decide on alone.
@PlasmaPower thanks for your hardwork. do you want to try making this a separate module first that augments a koa app? we can add it to the org

Out of curiosity, would a wrapper be a middleware or a function returning a wrapped middleware? I'm so confused at this point I'm stalled.

@fl0w A function returning a wrapped middleware. For example, here's an extremely simple profiler:
let wrapper = function (mw) {

};

they decorate middleware. all the wrappers will decorate all the middleware.

@PlasmaPower @jonathanong Right, so that's equivalent to the very very first example I did.
So what's the negative about assigning the wrappers to mw._wrappers and let compose reduce by those if provided?

@fl0w Because compose doesn't reduce - with compose wrappers would just be middleware that ran before every middleware.

This would be a really handy feature to have. Are there any plans to continue this?

@RobertHerhold There's been so much bikesheeding at this point I'm not sure. Even then, I'm personally getting a feeling that composing middleware at large through Koa is sort of useless since async-await. It's an anti-pattern as far as I'm concerned. I don't see any benefit (except for current statue quo mw ecosystem) over just having a single mw and calling whatever feature with await, e.g.
const myAppMiddleware = async (ctx, next) => {
  await middlewareOne(ctx)
  await middlewareTwo(ctx)
  if (logic) {
    await myRouter(ctx)
  }
  ...
}

At which point it's easy to just profile in between, or wrap, each call with whatever profiler poison you choose. They're all just mutating and using ctx anyway. I do see the benefit, however. Such as parallelism (if some mw do IO), less clutter in stack (no extra wrapping with promises), and just generally not needing compose in koa :).

For anyone interested, I just released a package that does exactly this. It works via dependency injection, so you can pass in your own logging function, if you happen to use something like winston.
https://www.npmjs.com/package/koa-profiler-middleware

@joemckie that doesn't profile a middleware, it simply counts how long the full request takes.
Equivalent to e.g.
app.use(async (ctx, next) => {
  const start = process.hrtime.bigint()
  await next()
  const end = process.hrtime.bigint()
  console.log(`Request took ${end - start} nanoseconds`)
})

... or https://github.com/koajs/response-time

@fl0w yep you're right, completely misread this thread 🤦♂

closing this, better to just profile each async function

authors: PlasmaPower RobertHerhold Student007 fl0w jeromew joemckie jonathanong tj

repo: koajs/koa


text:
Link to the fourth video in README is wrong

I think link to the fourth video is wrong as it is leading to third video. Its not a big problem though as YouTube just offers you the fourth one right next to it but it might be a hassle if it doesn't happen.

Good catch. Fixing it now :)

repo: koaning/spacy-youtube-material


text:
amogsus

amogus
TL;DR Jebać disa skurwysyna

when the impostor is dis

authors: MoltenCoreDev kocotian

repo: kocotian/amogus

license: WTFPL


text:
Migration to .NET 8 and enable AOT compilation

Pull request contains:

migration to .NET 8.0,
Enabling AOT compilation for .NET 8.0 - it was enough to modify one JSON serialization and deserialization.

The changes are code-wise acceptable, but there is significant slowness reproducible in the unit tests. This appears to be related to file I/O modifications. Testing was conducted on Windows using .NET 8.0, where the issue was observed. .NET 7.0 works fine.

The follow up issue:
Support BufferedFileStreamStrategy that is fixed on NET8.0

Thanks.

repo: koculu/ZoneTree


text:
Artist spotlight

I guess Art creation is not a contest or competition and we would like to give the spotlight to great artists around.
In this issue, we would like to have an array of artist's addresses, let's start with 10 of them(?) and it should show three gallery items from their recent mints, each row should be one artist.
We would make (bi)weekly voting rounds on Discord on artists spotlights in KodaDot Spotlight

[ ] https://nft.kodadot.xyz/leaderboard rename route to spotlight
[ ] array of artist where we can easily change who is showed up
[ ] create subquery grapql to show particular artists 3 last mints
[ ] links to artist profile and show their on-chain identity in the /spotlight for their particular row

I'd suggest to write articles something like interviews to give the artists the best spotlight.
Hosting discussions on discord with artist could be cool too, something like community call but with artist as host.
Probably relates to have on the front page art - recent mints maybe ?

authors: anettrolikova yangwao

repo: kodadot/nft-gallery


text:
Partykit other cursor's opacity is not lowered when hovering over preview card

What happened?
sometimes other cursor's opacity is not lowered when hovering over preview card

👋


text:
redesign: [price-section] [desktop] [ui-only] buy, offer, list, transfer, change price, and not listed section

Thank you for your contribution to the KodaDot NFT gallery.
👇 _ Let's make a quick check before the contribution.
PR Type

[ ] Bugfix
[ ] Feature
[ ] Refactoring
[x] Redesign

Context

[x] Closes #4505
[x] use bold for the active state in activity tabs
[x] use formatDistanceToNowStrict to trim about

Before submitting pull request, please make sure:

[x] My contribution builds clean without any errors or warnings
[x] I've merged recent default branch -- main and I've no conflicts
[x] I've tried to respect high code quality standards
[x] I've didn't break any original functionality
[x] I've posted a screenshot of demonstrated change in this PR

Optional

[ ] I've tested it at </bsx/collection>
[ ] I've tested PR on mobile
[ ] I've written unit tests 🧪
[ ] I've found edge cases

Had issue bounty label?

[ ] Fill up your KSM address: Payout

Community participation

[x] Are you at KodaDot Discord?

Screenshot 📸

[x] My fix has changed something on UI; a screenshot is best to understand changes for others.

Nice job, it looks really good!
One issue, we had chat in the parent issue about the responsive version. AnnndI have to rethink it because for example from 1024 to 768px does not makes sense to have this animation etc. I did not think about it that much. I'll attempt to come up with something better - it seems to be a popup that will transform into a modal on mobile.
I mean on desktop with full view it looks really good and i am conviced this was good solution, but looking at the ui in the device toolbar i think we have to change few things.
This was my fault and i am sorry for that.

At least deliver that first for v1.0 and adjust a little bit for mobile based on the desktop version.

Yes, agree with this approach.
We've had a quick update on how to save some space and make mobile adjustments.
I guess we will come up with a good mobile solution and how to reuse components from mobile to desktop for example.

Issue is with animation is too wide and if we account for future narrow devices, foldable, tablets we need to come up with something flexible and probably go more vertical space
To continue, we will track it in a separate mobile gallery item issue.

Hi! nice job
feedback

background of the card should be k-darkmode, not black
is it also possible to make the stroke around the frame as in design?

rest i think would be fixed in #4444 , for example stretching the card to something like this, which isnt expected behavior

Thanks!

I guess let's merge it and then we can look adding #4531 and then through feedback process to tune details?

I'm moving this forward

authors: exezbcz preschian yangwao


text:
Update README.md

Thank you for your contribution to the KodaDot NFT gallery.
Let's do a quick check before the merge.
Your contribution will be an eternal part of the community codebase
Before submitting this PR, please make sure:

[ ] Code builds clean without any errors or warnings
[ ] I've merged recent default branch -- main and I've no conflicts
[ ] I didn't break any original functionality

Optional

[ ] I've tested it on mobile and everything works

PR type

[ ] Bugfix
[ ] Feature
[ ] Refactoring

What's new? (maybe part of changelog)

closes #<issue_number> - <Brief_description_how_you_fixed_it>

If issue contains bounty label ($,$$,$$$)

Your KSM address: <Kusama_address>

Community participation

[ ] Are you at KodaDot Discord? If no, let's join us - https://discord.gg/35hzy2dXXh

Screenshot

[ ] Whenever your fix will change something on UI, a screenshot is more than welcome

Thanks!


text:
feat: multi chain balances

Thank you for your contribution to the KodaDot - One Stop Shop for Polkadot NFTs.
👇 __ Let's make a quick check before the contribution.
PR Type

[ ] Bugfix
[x] Feature
[ ] Refactoring

Context

[x] Related #5838
[x] Related #5986
[x] Related #4865
[x] Related #5850

Had issue bounty label?

[x] Fill up your KSM address: Payout

Todo

[ ] for now, every time we open the sidebar there it always shows the skeleton component. will try to improve that in the next PR

Copilot Summary

🤖 Generated by Copilot at 18988f4
This pull request adds a new feature to show the balances of different tokens and chains for the connected wallet. It introduces a new component MultipleBalances.vue that queries and displays the balances using the Polkadot API and the fiat store. It also updates the existing component WalletAsset.vue to use the new component and to hide the total value when not on the snek prefix.

🤖 Generated by Copilot at 18988f4

Sing, O Muse, of the cunning coder who devised
A wondrous component, MultipleBalances.vue,
To show the wealth of tokens and chains that he prized,
And query the Polkadot API for the true.

hi @yangwao @exezbcz @JustLuuuu, need your feedback about multi-chain balances in this PR. Is it better like this? I change the text from Network to Chain in this PR and use the full chain name. to distinguish between kusama as a token or chain

. Is it better like this?

if it would be stable I'm okay with it 😉

Todo

[ ] for now, every time we open the sidebar there it always shows the skeleton component. will try to improve that in the next PR

On kusama: should show only availableBalance

could you give me your address with sub.id link? I will check it. for now, should show free balance only

https://github.com/kodadot/packages/blob/53bfd21bda439c8b2fda4cfd1347c85a5d80a4fb/sub-api/src/common/query.ts#L8

How are you going to handle /snek balance?

for now, snek is still unchanged, still using the old component. I think we need to distinguish main and test network/chain

alright

Yes! much better, thank you
ad styling, I would maybe make the column names 12 px in k-grey for both light modes

like here:

kodadot/packages@53bfd21/sub-api/src/common/query.ts#L8

oohh thanks, will update that 🙏

would it be possible to store (or fetch) balance values in pinia auth.balance state? So it would be easier to access between components

let me check, didn't check the store yet for balance stuff

Love it!

would it be possible to store (or fetch) balance values in pinia auth.balance state? So it would be easier to access between components

I just modified a little bit on onMounted section, so it still fetches and store to the auth.balance. seems like this is the root cause of sometimes the balance zero e5f092a

I just modified a little bit on onMounted section, so it still fetches and store to the auth.balance. seems like this is the root cause of sometimes the balance zero e5f092a

I've already tried that but it didn't worked for me, idk why but know it work wtf.
This morning, on first fetch it would show 0 balance on rmr2 but in console I had the value from store...

viki did meanwhile, if something can be reused?

https://github.com/kodadot/nft-gallery/pull/6021

more of a feature request, but can we highlight / make bold the token used for paying? (on Basilisk)

for this, how do I know the token is being used for transactions on Basilisk? cc @vikiival @roiLeo

more of a feature request, but can we highlight / make bold the token used for paying? (on Basilisk)
I guess this is not what you meant to do

seems like we need to ask the @kodadot/design-squad how to deliver this, wdyt? to make it clear

@preschian, just to be sure, do you mean asset to pay the transactions or buying nfts in general?

@exezbcz the asset used for paying for transactions on Basilisk (ksm or bsx)

@daiagi Okay, I am not 100% sure whether we should highlight it somehow. If it isn't explicitly mentioned, the user could be confused about what that means. I can think of some possible solutions, but it's against the concept of a smart and simple asset view. It would require additional tooltips etc.; that is not what we want.
I could mention this in the signing modal.
I can create a follow-up issue with p5, and I may come up with another, more innovative solution.

I would try but https://deploy-preview-6019--koda-canary.netlify.app/

let me retry

I'm good, works

pay 80 usd
I like fresh take and all others contributing to discussion!
probably continue in

https://github.com/kodadot/nft-gallery/pull/6052

😍 Perfect, I’ve sent the payout
💵 $80 @ 25.6 USD/KSM ~ 3.125 $KSM
🧗 DY4SQF2iD456tH89aQtz5wv1EV3BbSW8wKKuMcwbmXaj1pM
🔗 0x7911bee1678741be63c420089f97770cf42b3bff3cab5c2504141e4b2c87498e
🪅 Let’s grab another issue and get rewarded!
🪄 github.com/kodadot/nft-gallery/issues

authors: JustLuuuu daiagi exezbcz preschian roiLeo yangwao


text:
🔧 Identity NuxtLink

close #7615

@roiLeo clicking it won't close sidebar after you get redirected to profile page

@roiLeo clicking it won't close sidebar after you get redirected to profile page

yeah new feature

authors: prury roiLeo


text:
🛑 rubick - hot is down

In 5c324c8, rubick - hot (https://squid.subsquid.io/rubick/graphql) was down:

HTTP code: 404
Response time: 153 ms

Resolved: rubick - hot is back up in 71acb68 after 20 minutes.

repo: kodadot/uptime


text:
Github Trees support

Hello,
Thanks for this wonderful library!
I would like the library to support github trees, is it foreseen (https://developer.github.com/v3/git/trees/)?
For instance I need to retrieve this:
https://api.github.com/repos/calipho-sib/nextprot-docs/git/trees/master?recursive=1
If you would like I can try to implement this feature and I make a pull request?

Yes, a pull request would be wonderful. It should probably be a method on GHCommit.

Hi @kohsuke ,
I thought to implements the trees the same way as the refs. So it could be called as a method of GHRepository, the same way the GHRef works. Does it make sense?

I have sent the pull request

authors: ddtxra kohsuke

repo: kohsuke/github-api


text:
How to determine that the program will be stopped?

Hello.
There is a console program. How do I intercept the event of closure and perform some action on the freeing of resources?
Interception SIGINT does not work.
Messages from log:
2016-05-29 11:27:56 - Send SIGINT 8368
2016-05-29 11:27:56 - SIGINT to 8368 failed - Killing as fallback
I think problem in 'AttachConsole'.
OS: Windows 10 x64

Relly simple code in go to test it
`
package main
import (
"fmt"
"os"
"os/signal"
)
func main() {
// Set up channel on which to send signal notifications.
// We must use a buffered channel or risk missing the signal
// if we're not ready to receive when the signal is sent.
c := make(chan os.Signal, 1)
signal.Notify(c, os.Interrupt)
// Block until a signal is received.
s := <-c
fmt.Println("Got signal:", s)

}
`
It works when yourself push Ctrl-C, but I do not see a message about closing when working through the wrapper

ModifyProgram

package main
import (
"fmt"
"io/ioutil"
"os"
"os/signal"
)
func main() {
fmt.Println("hello")

// Set up channel on which to send signal notifications.
// We must use a buffered channel or risk missing the signal
// if we're not ready to receive when the signal is sent.
c := make(chan os.Signal, 1)
signal.Notify(c, os.Interrupt)

// Block until a signal is received.
s := <-c
fmt.Println("Got signal:", s)

d1 := []byte("hello\ngo\n")
ioutil.WriteFile("dat1", d1, 0644)

}
File not created.

Most likely it's a Windows service specifics.
Need to RTFM about the signal handling behavior in this case.

repo: kohsuke/winsw


text:
[FEATURE]: verify checksum in CheckIsValidAddress

Is there an existing issue for this?

[X] I have searched the existing issues

New feature
Verify the checksum in CheckIsValidAddress:
https://github.com/koinos/koinos-util-golang/blob/0c4eb59be62dbf88ca21e187d530533a2016770a/output.go#L75
The address has 25 bytes, consisting of 3 parts:

prefix: 1 byte
data: 20 bytes
checksum: 4 bytes

Verify this:

The prefix must be 0 (for P2PKH addresses)
checksum must be equal to first 4 bytes of sha256(sha256(prefix + data))

Reference:
https://medium.com/coinmonks/how-to-generate-a-bitcoin-address-step-by-step-9d7fcbf1ad0b
Anything else?
No response

Related to #33.

This issue is stale because it has been open for 30 days with no activity.

authors: joticajulian koinos-ci sgerbino

repo: koinos/koinos-util-golang


text:
Not support live-reloading?

npm start
change file components/header.js
browser doesn't reload automatically

The hot reloading functionality is mostly configured but the core peace that reloads the App is commented out, will need to fix that:
https://github.com/koistya/react-static-boilerplate/blob/master/core/app.js#L23-L31

+1 for live reload

Oh, there is one more thing to live reload.. I think that code splitting should be disabled in order to make React Hot Loader work with Webpack 2.x.. trying to figure out, what the best way to do it. For example, live reload can be enabled by default when you run npm start, or maybe it's better to add a flag for it, like npm run -- --hmr or something like that, so you could test the site with Live Reload (requires modifications to the bundle), and also without Live Reload, where website will look more to what is actually going to be deployed.

I think adding a flag is a good idea

@zzswang @upq I think Hot Module Replacement (HMR) and React Hot Loader should work fine now, please let me know if there are still any issues. This is enabled by default when you launch the project by running:
$ node run              # same as `node run start`, `npm start`

There is also --no-hmr flag that effectivly disables "live reload":
$ node run --no-hmr     # same as `nor run star --no-hmr`, `npm start -- --no-hmr`

authors: koistya upq zzswang

repo: koistya/react-static-boilerplate


text:
add modify function of the firebase database

add modify function of the firebase database
minor change for event.js

good edit function for careless admin like me


text:
🛑 KomikON is down

In 7202189, KomikON (https://komikon.me) was down:

HTTP code: 0
Response time: 0 ms

Resolved: KomikON is back up in dd51285.

repo: komikonapp/status


text:
Straightforward example to add customized nodes?

Hi, Thanks for making this project public, I did try the example and it is perfect for generic usage.
Although I am having hard time to figure out exactly how do you create new nodes. Ideally I would like to have some guidance example, that show how did you make the nodes for the various operations; and what is the minimum viable code to actually get just the "work area" where to add nodes; and how to make nodes Input and Output.
The example that you made is really helpful but it is taking me some time to get to the basics; I know that you may not have time, but something step by step, that show starting from the inclusion of the control on the form, creation of a couple of different node types and how they interact with each other; would really be the fastest way to dive into your project.
Thanks for your efforts!

Hi, take look at main readme file, section "Step 3 - Adding & extending Node Editor context type", especially look on the comments. Everything what is key here is the attributes around methods. I'm considering also to make short tutorial in some spare time. Thanks for the info.

Thanks for your reply; I did check the readme file, but it has bits and pieces about how to use the control.
I was looking for something more simple; like how to create a new node type (not yet on how to instantiate a node via right click menu; that would follow once you have designed and coded your nodes with input and output).
I will go through the example and see where did you declare the operations nodes; and start from there; but if you have time and can write something really simple in steps, about how to get started; I am sure that others will appreciate it too :)
Thanks!

Hello, would it be possible to see examples on how to interact with custom editor?
How to read and write your node if you have a combobox, checkbox or a trackbar inside it?
 [Node("Trackbar", "Input", "Basic", "", false, false, typeof(TrackBar))]
        public void ParameterValue(string name, float input, float min, float max, float step, out float outValue)
        {
            outValue = input;
        }
        [Node("Combo", "Input", "Basic", "Choose output from combo", false, false, typeof(ComboBox))]
        public void InputValueCombo(float inValue, out float outValue)
        {
             outValue = inValue;
        }

Thanks!

@Luonnotar it's simple:
In you custom control you should have something like this:
private void UpdateNodeContext()
{
    var node = (Tag as NodeVisual);
    if (node != null)
    {
        dynamic context = node.GetNodeContext();

        if (textureBoxRender.RenderTexture != null)
        {
            context.Texture = new NodeTexture2D(textureBoxRender.RenderTexture);
        }
        else if (!string.IsNullOrEmpty(context.Texture.GetTexturePath))
        {
            textureBoxRender.SetTexturePath(context.Texture.GetTexturePath);
        }
    }
}

Your Node(Visual) is set in the "Tag" property of your custom control. Take a look at how I get the dynamic context to access and use the node properties.
You only need to call "UpdateNodeContext()" from somwhere else. I'm sure you'll figure this out.

authors: Luonnotar komorra sqrMin1 theshinyknight

repo: komorra/NodeEditorWinforms


text:
fix(CLOUDDST-24922): retry cosign in signing task

Retry failed cosign so that signing doesn't fail with temporary issues on pushing to quay.io.

I'm not sure we should do this before https://issues.redhat.com/browse/RELEASE-1251 is complete

I think RELEASE-1251 is to make it safe to retry the whole rh-sign-image-cosign task (maybe by checking if signatures exist before signing?), which is not conflict with retrying a single failed cosign command here.

I'm not sure we should do this before https://issues.redhat.com/browse/RELEASE-1251 is complete

I think RELEASE-1251 is to make it safe to retry the whole rh-sign-image-cosign task (maybe by checking if signatures exist before signing?), which is not conflict with retrying a single failed cosign command here.

You're right, sorry for the noise. I saw retries: 3 in a yaml file and assumed it was a pipeline yaml having the task retry 3x. Approved

/ok-to-test

/retest

/ok-to-test

/retest
Failed because multiplatform controller didn't start up

/ok-to-test

/retest

/retest

/ok-to-test

/retest

authors: emilyzheng jinqi7 johnbieren mmalina

repo: konflux-ci/release-service-catalog


text:
Gradle Support

Would love this plugin to work with gradle any plans for this or any branches for it?

I see you've found my gradle plugin for this. I've also answered your comment.

authors: PSJMcNeill gigaSproule

repo: kongchen/swagger-maven-plugin


text:
About ExAC's fields interpretation

1 13402 . G C 89.66 VQSRTrancheSNP99.60to99.80 AC=2;AC_AFR=0;AC_AMR=0;AC_Adj=0;AC_EAS=0;AC_FIN=0;AC_Het=0;AC_Hom=0;AC_NFE=0;AC_OTH=0;AC_SAS=0;AF=1.078e-04;AN=18552;AN_AFR=154;AN_AMR=20;AN_Adj=1476;AN_EAS=64;AN_FIN=0;AN_NFE=320;AN_OTH=20;AN_SAS=898;DP=38807;FS=0.000;GQ_MEAN=8.99;GQ_STDDEV=9.11;Het_AFR=0;Het_AMR=0;Het_EAS=0;Het_FIN=0;Het_NFE=0;Het_OTH=0;Het_SAS=0;Hom_AFR=0;Hom_AMR=0;Hom_EAS=0;Hom_FIN=0;Hom_NFE=0;Hom_OTH=0;Hom_SAS=0;
In this case, AC_Het=0
But,
1 13404 . G A,T 136.58 VQSRTrancheSNP99.60to99.80 AC=2,1;AC_AFR=0,0;AC_AMR=0,0;AC_Adj=0,1;AC_EAS=0,0;AC_FIN=0,0;AC_Het=0,1,0;AC_Hom=0,0;AC_NFE=0,0;AC_OTH=0,0;AC_SAS=0,1;AF=1.078e-04,5.391e-05;AN=18548;AN_AFR=142;AN_AMR=20;AN_Adj=1384;AN_EAS=62;AN_FIN=0;AN_NFE=300;AN_OTH=18;AN_SAS=842;BaseQRankSum=-2.780e-01;ClippingRankSum=0.896;DP=38414;FS=0.000;GQ_MEAN=8.90;GQ_STDDEV=9.04;Het_AFR=0,0,0;Het_AMR=0,0,0;Het_EAS=0,0,0;Het_FIN=0,0,0;Het_NFE=0,0,0;Het_OTH=0,0,0;Het_SAS=0,1,0;Hom_AFR=0,0;Hom_AMR=0,0;Hom_EAS=0,0;Hom_FIN=0,0;Hom_NFE=0,0;Hom_OTH=0,0;Hom_SAS=0,0;
**In this case, AC_Het=0,1,0 => why 3 values? **
According to this vcf header, right values are 1,0 ?
Header definition is the following
INFO=<ID=AC,Number=A,Type=Integer,Description="Allele count in genotypes, for each ALT allele, in the same order as listed">
INFO=<ID=AC_AFR,Number=A,Type=Integer,Description="African/African American Allele Counts">
NFO=<ID=AC_AMR,Number=A,Type=Integer,Description="American Allele Counts">
NFO=<ID=AC_Adj,Number=A,Type=Integer,Description="Adjusted Allele Counts">
INFO=<ID=AC_EAS,Number=A,Type=Integer,Description="East Asian Allele Counts">
INFO=<ID=AC_FIN,Number=A,Type=Integer,Description="Finnish Allele Counts">
INFO=<ID=AC_Hemi,Number=A,Type=Integer,Description="Adjusted Hemizygous Counts">
INFO=<ID=AC_Het,Number=A,Type=Integer,Description="Adjusted Heterozygous Counts

Yes, this is a known issue (#164) - the number of values is correct, but it shouldn't be Number=A. This will be fixed when we push a new VCF hopefully fairly soon.

This has now been fixed in release 0.3.1: ftp://ftp.broadinstitute.org/pub/ExAC_release/release0.3.1

authors: chulghim konradjk


text:
Topple Chess x64 for Windows

gauntlet ChessGUI.zip
gauntlet Arena.zip

Hello Vincent,
cf. attachments - I used these editions: http://www.chess2u.com/t11859-topplechess and https://transfer.sh/cfqH6/Topple.exe
To use the logos with a an interface like Arena, ChessGUI or WinBoard > rename .jpeg into .bmp (bitmap) e.g. http://www.photofiltre.com/
Both have still bugs....
Regards,

Looks like the bug here is from Topple detecting a position repetition in the move history, and refusing to search because it thinks the game should be over: this is because it treats a position as a draw when it has only been repeated twice, as opposed to three times.

win/ivybridge/O3 build of the latest commit can be found at https://transfer.sh/hMqBd/Topple.exe
Thanks for testing :)

authors: konsolas yellow-panther

repo: konsolas/ToppleChess


text:
Range filter gives type error when arguments are date strings

Brief bug description
When using the range filter in a typescript project, providing date/time strings as arguments causes a type error 'argument of type 'string' is not assignable to parameter of type 'number.' Based on our documentation this should be supported https://kontent.ai/learn/tutorials/develop-apps/get-content/filter-content-items-examples/?tech=typescript#a-range-of-dates-and-numbers
Repro steps
Create delivery client in typescript file
Apply range filter with date/time strings as arguments
Expected behavior
TS does not flag this with error
Test environment
Node 18.16.0
Additional context
Add any other context about the problem here.
Screenshots
Add links to screenshots, if possible.

Fixed by https://github.com/kontent-ai/delivery-sdk-js/pull/368

repo: kontent-ai/delivery-sdk-js


text:
Corrected the typo  crane export --help

Correct the typo "example" in the description of oc export --as-extras. This meets the 1st point in https://github.com/konveyor/crane/issues/71
I have just started exploring crane, so in case the 2 & 3 points in https://github.com/konveyor/crane/issues/71 are also required, I'd be happy to add those as well in the same PR. Let me know, thanks!

/lgtm

@apoorvajagtap Let's fix 2 and 3 in the issue in this PR.

authors: apoorvajagtap pranavgaikwad

repo: konveyor/crane


text:
Fixing tests branch in workflows

Use github.ref in TIER tests for release branches. github.ref is the branch triggered the workflow run. For workflows triggered by push, this is the branch or tag ref that was pushed. For workflows triggered by pull_request, this is the pull request merge branch.
For more information, see: https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#github-context

Thanks @aufi!
Without this change, the target branch of a PR will be used for testing instead of the source branch (the changes we want to check). Like in here: https://github.com/konveyor/go-konveyor-tests/actions/runs/11704654057/attempts/1

Ah, sorry, thanks for explanation, LGTM.

repo: konveyor/go-konveyor-tests


text:
[WIP] feat(hooks): Add usePaginationState and useSortState hooks from forklift-ui

In the process, I'm adding generics to the pagination hook and a few other utility functions to the return value of the sort hook (in case it is used standalone instead of with the PF table).
WIP, needs stories and tests.

Closing this because the versions in forklift have diverged a ton so I'm just going to open a fresh one.

repo: konveyor/lib-ui


text:
Add ability to filter tree view to a particular migration

Previous tree endpoint:
    # See all resources for a plan
    "/namespaces/:ns1/plans/:plan/tree",

Additional tree endpoint (this PR):
    # See all resources for a plan
    "/namespaces/:ns1/plans/:plan/tree",
    # Filter for a particular migration
    "/namespaces/:ns1/plans/:plan/tree/:migration",

To test:
AUTH_OPTIONAL=1 ROLE=discovery make run-fast

# See new schema items
curl http://localhost:8080/schema | jq

# View full tree view contents
curl http://localhost:8080/namespaces/openshift-migration/plans/plan-rocket-chat/tree/

# View filtered tree view contents
curl http://localhost:8080/namespaces/openshift-migration/plans/plan-rocket-chat/tree/stage-ec573

Tested and looking good!

repo: konveyor/mig-controller


text:
Bug 1883212 - Warning message should be given to user indicating empty project migration.

Following snapshots indicate the warning messages introduced by the bug-fix, for empty and non-empty (nginx) namespaces:
Empty Namespace [Stage]:

Empty Namespace [Migrate]:

NGinx Example Namespace [Stage and Migrate]:

Signed-off-by: seshapad seshapad@in.ibm.com

So this PR seems to do several things, but I'm not sure it's a net improvement.
The original purpose of the "StageNoOp" warning was to let a user know that they were performing a stage migration on a namespace which didn't have anything to stage -- i.e. it wasn't a mistake to show "success" even though there was no velero backup/restore created, but also to let the user know that for this sort of content to migrate, there's no value in stage, just go to final migration. With this PR we're adding in pod template checking to the same test, which is something we probably don't want to include for stage migration checking (since we'll no longer display the warning if there are no PVs or imagestreams for stage migration, since Deployments, etc. which are only included in final migration are also included in the "artifacts available" check). Also, for final migrations, the pod template check is probably insufficient, since it will flag as "empty" any namespace which doesn't have PVs, Imagestreams, or Pod Templates. The namespace could still have CRs, secrets, etc.
Also, I don't think forcing cancel is what we want here, especially considering the possibility that our "is the user migrating something real?" check may not be 100% accurate.

I'm thinking that the right approach here may be more along the lines of leaving the stage migration check/warning as-is but adding a new check (and warning condition) for final migrations, possibly one which makes use of some of our existing health check functionality since I know we're already looking at various resource types. @dymurray is there anything we have already that will give a quick answer to "Is there anything here to migrate?" In any case, I think for now we're probably better off just sticking with the warnings and not forcing cancellation. The downside of not canceling is that a migration with little to do will run to completion fairly quickly. The downside of canceling is that we may be preventing users from migrating actual data for certain edge cases.

@sseago Could I summarize your comments as follows:

Remove "cancellation" for empty namespaces in case of both staging and migration.
Retain the "stage migration check/warning" as it
For the final migration, use existing health checks defined in the mig-controller code which already looks for "Is there anything here to migrate?" (@dymurray could help clarify this).
Have I left anything out here? please clarify.

@seshapad Yes, I think that's right. And regarding 3), I'm not entirely sure whether we have anything appropriate. My concern was that "not having PodTemplates" is still a valid use case, so we probably need a more expansive check and it's possible we already have something that could be reused here.

Sure. I will wait for @djwhatle for any pointers he may share on this.

Apologize for the delay in response... but I am not aware of anything that exists today which indicates "is there anything in this namespace to migrate" but it sounds like a function that would be usable for other portions of the migration code.
I will review this PR independent of that, but I think Scott is right it's likely a more expensive check and is worth separating out to a separate check rather than the stage check.

I agree with Scott. This check should be used for final migrations and this stage check should be left alone. Other than that I have a few questions:

I think using ListTemplatePods is a good idea to determine if there's anything actually running in the namespace, but I don't think it accurately represents if a namespace is "empty". I think we should change the warning condition to reflect that we are checking for running pods in this case.
Is it worth checking for routes/networking objects? Unsure if it's a valid use case but I was trying to think of any reason someone would want a namespace migrated without running pods/objects.

Other than that I think you are on the right track, please let me know if it's worth setting up a conversation to discuss this further.

I think there are various use cases for namespaces that don't have pods, although these are all probably edge cases, so a pod-centric warning message which doesn't fail anything may still be appropriate. Shared CRs could be put in their own namespace (i.e. as we do for openshift-migration, although in that case we also have pods there), or it could be used for images only, etc.

@dymurray @sseago Based on comments you provided here and during the meeting, I am planning below modification to the PR:

I will remove "cancellation" of stage and migrate and restore "stage warning" to what it used to be before this change.
I will retrieve the miganalytics resource (from within the migrate task) and lookup the analytics (image count, resources, pv etc) it provides for the given namespace and check if they are all zero. If so, I will create a warning (without cancellation) to inform the user that the so and so resources are not available in the namespace (Note that I do this only if whatever resources miganalytics compiles turn out to be zero. if any of them are non-zero, I will go by the assumption that the warning is not necessary).

Please let me know if this modification is ok.

@seshapad Yes, that sounds like the appropriate way to move forward with this.

@seshapad Yes, that sounds like the appropriate way to move forward with this.

Thanks @dymurray . I will go ahead with this.

@sseago @dymurray Amended PR now applies the changes discussed here [https://github.com/konveyor/mig-controller/pull/811#issuecomment-740724976] and displays warning based on migrated resource statistics collected by miganalytic:

Does this change address the feedback raised previously?

@seshapad I am concerned about this PRs usage of MigAnalytics to make its determinations. We can't rely on MigAnalytics being present for a MigPlan. cc @jmontleon

@djwhatle @sseago @dymurray From Dererk's comments, it seems the MigAnalytics approach is not suitable for getting the list of k8s resources. In this scenario, would it be a good idea to obtain the resource list using first principles. For instance:

func collectResources(client compat.Client) ([]*metav1.APIResourceList, error) {
resources, err := client.ServerResources()
if err != nil {
return nil, err
}
for _, res := range resources {
res.APIResources = namespaced(res.APIResources)
res.APIResources = excludeSubresources(res.APIResources)
res.APIResources = listAllowed(res.APIResources)
}
return resources, nil
}

https://github.com/konveyor/mig-controller/pull/811#issuecomment-746492042

@seshapad I was thinking about if there's any way for us to avoid spending extra API requests / migration time to figure this out. What if we were to just examine the completed Velero Backup and pull the "Progress" field contents off to see how many items it actually backed up?  Would that work? @sseago thoughts on if this would accomplish the goals of this fix?

If pulling this info off the Velero Backup CR seems unsuitable, I think the "first principles" approach you suggest could definitely work. I think we would only have to run this check once per migration so the additional API calls should only need to happen once. I wonder if we could re-use any of the logic from MigAnalytics controller (e.g. if we relocated some of the logic there into a common package like migapi
	migapi "github.com/konveyor/mig-controller/pkg/apis/migration/v1alpha1"

@seshapad I was thinking about if there's any way for us to avoid spending extra API requests / migration time to figure this out. What if we were to just examine the completed Velero Backup upon completion and pull the "Progress" field contents off to see how many items it actually backed up? Would that work? @sseago thoughts on if this would accomplish the goals of this fix?
E.g. if totalItems == 0 and phase=Completed || Failed || whatever, raise the condition.
status:
  completionTimestamp: "2020-12-15T15:27:56Z"
  expiration: "2021-01-14T15:27:52Z"
  formatVersion: 1.1.0
  phase: Completed
  progress:
    itemsBackedUp: 28
    totalItems: 28
  startTimestamp: "2020-12-15T15:27:52Z"
  version: 1

If pulling this info off the Velero Backup CR seems unsuitable, I think the "first principles" approach you suggest could definitely work. I think we would only have to run this check once per migration so the additional API calls should only need to happen once. I wonder if we could re-use any of the logic from MigAnalytics controller (e.g. if we relocated some of the logic there into a common package like migapi
	migapi "github.com/konveyor/mig-controller/pkg/apis/migration/v1alpha1"

Not a hard requirement to re-use logic from MigAnalytics if this logic is unique/trivial, but wondering if anything is shared.

Thanks @djwhatle . I will wait for @sseago's comments and share a tentative approach to keep us all on the same page.

@djwhatle My initial reaction to your suggestion was that the "what's in the velero backup?" appraoch might be a simpler (and better) approach, but on further thinking, it starts to get messy. The big picture question we're asking is "are we migrating anything?". One velero backup won't tell that. First, we have to look at both initial and stage backups and add up the two totals. But we also have to consider direct migration of PVs and Images, since it's possible that Velero won't actually copy anything because the only thing migrated was images or volumes via direct migration. So we could follow this approach, but we'd need to include both velero backups and DIM and DVM totals. Then the question is which phase of the migration we'd do this at, since we have to look back at four completed phases and consider information from all of them. The "first principles" approach might end up being simpler.

@seshapad I was thinking about if there's any way for us to avoid spending extra API requests / migration time to figure this out. What if we were to just examine the completed Velero Backup upon completion and pull the "Progress" field contents off to see how many items it actually backed up? Would that work? @sseago thoughts on if this would accomplish the goals of this fix?
E.g. if totalItems == 0 and phase=Completed || Failed || whatever, raise the condition.
status:
  completionTimestamp: "2020-12-15T15:27:56Z"
  expiration: "2021-01-14T15:27:52Z"
  formatVersion: 1.1.0
  phase: Completed
  progress:
    itemsBackedUp: 28
    totalItems: 28
  startTimestamp: "2020-12-15T15:27:52Z"
  version: 1

If pulling this info off the Velero Backup CR seems unsuitable, I think the "first principles" approach you suggest could definitely work. I think we would only have to run this check once per migration so the additional API calls should only need to happen once. I wonder if we could re-use any of the logic from MigAnalytics controller (e.g. if we relocated some of the logic there into a common package like migapi
	migapi "github.com/konveyor/mig-controller/pkg/apis/migration/v1alpha1"

Not a hard requirement to re-use logic from MigAnalytics if this logic is unique/trivial, but wondering if anything is shared.

Thanks @djwhatle . I will wait for @sseago's comments and share a tentative approach to keep us all on the same page.

@djwhatle Right now, we are raising the warning at the init phase of the migration itself.  If we go with the Velero Backup CR approach, we will have to raise the warning condition after the backup phase is done, is it not?

@djwhatle My initial reaction to your suggestion was that the "what's in the velero backup?" appraoch might be a simpler (and better) approach, but on further thinking, it starts to get messy. The big picture question we're asking is "are we migrating anything?". One velero backup won't tell that. First, we have to look at both initial and stage backups and add up the two totals. But we also have to consider direct migration of PVs and Images, since it's possible that Velero won't actually copy anything because the only thing migrated was images or volumes via direct migration. So we could follow this approach, but we'd need to include both velero backups and DIM and DVM totals. Then the question is which phase of the migration we'd do this at, since we have to look back at four completed phases and consider information from all of them. The "first principles" approach might end up being simpler.

@djwhatle @sseago So...following from both your comments, shall I go by this simple flow:

I will add a function (say, CollectResources()) which fetches the list of resources:

migapi "github.com/konveyor/mig-controller/pkg/apis/migration/v1alpha1" "github.com/konveyor/mig-controller/pkg/apis/migration/v1alpha1"

Invoke CollectResources() with task.go init() to check the returned list of resources is non-zero. If zero, I raise warning condition. If not zero, do nothing.

Is this good?

That sounds reasonable to me. And upon further thinking, I'm not sure migapi is the right place to put this func, probably OK to keep it in the same pkg assuming size is reasonable.

@djwhatle I think this all makes sense, but yes if this is only ever called from the controller validation code, then it can just be a non-exported func within the same package.

@djwhatle @sseago I have moved the code to around to api pkg and modified analytic and migration code to use common functions. I will push the commit. Please take a look and let me know if it is appropriate.

@djwhatle what is the standard way to measure the timing of the function call in mig controller? Should I simply timestamp the function  and log the difference in time?

@djwhatle what is the standard way to measure the timing of the function call in mig controller? Should I simply timestamp the function and log the difference in time?

Here's an example of how to record an elapsed time figure.
https://github.com/konveyor/mig-controller/blob/6c28e299c8086ed7754ab6c2d8a760aecefd93f7/pkg/compat/client.go#L188-L193
nanoToMilli = 1e6
start := time.Now()
elapsed := float64(time.Since(start) / nanoToMilli)
# now you can log the elapsed time

authors: djwhatle dymurray seshapad sseago


text:
Single user ui changes

Update env var names
Conditionally render the keycloak provider wrapper based on an env var.
Pending operator changes: https://github.com/konveyor/tackle2-ui/issues/63

@ibolton336 I don't think we are using KEYCLOAK_REALM or KEYCLOAK_CLIENT_ID that I could find , perhaps it would make sense to remove them if they are useless. Also , KEYCLOAK_HOST makes sense more as KEYCLOAK_SERVER_URL , still follows naming but I think better represents what it is , since it is a URL that contains the host.

@fbladilo, please let us know when you have an operator PR covering the change from  SSO_SERVER_URL to KEYCLOAK_SERVER_URL

As we've discussed it would be preferable to use the Express API approach.

This approach is the same as the forklift-ui approach. We discussed it would be preferable to use the same approach across the apps. Adding in an asynchronous call when we are bootstrapping the app could cause some unforeseen issues. This PR just implements the proven template variable approach that Mike recommended. This way we can keep our strict typing for the env var constant.

@ibolton336, the way Forklift/MTV addressed its needs is definitively not a standard across the apps.
I would rather have a better long term solution.
Let's discuss it.

authors: fbladilo gildub ibolton336


text:
export to  excel

the data from database is being exported to excle but there is no graphical repesentation on excel as data is being shown in place of  column charts.  help me out......

We moved the source code to a new repo at https://github.com/koolreport/core
For questions please go to https://www.koolreport.com/forum/topics
Thanks!

authors: dongnl prphet

repo: koolphp/koolreport


text:
Kotlin 1.8 support

Plugin version 1.11.0 produces the following error in a project using Kotlin 1.8:
Unable to find method ''void org.jetbrains.kotlin.gradle.tasks.KotlinCompile.<init>(org.jetbrains.kotlin.gradle.dsl.KotlinJvmOptions, org.gradle.workers.WorkerExecutor, org.gradle.api.model.ObjectFactory)''
'void org.jetbrains.kotlin.gradle.tasks.KotlinCompile.<init>(org.jetbrains.kotlin.gradle.dsl.KotlinJvmOptions, org.gradle.workers.WorkerExecutor, org.gradle.api.model.ObjectFactory)'

I checked out an old Kotlin 1.7.20 commit of the same project and everything looks good.

This issue is currently preventing us from supporting Kotlin 1.8: https://youtrack.jetbrains.com/issue/KT-55720/KJS-IR-ReferenceError-SuspendFunction1-is-not-defined-with-1.8
We are waiting on its resolution.

MocKMP 1.12.0 is compiled with Kotlin 1.8.
Note that you may need to add:
kotlin.incremental.js.ir=false

If you are mocking suspend functions in JS.

authors: SalomonBrys jdamcd

repo: kosi-libs/MocKMP


text:
Revert "fix: fix potential bug"

Reverts kosmos-io/kosmos#242

/close

repo: kosmos-io/kosmos


text:
Add more than the daily eko to the news

Support the economics news as well

Solved with pr #31

repo: kotlinski/dagens-eko-player


text:
ShouldThrow matchers should allow testing for message and cause

I said something about this at #810, but it can be a different issue.
I usually see code used with shouldThrow being used in this fashion:
val throwable = shouldThrowAny { foo() }

throwable.message shouldBe "fooBar"

We should come up with a syntax to allow the shouldThrow matchers (all of them, of course) to explicitly test for the message.
An idea would be to optionally receive a message parameter:
shouldThrowAny(message = "fooBar") { foo() }

But I don't like this approach.
What I usually see is also
shouldThrowAny {
foo()
}.message shouldBe "fooBar"

But I don't know if it's descriptive enough.
Thoughts? @sksamuel

I tend to do the latter.
`shouldThrow { foo() } withMessage "fooBar"`` ?

shouldThrowWithMessage("wibble") {
  // test
}

or simplyy
shouldThrow("wibble") {
  // test
}

Even
shouldThrow(
  {  test here },
  { block with exception as receiver here }
)

Or
shouldThrow {
  // test
}.assertException {
  // exception as receiver here
}

But I'm not sure what we have is that bad.

Why not just keep the same "syntax" and just add some throwable matchers?
Playing with the lib, I built those:

Throwables / Exceptions

throwable.shouldBeOfType<T>()
Asserts that the throwable is of type T.

throwable.shouldBeExactlyOfType<T>()
Asserts that the throwable is exctly of type T.

throwable.shouldHaveMessage(message)
Asserts that the throwable message is the same of the given one.

throwable.shouldHaveCause()
Asserts that the throwable have a cause.

throwable.shouldHaveCause { block }
Asserts that the throwable have a cause, and pass it as parameter to the block

throwable.shouldHaveCauseOfType<T>()
Asserts that the throwable have a cause and it is of type T.

throwable.shouldHaveCauseOfExacltyType<T>()
Asserts that the throwable have a cause and it is exaclty of type T.

And to test, I just use the same existing syntax like this :point_down:
shouldThrowAny {
    throw FileNotFoundException("this_file.txt not found")
} shouldHaveMessage "this_file.txt not found"

shouldThrowAny {
    throw CompleteTestException()
}.shouldHaveCauseOfType<FileNotFoundException>()

Result.failure<Any>(FileNotFoundException("this_file.txt not found"))
    .exceptionOrNull()!!
    .shouldBeOfType<FileNotFoundException>()

If they are OK, I can open a PR with them.

We suggested that earlier.
If you're ok with doing this, feel free to PR these matchers! They'll be really helpful!

authors: Kerooker faogustavo sksamuel

repo: kotlintest/kotlintest


text:
Up to Surreal 1.4.0

prepare for new version:

fix bugs, docs
DEFINE...RELATE
INCLUDE ORIGINAL
highlight
http /rpc

#40

repo: kotolex/surrealist


text:
Can you possibility to make an action button

Hello,
I want to add a button but with your package is not possible. Can you add this feature please ?
Example:

Thanks

@CedricLphn thanks for this suggestion I will add it in the next version

/remind me to fix this issue after 9 hourse

/remind me to fix this issue after 9 hours

authors: CedricLphn koukibadr

repo: koukibadr/Cherry-Toast


text:
Speedy derive macro is throwing clippy errors in downstream crates

error: this public function might dereference a raw pointer but is not marked `unsafe`
   --> src/structure/guid.rs:476:3
    |
476 |   Readable,
    |   ^^^^^^^^
    |
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#not_unsafe_ptr_arg_deref
    = note: this error originates in the derive macro `Readable` (in Nightly builds, run with -Z macro-backtrace for more info)

Presumably this is because the Readable trait derived implementation has methods that dereference raw pointers. These could in principle be anything, so the methods are inherently unsafe and should be marked as such. That's most likely a breaking change (worth making).

looks like this may have already been addressed in https://github.com/koute/speedy/commit/1a2ec91aa42fdfe1e2a239b93eafe367f5483b02 ?

repo: koute/speedy


text:
Handle all request parameter types

Hi,
Thanks for this tool !
I'm trying to infer request parameter type, based on what's inside "in" field in operation's parameters.
It appears that only Query parameter type is handled for the moment, is it a known issue ? Willing to help and PR if needed.

Thank you for creating this issue.
And I'm sorry for my late reply.

It appears that only Query parameter type is handled for the moment, is it a known issue ?

Yes, the problem is related to the issue https://github.com/koxudaxi/fastapi-code-generator/issues/104
First, This code-generator  depends  datamodel-code-generator .
Second, I'm working on improving datamodel-code-generator to resolve complex schemas.
Third, I have a plan to add a feature to datamodel-code-generator that parsing any request types.

Willing to help and PR if needed.

If you have some OpenAPI files for the test case then, it helps implementation.
Thank you!!

authors: koxudaxi rambobinator

repo: koxudaxi/fastapi-code-generator