Re: help-manager in 5.0 (contribution: Help-Tag-Manager.lisp)

--On Friday, June 27, 2003 14:46 -0600 Alexander Repenning 
<ralex@...> wrote:

> At 8:33 PM -0400 6/26/03, Octav Popescu wrote:
>> --On Monday, June 23, 2003 19:55 -0600 Alexander Repenning
>> <ralex@...> wrote:
>>> Actually quite simple. Here's an early version contribution. Let me know
>>> what is missing.
>>>
>>> http://agentsheets.com/lisp/Help-Tag-Manager.lisp
>>>
>>> This code is compatible with  :helps-spec approach which was used
>>> previously for balloons.
>>
>> I tried it and it works quite nicely. Thanks. I have two problems though:
>>
>> 1. I tried to do a (push #'start-help-tag-manager
>> *lisp-startup-functions*) before a save-application, to have the new
>> image start it automatically. The new image does create the process,
>> but it's state is "exhausted". Any solution?
>
> tried the same with out of the box MCL 5. Could not replicate your
> problem. Could it be that you have other startup functions conflicting?

I figured it out. I also need to have a (push #'stop-help-tag-manager 
*lisp-cleanup-functions*). Without it, it works fine on the first saved 
image, but it's exhausted if you save another one from the saved image.

>> 2. I was trying to make it show "expanded" tags, when you press the
>> "command" key. I redefined the macro to take a cons tag spec, where

Fwd: LispWorks for Macintosh 4.3

Begin forwarded message:

> From: David Fox <davef@...>
> Date: Mon Jun 30, 2003  14:03:20 Europe/Prague
> To: lisp-hug@...
> Subject: LispWorks for Macintosh 4.3
> Reply-To: David Fox <davef@...>
>
>
> XANALYS ANNOUNCES THE RELEASE OF LISPWORKS FOR MACINTOSH 4.3
>
> June 30, 2003, Waltham, MA. LispWorks, the portable ANSI Common Lisp  
> integrated development tool from Xanalys, is available for the  
> Macintosh platform.
>
> Xanalys's powerful CAPI graphical libraries are now implemented on top  
> of the new Apple Cocoa API. Combined with the robust Unix-based  
> LispWorks kernel, this enables LispWorks to offer a unique, powerful  
> and fun to use Lisp development environment for Macintosh Mac OS X  
> (10.2 or higher) users
>
> Availability and Pricing
>
> As of June 30th, 2003, LispWorks for Macintosh is available as a  
> Professional Edition at $999 and Enterprise Edition at $2,999. The  
> Enterprise Edition includes Common SQL, LispWorks ORB and  
> KnowledgeWorks.  Support and Maintenance packages are also available.
>
>

Re: MCL 5.0 and multiprocessor Macs

At 9:24 PM -0400 6/2/03, Alice Hartley wrote:
>  >I just received the 5.0 release this weekend. I assume that this is the
>>5.0 final release - right?
>>
>>All seems well. I was just wondering, does this release resolve the
>>issues some people were having with multiprocessor macs under Mac OS X?
>  >
>  >Raf
>
>We believe it does solve the problems with multiprocessor machines.

What was exactly the problem?
We are encountering some problems with MCL5.0 final version on the 
dual processor Mac.
Some operations that work fine on a single processor machine do work 
"randomly" (sometimes yes, sometimes not, with Listener errors or 
with application exits) on the dual processor.
Are the problems not yet solved?

Best regards
Sandro

Re: MCL 5.0 and multiprocessor Macs

>At 9:24 PM -0400 6/2/03, Alice Hartley wrote:
>>  >I just received the 5.0 release this weekend. I assume that this is the
>>>5.0 final release - right?
>>>
>>>All seems well. I was just wondering, does this release resolve the
>>>issues some people were having with multiprocessor macs under Mac OS X?
>>  >
>>  >Raf
>>
>>We believe it does solve the problems with multiprocessor machines.
>
>
>What was exactly the problem?
>We are encountering some problems with MCL5.0 final version on the 
>dual processor Mac.
>Some operations that work fine on a single processor machine do work 
>"randomly" (sometimes yes, sometimes not, with Listener errors or 
>with application exits) on the dual processor.
>Are the problems not yet solved?
>
>Best regards
>Sandro

I suggest that you say what MacOS version you are using (and other 
specifics of your problems).
Problems related to pre-MacOS 10.2 have been sorted now (if you use 10.2).
I run dual 800 and MCL 5.0 seem fine.
See recent postings from Alice here.

Re: MCL 5.0 and multiprocessor Macs

>
> Date: Fri, 4 Jul 2003 14:27:40 +0200
> From: Sandro Pedrazzini <pedrazzini@...>
> Subject: Re: MCL 5.0 and multiprocessor Macs
>
> At 9:24 PM -0400 6/2/03, Alice Hartley wrote:
> [...]
> >We believe it does solve the problems with multiprocessor machines.
>
>
> What was exactly the problem?

The most severe problem had to do with how Time Manager tasks are
implemented in OSX. (Traditionally, they preempted the currently
executing cooperative thread; in OSX, they run in a separate native
thread and can therefore run concurrently with the cooperative thread
on multiprocessor machines.  This introduced resource contention
issues: the Time Manager task used to drive MCL's scheduler and the
current cooperative lisp thread would - sooner or later - both try
to modify a data structure that each thought it had exclusive access
to.

There was an even more obscure bug which seemed to indicate that the
OS doesn't save and restore registers correctly on multiprocessor
machines when the stack pointer isn't aligned on a 16-byte boundary
when a context switch occurs.  (If this was indeed the problem, it may
have had to do with Altivec alignment constraints.)  The Carbon
Exception Manager (which the beta version of MCL 5 used) calls the
application's exception handler with an improperly aligned stack
pointer; even if the application's exception handler fixed the stack

Re: MCL 5.0 and multiprocessor Macs

scrollers MCL5.0

Has anyone else noticed that scrolls bars are very choppy when
track-thump-p is set to true?  The examples that are given in
scrollers.lisp and scroll-bar-dialog-items.lisp demeonstrate this issue. 
The strange thing is that fred listener windows seem to handle scrolling
just fine when track-thumb-p is set to true.  Does anyone know of a fix so
that one could implement scroll bars in a window (or view) that are not
choppy when the user holds down the mouse to scroll?

Andy

Re: scrollers MCL5.0

>Has anyone else noticed that scrolls bars are very choppy when
>track-thump-p is set to true?  The examples that are given in
>scrollers.lisp and scroll-bar-dialog-items.lisp demeonstrate this issue. 
>The strange thing is that fred listener windows seem to handle scrolling
>just fine when track-thumb-p is set to true.  Does anyone know of a fix so
>that one could implement scroll bars in a window (or view) that are not
>choppy when the user holds down the mouse to scroll?
>
>Andy

Patch enclosed.

(in-package :ccl)
;; track thumb better feedback on OSX

(let ((*warn-if-redefine-kernel* nil)
      (*warn-if-redefine* nil))

(defmethod dialog-item-action ((item scroll-bar-dialog-item))
  (let ((f (dialog-item-action-function item)))
    (if f
      (funcall f item)
      (let ((scrollee (scroll-bar-scrollee item)))
        (when scrollee
          (scroll-bar-changed scrollee item))))
    (when (osx-p)  ;; aargh
      (with-port-macptr port
        (#_QDFlushPortBuffer port *null-ptr*)))))
)

Re: scrollers MCL5.0

At 10:26 AM -0400 7/8/03, MCL-LIST@... wrote:
>Has anyone else noticed that scrolls bars are very choppy when
>track-thump-p is set to true?  The examples that are given in
>scrollers.lisp and scroll-bar-dialog-items.lisp demeonstrate this issue.
>The strange thing is that fred listener windows seem to handle scrolling
>just fine when track-thumb-p is set to true.  Does anyone know of a fix so
>that one could implement scroll bars in a window (or view) that are not
>choppy when the user holds down the mouse to scroll?
>
>Andy

yes, we have a fix (see below). The issue is that 
track-scroll-bar-thumb never flushes the port buffer which is 
something that should be done for this type of action.  Without the 
explicit flush windows will still update eventually but will make 
scrolling look very sluggish. Strategically calling 
#_QDFlushPortBuffer solves the problem.

My Question: does anybody have code to make ths scroll bars be of 
proportion size? The current MCL implementation does not seem to 
adjust the scroller size.

Alex

__________________

;;; 4/30/03 Alexander repennning
;;; patching: scroll-bar-dialog-item.lisp

(in-package :ccl)

(let ((*Warn-If-Redefine-Kernel* nil))
(defun track-scroll-bar-thumb (item)
   (let* ((old-setting (scroll-bar-setting item))
          (min (scroll-bar-min item))
          (max (scroll-bar-max item))
          (horizontal? (eq (scroll-bar-direction item) :horizontal))
          (position (view-position item))
          (last-mouse (rref *current-event* :eventRecord.where))
          (size (view-size item))
          (real-time-tracking (scroll-bar-track-thumb-p item))
          width length old-mouse left right mouse setting)
     ; disable periodic tasks that draw
     ;; I have no idea why we need the osx-p thing here! akh
     (with-periodic-task-mask ((if (osx-p) 0 $ptask_draw-flag) t)
       (setq last-mouse
             ; global-to-local
             (add-points (view-origin item)
                         (subtract-points last-mouse (view-position 
(view-window item)))))
       (if horizontal?
         (setq width (point-v size)
               length (- (point-h size) width width width)
               left (+ (round (* width 3) 2) (point-h position))
               old-mouse (point-h last-mouse))
         (setq width (point-h size)
               length (- (point-v size) width width width)
               left (+ (round (* width 3) 2) (point-v position))
               old-mouse (point-v last-mouse)))
       (setq right (+ left length))
       (loop
         (unless (mouse-down-p)
           (unless (or real-time-tracking (not setting))
             (track-scroll-bar item setting :in-thumb)
             (#_QDFlushPortBuffer (#_GetWindowPort (wptr (view-window 
Item))) (%null-ptr)))
           (return))
         (setq mouse (view-mouse-position item))
         (unless (eql mouse last-mouse)
           (setq last-mouse mouse)
           (setq mouse (if horizontal? (point-h mouse) (point-v mouse)))
           (setq setting (min max
                              (max min
                                   (+ old-setting
                                      (round (* (- mouse old-mouse) (- max min))
                                             (- right left))))))
           (if real-time-tracking
             (progn (track-scroll-bar item setting :in-thumb)
                    (#_QDFlushPortBuffer (#_GetWindowPort (wptr 
(view-window Item))) (%null-ptr))
                    )
             (set-scroll-bar-setting item setting))))))))

--

-- 
Prof. Alexander Repenning
University of Colorado
Department of Computer Science and
Center of LifeLong Learning & Design
Campus Box 430
Boulder, CO 80309-0430
_____________________________________________________________
mailto:ralex@...            phone: (303) 492-1349
http://www.cs.colorado.edu/~ralex/      fax:   (303) 492-2844

Unicode fred

I've uploaded a module titled "Unicode-Fred" to hotdispatch.

<http://www.hotdispatch.com/officefronts/Takehiko_Abe>

It defines a fred-window class capable of opening and saving
files with various encodings. Supported are

:UTF-8 
:UTF-16 
:LATIN-1 
:ISO-2022-JP 
:EUC-JP 
:EUC-TW 
:BIG-5 
:ISO-2022-KR 
:EUC-KR 
:ISO-8859-5 
:KOI-8 
:EUC-CN 
:ISO-2022-CN 
:LATIN-2 
:LATIN-4 
:GB-18030 
:SHIFT-JIS

Comments are highly welcome.