Canno't install Dingo API / Laravel 5.5.19

Hi there :),
I'm facing a problem while requiring dingo/api:2.0.0-alpha1:

./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

Problem 1
- Conclusion: remove laravel/framework 5.5.x-dev
- Conclusion: don't install laravel/framework 5.5.x-dev
- dingo/blueprint 0.2.2 requires illuminate/filesystem 5.1.* || 5.2.* || 5.3.* || 5.4.* -> satisfiable by illuminate/filesystem[5.1.x-dev, 5.2.x-dev, 5.3.x-dev, 5.4.x-dev, v5.1.1, v5.1.13, v5.1.16, v5.1.2, v5.1.20, v5.1.22, v5.1.25, v5.1.28, v5.1.30, v5.1.31, v5.1.41, v5.1.6, v5.1.8, v5.2.0, v5.2.19, v5.2.21, v5.2.24, v5.2.25, v5.2.26, v5.2.27, v5.2.28, v5.2.31, v5.2.32, v5.2.37, v5.2.43, v5.2.45, v5.2.6, v5.2.7, v5.3.0, v5.3.16, v5.3.23, v5.3.4, v5.4.0, v5.4.13, v5.4.17, v5.4.19, v5.4.27, v5.4.36, v5.4.9].
- dingo/blueprint v0.2.0 requires illuminate/filesystem 5.1.* || 5.2.* || 5.3.* -> satisfiable by illuminate/filesystem[5.1.x-dev, 5.2.x-dev, 5.3.x-dev, v5.1.1, v5.1.13, v5.1.16, v5.1.2, v5.1.20, v5.1.22, v5.1.25, v5.1.28, v5.1.30, v5.1.31, v5.1.41, v5.1.6, v5.1.8, v5.2.0, v5.2.19, v5.2.21, v5.2.24, v5.2.25, v5.2.26, v5.2.27, v5.2.28, v5.2.31, v5.2.32, v5.2.37, v5.2.43, v5.2.45, v5.2.6, v5.2.7, v5.3.0, v5.3.16, v5.3.23, v5.3.4].
- dingo/blueprint v0.2.1 requires illuminate/filesystem 5.1.* || 5.2.* || 5.3.* -> satisfiable by illuminate/filesystem[5.1.x-dev, 5.2.x-dev, 5.3.x-dev, v5.1.1, v5.1.13, v5.1.16, v5.1.2, v5.1.20, v5.1.22, v5.1.25, v5.1.28, v5.1.30, v5.1.31, v5.1.41, v5.1.6, v5.1.8, v5.2.0, v5.2.19, v5.2.21, v5.2.24, v5.2.25, v5.2.26, v5.2.27, v5.2.28, v5.2.31, v5.2.32, v5.2.37, v5.2.43, v5.2.45, v5.2.6, v5.2.7, v5.3.0, v5.3.16, v5.3.23, v5.3.4].
- don't install illuminate/filesystem 5.1.x-dev|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem 5.2.x-dev|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem 5.3.x-dev|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem 5.4.x-dev|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.1.1|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.1.13|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.1.16|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.1.2|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.1.20|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.1.22|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.1.25|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.1.28|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.1.30|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.1.31|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.1.41|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.1.6|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.1.8|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.2.0|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.2.19|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.2.21|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.2.24|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.2.25|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.2.26|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.2.27|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.2.28|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.2.31|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.2.32|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.2.37|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.2.43|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.2.45|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.2.6|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.2.7|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.3.0|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.3.16|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.3.23|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.3.4|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.4.0|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.4.13|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.4.17|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.4.19|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.4.27|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.4.36|don't install laravel/framework 5.5.x-dev
- don't install illuminate/filesystem v5.4.9|don't install laravel/framework 5.5.x-dev
- Installation request for laravel/framework (locked at 5.5.x-dev, required as 5.5.*) -> satisfiable by laravel/framework[5.5.x-dev].
- Installation request for dingo/api 2.0.0-alpha1 -> satisfiable by dingo/api[v2.0.0-alpha1].
- Conclusion: don't install phpdocumentor/reflection-docblock 4.1.1|install dingo/blueprint 0.2.2|install dingo/blueprint v0.2.0|install dingo/blueprint v0.2.1
- Conclusion: remove phpdocumentor/reflection-docblock 4.1.1|install dingo/blueprint 0.2.2|install dingo/blueprint v0.2.0|install dingo/blueprint v0.2.1
- dingo/api v2.0.0-alpha1 requires dingo/blueprint ^0.2 -> satisfiable by dingo/blueprint[0.2.2, 0.2.x-dev, v0.2.0, v0.2.1, v0.2.3].
- dingo/blueprint 0.2.x-dev requires phpdocumentor/reflection-docblock ^3.1 -> satisfiable by phpdocumentor/reflection-docblock[3.1.0, 3.1.1, 3.2.0, 3.2.1, 3.2.2, 3.2.3, 3.3.0].
- dingo/blueprint v0.2.3 requires phpdocumentor/reflection-docblock ^3.1 -> satisfiable by phpdocumentor/reflection-docblock[3.1.0, 3.1.1, 3.2.0, 3.2.1, 3.2.2, 3.2.3, 3.3.0].
- Can only install one of: phpdocumentor/reflection-docblock[3.1.0, 4.1.1].
- Can only install one of: phpdocumentor/reflection-docblock[3.1.1, 4.1.1].
- Can only install one of: phpdocumentor/reflection-docblock[3.2.0, 4.1.1].
- Can only install one of: phpdocumentor/reflection-docblock[3.2.1, 4.1.1].
- Can only install one of: phpdocumentor/reflection-docblock[3.2.2, 4.1.1].
- Can only install one of: phpdocumentor/reflection-docblock[3.2.3, 4.1.1].
- Can only install one of: phpdocumentor/reflection-docblock[3.3.0, 4.1.1].
- Installation request for phpdocumentor/reflection-docblock (locked at 4.1.1) -> satisfiable by phpdocumentor/reflection-docblock[4.1.1].

Installation failed, reverting ./composer.json to its original content.

I just did a installation of laravel installer, created a projet and then required Dingo API.
Any help would be appreciated.
Best regards,
Guillaume R.

I'm sure i'll find a way to make it work these links.
https://github.com/dingo/api/issues/1076
https://github.com/dingo/api/issues/1060
I'll keep you in touch

Ok, I managed to install it by adding "minimum-stability": "dev" && "phpdocumentor/reflection-docblock": "3.x@dev" to my composer.json.

Ok, I managed to install it by adding "minimum-stability": "dev" && "phpdocumentor/reflection-docblock": "3.x@dev" to my composer.json.


a question on running MLCG-codes

Hello, I want to run your code to reproduce the results for your paper"Meta Learning to Compositionally Generalize" and unfortunately I met up with a problem.
Here is how's that going: following your instruction in ReadMe file, I successfully updated and installed all packets metioned in setup script file.  But when I tried to follow the Preprocessing step for COGS training and enter "tensor2struct preprocess configs/cogs/run_config/run_cogs_comp.jsonnet" on the command line, there is an error ocurring("KeyError: 'cogs_enc'"), and the entire error info is :
Using default log base dir /data2/home/zhaoyi/SrcCode for MLCG
WARNING <class 'tensor2struct.models.enc_dec.EncDecPreproc'>: superfluous {'name': 'EncDec'}
Traceback (most recent call last):
File "/data2/home/zhaoyi/anaconda3/envs/tensor2struct/bin/tensor2struct", line 33, in
sys.exit(load_entry_point('tensor2struct', 'console_scripts', 'tensor2struct')())
File "/data2/home/zhaoyi/SrcCode for MLCG/tensor2struct/commands/run.py", line 241, in main
preprocess.main(preprocess_config)
File "/data2/home/zhaoyi/SrcCode for MLCG/tensor2struct/commands/preprocess.py", line 47, in main
preprocessor = Preprocessor(config)
File "/data2/home/zhaoyi/SrcCode for MLCG/tensor2struct/commands/preprocess.py", line 15, in init
registry.lookup("model", config["model"]).Preproc, config["model"]
File "/data2/home/zhaoyi/SrcCode for MLCG/tensor2struct/utils/registry.py", line 61, in instantiate
return callable(**merged)
File "/data2/home/zhaoyi/SrcCode for MLCG/tensor2struct/models/enc_dec.py", line 36, in init
self.enc_preproc = registry.lookup("encoder", encoder["name"]).Preproc(
File "/data2/home/zhaoyi/SrcCode for MLCG/tensor2struct/utils/registry.py", line 28, in lookup
return _REGISTRY[kind][name]
KeyError: 'cogs_enc'
I want to know how to solve it and thanks a lot for your reply!

It should be fixed now!  Should come from the same issue as #10

Thanks for reporting this! Let me if it's fixed


Right Click>> Help: Missing Page - Control

Add Create Big Image
Right Click on the control
Click Help
Result: Page not found

I no longer get a 404 for this page this issue can be closed.


Mapping a name with colons (:) to external index breaks indexQuery

As stated by the lucene syntax query, property names must be escaped on the following characters: + - && || ! ( ) { } [ ] ^ " ~ * ? : \ /.
However, property names are not properly escaped when using indexQuery on a mixed index with a mapped-name containing (for example) a colon.
An example script to reproduce the issue is available on the ML.

Have you tried putting the name in quotation marks so that Titan keeps it together?

From the ML:

g.indexQuery('es-name4', 'v.\"name\\:4\":saturn').vertices().collect{[it.score, it.element]}
Found reference to non-existant property key in query at position [0]: name:4

Ah, yeah, that won't work.
On Wed, Jan 14, 2015 at 8:27 PM, Daniel Kuppitz<EMAIL_ADDRESS>wrote:

From the ML:
g.indexQuery('es-name4',
'v."name\:4":saturn').vertices().collect{[it.score, it.element]}
Found reference to non-existant property key in query at position [0]:
name:4
—
Reply to this email directly or view it on GitHub
https://github.com/thinkaurelius/titan/issues/927#issuecomment-70038417.

--
Matthias Broecheler
http://www.matthiasb.com


The TypeScript language service died unexpectedly 5 times in the last 5 Minutes. Please consider to open a bug report.

VSCode Version:
OS Version:

Steps to Reproduce:

When opening up VS code I get an error continuously appearing an disappearing in a dropdown. It appears for a second, disappears, then appears again. Like a blink tag. Very annoying.

[Window Title]
The TypeScript language service died unexpectedly 5 times in the last 5 Minutes. Please consider to open a bug report.
[Main Instruction]
Happens with the last update. This appears to be a random issue
[Content]
Version 1.6.1
Commit 9e4e44c19e393803e2b05fe2323cf4ed7e36880e
Date 2016-10-13T16:21:53.542Z
Shell 1.3.7
Renderer 52.0.2743.82
Node 6.5.0

[OK]

@tonywaterman thank you for opening this issue. Can you look at this issue and comment there? We are seeing many of the same issues that you have observed. Any insights into tracking this down would be much appreciated.


Login with the same device as the one I am really using

Hello,
Though it's really good to have the device generated by the library, it would be really nice to be able to set it manually easily - is there a way to do that? I guess it's only one line of code, but when to do it, and how exactly? I want to make sure as it's really too easy to get an IgActionSpamError recently.
Linked to that, I would like to find out what is the device string (?) used by the physical device I use every day. Is there a way to do this?
Basically, what I would like to do is to pretend I am using the same device, as much as possible. Right now, with the auto-generated device, I am getting an IgActionSpamError (which I am not sure why) but it works totally fine on my mobile.
Thanks a lot for your help and ideas :)

Hello @jordymeow!
Just look into a library code.
https://github.com/dilame/instagram-private-api/blob/b93ea285c9e0074f3ff481f3040a89d09a116b6f/src/core/state.ts#L175
Using generateDevice(seed: string) you should specify seed.
Device will be based on your seed. For example execution with seed 'test' will return the same device every time.
You can specify state.deviceString by yourself, just save it and use later.

Also related:
https://github.com/dilame/instagram-private-api/blob/b93ea285c9e0074f3ff481f3040a89d09a116b6f/examples/session.example.ts

Hi @realinstadude. Thanks for your reply :) Of course, I had a look at the code before asking you but I couldn't find a simple way to do this. My goal is to match my real physical device, so keeping the same seed will not help (it will still be random) and modifying the different values will also not work as the appUserAgent getter and webUserAgent are already set to Android.
In my case, hacking the library by replacing the appUserAgent getter by my own works. All my issues go away. However, I would need to modify your library every time I update it.
Wouldn't it be possible to add a function to replace it? The appUserAgent could be created once, when the library is initialized (or after the device is generated), then it could be overridden through a setter. That will allow anybody to modify it easily. I would really love that change :)
PS: Though I think it's great to improve other parts of that library (actually, I love it the way it is right now), I think it would be good to focus on this part at some point. My worry is that Instagram will seriously start to study the requests built by this particular library in order to reject them. So it could be an idea to propose more devices (in the JSON file already present), but some additional functions (+ documentation) to allow each user to have a really unique but somewhat real device would help greatly.

In my case, hacking the library by replacing the appUserAgent getter by my own works. All my issues go away. However, I would need to modify your library every time I update it.

@jordymeow did you managed to get your device ID from your android app or you replaced the user agent with something totally different?

@AfflatusX I have generated something that I guess would be similar to the one used by my device (iPhone actually), but I am not sure. Would still love to find a way to really get it, but I guess the only way would be to analyze the packets sent through the network. There might be an easier way, but I guess it would be also awesome to have a better generator build in the library, allowing us to match our device more easily.

@jordymeow interesting - my understanding is that simply swapping out the user agent from Android to iPhone would not work since the API is only working with Android (I tried to play with the user agent but can't even log-in). You mentioned changing that solved your problems (feedback_required I assume) - would you mind sharing how do you change the user agent to achieve that?

@AfflatusX Actually, I did it by hacking the library directly, and at every update, I need to do the same thing (so I hope they will add a method to do it directly someday). That said, I never had the feedback_required issue, only the IgActionSpamError (even though I am not spamming at all, but I believe the reason is different).


Publish new version

@Exelord would you mind publishing a new version?

Only when tests will be green :/


Occationally panic on jiffy mpsc node

I wrote a demo with the jiffy mpsc module on Win10. Mostly it wen well but I came across once with panic info:
thread '' panicked at 'called Option::unwrap() on a None value', C:\Users\testuser.cargo\registry\src\mirrors.ustc.edu.cn-15f9db60536bad60\nolock-0.4.0\src\queues\mpsc\jiffy\node.rs:93:25
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
I read the function comments and found that the unwrap() function is meant to be safe.  Would there be any bug in it?
My test code is below:
use std::thread;
use std::time::{Duration, Instant};
use core_affinity::{CoreId, get_core_ids};
use polars::prelude::{DataFrame, NamedFromOwned, Series};

fn main() {
    loop {
        let (mut receiver, mut sender) = nolock::queues::mpsc::jiffy::queue::<Instant>();
        let times = 10000;
        let times_clone = times.clone();

        let receiver = thread::spawn(move || {
            core_affinity::set_for_current(CoreId { id: 3 });
            let mut num = 0;
            let mut sum_latency = 0.0;
            let mut latencies = vec![];
            for idx in 0..times_clone {
                if let Some(info) = receiver.dequeue() {
                    let a = info.elapsed().as_secs_f64();
                    latencies.push(a);
                }
            }
            let series = Series::from_vec("", latencies);
            let df = DataFrame::new(vec![series]).unwrap();
            println!("{:?}", df.describe(None));
        });

        thread::spawn(move || {
            core_affinity::set_for_current(CoreId { id: 4 });
            for idx in 0..times {
                thread::sleep(Duration::from_millis(1));
                let start = Instant::now();
                sender.enqueue(start);
            }
        });
        receiver.join();
    }
}

Thanks for the bug report. I will investigate this issue later today and will see what I can find

FYI, I ran this code for 3 hours and the panic problem occured 6 times. So you may try run this for longer time.

Furthermore, when I ran the test code today after eliminating the core_affinity::set_for_current functions, the panic still occured.

I tested the program without core_affinity::set_for_current functions, the panic problem still occursed.
CentOS Linux release 7.8.2003 (Core)   rustc 1.60.0 (7737e0b5c 2022-04-04)

Hey, I just pushed a minor attempted fix for the Issue. If you want you can test it now as a git dependency and I will also try to find a good way to test this issue to verify that it was actually fixed or not

yeah, the invariants oultined in the code, weren't exactly held up before.


[Package Request]:

Package Requested

[X] I would like someone else to build the manifest.
[ ] I would like help so I can submit the manifest.
[X] I have performed a search and couldn't find this package.
[ ] I have checked that the installer for this package is not a standalone or portable executable or a .zip file
[ ] I think there is a new version available and I have provided the URL.

Please provide the following information
Publisher: MSI
Publisher Url: https://www.msi.com/Landing/afterburner/graphics-cards
Package Name: Afterburner
Description: MSI Afterburner is the most used graphics card software for a good reason.
Package Version: <IP_ADDRESS>55
Installer URL: https://download.msi.com/uti_exe/vga/MSIAfterburnerSetup.zip
Current Package Identifier (for new versions):
it is the most popular gpu overclocking softward in the world. although it is a .zip file, it will be a .exe after extracted.

Duplicate of https://github.com/microsoft/winget-pkgs/issues/1990


KeyError: 'pandasgui/widgets/../images/case-match.png'

QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-steph'
Traceback (most recent call last):
File "test_pandas_gui.py", line 6, in
show(example_df)
File "/home/steph/anaconda3/envs/bert/lib/python3.7/site-packages/pandasgui-<IP_ADDRESS>-py3.7.egg/pandasgui/gui.py", line 365, in show
File "/home/steph/anaconda3/envs/bert/lib/python3.7/site-packages/pandasgui-<IP_ADDRESS>-py3.7.egg/pandasgui/gui.py", line 76, in init
File "/home/steph/anaconda3/envs/bert/lib/python3.7/site-packages/pandasgui-<IP_ADDRESS>-py3.7.egg/pandasgui/gui.py", line 129, in setupUI
File "/home/steph/anaconda3/envs/bert/lib/python3.7/site-packages/pandasgui-<IP_ADDRESS>-py3.7.egg/pandasgui/widgets/find_toolbar.py", line 49, in init
File "/home/steph/anaconda3/envs/bert/lib/python3.7/site-packages/pkg_resources/init.py", line 1145, in resource_filename
self, resource_name
File "/home/steph/anaconda3/envs/bert/lib/python3.7/site-packages/pkg_resources/init.py", line 1744, in get_resource_filename
return self._extract_resource(manager, zip_path)
File "/home/steph/anaconda3/envs/bert/lib/python3.7/site-packages/pkg_resources/init.py", line 1765, in _extract_resource
timestamp, size = self._get_date_and_size(self.zipinfo[zip_path])
KeyError: 'pandasgui/widgets/../images/case-match.png'

I was unable to reproduce this, I think it was fixed a while ago. Let me know if not.


Tests working for HttpEndpoint

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

#109  👈
#108
#107
#106
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @acco and the rest of your teammates on  Graphite


Update w2b CLI interface in Program.cs

Description of issue

Update w2b CLI interface in Program.cs

Not needed


Additional icons pt. I

Various icons that have been made in the past few months. For current and future use. Please add these to Cardigan.

Attached is both the AI file, as well as SVG code for each icon.
AI file
Wellcome_Icons_Additions_02.ai.zip
SVG code:
Icon_SVG_Code.txt

@davidpmccormick Here are the 3 icons with text (outlined)
3-icons.zip


GEODE-9581: Fix possible sending of duplicate events

When group-transaction-events is set for a serial
gateway sender there is a small chance that duplicated
events are sent by the sender.
The reason behind is a bug in the serial gateway sender.
When the remove() method of the SerialGatewaySenderQueue
was invoked for an event that was peeked to complete
a transaction, it was also removed from the extraPeekedIds
structure.
This provoked that events already peeked, were peeked
again by SerialGatewaySenderQueue.peekAhead() when
they should not have been.
A change has been made in the remove() method so
that events that were peeked to complete a transaction
are only removed from the extraPeekedIds when a call
to remove() has been made previously for that event
(the events is in extraPeekedIdsRemovedButPreviousIdNotRemoved)
and the previous event is the lastDispatchedKey.

For all changes:

[ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message?

[ ] Has your PR been rebased against the latest commit within the target branch (typically develop)?

[ ] Is your initial contribution a single, squashed commit?

[ ] Does gradlew build run cleanly?

[ ] Have you written or updated unit tests to verify your changes?

[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

I expect to see some test cases

I expect to see some test cases

I did not write a new test case given that with the fault, there was a test case already failing, although it was not always.
I have added a unit test for this specific case.


Deploy to test pypi on PRs

Added

Deploy to Test Python Package Index on every PR build with a PEP440 compliant -rc<BUILDNUMBER>.dev<PR_NUMBER> meta data extension, see #5
Test release workflow running only on PRs is archiving and uploading built artifacts to Test Python Package Index

Changed

Built artifacts are no longer archived by the always running test workflow

Codecov Report

Merging #6 (7464cc3) into main (0872e6b) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main        #6   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            3         3
  Lines           14        14
  Branches         1         1
=========================================
  Hits            14        14

Flag
Coverage Δ

unittests
100.00% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

see 0.2.0rc1.dev6 without updated README, and after pushing 50316aa the next version 0.2.0rc2.dev6


Crash my server

crash-2019-03-31_18.53.31-server.txt

Enderzoo is no longer being updated. Please test with enderio zoo

The fallen knight es being attacked by an entity that doesn't have a location in the game. Not having one is invalid, report that to the mod that adds that entity, whatever it is.


Font size is set with DP instead of SP

I just noticed this when looking at the source code for the createTextView method
setTextSize(TypedValue.COMPLEX_UNIT_DIP, mergedStyle.fontSize.value)

This should be changed to the following, to ensure text size scaling settings on the device are honored.
setTextSize(TypedValue.COMPLEX_UNIT_SP, mergedStyle.fontSize.value)

why not create a Pull request?


Style Settings does not include Highlight Colors

Highlight Colors is listed as a customizable option in Style Settings on the Wiki here. It doesn't show up in any of the options/sections/submenus within the Style Settings options. It looks like everything else shown on the wiki page is in Style Settings.

Next update should include highlight colour options again, with some presets.


bpf: test: fix pktgen for IPv6 NEXTHDR_DEST option

When building packets with multiple IPv6 options, a missing break for the NEXTHDR_DEST option would cause us to set up the preceding option's nexthdr field incorrectly.

This only touches the BPF unit tests, no need for full e2e coverage.


about stocaching

sorry, i can not install this moudels.
pip install stocaching

You can remove the parts about stocaching. It is just to fasten training. The library should be still online on pypi. You can also use the renewed TorchGeo implementation of the dataset


Update testcontainers-scala-postgresql to 0.39.10

Updates com.dimafeng:testcontainers-scala-postgresql from 0.39.5 to 0.39.10.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.dimafeng", artifactId = "testcontainers-scala-postgresql" } ]

labels: library-update, early-semver-minor, semver-spec-patch

Superseded by #349.


Start enabled shardscanner fixers

What changed?
Start enabled fixers automatically; Fix activity for getting corrupted keys.

Why?
This is fix for a functional regression.

How did you test it?
Unit tests

Potential risks

Coverage increased (+0.05%) to 61.468% when pulling 1aa3a8e319582237272e83703b0065cf9bf48acb on mantas-sidlauskas:fixer_autostart into 6f67616f6c8c3c8d08f2c480551a16f9c96f4d9f on uber:master.

Coverage increased (+0.05%) to 61.468% when pulling 1aa3a8e319582237272e83703b0065cf9bf48acb on mantas-sidlauskas:fixer_autostart into 6f67616f6c8c3c8d08f2c480551a16f9c96f4d9f on uber:master.


Dismiss cookie banner when interacting with blocks

Open any shared script in an incognito window and interact with the shared blocks.
You can:

select them
drag them around
edit fields

and the cookie banner won't be dismissed..

This is by design. Only drag of new block dismisses cookie. Done intentionally to avoid more ways to dismiss cookie.
Shouldn't be a big issue as users see cookie once (in home screen) and new project clears it.


refactor(containerd_chaos): Converting containerd_chaos job to pod

Signed-off-by: shubhamchaudhary<EMAIL_ADDRESS>
What this PR does / why we need it:

Converting containerd_chaos job to pod

Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Checklist

[ ] Does this PR have a corresponding GitHub issue?
[ ] Have you included relevant README for the chaoslib/experiment with details?
[ ] Have you added debug messages where necessary?
[ ] Have you added task comments where necessary?
[ ] Have you tested the changes for possible failure conditions?
[ ] Have you provided the positive & negative test logs for the litmusbook execution?
[ ] Does the litmusbook ensure idempotency of cluster state?, i.e., is cluster restored to original state?
[ ] Have you used non-shell/command modules for Kubernetes tasks?
[ ] Have you (jinja) templatized custom scripts that is run by the litmusbook, if any?
[ ] Have you (jinja) templatized Kubernetes deployment manifests used by the litmusbook, if any?
[ ] Have you reused/created util functions instead of repeating tasks in the litmusbook?
[ ] Do the artifacts follow the appropriate directory structure?
[ ] Have you isolated storage (eg: OpenEBS) specific implementations, checks?
[ ] Have you isolated platform (eg: baremetal kubeadm/openshift/aws/gcloud) specific implementations, checks?
[ ] Are the ansible facts well defined? Is the scope explicitly set for playbook & included utils?
[ ] Have you ensured minimum/careful usage of shell utilities (awk, grep, sed, cut, xargs etc.,)?
[ ] Can the limtusbook be executed both from within & outside a container (configurable paths, no hardcode)?
[ ] Can you suggest the minimal resource requirements for the litmusbook execution?
[ ] Does the litmusbook job artifact carry comments/default options/range for the ENV tunables?
[ ] Has the litmusbooks been linted?

Special notes for your reviewer:

2020-03-30 19:36:50.558134 ************ BRACE YOURSELF, EXPERIMENT BEGINS! ************

2020-03-30 19:36:55.789287 Step: Gathering Facts
task path: /experiments/generic/container_kill/container_kill_ansible_logic.yml:2
META: ran handlers

2020-03-30 19:36:56.286098 Step: Identify the chaos util to be invoked
task path: /experiments/generic/container_kill/container_kill_ansible_prerequisites.yml:1
details => {"changed": true, "checksum": "94d7210bad1d6704aa50cf0ce550c1a1d8dcf07c", "dest": "./chaosutil.yml", "gid": 0, "group": "root", "md5sum": "4e03f8649fb0821e96b64983f4d5ec8f", "mode": "0644", "owner": "root", "size": 74, "src": "/root/.ansible/tmp/ansible-tmp-1585597015.84-102827246573207/source", "state": "file", "uid": 0}

2020-03-30 19:36:56.338752 Step: include_vars
task path: /experiments/generic/container_kill/container_kill_ansible_logic.yml:25
details => {"ansible_facts": {"c_util": "/chaoslib/litmus/container_kill/containerd_chaos/crictl-chaos.yml"}, "ansible_included_var_files": ["/experiments/generic/container_kill/chaosutil.yml"], "changed": false}

2020-03-30 19:36:56.401561 Step: Construct chaos result name
task path: /experiments/generic/container_kill/container_kill_ansible_logic.yml:29
details => {"ansible_facts": {"c_result": "engine-container-kill"}, "changed": false}
included: /utils/runtime/update_chaos_result_resource.yml for <IP_ADDRESS>

2020-03-30 19:36:56.772783 Step: [PreReq]: Generate the chaos result CR to reflect SOT (Start of Test)
task path: /utils/runtime/update_chaos_result_resource.yml:3
details => {"changed": true, "checksum": "f7c3177383a9885db6a95e01d61a8ed75bab1870", "dest": "/utils/runtime/chaos-result.yml", "gid": 0, "group": "root", "md5sum": "2aa63df0e25461545eb1900df3cec576", "mode": "0644", "owner": "root", "size": 312, "src": "/root/.ansible/tmp/ansible-tmp-1585597016.53-166080357767198/source", "state": "file", "uid": 0}

2020-03-30 19:36:58.511567 Step: [PreReq]: Apply the chaos result CR for container-kill experiment
task path: /utils/runtime/update_chaos_result_resource.yml:13
details => {"changed": true, "cmd": "kubectl apply -f /utils/runtime/chaos-result.yml -n shubham", "delta": "0:00:01.445290", "end": "2020-03-30 19:36:58.488151", "failed_when_result": false, "rc": 0, "start": "2020-03-30 19:36:57.042861", "stderr": "", "stderr_lines": [], "stdout": "chaosresult.litmuschaos.io/engine-container-kill configured", "stdout_lines": ["chaosresult.litmuschaos.io/engine-container-kill configured"]}
included: /utils/common/status_app_pod.yml for <IP_ADDRESS>

2020-03-30 19:36:59.611873 Step: [Status]: Checking whether application pods are in running state
task path: /utils/common/status_app_pod.yml:2
details => {"attempts": 1, "changed": true, "cmd": "kubectl get pods -n default -l run=nginx -o custom-columns=:.status.phase --no-headers", "delta": "0:00:00.798283", "end": "2020-03-30 19:36:59.586017", "rc": 0, "start": "2020-03-30 19:36:58.787734", "stderr": "", "stderr_lines": [], "stdout": "Running", "stdout_lines": ["Running"]}

2020-03-30 19:37:00.505220 Step: [Status]: Checking whether application containers are in running state
task path: /utils/common/status_app_pod.yml:9
details => {"attempts": 1, "changed": true, "cmd": "kubectl get pod -n default -l run=nginx --no-headers -o jsonpath='{.items[*].status.containerStatuses[*].ready}' | tr ' ' '\\n' | uniq", "delta": "0:00:00.710737", "end": "2020-03-30 19:37:00.481184", "rc": 0, "start": "2020-03-30 19:36:59.770447", "stderr": "", "stderr_lines": [], "stdout": "true", "stdout_lines": ["true"]}
included: /utils/common/generate-kubernetes-chaos-events.yml for <IP_ADDRESS>

2020-03-30 19:37:01.309058 Step: [Event]: Obtain the current date in ISO8601 format
task path: /utils/common/generate-kubernetes-chaos-events.yml:1
details => {"changed": true, "cmd": "date --iso-8601=seconds", "delta": "0:00:00.572476", "end": "2020-03-30 19:37:01.290349", "rc": 0, "start": "2020-03-30 19:37:00.717873", "stderr": "", "stderr_lines": [], "stdout": "2020-03-30T19:37:01+00:00", "stdout_lines": ["2020-03-30T19:37:01+00:00"]}

2020-03-30 19:37:01.365914 Step: set_fact
task path: /utils/common/generate-kubernetes-chaos-events.yml:5
details => {"ansible_facts": {"ts": "2020-03-30T19:37:01Z"}, "changed": false}

2020-03-30 19:37:02.205016 Step: [Event]: Creating a PreChaosCheck event in the chaosengine
task path: /utils/common/generate-kubernetes-chaos-events.yml:8
details => {"changed": true, "method": "patch", "result": {"apiVersion": "v1", "count": 1, "eventTime": null, "firstTimestamp": "2020-03-30T19:37:01Z", "involvedObject": {"apiVersion": "litmuschaos.io/v1alpha1", "kind": "ChaosEngine", "name": "engine", "namespace": "shubham", "uid": "3f5877f8-cf52-4b4c-a07a-9b34b8eb158b"}, "kind": "Event", "lastTimestamp": "2020-03-30T19:37:01Z", "message": "AUT is Running successfully", "metadata": {"creationTimestamp": "2020-03-30T19:24:00Z", "name": "event-\"PreChaosCheck\"", "namespace": "shubham", "resourceVersion": "374", "selfLink": "/api/v1/namespaces/shubham/events/event-%22PreChaosCheck%22", "uid": "dda455ef-e778-4a6b-8a58-1ba1cda5ce6f"}, "reason": "PreChaosCheck", "reportingComponent": "", "reportingInstance": "", "source": {"component": "container-kill-yfx46v-jtqj9"}, "type": "Normal"}}
included: /chaoslib/litmus/container_kill/containerd_chaos/crictl-chaos.yml for <IP_ADDRESS>

2020-03-30 19:37:03.180923 Step: Select the app pod
task path: /chaoslib/litmus/container_kill/containerd_chaos/crictl-chaos.yml:4
details => {"changed": true, "cmd": "kubectl get pod -l run=nginx -n default -o=custom-columns=:metadata.name --no-headers | shuf | head -1", "delta": "0:00:00.691721", "end": "2020-03-30 19:37:03.161161", "rc": 0, "start": "2020-03-30 19:37:02.469440", "stderr": "", "stderr_lines": [], "stdout": "nginx-7989b5f7f4-md8nr", "stdout_lines": ["nginx-7989b5f7f4-md8nr"]}

2020-03-30 19:37:03.241337 Step: Record app pod name
task path: /chaoslib/litmus/container_kill/containerd_chaos/crictl-chaos.yml:13
details => {"ansible_facts": {"app_pod": "nginx-7989b5f7f4-md8nr"}, "changed": false}

2020-03-30 19:37:04.095235 Step: Identify the application node
task path: /chaoslib/litmus/container_kill/containerd_chaos/crictl-chaos.yml:18
details => {"changed": true, "cmd": "kubectl get pod nginx-7989b5f7f4-md8nr -n default --no-headers -o custom-columns=:spec.nodeName", "delta": "0:00:00.679085", "end": "2020-03-30 19:37:04.071703", "rc": 0, "start": "2020-03-30 19:37:03.392618", "stderr": "", "stderr_lines": [], "stdout": "gke-shubham-containerd-default-pool-67a4bcdd-wk6w", "stdout_lines": ["gke-shubham-containerd-default-pool-67a4bcdd-wk6w"]}

2020-03-30 19:37:04.152558 Step: set_fact
task path: /chaoslib/litmus/container_kill/containerd_chaos/crictl-chaos.yml:26
details => {"ansible_facts": {"app_node": "gke-shubham-containerd-default-pool-67a4bcdd-wk6w"}, "changed": false}

2020-03-30 19:37:04.925071 Step: Generate a run id if not passed from the engine/experiment
task path: /chaoslib/litmus/container_kill/containerd_chaos/crictl-chaos.yml:30
details => {"changed": true, "cmd": "echo $(mktemp) | cut -d '.' -f 2 | cut -c -6", "delta": "0:00:00.585904", "end": "2020-03-30 19:37:04.906077", "rc": 0, "start": "2020-03-30 19:37:04.320173", "stderr": "", "stderr_lines": [], "stdout": "8eAJXG", "stdout_lines": ["8eAJXG"]}

2020-03-30 19:37:04.986443 Step: set_fact
task path: /chaoslib/litmus/container_kill/containerd_chaos/crictl-chaos.yml:34
details => {"ansible_facts": {"run_id": "8eajxg"}, "changed": false}

2020-03-30 19:37:05.421526 Step: Patch the chaoslib image
task path: /chaoslib/litmus/container_kill/containerd_chaos/crictl-chaos.yml:42
details => {"changed": true, "checksum": "8f233929bdc930d686b30c3c6f2b755017fbc643", "dest": "/chaoslib/litmus/container_kill/containerd_chaos/containerd-chaos-pod.yml", "gid": 0, "group": "root", "md5sum": "e9981fe1b8ba6d94b7d6cce6045ce88e", "mode": "0644", "owner": "root", "size": 746, "src": "/root/.ansible/tmp/ansible-tmp-1585597025.19-45698576248820/source", "state": "file", "uid": 0}
included: /utils/common/create_chaos_pod.yml for <IP_ADDRESS> => (item=1)
included: /utils/common/create_chaos_pod.yml for <IP_ADDRESS> => (item=2)
included: /utils/common/create_chaos_pod.yml for <IP_ADDRESS> => (item=3)

2020-03-30 19:37:06.632882 Step: Creating the chaos pod in default namespace
task path: /utils/common/create_chaos_pod.yml:3
details => {"changed": true, "cmd": "kubectl apply -f /chaoslib/litmus/container_kill/containerd_chaos/containerd-chaos-pod.yml -n default", "delta": "0:00:00.915248", "end": "2020-03-30 19:37:06.605431", "rc": 0, "start": "2020-03-30 19:37:05.690183", "stderr": "", "stderr_lines": [], "stdout": "pod/containerd-chaos-8eajxg created", "stdout_lines": ["pod/containerd-chaos-8eajxg created"]}
FAILED - RETRYING: Check for running status of the chaos pod (90 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (89 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (88 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (87 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (86 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (85 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (84 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (83 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (82 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (81 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (80 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (79 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (78 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (77 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (76 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (75 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (74 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (73 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (72 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (71 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (70 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (69 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (68 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (67 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (66 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (65 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (64 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (63 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (62 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (61 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (60 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (59 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (58 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (57 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (56 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (55 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (54 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (53 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (52 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (51 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (50 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (49 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (48 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (47 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (46 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (45 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (44 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (43 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (42 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (41 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (40 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (39 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (38 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (37 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (36 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (35 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (34 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (33 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (32 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (31 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (30 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (29 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (28 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (27 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (26 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (25 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (24 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (23 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (22 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (21 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (20 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (19 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (18 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (17 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (16 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (15 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (14 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (13 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (12 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (11 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (10 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (9 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (8 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (7 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (6 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (5 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (4 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (3 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (2 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (1 retries left).

2020-03-30 19:41:23.422243 Step: Check for running status of the chaos pod
task path: /utils/common/create_chaos_pod.yml:10
fatal: [<IP_ADDRESS>]: FAILED! => {"attempts": 90, "changed": true, "cmd": "kubectl get pods -l name=containerd-chaos-8eajxg -n default -o custom-columns=:.status.phase --no-headers", "delta": "0:00:00.678763", "end": "2020-03-30 19:41:23.398894", "rc": 0, "start": "2020-03-30 19:41:22.720131", "stderr": "", "stderr_lines": [], "stdout": "Failed", "stdout_lines": ["Failed"]}
...ignoring

2020-03-30 19:41:24.338543 Step: Delete the chaos pod, if it isn't scheduled successfully
task path: /utils/common/create_chaos_pod.yml:21
details => {"changed": true, "cmd": "kubectl delete -f /chaoslib/litmus/container_kill/containerd_chaos/containerd-chaos-pod.yml -n default", "delta": "0:00:00.719665", "end": "2020-03-30 19:41:24.316587", "rc": 0, "start": "2020-03-30 19:41:23.596922", "stderr": "", "stderr_lines": [], "stdout": "pod \"containerd-chaos-8eajxg\" deleted", "stdout_lines": ["pod \"containerd-chaos-8eajxg\" deleted"]}

2020-03-30 19:41:25.209889 Step: Confirm the deletion of chaos pod
task path: /utils/common/create_chaos_pod.yml:27
details => {"attempts": 1, "changed": true, "cmd": "kubectl get pods -l name=containerd-chaos-8eajxg -n default --no-headers", "delta": "0:00:00.679735", "end": "2020-03-30 19:41:25.182922", "rc": 0, "start": "2020-03-30 19:41:24.503187", "stderr": "No resources found.", "stderr_lines": ["No resources found."], "stdout": "", "stdout_lines": []}

2020-03-30 19:41:26.340993 Step: Creating the chaos pod in default namespace
task path: /utils/common/create_chaos_pod.yml:3
details => {"changed": true, "cmd": "kubectl apply -f /chaoslib/litmus/container_kill/containerd_chaos/containerd-chaos-pod.yml -n default", "delta": "0:00:00.892576", "end": "2020-03-30 19:41:26.309799", "rc": 0, "start": "2020-03-30 19:41:25.417223", "stderr": "", "stderr_lines": [], "stdout": "pod/containerd-chaos-8eajxg created", "stdout_lines": ["pod/containerd-chaos-8eajxg created"]}
FAILED - RETRYING: Check for running status of the chaos pod (90 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (89 retries left).
FAILED - RETRYING: Check for running status of the chaos pod (88 retries left).

2020-03-30 19:41:37.036697 Step: Check for running status of the chaos pod
task path: /utils/common/create_chaos_pod.yml:10
details => {"attempts": 4, "changed": true, "cmd": "kubectl get pods -l name=containerd-chaos-8eajxg -n default -o custom-columns=:.status.phase --no-headers", "delta": "0:00:00.684261", "end": "2020-03-30 19:41:37.012320", "rc": 0, "start": "2020-03-30 19:41:36.328059", "stderr": "", "stderr_lines": [], "stdout": "Running", "stdout_lines": ["Running"]}

2020-03-30 19:41:37.178626 Step: Set pod_running_status to Running
task path: /utils/common/create_chaos_pod.yml:41
details => {"ansible_facts": {"pod_running_status": "Running"}, "changed": false}

2020-03-30 19:41:38.309136 Step: Record the containerd-chaos pod on app node
task path: /chaoslib/litmus/container_kill/containerd_chaos/crictl-chaos.yml:63
details => {"changed": true, "cmd": "kubectl get pod -l name=containerd-chaos-8eajxg -o wide -n default | grep gke-shubham-containerd-default-pool-67a4bcdd-wk6w | awk '{print $1}'", "delta": "0:00:00.716319", "end": "2020-03-30 19:41:38.284610", "failed_when_result": false, "rc": 0, "start": "2020-03-30 19:41:37.568291", "stderr": "", "stderr_lines": [], "stdout": "containerd-chaos-8eajxg", "stdout_lines": ["containerd-chaos-8eajxg"]}

2020-03-30 19:41:39.512796 Step: Obtain the pod ID through Pod name
task path: /chaoslib/litmus/container_kill/containerd_chaos/crictl-chaos.yml:86
details => {"changed": true, "cmd": "kubectl exec containerd-chaos-8eajxg -n default -- crictl pods | grep \"nginx-7989b5f7f4-md8nr\" | awk '{print $1}'", "delta": "0:00:00.949535", "end": "2020-03-30 19:41:39.489489", "failed_when_result": false, "rc": 0, "start": "2020-03-30 19:41:38.539954", "stderr": "", "stderr_lines": [], "stdout": "ee68f8e531400", "stdout_lines": ["ee68f8e531400"]}

2020-03-30 19:41:40.618870 Step: Obtain the container ID using pod name and container name
task path: /chaoslib/litmus/container_kill/containerd_chaos/crictl-chaos.yml:95
details => {"changed": true, "cmd": "kubectl exec containerd-chaos-8eajxg -n default -- crictl ps | grep ee68f8e531400 | grep nginx | awk '{print $1}'", "delta": "0:00:00.921604", "end": "2020-03-30 19:41:40.595545", "failed_when_result": false, "rc": 0, "start": "2020-03-30 19:41:39.673941", "stderr": "", "stderr_lines": [], "stdout": "c8c9548739cc2", "stdout_lines": ["c8c9548739cc2"]}
included: /utils/common/generate-kubernetes-chaos-events.yml for <IP_ADDRESS>

2020-03-30 19:41:41.454945 Step: [Event]: Obtain the current date in ISO8601 format
task path: /utils/common/generate-kubernetes-chaos-events.yml:1
details => {"changed": true, "cmd": "date --iso-8601=seconds", "delta": "0:00:00.595989", "end": "2020-03-30 19:41:41.435634", "rc": 0, "start": "2020-03-30 19:41:40.839645", "stderr": "", "stderr_lines": [], "stdout": "2020-03-30T19:41:41+00:00", "stdout_lines": ["2020-03-30T19:41:41+00:00"]}

2020-03-30 19:41:41.521480 Step: set_fact
task path: /utils/common/generate-kubernetes-chaos-events.yml:5
details => {"ansible_facts": {"ts": "2020-03-30T19:41:41Z"}, "changed": false}

2020-03-30 19:41:42.389532 Step: [Event]: Creating a ChaosInject event in the chaosengine
task path: /utils/common/generate-kubernetes-chaos-events.yml:8
details => {"changed": true, "method": "patch", "result": {"apiVersion": "v1", "count": 1, "eventTime": null, "firstTimestamp": "2020-03-30T19:41:41Z", "involvedObject": {"apiVersion": "litmuschaos.io/v1alpha1", "kind": "ChaosEngine", "name": "engine", "namespace": "shubham", "uid": "3f5877f8-cf52-4b4c-a07a-9b34b8eb158b"}, "kind": "Event", "lastTimestamp": "2020-03-30T19:41:41Z", "message": "Injecting container-kill chaos on nginx container of nginx-7989b5f7f4-md8nr pod", "metadata": {"creationTimestamp": "2020-03-30T19:26:58Z", "name": "event-\"ChaosInject\"", "namespace": "shubham", "resourceVersion": "384", "selfLink": "/api/v1/namespaces/shubham/events/event-%22ChaosInject%22", "uid": "8e7adfb6-8342-4904-bbdd-f5f0fe67216f"}, "reason": "ChaosInject", "reportingComponent": "", "reportingInstance": "", "source": {"component": "container-kill-yfx46v-jtqj9"}, "type": "Normal"}}

2020-03-30 19:41:43.581986 Step: Kill the container
task path: /chaoslib/litmus/container_kill/containerd_chaos/crictl-chaos.yml:113
details => {"changed": true, "cmd": "kubectl exec containerd-chaos-8eajxg -n default -- crictl stop \"c8c9548739cc2\"", "delta": "0:00:01.006309", "end": "2020-03-30 19:41:43.558314", "failed_when_result": false, "rc": 0, "start": "2020-03-30 19:41:42.552005", "stderr": "", "stderr_lines": [], "stdout": "c8c9548739cc2", "stdout_lines": ["c8c9548739cc2"]}

2020-03-30 19:41:44.999733 Step: Obtain the container ID using pod name and container name
task path: /chaoslib/litmus/container_kill/containerd_chaos/crictl-chaos.yml:126
details => {"attempts": 1, "changed": true, "cmd": "kubectl exec containerd-chaos-8eajxg -n default -- crictl ps | grep ee68f8e531400 | grep nginx | awk '{print $1}'", "delta": "0:00:01.196341", "end": "2020-03-30 19:41:44.975867", "rc": 0, "start": "2020-03-30 19:41:43.779526", "stderr": "", "stderr_lines": [], "stdout": "f8c30efdc9c58", "stdout_lines": ["f8c30efdc9c58"]}

2020-03-30 19:41:46.087847 Step: Check if the new container is running.
task path: /chaoslib/litmus/container_kill/containerd_chaos/crictl-chaos.yml:137
details => {"attempts": 1, "changed": true, "cmd": "kubectl exec containerd-chaos-8eajxg -n default -- crictl ps | grep f8c30efdc9c58", "delta": "0:00:00.901477", "end": "2020-03-30 19:41:46.063618", "rc": 0, "start": "2020-03-30 19:41:45.162141", "stderr": "", "stderr_lines": [], "stdout": "f8c30efdc9c58       6678c7c2e56c9       1 second ago        Running             nginx                        1                   ee68f8e531400", "stdout_lines": ["f8c30efdc9c58       6678c7c2e56c9       1 second ago        Running             nginx                        1                   ee68f8e531400"]}

2020-03-30 19:42:18.864604 Step: Delete the crictl-chaos pod
task path: /chaoslib/litmus/container_kill/containerd_chaos/crictl-chaos.yml:150
details => {"changed": true, "cmd": "kubectl delete -f /chaoslib/litmus/container_kill/containerd_chaos/containerd-chaos-pod.yml -n default", "delta": "0:00:32.553739", "end": "2020-03-30 19:42:18.825867", "rc": 0, "start": "2020-03-30 19:41:46.272128", "stderr": "", "stderr_lines": [], "stdout": "pod \"containerd-chaos-8eajxg\" deleted", "stdout_lines": ["pod \"containerd-chaos-8eajxg\" deleted"]}

2020-03-30 19:42:19.786836 Step: Confirm that the containerd-chaos pod is deleted successfully
task path: /chaoslib/litmus/container_kill/containerd_chaos/crictl-chaos.yml:156
details => {"attempts": 1, "changed": true, "cmd": "kubectl get pods -l name=containerd-chaos-8eajxg --no-headers -n default", "delta": "0:00:00.737554", "end": "2020-03-30 19:42:19.763751", "rc": 0, "start": "2020-03-30 19:42:19.026197", "stderr": "No resources found.", "stderr_lines": ["No resources found."], "stdout": "", "stdout_lines": []}
included: /utils/common/status_app_pod.yml for <IP_ADDRESS>

2020-03-30 19:42:20.719521 Step: [Status]: Checking whether application pods are in running state
task path: /utils/common/status_app_pod.yml:2
details => {"attempts": 1, "changed": true, "cmd": "kubectl get pods -n default -l run=nginx -o custom-columns=:.status.phase --no-headers", "delta": "0:00:00.687742", "end": "2020-03-30 19:42:20.691460", "rc": 0, "start": "2020-03-30 19:42:20.003718", "stderr": "", "stderr_lines": [], "stdout": "Running", "stdout_lines": ["Running"]}

2020-03-30 19:42:21.600764 Step: [Status]: Checking whether application containers are in running state
task path: /utils/common/status_app_pod.yml:9
details => {"attempts": 1, "changed": true, "cmd": "kubectl get pod -n default -l run=nginx --no-headers -o jsonpath='{.items[*].status.containerStatuses[*].ready}' | tr ' ' '\\n' | uniq", "delta": "0:00:00.696146", "end": "2020-03-30 19:42:21.576985", "rc": 0, "start": "2020-03-30 19:42:20.880839", "stderr": "", "stderr_lines": [], "stdout": "true", "stdout_lines": ["true"]}
included: /utils/common/generate-kubernetes-chaos-events.yml for <IP_ADDRESS>

2020-03-30 19:42:22.426309 Step: [Event]: Obtain the current date in ISO8601 format
task path: /utils/common/generate-kubernetes-chaos-events.yml:1
details => {"changed": true, "cmd": "date --iso-8601=seconds", "delta": "0:00:00.582631", "end": "2020-03-30 19:42:22.406007", "rc": 0, "start": "2020-03-30 19:42:21.823376", "stderr": "", "stderr_lines": [], "stdout": "2020-03-30T19:42:22+00:00", "stdout_lines": ["2020-03-30T19:42:22+00:00"]}

2020-03-30 19:42:22.492566 Step: set_fact
task path: /utils/common/generate-kubernetes-chaos-events.yml:5
details => {"ansible_facts": {"ts": "2020-03-30T19:42:22Z"}, "changed": false}

2020-03-30 19:42:23.311013 Step: [Event]: Creating a PostChaosCheck event in the chaosengine
task path: /utils/common/generate-kubernetes-chaos-events.yml:8
details => {"changed": true, "method": "create", "result": {"apiVersion": "v1", "count": 1, "eventTime": null, "firstTimestamp": "2020-03-30T19:42:22Z", "involvedObject": {"apiVersion": "litmuschaos.io/v1alpha1", "kind": "ChaosEngine", "name": "engine", "namespace": "shubham", "uid": "3f5877f8-cf52-4b4c-a07a-9b34b8eb158b"}, "kind": "Event", "lastTimestamp": "2020-03-30T19:42:22Z", "message": "AUT is Running successfully", "metadata": {"creationTimestamp": "2020-03-30T19:42:23Z", "name": "event-\"PostChaosCheck\"", "namespace": "shubham", "resourceVersion": "390", "selfLink": "/api/v1/namespaces/shubham/events/event-%22PostChaosCheck%22", "uid": "10968389-4519-4de1-a267-53233e2959d8"}, "reason": "PostChaosCheck", "reportingComponent": "", "reportingInstance": "", "source": {"component": "container-kill-yfx46v-jtqj9"}, "type": "Normal"}}

2020-03-30 19:42:23.366487 Step: set_fact
task path: /experiments/generic/container_kill/container_kill_ansible_logic.yml:86
details => {"ansible_facts": {"flag": "Pass"}, "changed": false}
included: /utils/runtime/getting_failure_step.yml for <IP_ADDRESS>

2020-03-30 19:42:23.760053 Step: [Failure-Detection]: Recording the name of failed step
task path: /utils/runtime/getting_failure_step.yml:44
details => {"ansible_facts": {"failStep": "N/A"}, "changed": false}
included: /utils/common/generate-kubernetes-chaos-events.yml for <IP_ADDRESS>

2020-03-30 19:42:24.614152 Step: [Event]: Obtain the current date in ISO8601 format
task path: /utils/common/generate-kubernetes-chaos-events.yml:1
details => {"changed": true, "cmd": "date --iso-8601=seconds", "delta": "0:00:00.607361", "end": "2020-03-30 19:42:24.594517", "rc": 0, "start": "2020-03-30 19:42:23.987156", "stderr": "", "stderr_lines": [], "stdout": "2020-03-30T19:42:24+00:00", "stdout_lines": ["2020-03-30T19:42:24+00:00"]}

2020-03-30 19:42:24.675754 Step: set_fact
task path: /utils/common/generate-kubernetes-chaos-events.yml:5
details => {"ansible_facts": {"ts": "2020-03-30T19:42:24Z"}, "changed": false}

2020-03-30 19:42:25.383068 Step: [Event]: Creating a Summary event in the chaosengine
task path: /utils/common/generate-kubernetes-chaos-events.yml:8
details => {"changed": true, "method": "patch", "result": {"apiVersion": "v1", "count": 1, "eventTime": null, "firstTimestamp": "2020-03-30T19:42:24Z", "involvedObject": {"apiVersion": "litmuschaos.io/v1alpha1", "kind": "ChaosEngine", "name": "engine", "namespace": "shubham", "uid": "3f5877f8-cf52-4b4c-a07a-9b34b8eb158b"}, "kind": "Event", "lastTimestamp": "2020-03-30T19:42:24Z", "message": "container-kill Experiment Passed!", "metadata": {"creationTimestamp": "2020-03-30T19:27:02Z", "name": "event-\"Summary\"", "namespace": "shubham", "resourceVersion": "391", "selfLink": "/api/v1/namespaces/shubham/events/event-%22Summary%22", "uid": "b42f1235-e682-430a-be55-38a995a19094"}, "reason": "Summary", "reportingComponent": "", "reportingInstance": "", "source": {"component": "container-kill-yfx46v-jtqj9"}, "type": "Normal"}}
included: /utils/runtime/update_chaos_result_resource.yml for <IP_ADDRESS>

2020-03-30 19:42:26.397236 Step: [Result]: Update the chaos result CR to reflect EOT (End of Test)
task path: /utils/runtime/update_chaos_result_resource.yml:23
details => {"changed": true, "checksum": "ac00bcce865367ca550db292d4c2252a34b5ab5e", "dest": "/utils/runtime/chaos-result.yml", "gid": 0, "group": "root", "md5sum": "9b75431b619041fb2f53992a6ca98550", "mode": "0644", "owner": "root", "size": 329, "src": "/root/.ansible/tmp/ansible-tmp-1585597345.58-64034308827510/source", "state": "file", "uid": 0}

2020-03-30 19:42:27.446829 Step: [The END]: Apply the chaos result CR for container-kill experiment
task path: /utils/runtime/update_chaos_result_resource.yml:33
details => {"changed": true, "cmd": "kubectl apply -f /utils/runtime/chaos-result.yml -n shubham", "delta": "0:00:00.861954", "end": "2020-03-30 19:42:27.423117", "failed_when_result": false, "rc": 0, "start": "2020-03-30 19:42:26.561163", "stderr": "", "stderr_lines": [], "stdout": "chaosresult.litmuschaos.io/engine-container-kill configured", "stdout_lines": ["chaosresult.litmuschaos.io/engine-container-kill configured"]}
META: ran handlers
META: ran handlers

2020-03-30 19:42:27.455766 ************ RELAX, EXPERIMENT ENDS! ************
<IP_ADDRESS>                  : ok=61   changed=35   unreachable=0    failed=0

@ksatchit, We also get a case where the chaos pod is not coming to running state in the first attempt due to low resource availability. In the second attempt It came to running state, refer logs

@ksatchit, We also get a case where the chaos pod won't come to running state in the first attempt due to low resource availability.
In the second attempt, It comes to running state when resources are available(I have deleted some pod), refers logs

Great! Thanks @ispeakc0de


WIP: 0.4 compatibility fixes

This eliminates the deprecation warnings etc. in 0.4 via the Compat package or simple transformations.
The tests pass in 0.3.7 on my machine.  Unfortunately, I'm still getting a segfault in 0.4; I'm not sure what the problem is.
signal (11): Segmentation fault: 11
after_read at /Users/stevenj/.julia/HDF5/src/JLD.jl:369
read_scalar at /Users/stevenj/.julia/HDF5/src/JLD.jl:359
jl_apply at /Users/stevenj/Code/julia/src/gf.c:1693
read at /Users/stevenj/.julia/HDF5/src/JLD.jl:331
jl_apply at /Users/stevenj/Code/julia/src/./julia.h:1261
...

It seems you're not alone in that segfault. I can reproduce it with this snippet from our test scripts:
using HDF5, JLD

fn = joinpath(tempdir(),"test.jld")
syms = [:a, :b]
d = Dict([(syms[1],"aardvark"), (syms[2], "banana")])
jldopen(fn, "w") do file
    write(file, "d", d)
end

jldopen(fn) do file
    read(file, "d")
end

I bet this is since the cfunction/ccall ABI changes.

The segfault should be fixed by 5b60a15de9957ae332a6cc2561a1b8e08c11df0a.

Thanks, @simonster! In 4b63f1a261112fcbefe043fbc9514f1969f78d07 I fixed the next error; the tests now complete, but with several deprecation warnings. @stevengj, perhaps you want to rebase on current master?

Okay, rebased.

Changes Unknown when pulling 1ccbe008d5ba618ca2c1b682e9bb0cfda2dd6c52 on stevengj:0.4-compat into ** on timholy:master**.

Note that there was a warning Warning: using DataFrames.save in module Main conflicts with an existing identifier.  I worked around this by using import DataFrames instead of using, but it would be good to have a better solution for preventing the DataFrames and JLD from conflicting.

Hmm, the test passed once, then I rebuilt HDF5 and I'm getting ERROR: LoadError: LoadError: AssertionError: HDF5.isvalid(dt) at test/gc.jl:25

Changes Unknown when pulling 00c53f93ad0a0360b62bdc7d9def7f1bf77305a6 on stevengj:0.4-compat into ** on timholy:master**.

Looks very nice. I'll merge this (and fix the comment myself in some other commit). It will make it easier to debug any remaining problems.

And of course: thanks!


Add scala version suffix on scala modules

Why are the changes needed?

Add scala version suffix on scala modules to match the name pattern.
Enable kyuubi-extension-spark-3-1 in daily publish snapshot

How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[ ] Run test locally before make a pull request

Codecov Report

Merging #888 (6090c79) into master (962d721) will increase coverage by 0.35%.
The diff coverage is 100.00%.

:exclamation: Current head 6090c79 differs from pull request most recent head 16cb263. Consider uploading reports for the commit 16cb263 to get more accurate results

@@             Coverage Diff              @@
##             master     #888      +/-   ##
============================================
+ Coverage     78.79%   79.14%   +0.35%
  Complexity       11       11
============================================
  Files           137      143       +6
  Lines          5196     5346     +150
  Branches        644      649       +5
============================================
+ Hits           4094     4231     +137
- Misses          749      752       +3
- Partials        353      363      +10

Impacted Files
Coverage Δ

...ache/kyuubi/engine/spark/SparkProcessBuilder.scala
90.00% <100.00%> (ø)

.../scala/org/apache/kyuubi/server/KyuubiServer.scala
47.36% <0.00%> (-2.64%)
:arrow_down:

...pache/kyuubi/sql/KyuubiQueryStagePreparation.scala
79.41% <0.00%> (-0.99%)
:arrow_down:

...a/org/apache/spark/kyuubi/SparkContextHelper.scala
100.00% <0.00%> (ø)

...e/kyuubi/engine/spark/events/JsonEventLogger.scala
90.00% <0.00%> (ø)

...e/kyuubi/engine/spark/events/EventLoggerType.scala
100.00% <0.00%> (ø)

...ache/kyuubi/engine/spark/events/JsonProtocol.scala
100.00% <0.00%> (ø)

...uubi/engine/spark/events/EventLoggingService.scala
82.60% <0.00%> (ø)

...pache/kyuubi/engine/spark/events/EngineEvent.scala
90.00% <0.00%> (ø)

...in/scala/org/apache/kyuubi/config/KyuubiConf.scala
94.41% <0.00%> (+0.26%)
:arrow_up:

... and 2 more

Continue to review full report at Codecov.

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

cc @ulysses-you after this PR, kyuubi-extension-spark-3-1-1.3.0.jar will change to kyuubi-extension-spark-3-1_2.12-1.3.0.jar.
Because we are not intended to support multi scala version in short term, e.g. 2.13, just hardcode _2.12 in some place.

thanks, merging to master for v1.3.0


[wip] test: use standard channel for gwapi crds

DONT MERGE, JUST TESTING

we should have an prow integration test for contour as a required check too - I'm surprised we don't have one


Merge release/0.13.2 into develop branch

This PR merges release/0.13.2 code into the develop branch.

@daniloprates @tomothespian @MarcusHurney @DominikGuzei there were some issues with the app-version check logic which I have discovered tonight and decided to fix them in the scope of this PR: https://github.com/input-output-hk/daedalus/pull/1421/commits/1241015d19e192711aa7c3e264e7a8310a76a1e1
I will port most of these improvements to the release/0.13.2 branch in a separate PR.
The issues which were fixed by these changes are:

Proper handling of a case where app-version API call fails (in which case we assume there is no newer version available and show the "Having trouble connecting/syncing" notification)
Proper handling of Windows platform version check (original call was trying to fetch info for platforms.win32.version and the API responds with platforms.windows.version) - this was a major issue as on Windows we would never get version info 😱
Simplification of the isNewAppVersionLoading variable by reusing Request.wasExecuted and Request.isExecuting flags

@DeeJayElly here you can see how I have made sure the ManualUpdate overlay is hidden during Node shutdown sequence. I thought this might be useful for you :)

@daniloprates @tomothespian @MarcusHurney I have decided to port all the fixes onto the release/0.13.2 branch: https://github.com/input-output-hk/daedalus/pull/1423
Please review and approve that PR first. After we get that one merged I will update this PR again...

Release 0.13.2 has been canceled and the version 0.13.2 removed from the CHANGELOG and package.json in: https://github.com/input-output-hk/daedalus/pull/1441


Add TSDoc, style and className props

I added some TSDocs to the Giscus type definition. I also added style and className props for inline styling. Class name is useful for styled components
Feel free to make/open requests :D

@laymonage, I can check this the days, but I don't know so much over Angular and Vue


Exception in thread "main" java.lang.UnsupportedClassVersionError: org/aion/cli/AvmCLI has been compiled by a more recent version of the Java Runtime

I'm going through the hello world tutorial and coming across an error:
$ wget https://github.com/aionnetwork/AVM/releases/download/avmtestnet-2019-02-08/avmtestnet-2019-02-08.tar.bz2
$ tar xvzf avmtestnet-2019-02-08.tar.bz2
$ cd aion/lib
$ java -jar avm.jar
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: org/aion/cli/AvmCLI has been compiled by a more recent version of the Java Runtime (class file version 54.0), this version of the Java Runtime only recognizes class file versions up to 52.0
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
	at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)

I'm on macOS and not the most familiar with Java. Any help is appreciated. Thanks

That error means that you have JDK8 and the AVM requires JDK10.  You will need to make sure that you have at least JDK10 installed and that it is the one your system is trying to use (you can verify this on the command line with java -version to see the version and then which java will show you where the one you are using is installed).

Thanks! Updating to JDK11 fixed it.


Install tasks via SLURM

Refs:

#556
#659
#528

After reviewing these issues, we (me and @mfranzon) propose to switch to another way of collecting task (which was already mentioned in the past), namely one wher ethe venv-related commands (venv creation and pip commands) are executed on the same machine where the tasks will be executed.
Briefly, task collection would have three phases:

Preliminary checks and configuration (as part of fractal-server)
venv/pip commands
Final checks and db operations (as part of fractal-server)

Steps 1 and 3 should remain very similar to what they are now.
Step 2 should be heavily refactored. Right now it consists of a series of subprocess.run commands, with their I/O handled in python. All these commands are executed on the machine where fractal-server runs, which is clearly a problem (see issues above, but also the possible incompatibility in system libraries).
In the future version, step 2 will be transformed into a bash script, similar to the following prototype:
#!/bin/bash

# Variables to be filled in fractal-server
PYTHON=python3
FRACTAL_TASKS_DIR=/tmp/artifacts
PACKAGE=devtools
VERSION=0.1
USER=fractal
EXTRAS="[]"

PKG_ENV_DIR=$FRACTAL_TASKS_DIR/.${USER}/${PACKAGE}${VERSION}
VENVPYTHON=${PKG_ENV_DIR}/bin/python
LOGFILE=${PKG_ENV_DIR}/collection.log
SUCCESFILE=${PKG_ENV_DIR}/pkg_location.log

# Create venv
$PYTHON -m venv $PKG_ENV_DIR --copies 2>1 >> $LOGFILE

# Update pip
$VENVPYTHON -m pip install pip --upgrade >> $LOGFILE

# Install package
$VENVPYTHON -m pip install ${PACKAGE}${EXTRAS}==${VERSION} >> $LOGFILE

# Show
$VENVPYTHON -m pip show ${PACKAGE} >> $LOGFILE
$VENVPYTHON -m pip show ${PACKAGE} | grep "Location: " > $SUCCESFILE

And, most importantly, this script will be executed via FractalSlurmExecutor (for the slurm backend), or via a standard ThreadPoolExecutor (for the local backend). Thus a SLURM job will install the tasks while executing on a SLURM node.
Some notes:

Relevant paths will still have to be on a share, because both the server and all users need access.
This change will remove the current fail-fast behavior, where an invalid-manifest error (for instance) leads to an early failure (i.e. it does not have to first install a heavy package and then fail). That's an acceptable trade-off, in our opinion.
Once this is implemented and tested, #556 should be automatically fixed.
As per #659, with this refactor we could then easily switch to a situation where the SLURM configuration file also points to several python paths (rather than just a single one in FRACTAL_SLURM_WORKER_PYTHON), each one for a given version. For instance the Fractal admin could include something like

{
  "python3.9": "/usr/bin/python3.9",
  "python3.10": "/data/homes/fractal/miniconda3/env/py310/bin/python"
}

This is to be reviewed and re-discussed together, but we think that the current task collection is wrong, and it just works by accident (mainly because the server machine is very similar to the cluster nodes).

Just to quickly confirm: The fractal user at FMI does not have access to submit jobs to the cluster.
I could make my own user admin as well though (or create an admin user that submits as my slurm user) and we could install tasks via that user.

High-level: Let's not do this now, but take it for further discussion (e.g. with Enrico)

Some content brainstorming:
On 1:
Needs to be the user's slurm user.
Only alternative: We come up with a fractal_service_user (not the server user with sudo rights) that handles environment creation. This user wouldn't have any sudo access.

When we use tasks, we are assuming that the permissions the user chose (e.g. making the task available to a certain user group) reflect the on-disk permissions to the task files.

Yes. Can we make on-disk permissions for this just very broad? => everyone can execute, every user can write to this task folder.
If we go the service user direction, we do not need to give broad write access.
On 2:
/path/to/fractal/general_deployment/.FRACTAL_TASKS/
Give everyone read, write & execute to this folder
Open question: Does the server keep track of whl files separately?

I had a great conversation with Enrico about this today. The conclusion was that we probably shouldn't run jobs as slurm jobs & just tackle the concerns separately. Because handling task environments owned (& editable) by many users would get very tricky!
The main concern is malicious code being run during task installation or malicious task code being installed. Enrico suggested the following mitigation approaches that we should evaluate in due time:

Run an antivirus check on the task directory we have created (& delete it if it spots something? A bit of a false positive risk there). Enrico suggested using clamscan for this.
Run installation as a different user than what runs the server
Encapsulate this user, e.g. using bubblewrap (https://github.com/containers/bubblewrap) & only give it filesystem access to the required folders (e.g. to the task dir, read access to the Python interpreter folder, a tmp dir (can use tmpfs) & potentially a cache dir).

See e.g. https://github.com/containers/bubblewrap/blob/main/demos/bubblewrap-shell.sh


chore(deps): upgrade configuration

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-configuration-k8s-27-main" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 3725

Questions ?
Please refer to the Backport tool documentation


Wallet connect out from native wallet spins on tx attempt

To repro:

connect native wallet to app
connect wallet connect out to an app (etherscan used for testing)
once connected attempt a transaction on etherscan
notice the spinner.....

screen recording upload....

https://github.com/shapeshift/web/assets/15096737/9cb4fad8-ab28-4a5c-815f-38ad1f197475


Issue #47: Implement Mobile Menu in Navbar Component

Issue #47: Mobile menu not implemented in navbar component
Fix:

Added mobileMenuOpen state variable and closeMenu function.
Created MobileNavLink component for mobile menu navigation links.
Implemented Dialog component from @headlessui/react for the mobile menu.
Added a button with Bars3Icon to toggle the mobile menu.
Added @headlessui/react and @heroicons/react as dependencies.

Screenshots:

@AnasGamal I keep saying you are the best a lot. Lol. Thank you for this update.


chaosbot down - database PR

current head yields this on startup:
Traceback (most recent call last):
  File "chaos.py", line 145, in <module>
    main()
  File "chaos.py", line 95, in main
    schedule.run_pending()
  File "/root/.virtualenvs/chaos/lib/python3.6/site-packages/schedule/__init__.py", line 462, in run_pending
    default_scheduler.run_pending()
  File "/root/.virtualenvs/chaos/lib/python3.6/site-packages/schedule/__init__.py", line 75, in run_pending
    self._run_job(job)
  File "/root/.virtualenvs/chaos/lib/python3.6/site-packages/schedule/__init__.py", line 129, in _run_job
    ret = job.run()
  File "/root/.virtualenvs/chaos/lib/python3.6/site-packages/schedule/__init__.py", line 377, in run
    ret = self.job_func()
  File "/root/workspace/Chaos/cron/__init__.py", line 11, in <lambda>
    lambda: poll_pull_requests(api))
  File "/root/workspace/Chaos/cron/poll_pull_requests.py", line 19, in poll_pull_requests
    db = DB.get_instance()
  File "/root/workspace/Chaos/lib/db.py", line 18, in get_instance
    DB.instance = DB(settings.DB_ADAPTER, settings.DB_CONFIG)
  File "/root/workspace/Chaos/lib/db.py", line 31, in __init__
    self.adapter = self.create_adapter(adapter_name, config)
  File "/root/workspace/Chaos/lib/db.py", line 27, in create_adapter
    return getattr(module_instance, class_name)(config)
TypeError: __new__() missing 2 required positional arguments: 'bases' and 'namespace'
Exception ignored in: <bound method DB.__del__ of <lib.db.DB object at 0x7fa92a8d7320>>
Traceback (most recent call last):
  File "/root/workspace/Chaos/lib/db.py", line 35, in __del__
    self.adapter.disconnect()
AttributeError: 'DB' object has no attribute 'adapter'

The real error here is TypeError: __new__() missing 2 required positional arguments: 'bases' and 'namespace'  Will merge a manual PR fixing this.

I'm going to rewrite the db stuff. Should make this a lot smoother

@rudehn thanks! The DB seems to have been causing a lot of trouble. The meritocracy mentioned code currently uses the DB, mind rewriting that too?

Yeah I'll get something up tomorrow.

hotfixes
https://github.com/chaosbot/Chaos/commit/8637b39d66303c19c70552fa4b593884368dde9b
https://github.com/chaosbot/Chaos/commit/626de9e3a72c0a97da5b1d295c0d2e79db4c184e


fix: added contract symbol and position to selection context

Introduces a selection context which stores the state of selection

contract symbol
position (long / short) per contract symbol

resolves #2905

bors+

bors r+


Add support for Stitches as a @mui/styled-engine

Import from a GitHub discussion (we archived them all)

Originally posted by tpvladyslavdasyha April 27, 2022
Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Summary 💡
This RFC is a proposal for adding a style engine Stitches package to MUI.
TL:DR; The question is, will you expand the amount of the engine by adding Stitches in the nearest future?
Examples 🌈
No response
Motivation 🔦
What`s the motivation?

Increasing the existing amount of style engines and package coverage.
Giving support for projects that already use stitches-based solutions.
Stitches support CSS-in-JS with near-zero runtime.
Stitches have a dedicated React lib, but @stitches/core works with any framework including Vue, Svelte, and even vanilla -HTML.
Stitches avoid unnecessary prop interpolations at runtime, making them more performant than other styling libraries.

Stitches show impressive performance statistics.
Stitches support cross-browser server-side rendering, even for responsive styles and variants.

If I'm not mistaken, since you can use the styled() API to hook in with other styling libraries, you should be able to use the styled() function provided by stitches to incorporate it into a mui project.

Stitches uses theme variables and you can't pass a theme as a function for styled:
const { styled } = createStitches({   theme: {     colors: {       violet800: 'hsl(252 62% 54.9%)',     },   }, }); const Button = styled('button', {   backgroundColor: '$violet800', });

Any news on this?

@oliviertassinari the link in top returns 404 (https://github.com/mui/material-ui/discussions/32476). Can you please update?

Closing per https://github.com/stitchesjs/stitches/discussions/1149, the project will be deprecated.


Feature Request: Support installation of common CA cert chain

Enhancement request to support the installation of a common CA cert chain to be referenced within SSL profiles across A3S and non-AS3 deployed applications

This functionality would be within AS3 as its L4-L7.
Certificates may be created in /Common/Shared via AS3 for this purpose and then referenced from other Tenants. If this work flow does not meet the use case, please open a ticket with AS3 for RFE/bug.


Python base upgrade from v3.6 to v3.12.

Is your feature request related to a problem? Please describe.
We now have the latest Python v3.12 and would like to upgrade the project base.
Check all scripts and dependencies too.
Describe alternatives you've considered
Suggest changes if anyone wants to do them one by one rather than changing the whole project base.

I would like to work on this issue @c0sm0void

@trishap-16 assigned.
Please reach out to project mentos for any guidance @whyvineet @mvp-2003

Hi @trishap-16 , I can see with the latest 3.12 it's not compatible especially as it used virtual Python space to work in 3.6.
Could you please make every script and requirement compatible, in that case, we can make it level 3?


Allow module to enable service, but not manage it.

When passing undef to service_ensure, it's ignored and assumed the default value of param, which is "true". When default value of $wildfly::params::service_ensure is undef, this module become more flexible because it's able to enable the service but not manage it.

Coverage remained the same at 74.31% when pulling 8d1a6bf453970572daffe9d1e2322f6d0021cc7e on matheuslcruz:master into 8865a0dcaddc028e13c2ed41d49a23d84ead0c60 on biemond:master.

Coverage remained the same at 74.31% when pulling 8d1a6bf453970572daffe9d1e2322f6d0021cc7e on matheuslcruz:master into 8865a0dcaddc028e13c2ed41d49a23d84ead0c60 on biemond:master.

Coverage decreased (-32.3%) to 42.017% when pulling 6a01d5fc188f1c0f86db706d752926c33f608837 on matheuslcruz:master into 8865a0dcaddc028e13c2ed41d49a23d84ead0c60 on biemond:master.

Coverage decreased (-32.3%) to 42.017% when pulling 6a01d5fc188f1c0f86db706d752926c33f608837 on matheuslcruz:master into 8865a0dcaddc028e13c2ed41d49a23d84ead0c60 on biemond:master.

Coverage decreased (-32.3%) to 42.017% when pulling 6a01d5fc188f1c0f86db706d752926c33f608837 on matheuslcruz:master into 8865a0dcaddc028e13c2ed41d49a23d84ead0c60 on biemond:master.

Coverage decreased (-32.3%) to 42.017% when pulling 6a01d5fc188f1c0f86db706d752926c33f608837 on matheuslcruz:master into 8865a0dcaddc028e13c2ed41d49a23d84ead0c60 on biemond:master.

Coverage decreased (-32.3%) to 42.017% when pulling 6a01d5fc188f1c0f86db706d752926c33f608837 on matheuslcruz:master into 8865a0dcaddc028e13c2ed41d49a23d84ead0c60 on biemond:master.

Coverage remained the same at 74.31% when pulling 56127771e8c0b86c1539c92969c6eed3f273247d on matheuslcruz:master into 8865a0dcaddc028e13c2ed41d49a23d84ead0c60 on biemond:master.

Coverage remained the same at 74.31% when pulling 56127771e8c0b86c1539c92969c6eed3f273247d on matheuslcruz:master into 8865a0dcaddc028e13c2ed41d49a23d84ead0c60 on biemond:master.

Coverage remained the same at 74.31% when pulling 56127771e8c0b86c1539c92969c6eed3f273247d on matheuslcruz:master into 8865a0dcaddc028e13c2ed41d49a23d84ead0c60 on biemond:master.

Coverage remained the same at 74.31% when pulling 56127771e8c0b86c1539c92969c6eed3f273247d on matheuslcruz:master into 8865a0dcaddc028e13c2ed41d49a23d84ead0c60 on biemond:master.

Coverage remained the same at 74.31% when pulling 56127771e8c0b86c1539c92969c6eed3f273247d on matheuslcruz:master into 8865a0dcaddc028e13c2ed41d49a23d84ead0c60 on biemond:master.

Coverage remained the same at 74.31% when pulling 56127771e8c0b86c1539c92969c6eed3f273247d on matheuslcruz:master into 8865a0dcaddc028e13c2ed41d49a23d84ead0c60 on biemond:master.

Sorry, but I'm failing to see your intent here.
Couldn't you just?
class { 'wildfly':
  service_ensure => false, #or 'stopped'
}

If service_ensure is false or stopped, then puppet agent will try to stop
the service. If true or running, it will try to start the service. I don't
want anyone of these behaviors. I need to stop the service - to deploy .ear
for example - and then restart the service. With ensure = undef, a manual
management of the service would be able. The problem is when I pass undef
to ensure_service. In this case puppet assumes the default value, which is
true.
Em 14/01/2017 17:01, "Jairo Junior"<EMAIL_ADDRESS>escreveu:

Sorry, but I'm failing to see your intent here.
Couldn't you just?
class { 'wildfly':
service_ensure => false, #or 'stopped'
}
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/biemond/biemond-wildfly/pull/171#issuecomment-272645279,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABC5S0A6XG7awcEB13ervWh7sHb_65yJks5rSRujgaJpZM4LjKMY
.

I see your point.
I'd like to offer you two options, since the change you proposed will break the behavior for current users:
1 - Couldn't you use wildfly_restart for your scenario? You could have:
wildfly::deployment { 'myapp.ear' :}
~>
wildfly::restart { 'restart after deploy':

2 - If you really can't manage Wildfly service with this module we could have something like manage_user parameter, but for service (manage_service), that defaults to true, but if it's set to false, service resource won't be declared:
Something like this: https://github.com/biemond/biemond-wildfly/blob/master/manifests/prepare.pp#L6 but here: https://github.com/biemond/biemond-wildfly/blob/master/manifests/service.pp#L38

Closed for lack of contact. If you still need this, feel free to reopen or open an issue.


Non-passing tests showing up as grayed out/not run when testing Jasmine in PhantomJS

Apologies for not having a screenshot at hand but the issue I've faced is fairly simple to describe. The extension installs without issue and integrates with Karma fine (as long as the karma.conf.js is actually included in the .csproj - which should probably be documented somewhere; different issue). When running jasmine tests in Chrome everything works seamlessly and great. However, when using PhantomJS to launch tests, anything that does not come back as a success gets grayed out by the test explorer, normally a symptom of a test not having been run. The icon stays as whatever it last was, i.e. if it's ever passed then it will stay with a Tick and just toggle on/off depending on whether it passes. This is semi useful but a test not reporting why it failed is incredibly limiting to the value added by a testing framework.
If I run karma start from the command line everything appears to work fine. It reports failures and successes normally. Apologies I do not have the ability to take an exact output of this at present but can post it later if it would be beneficial.
Packages used to run phantomjs:
Karma regular:
    karma
    karma-jasmine

PhantomJS-specific:
    karma-phantomjs-launcher
    phantomjs-prebuilt

A few details about my System:
Operating System:
	Windows 10 Enterprise

NodeJS:
    v5.5.0

Output from Visual Studio:
	Microsoft Visual Studio Enterprise 2015
	Version 14.0.23107.0 D14REL
	Microsoft .NET Framework
	Version 4.6.01038

	Installed Version: Enterprise

	Architecture and Modeling Tools   00322-80000-00000-AA858
	Microsoft Architecture and Modeling Tools

	UML® and Unified Modeling Language™ are trademarks or registered trademarks of the Object Management Group, Inc. in the United States and other countries.

	Visual Basic 2015   00322-80000-00000-AA858
	Microsoft Visual Basic 2015

	Visual C# 2015   00322-80000-00000-AA858
	Microsoft Visual C# 2015

	Visual C++ 2015   00322-80000-00000-AA858
	Microsoft Visual C++ 2015

	Application Insights Tools for Visual Studio Package   1.0
	Application Insights Tools for Visual Studio

	ASP.NET and Web Tools   14.0.20626.0
	ASP.NET and Web Tools

	ASP.NET Web Frameworks and Tools 2013   5.2.30624.0
	For additional information, visit http://www.asp.net/

	Common Azure Tools   1.5
	Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.

	GenerateUnitTest   1.0
	Generates unit test code for methods in classes under test.

	Microsoft Azure Mobile Services Tools   1.4
	Microsoft Azure Mobile Services Tools

	Microsoft Code Digger   0.9
	Microsoft Code Digger

	Microsoft Team Foundation Server 2015 Power Tools   14.0
	Power Tools that extend the Team Foundation Server integration with Visual Studio.

	Microsoft Visual Studio Process Editor   1.0
	Process Editor for Microsoft Visual Studio Team Foundation Server

	Microsoft.Pex.VisualStudio   1.0
	Pex

	NuGet Package Manager   3.0.0
	NuGet Package Manager in Visual Studio. For more information about NuGet, visit http://docs.nuget.org/.

	PreEmptive Analytics Visualizer   1.2
	Microsoft Visual Studio extension to visualize aggregated summaries from the PreEmptive Analytics product.

	SQL Server Data Tools   14.0.50616.0
	Microsoft SQL Server Data Tools

	Visual Studio Tools for Universal Windows Apps   14.0.23121.00 D14OOB
	The Visual Studio Tools for Universal Windows apps allow you to build a single universal app experience that can reach every device running Windows 10: phone, tablet, PC, and more. It includes the Microsoft Windows 10 Software Development Kit.

	Web Essentials 2015   1.0.204
	Adds many useful features to Visual Studio for web developers.

Same behaviour with Firefox

I have the same behavior as peabnuts123. When I specify PhantomJS and Chrome in karma.conf.js, I see the greyed out tests. But when I do "karma start" in a CMD window, the tests are run and pass.  I have VS2015 Update 1.

It seams that the problem is in JsTestAdapter. I managed to fix it locally under this post:
https://github.com/MortenHoustonLudvigsen/JsTestAdapter/issues/2


Fix typo sometines to sometimes

Changes

Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:

[ ] Includes tests (if functionality changed/added)
[ ] Includes docs (if user facing)
[ ] Commit messages follow commit message best practices

See the contribution guide for more details.
Double check this list of stuff that's easy to miss:

If you are adding a new binary/image to the cmd dir, please update
the release Task to build and release this image.

Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.
Release Notes
Describe any user facing changes here, or delete this block.

Examples of user facing changes:
- API changes
- Bug fixes
- Any changes in behavior

/assign afrittoli

Thank you!
/ok-to-test

/kind documentation
/lgtm

/approve


test: clean some fail_point after test finished

What is changed and how it works?

Issue Number: ref #15990

What's Changed:
Add some missing fail::remove

Related changes

[ ] PR to update pingcap/docs/pingcap/docs-cn:
[ ] Need to cherry-pick to the release branch

Check List
Tests

[ ] Unit test
[ ] Integration test
[ ] Manual test (add detailed scripts or steps below)
[ ] No code

Side effects

[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Breaking backward compatibility

Release note

None

@Connor1996 @overvenus maybe we can change the fail::cfg interface to return a drop guard so manually call fail::remove is no longer needed in most cases, what do you think?

lgtm

The failpoints's custom_test_frameworks automatically remove all failpoints after tests finishes.
https://github.com/tikv/tikv/blob/0151ee39b1048bf598c902d0f7e4de9c1e4267fe/tests/failpoints/mod.rs#L5C27-L5C46

closed since the test framework can ensure all failpoints are cleaned after test finished.


Missing information in Documentation - Compound WHERE - Space missing

The documentation states adding a comment if we are using OR multiple times

// assign a comment for each AND and OR key name. The comment content can be everything.
$database->select("account", '*', [
	"AND #Actually, this comment feature can be used on every AND and OR relativity condition" => [
		"OR #the first condition" => [
			"user_name" => "foo",
			"email" =><EMAIL_ADDRESS>		],
		"OR #the second condition" => [
			"user_name" => "bar",
			"email" =><EMAIL_ADDRESS>		]
	]
]);
// SELECT * FROM "account"
// WHERE (
// 	(
// 		"user_name" = 'foo' OR "email" =<EMAIL_ADDRESS>// 	)
// 	AND
// 	(
// 		"user_name" = 'bar' OR "email" =<EMAIL_ADDRESS>// 	)
// )

But the documentation does not states that there has to be space between AND and #Some Comment.  If the code is AND#Some Comment then it does not create expected SQL. The code should be AND #Some Comment.
I am not sure if this is the expected behaviour of the library or error in documentation.
To reproduce this error here is my code

$tasks = $db->select(
    // table name
    'task',
    // table join
    [
      '[><]client' => [
        // task => client
        'officeid' => 'officeid',
        'clientid' => 'clientno'
      ],
      '[><]taskteam' => [
        // task => taskteam
        'officeid' => 'officeid',
        'taskno' => 'taskid'
      ]
    ],
    // columns
    [
      'taskno',
      // Many other columns
    ],
    // where clause
    [
      // Default Values
      'task.officeid' => $_SESSION['offid'],
      'taskstatus' => ['G', 'S'],
      'taskteam.staffmob' => $_SESSION['mobno'],
      // User Values
      'AND #Some Comment' => [
        'OR #task ' => [
          'taskname[~]' => $_GET['tasksearch'],
          'taskno[~]' => $_GET['tasksearch'],
        ],
        'OR #client ' => [
          'fname[~]' => $_GET['clientsearch'],
          'lname[~]' => $_GET['clientsearch'],
          'cname[~]' => $_GET['clientsearch'],
          'clientid[~]' => $_GET['clientsearch'],
        ],

      ],

      // GROUP BY
      'GROUP' => ['task.taskno'],
    ]
  );

This generates below WHERE Clause

WHERE
`task`.`officeid` = 'DEMO' AND
`taskstatus` IN ('G', 'S') AND
`taskteam`.`staffmob` = '99999' AND
(
 (
   (`taskname` LIKE '%%') OR
   (`taskno` LIKE '%%')
 )
 AND
 (
  (`fname` LIKE '%kesh%') OR
  (`lname` LIKE '%kesh%') OR
  (`cname` LIKE '%kesh%') OR
  (`clientid` LIKE '%kesh%')
 )
)

GROUP BY `task`.`taskno`

If the code is changed to remove the space
      'AND#Some Comment' => [

It generates below WHERE Clause
WHERE
`task`.`officeid` = 'DEMO' AND
`taskstatus` IN ('G', 'S') AND
`taskteam`.`staffmob` = '99999' AND
`AND` IN (Array, Array)

GROUP BY `task`.`taskno`

Thank You. I wasted hours thinking whats wrong with my code. Save me a lot time.

Added it.


make: don't optimize debug binaries

Disable compiler optimizations and function inlining on a debug build to
improve debugging experience.

Is there anything else that needs my attention before the PR can be merged?

No, this just needs a second reviewer. Going to pick someone.


build.gradle Deprecated

No build.gradle ### classpath is outdated, and repositories still using ### jcenter()

Hello WebEngage team!
Our building is falling due jcenter problems, this is direct broken our pipeline and stop our production releases!!
Jcenter is a completely out dated plugin lib, can you fix this asap?

Updating to the lates version 1.2.1 still throws an error com jcentral...


fix AssertionError in DefaultLogStream

this is the same bug as https://github.com/spotify/helios/pull/1018

@davidxia @dflemstr

Current coverage is 46.25% (diff: 87.50%)

Merging #531 into master will increase coverage by 0.54%

@@             master       #531   diff @@
==========================================
  Files           131        131
  Lines          4307       4315     +8
  Methods           0          0
  Messages          0          0
  Branches        638        638
==========================================
+ Hits           1969       1996    +27
+ Misses         2149       2128    -21
- Partials        189        191     +2

Powered by Codecov. Last update 08cc1f7...7754d5c


Add a loading indicator for notebook language detector

Testing #148089
Noticed there is a few second delay of the cell updating to when the action is gone. I think this would be a great place to use the loading~spin icon as it's processing the change as the first few seconds you are not sure if clicking on it worked. The spinner will help in this situation.
https://user-images.githubusercontent.com/35271042/165363321-0651e2d3-82c1-45ca-b3d5-0259807e6313.mp4

Decided to make it fast instead of load :)

/verified?
It detects the language really fast but it doesn't auto switch anymore? I'm guessing this is on purpose.

Notebooks have never auto switched, but untitled editors still should. This bug did not affect untitled editors.


[contact-list] refactor tests

Code changes

[x] refactor tests in contact list

License
I confirm that this contribution is made under the terms of the MIT license and that I have the authority necessary to make this contribution on behalf of its copyright owner.

I think the test cases are very clear.