How to determine location of executable dump - sbcl

I am dumping a new interpreter written in CL with SBCL, and need to determine the location of the binary (executable sbcl dump) to set up some search path. Is there a way to find out how?
I tried *core-pathname* but it seems not to be defined in executable dumps.

Ok, after some digging I think I found the answer myself! It is:
sb-ext:*core-pathname*
which works! Strange that this is not mentioned in the SBCL manual.

Related

Setting `sql-mysql-program` in emacs

There are at least three major overviews that come up when searching for information on using sql with emacs (due to my insufficient reputation I can't 'afford' to link to them here).
I can find no mention in any of them of the need to set the variable sql-mysql-program when working with mysql servers. Yet I could not get M-x sql-mysql to work without following the advice from this SO question to set this variable as follows:
(setq sql-mysql-program "/path/to/your/mysql")
In fact, the only tutorials/documentation I've seen highlighting this variable are in the above SO question and another SO question about "emacs-how-to-use-ssh-tunnel-to-connect-to-remote-mysql" (which again I can't link to because of insufficient reputation.)
An alternate solution seems to be suggested here How to work with emacs and mysql, which suggests changing the value of the emacs exec-path.
The question is, which of these options is preferable, or is it simply a matter of taste?
And what is the significance of the fact that none of the above-linked overviews of sql/emacs mentions the need to get emacs to recognize the binary? Is there something wrong with my emacs?
I spent a long time combing the sql.el source to try to understand what was going on and I do see a (defcustom sql-mysql-program "mysql"…)but in my case at least that did not seem to do the trick (perhaps because I'm starting emacs up with -q option?).
PS. In case it matters, my M-x emacs-version is GNU Emacs 24.5.1 (x86_64-apple-darwin12.5.0, NS apple-appkit-1187.40) of 2015-05-01, which I am running on an older Mac (10.8.5)
Note that this can be generalised to a question of:
What do I do if Emacs can't find an executable?
which is where the exec-path list comes into play.
As noted in C-hig (emacs) Shell RET, the exec-path list is initialised from the environment variable PATH when Emacs is started (see also (emacs) General Variables), so there are multiple ways to populate that list with the values you need.
Using an absolute path to sql-mysql-program is also fine, but potentially less portable. It's up to you, really.

Where can I find itkScalarImageTextureCalculator

I am trying to run a piece of code that includes "itkScalarImageTextureCalculator.h". However, cmake cannot find this reference, and I can't seem to find it manually neighter. I've looked for it in
Modules/Numerics/Statistics/include
Modules/Compatibility/V3Compatibility/include
Modules/Compatibility/Deprecated/include
but i can't find it anywhere. A search in the itk folder also returns no results. Was this library deleted/renamed/moved somewhere else? Or maybe there is some kind of problem with my itk installation? I have successfuly used other libraries, and I only have itk installed (I mean I don't have vtk, tcl etc).
It has been renamed itkScalarImageToTextureFeaturesFilter (probably in ITK 4.0). You can see this conversion listed in the table here: http://itk.org/Wiki/Proposals:Refactoring_Statistics_Framework_2007_Migration_Users_Guide

Perl MYSQL Error : libmysql.dll

Have you ever met this error when code Perl to access db MYSQL :
The procedure entry point mysql_get_parameters could not be located in libmysql_.dll ?
I already copied libmysql.dll from D:\xampp\mysql\lib\ to many places and renamed it to libmysql_.dll:
- D:\xampp\perl\vendor\lib\auto\DBD\mysql\
- C:\WINDOWS\System32\
But still Entry Point Not Found -.-'
Please help ...
Regards,
Christine
Download Strawberry Perl from http://strawberryperl.com/
Install it on your PC
Find libmysql_.dll file from C:\strawberry\c\bin
Copy it onto D:\xampp\perl\vendor\lib\auto\DBD\mysql
I know this is an OLD problem, but current strawberry perl (5.24.1.1) will not work as downloaded/installed unless you use the answer above to fix it.
Copy the dll located at [DRIVELETTER]:\Strawberry\c\bin\LIBMYSQL_.dll
TO: [DRIVELETTER]:\Strawberry\perl\vendor\lib\auto\DBD\mysql
And your legacy mysql scripts will work again :-) (well, mine did)
Copying
C:\strawberry\c\bin\libmysql_.dll
to
c:\strawberry\perl\vendor\lib\auto\mysql
does not work in Release Strawberry 5.28.2.
My solution is rather unusual - but works (until now):
I took the libmysql_.dll from Release Perl 5.12 from ActiveState (yes, sorry, but I was in despair)!!!
Copying this file (from 28th Sept 2016) to
c:\strawberry\perl\vendor\lib\auto\mysql did it for me.

Unreadable bytecode database tar.gz on windows (Maxmind)

Following my previous question (Maxmind world cities database issue (MySql)), for which I did not receive any solution, just closed my question with couple comments (anyway, thanks for the comments).
I repost my question in an other way : how could somebody import a database contained in txt file under bytecode form, file compressed in a tar.gz file (may be twice), and this on MySQL for Windows.
Here is the file : http://www.maxmind.com/app/worldcities
Thanks in advance,
This is a problem which seems to be affecting a number of people, me included. The problem is currently being discusssed at the MaxMind forums. You may find it helpful to look- hopefully it can be resolved soon.
[EDIT] It's been solved! The file WAS compressed twice, as you said. See the link for details.
I found the solution with a_horse help : as he said, the file is twice zipped (tar.gz), but in the wrong way.
So here is the process : gunzip the tar.gz file. You gonna have a worldcitiespop.txt. Rename this file as a tar.gz. Gunzip (force if it's required) this file. You gonna obtain a worldcitiespop.tar file. Rename this file as a txt and here is it!
When you have malformed files of this sort, the first advisable thing is to use a program like file. file looks at the first few bytes of a file for magic numbers which identify the format of the file, ignoring the potentially-misleading extension. Using this tool, you could have determined the filetype, changed the extension to the appropriate one, and continued extracting until you had the plaintext you were after.
I hope you'll pardon the broad answer, especially after you've already found a solution to your specific problem, but for the purposes of future visitors to the site, it is more likely they have the general problem of "unable to open a file which has the wrong extension" than your specific issue.

oprofile on a stripped binary

I am trying to find ways to use oprofile on a stripped binary yet
still get detailed information when symbol tables are available
later, but so far I haven't find any solution.
Here is my situation: Our software is shipped to our customer stripped, but we have unstripped version on our build machine. When
we have a software crash, the backtrace can be sent back and we
can interpret it with local unstripped build.
Since oprofile is about taking samples and interpreting samples, is there a way to de-couple this process? Is there a way for oprofile/opreport to generate hex-address based profile information that can be interpretted on a different machine with all symbols available. Maybe I can do so by copying back the sample files?
I am sure it must be possible, so I am reaching out to the experts for advice. Detailed steps would be nice.
Thanks in advance.
I found a way to do it. It might not be the best, but I am surprised this didn't generate enough interest.
Say you have a binary called "mybin" and running its stripped version at customer site. Here would be my procedure:
Ask the customer (or your field engineer) run oprofile, the
whole nine yard (setup, start, dump and shutdown), then do:
tar czf OP-`date +"%Y%m%d%H%M%S"`.tgz /var/lib/oprofile
and ship that back.
On your build machine, do the following
mkdir /tmp/migrate && cd /tmp/migrate
tar xzf OP-*.tgz
Now you can check the overall CPU usage on target, by
opreport -% --session-dir=/tmp/migrate/var/lib/oprofile
If your "mybin" is built under /home/nobody/build/1.2.0/, you can use
opreport -l mybin --image-path /home/nobody/build/1.2.0/ --session-dir=/tmp/migrate/var/lib/oprofile
to see the details just for "mybin".