Is there something similar to the Python utility virtualenv or Ruby utility rvm?
I want to switch SBCL to Clozure CL, for example.
Management of software systems would be done by something like ASDF (define software systems and actions for them) and Quicklisp (downloading of software systems via central registration). AFAIK it does not deal with multiple versions of a software systems, such that you can say which version to load. Using different Lisps with the same library should work, since each Lisp usually has a different file type for compiled code (and/or uses a different directory for the compiled code).
It's not "fully" in the sense of rvm. But the slime software has support for nearly any Common Lisp. You start in emacs with M-x lisp-you-want.
I'm not fully sure if Clozure CL is supported. Anyway the homepage of SLIME is at:
http://common-lisp.net/project/slime/
What it does not support is the installation of diverse Common Lisps. You either install them manualla or via your package management software (e.g apt in Debian)
Related
I want to use any of the FLOSS implementations of MPI (i.e., OpenMPI or MPICH2) with my MSYS-MinGW environment and compilers. Please consider that I'm aware of the Microsoft MPI SDK mingw64/mingw-w64-x86_64-msmpi which you may find with
pacman -Ss msmpi
and install with
pacman -S msmpi
but I want to know if I can install any of the open-source implementations. I tried searching
pacman -Ss mpi
but there are too many results to check manually, and openmpi or mpich2 search queries do not return any results. So my questions are:
are any of the FLOSS implementations of MPI shipped with MinGW or MSYS2
if not how one can install them?
P.S.1. Cygwin does have some openmpi related packages, so it is a wonder why MSYS2, AFIK being a Cygwin fork, doesn't!
P.S.2. MPICH2 binaries are available here but they are way way behind the latest builds for other platforms. That's just sad!
P.S.3. Surprise that Microsoft's MPI implementation is actually open-source! It seems to be a fork of MPICH or at least compatible with it.
MSYS2's main objective is to provide you with an environment to build native Windows applications.
As such, it's natural that it will export bindings to the native Microsoft MPI implementation, while not providing ports of other MPI implementations such as OpenMPI or MPICH which have dependencies on a full POSIX layer.
From How does MSYS2 differ from Cygwin:
MSYS2 tries to provide an environment for building native Windows software. MSYS2 provides a large collection of packages containing such software, and libraries for their development. As a large portion of the software uses GNU build tools which are tightly coupled to the unix world, this environment is also POSIX-compatible, and is in fact based on Cygwin.
Cygwin tries to bring a POSIX-compatible environment to Windows so that most software that runs on unices will build and run on Cygwin without any significant modifications. Cygwin provides a large collection of packages containing such software, and libraries for their development.
There are more details on that page on how MSYS2 leverages Cygwin and a POSIX-compatible layer mainly to offer ports of tools needed in a build environment, mainly to support POSIX-like build systems (such as autoconf, make, meson, etc.), while mainly aiming at exposing these tools to support building Windows native binaries and porting applications to run natively on Windows.
we have a old AIX server and it has an executable file and we want to rewrite the same logic of the executable file on linux server, so we are trying to read it but could not find a way to do that.could you please let us know if there is a way to decipher this file
$ file execfile
execfile: executable (RISC System/6000) or object module
The IBM RS/6000 has a POWER architecture CPU, possibly a PowerPC 603 or PowerPC 604, or possibly one of the newer models like POWER1, POWER2, POWER3, etc. The most recent (current) systems use POWER7 or POWER8.
Anyway, if the system has the compiler and toolchain installed on it then there should be a decent symbolic debugger included, and you should be able to use that to disassemble any executable. Depending on exactly which version of the OS it was compiled on, and which compiler was used, you might even be able to use PowerPC tools on some other OS, such as MacOS, or even potentially a cross-compiler toolchain on any type of system, to disassemble the program. For example GDB built for PowerPC may be able to disassemble the program.
However if the executable has been stripped of symbols (as was typically the case on AIX systems, IIRC), and especially if it had been run through the most powerful optimizing stage of the compiler, then you'll be pretty much lost and what you are trying to do will be impractical and require many man hours to decipher -- indeed many thousands of man hours for any significantly sized program, even if you're able to hire someone to help who is familiar with the code generation patterns of the particular compiler which was used.
You might be better off trying to hire an archeologist to help you dig through the specific landfill where you might hope to find listings or backup tapes or CDs or disks containing the original source code, or specification documents, etc., for this program. Seriously.
Or try to find and (re-)hire the original author(s).
I had this question on my exam, now in diagrams I saw, we have : hardware, kernel, system call interface to the kernel, then (compilers, shells, sys.libs) and on top some applications. Does OS scope include only kernel, and everything else is just some additional functions we choose to install , or does a Unix OS include everything from the list I gave above?
OS have more or less 2 definitions :
academic : OS is soft for doing a abstraction layer between
hardware and software
pragmatic : OS is soft that come with hardware when we buy it.
Compiler and shell don't enter in definition 1. It can be enter in definition 2.
And usually, users that are interesting by a compiler or a shell prefer to consider OS as asbtraction layer (academic definition).
Simple answer, No. They are not an internal part of Unix but additional functionality to help make the Operating System more usable.
The OS scope applies primarily to the kernel only.
Whilst you need a compiler to build the kernel, you don't necessarily require one for the general day to day use of the system. Most operating systems don't ship the compiler by default and instead, the kernel and applications is built on one machine and then the resulting binarys are packaged and distributed either with the computer directly (Windows/Unix) or via the internet for others to download and install (Linux/BSD)
Likewise with the shell. Although all operating systems ship with a default one (sh/bash/dash on Linux|Unix systems, Command Prompt/Powershell on Windows), most general users can go their entire lives without using it.
Having said that, if you were to delete the shell, you'll almost certainly find your system won't boot up. This is because a lot of core start-up scripts rely on the shell to stop / start the services presenting interfaces between the user and the kernel.
In summary:
You need a compiler to build the kernel and applications but not for running the OS.
You need a shell to execute applications (which also includes the compiler)
On windows applications are typically packaged as MSI, on Redhat Linux as RPM, what would be a best open source packaging method that could be used to deploy applications to all platforms including different flavors of unix and windows?
Contents would include exes, unix binaries, java jar files, user data, even database scripts to be run.
(I recognize contents would vary per destination OS, ie. binaries would be different, win exe vs unix binary etc, but for example config files may be the same or in the case of java even the bytecode jars)
Key feature I'd like the packaging to support is different users and permissions for different directories, however I recognize supporting this feature multiplatform may be very difficult.
Rather than build a package that is supposed to work across all of your platforms, which is likely impossible, you should have your build system build different packages for each target platform.
With CPack (It come with CMake) you can create packages for Windows (with NSIS), Linux (rpm and deb), and OS X with "make package". CMake also simplify cross-platform building.
For a sample you can look at avogadro's CMakeLists.txt and AvoCPack.cmake
I have a client that uses IzPack to create a single installer (it's Java-based) that installs their app on Windows, OS X and Linux.
http://izpack.org/
NSIS is an open-source solution which, as far as I know is able to build installers that run on Windows and UNIX-likes alike. However, for software deployment on Windows (especially in corporate environments) MSI is the way to go and NSIS is more of a headache.
So I wouldn't advise that you try to build a single package/installer for different platforms. But rather, as RibaldEddie indicated, multiple packages: one for each platform. That also allows to restrict the contents of the package to the files relevant to each platform.
If you'd like to support packaging for multiple distributions, I'd suggest helping the packagers for those distributions out; use some sort of well-known build system for your software (GNU's autotools or something like scons or waf), and document the build, optional dependencies, and so forth pretty well.
That way, when a Debian, Ubuntu, Red Hat, SuSE, whatever, packager comes along, they'll be able to create the package for you. You can optionally include packaging templates for one or more distributions in a separate VCS tree that is available, if you'd like.
If you are looking at packaging a closed-source/proprietary application for multiple systems, you'd probably do best to package up a .tar.gz file and document the installation process for it. You'll also want to make sure that the build process used doesn't embed any path information into the application, so that it can be run in /opt, /usr, or /usr/local, which are some popular choices for third-party add-on software.
BitRock InstallBuilder allows you to create installer packages for each one of the platforms you mentioned (as well as creating RPM, DEB, packages etc. from a single project file)
I've already got slime+emacs+sbcl running (SBCL 1.0.23) on my Windows XP machine. CUSP installs with SBCL 1.0.6.
Is there a way to make CUSP use the existing SBCL installation instead of its own?
You can, I don't have it installed on this computer; but in the options (maybe preferences) section (where Java, Lisp, and other tabbed panels to the left are listed) there is a sub section under Lisp called implementation.
In that section you can select which SBCL binary to use and which image file to load. It doesn't work with the latest SBCL implementation (At least as far as I know).