error: error executing jsonpath "{.contexts[?(#.name==\"\")].context.namespace}": Error executing template: <nil> is not array or slice and cannot be filtered. Printing more information for debugging the template:
template was:
{.contexts[?(#.name=="")].context.namespace}
object given to jsonpath engine was:
map[string]interface {}{"apiVersion":"v1", "clusters":interface {}(nil), "contexts":interface {}(nil), "current-context":"", "kind":"Config", "preferences":map[string]interface {}{}, "users":interface {}(nil)}
I also had this issue. It started after I upgraded my kubectl to a newer version.
In my case In my zsh I have a custom prompt using POWERLEVEL_9K plugin which displays the current k8s cluster/namespace.
This prompt config in my ~/.zshrc looks like
POWERLEVEL9K_RIGHT_PROMPT_ELEMENTS=(status root_indicator command_execution_time kubecontext background_jobs history time)
Remove kubecontext from there and here you go.
If you'd like to remain k8s info in your prompt, the template in the theme needs to be fixed. I was using POWERLEVEL9K and switching to POWERLEVEL10K did a trick for me.
Related
I am trying to simply upgrade the version of vue3 we are running at work from v3.2.31 to v3.2.40. However, when I do, I am now getting an error in the runtime-dom.d.ts
Below is a screen shot from the file with vue v3.2.31 installed.
Once I've run the "npm update vue --save" command, the file looks like this (v3.2.40)...
...and VS 2022 throws the following error when trying to build...
If I delete the line from my local copy of runtime-dom.d.ts, all works as before. My problem comes when deploying the solution to the development environment etc. The npm install step puts a version of the runtime-dom.d.ts that does still have this line.
I'd like to fix this without having to resort to hacking the runtime-dom.d.ts file if at all possible.
Many thanks in advance.
I've seen the post about blogdown::serve_site() no longer serving the site and read the release notes for blogdown 0.21, but it didn't help with my problem.
My workflow is/was to write a post, then click "Serve Site" in RStudio and check out the newly generated files in the public/ folder of my project. I have a symbolic link of that folder in my ShinyApps directory so I can view my site via the Shiny server. This is great, because then my colleagues who also use the server can see my site as well.
Now this doesn't work anymore. While I get the updated site in RStudio directly, the files displayed by the Shiny server are not being updated. The only explanation I can find is this one:
The global option blogdown.generator.server has been deprecated. Now blogdown::serve_site() always use the Hugo server (which corresponds to options(blogdown.generator.server = TRUE) in previous version of blogdown), instead of the server created via the servr package (which corresponds to the default options(blogdown.generator.server = FALSE) before).
I don't know much about Hugo but I found that hugo server doesn't update the public/ directory, is that correct? What can I do now to update that?
The question was already answered on GitHub:
I need to build the site with blogdown::build_site(local=TRUE).
Edit: Turns out that the below was not the solution either for me. Therefore I posted an own question with a possible workaround:
Problem (and solution?) with rendering Hugo/blogdown site
Earlier (old) post:
With me this did not help. When updating blogdown and starting-up my R project, blogdown:::preview_site(startup = TRUE) automatically runs. Something I don't recall from earlier start-ups. I now always receive the same Error message:
Launching the server via the command:
hugo server --bind 127.0.0.1 -p 4321 --themesDir themes -t hugo-academic -D -F --navigateToChanged
sh: line 0: kill: (3262) - No such process
Error: It took more than 30 seconds to launch the server. There may be something wrong. The process has been killed. If the site needs more time to be built and launched, set options(blogdown.server.timeout) to a larger value.
Running blogdown::build_site(local = TRUE) results in an even longer Error message starting with:
ERROR 2020/11/13 15:55:56 render of "page" failed: execute of template failed: template: _default/single.html:6:5: executing "_default/single.html" at <partial "page_header.html" .>: error calling partial: execute of template failed: template: partials/page_header.html:92:7: executing "partials/page_header.html" at <partial "page_metadata" (dict "page" $page "is_list" 0 "share" true)>: error calling partial: "/Users/frederick/Dropbox/EUR/R_work/r_website/r_website_project/themes/hugo-academic/layouts/partials/page_metadata.html:63:31": execute of template failed: template: partials/page_metadata.html:63:31: executing "partials/page_metadata.html" at <.>: range can't iterate over R
Solution for me
For me, it helped to roll-back to blogdown version 0.20 like so:
packageVersion("blogdown")
#> [1] '0.21'
library("devtools")
#> Loading required package: usethis
install_version("blogdown", version = "0.20", repos = "http://cran.us.r-project.org")
#> Downloading package from url: http://cran.us.r-project.org/src/contrib/Archive/blogdown/blogdown_0.20.tar.gz
packageVersion("blogdown")
#> [1] '0.20'
Created on 2020-11-13 by the reprex package (v0.3.0)
Now everything is back to "normal".
I get the following error while attempting to use the "save hook" functionality in Bosun -
failed to call save hook: fork/exec /tools/bosun/bin/save-hook: exec format error. Restoring config: successful
The file is executable and I've removed all logic from it, and the error still occurs.
Should the file return anything? Or is this a bug?
The documentation indicates it should be successful as long as the hook exits ok.
https://bosun.org/system_configuration#commandhookpath
I would guess the OS is not accepting this as a proper executable?
If a binary, did you compile it on the same system, or make sure your cross compiled it for the right architecture?
If a script, does your script have the bang line at the start, for example #!/bin/bash?
For a project we try to expand the Google Cloud Datalab with IPyWidgets. When we try out IPyWidgets in jupyter notebook (not in google-cloud-datalab) locally, everything run as expected (i.e. we tried to show a Text field, which worked). When we try to execute the same code in Google Cloud Datalab, it fails. In the web console we see following error:
Error 1:
Error message: "Class ipython.widget not found in registry "
Error stack: "load_class/<#http://localhost:8081/static/notebook/js/main.min.js:12751:28load_class#http://localhost:8081/static/notebook/js/main.min.js:12736:1CommManager.prototype.comm_open#http://localhost:8081/static/notebook/js/main.min.js:21802:31.proxy/i#http://localhost:8081/static/notebook/js/main.min.js:89:5486Kernel.prototype._handle_iopub_message#http://localhost:8081/static/notebook/js/main.min.js:23101:20Kernel.prototype._finish_ws_message#http://localhost:8081/static/notebook/js/main.min.js:22936:1Kernel.prototype._handle_ws_message/this._msg_queue<#http://localhost:8081/static/notebook/js/main.min.js:22926:39"
Error 2:
Message: Could not open comm
Error message: "Couldn't process kernel message"
Error stack: "WrappedError#http://localhost:8081/static/notebook/js/main.min.js:12706:19reject/<#http://localhost:8081/static/notebook/js/main.min.js:12785:33"
The strange thing is, is when google-cloud-datalab is running and we go to the jupyter notebook (on port 9000), and we execute the code over there it works.
Do we need to make changes to nb.html, and/or static.ts to make this work?
Question: Is there a way to execute IPyWidgets on Google Cloud Datalab?
Greetings, Brecht
Edit: I can now load the js and the css files from IPyWidgets in google-cloud-datalab (you need to change static.ts, for those who wonder). The only remaining issue (hopefully), is that we get following error:
"Error: Could not determine where the display message was from. Widget will not be displayed".
This is because
var cell = this.get_msg_cell(msg.parent_header.msg_id);
is null (line 556, of ipywidgets/widgets/js/manager.js). I assume that changing static.ts is not enough?
The:
"Error: Could not determine where the display message was from. Widget will not be displayed".
issue can be fixed by changing this line in datalab.js:
originalExecute.apply(this, [ code, callbacks, options ]);
to:
return originalExecute.apply(this, [ code, callbacks, options ]);
I'm attempting to use jade in meteor with this package https://github.com/SimonDegraeve/meteor-jade-handlebars
I'm on a windows machine. I've so far managed to use most meteorite packages by following the instructions here (www.discovermeteor.com/2013/03/20/using-meteor-and-atmopshere-on-windows/)
When i run 'meteor' on my project with .jade files, I'm getting this error:
While building the application:
client\todos.jade: Jade compiler error: Cannot read property 'length' of undefin
ed
=> Your application has errors. Waiting for file change.
Terminate batch job (Y/N)?
I tried to use this new fork too -> https://github.com/kynan/meteor-jade-handlebars/tree/refactor-for-meteor-0.6.5
Same problem.
I further tested this in a Linux machine and it works perfectly. I have no idea why this is failing with the above mention error on windows.
Try adding a blank extra line to the end of your file. For example, an extra line would be needed here.
template(name="name")
h1 Hello!
I've been dealing with a lot of problems getting jade-templating to work with meteor, but finally got it to work.. Here's how:
Add this to smart.json, belt-jade-handlebars is jade for newer versions of meteor:
"packages": {
"belt-jade-handlebars": {}
}
Add this to .meteor/packages:
belt-jade-handlebars
And finally add the extra blank line to all *.jade files. ( suggested by user3064375 )
Start the app by using:
$ meteor run --release template-engine-preview-3
This will use the latest template engine and start meteor.