I have a Cython extension which I've compiled on Ubuntu 14 and uploaded as an Anaconda package. I'm trying to install the package on another machine which is running Scientific Linux (6?) which ships with an older version of glibc. When I try to import the module I get an error that looks (something like) this:
./myprogram: /lib/libc.so.6: version `GLIBC_2.14' not found (required by ./myprogram)
When I say "something like" - the "myprogram" is actually the .so name of the extension.
From what I understand this error is because I have a newer version of glibc on the build system which has an updated version of the memcpy function.
This page has a good description of the problem, and some rather impractical solutions: http://www.lightofdawn.org/wiki/wiki.cgi/NewAppsOnOldGlibc
There is also a much simpler answer proposed here: How can I link to a specific glibc version?
My question is: how to I apply this solution to my Cython extension? Assuming the __asm__ solution works (as given in the second link) what's the best way to get it into the C generated by Cython?
Also, more generally, how to other modules avoid this issue in the first place? For example, I installed and ran a pre-built copy of numpy without any issues.
This turned out to be quite simple.
Create the following header, glibc_fix.h:
__asm__(".symver memcpy,memcpy#GLIBC_2.2.5")
Then include it by using CFLAGS="-include glibc_fix.h". This can be set as an environment variable, or defined in setup.py.
Additionally, it turns out numpy doesn't do anything special in this regard. if I compile it myself it links with the newer version on my system.
I want to know about modular programming in tcl and how we can achieve that .
In some tcl tutorials mention like source command having some drawbacks in achieving "modularity" so that we came to the "package" after that "package" is having some more drawbacks so that we came with the combination of package and namespaces .
I want to know what are the drawbacks and proper hierarchy of 3 concepts . Can Anyone help me ?
I'm not sure if I understand your question correctly, so I'll try to explain the 3 commands you throwed in your question:
source: Evaluates a file as a Tcl script. -
It simply opens the file, reads until the EOF character (^Z on both windows and *nix) and evaluates it.
It does not keep track of sourced files, so you can source the same file again (great for hotpatching), but this is the drawback: It will source the file again.
package: Manages packages. It basically keeps track of the provided packages and tries to figure out which file it has to source to load a new package.
namespace: They provide context for commands and variables, so you don't have to worry about unique names for your commands. Just the namespace has to be unique. Has nothing to do with loading packages or other modules, it just provides namespaces.
I suggest that you use packages, each package in it's own file, each package with a namespace equal to the package name where all commands reside.
You should export the public commands with namespace export.
I've just started using IPython for interactive development and exploratory research, which I've found really exciting with all the cool features and possibilities. I am using the Anaconda package manager to manage dependencies, which includes IPython.
From what I've read, one goal of the IPython team is to eventually integrate Sage Math (CAS) into IPython, as a cell magic. Does anyone know if this is still under development? Or rather, if I wanted to use Sage now, is writing an extension the only way to do this [1]?
[1] https://github.com/ipython/ipython/wiki/Extensions-Index
Also, if I install additional packages for scientific development, not included in the Anaconda distribution, is that as easy as just pip or do I have to go through a Anaconda package build to handle dependencies and such? If I were only using IPython, I could understand just doing easy_install or pip as recommended in the docs, but I believe that overwrites existing dependencies within Anaconda. If I use pip, how does that affect Anaconda dependencies if I do not install in an Anaconda environment, which I take is the equivalent as virtualenv.py, and is this the way to also set up revision control (i.e. Mercurial)?
To clarify, I do not want to run IPython from within Sage, I want to run Sage, as a CAS, from within IPython. I'd rather go the Sage approach of integrating domain specific languages. Or in contrast, will IPython extensions replace Sage?
I'm a self taught programmer, not a professional software developer. As an engineer, I am used to Matlab, Mathematica, and commercial solutions, that allow me to abstract away the plumbing. I'm trying to wrap my mind around getting everything glued together, but it's like a mix of spaghetti soup and a dynamic link library, due to lack of knowledge. I'm probably using the wrong approach.
What I want is Anaconda/Enthought package management (IPython, pandas, etc..), custom rolled Sage through hooks/extensions or magics, extensions to packages not included in Anaconda (i.e. Matlab see [1] above), and revision control with Git and Mercurial. How would professional developers set this up on a Mac or Linux box?
Answering the first question:
Sage is a huge collection of mathematical software, including IPython. There's no way we'd integrate all of that into IPython.
Possibly what you've heard is that we're going to integrate Sage-style 'interacts' into IPython. That's where you have a slider to control the value of some input variable, and the output updates as you move it around, based on a calculation written in Python. That is still on our roadmap to add to IPython.
Another possibility is that you're thinking of SymPy, a Python-based CAS. SymPy works well within IPython, especially if you call sympy.init_printing() to get the fancy representations of expressions.
I wrote an IPython extension to load Sage customizations into the IPython notebook---in fact, that's how many of the customizations to IPython are done for the normal Sage interface. It basically turns the IPython notebook into an interface to Sage (e.g., preparsing is done, etc.).
You do need to run it from Sage's copy of IPython, though. Just start the IPython notebook:
sage -ipython notebook
and then load the sage extension in a cell:
%load_ext sage.misc.sage_extension
Pretty soon we'll upgrade to IPython 1.0 (I've made the changes necessary, and it needs to be reviewed). If you want to run IPython 1.0 already, email the sage-support mailing list and I'll post instructions.
To answer your other question, Sage includes many packages that are not available in Anaconda. Sage depends on these packages heavily for many features. I suppose there is a possibility getting Sage and its dependencies distributed with something like Anaconda, but no one is working on that as far as I know. There is some work on packaging Sage up for different linux distributions and replacing the package manager for Sage.
To clarify, I do not want to run Ipython from within Sage, I want to run Sage, as a CAS, from within Ipython. I'd rather go the Sage approach of integrating domain specific languages. Or in contrast, will Ipython extensions replace Sage?
If you want to run Sage within Ipython, the easiest thing to do is to use Sage's copy of Ipython:
$ sage -ipython
Python 2.7.5 (default, Aug 1 2013, 18:11:00)
Type "copyright", "credits" or "license" for more information.
IPython 0.13.1 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help -> Python's own help system.
object? -> Details about 'object', use 'object??' for extra details.
In [1]: from sage.all import *
In [2]: integrate(x^2,x)
---------------------------------------------------------------------------
NameError Traceback (most recent call last)
<ipython-input-2-006357f5d9c0> in <module>()
----> 1 integrate(x^2,x)
NameError: name 'x' is not defined
In [3]: var('x')
Out[3]: x
In [4]: integrate(x^2,x)
---------------------------------------------------------------------------
RuntimeError Traceback (most recent call last)
<ipython-input-4-006357f5d9c0> in <module>()
----> 1 integrate(x^2,x)
/Users/.../sage-5.11.rc0/local/lib/python2.7/site-packages/sage/structure/element.so in sage.structure.element.Element.__xor__ (sage/structure/element.c:6754)()
RuntimeError: Use ** for exponentiation, not '^', which means xor
in Python, and has the wrong precedence.
In [5]: integrate(x**2,x)
Out[5]: 1/3*x^3
Note that there are some differences between this and Sage - for instance, there is no preparsing of the syntax. Presumably if you had Sage someplace your own installation of Ipython can find it, you could do this there too (though there is no easy_install and the Python versions might not match correctly!).
Please observe that Sage, as it currently is and should be in the near future, is a huge package that runs in POSIX (Linux-like) OSes only. If you intend it to run in Windows you must use VirtualBox with Sage running under a VM.
If you want a simple CAS that is simple to install and runs everywhere that Python does, you should consider taking a look at Sympy. It doesn't interact with all the software that Sage does, but is simple to use, lightweight (no external libraries needed) and is already included in the base Anaconda distribution.
Besides, it can be easily used inside other Python programs, since it's just like any other module and doesn't make changes to the Python syntax.
I've installed the Yojson library for OCaml via GODI:
http://martin.jambon.free.fr/yojson.html
I want to start an interactive ocaml session (i.e. via the ocaml command) and execute functions from the Yojson library e.g.
Yojson.Safe.from_string;;
How do I do this? The above command gives "Error: Unbound module Yojson". I've worked out how to compile via ocamlc with Yojson available, but I want to launch an interactive session instead.
I know this seems like a horrible beginners question but Yojson comes with no samples and minimal instructions so I'm really stumped. I've tried various combinations of "#load" and compiler switches and I'm stuck.
The tool you are after is called findlib. It is included in the base GODI installation. The tools that come with findlib allow you to easily compile against most OCaml libraries and use those libraries from a toplevel session (ocaml). The findlib documentation is fairly comprehensive, but here is a quick summary to get started.
To start using findlib from within a toplevel session:
#use "topfind";;
This will display a brief usage message. Then you can type:
#list;;
This will show you a list of all of the available packages. Yojson will likely be among them. Finally:
#require "yojson";;
where yojson is replaced by the appropriate entry shown by #list;;. Yojson's modules should be available for you to use at this point.
I'm trying to translating the MySql C connector 6.02 headers to D, but I get some weird crashes.
My guess is I've made some mistakes on translating the structs or function (I'm not very good at C).
I used implib /system on the libmysql.dll to create a lib file.
I couldn't get htod.exe to work. Using -hs (include system files) complained it couldn't find system files.
Coffimplib.exe didn't have an option to prepend _ to exported internal names.
I couldn't find a free version of coff2omf.
mysql.d is the wrapper. I've included the C definition before each wrapped definition to easier spot bugs. The file includes the mysql dll and converted libfile too.
When compiling mytest_fails.d it crashes. mytest_works.d only has an assert, and this makes it work.. Compiling mytest_works with -release makes it crash too.
I've been using dmd 2.051
Download mytest.zip from share1t.com
Update: I've also asked some question regarding this on the D.learn newsgroup, but I don't think anyone has gone through the code.
C Const
Compiler extensions
Connot get htod.exe to work
The weird crashes
stdcall is a Windows function calling convention (very different from the C calling convention). HTOD failed to mark several functions with extern(Windows). This is normal, since HTOD isn't equipped to handle macros (STDCALL is defined as a macro, I can see that from the leftover comments in msyql.d).
Here's an updated mysql.d file:
http://dl.dropbox.com/u/9218759/mysql.d
Now, you need the proper import library in OMF format. I'd generally advise that you do not use implib for this. I've had several problems with it and others have reported having problems using it. Using coffimplib is the way to go. But first, you will need a COFF import library.
If you need it, the Mysql release with the COFF import library can be downloaded from here: http://dev.mysql.com/downloads/mirror.php?id=377977#mirrors (Libraries in DLL form marked for Visual Studio usually come with a COFF import library).
But I'm providing you the translated COFF import library in OMF format here: http://dl.dropbox.com/u/9218759/libmysql.lib
I've tried both of your test cases and they both seem to work fine now. In case of problems, try to check the translated header file again (mysql.d), it's possible that I might have missed to specify all the calling conventions properly.