I have a book called Beginning Lua Programming which is suppose to go over the raw basics but it is sort of leaving me stranded. Here is an effort to condense 3 pages:
QUOTE:
The following environment variables are recommended for Windows:
UTIL_DIR=c:\program files\utility
LUA_DIR=c:\program files\lua\5.1
LUA_CPATH=?.dll;%LUA_DIR%\?.dll
LUA_PATH=?.lua;%LUA_DIR%\?.lua
The UTIL_DIR variable identifies the utility directory you created in the preceding section.
After this, there is a segment about setting the 'windows search path' for lua. Basically, it tells me to look up the output of 'doskey /?' and 'path' and figure it out myself. I have no idea what these do, how to use them, and what the difference between them is.
I'm at my wits end. A detailed explanation or a link to a detailed blog/article or youtube video is EXTREMELY appreciated!
There are a few ways to get Lua working on your machine. If you just want to a functional Lua environment in a hurry with minimal fuss then consider downloading one of the precompiled Lua binaries. The common ones being Lua for Windows and LuaBinaries.
Building Lua with Mingw isn't too difficult:
First get your desired Lua version here.
Extract the tar file containing Lua's source somewhere. For this example, I'll assume you extracted to c:\lua
If you have Msys already set up, you can run the make file from that environment. From the Msys shell, you can build lua with the follow commands:
cd /c/lua
make PLAT=mingw
make install
You should find lua.exe and luac.exe somewhere in there after the build completes. Lua should be ready for use at this point.
The regular cmd.exe shell can work too with some changes to the commands:
cd lua
mingw32-make PLAT=mingw
The make install assumes a *nix environment and so doesn't work under a normal windows cmd shell. In this case you can just manually copy the compiled files from .\lua\src to where you want or you can just run it directly from there if desired.
Related
When using XCode to compile a Cocoa application, I'm running a custom Bash script in the build phase. Unfortunately, I'm having to spell out full paths. Instead, I'm almost certain there are variables I can use in the Bash and one of those might cover it. Here's what I'm running:
/Users/mike/Projects/objectivec/proj1/proj1/shellscript.sh /Users/mike/Projects/objectivec/proj1/proj1/proj1/lang/en/html/
See how having a $VAR would help here, rather than specifying physical paths? It would also help members on my team be able to compile this project without modification.
I tried looking in the XCode7 docs, but couldn't find any listing anywhere of what these variables might be that I can use.
Note that the path /Users/mike/Projects/objectivec/proj1/proj1/ folder contains my AppDelegate.mm file in this case, if that helps you.
Can you tell me where I can find the documentation on this list of available variables so that I don't have to specify full physical paths?
The fix was that I made it run this Bash script as a test:
#!/bin/bash
set > /tmp/vars.txt
Then, I compiled a build. After that, I looked in /tmp/vars.txt to see what was available to use. From there, I could use these directly both in my custom Bash script and in the black script field inside XCode, such as $SOURCE_ROOT.
Thanks in advance for the help.
I'm looking for a binary executable to convert an .arff into a .csv in a bash script. Ideally something that I could run along the lines of
#! /bin/sh
... some stuff....
converstionFunc input.arff output.csv
... some more stuff ...
Looking into writing this myself I found that weka provides a library that I could utilize that would allow me to do this. However, as much as I looked for it, I could not find it. I have weka installed on my mac and after looking around for the library I still was unable to find it.
Does anyone know where I may find such an executable, or able to point me where I could get a hold of the weka java library that would let me write it myself?
Clone this github repository. It contains an arff2csv tool in the "tools" subdirectory.
arff2csv is designed to run in pipes of unix commandline tools.
https://github.com/jeroenjanssens/data-science-at-the-command-line
arff2csv is a one-line shell-script that calls another shell script that calls weka.jar,
so it needs java installed on your machine; and note that arff2csv needs Weka version 3.6. (According to my experiments the newer v3.7 does not work.)
The script wants this environment variable set:
export WEKAPATH=/path/to/wekajar-dirname
and then you can do
cat /opt/smallapps/weka-stable/data/breast-cancer.arff | arff2csv > breast-cancer.arff.csv
Large arffs need some time to get processed.
You can read J.Janssen's book (see repo-README) for a bit more info.
Try an web search for arff2csv. It looks like there are lots of utilities out there.
I have been putting together a makefile in a Windows environment for my team to use. I decided to use MinGW's version of make for Windows. I put that executable with its dependencies into a repository location that should be in everyone's PATH variable. The executable was renamed "make.exe" for simplicity.
Then I realized that I have to account for the case when someone has cygwin's bin folder in their path. Commands like echo, rmdir, and mkdir will call echo.exe, rmdir.exe, and mkdir.exe from cygwin's bin folder. This means that I need to appropriately catch this scenario and use different flags for each command.
I see three cases here:
Cygwin's bin path comes before the path where make.exe is located in the repository. When a team member executes make.exe, they will be executing cygwin's make. Unix-style commands must be used.
Cygwin's bin path comes after the path where make.exe is located in the repository. The correct make.exe will be executed, but I still have to use Unix-style commands.
Cygwin is not installed or not in the PATH. I can use all Windows commands in this case.
I am fine with treating cases 1 and 2 the same. Since MinGW's make and cygwin's make are both based on GNU Make, then I don't see this being much of an issue other than incompatibility issues between versions of GNU Make. Let's just assume that isn't a problem for now.
I have come up with the following check in my makefile.
ifneq (,$(findstring cygdrive,$(PATH))$(findstring cygwin,$(PATH))$(findstring Cygwin,$(PATH)))
#Use Unix style command variables
else
#Use Windows style command variables
endif
Finding "cygdrive" in the path variable means that we are most likely in case 1. Finding "cygwin" or "Cygwin" in the path variable most likely means that we are in case 2. Not finding either string in the path most likely means that we are in case 3.
I am not completely fond of this solution because the cygwin's folder can be renamed or the string "cygwin" or "cygdrive" can be put in the PATH variable without having cygwin installed. One team member is still having issues as he has cygwin's bin path in the PATH variable, but the above does not catch that. I am assuming that he renamed the folder to something else, but I haven't been able to check on that.
So is there a better way to figure out what syntax that I should be using?
Here is another solution that I thought up.
ifeq (a,$(shell echo "a"))
#Use Unix style command variables
else
#Use Windows style command variables
endif
This is based on the fact that 'echo "a"' in Unix will print a (without quotes) but windows will print "a" (with the quotes). If I am using the Unix style echo then I can assume that I am using all Unix commands.
I don't find this solution very elegant though, so I am not marking it as the solution for this question. I think this is better than what I originally had though.
Cygwin make v. MinGW make: Does mingw make support the jobserver, as in can you do make -j5? If not, ${.FEATURES} has jobserver for cygwin make. Maybe load is a good test too.
Cygwin before non-cygwin on path: cygpath.exe is unique to cygwin. You could just look for this in ${PATH}. Unfortunately, Windows users like using spaces in folder names, and there's no way of dealing with this in pure make. $(shell which make) will return /usr/bin/make for cygwin, though a shell invocation on every make run is very smelly.
You don't install a compiler from a repository, is not make a similar case? Just get your users to install cygwin and be done with it.
git-slave documentation only has the following not-so-helpful comment regarding installation on Windows:
* Limited windows support
Multiple users have been successful in using gitslave with Windows.
This is "supported" only in the sense that people have reported it to
work and we accept bugfixes, not that you can `make` install or check,
or that it is QAed on this platform prior to release."
When I try to download and run 'nmake install' I get the equally cryptic error:
makefile(2) : fatal error U1001: syntax error : illegal character '{' in macro
Stop.
Does anyone have any experience with this and can point me in the right direction?
The Makefile for git-slave has only been used with GNU Make - as it is a rather simple makefile, there is no reason it shouldn't work with Microsoft nmake as well, except for "gratuitous" use of Make extensions that are not supported by Microsoft nmake. ( How similar/different are gnu make, microsoft nmake and posix standard make? has a good summary of the differences).
On lines 2-4 of gitslave/Makefile, if you replace ${prefix} with $(prefix) and ${mandir} with $(mandir) [essentially replace braces with parentheses (brackets)] nmake should no longer choke on Makefile. However, unless you have installed a bunch of POSIX utilities or something that allows commands like mkdir -p, rm -f, and sed to work, fixing the nmake incompatibility would only allow (at best) make testcheck to work.
None of the gitslave developers have regular(?) access to Windows development machines, so like the documentation says: "we accept bugfixes, [but do] not [claim] that you can make install or check,
or that it is QAed on this platform."
I imagine that the other people who have used git-slave on windows just made sure that Perl and gitslave and any POSIX utilities that gitslave depends on (e.g. grep and rm) are installed somewhere in PATH.
On Windows you can download and install the free unix tool kit including all necessary programs:
https://sourceforge.net/projects/unxutils/
You also need a perl tool kit because "pod2man" is used in the make process.
Furthermore the script "gits" is a perl script which runs under *ix because of the "she-bang" instruction in the first line ("#!/usr/bin/perl") - this doesn't work on Windows.
I created a small wrapper batch scripts that uses my perl to start the original script:
gits.bat:
perl gits %*
Hope this helps.
I'm using Mingw to build a C/C++ project. This project has makefiles beyond my comprehension, and relies on a custom and quite sophisticated toolchain to compile it. It's quite convenient to have GNU tools available on Windows, especially from Windows's cmd shell, but while invoking the tools (make in particular), MinGW seems to change my PATH around.
Cmd does it normally:
echo %PATH% > ... c:\Apps\msys\bin ... (from cmd)
but msys changes this address to :
echo $PATH > ... /usr/bin ...
in msys, even when I print the PATH from a makefile. As a result, make complains that it can't find commands like make, uname, echo, you name it (no pun intended).
Strangely, I managed to get this environment working ages ago without a hitch, but this is the first time I remember seeing this path problem. How can I get MinGW/msys to correctly point to its executables?
richard has a point - there were two different shells fighting over environment variables (not to mention running msys) and so each parsed its own and the system's environment variables differently.
Also make sure that variables defined in your user or system environment are properly written - Windows likes "C:\foo\bar" style paths, but Msys treats them as "/c/foo/bar".