"Typical good candidates for the NDK are self-contained, CPU-intensive 
operations that don't allocate much memory, such as signal processing, physics 
simulation, and so on."

Ok, here's a plan for :-) a real Android picolisp ... start by taking a version 
of picolisp, and begin cutting it back by dropping everything ndk c/c++ headers 
do not support.    So, the idea would be you'd get much of picolisp, hopefully 
more than minipicolisp, at least as much as ersatz, (I would think), and with 
no java interpretation penalty for the lisp interpreter. 

re: "... that don't allocate much memory". Fine; allocate what you need per 
application on init (from java), pass it to android picolisp to use. 


Reply via email to