{	name = 'latex.definition';
	match = '(\\)(newcommand|renewcommand)\{[^\}]+\}';
}

Then, I created a new LaTeX Preference with scope selector “latex.definition”, and contents:

{	showInSymbolList = 1;
	symbolTransformation = '
		s/^\\(newcommand|renewcommand)\{\\(.+)\}/$2/;';
}

I’m sure there’s a more elegant way to solve this, but when I last faced it a few years ago, I hacked together an ugly shell script that converts the PDF to PS to EPS back to PDF again. I don’t recall why all these steps were necessary, but at the time this was the quickest thing I could find that worked:

#!/bin/bash
 
export GS_OPTIONS='-dEmbedAllFonts=true -dPDFSETTINGS=/printer'
cp $1 $1.old
pdftops $1 tmp.ps
ps2eps tmp.ps 
epstopdf tmp.eps 
mv tmp.pdf $1
rm tmp.ps tmp.eps

As you can see here, it successfully embeds the fonts in a pdf file, without increasing the file size too much. And each of the conversion steps should be lossless, so the final pdf looks exactly the same as the input:

jawolfe@[~/Projects/reports/11-ijcai/graphs]: pdffonts independent.pdf 
name                                 type              emb sub uni object ID
------------------------------------ ----------------- --- --- --- ---------
Helvetica                            Type 1            no  no  no       7  0
Symbol                               Type 1            no  no  no       8  0
jawolfe@[~/Projects/reports/11-ijcai/graphs]: ./fixfonts independent.pdf 
... (ignore the error messages)
jawolfe@[~/Projects/reports/11-ijcai/graphs]: ls -l
total 72
-rwxr--r--@ 1 jawolfe  admin   173 Apr 12 15:45 fixfonts*
-rw-r--r--  1 jawolfe  admin  9642 Apr 12 15:45 independent.pdf
-rw-r--r--  1 jawolfe  admin  4102 Apr 12 15:45 independent.pdf.old
jawolfe@[~/Projects/reports/11-ijcai/graphs]: pdffonts independent.pdf 
name                                 type              emb sub uni object ID
------------------------------------ ----------------- --- --- --- ---------
QHKFIS+Helvetica                     Type 1C           yes yes no       8  0
ONFWFL+Symbol                        Type 1C           yes yes no      10  0

Thus, I decided to modify swank-clojure to present exceptions in the opposite order: rather than starting with the caught exception and providing the option to examine its “Cause”, start with the innermost cause and allow examining its “Source”. In addition to providing the must useful stack traces up front, this also means that the first thing you see in the SLDB window is the real exception, not a mess of RuntimeExceptions.

For the interested, I posted the change on GitHub; it’s my first real change to anything SLIME, so take care if you decide to use it.

user> (set! *warn-on-reflection* true)
true
 
user> (defmacro declare-first-char [cls]
	(let [x (gensym)]
	  `(defn first-char [~(with-meta x {:tag cls})] 
             (.charAt ~x 0))))
#'user/declare-first-char
 
user> (declare-first-char String)
#'user/first-char ; No reflection warning!
 
user> (first-char "test")
\t

The key here is the [~(with-meta x {:tag cls})] fragment, which replaces the normal [#^String x#] version that could be used if the type was known in advance.

Things seem pretty easy if you just need to call some C++ functions from Java: you use JNI and do a little gruntwork to translate data to and from Java objects, or let SWIG do the heavy lifting for you. However, in my case things were harder, because the library is multithreaded (using boost threads) and makes heavy use of callbacks into the client (i.e., Java).

The main complication is that each native thread that calls a Java method must do so through its own JNIEnv pointer, obtained by calling AttachCurrentThread on a JavaVM instance. Each such native thread (which may be created and managed by code you can’t change) must eventually be detached from the JVM by calling DetachCurrentThread within it, or it seems memory leaks and JVM shutdown issues can result. There is no obvious way to detach the thread from the outside, so if you let the thread die or get away before it calls DetachCurrentThread you’re stuck.

Since a C++ wrapper for the Java callbacks is needed anyway, one easy solution is to attach before each callback and detach afterwards. However, this may be very expensive; I haven’t measured the cost, but one post I found quoted a factor of 6 slowdown. My alternative solution uses boost::thread_specific_ptr to detach each native thread just before it dies:

#include <boost/thread/tss.hpp>
 
static JavaVM *vm = NULL;
 
class ThreadJNIEnv {
public:
    bool _detach;
    JNIEnv *env;
    ThreadJNIEnv() {
        cout << "Attaching " << boost::this_thread::get_id() << endl;
        vm->AttachCurrentThread((void **) &env, NULL);
        ASSERT(env != NULL);
        _detach = true;
    }
 
    ThreadJNIEnv(JNIEnv *e) {
        env = e;
        _detach = false;
    }
 
    ~ThreadJNIEnv() {
        if (_detach) {
            cout << "Detaching " << boost::this_thread::get_id() << endl;
            vm->DetachCurrentThread();
        }
    }
};
 
static boost::thread_specific_ptr<ThreadJNIEnv> envs;
 
JNIEnv *getJNIEnv(){
    ThreadJNIEnv *tenv = envs.get();
    if (tenv == NULL) {
        tenv = new ThreadJNIEnv();
        envs.reset(tenv);
    }
    return tenv->env;
}
 
bool init(JNIEnv *env) {
   if (!env->GetJavaVM(&vm) < 0) return false;
   envs.reset(new ThreadJNIEnv(env));
   return true;
}

If your main function is in Java, you initialize the library by calling init(env) with the current thread’s JNIEnv (with multiple Java threads, you may have to take care). If it’s C++, you just set “vm” directly when you create the JVM instance.

Then, any function not in a direct JNI call just uses getJNIEnv() to get a JNIEnv pointer that’s valid for the current thread. This will work correctly both for indirect calls from Java, and from native threads, which will be automatically attached on the first call to getJNIEnv and automatically detached before death.

Seemed to work for me on Ubuntu; YMMV.

Similar issues exist for anonymous functions, which some time ago I realized you could give names by using (fn name [args] & body). What I didn’t realize is the same is true of multimethods. By simply using (defmethod multifn dispatch-val *name* [args] &body), you can give each instance of a multimethod a unique name, which will show up in stack traces and profile results.