The following error is shown when using compiling with truffle:
Source file requires different compiler version (current compiler is 0.5.0+commit.1d4f565a.Emscripten.clang - note that nightly builds are considered to be strictly less than the released version
pragma solidity ^0.4.23;
^----------------------^
SyntaxError: Source file requires different compiler version (current compiler is 0.5.0+commit.1d4f565a.Emscripten.clang - note that nightly builds are considered to be strictly less than the released version
pragma solidity ^0.5.4;
^---------------------^
Compilation failed. See above.
Truffle v5.0.4 (core: 5.0.4)
Node v8.12.0
The truffle that you have installed doesnot support solidity compiler 0.5.4, you may either try solving it by using compiler of 0.4.23 or higher as pragma solidity >=0.4.23 or upgrade the compiler that your truffle supports which is mentioned in this link
You should declare solidity compiler version in truffle.js file.
compilers: {
solc: {
version: '^0.4.23'
}
}
Some things you can do,
Open the file in VS Code . Right click on .sol file and click "solidity:download compiler". Then select the version that matches the version of solidity used in your contract (i.e written at top of the .sol file ). Then right click again on the .sol file and choose "solidity : Change the default workspace compiler to remote, local,...".From that choose "localNodeModule"
Right click again on the .sol file and choose "solidity : Change the default workspace compiler to remote, local,...".From that choose "remote"
Go to VS Code>File>preferences>settings
there under left panel, u'll find extensions and in it u'll find solidity preferences. There choose remote.
With that the file will start using the mentioned version
Related
Based on some quick searching, it doesn't look like this issue has been reported yet.
This occurs when locally testing in a firebase functions project with two or more http functions defined for different paths, when supplying the --inspect-functions flag in this command:
firebase emulators:start --only functions --inspect-functions
After a function is called for the first time, the mapping of http paths to functions is broken. Every subsequent call to any function path will be routed to the first function that was called, rather than the one that corresponds to that path.
Minimal code to reproduce: https://github.com/johnang3/functions-emulator-bug-demo
This occurs when using version 10.2.1 of the firebase CLI with firebase-functions versions 3.13.2 and 3.18.1. I have not tested any other versions.
It seems that you are using an outdated version of firebase-tools.
I've tried running the command below under the functions directory, then tried running the browsers found in your Github, and it works fine on my end.
npm install -g firebase-tools
I have attempted to install Psychtoolbox for Octave on Windows 10, per the installation instructions. Before the installation completes, I get this warning:
Screen() failed to work for some reason:
Check the troubleshooting instructions on our Wiki (Download section
and FAQ section, maybe also the Bugs section).
You may need to delete (or rename) the following DLL files in your Octave-4.4.1 installations
bin folder to make this work, then restart Octave:
C:\Octave\4.4.1\bin\libglib-2.0.0.dll
C:\Octave\4.4.1\bin\libgmodule-2.0.0.dll
C:\Octave\4.4.1\bin\opengl32.dll
Once you manage to fix the problem (simply type 'AssertOpenGL' to verify
that stuff works now), you do not need to run the installation routine again,
but can start working immediately.
I had already deleted the named DLL files, which I confirmed. I then ran AssertOpenGL and received this error:
Last Error: could not find library or dependencies: D:\Coding\PTB\Psychtoolbox\PsychBasic\Octave4WindowsFiles64\Screen.mex
Simply calling Screen directly gives this error:
error: library open failed: D:\Coding\PTB\Psychtoolbox\PsychBasic\Octave4WindowsFiles64\Screen.mex
However, the directory containing Screen.mex is at the very top of my path:
Octave's search path contains the following directories:
.
D:\Coding\PTB\Psychtoolbox\PsychBasic\Octave4WindowsFiles64
D:\Coding\PTB\Psychtoolbox
<etc>
As such, the solution to this similar question is of no use. What might I be able to do to correctly configure PTB on Octave?
What version of gstreamer are you using? I had a similar problem recently and fixed it by installing gstreamer 1.14.4. The latest version of gstreamer will not work, nor will versions earlier than 1.14.4.
Situation
I work with Ubuntu 14.04. I am building GNU Octave 4.2.1 from source with GNU 6.3.0. This version of Octave is quite new, but I see the issue arising also when trying to compile older Octave releases (down to 3.8.1).
I configure the build of Octave with
${sourcedir}/configure --prefix=/opt/octave/4.2.1 \
--with-java-homedir=/usr/lib/jvm/default-java \
--with-java-libdir=/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server
Issue
The compilation is successful but the undesired warning shows up
configure: WARNING: ARPACK library found, but does not seem to work properly; disabling eigs function
I would rather like to have the eigs() function in place.
Information
I have built ARPACK-ng myself with the same compiler. All tests in the test suite (make check) are passed. The environment variables LD_LIBRARY_PATH and PKG_CONFIG_PATH point to the ARPACK library directory as intended. The configure file of Octave recognizes that location correctly, as seen before.
Besides, I get the same message if I compile Octave in another computer where ARPACK is installed natively (libarpack2 and libarpack2-dev version 3.1.5-2). It does not change a thing if I also install the related extra libraries libarpack++2c2a and libarpack++2-dev using the package repository. So the issue appears to be independent of the origin of the ARPACK files.
The part of the configure.ac file of Octave that throws this error is
### Check for ARPACK library.
save_LIBS="$LIBS"
LIBS="$LAPACK_LIBS $BLAS_LIBS $FLIBS $LIBS"
OCTAVE_CHECK_LIB([arpack], ARPACK,
[ARPACK not found. The eigs function will be disabled.],
[],
[dseupd],
[Fortran 77], [don't use the ARPACK library, disable eigs function],
[warn_arpack=
OCTAVE_CHECK_LIB_ARPACK_OK(
[AC_DEFINE(HAVE_ARPACK, 1, [Define to 1 if ARPACK is available.])],
[warn_arpack="ARPACK library found, but does not seem to work properly; disabling eigs function"])])
LIBS="$save_LIBS"
The farthest I go in tracing back the issue is that the subroutine OCTAVE_CHECK_LIB_ARPACK_OK issuing the warning lives in the file ${octave_source}/m4/acinclude.m4. It is written in m4 language, which I don't know
Question
Is it possible to understand why ARPACK 'does not seem to work properly'?
Is there any workaround for this?
Is this a false alarm or a bug?
I've successfully installed Cuda SDK and tested the compiler with an HelloWorld
Then I've opened Nsight and I've tried with the same code.
I got this answer " Launch Failed. Binary not found." Is this a problem of the compiler involved in Nsight?
Thank you
This is a known bug. We are aware of it and will try to fix it in one of our future releases.
You need to manually build the project at least once before starting the debug - this is needed for the debugger to be able to detect executable and setup all settings. Note that the debugger will automatically trigger the build on subsequent runs - when it already knows the executable and build configuration you are using..
I want to interact with a MySQL database from Matlab.
I found a mysql "library" for matlab here and the same on mathworks.
I followed the instructions to compile the library and the compilation seems to be successful. I get a mex32 file at the end. Only, the instructions on the first page refer to a Dll that I need to use (I guess that a Dll was supposed to be generated).
I am not familiar with the mex compiler or with compiling external modules for Matlab.
Am I missing something trivial? Where is the Dll supposed to be?
Thanks.
The reference to the dll is obsolete.
When you compile a mex function on Windows, you compile it as a dll (not an .exe). Thus, compiled mex functions used to have the extension .dll. Mex-functions with .dll extensions still work, but there is a warning that this might stop being the case in the future.
When 64-bit Windows arrived, TheMathWorks needed a way that people were to be able to compile the same mex-function for both Win32 and Win64, thus they changed the extension to .mexw32 and .mexw64, respectively. Apparently, they did not update the documentation completely.
I'd recommend using java to connect MATLAB and MySQL (or any other db if required).
The java database connector is simple to set up. I built a simple java class to connect to the database - see previous posting for a crude but working solution.
The MATLAB code works as indicated
% include java class
import Jam.ConnectToDatabase
% set up database connection info
userName='myName';
userPassword='myPassword';
databaseUrl='jdbc:mysql://glnd2818898.internal.net/2000';
% create java class instance and open connection to the database
ctd = ConnectToDatabase;
ctd.openConnection(userName, userPassword, databaseUrl)
Once the connection is open I can then use the java methods to submit SQL queries, create tables, insert data etc. I'd never used java before but I downloaded Netbeans and I was away.
OK, here is the solution to my problem.
The compilation does generate a mex32 file (32 is because I compiled it under a 32bit systme). You can check the output file of the compilation by running mexext. So apparently a mex32 file is a compiled version of the C file.
Once I placed the file in a directory that is in the Matlab's path it worked.
I guess the reference to the Dll in the link I provided is either obsolete or wrong.