Re: Clozure CL on Android

On Wed, 1 Feb 2012, Roman Kovalev wrote:

> CCL is now working on my Android and I have some questions.
>
> 1. I transferred Android-headers to the device and tried to run rebuild-ccl:
> Error: File #P"ccl:lib;systems.lisp.newest" not found.
> Sources needed?

Yes, and getting them onto an Android device is sometimes a little
awkaward.  (I've been doing stuff involving mounting the device as a
USB disk on a Mac (a Windows or Linux box should work as well), doing
an "svn checkout" and periodic "svn updates" to a CCL directory on the
mounted disk, then unmounting it and using symbolic links from the
subdirectories /mnt/sdcard/ccl (where the svn tree is) to subdirectories
of /data/local/ccl.

Anyway: REBUILD-CCL compiles sources to FASLs and builds a heap image out
of those FASLs, and it's not going to be able to do much if the sources
aren't there.

>
> 2. I ran the following code.
> (do-external-symbols (s (find-package "ARM-ANDROID")) (print s))
>
> And the output list is empty. Situation will change after a rebuilding CCL?

Yes. More precisely, symbols that're read by #$/#_ are interned in that
package.

ELS 2012, Zadar, Croatia

Apologies for the multiple postings. 

PAPER SUBMISSION DEADLINE EXTENDED 

European Lisp Symposium 2012, Zadar, Croatia, April 30th - May 1st, 2012 

http://european-lisp-symposium.org 

The purpose of the European Lisp Symposium is to provide a forum for 
the discussion and dissemination of all aspects of design, 
implementation and application of any of the Lisp and Lisp-inspired 
dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, 
Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, and so on. We 
encourage everyone interested in Lisp to participate. 

The main theme of the 2012 European Lisp Conference is 
"Interoperability: Systems, Libraries, Workflows".  Lisp based and 
functional-languages based systems have grown a variety of solutions 
to become more and more integrated with the wider world of Information 
and Communication Technologies in current use.  There are several 
dimensions to the scope of the solutions proposed, ranging from 
"embedding" of interpreters in C-based systems, to the development of 
abstractions levels that facilitate the expression of complex context 
dependent tasks, to the construction of exchange formats handling 
libraries, to the construction of theorem-provers for the "Semantic 
Web".  The European Lisp Symposium 2012 solicits the submission of 
papers with this specific theme in mind, alongside the more 
traditional tracks which have appeared in the past editions. 

We invite submissions in the following forms: 

format to a

I am having trouble with cursor position in a programmatic Hemlock view.
The attached (also enclosed) code makes a Hemlock view, creates a stream
to write to it, and writes a few lines using format.

Clicking in this view makes the insertion-point cursor blink where you clicked,
but then trying to move the cursor using arrow keys reveals the insertion
point is really still at the end of the buffer.

I don't think my code does anything naughty. Perhaps there is something it
ought to do nice?

Arthur

Welcome to Clozure Common Lisp Version 1.7-r15184M  (DarwinX8664)!

(in-package hemlock)

; --------------------------------------------------------------------------------
; Redefine methods given in ccl:cocoa-ide;hemlock;src;streams.lisp merely
; to ensure that hemlock buffer modification is done in the proper thread
; --------------------------------------------------------------------------------

(defmethod hi::stream-write-char ((stream hi::hemlock-output-stream) char)
  (gui::execute-in-gui
   (lambda nil
     (gui::assume-cocoa-thread)

Re: format to a

Follow-up: I wonder if stream-terpri should do something more to a hemlock-output-stream
than simply write a #/Newline?
Arthur

On 1 Feb 2012, at 15:36, Arthur Cater wrote:

> I am having trouble with cursor position in a programmatic Hemlock view.
> The attached (also enclosed) code makes a Hemlock view, creates a stream
> to write to it, and writes a few lines using format.
> 
> <unclickable.lisp>
> 
> Clicking in this view makes the insertion-point cursor blink where you clicked,
> but then trying to move the cursor using arrow keys reveals the insertion
> point is really still at the end of the buffer.
> 
> I don't think my code does anything naughty. Perhaps there is something it
> ought to do nice?
> 
> Arthur
<snip>

Re: Clozure CL on Android

On Wed, 1 Feb 2012, Roman Kovalev wrote:

> Thanks for the quick response.
>
>>> 1. I transferred Android-headers to the device and tried to run
>>> rebuild-ccl:
>>> Error: File #P"ccl:lib;systems.lisp.newest" not found.
>>> Sources needed?
>>
>>
>> Yes, ...
> From http://article.gmane.org/gmane.lisp.openmcl.devel/7511 :
> "get CCL sources onto the device (you can use
> "adb push".)  There's a basic set of interfaces in svn at
> http://svn.clozure.com/publicsvn/openmcl/trunk/android-headers
> and if you copy them to /data/local/ccl/android-headers you should be
> able to use #_/#$ and do
> ? (rebuild-ccl :clean t)"
>
> Which sources are needed?
> ? only http://svn.clozure.com/publicsvn/openmcl/trunk/android-headers
> ? http://svn.clozure.com/publicsvn/openmcl/trunk/source/compiler/ARM

On a Mac, the device is mounted at /Volumes/NO\ NAME/, so:

$ cd /Volumes/NO\ NAME
$ svn co http://svn.clozure.com/publicsvn/openmcl/trunk/androidarm/ccl

will check out all sources and androidarm-specific binaries, analogous

Re: format to a

Arthur,

If you can't find a solution to the stream/format approach (which I like), you might try using hi::insert-string.

It accepts a :charprops parameter and will not foul up the insertion point.

-- Glen

On Feb 1, 2012, at 10:36 AM, Arthur Cater wrote:

> I am having trouble with cursor position in a programmatic Hemlock view.
> The attached (also enclosed) code makes a Hemlock view, creates a stream
> to write to it, and writes a few lines using format.

Re: format to a

Thanks Glen.

I've never looked at the innards of Format, but I assumed it bottoms out in calls
to stream-write-char, stream-write-string, and perhaps stream-terpri.
And these all turn into hi::insert-character and hi::insert-string.
So I'm puzzled about what does foul up the insertion point.

Arthur

On 2 Feb 2012, at 09:49, Glen Foy wrote:

> Arthur,
> 
> If you can't find a solution to the stream/format approach (which I like), you might try using hi::insert-string.
> 
> It accepts a :charprops parameter and will not foul up the insertion point.
> 
> -- Glen
> 
> 
> On Feb 1, 2012, at 10:36 AM, Arthur Cater wrote:
> 
>> I am having trouble with cursor position in a programmatic Hemlock view.
>> The attached (also enclosed) code makes a Hemlock view, creates a stream
>> to write to it, and writes a few lines using format.
> 

Re: format to a

Sorry for not responding earlier (and I still haven't looked at your
test case in any detail.)

A Hemlock buffer in the IDE is (usually/always/almost always) associated
with a Cocoa text view; from the point of view of the text view, the
Hemlock buffer implements the view's text storage.

Modifying an NSTextStorage object safely and sanely requires that a 
certain protocol be observed; that protocol involves telling the text
system that editing (if the storage object) is in progress, informing
it of what ranges of text are affected by insertions/deletions/etc,
and telling the text system that a sequence of editing operations has
been completed and the view should redisplay affected areas.

When a Hemlock command runs (usually in response to some key event),
it (a) runs on the main Cocoa event thread and (b) observes this protocol;
it can call HI::INSERT-CHARACTER and HI::INSERT-STRING (or have FORMAT
do that), and these things mean that modification on the buffer/textstorage
is synchronised with redisplay of the containing view.  Nothing really
enforces the first constraint (that everything's happening on a single
thread) except for the fact that trying to modify the buffer from some
other thread will probably lead to display and other problems.)

It'd be nice if there was some protocol that allowed arbitrary code
(running in an arbitrary thread) to modify Hemlock buffers in thread-safe
ways and to ensure that those modifications were made in accordance with
Cocoa constraints.  That protocol doesn't exist.

Like I said, I haven't really looked at this but I suspect you'll find
that FORMAT modified the buffer as expected but (a) the text view doesn't

Re: format to a hemlock view's buffer

Thank you Gary for responding, I appreciate the help.

The test case code attached here is quite small, 42 lines, see below.
Since everything it does is done inside gui::execute-in-gui I have removed
the redefinitions of stream-write-char and stream-write-string that ensured this.

I have taken code from handle-hemlock-event that seems to me to cover
the protocol issues you mentioned, and - with some reordering of bindings -
encapsulated it in the with-hemlock-protocol macro. Without success:
still, a mouseclick moves the visible cursor but a subsequent arrowkey
reveals the buffer-point is still at the end of the inserted text.

Arthur

(in-package hemlock)

(defmacro with-hemlock-protocol (streamexpr &rest actions)
  (let ((stream (gensym)) (mark (gensym)) (view (gensym)) (text-buffer (gensym)))
    `(ccl::with-standard-abort-handling "Abort editor event handling"
       (let ((,stream ,streamexpr) ,mark)
         (if (and (typep ,stream 'hi::hemlock-output-stream)
                  (setq ,mark (hi::hemlock-output-stream-mark ,stream)))
           (let* ((,text-buffer (hi::line-buffer (hi::mark-line ,mark)))
                  (hi::*current-buffer* ,text-buffer)
                  (,view (gui::front-view-for-buffer hi::*current-buffer*))
                  (hi::*current-view* ,view)
                  (hi::*next-view-start* nil) ;; gets set by scrolling commands

Re: format to a hemlock view's buffer

If you obscure the window that your example writes to (e.g., move another
window in front of it, minimize it, whatever) and then force it to display
itself, everything seems fine.  (Until that happens, the buffer and view
seem to be out of synch.)

A Hemlock keystroke is processed (at the moment) by
HI::PROCESS-HEMLOCK-EVENT; that method's second argument can be either
a key event or a function of 0 arguments.  Changing your example so that
it uses HI:HANDLE-HEMLOCK-EVENT instead of enclosing the DOTIMES in
WITH-HEMLOCK-PROTOCOL:

(hi::handle-hemlock-event
     view
    (lambda () (dotimes (num nlines) (format stream "Line ~a is here~%" num))))

seems to ensure that the right kind of redisplay happens (in the right view)
after the buffer is modified.

Like I said,  I agree that there should be an easier public way to do this
sort of thing.  Using HI::HEMLOCK-EVENT like this is fairly easy, but it's
not intended to be a public interface and it could change/disappear in the
future.

On Fri, 3 Feb 2012, Arthur Cater wrote:

> Thank you Gary for responding, I appreciate the help.
>
> The test case code attached here is quite small, 42 lines, see below.
> Since everything it does is done inside gui::execute-in-gui I have removed
> the redefinitions of stream-write-char and stream-write-string that ensured this.