I'm playing with lua with the following link: https://www.tutorialspoint.com/lua/lua_basic_syntax.htm.
Now I'm a bit confused with this supposed simple task to run lua file in the other way, i.e.,
Let's try another way to execute a Lua program. Below is the modified test.lua file −
Live Demo
#!/usr/local/bin/lua
print("test")
Here, we have assumed that you have Lua interpreter available in your /usr/local/bin directory. The first line is ignored by the interpreter, if it starts with # sign. Now, try to run this program as follows −
chmod a+rx test.lua
./test.lua
We will get the following output.
test
I think somehow I need to know where the Lua interpreter located. Any comments are greatly appreciated.
EDIT: After changing /usr/local/bin/lua into /usr/bin/lua, it worked out well.
As mentioned in the manual, use
#!/usr/bin/env lua
if lua is in your PATH.
Related
I'm trying to run a lua file other than main on replit.com, and I'm not sure how to do that. I know in java you just type "java name_of_file" into the terminal but typing "lua name_of_file) doesn't work.
Here is a screenshot of what I'm trying to do:
Here is my code on replit, so you can try running it: https://replit.com/join/kxisutsa-suzm10
You are currently in console, use shell instead and use lua activity.lua to run the activity.lua file.
Title says it all really.
I have a setup that requires the use of environment variables when setting these kind of assignments. Most seem to work, but when it comes to QIP_FILE assignments in a tcl script, Quartus errors.
Using an explicit path in the .qsf project file works. Is there any way of using environment variables in a .qsf file, or am I doing something wrong in my .tcl script?
The line I am using is:
set_global_assignment -name QIP_FILE $::env(MY_VAR_PATH)/my/path/my.qip
Any help on this would be great,
Thanks in advance
EDIT: The error I get when attempting to use the .tcl script is:
------------------------------------------------
ERROR: Can't open project: flash_leds
while executing
"project_open $project_name -cmp $ap_name"
(file "/opt/altera/15.0/quartus/common/tcl/internal/qsh_smart.tcl" line 60)
------------------------------------------------
So I managed to find a solution!
I was calling this .tcl script as source in the .qsf file (as it included other scripts which also needed sourcing. Turns out, for some reason, that the
set_global_assignment -name QIP_FILE ...
command doesn't work when the .tcl file is called using source (but other set_global_assignment calls do work... I don't really know whats happening there!).
To solve this I had to create another .tcl file and move all of the set_global_assignment calls to there, leaving the other file with only the other sourced scripts. This new file then has to be included in the .qsf file in the following way:
set_global_assignment -name SOURCE_TCL_SCRIPT_FILE <filename>
This seemed to solve my issue, and the QIP file was correctly found using the environment variable path.
I am using ZeroBrane Studio as IDE to code deep learning. I have realized that the models I save when programming in the IDE (using Lua 5.1 as interpreter) do not load well when executing the same loading from Torch7. The same happens when learning from torch (./th code.lua) and then trying to load them inside the IDE. I get something like:
/opt/zbstudio/bin/linux/x64/lua: /home/dg/torch/install/share/lua/5.1/torch/File.lua:294: unknown object
Does anybody know how to check the lua version that torch is using? Any idea on how to workaround this?
Thanks!
update: It seems that I am indeed using the same Lua version (5.1) in both Torch and ZeroBrane. I still get different behaviour (one successful and the other crashing) when passing through torch.load().
To check the version of Lua that anything is running, you would usually print _VERSION. It's a global variable that stores the version of Lua (unless you overwrite it, of course).
print(_VERSION)
If this isn't available for some reason, they might state their version on their site (?)
Most command line tools on Linux understand the -v command line switch (for "version"). So do Lua and LuaJIT.
To figure out which interpreter is running a particular script, you can scan the arg table for the smallest (usually negative) index:
local exe, i = arg[ 0 ], -1
while arg[ i ] do
exe, i = arg[ i ], i-1
end
print( exe )
Or (on Linux) you can look into the /proc file system while your script is running:
ls -l /proc/4425/exe
(substitute 4425 with real process ID).
Judging from the error message the interpreter used in ZeroBrane Studio seems to be /opt/zbstudio/bin/linux/x64/lua in your case.
#siffiejoe: thanks for posing your question regarding versions, it gave me the correct directions to explore.
/opt/zbstudio/bin/linux/x64/lua version is LuaJIT 2.0.2
"lua" command alone points to /usr/bin/lua, and it is Lua 5.1.5
~/torch/install/share/lua/5.1 seemed to contain Lua 5.1
~/torch/install/bin/luajit is 2.1.0-alpha
So after realizing that terminal "th" is using LuaJit 2.1.0 all I had to do is create a user.lua in ZeroBrane and add the line "path.lua = "~/torch/install/bin/luajit". Now ZB is using the same luajit interpreter as th.
Thanks all for your suggestions.
I have a simple script that I want to import into another with require, but when I run it from Notepad++ I get the usual error that require produces.
The funny thing is that it worked an hour ago and I did not restart the computer since then.
The files are in the same directory, so the simple file name (without .lua) worked and should still work. (relative path)
Lua runs the script just fine.
this is what I entered in Notepad:
cmd /k lua "$(FULL_CURRENT_PATH)"
Earlier I also had a problem with Penlight, maybe there is some connection, so here it is:
I tried to require"pl" but it failed to find the module. (ran from SciTE, worked prevously)
I tried it in the Lua command line and it worked like a charm.
Tried again in SciTE and voila it worked again.
I have no idea what causes any of them.
ps.: using the lfs module and os.execute("cd /d ...path...") did not work
Lua is searching for your required module in the folders of LUA_PATH. In the script you run via F5, put this statement:
print('current path is:')
os.execute('cd')
require 'someModuleThatDoesntExist'
After printing the "working" forlder (Program Files/Notepad++), it tries to find the required module and fails. The traceback shows that Lua looks through many different folders, none of them being the one containing FULL_CURRENT_PATH, so it can't find the module.
You have several choices:
put your scripts in one of the listed paths
set LUA_PATH in your environment to contain the folder name where your scripts are located
change package.path from your script so it knows where to look for other modules. You could do this by either:
including an extra parameter to your F5, namely CURRENT_DIRECTORY, and make your script take its first command line param (CURRENT_DIRECTORY) to add it to package.path
parse arg[0] when your script starts, to get the folder containing script, and extend package.path
For example with #3, first option, you would use
cmd /k lua "$(FULL_CURRENT_PATH)" "$(CURRENT_DIRECTORY)"
in notepad++ and in your Lua module you would use
thisModuleDir = arg[1]
package.path = thisModuleDir .. ";" .. package.path
require 'yourmodule'
Does Lisp Flavored Erlang (LFE) work on Windows? I am using LFE 0.6/Erlang 5.8.2/Windows 7 32-bit. I copied the lfe shell script as a batch file (replacing $# with %1 %2 %3 %4) and it gives me this:
D:\projects\checkout\lfe>lfe
{"init terminating in do_boot",{undef,[{lfe_boot,start,[]},{init,start_it,1},{init,start_em,1}]}}
Crash dump was written to: erl_crash.dump
init terminating in do_boot ()
The problem here is that Erlang can't find the LFE ebin directory. Two ways to solve this problem are:
Use an explicit -pa <lfe ebin dir> argument when starting LFE, either in the lfe.bat script or when you call it. Simple but hard wired.
Use the ERL_LIBS environment variable. This is described in the code module documentation, http://erlang.org/doc/man/code.html. If you create an extra Erlang library directory, say c:\projects\erlang, drop Erlang apps which follow the Erlang application directory structure as LFE does, and point ERL_LIBS at it then the code server will automatically add ebin directories it finds there to its code path.
This is also described in How do I install LFE on Ubuntu Karmic? but in a UNIX context.
The ERL_LIBS feature should definitely be better advertised.
EDIT: Replying to #Shantanu Kumar's comment.
I don't have access to a Windows machine so I can't test it properly. The problem seems to be that using lfe_boot tries to start the port program ttysl which doesn't seem to work on Windows, at least not when running erl.exe. Some solutions to try:
Use werl.exe instead. This may work, but I would do it anyway.
Try starting Erlang in the normal way with werl.exe -pa ebin (to get the right load path) and manually starting the LFE shell with lfe_shell:server().
Try starting Erlang with werl.exe -pa ebin -noshell -s lfe_shell start. This will run lfe_shell as the shell but the ^G won't be available.
Also while it is nice to use it you don't need to use the LFE shell to run LFE, you can use the normal Erlang shell and just call the LFE functions in the "normal" way. You might become a little schizophrenic with two io formats, but there are no problems. :-)
Hope this helps.
My apologies; I know this post is basically dead, but I don't find other posts on the topic, thus replying here seems appropriate.
I believe I've found a methodology that works. Very simple really: just use MSYS2 and Mingw-w64 to build LFE, then run it from the build directory via ./bin/lfe.
There's one tweak needed it seems: the last line of bin/lfe seems to require a tweak to call "werl" instead of "erl". Honestly I don't know why this is; I'm too green behind the ears with Erlang to say why.
I've also documented this with slightly more detail on my personal blog: http://www.vultaire.net/blog/2016/05/02/installing-lisp-flavored-erlang-on-windows/
Hope this helps someone out!