Using ~/.guile, the functions in money.scm are available automatically in guile REPL.
>cat ~/.guile
(use-modules (ice-9 readline))
(activate-readline)
;(load "money.scm")
;(use-modules (money))
then how can i config the clisp REPL ?
BTW,
are there any "http://try-clojure.org/" similar site ?
Sincerely!
From the GNU Common Lisp man page:
Normally CLISP loads the user “run control” (RC) file on startup (this happens after the -C option is processed). The file loaded is .clisprc.lisp or .clisprc.fas in the home directory USER-HOMEDIR-PATHNAME, whichever is newer.
Related
Well the idea goes as followed,
I have a bash file for linux, there I obviously run it by making ./my_run.
The problem is I'm in windows so I downloaded and installed cygwin.
I added cygwin bin to the Enviromental Variables and check that at least "ls" works so I guessed I did it well.
When I try to run it with the cmd it displays:
'.' is not recognized as an internal or external command,
operable program or batch file.
As if the cygwin variables were not correctly installed (as I said I tried ls and works).
Then I tried it directly with cygwin and when doing the ./my_run I got it to work right.
So how is that I can use some commands like ls but when doing ./ it doesn't work on the cmd? How can I fix this?
Well, cygwin is only a shared library and a lot of stuff (the programs) using it (read Cygwin doc). cygwin.dll changes internally path resolution / chars to allow you to say ./my_script and converts it to .\my_script before doing the actual windows call, it also adds the proper extension to executables to allow it to execute windows binaries. This magic persists as long as you use it. cmd.exe is a Microsoft Windows command shell that is completely unaware of Cygwin's shared library and by that reason it doesn't use it, so it will not call it for path translation, even if you populate the environment of zetabytes of stuff. When you run in Cygwin terminal, you are running bash shell, which is a Cygwin executable, linked to cygwin.dll. It manages to use Cygwin library for all the unix system call emulations, so when you pass it e.g. to exec("./my_script", ...);, it internally converts that to try for ./my_script, then .\my_script, ./my_script.exe, ... and the same for .com and .bat extensions.
This fact often makes some people to say that Cygwin is not a good, efficient, environment. But the purpose was not to be efficient (and it is, as it caches entries and makes things best to be efficient) but to be compatible.
In your example ls is a Cygwin executable that mimics the /bin/ls executable from unix systems. It uses the Cygwin library, so all path resolution will be properly made (well, under some constraints, as you'll see after some testing) and everything will work fine. But you cannot pretend all your Windows applications to suddenly transform themselves and begin working as if they where in a different environment. This requires some try and error approach that you have to try yourself. And read Cygwin documentation, it is very good and covers everything I've said here.
If you open up Cygwin and run the command there you should be fine.
recently, i try to compile a gnu wget from source code in cygwin environtment that pop-up error if perl is not found. otherwise, perl is installed both perl and perl5 on /bin/ but the wget is try search perl on /usr/bin. i think i have missed basic ./configure to setup path executable. so my question is basic.
what is it all about options on below:
*
--bindir=DIR
--sbindir=DIR
--libexecdir=DIR
*
Thank you
These options specify directories where a software package being compiled is going to be installed. As far as I remember it doesn't deal with checks performed by configure. Make sure that perl is in $PATH. If nothing helps, try to locate the exact place in the configure script (usually it's robot-generated and not intended for human eyes, but afterall it's a shell script, and anybody can read it) and see what checks exactly are performed to locate perl.
Update: I have checked, the tests corresponding to perl look like this in configure.ac (which essentially is a "source code" for configure):
AC_PATH_PROGS(PERL, [perl5 perl], no)
AC_PATH_PROG(POD2MAN, pod2man, no)
This means that PERL with executable named perl5 or perl (somewhere in $PATH) is checked, and then POD2MAN with executable pod2man. Carefully check the configure output and config.log file and see what tests have failed.
Update2: The third argument of the AC_PATH_PROG and AC_PATH_PROGS is value-if-no-found. Also you may specify the fourth argument, $PATH for this particular check. Make sure that configure gets rebuilt after you changed configure.ac (usually it happens automatically, but may be performed by autoconf explicitly)
what is it all about options on below:
*
--bindir=DIR
--sbindir=DIR
--libexecdir=DIR
The first (bindir), is where binaries will be installed. For wget, that's (on my system) /usr/bin.
The second (sbindir), is where static binaries will be installed. You might set that to /usr/sbin.
The third (libexecdir), is where your runtime libraries are to be installed. That's usually /usr/lib.
In fact, usually you let configure set all three by using --prefix.
./configure --prefix=/usr/local
I just downloaded and started using Vim so I'm still a bit confused with it. I've been watching tutorial videos and I see that I can open Vim by typing vim in command. However when I do it I get
'vim' is not recognized as an internal or external command, operable program or batch file
Did I need to install something else? Also I want to code and compile C in vim, would I need to install a compiler?
You have to invoke Vim (or gvim, the GUI application) with the full path, e.g.
"C:\Program Files\vim\vim74\vim.exe"
The Vim installer doesn't add the location to the PATH. In Windows, you can create a shortcut (*.lnk) in your Start Menu, or re-run "C:\Program Files\vim\vim74\install.exe", which has an option to install batch files to C:\Windows, or manually add "C:\Program Files\vim\vim74" to your PATH via the Control Panel.
Vim is just a (very advanced and powerful) text editor, so it ships with syntax highlighting for most programming languages, but unlike IDEs, it doesn't come with the full toolset of compiler, linker, debugger, etc. You need to separately install that (e.g. mingw, or Microsoft's compiler from the Windows SDK, or any other).
C:\>vim somefile.txt
During Vim (for Win32) install, you have the option to install batch files for launching vim from the command-line.
make sure you install vim properly. (https://www.vim.org/download.php)
On Windows. Don't forget to set the environment variables (simply add \vim\vim**; at the end of the classpath)
Type vim at command line (gvim.exe will start the Graphic user interface software).
If you want to compile and run c program using the command line, you should download the GCC Compiler and follow the same procedure as mentioned before (The classpath thing). Then you can compile C program using gcc command.
I have a project with Fortran and I use gvim as my editor. When I use gfortran as my compiler in my makefile, I encounter no problems. I also have a version of the makefile that uses intel fortran and that makefile also works fine when called from the terminal.
My problem is within gvim. Gfortran version of my makefile works great when called within vim with :make and it shows me the errors and jumps to them etc. However, when I use the ifort version, :make command in vim gives me an error saying he could not find ifort.
ifort works fine from the terminal. I have both ~/.bashrc and /etc/bash.bashrc edited so that it sources intel compilers. I use Crunchbang Waldorf (read: Debian Testing) and I remember having the same problem in LMDE.
Any help is greatly appreciated
Move PATH modifications from .bashrc//etc/bash/bashrc to .profile//etc/profile. This way you won’t need interactive shell like #ib. suggests (and, by the way, you need to do modifications to only one file, not both).
If your distribution uses /etc/env.d it may make sense to do
echo 'PATH=/path/to/ifc/binaries' >> /etc/env.d/99ifort
env-update
. But this should be distribution-specific.
I upgrade perl from perl58 to perl588 on Suse Linux.It looks that even though the Config.pm exists for the older version the newer version installation breaks the older version.While the upgrade of Perl on other OSes like HP and AIX does not disturb the older version.
For eg: The perl58 and perl588 versions are present in folder say "/usr/standard_perl" as follows:
/usr/standard_perl/perl58 (directory)
/usr/standard_perl/perl588 (directory)
and have symbolic links pointing to it.
Before and after upgrade the links are as follows:
Before:
perl58_link -> /usr/standard_perl/perl58
After:
perl5_link -> /usr/standard_perl/perl588
perl58_link -> /usr/standard_perl/perl588
perl588_link -> /usr/standard_perl/perl588
Now when i try to run simple "./perl -V" command from /usr/standard_perl/perl58/bin the older version complains of Config.pm not found even though its very well present in its own tree structure.
Is it that in Linux, perl is following a hard coded path for #INC.This kind of behaviour is observed only on Linux.
I am worried for I cannot roll to production for there are scripts that have been running for older version and if this kind of behaviour exists I would need to know if its possible to fix or this is a known behaviour of Linux.
I am not sure could this be because now the older links after upgrade is been pointed to newer version and just linking is not sufficient and need to modify something more on LINUX?
Note:
1.The perl modules are seperately maintained for each version
2.I am not mixing any of the files with previous version.
3. We want all of the old perl scripts running in production servers not to break and use latest version instead for the mainatainence of Perl versions.
3a.Hence a need to tweak the links pointing to latest version instead of their own versions.
Observation:
Only on Linux seeing this behaviour.
One point worth noting is when i twek links of older version to latest version. the #INC automatically is updated for latest version INC and not in LINUX.
Am i missing something here?
I've never seen this problem on Linux. I leave the original perl in its location (/usr/bin/perl), and simply compile my own perl to install to /usr/local/bin (or whatever), and have never seen any breakage of the old version.
You don't say
how you came to have a /usr/standard_perl/perl588 (compiled, given in rpm format or something, pre-compiled tarball, ...)
what options you used when configuring the compilation
You're also very vague with your details - perl58_link, standard_perl, etc. - where is this really? Most of the time it doesn't matter, but sometimes it does.
If you move the link back, do things start to work? If you move the entire 5.8.8 tree somewhere else, do things start to work? Can you recover your base perl from RPM or whatever to try to make it work? IMO, the base perl working is paramount, a secondary perl is always bonus. (I'd take the same opinion of other core unix tools, like shells, awk, sed, or even python or whatever your distro uses for package management. Less so for non-core tools like Java, but if I were running Java apps in production then I'd say the same here, too.)
Leave the system perl executable alone, compile your own, and have your Perl programs run using the one you compiled
All system programs written in Perl should start with:
#! /usr/bin/perl
All non-system Perl programs, user written programs:
This one will use which ever perl executable is found first on $PATH. (same as 'which perl')
#! /usr/bin/env perl
Another option is to specify exactly where the executable you want to use is:
#! /opt/bin/perl
#! /opt/perl/bin/perl
#! /opt/perl/5.10.0/bin/perl
#! /opt/perl-5.10.0/bin/perl
#! /home/$user/perl/bin/perl
#! ~/bin/perl
Or what ever the path to the perl executable is.
Never replace /usr/bin/perl with one you compiled yourself!
I did this once on Ubuntu 7.10, and it broke my system. I could login, and do most everything, but I couldn't change the appearance, for example. I ended up running 'sudo nano $filename' on every Perl program on my computer, and change them so they would run under Perl 5.10, instead of Perl 5.8.
After which I had to install Ubuntu 8.10 from scratch, when it finally came out.
You could also experience incompatibilities if you use cpan or cpanp to install modules, because they could have an incompatible feature change. And for a non-binary compatible perl executable, you have to reinstall all modules that require XSubs.
Thats why all Perl programs that I write I add the header '#!/usr/bin/env perl', and add the path to the Perl executable, to the beginning of the $PATH variable.