I added vue-chartjs as per instruction (https://vue-chartjs.org/ja/guide/).
% yarn add vue-chartjs chart.js#2.9.4
Then ran % yarn dev.
Now I see this error on console.
Loading...
ERROR in ./node_modules/vue-chartjs/dist/index.js 198:37
Module parse failed: Unexpected token (198:37)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
| const ref = shallowRef(null);
| const reforwardRef = (chartRef)=>{
> ref.value = chartRef?.chart;
| };
| expose({
Reproduction
I can give an access to the repository if needed.
chart.js version
2.9.4
vue-chartjs version
^5.2.0
Possible solution
I did try installing style-loader css-loader, but it caused another error.
in ./.nuxt/components/nuxt-error.vue?vue&type=style&index=0&id=74e3df5b&lang=css& (./node_modules/css-loader/dist/cjs.js??ref--3-oneOf-1-1!./node_modules/#nuxt/webpack/node_modules/vue-loader/lib/loaders/stylePostLoader.js!./node_modules/postcss-loader/src??ref--3-oneOf-1-2!./node_modules/#nuxt/webpack/node_modules/vue-loader/lib??vue-loader-options!./.nuxt/components/nuxt-error.vue?vue&type=style&index=0&id=74e3df5b&lang=css&)
Module build failed (from ./node_modules/css-loader/dist/cjs.js):
TypeError: this.getOptions is not a function
at Object.loader (/Users/tenna/Desktop/Henshin-Bike-Tomo/manageWeb/hajimenavi_manage/node_modules/css-loader/dist/index.js:22:27)
% yarn add vue-chartjs chart.js#2.9.4
% yarn dev
Related
Can an apama_project specify the injection order of user-defined types?
It appears the engine_deploy does not automatically resolve the user-defined dependency graph.
Using the apama_project tool, I have setup a project with two *.mon files. 1.mon depends on an event definition in 2.mon.
TestProject
|-.dependencies
...
|-events
|-monitors
| |-1.mon // depends 2.mon
| |-2.mon
|-.project
The intent was to see if the engine_deploy tool could identify the dependency tree of user-defined types. Unfortunately, it does not appear to:
engine_deploy -d ../Deployment .
INFO: copying the project file from /home/twanas/base_project to output directory ../Deployment
WARN: Overwriting output deployment directory ../Deployment
ERROR: Failed to generate initialization list as the project has below error(s):
/home/twanas/base_project/monitors/1.mon: 1: the name rt in the com namespace does not exist
/home/twanas/base_project/monitors/1.mon: 5: "A" does not exist
Full source:
// 1.mon
using com.rt.sub_a;
monitor B {
action onload() {
on all A() as a {
log a.toString();
}
}
}
// 2.mon
package com.rt.sub_a;
event A {
string mystring;
}
Assuming the user is developing on linux so does not use the 'SoftwareAG Designer' - how can this be achieved?
On a separate note - the apama_project and engine_deploy are great additions to toolbase.
The issue was actually caused by invalid EPL using com.rt.sub_a;
The tools did indeed resolve the user-defined dependencies which is excellent.
In my Vue-CLI project, when I tried using the ?? operator, I got this error:
Syntax Error: SyntaxError: /Users/stevebennett/odev/freelancing/v-map/src/components/Map.vue: >Support for the experimental syntax 'nullishCoalescingOperator' isn't currently enabled (30:29):
...
Add #babel/plugin-proposal-nullish-coalescing-operator (https://git.io/vb4Se) to the 'plugins' section of your Babel config to enable transformation.
I installed #babel/plugin-syntax-nullish-coalescing-operator (its name seems to have changed), added it to my babel.config.js:
module.exports = {
presets: ['#vue/app'],
plugins: ['#babel/plugin-syntax-nullish-coalescing-operator'],
};
Now the error message seems to have gone backwards, no reference to the operator name at all:
Module parse failed: Unexpected token (39:35)
You may need an appropriate loader to handle this file type.
| case 8:
| points = _context.sent;
console.log(sheetID ?? 37);
What am I doing wrong?
For me, the #babel/plugin-syntax-nullish-coalescing-operator plugin would not work, which is the one you are using.
I had to use the #babel/plugin-proposal-nullish-coalescing-operator plugin which is the one that the error message suggests you use.
Additionally, I noticed this on the page for the #babel/plugin-syntax-nullish-coalescing-operator plugin:
I can't say for sure if this will fix your problem, but it certainly fixed mine
Error I get:
error[E0433]: failed to resolve: could not find `openssl` in `backend`
--> ...\src\...\swagger-0.12.1\src\connector.rs:41:34
|
41 | native_tls::backend::openssl::TlsConnectorBuilderExt::from_openssl(ssl);
| ^^^^^^^ could not find `openssl` in `backend`
error[E0433]: failed to resolve: could not find `openssl` in `backend`
--> ...\swagger-0.12.1\src\connector.rs:85:34
|
85 | native_tls::backend::openssl::TlsConnectorBuilderExt::from_openssl(ssl);
| ^^^^^^^ could not find `openssl` in `backend`
Compiling hyper v0.2.1
error: expected identifier, found `"rustc-serialize"`
--> ...\hyper-0.2.1\src\lib.rs:129:14
|
129 | extern crate "rustc-serialize" as serialize;
| ^^^^^^^^^^^^^^^^^ expected identifier
Generated a server stub user swagger. Ran into issues where cargo couldn't find openssl, giving an error like 'custom build something openssl-sys 0.9.24'. This was a known issue and I overcame it by downloading vcpkg, and using vcpkg to download openssl. Then using environment variables to point to the download folder so cargo could use openssl. But now the error seems to be that openssl doesn't exist in backend?
It also seems to specific to windows, any ideas?
Tried changing the version of native-tls to the most up to date version but it doesn't seem to have an affect at all. It looks like swagger's dependencies need updating but I literally just generated this stub...
You've landed on a flaw from the Rust documentation tools; it picks up what is in a package, but doesn't show the limits.
The backend module definition is defined as:
#[cfg(any(target_os = "macos", target_os = "ios"))]
pub mod security_framework;
#[cfg(target_os = "windows")]
pub mod schannel;
#[cfg(not(any(target_os = "macos", target_os = "windows", target_os = "ios")))]
pub mod openssl;
In other words, the situation is the following:
If you are on linux (i.e. not macOS, not windows, not iOS), then openssl is available
If you are on windows, then schannel is available
If you are on MacOS or iOS security_framework is available
You should, however, not be trying to target a specific backend, as this defeats the purpose of the library. Instead of importing native_tls::backend::openssl::TlsConnectorBuilderExt, import native_tls::TlsConnectorBuilder and let it decide what backend you need.
This may be easier said than done, however, since by the looks of your error this is caused by a third-party library, which indicates that it was only tested on Linux.
In the book "Embedded Linux Systems with the Yocto Project", Chapter 4 contains a sample called "HelloWorld - BitBake style". I encountered a bunch of problems trying to get the old example working against the "Sumo" release 2.5.
If you're like me, the first error you encountered following the book's instructions was that you copied across bitbake.conf and got:
ERROR: ParseError at /tmp/bbhello/conf/bitbake.conf:749: Could not include required file conf/abi_version.conf
And after copying over abi_version.conf as well, you kept finding more and more cross-connected files that needed to be moved, and then some relative-path errors after that... Is there a better way?
Here's a series of steps which can allow you to bitbake nano based on the book's instructions.
Unless otherwise specified, these samples and instructions are all based on the online copy of the book's code-samples. While convenient for copy-pasting, the online resource is not totally consistent with the printed copy, and contains at least one extra bug.
Initial workspace setup
This guide assumes that you're working with Yocto release 2.5 ("sumo"), installed into /tmp/poky, and that the build environment will go into /tmp/bbhello. If you don't the Poky tools+libraries already, the easiest way is to clone it with:
$ git clone -b sumo git://git.yoctoproject.org/poky.git /tmp/poky
Then you can initialize the workspace with:
$ source /tmp/poky/oe-init-build-env /tmp/bbhello/
If you start a new terminal window, you'll need to repeat the previous command which will get get your shell environment set up again, but it should not replace any of the files created inside the workspace from the first time.
Wiring up the defaults
The oe-init-build-env script should have just created these files for you:
bbhello/conf/local.conf
bbhello/conf/templateconf.cfg
bbhello/conf/bblayers.conf
Keep these, they supersede some of the book-instructions, meaning that you should not create or have the files:
bbhello/classes/base.bbclass
bbhello/conf/bitbake.conf
Similarly, do not overwrite bbhello/conf/bblayers.conf with the book's sample. Instead, edit it to add a single line pointing to your own meta-hello folder, ex:
BBLAYERS ?= " \
${TOPDIR}/meta-hello \
/tmp/poky/meta \
/tmp/poky/meta-poky \
/tmp/poky/meta-yocto-bsp \
"
Creating the layer and recipe
Go ahead and create the following files from the book-samples:
meta-hello/conf/layer.conf
meta-hello/recipes-editor/nano/nano.bb
We'll edit these files gradually as we hit errors.
Can't find recipe error
The error:
ERROR: BBFILE_PATTERN_hello not defined
It is caused by the book-website's bbhello/meta-hello/conf/layer.conf being internally inconsistent. It uses the collection-name "hello" but on the next two lines uses _test suffixes. Just change them to _hello to match:
# Set layer search pattern and priority
BBFILE_COLLECTIONS += "hello"
BBFILE_PATTERN_hello := "^${LAYERDIR}/"
BBFILE_PRIORITY_hello = "5"
Interestingly, this error is not present in the printed copy of the book.
No license error
The error:
ERROR: /tmp/bbhello/meta-hello/recipes-editor/nano/nano.bb: This recipe does not have the LICENSE field set (nano)
ERROR: Failed to parse recipe: /tmp/bbhello/meta-hello/recipes-editor/nano/nano.bb
Can be fixed by adding a license setting with one of the values that bitbake recognizes. In this case, add a line onto nano.bb of:
LICENSE="GPLv3"
Recipe parse error
ERROR: ExpansionError during parsing /tmp/bbhello/meta-hello/recipes-editor/nano/nano.bb
[...]
bb.data_smart.ExpansionError: Failure expanding variable PV_MAJOR, expression was ${#bb.data.getVar('PV',d,1).split('.')[0]} which triggered exception AttributeError: module 'bb.data' has no attribute 'getVar'
This is fixed by updating the special python commands being used in the recipe, because #bb.data was deprecated and is now removed. Instead, replace it with #d, ex:
PV_MAJOR = "${#d.getVar('PV',d,1).split('.')[0]}"
PV_MINOR = "${#d.getVar('PV',d,1).split('.')[1]}"
License checksum failure
ERROR: nano-2.2.6-r0 do_populate_lic: QA Issue: nano: Recipe file fetches files and does not have license file information (LIC_FILES_CHKSUM) [license-checksum]
This can be fixed by adding a directive to the recipe telling it what license-info-containing file to grab, and what checksum we expect it to have.
We can follow the way the recipe generates the SRC_URI, and modify it slightly to point at the COPYING file in the same web-directory. Add this line to nano.bb:
LIC_FILES_CHKSUM = "${SITE}/v${PV_MAJOR}.${PV_MINOR}/COPYING;md5=f27defe1e96c2e1ecd4e0c9be8967949"
The MD5 checksum in this case came from manually downloading and inspecting the matching file.
Done!
Now bitbake nano ought to work, and when it is complete you should see it built nano:
/tmp/bbhello $ find ./tmp/deploy/ -name "*nano*.rpm*"
./tmp/deploy/rpm/i586/nano-dbg-2.2.6-r0.i586.rpm
./tmp/deploy/rpm/i586/nano-dev-2.2.6-r0.i586.rpm
I have recently worked on that hands-on hello world project. As far as I am concerned, I think that the source code in the book contains some bugs. Below there is a list of suggested fixes:
Inheriting native class
In fact, when you build with bitbake that you got from poky, it builds only for the target, unless you mention in your recipe that you are building for the host machine (native). You can do the latter by adding this line at the end of your recipe:
inherit native
Adding license information
It is worth mentioning that the variable LICENSE is important to be set in any recipe, otherwise bitbake rises an error. In our case, we try to build the version 2.2.6 of the nano editor, its current license is GPLv3, hence it should be mentioned as follow:
LICENSE = "GPLv3"
Using os.system calls
As the book states, you cannot dereference metadata directly from a python function. Which means it is mandatory to access metadata through the d dictionary. Bellow, there is a suggestion for the do_unpack python function, you can use its concept to code the next tasks (do_configure, do_compile):
python do_unpack() {
workdir = d.getVar("WORKDIR", True)
dl_dir = d.getVar("DL_DIR", True)
p = d.getVar("P", True)
tarball_name = os.path.join(dl_dir, p+".tar.gz")
bb.plain("Unpacking tarball")
os.system("tar -x -C " + workdir + " -f " + tarball_name)
bb.plain("tarball unpacked successfully")
}
Launching the nano editor
After successfully building your nano editor package, you can find your nano executable in the following directory in case you are using Ubuntu (arch x86_64):
./tmp/work/x86_64-linux/nano/2.2.6-r0/src/nano
Should you have any comments or questions, Don't hesitate !
I've been trying to install SNA packages but i always get the next errors,
> install.packages("sna")
Installing package(s) into ‘/home/rvaca/R/i486-pc-linux-gnu-library/2.14’
(as ‘lib’ is unspecified)
--- Please select a CRAN mirror for use in this session ---
Loading Tcl/Tk interface ... done
trying URL 'http://cran.cnr.Berkeley.edu/src/contrib/sna_2.2-0.tar.gz'
Content type 'application/x-gzip' length 273329 bytes (266 Kb)
opened URL
==================================================
downloaded 266 Kb
The downloaded packages are in
‘/tmp/Rtmp7iF3Qz/downloaded_packages’
> library(sna)
starting httpd help server ... done
Error in attr(helpObj, "call") <- this.call :
attempt to set an attribute on NULL
Error: package/namespace load failed for ‘sna’
> library("sna")
Error in attr(helpObj, "call") <- this.call :
attempt to set an attribute on NULL
Error: package/namespace load failed for ‘sna’
> library('sna')
Error in attr(helpObj, "call") <- this.call :
attempt to set an attribute on NULL
Error: package/namespace load failed for ‘sna’
What happened? Thanks in advance
vacing
When loading the sna package using library(sna) or require(sna), the function .First.lib() is (still) called. This function is now among the defunct functions in the base package (see ?.First.lib), but that's beside the point.
Looking at the source files for sna, .First.lib() is defined in the file zzz.R and contains the line
ehelp <- help(package="sna")$info[[1]].
This does not work well if getOption("help_type") is not "text". You could, therefore, try setting this option before loading the package to see if that works.
options(help_type="text")
library(sna)
Does this still produce an error?
EDIT
Since the above still gives an error, and since the package has properties that are being phased out (i.e., no namespace, and using .First.lib()), I would recommend contacting the package's maintainer (perhaps with a reference to this question on SO):
packageDescription("sna")$Maintainer
Again, my suspicion is that the problem lies in creating the object ehelp in the .First.lib() function, which is called since there is no package namespace specified.
Ok this is the result of sessionInfo(), (I forgot to comment that i runs it into Eclipse)
> sessionInfo()
R version 2.14.2 (2012-02-29)
Platform: i486-pc-linux-gnu (32-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=en_US.UTF-8
[9] LC_ADDRESS=en_US.UTF-8 LC_TELEPHONE=en_US.UTF-8
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] Cairo_1.5-1 igraph_0.5.5-4 rj_1.0.3-7
loaded via a namespace (and not attached):
[1] rj.gd_1.0.3-3 sna_2.2-0 tools_2.14.2