I love coding in Haskell, but often am on a computer where I cannot install software, and which has some restrictions about what you can run. I would like to write Haskell code and test it while on this computer. Does anyone know of version of Haskell, interpreted or compiled, written in Java, JavaScript, Ruby, Python, or another interpreted language available in the default install on a Mac? A standalone version of Haskell which can be installed at the user level works too, but compiling Haskell myself is not an option.
The GHC binary distributions (the ones that come as tarballs, not installers) all can be installed locally trivially easily.
./configure --prefix=$HOME/ghc
make install
Then update your path to include $HOME/ghc/bin
If you want cabal, get the tarball from hackage, then untar it and run bootstrap.sh.
GHC works really well as a local install. In fact, I never use it as a system install.
I do this on my workstation, too, so that the distribution I'm on (Debian in my case) doesn't suddenly start upgrading stuff without me noticing in a simple apt-get upgrade.
This solution installs a full ghc and haskell-platform as well as ~/.cabal prefix.
First of all, I have a ~/local directory that I use in order to put custom-compiled programs in my home directory. I usually dislike the sudo make install step, because I'm giving some random Makefile root access to my system, and that makes me feel queasy.
Then I download the ghc binary distribution from the ghc site. NOTE that I linked you to 7.4.2. I hear there's some segfault bug on Mac OS X, but I'm not aware of the details. You should check that out or get the newer ghc instead, but be aware that there are many packages on hackage that are not yet fixed to work with 7.6. Also, ignore that "STOP!" warning, you're the 1% who actually want a non-distrib GHC binary.
You can just cd into the ghc directory, then do ./configure --prefix=$HOME/local/haskell or so, followed by make install (no compiling necessary, it's just going to install, not compile.)
At this point, you should add ~/local/haskell/bin to your path. Here's the code that I put in my ~/.zshrc, which will add all ~/local/*/bin directories to your path.
You can then get the Haskell Platform, and do the same ./configure --prefix=$HOME/local/haskell && make && make install dance. This step will need compilation. It means that you will need some header libraries installed. I find the random openGL headers that are necessary particularly annoying.
You can also of course skip haskell-platform, and just download cabal-install directly, then install what you need. You should in any case not forget to add ~/.cabal/bin to your $PATH!
Do a cabal update and you should be good to go.
NOTE: there's one important part that the binary distribution of GHC needs, which can sometimes be a pita on old Linux systems: libgmp. It's linked dynamically against it, and if you get some errors about the shared libgmp not being found on OS X, too, you can… well, ask that question in a comment, and I shall explain how to get there. Basically, you'll have to compile libgmp + deps yourself.
But I don't think that should be a problem on OS X. It's just been a problem on a couple old debian boxes I've tried this on.
For single files, you can use codepad.
Related
My goal is to connect the open-source CBC solver with Pyomo in Spyder. I am working on a Windows 10 machine and it is not an option for me to use the NEOS server due to company policy.
I have downloaded the binaries from Bintray (https://bintray.com/coin-or/download/Cbc#files) that include a cbc.exe file. However when trying to run it, several errors come up stating that I am missing files (among other libbz2-1.dll and zlib1.dll). I do not know much about linux or software development but after a lot of time on google I understand that these are used for unpacking data among other things. I found all files except zlib1.dll in a developer chat on the same subject and zlib1.dll I found on another page. However when running I now get the error: “The application was unable to start correctly (0xc000007b).
I have also tried downloading MSYS2 MinGW and followed instructions from CBC. I don’t know if I require this or if it is only for developers.
Can anyone tell me what to do? I suspect other people than myself want to use CBC in Pyomo as an alternative to GLPK.
If you already have the .exe file, make sure it is in your current working folder (set as the working directory in Spyder, simply opening your file is not enough) and call it using the SolveFactory function:
opt = SolverFactory("cbc.exe")
results = opt.solve(model)
It works for me.
You will find some general information here where i outlined some approaches.
While this was targeted at Clp, it also applies to Cbc.
It's a bit strange as i observed too, that some libs are not statically linked (zlib) while it's certainly doable. But as mentioned in the thread, this should not be the case anymore (see the restriction about which files are fully statically linked) and therefore your observation is strange (and you did not say, which file you downloaded).
So i would trying one of the following (in this order):
Try again with your source, but stick to the master-versions (see first link) as the maintainer only guaranteed fully-static builds for those!
Use the builds from AMPL
(tested and works for me; generally recommended in terms of quality/stability of builds)
Use the builds from coin-or/pulp, another modelling-tool for python
(tested and works for me)
Compile from source using mingw64
(Use any build and provide some external dll of zlib and co -> hard to debug)
Of course i completely ignored other potential issues:
license-stuff (what's part of those builds)
not sure if a company can afford to use binaries not build themself in regards to legal stuff
version-compatibility with python
does every version of Cbc work
cbc version + configuration
modern version
compiled with multi-threading
...
Of course we all know building GCC version >= 4.1.x requires the supplementary packages MPFR, GMP and MPC to be present.
There's a few ways to handle these GCC dependencies:
1) Download and build each supporting package separately and then tell make where the binaries are located during GCC build time.
2) Download each supporting package, untar and move the source into your GCC build directory and make will automatically build each of the packages when needed.
(Executing the gcc-src/contrib/download_prerequisites script does the same as option 2)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Is there an advantage to either method? Does pre-compiling the binaries provide something I'm missing by taking the "easy route" and just dumping the package's source into my GCC build directory and letting make figure it out?
I've seen it done more frequently in various build scripts by pre-compiling each package to a binary, and then telling make where they are located during gcc compilation. Is this the "preferred" way to do it? Why?
To add context, I'm mainly building cross-compilers targeting various ARM platforms.
For most use cases I believe that option 2 is just as good as option 1. However, I can see a few situations in which one would want to do it manually.
A package maintainer wants to build separately as they want separate packages for mpfr et al.
Someone who wants to pass different configure arguments/CFLAGS to each of the packages.
A GCC developer who wants to keep their source and build trees small as they don't make any changes to MPFR/GMP/etc.
I haven't done too much work with the (rather ugly) GCC build system, but I haven't seen any obvious differences in how the binaries are built.
I'm not the biggest authority on this though, so YMMV; I may be wrong.
I can't stand XCode, but really love OpenFrameworks, and I know it works on Linux+Win32 so I don't see why it should be XCode dependent. If I need to have XCode installed that's fine, I just don't want to use it at all.
Xcode internally uses gcc/llvm. in fact from the command line you can cd into a directory that contains an openFrameworks project and just type xcodebuild. but this won't allow you to edit the project file and add new source code, etc.
the Linux makefiles could be adapted to work on OSX as well. they already contain a lot of the information necessary about finding the correct source files, library paths etc. however Linux allows us to install many more components as shared system libraries, while on OSX we link most of the libs statically, so a number of extra library paths would need to be added. probably the biggest gotcha is that everything has to be compiled 32 bit, which means passing -arch i386 everywhere, so you can't just install dependant libs using Homebrew or MacPorts. we are in the process of transitioning to 64 bit but there are still some QuickTime calls that require us to stick with 32 bit, mainly around accessing legacy video capture devices that a lot of us still use for computer vision.
like #cdelacroix points out, we only maintain Xcode project files on OSX. this is mainly due to the lack of a decent alternative. there is a version of Code::Blocks for OSX but it is not very well supported, has some issues with native gui rendering and tends to lag behind the other platforms. Xcode is also the easiest way to install a toolchain on OSX so for most users installing Xcode is necessary.
if you do get a makefile based build system working, and would be interested in maintaining it medium to long term, please consider contributing it to the GitHub repository, it would be gladly accepted.
As of March 2013, openFrameworks has official makefile support for compiling the library itself. However, at the time of this writing, the changes haven't yet been merged into the stable release. You'll need to clone the Git repository and switch to the development branch.
git clone https://github.com/openframeworks/openFrameworks
cd openFrameworks && git checkout develop
cd libs/openFrameworksCompiled/project
make
As far as I can tell, we still need to use the unofficial solutions for compiling apps against the library.
You need Xcode, or at least a set of compilers (more information is available here), but otherwise, no, you can edit/work with the code in whatever editor or environment you want.
Here's a link to a makefile which will compile an OpenFrameworks application on OsX:
https://gist.github.com/labe-me/1190981
Place the makefile in the apps' directory and run make. Tested on OsX 10.6, but haven't tried with addons yet.
As #mipadi said, there is no requirement to actually use Xcode, you can do pretty much everything you do in Xcode with make or cake or any of your build system of choice. All you have to do is find the right set of command line options to pass to the usual tools (compiler, linker, strip, etc.), and sometimes the easier way is to... look in the Xcode build window how it is doing stuff (expand the lines with the small button on the right of each line).
For example you can link with your framework of choice with ld -framework Framework -FPathToFramework foo.o or your dynamic library with ld -lLib -LPathToDylib foo.o. You might have to learn about #rpath, #loader_path and install_name_tool to ship a self-contained packaged application.
As for OpenFrameworks, the "requirement" for Xcode is that the authors decided to maintain only Xcode project files. I just looked at how they do it, they ship source code and Xcode project files that build static libraries, so it will be even more simple for you (although you will need to link the library dependencies by hand). You will have to choose between compiling everything from source in your build system (if you want more customization power without touching Xcode), or just produce the 2 static libraries (openFrameworks.a and openFrameworksDebug.a) with Xcode once, then use them in your build system (recommended until you really need continuous customization).
What are the things I need in my install and uninstall targets in a Makefile for an OCaml library in order to make it play nicely with the rest of the installation, work seamlessly with ocamlfind and so on? Basically to be a "good citizen". I am not interested in GODI at the present time. Thanks!
META files for ocamlfind are easy to write (basically, look for a META in another ocaml project you know¹, copy it and make the corresponding changes), and they will give you ocamlfind integration, with in particular easy support for post-build installation and desinstallation (using ocamlfind install and ocamlfind remove). You should begin with that.
¹: for example I take inspiration from batteries's META.
The building part of the Makefile is more tricky, their are numerous solutions (OCamlMakefile, OMake, ocamlbuild, plain Makefile, etc.) with varying strenghts and weaknesses. If you project is simple enough I would recommend ocamlbuild that takes care of a lot of the dependency tracking by itself.
You may also use Oasis, which is a relatively new tools that builds on ocamlbuild and ocamlfind and seeks to provide a unified configuration file for pre-build configuration and various building and deployment (of your program, your software libraries if any, accompanying data or documentation...). It's not yet a mature project (and its little brother Oasis-DB isn't released yet), but I encourage you to give it a try if you have time. It's a bit more complex than META, as it does more in the end, so building the META first is still a good step.
Finally, you said you weren't interested in Godi (Godi is a very good system, and in some cases (eg. BSD etc.) it's a premium choice to have a good OCaml installation), but in case you may still be interested in Godiva, a tool to help the building of GODI packages. I have never used it myself, though.
I don't use makefiles but ocamlbuild and a shell script to install the software I distribute. Debian people did packages for my software with these scripts without problems. So you may want to check them out since they correspond to some of their requirements (e.g. separate targets for byte and native code).
You may also want to have a look
to their packaging policy, though I don't know if this document is still up to date.
Don't forget to add a META file for ocamlfind. And you may also want to include an _oasis file for the upcoming oasis-db project (not yet done in the software I distribute).
When compiling from source, I never know which configure flags to use to optimize the compilation for my environment. Assume the following hardware/OS:
Single Core, 2 GHz Intel
512MB Ram
Debian 4
I usually just go with
./configure --prefix=/usr/local
Should I be doing anything else?
I always use Debian packages. Compiling from sources can break your development environment during libraries conflicts and such problems are hard to detect.
You might want to check those few options out, which may be required by a Ruby On Rails environment, in which case they should be compiled. Just make sure the directory corresponds to your current settings.
--with-openssl-dir=/usr --with-readline-dir=/usr --with-zlib-dir=/usr
I recommend mixing in a few packages from Debian Unstable feeds. They tend to be pretty stable, despite the name. They're also very up to date.