Solidity compiler error loading specific function - node.js

Well, here we are once again.. It seems like there is literally NO docs for the usage of the Solidity compiler in Node.js.. Here is my question.
Context : I want to load a specific version of the Solidity compiler in my Node.js program. In order to do so, I installed the Solidity compiler through npm install solc . Then in my code I declared the solc variable, as follows : var solc = require('solc'). Until there no problem whatsoever.
Problem #1 : solc.loadRemoteVersion(version,callback) seems not to work correctly since this call instantly throw the following error: Error retrieving binaries: not found. Even tho this function is supposed to reach a remote folder on GitHub where all (or almost all) versions of the solidity compiler are stored it seems like it's not even trying to fetch the remote versions (it should at least look take some time before failing miserably)
Problem #2 : solc.useVersion(version) throw another error, more interesting in this case: solc.useVersion() is not a function. This call should go under the folder node_modules/solc/bin/solcjs-version.js and look for the desired version of the compiler but insted it decided to completely not work,
Any help is appriciated. I'm literally stuck on this since two days ago.

The package looks for the full version string, including the commit ID - not just the version number. See the wrapper.ts source.
You can find the specific full version strings in list.json that is mentioned in the docs.
And here is a working example:
solc.loadRemoteVersion("v0.8.0+commit.c7dfd78e", (err, solcSnapshot) => {
// prints: 0.8.0+commit.c7dfd78e.Emscripten.clang
console.log(solcSnapshot.version());
});

Related

Rust Compilation dieselrs sqlite3 Generated-Colums

Background
I need to run a binary in an arm based computer(Jetson Nano) and i was compiling and running it without any problems until my team decided to use Generated Columns in sqlite3 a feature that was implemented in version 3.31.0 but the Ubuntu Image ran by said computer has a previous dev-version and results in the following crash using Dieselrs library
thread 'main' panicked at 'called `Result::unwrap()` on an
`Err` value: DatabaseError(__Unknown, "malformed database schema
(group) - near \"as\": syntax error")', src/common_queries.rs:182:35
(we handle the unwrap but i removed it in order to see the real message)
I know its a version problem since the message shown is similar to what its stated in the sqlite3 documentation
.... If an earlier version of SQLite attempts to read a
database file that contains a generated column in its schema,
then that earlier version will perceive the generated column syntax
as an error and will report that the database schema is corrupt.
and because in an x86 computer with sqlite3 version 3.34 works without a problem.
What has been tried
update libraries
I already tried downloading version 3.36 of SQLite from the official webpage and ran sudo make install but that didn't create the library in /usr/include but somehow it still compiles it and it still shows the same error. (maybe it knows where the new library is but its weird that despite that it still doesn't work).
Change db-schema
the simplest solution that i could come up with was to change the schema and store the generated column as a new column that would be generated with an after update trigger but that would mean that the database would no longer be in a Normal form.
Cross compilation
Since it works in an x86 machine I tried targeting the architecture, following different approaches that resulted in the following message
linking with `aarch64-linux-gnu-ld` failed: exit status: 1
....
....
....
aarch64-linux-gnu-ld: cannot find -lsqlite3
aarch64-linux-gnu-ld: cannot find -lgcc_s
which i guess comes from the fact that neither of them show up in /usr/aarch64-linux-gnu/include/ but installing libsqlite3-dev doesn't fix the issue.
Any ideas on how to fix this problem?
Try adding libsqlite3-sys = { version = "0.22.0", features = ["bundled"]} to your Cargo.toml. This forces libsqlite3 to be build from source for the correct target. This uses the latest version of sqlite.
See the documentation of libsqlite3-sys for details.

`fake-timers` 7.1.x compile error "Cannot find name 'queueMicrotask'."

I'm trying to compile a Salesforce sfdx plugin which is a node project with (among others) the following dependency chain that ultimately leads to fake-timers#^7.1.0:
#salesforce/command#2.2.0 -> #oclif/test#^1.2.4 -> fancy-test#^1.4.3 -> #types/sinon#* -> #sinonjs/fake-timers#^7.1.0.
When compiling it with the Typescript compiler tsc, I get the following error:
node_modules/#sinonjs/fake-timers/types/fake-timers-src.d.ts:11:28 - error TS2304: Cannot find name 'queueMicrotask'.
11 queueMicrotask: typeof queueMicrotask;
~~~~~~~~~~~~~~
Found 1 error.
error Command failed with exit code 1.
This looks like a bug in fake-timers-src.d.ts but introduced in 7.1.0 so I could try to lock the version at 7.0.5 but that might break all kinds of other things.
Does anybody who uses/maintains fake-timers know how to fix this? Or will this be fixed in a future version?
BTW I'm a total NodeJS n00b so if there's something really obvious here that I'm missing, please be kind and just tell me what it is :)
Thanks!
Frans
Frans! fatso83 from the Sinon team here :)
The problem here has all to do with TypeScript and nothing to do with Node, so I feel your pain. No wonder you are wondering. The problem is that the definitions are probably missing that property. For version 7 we tried to generate TypeScript definitions from JSDoc. This works reasonably well for simpler type, but ultimately, TypeScript is more powerful in describing types than JSDoc (like the typeof operator), so it was an uphill battle that would never result in the same quality as the types available from the external Definitely Typed project. We ended up abandoning that effort and therefore this will not be fixed, but it will naturally go away with version 8 (that will not be shipping its own types).
What you can do is this: npm install #sinonjs/fake-timers#6 (which is the previous version) and npm install #types/sinonjs__fake-timers#6 (which are the externally maintained types).
You might find some background for this in this issue.

Typescript template literal strings type error

A new version of Typescript is allowing to use template litteral strings as types like for example:
type Hey = 'Hey';
type HeyThere = `${Hey} There`;
And it's working very well in the playground of Typescript with the last version which is 4.1.3.
But when I try using it in my projects, I still get the "Type expected. ts(1110)" error in my syntax.
Even though of course I updated the package to the latest version, I also tried to use it in a new project created from scratch and still didn't work. I'm sure it's a very simple mistake but I can't fix it. Also this is very new feature so I can't find much answers online.
Thank you very much for your help!
update ts-loader to version 8 or 9

Naming an Ngram document after a string. Julia v1.1.1

I am running Julia v1.1.1 on a windows 10 machine.
I recently went back to update my Julia v0.6.2 code to Julia v.1.1.1 as my code is no longer supported in Julia v0.6.2 anymore.
I was wondering if anyone knows how to name an Ngramdocument after a string, I think the function used to do this was in the TextAnalysis package :
name!(Ngramdocument, string)
However, recently now that I am trying to update my code to Julia v1.1.1 it is saying that the function is undefined. I was wondering if maybe I was wrong in assuming that the function was defined in the TextAnalysis.jl package or if they changed the name. I have not been able to find documentation of a name change however.
name! was changed to title!. title!(Ngramdocument, string) should work as expected in Julia 1.1.1 with the recent TextAnalysis.jl release. You can see the relevant pull request here.
While migrating code, if you face such undefined function errors, you may quickly find the changes looking at the commit history of the package repository or using search function on the GitHub repo of the package.

TypeError after upgrading Node version

I'm trying to fix this problem for 6 hours now and I'm slowly starting to lose my mind, so please excuse my generic question.
First of all I am using:
Node: 8.10.0 | npm: 5.6.0 | Yarn: 1.5.1
I just upgraded my project to Node v8 and npm refused to install all dependencies, so i installed yarn which fixed the issue immediately.
My sources are compiled using Laravel Mix which utilises Webpack, Babel, ... internally.
Installing and compiling of my sources works perfectly fine now but for some reason my compiled js file is not working anymore (even if I downgrade to the previous Node version - 6.10.0).
Uncaught TypeError: fn.bind is not a function
at nativeBind (admin.js?id=8c4a6887899977ba8021:72515)
at initMethods (admin.js?id=8c4a6887899977ba8021:75849)
at initState (admin.js?id=8c4a6887899977ba8021:75617)
at Vue._init (admin.js?id=8c4a6887899977ba8021:76936)
at new Vue (admin.js?id=8c4a6887899977ba8021:77037)
at Object../resources/assets/js/admin.js (admin.js?id=8c4a6887899977ba8021:83350)
at __webpack_require__ (admin.js?id=8c4a6887899977ba8021:20)
at Object.1 (admin.js?id=8c4a6887899977ba8021:83790)
at __webpack_require__ (admin.js?id=8c4a6887899977ba8021:20)
at ./node_modules/babel-loader/lib/index.js?{"cacheDirectory":true,"presets":[["env",{"modules":false,"targets":{"browsers":["> 2%"],"uglify":true}}]],"plugins":["transform-object-rest-spread",["transform-runtime",{"polyfill":false,"helpers":false}]]}!./node_modules/vue-loader/lib/selector.js?type=script&index=0!./resources/assets/js/components/Autocomplete.vue.Object.defineProperty.value (admin.js?id=8c4a6887899977ba8021:63)
I have aboslutely no ideas what this error means let alone what causes it.
I know that the error message is pretty generic and could probably mean a lot of things but hopefully someone knows what it means given my context.
Thanks!
#Ortomala Lokni's answer pushed me in the right direction.
For some reason I thought my problem was related to my build scripts, npm, webpack or anything of that sort, which - of course - it was not.
Event though it wasn't really an API change as he suggested there was simply a wrong call to the VueJS constructor in my JS file which, for some reason, had been ignored by a previous release of VueJs but apparently not by the current one.
For anyone experiencing some weird bugs that just don't make sense I recommend the following:
First of all: Determine what really is your problem - if it compiles it is most certainly not related to your JS build
Comment out all of your JS code in your main file
The error should be gone at this point
Narrow down the error by trying to uncomment line by line (or block by block) and test your code after each uncomment
Even though this steps might seem obvious you can easily forget about such simple thing because of the million things that could possibly break when working with modern JS.
Sometime when you upgrade libraries you have to adapt some code. As Javascript is not a typed language, the problem does't appears at compile time but at run time.
In your case, I suppose that you have a problem similar as this one.
Check which libraries yarn has upgraded and verify if some API has changed.

Resources