How can I simply "run" lisp files - windows

Python
When I learned Python I installed it on windows with a nice gui installer and all .py files would automatically run in python, from the command line or explorer.
I found this very intuitive and easy, because I could instantly make plain text files and run them.
Lisp
I'm starting to learn lisp and have decided (from reviews) that SBCL is not a bad lisp implementation.
Is there a way to setup SBCL to run .lisp files as easily as with Python?
Are there other lisp implementations that have this?

Executables
SBCL can save executable images, as Greg Harman mentions (see the :EXECUTABLE keyword): http://www.sbcl.org/manual/index.html#Saving-a-Core-Image
Scripts
Lisp files can be executed as scripts, see: http://www.sbcl.org/manual/#Shebang-Scripts
Command Line Options
SBCL has command line options to evaluate/load lisp code on start: http://www.sbcl.org/manual/#Command-Line-Options
SLIME
SLIME is an Emacs interface for Common Lisp. One can use SBCL via SLIME from within Emacs. Many people prefer Emacs Lisp listeners over typical shell interfaces.
Most Common Lisp implementations have similar capabilities. For details consult their manual or ask here for specific implementations.

A few minutes ago someone replied with an answer nearing what I was looking for.
The reply linked to http://www.sbcl.org/manual/Shebang-Scripts.html which was a great help in figuring out my solution. Whoever it was shouldn't have removed their answer as I was about to mark it as correct ;)
My final solution was to create a batch script that is linked through normal program file association as the program to open .lisp files (Right click file->Properties->Opens With->[Change]).
#ECHO OFF
"C:\Program Files\Steel Bank Common Lisp\1.0.37\sbcl.exe" --script %1
When you double click files in explorer it executes them and when you run them in the command line it does the same.

SBCL can save an executable core image via sb-ext:save-lisp-and-die

If you have already downloaded and installed the SBCL interpreter, then in order to run your programs by simply entering them into the command line you need to add the location of the interpreter to your system PATH variable, so that your machine knows where to look.
This is true for any language. What the Python installer did was add the location of the Python interpreter to your PATH environment variable.
Depending on your platform, do a quick Google search on how to set environment variables.

Related

Cross platform make replacement

I am hoping there are some Windows command-line wizards here. If there are, I am forever in your debt.
I have used R (and related tools) on Linux for years. I do everything in emacs if I can. My fingers are just happier that way.
To ensure my analysis is reproducible, I write a makefile for each report / analysis in a project. I use a combination of R and pandoc to produce reports these days. Once my makefile is written, I simply open a shell and enter:
make -f my_target
And my computer runs my analysis. Easy. On Linux.
I have recently started a job with the government and my computer is running Windows and I no longer have make, except through mingw and neither emacs nor gitbash recognize make. I would like to be able to run make (or something equivalent) from both (or either) emacs / gitbash to run my code in a coherent / sane manner.
Thus my question is this. How can I use make, which is currently ONLY accessible through a msys shell and not connected to either gitbash or emacs or what other tool should I move to so I can continue to "build" my reports in a sane / reproducible manner?
If I am better off learning a new tool, that is fine. If there is some way to run mingw's make from emacs / gitbash that is good too. I am open to suggestions. Most of the tutorials on-line are for Windows programmers moving to Linux. There aren't as many resources for us moving from Linux to Windows (which is understandable).
After much swearing and gnashing of teeth, I finally figured out what I did wrong.
I followed the installation instructions for MinGW, but I made a typo when I altered my user's path. Thus, MinGW was NOT in my path.
Following these instructions work, but it isn't smart enough to fix your typographical errors.
Getting Started

bizarre behavior of system() in Ruby

I have set up shuffle_play.rb in Ruby by Example to work on Windows, with mpg123 instead of ogg123. The critical part is a method called play_file, which initially I wrote like this
def play_file(file)
system("mpg123 \"#{file}\"")
end
I have mpg123 in the same directory as my script ... it didn't work. But this does work:
def play_file(file)
system("mpg123.exe \"#{file}\"")
end
I reckon it's because I don't have working directory in %PATH% (and indeed the problem goes away when I add it) but even then I don't know enough about Windows to know the difference. Could someone explain the rationale for this?
Probably the examples assume that you're on a *nix variant such as Linux or Mac. In those Operating Systems, the program is called mpg123, because those OS, don't care about extensions, the just check that the file has an executable attribute
On windows things are very different. Windows decides if something is a program depending on the extension (.exe, .com, .bat, .cmd, etc.). So the program in windows has to be called mpg123.exe. If you open a command line on windows, you can run the program without specifying the extension, as windows automatically tries the different extensions. This behaviour of trying different extensions happens ONLY in the command line and not when you try to invoke a program from another one.
There a environment variable called PATHEXT that list in which order windows tries the different extensions. On my computer that list is:
C:\Windows\System32>echo %PATHEXT%
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.RB;.RBW
I hope it was clear. And a suggestion if you want to code in ruby, install Linux or get a Mac.

alternative bash for windows / or help on cygwin with specific tasks

my goal: to create a suite of scripts that do some common system tasks, which include these
copy/move/list/search/grep files
watch/start/stop processes
run queries against Oracle via sqlplus
i grew accustomed to using Cygwin/bash to ease my life at work, and frankly speaking, i don't want to move away from bash language and start learning PowerShell, for example - so i started searching for a way to run bash scripts on Windows, ... preferably something alternative to Cygwin.
the truth is that i am still not pleased with Cygwin installation, and the fact that there is no simple way around it, that it is targeting more or less expert users, and there are a number of things that might pop up during the installation. i mean. what i am trying to do now is to write a suite of scripts that will target someone less expert than me (and i am in no way a real expert) - in most cases some kind of an administrator who doesn't want to know the script details.
i am thinking that this user will also want to be able to run these scripts on another machine, and i want to be able to explain him/her how to do it, without just saying, call the support, and, me, eventually (so that we can install cygwin on another machine etc etc.)
i tried MinGW(msys) but it also needs manual steps to set things up - i mean, these manual steps have become something of a de facto standard in these Windows ports (sorry, maybe i have a mood for bragging). win-bash looked like it could be a solution, but i ended up trashing it too, because of the old bash version, and its inability to do things i was able to do in cygwin - specifically
here documents
things like "cmd /C dir *" (don't know why) - and yes, i do cmd /C dir in cases i am in some kind of shared network folder with thousands of files, and ls is significantly slower than dir
my questions at last:
am i doomed to use PowerShell? i guess i will, reluctantly, if i have to
is there a simple pre-packaged "slim" cygwin installation.. or, portable cygwin, even better? there is a cygwin-portable project on sourceforge, but it's not that doesn't need those manual steps, again, apparently - is there a way to automate those steps, perhaps? and if there is, i wonder why somebody hasn't done it already? - and then, would it be possible to call bash scripts from Windows command prompt using a simple command like "bash somescript.sh"?
thanks for your attention.
As mentioned here, the Cygwin installation can totally be scripted and parametrized to ran in a silently and automatic mode.
If you define the minimal list of cygwin packages you need, just use a little .bat script that call the cygmin setup executable like this
setup.exe --packages=list_of_packages_you_need --quiet-mode
If you wrap the cygwin install process, it should be tolerable for a less technical user.
The cygwin install can be streamlined using command-line args;
http://sources.redhat.com/ml/cygwin-apps/2003-03/msg00526.html
You can also automate the install of most cygwin packages through cyg-apt.
I haven't verified this but I suspect that msys implements a *nix look alike by creating windows executable versions of system commands. All of the common commands have an executable on my install of msys. If that is true then it should be possible to use them separate from a complete install.
Try copying "bash.exe", "cp.exe", etc. from the msys bin directory to a machine/vm that does not have an msys install and see if it works. You may need to copy some dll's or shared libraries as well. A windows dependency checker program would show which dll's an executable is using.
You could package up the stuff you use and make a simple installer or just copy the files with your scripts.
Take a look at MKS Toolkit. Unlike Cygwin, it can live within the Windows world. Files end in CR/LF like Windows files, and you don't have that /cygdrive/c stuff. Naked drive letters work fine in MKS Toolkit.
A few caveats:
I haven't used MKS Toolkit in a long time. See following reason.
MKS Toolkit is (sit down for this) $600 per license. Ouch! That's why I use Cygwin even though I don't think it's as good or works as well.
It's Kornshell based and not Bash (although this may be a bit different). Kornshell and BASH are 95% alike. However, that last 5% gets you. I actually like Kornshell better than BASH in many respects. Kornshell has the print statement which is way superior than the echo statement. Variable names don't disappear in blocks. You can easily do double loops because almost all the commands can take unit numbers of input and output. However, Kornshell doesn't have those neat escape characters in the prompt, and it's hard to find the exit status of a command in the middle of the pipeline.

Clojure REPL from USB drive

I'm trying to learn Clojure at the moment, but off to my parents this weekend. They have a Windows laptop, but I don't want to install anything...so is it possible to run a Clojure REPL solely with files installed on a USB drive?
The best portable clojure "environment" that I have come across is Lisp Cabinet.
It gives the option of multiple lisp environments, but you can choose to just have a clojure environment. It is a little dificult to discern from the website that it's portable, but the installer gives you the option of installing everything in one folder for a completely portable experience.
Edit: As for a repl, when you launch it, Lisp Cabinet gives you an emacs slime REPL for the environments that you choose (that would probably just be clojure).
Sure, absolutely this will work. If you install both Java and Clojure onto a flash drive, it will work just the same as if you installed it onto a normal hard drive.
As this blog post recommends you can set up a clj.bat file:
#ECHO OFF
java -cp clojure.jar clojure.lang.Repl
Just keep in mind that your parent's laptop won't have any environment variables set (i.e. PATH), so depending on where everything is located, you will need to tweak it to make sure java is recognized, and clojure.jar is on the classpath.
You could also install leiningen on the USB drive. Then call
/path/to/USB/lein.bat repl
Enjoy!

Do the vi and emacs implementations for Windows behave like their Unix counterparts?

If not, what are the significant differences?
Edit: Daren Thomas asks:
which ones?
I use gvim on Windows and MacVim on the mac. Seem similar enough to be the same to me...
By which ones, I'm guessing that you mean a specific implementation of vi and emacs for Windows. I'm not sure as I thought there were only one or two. I'm looking for the ones that are closest to the Unix counterparts.
I use GNU emacs built for Windows, and have found very few, if any, differences. There's the option to load your .emacs file from _emacs or .emacs (although .emacs works fine on XP and above). You can configure it to use Windows-style or Unix-style line endings by default (which I suppose you could do on a Unix system too...).
You may want to tweak such settings as Emacs's startup directory and home directory. To do the former, modify the shortcut that starts emacs. To do the latter, add a HOME environment variable - this will control where your .emacs is loaded from. For more information, check the always-excellent EmacsWiki's MsWindowsInstallation page.
which ones?
I use gvim on Windows and MacVim on the mac. Seem similar enough to be the same to me...
GNU Emacs has long been working natively on Windows as part of the main source, and can be compiled with Visual Studio (you can also find some pre-compiled binaries). As far as I know, there are no significant differences.
There are quite a few vi clones (e.g. vim) and also various Emacs implementations (Gnu Emacs vs. XEmacs spring to mind).
These clones differ on Unix themselves and will thus also differ on Windows.
One thing I found with vim is that the directory structure for plugins etc. is very different on Windows - ~/vim.rc translates to %HOME%\vim_rc (or similar, depends on stuff I don't understand), vim tends to save stuff like plugins under C:\Program Files\vim\... instead of ~/.vim/...
The Windows versions typically use the same base source code as the "regular", Unix-based versions. There may be sections of the code that are specific to Windows, just as there are sections specific to certain flavours of Unix. In general, though, the Windows versions of these packages will behave identically to the Unix ones, except where this is not possible (for example, gvim in Windows will use Windows GUI elements, of course).

Resources