I'm new to Lua and work around with some tutorials, try some basic stuff like coding common algorithms etc.
But I have some trouble while using the lua interpreter on my mac os machine.
For example let's say we have a file called 'sample.lua', holds the code line:
function fib(n) return n<2 and n or fib(n-1)+fib(n-2) end
How do I run that function from terminal?
If I don't use any function, I just call the script with 'lua script.lua' - works!
Next question points on the basic understanding between the usage of non-compiled and compiled lua-source. Why is lua code run without compiling, like I mentioned before (lua script.lua)? Or will this statement compile the code temporarily and run afterwards?
Thanks in advance
chris
You can run lua from the terminal with the -i flag:
lua -i luascript.lua
This will execute the script and then put the interpreter into interactive mode. Then you could call the function right from the interactive prompt:
fib(3)
To run that function from the terminal, you would have to do something like:
lua -e"dofile'sample.lua' print(fib(3))"
The -e there just tells it to execute the following string, which loads your file 'sample.lua' and then prints the result of fib(3) to stdout.
I don't know the answer to your second question though.
Lua scripts are always compiled into Lua VM instructions before running. Precompiled scripts just skip this step.
Related
I am trying to run algolia for the first time but it seems that there is something wrong with my environment. I followed the detailed explanation here https://community.algolia.com/jekyll-algolia/getting-started.html.
I installed and configured everything that is needed from the previous steps but when I run the command
ALGOLIA_API_KEY=xxxxxxxxxxxxxx bundle exec jekyll algolia
I get an error:
'ALGOLIA_API_KEY' is not recognized as an internal or external command,
operable program or batch file.
I have been rereading the documentation for both jekyll and angolia but couldn't find anything that could be helpful.
Since you're running on Windows, you cannot set an environment variable for your command like you can do on UNIX.
As advised in this question, Setting and using variable within same command line in Windows cmd.exe, I believe you could use
set ALGOLIA_API_KEY=xxxxxxxxxxxxxx && bundle exec jekyll algolia
I have installed Octave 3.6.1 along with packages including "signal 1.1.2" but when i run a simple example of "sigmoid_train" function an error appears "sigmoid_train function is undefined".
Can any body tell me what is the problem?
The problem is that you didn't load the signal package. When you type pkg list you can find which ones are loaded by an asterisk in front of their names. Load a package with pkg load signal.
Having to load a packages is that thing that many users coming from Matlab find strange but if you compare with other languages, such as Python, Perl, or C++, would you expect them to import, use, or #include every libraries available in the system by default? See Octave's FAQ for more details.
If you want a package to be loaded automatically by default, the recommended action is to add the line pkg load signal to your ~/.octaverc file.
Finally, you have just started with Octave, you should had installed Octave 3.8.1.
I'm pretty new to CUDA and flying a bit by the seat of my pants here...
I'm trying to debug my CUDA program on a remote machine I don't have admin rights on. I compile my program with nvcc -g -G and then try to debug it with cuda-gdb. However, as soon as gdb hits a call to a kernel (doesn't even have to enter it, and it doesn't happen in host code), I get:
(cuda-gdb) run
Starting program: /path/to/my/binary/cuda_clustered_tree
[Thread debugging using libthread_db enabled]
[1]+ Stopped cuda-gdb cuda_clustered_tree
cuda-gdb then dumps me back to my terminal. If I try to run cuda-gdb again, I get
An instance of cuda-gdb (pid 4065) is already using device 0. If you believe
you are seeing this message in error, try deleting /tmp/cuda-dbg/cuda-gdb.lock.
The only way to recover is to kill -9 cuda-gdb and cuda_clustered_ (I assume the latter is part of my binary).
This machine has two GPUs, is running CUDA 4.1 (I believe -- there were a lot installed, but that's the one I set the PATH and LD_LIBRARY_PATH to) and compile + runs deviceQuery and bandwidthTest fine.
I can provide more info if need be. I've searched everywhere I could find online and found no help with this.
Figured it out! Turns out, cuda-gdb hates csh.
If you are running csh, it will cause cuda-gdb to exhibit the above anomalous behavior. Even running bash from within csh, then running cuda-gdb, I still saw the behavior. You need to start your shell as bash, and only bash.
On the machine, the default shell was csh, but I use bash. I wasn't allowed to change it directly, so I added 'exec /bin/bash --login' to my .login script.
So even though I was running bash, because it was started by csh, cuda-gdb would exhibit the above anomalous behavior. Getting rid of 'exec' command, so I was running csh directly with nothing on top, still showed the behavior.
In the end, I had to get IT to change my shell to bash directly (after much patient troubleshooting by them.) Now it works as intended.
When i test my debian package with lintian i get the following warning:
executable-not-elf-or-script usr/share/cw1-6005-pp6g11/rss_reader.php
Does anyone know why lintian show this warning.
That file, rss_reader.php, has the +x permissions bit set, making it executable, but it isn't an ELF binary and it isn't a script with #! at the start. It therefore can't be executed by a standard linux kernel (there are modules to allow other binary formats to be executed).
In this particular case, although PHP scripts can be given a #! line and made executable, if they're part of a web application this probably isn't what you want. You should probably just remove the +x bit.
chmod -x /usr/share/cw1-6005-pp6g11/rss_reader.php
this will remove the EXECUTION bit from it and Lintian will not print the warning.
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.