Today I've upgraded from neovim 0.7.2 to 0.8.0 and my color scheme broke. It seems that some of the colors are okay and some of them are not.
I'm using this color scheme:
https://github.com/arzg/vim-colors-xcode/blob/master/colors/xcodelighthc.vim
here is output of the :highlight command:
The strange thing is that I have this color for example defined in my color scheme that I'm using:
hi Pmenu guifg=#000000 guibg=#f4f4f4 gui=NONE cterm=NONE
but the highlight command shows that
Pmenu xxx ctermfg=0 ctermbg=225 guibg=LightMagenta
guibg=#f4f4f4 vs guibg=LightMagenta
I've checked the changelog for breaking changes regarding colorscheme but I found nothing.
It seems that this weird behaviour is caused by this if statement
let s:t_Co = exists('&t_Co') && !empty(&t_Co) && &t_Co > 1 ? &t_Co : 2
if s:t_Co >= 256
Line: https://github.com/arzg/vim-colors-xcode/blob/master/colors/xcodelighthc.vim#L372
After the update s:t_Co >= 256 evaluates to false and because of that it's not applying the colors correctly.
git bisect told me that neovim broke backward compatibility for exists('&t_Co') in PR #20375. After that commit was merged, the return value of exists('&t_Co') changed from 1 to 0, and even built-in color schemes were also affected.
Edit: I've reported the issue at #21499, and it is now fixed in nightly builds and the upcoming 0.8.2 release.
Related
Lately I can't start single tests in VSCode in neither TestExplorer nor the gutter in the editor via the 'play' button.
npm run test and npm run test:coverage work fine as does the JestRunner extension.
The error I'm receiving is:
> myproject#version1 test
> jest --maxWorkers=${JEST_MAX_WORKERS:-4} "--testLocationInResults" "--json" "--useStderr" "--outputFile" "C:\\Users\\ME~1\\AppData\\Local\\Temp\\jest_runner_myproject.json" "--testNamePattern" "TestFile should do something" "--no-coverage" "--reporters" "default" "--reporters" "c:\\Users\\me\\.vscode\\extensions\\orta.vscode-jest-5.2.2\\out\\reporter.js" "--colors" "--watchAll=false" "--testPathPattern" "c:\\\\path\\\\to\\\\my\\\\project\\\\src\\\\persistence\\\\testfile\\.spec\\.ts"
No tests found, exiting with code 1
Run with `--passWithNoTests` to exit with code 0
In C:\path\to\my\project
86 files checked.
testMatch: **/__tests__/**/*.[jt]s?(x), **/?(*.)+(spec|test).[tj]s?(x) - 25 matches
testPathIgnorePatterns: dist\\, src.bak\\, integration-tests\\ - 83 matches
testRegex: - 0 matches
Pattern: c:\\\\path\\\\to\\\\my\\\\project\\\\src\\\\persistence\\\\testfile\\.spec\\.ts - 0 matches
Apparently the pattern uses 4 backslashes, which might be the problem, but I have no idea how to resolve this issue.
I tried changing the testPathIgnorePatterns in the jest.config.cjs but that didn't change anything.
Also in IntelliJ IDEA everything works as expected, but I prefer VSCode for this particular project.
I am using Airflow2.0 with KubernetesPodOperator want to run a command that use as a parameter a file from inside the image ran by the Operator. This is what I used:
KubernetesPodOperator(
namespace=commons.kubernetes_namespace,
labels=commons.labels,
image=f"myregistry.io/myimage:{config['IMAGE_TAG']}",
arguments=[
"python",
"run_module.py ",
"-i",
f'args/{config["INPUT_DIR"]}/{task_id}.json'
],
name=dag_name + task_id,
task_id=task_id,
secrets=[secret_volume]
)
But this gives me the error:
raise TemplateNotFound(template)
jinja2.exceptions.TemplateNotFound: args/airflow2test/processing-pipeline.json
The image does not use any macros.
Anyone has any clue? What do I do wrong?
This was a bug that started with PR released in version 2.0.0 of apache-airflow-providers-cncf-kubernetes.
The goal of the change was to allow templating of .json files. There was a GitHub issue about the problems it created. The bug was eventually resolved by PR which was released in version 2.0.2 of the provider.
Solution:
Upgrade to the latest apache-airflow-providers-cncf-kubernetes (currently 2.0.2)
If upgrade is not an option use custom KubernetesPodOperator
There are two ways to workaround that problem one is to change template_fields the other is to change template_ext:
1st option: As posted on issue by raphaelauv is not to allow rendering of arguments field:
class MyKubernetesPodOperator(KubernetesPodOperator):
template_fields = tuple(x for x in KubernetesPodOperator.template_fields if x != "arguments")
2st option: if you prefer not to render .json files:
class MyKubernetesPodOperator(KubernetesPodOperator):
template_ext = ('.yaml', '.yml',)
I'm hunting a fun little bug in a tiny reprocessing test: reprocessing01.
The project builds just fine until I make a change and trigger refmt via vscode, and then the project will no longer compile.
Here's the code that compiles and runs just fine for me before making any changes.
open Reprocessing;
type stateT = {
image: imageT,
};
let setup = (env) => {
Env.size(~width=800, ~height=600, env);
let image = Draw.loadImage(
~filename="assets/Wave_pattern_by_inkelv1122_on_flickr_800w.jpg",
~isPixel=false, env);
{
image: image
}
};
let draw = ({image} as state, env) => {
Draw.background(Constants.white, env);
Draw.image(
image,
~pos=(0,0),
~width=Env.width(env),
~height=Env.height(env),
env
);
state
};
run(~setup, ~draw, ());
If I open the project in vscode, make a change such as adding let myvar = 42; at the top, and save to trigger refmt, that introduces this error:
/Users/myer/dev/react/reasonml-playground/reprocessing01/node_modules/bs-platform/lib/bsc.exe -pp "/Users/myer/dev/react/reasonml-playground/reprocessing01/node_modules/bs-platform/lib/refmt3.exe --print binary" -bs-super-errors -w -30-40+6+7+27+32..39+44+45+101 -bs-D BSB_BACKEND="bytecode" -nostdlib -I '/Users/myer/dev/react/reasonml-playground/reprocessing01/node_modules/bs-platform/lib/ocaml' -no-alias-deps -color always -c -o src/index.mlast -bs-syntax-only -bs-simple-binary-ast -bs-binary-ast -impl /Users/myer/dev/react/reasonml-playground/reprocessing01/src/index.re
File "/Users/myer/dev/react/reasonml-playground/reprocessing01/src/index.re", line 12, characters 4-5:
Error: 2817: <UNKNOWN SYNTAX ERROR>
The line in question is the last one of this code block:
Draw.loadImage(
~filename="assets/Wave_pattern_by_inkelv1122_on_flickr_800w.jpg",
~isPixel=false,
env,
);
After this, the only way out is to revert the code to before the changes introduced by refmt.
I suspect that my version of refmt is out of sync with the one required by bsb-native#2.1.1, but I'm not sure which one to install. I have:
$ refmt --version
Reason 3.0.0 # bee43b0
Is there a table that shows compatible versions between reason-cli and bs-platform?
Are there other ways I should investigate this issue or other potential root causes of this behavior?
UPDATE:
I was able to upgrade bsb-native to the master branch and it worked when building to native until I added some more code in reprocessing02
this issue is because bsb-native#2.1.1 comes with an old version of refmt (pre version 3) which can't read the code that your global refmt outputs (most likely because of the trailing commas). I'm working on making a new release 3.2.0 on all platforms, which comes with the latest refmt. If you're on OSX you can try it by just changing your dep to bsansouci/bsb-native#3.2.0, nuking node_modules and reinstalling.
Sorry for the inconvenience. I'm planning on making my release cycle tighly coupled with bsb's release cycle.
I'm trying to configure the max line length (among other settings) for TS Lint in VS code but no matter what changes I make it doesn't 'take'.
So, the first strange thing is that VS code's TS Lint error for max line length says I've exceeded the 140 character limit but in the various config files I've found it only ever mentions 120 characters as the default.
I've changed this to 200 characters, disabled / enabled the extension but still get the 140 character warning. Does anyone know where and how to configure this setting? The documentation online is clear enough but I don't appear to have a tslint.json file and within the node_modules => tslint => lib => rules folder the setting is 120 and changing it makes no difference.
Edit 2020-09-30
Microsoft deprectaded the old plugin and released a newer, completely rewritten version with additional features here.
For the new plugin the setting "tslint.enable": true does not exists and is not needed anymore.
Original Answer
You need to create a tslint.json (in your workspace root) and set something like this to disable the maximum line length:
{
"defaultSeverity": "error",
"extends": [
"tslint:recommended"
],
"jsRules": {},
"rules": {
"max-line-length": [false]
},
"rulesDirectory": []
}
Furthermore, ensure that the following options are set in the in the vscode user settings (settings.json):
"tslint.configFile": "./path/to/tslint/relative/from/workspaceroot/tslint.json",
"tslint.enable": true
The tslint.configFile option can be empty if the file is in the root directory of your workspace.
Further rules can be found here.
ffmpeg -i /home/mysite/public_html/videos/thankyou/thankyou_1.mp4 -strict -2 -vf
"[in]drawtext=fontfile=/home/mysite/fonts/OswaldFont/Oswald-Bold.ttf: x=450:
y=150: fontsize=152: fontcolor=0xAE0216#1: draw='if(gt(n,40),lt(n,300))':
text='THANK YOU',drawtext=fontfile=/home/mysite/fonts/OswaldFont/Oswald-Bold.ttf:
x=450: y=320: fontsize=200: fontcolor=0xAE0216#1: draw='if(gt(n,50),lt(n,300))':
text='JAMISON'" /home/mysite/public_html/videos/thankyou_2.mp4
When running the above, I'm getting the following. It seems to run properly on other distributions. Not sure where to check next.
[Parsed_drawtext_0 # 0x2835480] Option 'draw' not found
[AVFilterGraph # 0x283f980] Error initializing filter 'drawtext' with args 'fontfile=/home/mysite/fonts/OswaldFont/Oswald-Bold.ttf: x=450: y=150: fontsize=152: fontcolor=0xAE0216#1: draw=if(gt(n,40),lt(n,300)): text=THANK YOU'
Error opening filters!
Additionally, this original command works fine in Ubuntu, but give the seen error when running in centOS.
According the the FFmpeg drawtext filter documentation:
draw
This option does not exist, please see the timeline system
This means you should use timeline editing instead.
To do that replace the draw='...' part of your command with:
enable=if(gt(n\,50)\,lt(n\,300))
You should also check:
FFmpeg versions on each machine. You might have an older version installed on Ubuntu, which supports the draw option, and a newer version on CentOS in which the option was removed.
if the font files exist