Safe shut down for sequence of requests

Hello. First of all — thanks for the great job.
I'm trying to implement a graceful shutdown for my app.
The idea of the app is pretty simple:

It gets a batch of messages from the queue
it processes each message one by one

The first part of processing may take quite some time and can be interrupted by a shutdown signal.
The second part of processing is fast and better not to be interrupted (store result to db/queue)
If we shut down the app - each unprocessed message should placed back in the queue (i.e. canceling job)
For example, let's say we have [0..10] as the naive implementation of batch messages. The code will look like this:
use std::time::Duration;
use tokio::task;
use tokio::time::sleep;
use tokio_graceful::Shutdown;

#[tokio::main]
async fn main() {
    let shutdown = Shutdown::default();
    let guard1 = shutdown.guard();
    task::spawn(async move {
        for i in 0..10 {
            tokio::select! {
                _ = guard1.cancelled() => {
                    canceling(i).await;
                },
                result = non_mandatory_work(i) => {
                    mandatory_work(result).await;
                },
            }
        }
    });

    // Wait for shutdown signal
    shutdown.shutdown().await;
}

async fn canceling(i: u32) {
    println!("Canceling after {}", i);
}

async fn non_mandatory_work(i: u32) -> u32 {
    println!("Non-mandatory work started for {}", i);
    sleep(Duration::from_secs(2)).await;
    println!("Non-mandatory work done for {}", i);
    i
}

async fn mandatory_work(i: u32) {
    println!("Mandatory work started for {}", i);
    sleep(Duration::from_secs(2)).await;
    println!("Mandatory work done for {}", i);
}

In this code, tokio cancels non_mandatory_work after shutdown. And mandatory_work never happens because guard1.cancelled()  is faster then non_mandatory_work

Still, it starts `non_mandatory_work` as well and just drops it before it can finish.
See output (^C is cancel)
Non-mandatory work started for 0
^C Canceling after 0
Non-mandatory work started for 1
Canceling after 1
Non-mandatory work started for 2
Canceling after 2
Non-mandatory work started for 3
Canceling after 3
Canceling after 4
Non-mandatory work started for 5
Canceling after 5
Canceling after 6
Canceling after 7
Canceling after 8
Non-mandatory work started for 9
Canceling after 9

The problem
Still, there is a concurrency. We can observe it by making non_mandatory_work faster by removing sleep inside. Then, sometimes, non_mandatory_work finishes faster than guard1.cancelled()

See output:
Non-mandatory work started for 0
Non-mandatory work done for 0
Mandatory work started for 0
^CMandatory work done for 0
Non-mandatory work started for 1
Non-mandatory work done for 1
Mandatory work started for 1
Mandatory work done for 1
Canceling after 2
Canceling after 3
Non-mandatory work started for 4
Non-mandatory work done for 4
Mandatory work started for 4
Mandatory work done for 4
Canceling after 5
Canceling after 6
Canceling after 7
Canceling after 8
Canceling after 9

Naive solution
I solved this problem externally by creating an additional controller with Arc and infinite await.

 Naive implementation
use std::sync::Arc;
use std::sync::atomic::AtomicBool;
use std::time::Duration;
use tokio::signal::unix::signal;
use tokio::task;
use tokio::time::sleep;
use tokio_graceful::Shutdown;

#[tokio::main]
async fn main() {
    let shutdown = Shutdown::default();
    let guard1 = shutdown.guard();
    let controller = Arc::new(AtomicBool::new(false));
    let some = Some {
        controller: controller.clone(),
    };

    task::spawn(async move {
        for i in 0..10 {
            tokio::select! {
                _ = guard1.cancelled() => {
                    canceling(i).await;
                },
                result = some.non_mandatory_work(i) => {
                    mandatory_work(result).await;
                },
            }
        }
    });

    waiting_for_signal().await;
    controller.store(true, std::sync::atomic::Ordering::Relaxed);
    shutdown.shutdown().await;
}

struct Some {
    controller: Arc<AtomicBool>,
}

impl Some {
    async fn controller_fn(&self) {
        while self.controller.load(std::sync::atomic::Ordering::Relaxed) == true {
            sleep(Duration::from_secs(1)).await;
        }
    }

    async fn non_mandatory_work(&self, i: u32) -> u32 {
        self.controller_fn().await;
        println!("Non-mandatory work started for {}", i);
        println!("Non-mandatory work done for {}", i);
        i
    }

    fn shutdown(&self) {
        self.controller.store(true, std::sync::atomic::Ordering::Relaxed);
    }
}

async fn canceling(i: u32) {
    println!("Canceling after {}", i);
}

async fn mandatory_work(i: u32) {
    println!("Mandatory work started for {}", i);
    sleep(Duration::from_secs(2)).await;
    println!("Mandatory work done for {}", i);
}

async fn waiting_for_signal() {
    let mut sigterm = signal(tokio::signal::unix::SignalKind::terminate()).unwrap();
    let mut sighup = signal(tokio::signal::unix::SignalKind::hangup()).unwrap();
    let mut sigint = signal(tokio::signal::unix::SignalKind::interrupt()).unwrap();
    let mut sigquit = signal(tokio::signal::unix::SignalKind::quit()).unwrap();

    tokio::select! {
        _ = sigterm.recv() => {
            println!("Received SIGTERM");
        }
        _ = sighup.recv() => {
            println!("Received SIGHUP");
        }
        _ = sigint.recv() => {
            println!("Received SIGINT");
        }
        _ = sigquit.recv() => {
            println!("Received SIGQUIT");
        }
    }
}

But it will be nice to have infinite await in tokio-graceful crate.
What do you think? Is this make sense to you?
Thanks

I am not sure I  understand your issue due to the abstract example you gave here. But as far as I understand it you want to be able to:

do concurrent work
have the non-mandetory work stop ASAP when the cancellation has been kicked off
but ensure that the mandetory work does conclude, with the results of the cancelled or finished mandetory work

If so then this is how you would do that with tokio-graceful as is (btw also notice that it's easier to spawn tasks directly with the graceful API as it will make it that you do not need to move/clone guards yourself and ensures all your tasks get a guard):
use std::time::Duration;
use tokio::time::sleep;
use tokio_graceful::{Shutdown, WeakShutdownGuard};

#[tokio::main]
async fn main() {
    let shutdown = Shutdown::default();
    shutdown.spawn_task_fn(|guard| async move {
        for i in 0..10 {
            let nm_guard = guard.clone_weak();
            let result = non_mandatory_work(nm_guard, i).await;
            mandatory_work(result).await;
        }
    });

    // Wait for shutdown signal
    shutdown.shutdown().await;
}

async fn canceling(i: u32) {
    println!("Canceling after {}", i);
}

async fn non_mandatory_work(guard: WeakShutdownGuard, i: u32) -> u32 {
    println!("Non-mandatory work started for {}", i);
    tokio::select! {
        _ = guard.cancelled() => {
            canceling(i).await;
            println!("Non-mandatory work cancelled early for {}", i);
            return i;
        }
        _ = sleep(Duration::from_secs(2)) => (),
    };
    println!("Non-mandatory work done for {}", i);
    i
}

async fn mandatory_work(i: u32) {
    println!("Mandatory work started for {}", i);
    sleep(Duration::from_secs(2)).await;
    println!("Mandatory work done for {}", i);
}

Which works and you can see that after CTRL+C that the non-mandatory works immediately returns because it was cancelled but that all mandatory work does get executed.
Final note: given that this does mean your cancellation gets delayed for until your non-mandatory is early cancelled and mandatory work is finished, that you :

either have to wait infinite time for cancellation to complete (what you are currently doing)
or cancel with timeout but put the timeout high enough (what I would recommend.

The second is achieved by using Duration::from_secs(60) instead of shutdown.shutdown().await. Higher time if you need more. Dunno how slow that graceful execution of your tasks is.
tokio-graceful was created so that you do not need to fiddle with signals and atomics yourself for this purpose. So hopefully my example here shows that you can easily achieve what you want, as-is, today already? Unless I misunderstood something?

Thank you so much for such a detailed answer. I'll try to explain what I'm trying to achieve because I feel that I previously explained it poorly. I'll use other terminology for the same steps to make them clearer.
I have two scenarios:
Regular workflow
get a message from batch → process → submit
Regular workflow after shutdown
get a message from batch → send it back, don't start process and don't start submit
And I have two additional scenarios:
if shutdown happens in the middle of process we send message back and don't run submit and don't wait process to finish
if shutdown happens in the middle of submit we continue with submitting
And overall get→process→submit and get batch→process→submit is typical scenarios

sequenceDiagram
    participant RabbitMQ
    participant App
    participant Processor
    participant Submitter

    Note over RabbitMQ,Submitter: Regular workflow Start
    App->>RabbitMQ: Get batch of messages
    RabbitMQ-->>App: Batch of messages
    loop For each message in batch
        App->>Processor: Process message
        Processor-->>App: Processed message
        App->>Submitter: Submit processed message
        Submitter-->>App: Submission result
        App->>App: Mark message as done
    end
    App->>RabbitMQ: Get new batch of messages

    Note over RabbitMQ,Submitter: Regular Workflow End

    Note over RabbitMQ,Submitter: After Shutdown Signal Happens
    RabbitMQ-->>App: Batch of messages

    loop For each message in batch
        App->>App: Mark message as nack
        App->>RabbitMQ: Send message back
    end
    Note over RabbitMQ,Submitter: Shutdown Complete

    Note over RabbitMQ,Submitter: Additional Scenarios
    Note over App,Processor: Shutdown during process
    App->>Processor: Process message
    Processor-->>App: Shutdown received
    App->>App: Mark message as nack
    App->>RabbitMQ: Send message back

    Note over App,Submitter: Shutdown during submit
    App->>Submitter: Submit message
    Submitter-->>App: Shutdown received
    Submitter-->>App: Complete submission
    App->>App: Mark message as done
    App->>App: Proceed to next message

About code you posted:
async fn non_mandatory_work(guard: WeakShutdownGuard, i: u32) -> u32 {
    println!("Non-mandatory work started for {}", i);
    tokio::select! {
        _ = guard.cancelled() => {
            canceling(i).await;
            println!("Non-mandatory work cancelled early for {}", i);
            return i;
        }
        _ = sleep(Duration::from_secs(2)) => (),
    };
    println!("Non-mandatory work done for {}", i);
    i
}

Here, tokio::select! has two branches: guard.cancelled() and sleep(Duration::from_secs(2)) — in this demo it will work as expected, because sleep(Duration::from_secs(2)) is a slow function and it returns after guard.cancelled()
if we replace sleep(Duration::from_secs(2)) to something like async { println!("Hi") }  — it will be fast enough to be selected before guard.cancelled() which leads to doing processing and submitting after shutdown signal was sent.
And the only solution I can see right now is a function which do:

Infinite await if we shuted down
pass if we not shuted down

either have to wait infinite time for cancellation to complete

I'm not sure that I understand you there. Cancelation happens after branch with guard.cancelled()  is selected and that means that  other branch are dropped

About the last part I meant that on the actual shutdown await statement itself (so the only one in your app (section) that finishes on all work being completed). The shutdown() method waits forever, usually I prefer at least an upper-bound limit, before the orchestrating systems destroys it anyway.
So ok.. I think I understand you now... You mean that work might still get "started" as the select statement is fair and thus starts both and even might progress the 2nd without first checking if it was cancelled or not.
The simple solution is to put a select statement before with a timeout so that you are okay with it not being cancelled but just to check...
So with that approach you would get the following output:
Running `target/debug/i7`
Non-mandatory work started for 0
Silly work...
Non-mandatory work done for 0
Mandatory work started for 0
Mandatory work done for 0
Non-mandatory work started for 1
Silly work...
Non-mandatory work done for 1
Mandatory work started for 1
^CMandatory work done for 1
Canceling after 2
Non-mandatory work not started because of guard cancellation for 2
Mandatory work started for 2
Mandatory work done for 2
Canceling after 3
Non-mandatory work not started because of guard cancellation for 3
Mandatory work started for 3
Mandatory work done for 3
Canceling after 4
Non-mandatory work not started because of guard cancellation for 4
Mandatory work started for 4
Mandatory work done for 4
Canceling after 5
Non-mandatory work not started because of guard cancellation for 5
Mandatory work started for 5
Mandatory work done for 5
Canceling after 6
Non-mandatory work not started because of guard cancellation for 6
Mandatory work started for 6
Mandatory work done for 6
Canceling after 7
Non-mandatory work not started because of guard cancellation for 7
Mandatory work started for 7
Mandatory work done for 7
Canceling after 8
Non-mandatory work not started because of guard cancellation for 8
Mandatory work started for 8
Mandatory work done for 8
Canceling after 9
Non-mandatory work not started because of guard cancellation for 9
Mandatory work started for 9
Mandatory work done for 9

with the updated code:
use std::time::Duration;
use tokio::time::sleep;
use tokio_graceful::{Shutdown, WeakShutdownGuard};

#[tokio::main]
async fn main() {
    let shutdown = Shutdown::default();
    shutdown.spawn_task_fn(|guard| async move {
        for i in 0..10 {
            let nm_guard = guard.clone_weak();
            let result = non_mandatory_work(nm_guard, i).await;
            mandatory_work(result).await;
        }
    });

    // Wait for shutdown signal
    shutdown.shutdown().await;
}

async fn canceling(i: u32) {
    println!("Canceling after {}", i);
}

async fn non_mandatory_work(guard: WeakShutdownGuard, i: u32) -> u32 {
    tokio::select! {
        _ = guard.cancelled() => {
            canceling(i).await;
            println!("Non-mandatory work not started because of guard cancellation for {}", i);
            return i;
        }
        _timeout = sleep(Duration::from_micros(1)) => (),
    };

    println!("Non-mandatory work started for {}", i);
    let silly_fut = async {
        println!("Silly work...");
    };
    tokio::select! {
        _ = guard.cancelled() => {
            canceling(i).await;
            println!("Non-mandatory work cancelled early for {}", i);
            return i;
        }
        _ = silly_fut => (),
    };
    println!("Non-mandatory work done for {}", i);
    i
}

async fn mandatory_work(i: u32) {
    println!("Mandatory work started for {}", i);
    sleep(Duration::from_secs(2)).await;
    println!("Mandatory work done for {}", i);
}

That said, while for many use cases that silly wait time is not an issue, it's also not really technically needed, more of a limitation of the API. So if I do understand you correctly now and the above does achieve what you want then I can make a new version where
tokio::select! {
        _ = guard.cancelled() => {
            canceling(i).await;
            println!("Non-mandatory work not started because of guard cancellation for {}", i);
            return i;
        }
        _timeout = sleep(Duration::from_micros(1)) => (),
    };

can be replaced with:
if guard.cancelled_peek() {
        canceling(i).await;
        println!("Non-mandatory work not started because of guard cancellation for {}", i);
        return i;
    }

Which will ensure to get the same behaviour without having to also add an arbitrary delay in there.
Also if you want that you can perhaps help me come up with a different name then cancelled_peek as it sounds a bit strange...

Got a branch open for you that I can use as a starting point: https://github.com/plabayo/tokio-graceful/pull/8
it's however not yet working so would need some work, but I imagine there is a way, if that is indeed a kind of feature you would need. Output currently shows though that this approach does not work yet:
 Running `target/debug/i7`
Non-mandatory work started for 0
Silly work...
Non-mandatory work done for 0
Mandatory work started for 0
Mandatory work done for 0
Non-mandatory work started for 1
Silly work...
Non-mandatory work done for 1
Mandatory work started for 1
^CMandatory work done for 1
Non-mandatory work started for 2
Canceling after 2
Non-mandatory work cancelled early for 2
Mandatory work started for 2
Mandatory work done for 2
Non-mandatory work started for 3
Canceling after 3
Non-mandatory work cancelled early for 3
Mandatory work started for 3
Mandatory work done for 3
Non-mandatory work started for 4
Silly work...
Non-mandatory work done for 4
Mandatory work started for 4
Mandatory work done for 4
Non-mandatory work started for 5
Silly work...
Non-mandatory work done for 5
Mandatory work started for 5
Mandatory work done for 5
Non-mandatory work started for 6
Silly work...
Non-mandatory work done for 6
Mandatory work started for 6
Mandatory work done for 6
Non-mandatory work started for 7
Silly work...
Non-mandatory work done for 7
Mandatory work started for 7
Mandatory work done for 7
Non-mandatory work started for 8
Silly work...
Non-mandatory work done for 8
Mandatory work started for 8
Mandatory work done for 8
Non-mandatory work started for 9
Canceling after 9
Non-mandatory work cancelled early for 9
Mandatory work started for 9
Mandatory work done for 9

ok @ctrlok added some more code seems to work now in the example code above:
Running `target/debug/i7`
Non-mandatory work started for 0
Silly work...
Non-mandatory work done for 0
Mandatory work started for 0
Mandatory work done for 0
Non-mandatory work started for 1
Silly work...
Non-mandatory work done for 1
Mandatory work started for 1
^CMandatory work done for 1
Canceling after 2
Non-mandatory work not started because of guard cancellation for 2
Mandatory work started for 2
Mandatory work done for 2
Canceling after 3
Non-mandatory work not started because of guard cancellation for 3
Mandatory work started for 3
Mandatory work done for 3
Canceling after 4
Non-mandatory work not started because of guard cancellation for 4
Mandatory work started for 4
Mandatory work done for 4
Canceling after 5
Non-mandatory work not started because of guard cancellation for 5
Mandatory work started for 5
Mandatory work done for 5
Canceling after 6
Non-mandatory work not started because of guard cancellation for 6
Mandatory work started for 6
Mandatory work done for 6
Canceling after 7
Non-mandatory work not started because of guard cancellation for 7
Mandatory work started for 7
Mandatory work done for 7
Canceling after 8
Non-mandatory work not started because of guard cancellation for 8
Mandatory work started for 8
Mandatory work done for 8
Canceling after 9
Non-mandatory work not started because of guard cancellation for 9
Mandatory work started for 9
Mandatory work done for 9

Is that something that would "unblock" you without needing to resort to workarounds. Or does this not help you? if it doesn't please elaborate further on my example (E.g. edit it further to show where there's still an issue for you).
If this does solve your issue then I'll add some more Q&A and testing code and prepare a release today.

Hey!
Thanks for the answers. I will try your implementation, but I found out that it's unnecessary.
tokio::select! macro supports biased; option.
Normaly tokio::select! runs branches randomly. But with the biased; option, it runs branches from top to bottom, and the shutdown check always runs first. The non-mandatory never has a chance to run if the shutdown has already happened.

I checked the cancelled_peek() functionality, and it's pretty interesting and useful. Still, it didn't fit my case because it requires borrowing guard as mutable while I'm trying to borrow it as immutable at the same time (for guard1.cancelled() in the first branch)
It could be solved by adding a weak guard, but in my tests, it didn't work.
For code:
    let shutdown = Shutdown::default();
    let guard1 = shutdown.guard();
    let mut week = shutdown.guard_weak();

    task::spawn(async move {
        for i in 0..10 {
            tokio::select! {
                // biased;
                _ = guard1.cancelled() => {
                    canceling(i).await;
                },
                result = async {
                    if weak.cancelled_peek() {
                        println!("Weak cancelled for {}", i);
                        loop {}
                    }
                    non_mandatory_work(i).await
                } => {
                    mandatory_work(result).await;
                },
            }
        }
    });

it produces output
Non-mandatory work started for 0
^CReceived SIGINT
Canceling after 0
Canceling after 1
Weak cancelled for 2

and goes to the infinite loop after it
That means it somehow blocks guard1.cancelled() from execution and I don't understand why

https://docs.rs/tokio/latest/tokio/macro.select.html#fairness

Perfect @ctrlok then I think I'm going to close the open MR and drop that feature. As it's added complexity/code, without a real use case then. We can always add it later if we do find a use case for which it is required. Seems to me that that biased does indeed achieve what you wanted to do.

Thank you so much for such detailed answers and help!

Still, it didn't fit my case because it requires borrowing guard as mutable while I'm trying to borrow it as immutable at the same time (for guard1.cancelled() in the first branch)

I do not get what the issue with requiring mutability though. tokio-graceful is created to make cloning guards cheap (e.g. non-locking). So feel free to make as many clones as you want. That goes the same for regular guards as well as weak guards. So as such you should be able to mark it as mut given that you can have always a single owner.
That said, if we do ever find a use case for the peeking, we can also make it &self instead of &mut self, as the core functionality for peek doesn't require mutability. I only did it so that I can update the state if I checked it anyway, but that's more of an optimisation, not a requirement. So to be clear, we can make it immutable if also that has a real use case.
And as I said before in my examples do make your life easier by spawning tasks or task functions directly from the guard or main shutdown handler. It does the same as task::spawn but it ensures there is a guard cloned for you and moved into the task without you having to do that manual work.
The infinite loop is normal though, as you never await within the loops, so you are essentially doing a blocking task within your future. Which is a mix of colours. And not a good one. First of all that's a very expensive operation either way, as it's similar to a "spinning lock", but if you do for some reason I do not get want something like that you'll at the very least will need to yield (https://docs.rs/tokio/latest/tokio/task/fn.yield_now.html) on every iteration, giving other futures the chance to poll. Even then though that future will never complete making me even less sure why you want something like that.
Glad to help. Hopefully you are indeed helped and unblocked, and can happily use tokio-graceful onwards and forward. If not, do feel free to re-open or make a new issue. I do want to help, and gladly do so. So if you feel stuck or have a question do feel free to reach out :) Take care.


Failing tests with latest tree-sitter versions

At the moment CI piplines use the tree-sitter fork, which is at version 0.20.0
Running tests on main branch via latest versions (0.20.1 and 0.20.2 tested) of tree-sitter results in a few failing tests:

Steps to reproduce:
cargo install tree-sitter-cli
tree-sitter generate
tree-sitter test

Huh, wonder how this wasn't caught by CI. I noticed this on my mac a couple weeks ago but thought it was just a local thing. Will look into it.

I've tested multiple combinations locally on Linux:

Generate by
Test by
Test result

fork
fork
ok

fork
upstream
error

upstream
fork
error

fork
upstream
error

So, even with the fork-generated grammar latest tree-sitter versions fail to parse some specs with disj_list and conj_list correctly

The more surprising thing here is that grammars generated with upstream fail on fork. The get_column changes are present in the runtime tree-sitter C library, not the generated code. I will do the following:

Rebase fork changes on latest tree-sitter release and create another fork release
Actually get around to writing good tests for the get_column changes so I can merge them with upstream

he more surprising thing here is that grammars generated with upstream fail on fork

Ah, that's my copy-paste fault. Sorry for that

Neovim ts playground also shows the behavior described above.
Syntax highlighting is broken as well

Neovim

If you would believe it, I had to hack together a fork of neovim using my tree-sitter fork for the demo lol: https://github.com/tlaplus-community/neovim

Required changes have been merged into upstream tree-sitter and a new release was issued yesterday. Now we are just waiting for the tree-sitter-cli NPM module to be updated; see https://github.com/tree-sitter/tree-sitter/issues/1613

Neovim (nightly) already has tree-sitter 0.20.3 since yesterday ;)

0.20.4 is out on npm.


after opening the veo from clicking the edit cell, the graph should be here

Currently, it just says create a query, even though there is a query selected in the builder.

See also https://github.com/influxdata/influxdb/issues/12789


Sample for Android 10 unstable! (restart or crash)

Bug Information
MediaPlugin take many photos results in restart or crash the app on some Android tablet devices.
Version Number of Plugin: 5.0.1
Device Tested On: Tablet Samsung SM-T515 Android 10.0
Simulator Tested On: -
Version of VS: Microsoft Visual Studio Enterprise 2019 Version 16.7.6
Version of Xamarin: Xamarin.Essentials <IP_ADDRESS>, Xamarin.Forms <IP_ADDRESS>4
Versions of other things you are using: NETStandard.Library 2.0.3 Android 10.0 (API 29 - Q), Android SDK Tools 26.1.1, provider android:name="androidx.core.content.FileProvider".
Steps to reproduce the Behavior
Debug or build and run APK using test project on Android tablet (Samsung SM-T515).
https://github.com/roman536/Xamarin-MediaPlugin-Test
Use TakePhoto function to make many photos continuously.
Try to focus the view on monochromic surfaces.
Notice only some Android tablet devices have troubles with MediaPlugin!
Expected Behavior
The message "The plugin CrossMedia has been started!" should appear after init only.
The TakePhoto functionality should be able to make and store many photos continuously.
Actual Behavior
Not after first photo, but randomly some activity results in restart or crash the app.
Once before 10th photo, sometimes after 20th.
APK or test video file can be provided on request.
Code snippet
https://github.com/roman536/Xamarin-MediaPlugin-Test

Hi @roman536 , am facing same issue in same Tablet Samsung SM-T515 Android 10.0
https://github.com/jamesmontemagno/MediaPlugin/issues/901

I've been observing a relatively large number of unexplained crashes (they're not caught by App Center) on Samsung SM-T515 devices and only now I've had someone reach out explaining it happens when they're taking photos.
(unconfirmed) one user may have started getting issues following a device update from android 9 to android 10.
I've no access to one of those devices to actually attempt to reproduce this - has anyone got this to fail on another device type?

I've been observing a relatively large number of unexplained crashes (they're not caught by App Center) on Samsung SM-T515 devices and only now I've had someone reach out explaining it happens when they're taking photos.
(unconfirmed) one user may have started getting issues following a device update from android 9 to android 10.
I've no access to one of those devices to actually attempt to reproduce this - has anyone got this to fail on another device type?

Its true. working in android 9 but crashing in 10.

If you have access to these devices, can you tell what is terminating the application? is there any specific error message that you can share?
If the application is being terminated by android, perhaps you can check the android device log for messages that can point us in the direction of the actual issue?

I also ran into this issue with a SM-T515. I was able to replicate the issue, but I tried switching to the Xamarin.Essentials Camera implementation and I ran into the same issue. I found the same kind of issue here: https://github.com/apache/cordova-plugin-camera/issues/345 as well.
I tried installing OpenCamera and I wasn't able to replicate the crash using OpenCamera.
This might be an issue with the Samsung Camera App.

This or other circumstances may help, but there must be some deeper complication.
I could have run into crash using Pick function to get pictures from the Gallery as well!
Try to pick continuously any picture for 20-50 or more times. Sometimes the device makes a breather, sometimes works farther on, but it smothers somehow.
All the same processes perform much more powerful on the better smartphone.
Maybe the smaller display needs less power, maybe there is better core inside?
Is there time out issue while acquiring wide permissions?

also possibly related https://github.com/apache/cordova-plugin-camera/issues/665

Meanwhile I have evaluated Xamarin.Essentials 1.6.0 MediaPicker.CapturePhotoAsync method resulting in same behavior on Samsung SM-T515. Therefore, the mistake insinuates rather to Android 10 specifics on this or similar devices.

Meanwhile I have evaluated Xamarin.Essentials 1.6.0 MediaPicker.CapturePhotoAsync method resulting in same behavior on Samsung SM-T515. Therefore, the mistake insinuates rather to Android 10 specifics on this or similar devices.

I am closing this issue due to nature of the crash generated not directly by Media.P* but rather dependency on the hardware and android system.
Enclosed there is last evaluation with 2 Cam-Apps installed:

MyApp with implemented Media.P* calls some Cam-App.
There is a selection for Cam-App 1/2 (OK so far).
After selection for Cam-App1 but before drop any photo MyApp disappears from device memory or not. If so, there is no return (crash). If MyApp is still living, go farther.
Do not make photo still but open another Cam-App2. MyApp should still exist in memory.
We are now taking a photo with Cam-App2 still holding MyApp and called Cam-App1 in memory. This step results often in disappeared MyApp from memory.
In such scenario there is no return to MyApp after pushing OK button on called Cam-App.

I guess Media.P* becomes any return event from called Cam-App but is watching file system for new photos trying to import them and reactivate itself. It is irrelevant to Cam-App (one or more). This seams not to work on some devices like Tablet Samsung SM-T515 having 2GB memory and originally Android 9.0 but updated to Android 10.0

I am closing this issue due to nature of the crash generated not directly by Media.P* but rather dependency on the hardware and android system.
Enclosed there is last evaluation with 2 Cam-Apps installed:

MyApp with implemented Media.P* calls some Cam-App.
There is a selection for Cam-App 1/2 (OK so far).
After selection for Cam-App1 but before drop any photo MyApp disappears from device memory or not. If so, there is no return (crash). If MyApp is still living, go farther.
Do not make photo still but open another Cam-App2. MyApp should still exist in memory.
We are now taking a photo with Cam-App2 still holding MyApp and called Cam-App1 in memory. This step results often in disappeared MyApp from memory.
In such scenario there is no return to MyApp after pushing OK button on called Cam-App.

I guess Media.P* becomes any return event from called Cam-App but is watching file system for new photos trying to import them and reactivate itself. It is irrelevant to Cam-App (one or more). This seams not to work on some devices like Tablet Samsung SM-T515 having 2GB memory and originally Android 9.0 but updated to Android 10.0


Models are not affected by room darkness.

To reproduce, use the light switch in the first room on Defection, or load the start of Extraction.

This also applies to vertex shadows:

This should be fixed now.

Can confirm both screenshots are fixed in the current artifact.


tab-bar: Add StackBlitz demonstration for handling browser refresh and active tab

Added example active-tab-router.directive.ts, but it requires the not yet released v0.38.2. Will update example after 0.38.2 is published.

All set. Closing


In Memory Node Connection Error

🐛 Bug Report for zksync-cli
📝 Description
When following the zkSync 101 Guide and running npm run deploy:hello-zksync, I encountered a socket hang up error during deployment. Additionally, when checking the balance using cast balance, I received a connection error. Both issues seem related to the network or RPC configuration.
🔄 Reproduction Steps

Follow the steps in the zkSync 101 Guide to set up the project.
Attempt deployment with the following command: npm run deploy:hello-zksync
Test cast balance: cast balance 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 --rpc-url http://<IP_ADDRESS>:8011

🤔 Expected Behavior

The deployment script should deploy the contract without errors.
The cast balance command should return the balance of the specified address.

😯 Current Behavior

Deployment fails with a socket hang up error.
The cast balance command returns a connection error (Connection reset by peer).

🖥 Environment
nodejs 22.11.0
npm 10.9.0
npx 10.9.0
pnpm 9.14.4
📋 Additional Context
Add any other context about the problem here. If applicable, add screenshots to help explain.
📎 Log Output
Paste any relevant log output here.

Stems from: https://github.com/zkSync-Community-Hub/zksync-developers/issues/796

Solved in era-test-node release v0.1.0-alpha.35


fixed two issues:

tree now finds correct class to avoid dup
finding the correct assembly now find root project

closing because I accidentally pushed to master...


Added dry run option

Added sf compatibility

Added the ability to switch between the older sfdx commands and newer sf commands. Also added a dry run option


Update devfile sample output in deploying-a-devfile-using-odo.adoc

/kind documentation
/area devfile
The sample output in deploying-a-devfile-using-odo.adoc is out of date and from pre odo 1.2.0. We should update the samples on that page so that they reflect what's current in odo 1.2.0.
For example, the doc has the following for odo push:
   $ odo push
    •  Push devfile component myspring  ...
    ✓  Waiting for component to start [30s]

   Applying URL changes
    ✓  URL myspring-8080: http://myspring-8080.apps-crc.testing created
    ✓  Checking files for pushing [752719ns]
    ✓  Syncing files to the component [887ms]
    ✓  Executing devbuild command "/artifacts/bin/build-container-full.sh" [23s]
    ✓  Executing devrun command "/artifacts/bin/start-server.sh" [2s]
    ✓  Push devfile component myspring [57s]
    ✓  Changes successfully pushed to component

When it should be:
$ odo push

  Validation
   ✓  Validating the devfile [81808ns]

  Creating Kubernetes resources for component myspring
   ✓  Waiting for component to start [5s]

  Applying URL changes
   ✓  URL myspring-8080: http://myspring-8080.apps-crc.testing created

  Syncing to component myspring
   ✓  Checking files for pushing [2ms]
   ✓  Syncing files to the component [1s]

  Executing devfile commands for component myspring
   ✓  Executing devbuild command "/artifacts/bin/build-container-full.sh" [1m]
   ✓  Executing devrun command "/artifacts/bin/start-server.sh" [2s]

  Pushing devfile component myspring
   ✓  Changes successfully pushed to component

We should also mention the --downloadSource flag that was added in 1.2.0.

/assign


Use selectors extracted during detection

Show and save any selectors extracted during detection.
NOTE - selector on any individual 'box' selected is not guaranteed (yet?).

Example of saved JSON:

{
  color: "rgba(255, 255, 0, 0.4)"
  domClasses: "col-sm-3.col-md-3.sppb-in-article"
  domId: "sp-right"
  id: "box-id-8945113"
  layout: {numCols: 0, numRows: 0}
  mapping: "exclude"
  xpath: "/html[1]/body[1]/div[1]/div[1]/section[4]/div[1]/div[1]/div[2]"
}

If section mapping is targeting the non-developer/less technical user would it make sense to simplify this table?

Color heading could be left out
Change Id/Classes to simply Selector?
Is layout useful? I don't know what it means.

Color heading could be left out
Change Id/Classes to simply Selector?
Is layout useful? I don't know what it means.

Color matches the 'box' in the preview's color.  It makes it easier to spot it.
Yes - Selector might be better.
I've been playing with Layout to identify things like columns, and could use it for auto-selecting the mapping.  0x0 isn't helpful for sure, except to give you a hint that it is a simple component, but "N/A" might be more meaningful.


1.2.6 - GEOMESA-1507 Adding bin filtering to saved query servlet

Signed-off-by: Emilio Lahr-Vivaz<EMAIL_ADDRESS>

do we want to cut a <IP_ADDRESS> with this?

yeah, Britt wants it in there even though it's not technically a bug fix.


Update core.py

for #3694

IMO the error message is not so clear and needs to be capitalized. The same message as pipenv --venv should be just OK.

@frostming "location not created nor specified" was copied from current RuntimeError. This won't make break changes if some tools captured stderr and search the string.

@Cologler Thanks for contributing to pipenv!  It will be nice to not have the whole stack trace print out.  I hope that I can work on the cause of the underlying problem so we won't have to see the error message 😅

@frostming any news for this?

would you mind adding a news entry?

@frostming My English is poor 😂


"Recent Players" window in AdminMenu

We need a recent players window that pulls the list of players from the DB, optionally can search all players by username, to find their ID to ban. Also add a way to ban them directly from this menu.

Is this still an issue?


merge: update master from develop

Codecov Report

Merging #19 into master will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master      #19   +/-   ##
=======================================
  Coverage   88.50%   88.50%
=======================================
  Files           1        1
  Lines          87       87
=======================================
  Hits           77       77
  Misses         10       10

Impacted Files
Coverage Δ

index.js
88.50% <100.00%> (ø)

Continue to review full report at Codecov.

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

@thedaviddias We should release a version for the latest version of 0.14 htmlhint
Then we can start with conversions for 1.0.0


kubectl fails to launch after rancher rollback

Rancher version: v2.1.6
Upgrade to v2.2.0-rc2 and rollback to v2.1.6
Steps:

Create 3 node clusters [DO, GKE] in rancher v2.1.6 setup . Create new workloads/ingress in each of the clusters.
Upgrade rancher to v2.2.0-rc2 . Create new workloads/ingress in each of the clusters. Create a new cluster
Rollback to rancher v2.1.6

After rollback, launch kubectl in any of the clusters. kubectl fails to launch with the below error:
No cacerts provided
command terminated with non-zero exit code: Error executing in Docker Container: 1

@soumyalj you rolled back by  restoring the etcd snapshot of rancher-server?

Rollback was performed using the steps below:
https://rancher.com/docs/rancher/v2.x/en/upgrades/rollbacks/single-node-rollbacks/

kubectl fails to launch after rancher rollback for cluster types - DO, AWS, Azure

Tested with upgrade from v2.1.6 to master build from Feb 26.

Create 3 node clusters [DO, GKE] in rancher v2.1.6 setup . Create new workloads/ingress in each of the clusters.
Upgrade rancher to master . Create new workloads/ingress in each of the clusters. Create a new cluster
Rollback to rancher v2.1.6

After rollback, launch kubectl in any cluster. kubectl shell was functional in all the clusters.


feat:build support save output as tar file

Describe what this PR does / why we need it
build default output is filesystem, if user specify "type=local,dest=dir or filename" ,will save output as local file.
save output at filesystem:
sealer build -t my-kubernetes:1.19.8
save output as local file:
sealer build -t my-kubernetes:1.19.8 --output type=local,dest=/path/to/my-image.tar
at meantime , sealer save support specify dir with default image name as tar filename.
sealer save kubernetes:v1.19.8 -o /tmp
Does this pull request fix one issue?

Describe how you did it
Describe how to verify it
Special notes for reviews

We already has sealer save why need this feature?  Or why not just call the Save interface when complete build?

We already has sealer save why need this feature? Or why not just call the Save interface when complete build?

1, use "--output", we can support to set image local save dir , or save image tar file to oss or docker hub . and the default is local filesystem.
2, old save interface  mix transfer imagename to *v1.image ,loading image metadata, writing file together, cannot be used directly.
3,sealer save dont support specify dir must the full ${image name} .tar .


[Explore]: Is Korifi support stratos UI

Background
Hi ,
Is korifi support stratos UI or any UI application
Acceptance Criteria
check if korifi support stratos UI or any UI applicatio
Timebox
No timebox
Dev Notes
No response

Hi @mohamedhani!
I'm not very familiar with Stratos, but I suspect it wouldn't work. Korifi does not use UAA for authentication, but instead delegates authentication to Kubernetes.
Each Kubernetes provider authenticates in a different way, which is why we have modified the cf CLI to leverage the same authentication mechanism used by kubectl. I don't think there's a straightforward of doing the same thing for Stratos.
We might explore this in the future but it's not a priority at the moment. Thanks for reaching out!


[azure-messaging-eventhubs-cpp] Shorten source paths

Windows has a path limit of 260 characters, and certain packages fail to build when depending on azure-messaging-eventhubs.
This change patches the directory names and it does not change any public surface available to the port users.
cc @LarryOsterman

I don't think this is something vcpkg needs to patch. It is up to upstream to change the dir layout. Just put in a length warning and/or use a similar approach to qtwebeengine without needing to add more than 200 lines of patch

@antkmsft Could you modify your PR according to dg0yt's suggestions?

@Neumann-A, I am from the upstream. We will shorten the path in our repo. We don't want to create a new release just to shorten the path without visible user benefits. We don't want to wait for the next planned release. Some of our development is blocked by this, as we made several CI pipelines that obtain our packages via vcpkg on multiple platforms, for better verification.

@antkmsft Use cmake variable VCPKG_INSTALL_OPTIONS and add --x-buildtrees-root=<shortpath> to shorten the default buildtree vcpkg uses. This PR seems totally unnecessary from my point of view.

I don't think this is something vcpkg needs to patch. It is up to upstream to change the dir layout. Just put in a length warning and/or use a similar approach to qtwebeengine without needing to add more than 200 lines of patch

For context, the filename lengths are causing issues on Windows which block active development of the azure-sdk-for-cpp repo.
We don't have the option of making a fix in our CI pipeline right now, because the azure-sdk-for-cpp repo releases package updates on a monthly cadence, but we can do this in a patch to vcpkg which will resolve the issue without breaking customers.
And then in the October update, we'll rename the source layout to alleviate the problem long-term.

@antkmsft Use cmake variable VCPKG_INSTALL_OPTIONS and add --x-buildtrees-root=<shortpath> to shorten the default buildtree vcpkg uses. This PR seems totally unnecessary from my point of view.

How much of the path does that actually shorten? It looks like the vast majority of the path comes from the source tree. Or is the idea to move the buildtrees-root outside the cmake build scope?

How much of the path does that actually shorten?

that depends on where your vcpkg is located. It basically removes %vcpkg_root%/buildtrees and replaces it with <shortpath>

@Cheney-W, I updated the PR to use a cmake directive for renames, and I added azure storage ports as well.

@Cheney-W, if there is no further feedback, would it be possible to get this merged by the end of this week?


chore: import repository https://github.com/hazem-internship/jenkinsfile.git

this commit will trigger a pipeline to generate the CI/CD configuration which will create a second commit on this Pull Request before it auto merges

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign
You can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Pass Column Names

How do we pass the column names dynamically to the Where method. Filters is a dictionary with key being the name of the column and Value is the value of the filter, it can be a list of strings, single string.  I would like to do something like this,  of-course this is pseudo code, in production I will check if the column exists in the database
foreach (var filter in filters)
{
              q.Where($"{filter.Key}= @{filter.Value}");

            }

Thanks in Advance

Check the raw modifier in the documentation.
Example here: https://stackoverflow.com/a/63650815/3606250
So you can use like:
q.Where($"{filter.Key:raw} = {filter.Value}");

I was looking into, thanks for the response.

Thanks for all your help. Awesome library, I am able to pass filters dynamically at runtime and everything is working as expected. Cheers :)
foreach (var filter in filters)
{
              q.AppendLine($"AND {filter.Key:raw} = {filter.Value.ToString()}");

            }


Static mount options should be on the static page

there's a blurb about what to how to set mountOptions if creating a static volume which really should go on the static page as it just add confusion here

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

ID: a57e48b4-dc33-0b9d-b773-42ce7d2bffd0
Version Independent ID: e912ac2d-cf6a-0b54-4697-1940b1270874
Content: Dynamically create a Files volume for multiple pods in Azure Kubernetes Service (AKS)
Content Source: articles/aks/azure-files-dynamic-pv.md
Service: container-service
GitHub Login: @iainfoulds
Microsoft Alias: iainfou

Thanks for the feedback! We are currently investigating and will update you shortly.

@cmeyertons can you clarify a bit more on the enhancement you want to see?
I see the mount options here

What else were you looking to see added here?

it's this blurb i'm talking about:

why call this out on the dynamic page when you could put this documentation directly on the static page?
reason i ask, is i was going through and copying the file examples, and i had to re-read the blurb to just ignore this portion


sap.sap_operations collection version 1.0.0

sap.sap_operations collection version 1.0.0

Thanks for committing. Most of it looks good to me.

I do not understand the change in .gitignore. Can you please explain.
We need to merge the galaxy.yml file, which needs to keep the IBM authors for the whole collection and the license string does not comply with SPDX standard (the - is missing I guess).

To fix the latter problem can you please change the PR from the main to the dev branch. The I will fix the Galaxy.yml with another quick PR.

I do not understand the change in .gitignore. Can you please explain.

This is by mistake, sorry.

We need to merge the galaxy.yml file, which needs to keep the IBM authors for the whole collection and the license string does not comply with SPDX standard (the - is missing I guess).

We are open to any suggestions.

To fix the latter problem can you please change the PR from the main to the dev branch.

As there will be a link from AAP to public repo with sap.sap_operations collection. I think it is in the interest of people clicking that link from AAP (this will lead to main branch) to have all the code that is in AAP in the main (default) branch.

OK, this time it might be ok, but may take a little longer because we have to bypass the process here, which needs some exceptions

@rhmk

OK, this time it might be ok, but may take a little longer because we have to bypass the process here, which needs some exceptions

it this is a statement about merging into dev VS main branch, then we have a misunderstanding here. This is not an ask for one time exception. This is requirement from AAP, we have to put a link to public repo in AAP for the collection. And link to repo pointing to the default branch (main).

That was exactly my question too. Do we really need same functionallity twice ?
@kksat could please have a look here: https://github.com/sap-linuxlab/community.sap_libs/blob/main/plugins/modules/
The other question is, shouldn't we put all modules in one place ?

@rainerleber to answer your question

That was exactly my question too. Do we really need same functionallity twice ?
@kksat could please have a look here: https://github.com/sap-linuxlab/community.sap_libs/blob/main/plugins/modules/

I do not see same functionality being duplicated here. I see different ways of doing similar operations.
We are aware of collection community.sap_libs. Unfortunately for purposes of publishing to AAP we cannot depend on community collections.

The other question is, shouldn't we put all modules in one place ?

All modules that are required by collection sap.sap_operations are in one place in that collection. So as per Ansible recommendations collection does not depend on any other collections, just ansible core and OS packages.

@rainerleber to answer your question

That was exactly my question too. Do we really need same functionallity twice ?
@kksat could please have a look here: https://github.com/sap-linuxlab/community.sap_libs/blob/main/plugins/modules/

I do not see same functionality being duplicated here. I see different ways of doing similar operations. We are aware of collection community.sap_libs. Unfortunately for purposes of publishing to AAP we cannot depend on community collections.

The other question is, shouldn't we put all modules in one place ?

All modules that are required by collection sap.sap_operations are in one place in that collection. So as per Ansible recommendations collection does not depend on any other collections, just ansible core and OS packages.

So to support stuff which is already present you will accept confusing users ?
And you really want to explain me a untested module will be better ?

Generally a good module will be tested with a sanity, unit test or a integration test against different ansible and python
versions.

Wouldn't it be better to work on the same code base ? Having a upstream oss variant and a supported ?

So to support stuff which is already present you will accept confusing users ?
I do not understand what you are referring to here.

And you really want to explain me a untested module will be better ?
I completely agree that tested module is better than untested one.

Generally a good module will be tested with a sanity, unit test or a integration test against different ansible and python
versions.
Fully agree. And just for your information, all the code has been tested with unit testing, sanity, molecule testing, code reviewed.

Wouldn't it be better to work on the same code base ? Having a upstream oss variant and a supported ?

That is exactly intention of this PR. There has been separate repo with this collection. Apparently it is not allowed to create separate repo for separate collection in SAP Linux Lab org.

from my point of view generally this pr is unacceptable because:

it tries to rename the collection and a lot of other stuff
not following any specifications and guidelines
does not have any tests for the modules
modules do the same as modules in sap_libs (redundancy)
not intended to be community driven

@sean-freeman what do you think

from my point of view generally this pr is unacceptable because:
* it tries to rename the collection and a lot of other stuff

The intention of this PR is to start discussion, how to store supported collection with unsupported content in single repo, so I think this point should be discussed, not considered as no go because of this. Sure there are challenges to be solved.

* not following any specifications and guidelines

what are they?

* does not have any tests for the modules

We have all - sanity, unit tests and integration tests. We can provide them, but there are no tests/CI in this repo, so maybe better to push this separately after discussion, how/where to test.

* modules do the same as modules in sap_libs (redundancy)

True. But there are few different things, which we should discuss. We would need to anyway prepare such module to support for example kernel update, and it's reusing generic module_utils stuff, which supports also using local unix socket, instead of providing username/password for SOAP.

* not intended to be community driven

I think we would like to do so.

@sean-freeman what do you think

Require @rainerleber to comment on overlap with existing Ansible Modules consolidation and merging activities under community.sap_libs. A review is required to analyse:
* [service.py](https://github.com/sap-linuxlab/community.sap_operations/blob/371bbe6f5b16148cb9d9f26dea8ddd11de3e839f/plugins/modules/service.py) and [system.py](https://github.com/sap-linuxlab/community.sap_operations/blob/371bbe6f5b16148cb9d9f26dea8ddd11de3e839f/plugins/modules/system.py) Ansible Modules included in this PR `vs.` existing functionality under Ansible Role [sap_operations/sap_control](https://github.com/sap-linuxlab/community.sap_operations/tree/dev/roles/sap_control) and ongoing work to port these to use [sap_libs/sap_control_exec](https://github.com/sap-linuxlab/community.sap_libs/blob/dev/plugins/modules/sap_control_exec.py) Ansible Module.

* [system_info.py](https://github.com/sap-linuxlab/community.sap_operations/blob/371bbe6f5b16148cb9d9f26dea8ddd11de3e839f/plugins/modules/system_info.py) Ansible Module included in this PR `vs.` existing functionality under [sap_operations/sap_facts](https://github.com/sap-linuxlab/community.sap_operations/blob/main/plugins/modules/sap_facts.sh) Ansible Module and ongoing work to port this into [sap_libs/sap_system_facts](https://github.com/sap-linuxlab/community.sap_libs/blob/main/plugins/modules/sap_system_facts.py) Ansible Module.

There was already deviation in approach to start/stop and gathing SAP System information when the initiative was started. After much discussion, there was development work in progress to consolidate and @rainerleber was leading this consolidation according to SAP LinuxLab Governance Board agreements.
I would not suggest merging this PR until it is clear why it is necessary to have separate Ansible Modules with this overlapping functionality, and deviation from using sap_libs Ansible Collection to store the highly reusable / generic usage Ansible Modules (e.g. 'get facts', 'call SAP RFC endpoint', 'call SAP SOAP endpoint' etc etc.)

Would you please explain why some of the modules are using SOAP with Python code, some bash code with sapcontrol binary calls, and some Python code with sapcontrol binary calls?
It would be great to consolidate. In my opinion the best solution is to use SOAP with Python, as you can programatically access the return data, rather then parse stdout of the sapcontrol binary calls, which shouldn't be considered as anything stable, SOAP API is considered stable and backward compatible, so it's easy to be supported.
Also it's easier to code waiting functionality for calls, which don't support waiting implicitly.
So would you please explain the pros and cons of your approach in compare to use SOAP API?

Also as far as I read your code properly, your code doesn't support impotency, which I think should be required. Our code does, and we also have tests for it. I think there is space for discussion, how to consolidate and solve the problems properly.

Not that we misunderstand one another i am not against your contribution i am happy for any contribution :-) so Sean and I have agreed to move every module out of the collection to sap_libs from time to time. At the moment i have not that much time to go further. But the *.sh modules should be replaced for example with the sap_facts module form sap_libs or the sap_control_exec each module in sap_libs will follow the ansible guidelines and are idempotent.

and are idempotent.

I didn't review them carefully, but for example this operation is not: https://github.com/sap-linuxlab/community.sap_operations/blob/main/roles/sap_control/tasks/sapcontrol.yml#L17

I don't talk about the modules provided at sap_operations, these modules should be migrated to community.sap_libs and rewritten if neccessary because they aren't that good. Each module in sap_libs are following ansible dev guidelines and are idempotent and also included in the Ansible Package.
You should have a look at sap_libs because there is already a sapcontrol module with suds in place:
https://github.com/sap-linuxlab/community.sap_libs/blob/main/plugins/modules/sap_control_exec.py
Maybe we should discuss consolidating both approaches.

I think this task will be reported as changed even if the system is already in state the user is asking for.
But anyway, if you have time please write down the requirements you have to have this code mergeable, we can discuss and work on it.

A lot of requirements are documented in this pr already (see code comments). At first you should revert the change from community.sap_operations to sap.sap_operations.
Adjust your modules. License, namespaces etc. considering the move to sap_libs because we discussed sap_libs as the exclusively modules collection.
Test integration. Add Pipeline for test etc.
Not remove any stuff from sap_operations collection.
Later you can use the script from RH to convert to a supported collection.

PR closed, not required anymore.


Remove redundant prefixes from fields in PanelCfg schema interface

This is the current PanelCfg schema interface contract that all PanelCfg composable kinds must follow:
https://github.com/grafana/kindsys/blob/b1fe864ba880ea7aa4544e7cbf810856d40db56d/schema_interface.cue#L98-L109
Having the Panel prefix is redundant. Options and FieldConfig would be perfectly sufficient.
The change here is simple enough while we're effectively in pre-launch mode:

[x] All panel implementations in grafana/grafana will need to be updated
[x] Names of generated types within panel plugins will need to be updated as well
[ ] Grok will need to be regenerated.

Sooner we do this one, the better, because it's a wildly breaking change 😄

Requires the following PRs to be merged:

Grafana https://github.com/grafana/grafana/pull/68034
Kindsys https://github.com/grafana/kindsys/pull/7
This PR needs to be updated to use kindsys main as a dependency in Grafana https://github.com/grafana/grafana/pull/65297

Whoops, in skirting around the lineage flattening PR, i had to modify ordering of these merges. grafana is now on an off-main commit for kindsys, and will have to stay there until we fix grafana/grafana#68034


Split payment history into payments and refunds

what's the issue related to this PR? IMO better off to have all transactions in one, but filter (e.g. checkboxes) for each transaction type

There might be other transaction types, e.g. issuance of free tickets, right?
Would it be better to have:
Filters: [ ] purchases  [ ] refunds   [ ] other

We have change this page to show only payment related transactions. In this
case, only paid and refund of tickets and route pass will be shown.
Things like issue free tickets or ticket purchase using route pass are not
shown because there is no payment involved.
On Fri, 29 Jun 2018 at 10:57 AM, Daniel Sim<EMAIL_ADDRESS>wrote:

There might be other transaction types, e.g. issuance of free tickets,
right?
Would it be better to have:
Filters: [ ] purchases [ ] refunds [ ] other
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/datagovsg/beeline-frontend/pull/647#issuecomment-401232728,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVtU3-rhCTUM2wxJ9lca5kQNmS3q0MBfks5uBZepgaJpZM4U66Bb
.

@joelchoo also, what happened to the infinite scroll?

We decided to remove loading more transactions because we figure that the user will mostly only be concerned with recent transactions - that's why we fetch 80 instead of 20 which should give us at least 2 months of payments for most users.
I think the scroll to load more is also weird UX when we have filters or tabs in the situation where the first refund is say 3 pages in.
We also tried using a load more button instead of loading more on scroll but that still felt like really weird UX.


Added relaxer application

Title and Issue number
Relaxer Application #2551
Close #2551
Checklist:

[X] I have mentioned the issue number in my Pull Request.
[X] I have commented my code, particularly in hard-to-understand areas
[] I have created a helpful and easy to understand README.md

https://github.com/pranjay-poddar/Dev-Geeks/assets/133862694/e3f153aa-10ab-45f3-b98e-a2c44ff21959

@MohitGupta121


Check if the getProduct() method exist instead of php_self name

As the renderWidget is call if you need it, you have to check if the needed method exist on the current controller and not if the controller is the product one.

Let me ping you on this, @maximebiloe

Thank you @prestamodule


Cannot create PPP connection to pudding A9G board

I am not sure if this is a correct forum, but I did not find better location to get some assistance to the issue I am seeing.
I have a A9G pudding board running running V02.02.20190915R firmware. I am trying to connect that A9G board to other MCU via UART. The idea is that A9G is just a GPRS modem that the other MCU is using. This means that I am using AT commands, that are sent to A9G, to enable PPP mode to connect to Internet. The final PPP handshake fails when A9G sends peer refused to authenticate to me. Below is a log output of the issue.  Doing PPP negotiation next. The A9G sent data can be seen below in lines marked recv L2.
[00:00:04.966,278] <dbg> net_l2_ppp.carrier_on: (0x20002930): Carrier ON for interface 0x2001c860
[00:00:04.966,308] <dbg> net_l2_ppp.ppp_change_phase_debug: (0x20002930): [0x2001c89c] phase DEAD (0) => ESTABLISH (1) (start_ppp():203)
[00:00:04.966,308] <dbg> net_l2_ppp.ppp_fsm_lower_up: (0x20002930): [LCP/0x2001c8cc] Current state INITIAL (0)
[00:00:04.966,308] <dbg> net_l2_ppp.ppp_change_state_debug: (0x20002930): [LCP/0x2001c8cc] state INITIAL (0) => CLOSED (2) (ppp_fsm_lower_up():285)
[00:00:04.966,339] <dbg> net_l2_ppp.start_ppp: (0x20002930): Starting LCP
[00:00:04.966,339] <dbg> net_l2_ppp.ppp_fsm_open: (0x20002930): [LCP/0x2001c8cc] Current state CLOSED (2)
[00:00:04.966,339] <dbg> net_l2_ppp.fsm_send_configure_req: (0x20002930): [LCP/0x2001c8cc] Sending Configure-Req (1) id 1 to peer while in CLOSED (2)
[00:00:04.966,400] <dbg> net_l2_ppp.ppp_send_pkt: (0x20002930): [LCP/0x2001c8cc] Sending 6 bytes pkt 0x20019ff8 (options len 0)
[00:00:04.966,430] <dbg> net_l2_ppp.ppp_change_state_debug: (0x20002930): [LCP/0x2001c8cc] state CLOSED (2) => REQUEST_SENT (6) (ppp_fsm_open():309)
[00:00:04.966,522] <dbg> net_l2_ppp.net_pkt_hexdump: send L2
[00:00:04.966,552] <dbg> net_l2_ppp: 0x20019ff8
c0 21 01 01 00 04                                |.!....
[00:00:04.979,827] <dbg> net_l2_ppp.net_pkt_hexdump: recv L2
[00:00:04.979,858] <dbg> net_l2_ppp: 0x20019ef8
c0 21 01 01 00 18 02 06  00 00 00 00 03 04 c0 23 |.!...... .......#
05 06 00 01 e0 6f 07 02  08 02                   |.....o.. ..
[00:00:04.979,888] <dbg> net_l2_ppp.ppp_fsm_input: (0x20002494): [LCP/0x2001c8cc] LCP Configure-Req (1) id 1 payload len 20
[00:00:04.979,919] <dbg> net_l2_ppp.fsm_recv_configure_req: (0x20002494): [LCP/0x2001c8cc] Current state REQUEST_SENT (6)
[00:00:04.979,949] <dbg> net_l2_ppp.ppp_parse_options: (0x20002494): [LCP/0x2001c8cc] Recv option ASYNC_CTRL_CHAR_MAP (2) len 6
[00:00:04.979,980] <dbg> net_l2_ppp.ppp_parse_options: (0x20002494): [LCP/0x2001c8cc] Recv option AUTH_PROTO (3) len 4
[00:00:04.980,010] <dbg> net_l2_ppp.ppp_parse_options: (0x20002494): [LCP/0x2001c8cc] Recv option MAGIC_NUMBER (5) len 6
[00:00:04.980,041] <dbg> net_l2_ppp.ppp_parse_options: (0x20002494): [LCP/0x2001c8cc] Recv option PROTO_COMPRESS (7) len 2
[00:00:04.980,072] <dbg> net_l2_ppp.ppp_parse_options: (0x20002494): [LCP/0x2001c8cc] Recv option ADDR_CTRL_COMPRESS (8) len 2
[00:00:04.980,072] <dbg> net_l2_ppp.lcp_config_info_req: (0x20002494): [LCP/0x2001c8cc] Check option ASYNC_CTRL_CHAR_MAP (2) len 6
[00:00:04.980,102] <dbg> net_l2_ppp.lcp_config_info_req: (0x20002494): [LCP/0x2001c8cc] Check option AUTH_PROTO (3) len 4
[00:00:04.980,102] <dbg> net_l2_ppp.lcp_config_info_req: (0x20002494): [LCP/0x2001c8cc] Check option MAGIC_NUMBER (5) len 6
[00:00:04.980,133] <dbg> net_l2_ppp.lcp_config_info_req: (0x20002494): [LCP/0x2001c8cc] Check option PROTO_COMPRESS (7) len 2
[00:00:04.980,133] <dbg> net_l2_ppp.lcp_config_info_req: (0x20002494): [LCP/0x2001c8cc] Check option ADDR_CTRL_COMPRESS (8) len 2
[00:00:04.980,194] <dbg> net_l2_ppp.fsm_recv_configure_req: (0x20002494): [LCP/0x2001c8cc] Sending Configure-Rej (4) id 1 to peer while in REQUEST_SENT (6)
[00:00:04.980,285] <dbg> net_l2_ppp.ppp_send_pkt: (0x20002494): [LCP/0x2001c8cc] Sending 26 bytes pkt 0x20019ff8 (options len 20)
[00:00:04.980,499] <dbg> net_l2_ppp.net_pkt_hexdump: send L2
[00:00:04.980,529] <dbg> net_l2_ppp: 0x20019ff8
c0 21 04 01 00 18                                |.!....
[00:00:04.980,560] <dbg> net_l2_ppp: 0x20019ff8
02 06 00 00 00 00 03 04  c0 23 05 06 00 01 e0 6f |........ .#.....o
07 02 08 02                                      |....
[00:00:04.985,443] <dbg> net_l2_ppp.net_pkt_hexdump: recv L2
[00:00:04.985,473] <dbg> net_l2_ppp: 0x20019ef8
c0 21 02 01 00 04                                |.!....
[00:00:04.985,504] <dbg> net_l2_ppp.ppp_fsm_input: (0x20002494): [LCP/0x2001c8cc] LCP Configure-Ack (2) id 1 payload len 0
[00:00:04.985,504] <dbg> net_l2_ppp.fsm_recv_configure_ack: (0x20002494): [LCP/0x2001c8cc] Current state REQUEST_SENT (6)
[00:00:04.985,504] <dbg> net_l2_ppp.ppp_change_state_debug: (0x20002494): [LCP/0x2001c8cc] state REQUEST_SENT (6) => ACK_RECEIVED (7) (fsm_recv_configure_ack():702)
[00:00:05.013,458] <dbg> net_l2_ppp.net_pkt_hexdump: recv L2
[00:00:05.013,488] <dbg> net_l2_ppp: 0x20019ef8
c0 21 01 02 00 04                                |.!....
[00:00:05.013,519] <dbg> net_l2_ppp.ppp_fsm_input: (0x20002494): [LCP/0x2001c8cc] LCP Configure-Req (1) id 2 payload len 0
[00:00:05.013,519] <dbg> net_l2_ppp.fsm_recv_configure_req: (0x20002494): [LCP/0x2001c8cc] Current state ACK_RECEIVED (7)
[00:00:05.013,549] <dbg> net_l2_ppp.fsm_recv_configure_req: (0x20002494): [LCP/0x2001c8cc] Sending Configure-Ack (2) id 2 to peer while in ACK_RECEIVED (7)
[00:00:05.013,610] <dbg> net_l2_ppp.ppp_send_pkt: (0x20002494): [LCP/0x2001c8cc] Sending 6 bytes pkt 0x20019ff8 (options len 0)
[00:00:05.013,641] <dbg> net_l2_ppp.ppp_change_state_debug: (0x20002494): [LCP/0x2001c8cc] state ACK_RECEIVED (7) => OPENED (9) (fsm_recv_configure_req():623)
[00:00:05.013,671] <dbg> net_l2_ppp.ppp_link_established: (0x20002494): [0x2001c89c] Link established
[00:00:05.013,671] <dbg> net_l2_ppp.ppp_change_phase_debug: (0x20002494): [0x2001c89c] phase ESTABLISH (1) => AUTH (2) (ppp_link_established():85)
[00:00:05.013,702] <dbg> net_l2_ppp.ppp_change_phase_debug: (0x20002494): [0x2001c89c] phase AUTH (2) => NETWORK (3) (do_network():40)
[00:00:05.013,702] <dbg> net_l2_ppp.ppp_fsm_open: (0x20002494): [IPCP/0x2001c9b8] Current state INITIAL (0)
[00:00:05.013,702] <dbg> net_l2_ppp.ppp_change_state_debug: (0x20002494): [IPCP/0x2001c9b8] state INITIAL (0) => STARTING (1) (ppp_fsm_open():322)
[00:00:05.013,732] <dbg> net_l2_ppp.ppp_fsm_lower_up: (0x20002494): [IPCP/0x2001c9b8] Current state STARTING (1)
[00:00:05.013,763] <dbg> net_l2_ppp.ipcp_config_info_add: (0x20002494): Added IPCP IP Address option <IP_ADDRESS>
[00:00:05.013,763] <dbg> net_l2_ppp.fsm_send_configure_req: (0x20002494): [IPCP/0x2001c9b8] Sending Configure-Req (1) id 1 to peer while in STARTING (1)
[00:00:05.013,824] <dbg> net_l2_ppp.ppp_send_pkt: (0x20002494): [IPCP/0x2001c9b8] Sending 24 bytes pkt 0x20019fb8 (options len 18)
[00:00:05.013,854] <dbg> net_l2_ppp.ppp_change_state_debug: (0x20002494): [IPCP/0x2001c9b8] state STARTING (1) => REQUEST_SENT (6) (ppp_fsm_lower_up():290)
[00:00:05.013,946] <dbg> net_l2_ppp.net_pkt_hexdump: send L2
[00:00:05.013,977] <dbg> net_l2_ppp: 0x20019ff8
c0 21 02 02 00 04                                |.!....
[00:00:05.015,533] <dbg> net_l2_ppp.net_pkt_hexdump: send L2
[00:00:05.015,563] <dbg> net_l2_ppp: 0x20019fb8
80 21 01 01 00 16                                |.!....
[00:00:05.015,594] <dbg> net_l2_ppp: 0x20019fb8
03 06 00 00 00 00 81 06  00 00 00 00 83 06 00 00 |........ ........
00 00                                            |..
[00:00:05.031,219] <dbg> net_l2_ppp.net_pkt_hexdump: recv L2
[00:00:05.031,250] <dbg> net_l2_ppp: 0x20019ef8
c0 21 05 03 00 20 70 65  65 72 20 72 65 66 75 73 |.!... pe er refus
65 64 20 74 6f 20 61 75  74 68 65 6e 74 69 63 61 |ed to au thentica
74 65                                            |te
[00:00:05.031,311] <dbg> net_l2_ppp.ppp_fsm_input: (0x20002494): [LCP/0x2001c8cc] LCP Terminate-Req (5) id 3 payload len 28
[00:00:05.031,311] <dbg> net_l2_ppp.fsm_recv_terminate_req: (0x20002494): [LCP/0x2001c8cc] Current state OPENED (9)
[00:00:05.031,341] <dbg> net_l2_ppp.fsm_recv_terminate_req: (0x20002494): [LCP/0x2001c8cc] Terminated by peer (peer refused to authenticate)
[00:00:05.031,341] <dbg> net_l2_ppp.ppp_change_state_debug: (0x20002494): [LCP/0x2001c8cc] state OPENED (9) => STOPPING (5) (fsm_recv_terminate_req():846)
[00:00:05.031,372] <dbg> net_l2_ppp.ppp_fsm_lower_down: (0x20002494): [IPCP/0x2001c9b8] Current state REQUEST_SENT (6)
[00:00:05.031,372] <dbg> net_l2_ppp.ppp_change_state_debug: (0x20002494): [IPCP/0x2001c9b8] state REQUEST_SENT (6) => STARTING (1) (ppp_fsm_lower_down():239)
[00:00:05.031,402] <dbg> net_l2_ppp.ppp_fsm_close: (0x20002494): [IPCP/0x2001c9b8] Current state STARTING (1)
[00:00:05.031,402] <dbg> net_l2_ppp.ppp_change_state_debug: (0x20002494): [IPCP/0x2001c9b8] state STARTING (1) => INITIAL (0) (ppp_fsm_close():211)
[00:00:05.031,433] <dbg> net_l2_ppp.ppp_change_phase_debug: (0x20002494): [0x2001c89c] phase NETWORK (3) => DEAD (0) (ppp_link_down():118)
[00:00:05.031,433] <dbg> net_l2_ppp.validate_phase_transition: (0x20002494): Invalid phase transition: NETWORK (3) => DEAD (0)
[00:00:05.031,433] <dbg> net_l2_ppp.ppp_change_phase_debug: (0x20002494): [0x2001c89c] phase DEAD (0) => ESTABLISH (1) (lcp_down():235)
[00:00:11.038,452] <dbg> net_l2_ppp.net_pkt_hexdump: recv L2
[00:00:11.038,513] <dbg> net_l2_ppp: 0x20019ef8
c0 21 05 04 00 20 70 65  65 72 20 72 65 66 75 73 |.!... pe er refus
65 64 20 74 6f 20 61 75  74 68 65 6e 74 69 63 61 |ed to au thentica
74 65                                            |te
[00:00:11.038,543] <dbg> net_l2_ppp.ppp_fsm_input: (0x20002494): [LCP/0x2001c8cc] LCP Terminate-Req (5) id 4 payload len 28
[00:00:11.038,543] <dbg> net_l2_ppp.fsm_recv_terminate_req: (0x20002494): [LCP/0x2001c8cc] Current state STOPPING (5)
[00:00:11.038,543] <dbg> net_l2_ppp.fsm_recv_terminate_req: (0x20002494): [LCP/0x2001c8cc] Invalid state STOPPING (5)
[00:00:15.031,524] <dbg> net_l2_ppp.ppp_fsm_timeout: (0x20002930): [LCP/0x2001c8cc] Current state STOPPING (5)
[00:00:15.031,555] <dbg> net_l2_ppp.ppp_change_state_debug: (0x20002930): [LCP/0x2001c8cc] state STOPPING (5) => STOPPED (3) (ppp_fsm_timeout():105)
[00:00:15.031,555] <dbg> net_l2_ppp.ppp_change_phase_debug: (0x20002930): [0x2001c89c] phase ESTABLISH (1) => DEAD (0) (ppp_link_terminated():103)
[00:00:15.031,555] <dbg> net_l2_ppp.ppp_link_terminated: (0x20002930): [0x2001c89c] Link terminated
uart:~$

Any idea why A9G terminates the connection establishment? It ACKs the connection attempt at time 04.985,504 but then later terminates the connection. There is no authentication on PPP link, so no PAP or similar is used. The APN does not have any password or username. The message peer refused to authenticate is confusing as there is no need to authenticate anywhere. The same setup works works fine if I use SIMCOM SIM808 modem instead of A9G, so the cellular connection setup is correctly set.

Same problem. I also cannot use PPP from Mongoose OS.

I was able to get it to work. If your user and password is empty ("", ""). Add a space (" ", " ") to the user and pasword. I use the same module and version but different os. Mine is Mongoose OS.


Add blurb about Tyler's AMOS poster on News page

@WhiffleFish can you add a blurb about your AMOS poster on the news page by the end of this week? Thanks

Still waiting on AMOS 2022 archive to drop to be able to link the work

@WhiffleFish looks like the papers are posted - can you add the appropriate links by the end of this week?


equals should skip null and undefined props

This is a continuation of #151, which fixed the skipping of nodes, but the same issue exists for props.
Here's an example to demonstrate the problem:
import React from 'react';
import {shallow} from 'enzyme';

const Box = ({className}) => (

);

shallow(<Box/>).equals(
); //=> false
shallow(<Box/>).equals(
); //=> true
shallow(<Box className="awesome"/>).equals(
); //=> true

nodeEqual() fails, because it expects className={undefined} property in the other component (
). This is happening here https://github.com/airbnb/enzyme/blob/master/src/Utils.js#L94. Tested using the latest enzyme available on npm (2.5.1).
I think this case should be covered in enzyme by ignoring null and undefined props, which is what React does too. If everyone agrees, I can submit a PR to fix it ;)

That does seem reasonable, but let's get thoughts from more collabs before making the PR.

👍 sounds good to me. If React ignores it, we should too.


Flaky notebook test: set outputs

https://dev.azure.com/monacotools/Monaco/_build/results?buildId=116579&view=logs&j=4d2898ab-dfbe-557e-92e7-aaac158fdd2f&t=b2ac4860-fb3b-5a51-42a7-7423ead0721b&l=363
1) Notebook API tests
       set outputs on interrupt:
     Error: asPromise TIMEOUT reached
      at Timeout._onTimeout (extensions/vscode-api-tests/src/utils.ts:130:11)
      at listOnTimeout (internal/timers.js:554:17)
      at processTimers (internal/timers.js:497:7)

https://dev.azure.com/monacotools/Monaco/_build/results?buildId=116584&view=logs&j=672276a2-8d3a-5fab-615d-090c51352f92&t=c55167a9-8752-5898-67fa-9d7c918c61b3&l=357
  1 failing
  1) Notebook API tests
       set outputs on cancel:

      AssertionError [ERR_ASSERTION] [ERR_ASSERTION]: Expected values to be strictly deep-equal:
+ actual - expected

  [
+   'my output'
-   'Canceled'
  ]
      + expected - actual

       [
      -  "my output"
      +  "Canceled"
       ]

      at D:\a\1\s\extensions\vscode-api-tests\src\singlefolder-tests\notebook.test.ts:819:11
      at withEvent (D:\a\1\s\extensions\vscode-api-tests\src\singlefolder-tests\notebook.test.ts:57:2)
      at Context.<anonymous> (D:\a\1\s\extensions\vscode-api-tests\src\singlefolder-tests\notebook.test.ts:812:3)

Feeling lucky...  Closing because we are using more strict API now and there is more assertions that should tell us more about why/how this fails (if this fails again)


Prow Shows Irrelevant hack/e2e.go under Failed Test Cases

Istio now has junit results on Prow. It shows command like go run hack/e2e.go -v --test --test_args=‘--ginkgo.focus=istio\.io\/istio\/pilot\/pkg\/config\/kube\/crd\sTestControllerCacheFreshness$ under each failed test case, which is a message that does not apply to istio. We use a recent fork of Prow from k8s and this message does not apply to istio and is misleading to the istio developers. Looking forward to removing or customizing it.

Obsolete. Closing.


[ADDED]: Space Drifter

PR Description 📜
The Space Drifter game has been added
Fixes #1989

Mark the task you have completed ✅

[X] I follow CONTRIBUTING GUIDELINE & CODE OF CONDUCT of this project.
[X] I have performed a self-review of my own code or work.
[X] I have commented my code, particularly in hard-to-understand areas.
[X] My changes generates no new warnings.
[X] I have followed proper naming convention showed in CONTRIBUTING GUIDELINE
[X] I have added screenshot for website preview in assets/images
[X] I have added entries for my game in main README.md
[X] I have added README.md in my folder
[X] I have specified the respective issue number for which I have requested the new game.

Add your screenshots(Optional) 📸

Thank you soo much for contributing to our repository 💗

Thank you @Killer2OP ,for creating the PR and contributing to our GameZone 💗
Review team will review the PR and will reach out to you soon! 😇
Make sure that you have marked all the tasks that you are done with ✅.
Thank you for your patience! 😀

@kunjgit Please can you review my PR and kindly merge it.

Thank you  @Killer2OP , for your valuable time and contribution in our GameZone 💗.
It’s our GameZone, so Let’s build this GameZone altogether !!🤝
Hoping to see you soon with another PR again 😇
Wishing you all the best for your journey into Open Source🚀

Hey @Killer2OP,
You can't work on a closed issue 👀!
Follow the proper guideline and make a new PR again 😀.
Happy Hacking 💗

@kunjgit , @gurjeetsinghvirdee ,
Remove the labels.
This game is copied from : https://github.com/bence-toth/space-drifter
Check the link he copied each and every thing.
Original JS Code by developer :

@Killer2OP Code :

I have a small request to you please don't tag me on every repo @killingkillers
I'm already frustrated with other things

Either I will leave this program

I have a small request to you please don't tag me on every repo @killingkillers I'm already frustrated with other things

Okay, will remember next time.

Either I will leave this program

Same, This program is nothing and I'm not going to participate and also not going to suggest anyone now.

If someone want to frustrate then join this program 😕


[TOOLS] tsed-cli

Informations

Type
Version

Tools
3.x

Description
Create a command line tools to scaffold a project like angular-cli.

Project configuration. Ability to choose basic Ts.ED extensions (Swagger, Socket.io, etc...),
Generate a Service,
Generate a Controller,
Generate a Middleware.

Proposal:
Usage: tsed [options] [command]

  Options:

    -V, --version  output the version number
    -h, --help     output usage information

  Commands:

    new              Scaffold a new Ts.ED project
    generate, g  Create a new components (Controller, Service, Middleware, etc...)
    help [cmd]   Display help for [cmd]

@Romakita I am in the process of creating a CLI based on Commander.js and Inquirer.js. Do you think it will be helpful?

@OskarLebuda  Yes, it could be helpul for new developers ;)

Ok, so I’ll try to finish it ASAP ;)

Any update?

On my side, I'm not able to work on currently ^^. @OskarLebuda want to work on. Tell me if you need help.

It’s almost done. I think I’ll create a pull request this week

Nice. Take your time. I won’t be able to review it and merge the branch until two weeks. No computer and small network 😜.
See you ;) (I sent you an invite to the tsed repo ;))

Any update?

Sorry for late, but I had some personal issues. I'll try to create PR this week

@OskarLebuda is there any updates?
I think I can help with this.
We have to plan features first, like:

Project Initializer (we need templates like CRA(https://github.com/facebook/create-react-app/tree/master/packages/react-scripts/template*) or Vue(https://github.com/vuejs-templates))
Codegen: Service, Controller, etc...
Debug/Test/Run, new version check in debug environment
Upgrade mechanism use ts-simple-ast or just a simple git diff(like rn)

Seems the project initializer and codegen is the pain point of CLI and should have higher priority.

^ @Romakita

Hello @edgesite,
Currently, I'm really busy, I work on issue and enhancement on core framework. I know the CLI really importante and contributors are welcome. I can help on this topics to create dedicated repository or given any things required for the project (deployment, tasks, infos, etc...). I worked on projects examples last week which can be reused for a project template.
@OskarLebuda is the first to work on the cli (branch feat/cli).
Tell what can I do to advance the subject and work togother :)
See you
Romain

CLI can be develop on this repository https://github.com/TypedProject/tsed-cli if it's more comfortable for you :)

Okay thanks for update. I think I can make the CLI works and make an iterate plan in a few weeks.

Any progress on this feature?  I can help if need be.

Hello @shakilsiraj
Your help is welcome ;)

@Romakita could you initialize cli repo with some default config, like prettier or eslint or whatever you want to have? I was going to start with cli but I miss the basic skeleton, I started creating the basic features but I don't know which are your preferences
Thanks

@d0whc3r Yes I doing that :)

@d0whc3r I you write the cli in typescript or pure js ?

typescript and rollup to transpile should be a good choise, also eslint instead of tslint

rollup ?

Ok rollup isn't necessary. We haven't needs about to create bundle. isn't a front-end application :)

ok, then you plan to execute with ts-node?

No, I'll compile the source to js (with tsc) and deploy it on npm :)
It's almost done :)

ok, perfect

The project base code is ready :)
I already implemented an example to generate a Controller.
The stack is based on:

Inquirer
Commander
TsED DI
TsED decorators
Lerna.js (monorepo)
Consolidate/handlebars for template
Typescript

I sent you an invitation to the repo ;)
See you

https://github.com/TypedProject/tsed-cli

The cli is available in alpha version:
npm i -g @tsed/cli@alpha

Your feedback are welcome :)
See you

Also I published the @tsed/cli-core package. This package is designed to help developer to create his own CLI with TypeScript and the Ts.ED DI framework + Plugins.
Here the readme:
https://github.com/TypedProject/tsed-cli/tree/master/packages/cli-core

CLI is now in beta. Website is available: https://cli.tsed.io/
See you :)

@Romakita
If I select "Database -> TypeORM" installation gets stuck on "Resolve versions" step.
@tsed/cli 1.6.3
node 10.19.0
yarn 1.22.4
npm 6.13.4
Ubuntu 18.04

Hello @NachtRitter
I released a fix to print an error log when Resolves versions step fail. Can you  reinstall the CLI and run again the same command please :).
See you
Romain

@Romakita
Unfortunately, there is no error. Only an endless step of resolving versions.

Have you a network restrict or a proxy configured?
I’ll try reproduce the bug by installing postgres.

You can also run the command in verbose mode. Maybe the logs will be more interesting.
tsed init . —verbose

Are you on windows ?

@Romakita
Nevermind, I guess it was really some issues with my router. I've checked and realized that I have a big latency between my notebook and router (during packages installation it was ~300-800 ms). After router rebooting looks like it works fine.

Hoo coool xD.
Latest version add docker-compose generation, by adding service (database) according to your database choice :D
See you
Romain


bump Apache.NMS.ActiveMQ library to official and latest version

Merged.

@McMlok this was the PR, i modified your commit to include all the async overload changes. Thank you so much for testing it out!


Allow transform_generic to keep existing fields

Addresses issue #151

Codecov Report

Merging #156 (e5f96a5) into main (28f6256) will increase coverage by 0.63%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #156      +/-   ##
==========================================
+ Coverage   58.08%   58.72%   +0.63%
==========================================
  Files          51       51
  Lines        2949     2968      +19
==========================================
+ Hits         1713     1743      +30
+ Misses       1123     1113      -10
+ Partials      113      112       -1

Flag
Coverage Δ

unittests
58.72% <100.00%> (+0.63%)
:arrow_up:

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

Impacted Files
Coverage Δ

pkg/pipeline/transform/transform_generic.go
100.00% <100.00%> (ø)

pkg/pipeline/utils/exit.go
100.00% <0.00%> (+47.82%)
:arrow_up:

Continue to review full report at Codecov.

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

The default is now to include all previous key/values and to enrich them. To get only the newly specified keys, we now have policy: replace_keys as a parameter in the yaml.

addresses issue #151


[v2.2.2] fixed CVE-2018-16843, CVE-2018-16844

commit d84cb79d23f6ba8ad7e4cb08d2a6620858d40b6b (HEAD -> 2.2.2)
Author: Xiaochen Wang<EMAIL_ADDRESS>Date:   Sat Nov 10 12:03:42 2018 +0800

    fixed CVE-2018-16845

case result:

$ TEST_NGINX_UNSAFE=yes TEST_NGINX_BINARY=/home/xiaochen.wxc/work/github/tengine-fix/objs/nginx prove -I /home/xiaochen.wxc/work/github/tengine-fix/tests/nginx-tests/nginx-tests/lib tests/nginx-tests/nginx-tests/mp4.t
tests/nginx-tests/nginx-tests/mp4.t .. ok
All tests successful.
Files=1, Tests=14,  4 wallclock secs ( 0.04 usr  0.01 sys +  1.95 cusr  0.20 csys =  2.20 CPU)
Result: PASS

Report-generated-by: http://github.com/chobits/tengine-script/runtest.sh


How to get the correct virtual site3?

In the parameter file for caffeine,
[constraints]
#endif
; i  j  funct length
1  3   1     0.474 1000000 ; cog
1  6   1     0.405 1000000 ; cog
3  6   1     0.599 1000000 ; cog
3  7   1     0.555 1000000 ; cog
6  7   1     0.283 1000000 ; cog
[dihedrals]
; improper
; i j k l  funct  ref.angle force_k
1 3 6 7    2      180       200
[virtual_sites2]
; sites positioned at 1-a
; site  from  funct    a
5    3 6     1     0.635 ; cog
[virtual_sites3]
; peripheral virtual sites
; site positioned as a linear combination of 3 atoms
; the site is in the same plane
; site  from      funct    a      b
2    5 1 3       1     0.640 0.605 ; cog
4    5 3 7       1     0.650 0.600 ; cog
In the [virtual_site2], how do we get the factor 'a'? Is factor 'a' equal to 0.38 (i.e., the distance of bead 3 and bead 5) divided by 0.599 (i.e., the distance of bead 3 and bead 6)? And for the factors 'a' and 'b' in the [virtual_site3], I would very much like to know how to calculate them too.

Hi @Clare-xiong and thanks for the question. The factors for the virtual sites constructions are obtained in the same way as the bond length and other bonded parameters, i.e., by comparing the mapped distributions coming from all-atom simulations to the CG distributions, as described in tutorial to parametrize new small-molecules (around section 7)). Namely, in deriving the factors for building the virtual sites, you should consider them as actual particles and hence have bond lengths between the particles and the virtual sites and match such bond lengths (even though you won't have such bond lengths in the final model). Actually, a chapter we recently published describes in quite some detail exactly the making of the caffeine model - see in particular Fig 1.2a and Fig1.c and associated discussions.
In principles, given that the virtual sites are built as linear combinations of the particle positions, you can probably devise a cleverer way to obtain those factors. However, you'll still need to extract bond lengths between the real particles as described in the tutorial to parametrize new small-molecules.

I already read this chapter, but the factor for the virtual sites constructions are still confuse me.