what the difference between 'devtool build-image ' and 'bitbake '
I'm working with rocko branch. I use the regular way to build image via:
bitbake core-image-full-cmdline
All works fine!
But now I'm trying to work with devtool tool and then I need to use another way to build the core image:
devtool build-image core-image-full-cmdline
So, what's the difference?
Related
I am attempting to get the volar vue language server to work in place of vetur for neovim's native lsp.
Using both lspconfig and lspinstall I was able to create a working custom install for sumneko_lua (unrelated but had to manually build due to some issues with the built-in :LspInstall lua). Below is that code duplicated and modified for an attempt at using this new vue server:
local vue_config = require'lspinstall/util'.extract_config('vuels')
vue_config.default_config.cmd = {'node', './node_modules/vscode-vue-languageservice/out/index.js', '--stdio'}
require'lspinstall/servers'.newvue = vim.tbl_extend('error', vue_config, {
install_script = [[
! test -f package.json && npm init -y --scope=lspinstall || true
npm install vscode-vue-languageservice#latest
]],
uninstall_script = nil
})
Running :LspInstall newvue installs properly, however :LspInfo shows this language server is attached to the buffer (of a .vue file) but not active. I believe the issue is with this path: ./node_modules/vscode-vue-languageservice/out/index.js. It exists, but may not be the correct entry point? The default vue ls simply has vls as the command because it provides a binary. Am I missing something in this package? I have yet to come across another language server without a single binary to pick out.
Thanks!
Can you try an absolute path to the out.js file? In my pretty elaborate config for a custom Volar install I'm using something just /home/myuser/dev/volar/packages/server/out/index.js (where the volar folder is just the whole volar cloned github repo). My full config is here
I don't think you can use relative paths like you did. I know you're assuming that the "./node_modules" means "workspace directory" but it's hard to tell in which directory nvim-lspconfig opens up those executables.
I have yet to come across another language server without a single binary to pick out.
Volar also provides a binary, it's volar-server (after running npm i -g #volar/server), it's just with a custom install (ie. alongside the real volar) you can't use it, because I assume you want to use your local install with custom code.
As for more indepth debugging/logging, you can check ~/.cache/nvim/lsp.log to see why the language server dies in detail.
Environment
Laravel Mix Version: laravel-mix#2.1.0
Node Version: v8.2.1
NPM Version: 6.10.0
OS: Linux (Ubuntu 18.04)
Description:
I'm trying to identify which CSS process is the culprit of some wrong CSS being applied with npm run production but I'm not being able to do it. Some Bootstrap 4 CSS properties are being translated/simplified and it's producing wrong styles. I tried a lot of solutions (in my local webpack.mix.js => mix.options). I've tried to disable purifyCss (I discovered it's not using it), uglify, force outputStyle to 'expanded' (in .sass() method), etc. None of them worked.
As a workaround, I could add a new "prod" ENV and perform minification and other things directly from my webpack.mix.js, but I don't like this solution, specially when I think it's just because of a setting/flag somewhere I could easily change (if I knew which one).
Thank you.
Steps To Reproduce:
npm run dev: background-position: center right calc(0.375em + 0.1875rem)
npm run production: background-position: 100% calc(.375em + .1875rem)
Well, it looks like it was a bug in a mixin:
https://github.com/twbs/bootstrap/commit/de1a6e3201a2f047c5abd2430795be32d37e9a35#diff-4fcf7dc3cf66b28cb08274cc30798d70
https://github.com/cssnano/cssnano/issues/712
Updating to latest Bootstrap version solves the issue.
There is a javascript library, pre-built and available on npm, that I wish to develop with/debug. In my case, it is openlayers.
In the classic way of requiring a javascript file and wanting to debug, one would just switch the script url from the production version to the debug version, ie:
to
However, when using webpack and then importing via npm:
import openlayers from 'openlayers'
Gets you the production distribution of the library, the same as the ol.js script from above.
On a side note, to stop webpack trying to parse a prebuilt library and throw a warning about that you must include something like this:
// Squash OL whinging
webpackConfig.module.noParse = [
/\/dist\/ol.*\.js/, // openlayers is pre-built
]
Back to the problem at hand: how can I conditionally load a different entry-point for a module prebuilt and imported like this?
Of course, I can do it in a hacky way. By going into the node_modules/openlayers/package.json and switching the browser field from
"browser": "dist/ol.js",
to
"browser": "dist/ol-debug.js",
Is there a way I can request a different entry point via webpack or by using a different import syntax? Do I first have to petition the library maintainers to update the browser field to allow different entry point hints to browsers, according to the spec? https://github.com/defunctzombie/package-browser-field-spec
Thoughts on a more effective way to make this happen? Yearning to be able to programmatically switch loading of the production and debug versions of a library based on env variables.
Webpack has configuration options for replacing a module into a different path: https://webpack.github.io/docs/configuration.html#resolve-alias
This resolves the openlayers import to use the debug version:
webpackConfig.resolve.alias: {
openlayers: 'openlayers/dist/ol-debug.js'
}
In my build system I have a function that takes the environment type and returns the matching webpackConfig. Based on the parameter I include the above snippet or not.
Full code: webpack-multi-config.js
I have two different (gulp-) tasks for development and production. For example the production task: webpackProduction.js
Line 1 imports the config script with production as type.
My build system is based on gulp starter.
This is first time I am working with collectd.
I have performed the following steps :
Downloaded https://collectd.org/files/collectd-5.5.2.tar.gz
Extracted the tar.
executed configure
executed make all install
changed the collectd.conf in /opt/collectd/etc/collectd.conf
uncommented the necessary plugin and made changes to file paths.
I have used the following link.
I am getting the above error when I try to run collectd.
However when I use csv plugin it works correctly.
As much as I understood rrdtool is necessary in order to visualize data.
I need rrdtool so that I can visualize my data.
Is there any other alternative to rrdtool to view data on my browser, or any other tool or plugin using which I can visualize my csv data.
This is what I have figured out after running configure:
Thank you
In the same output you have to find the missign lib.
Dependencies:
collectd(x86-64) = 5.6.0-1.sdl7
libc.so.6(GLIBC_2.14)(64bit)
libdl.so.2()(64bit)
librrd_th.so.4()(64bit)
rtld(GNU_HASH)
I'm trying out casperJS to run some automated tests. On windows. I followed this installation guide but am stuck.
when I try to run a simple test from the command line like this:
casperjs.bat smoketest.js
I get the following error:
Error: Cannot find module 'C:/code/base/main/Shared/casperjs\modules\cli.js'
I checked, and the file cli.js does exist under the specified path.
I thought the problem could be the mixture of forward and backward slashes in the path, but I edited the bootstrap.js casper code to hard code the path and it made no difference - it still the cannot find module.
I'm have tried this using phantomJS version 1.9.0, and 1.8.2.
Anyone know what I am doing wrong?
Has anyone had success running casper on Windows?
This is due to a bug in PhantomJS 1.9.0 that does not allow for absolute path loading in Windows. Afaik, this should only be apparent if you are using a master build of CasperJS (v1.1).
This bug has been fixed, but is not yet in the Windows binary. You can compile it yourself if you'd like, but that can take quite a bit of time.
I was using the master build of casper. With the latest released version, 1.0.2, it works fine.