From stoye at stoye.com  Fri Oct  7 06:03:23 2016
From: stoye at stoye.com (Ralf Stoye)
Date: Fri, 7 Oct 2016 15:03:23 +0200
Subject: [Openmcl-devel] how to debug this? (1 > (:B) => Don't know how to
	find slots of 0
Message-ID: <f61351a1-9127-e410-2c91-d9dd47f68a98@stoye.com>

Hi,
at first: sorry if this post is a duplicate, the first mail doesn't seem 
to reach the list.

Using cl-markdown, i encounter a bug which even prevents a backtrace. 
sometimes i'm thrown into the kernel debugger. In any case the data is 
substantially damaged and i am not comfortable debugging cl-containers 
and other involved libraries.
Since the code runs seamless in sbcl it may be some ccl problem (i 
understand that often some vague interpretation of the specs causes 
things like that ;-)
ccl Versions used: 1.11-r16796M (LinuxARM32) & 1.11-r16635 (LinuxX8664)
You'll find the code i run at the end of this mail (problem.lisp)
It should output some html. The "bad" thing is the call to 
table-of-contents which inserts some links and a table into the document 
structure.
I tried proclaiming safe optimizations (speed 0, safety & debug 3...) 
but to no avail (don't know how to prevent local optimize declarations 
inside the used libraries, any hints on that?)

So here is what should happen (and does in SBCL):
[rs at astreamer ~]$ sbcl --no-sysinit --no-userinit --load problem.lisp
This is SBCL 1.3.1,...
To load "cl-markdown":
   Load 1 ASDF system:
     cl-markdown
; Loading "cl-markdown"
.....
<a name='table-of-contents' id='table-of-contents'></a>
<div class='table-of-contents'>
<h1>Contents</h1><h1><a href='#header1-1' title='Headline 1'> Headline 1 
</a></h1><h2> <a href='#header2-3' title='headline 1.1'> headline 1.1 
</a></h2><h2> <a href='#header2-4' title='headline 1.2'> headline 1.2 
</a></h2><h1> <a href='#header1-6' title='Headline 2'> Headline 2 
</a></h1><h2> <a href='#header2-7' title='Headline 2.1'> Headline 2.1 
</a></h2>
</div>
   <a name='header1-1' id='header1-1'></a><h1>Headline 1</h1><p>some 
text </p><a name='header2-3' id='header2-3'></a><h2>headline 1.1</h2><a 
name='header2-4' id='header2-4'></a><h2>headline 1.2</h2><p>more text 
</p><a name='header1-6' id='header1-6'></a><h1>Headline 2</h1><a 
name='header2-7' id='header2-7'></a><h2>Headline 2.1</h2><p>last line </p>
* (SB-EXT:EXIT)


Using ccl the following happens:
[rs at astreamer ~]$ ccl -n -l problem.lisp
To load "cl-markdown":
   Load 1 ASDF system:
     cl-markdown
; Loading "cl-markdown"

 > Error: Array index -20 out of bounds for #<SIMPLE-VECTOR 13> .
 > While executing: ARRAY-ELEMENT-TYPE, in process listener(1).
 > Type :GO to continue, :POP to abort, :R for a list of available restarts.
 > If continued: Skip loading "problem.lisp"
 > Type :? for other options.
1 > (:B)
Don't know how to find slots of 0
1 >


---------------------------------------------------------------------
;;; problem.lisp
(load #P"~/quicklisp/setup.lisp")
(ql:quickload :cl-markdown)
(in-package :cl-markdown)
(markdown "
{table-of-contents :depth 2  :start 1 :label \"Contents\"}

# Headline 1

some text

## headline 1.1

## headline 1.2

more text

# Headline 2

## Headline 2.1

last line
" :stream *standard-output*)


From pjb at informatimago.com  Fri Oct  7 11:25:36 2016
From: pjb at informatimago.com (Pascal J. Bourguignon)
Date: Fri, 07 Oct 2016 20:25:36 +0200
Subject: [Openmcl-devel] how to debug this? (1 > (:B) => Don't know how
	to find slots of 0
References: <f61351a1-9127-e410-2c91-d9dd47f68a98@stoye.com>
Message-ID: <87y4202ezj.fsf@informatimago.com>

Ralf Stoye <stoye at stoye.com> writes:

> Hi,
> at first: sorry if this post is a duplicate, the first mail doesn't
> seem to reach the list.
>
> Using cl-markdown, i encounter a bug which even prevents a
> backtrace. sometimes i'm thrown into the kernel debugger. In any case
> the data is substantially damaged and i am not comfortable debugging
> cl-containers and other involved libraries.
> Since the code runs seamless in sbcl it may be some ccl problem (i
> understand that often some vague interpretation of the specs causes
> things like that ;-)
>> Error: Array index -20 out of bounds for #<SIMPLE-VECTOR 13> .

Most probably, you'll discover it's not a ccl problem.

Start by grepping all the sources you load for "optimize", and remove
all declaration, declaimation and proclaimation of optimize.

Then (declaim (optimize (space 0) (speed 0) (debug 3) (safety 3)))
and remove the compiled binaries, and recompile and reload the sources.

ccl will most probably tell you right away where the problem is.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
?The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.? -- Carl Bass CEO Autodesk



From rme at clozure.com  Sun Oct  9 16:16:52 2016
From: rme at clozure.com (R. Matthew Emerson)
Date: Sun, 9 Oct 2016 16:16:52 -0700
Subject: [Openmcl-devel] how to debug this? (1 > (:B) => Don't know how
	to find slots of 0
In-Reply-To: <87y4202ezj.fsf@informatimago.com>
References: <f61351a1-9127-e410-2c91-d9dd47f68a98@stoye.com>
 <87y4202ezj.fsf@informatimago.com>
Message-ID: <2D12E1FF-D741-454A-8DB6-392E28CF30B1@clozure.com>


> On Oct 7, 2016, at 11:25 AM, Pascal J. Bourguignon <pjb at informatimago.com> wrote:
> 
> Ralf Stoye <stoye at stoye.com> writes:
> 
>> Hi,
>> at first: sorry if this post is a duplicate, the first mail doesn't
>> seem to reach the list.
>> 
>> Using cl-markdown, i encounter a bug which even prevents a
>> backtrace. sometimes i'm thrown into the kernel debugger. In any case
>> the data is substantially damaged and i am not comfortable debugging
>> cl-containers and other involved libraries.
>> Since the code runs seamless in sbcl it may be some ccl problem (i
>> understand that often some vague interpretation of the specs causes
>> things like that ;-)
>>> Error: Array index -20 out of bounds for #<SIMPLE-VECTOR 13> .
> 
> Most probably, you'll discover it's not a ccl problem.
> 
> Start by grepping all the sources you load for "optimize", and remove
> all declaration, declaimation and proclaimation of optimize.
> 
> Then (declaim (optimize (space 0) (speed 0) (debug 3) (safety 3)))
> and remove the compiled binaries, and recompile and reload the sources.
> 
> ccl will most probably tell you right away where the problem is.

Another approach you might try is to set ccl:*load-preserves-optimization-settings* to t, then remove fasls and recompile.

This setting makes (declaim (optimize ...)) effectively file local.  When the setting is nil (as it is by default), (declaim (optimize ...)) has load-time effects.

You can use (declaration-information 'optimize) to see what the current optimize settings are.

The default, of course, is ((SPEED 1) (SAFETY 1) (COMPILATION-SPEED 1) (SPACE 1) (DEBUG 1)).

If you've loaded some file that contains (declaim (optimize (safety 0))) or something equally ill-advised, (declaration-information 'optimize) will show different values.

To belabor the point, you could do something like this:

(declaration-information 'optimize)
(ql:quickload :some-system)
(declaration-information 'optimize)

If output of declaration-information changes after loading the system, some file is messing around with global optimization settings and should be fixed.

Sometimes

(eval-when (:compile-toplevel)
  (declaim (optimize ...))

is what is actually meant.





From gb at clozure.com  Wed Oct 12 06:56:17 2016
From: gb at clozure.com (Gary Byers)
Date: Wed, 12 Oct 2016 07:56:17 -0600
Subject: [Openmcl-devel] how to debug this? (1 > (:B) => Don't know how
 to find slots of 0
In-Reply-To: <2D12E1FF-D741-454A-8DB6-392E28CF30B1@clozure.com>
References: <f61351a1-9127-e410-2c91-d9dd47f68a98@stoye.com>
 <87y4202ezj.fsf@informatimago.com>
 <2D12E1FF-D741-454A-8DB6-392E28CF30B1@clozure.com>
Message-ID: <66231d73-7e8f-db51-764b-7da48c2f0a6c@clozure.com>

Given that there is no lomger a cl-markdown project on common-lisp.net 
(there may have once been) amd the fact that quicklisp tries to build 
cl-markdown by installing a tarball contaiinng Darcs netainfolrmation 
from 2008 or so. I suspect that the problem here hss more to do with 
that bitrot than it has to do with handling of OPTIMIZE declarations.

On 10/09/2016 05:16 PM, R. Matthew Emerson wrote:
>
>> On Oct 7, 2016, at 11:25 AM, Pascal J. Bourguignon <pjb at informatimago.com> wrote:
>>
>> Ralf Stoye <stoye at stoye.com> writes:
>>
>>> Hi,
>>> at first: sorry if this post is a duplicate, the first mail doesn't
>>> seem to reach the list.
>>>
>>> Using cl-markdown, i encounter a bug which even prevents a
>>> backtrace. sometimes i'm thrown into the kernel debugger. In any case
>>> the data is substantially damaged and i am not comfortable debugging
>>> cl-containers and other involved libraries.
>>> Since the code runs seamless in sbcl it may be some ccl problem (i
>>> understand that often some vague interpretation of the specs causes
>>> things like that ;-)
>>>> Error: Array index -20 out of bounds for #<SIMPLE-VECTOR 13> .
>>
>> Most probably, you'll discover it's not a ccl problem.
>>
>> Start by grepping all the sources you load for "optimize", and remove
>> all declaration, declaimation and proclaimation of optimize.
>>
>> Then (declaim (optimize (space 0) (speed 0) (debug 3) (safety 3)))
>> and remove the compiled binaries, and recompile and reload the sources.
>>
>> ccl will most probably tell you right away where the problem is.
>
> Another approach you might try is to set ccl:*load-preserves-optimization-settings* to t, then remove fasls and recompile.
>
> This setting makes (declaim (optimize ...)) effectively file local.  When the setting is nil (as it is by default), (declaim (optimize ...)) has load-time effects.
>
> You can use (declaration-information 'optimize) to see what the current optimize settings are.
>
> The default, of course, is ((SPEED 1) (SAFETY 1) (COMPILATION-SPEED 1) (SPACE 1) (DEBUG 1)).
>
> If you've loaded some file that contains (declaim (optimize (safety 0))) or something equally ill-advised, (declaration-information 'optimize) will show different values.
>
> To belabor the point, you could do something like this:
>
> (declaration-information 'optimize)
> (ql:quickload :some-system)
> (declaration-information 'optimize)
>
> If output of declaration-information changes after loading the system, some file is messing around with global optimization settings and should be fixed.
>
> Sometimes
>
> (eval-when (:compile-toplevel)
>   (declaim (optimize ...))
>
> is what is actually meant.
>
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> https://lists.clozure.com/mailman/listinfo/openmcl-devel
>


From arthur.cater at ucd.ie  Wed Oct 12 07:43:17 2016
From: arthur.cater at ucd.ie (Arthur Cater)
Date: Wed, 12 Oct 2016 15:43:17 +0100
Subject: [Openmcl-devel] Hemlock and its documents and windows
Message-ID: <24A59692-C19F-4900-830A-B091C7E4C9DE@ucd.ie>

Hi everybody,

On my mid-2015 Macbook Pro with OS X.11.5 I have been trying to move my code
from DarwinX8664 ccl 1.10 r16196 to ccl 1.11 r16635.

I have a problem with some code I contributed a few years back, clickable.lisp.
Specifically it uses gui::find-or-make-hemlock-view and then  (hold your noses here)
changes the ns:isa slot of the window to a subclass of gui::hemlock-frame and
changes the ns:isa slot of the document to a subclass of guy::hemlock-editor-document.
While the first seems to succeed, the second seems to cause a crash in ccl 1.11.

I notice that the original contents of these ns:isa slots are now foreign pointers, whereas previously in ccl 1.10 they were ns class objects. I also notice that sometime between
my developing that code and ccl 1.10 coming along, a change was made to the
hemlock-frame?s ns:isa to be a #<NS-OBJECT NSKVONotifying_HemlockFrame ?>.

So I have a few questions, I?d love to hear your helpful answers!

Is there a better way to get the effect of change-class on a NS object than to change its NS:ISA slot?

If I am to change the slot, what sort of value should be used? If a foreign pointer, then
how do I make an appropriate one (I only know of ccl::%int-to-ptr but that probably isn?t
appropriate and if it is then I don?t know how to get the appropriate int)

Where is that NSKVONotifying_HemlockFrame defined? Where is it used? Searches of the ccl files don?t show me anything relevant.

Arthur



From cmhanson at eschatologist.net  Wed Oct 12 18:58:39 2016
From: cmhanson at eschatologist.net (Chris Hanson)
Date: Wed, 12 Oct 2016 18:58:39 -0700
Subject: [Openmcl-devel] Hemlock and its documents and windows
In-Reply-To: <24A59692-C19F-4900-830A-B091C7E4C9DE@ucd.ie>
References: <24A59692-C19F-4900-830A-B091C7E4C9DE@ucd.ie>
Message-ID: <C3072351-A19B-4B81-99FF-691400081782@eschatologist.net>

On Oct 12, 2016, at 7:43 AM, Arthur Cater <arthur.cater at ucd.ie> wrote:
> 
> On my mid-2015 Macbook Pro with OS X.11.5 I have been trying to move my code
> from DarwinX8664 ccl 1.10 r16196 to ccl 1.11 r16635.
> 
> I have a problem with some code I contributed a few years back, clickable.lisp.
> Specifically it uses gui::find-or-make-hemlock-view and then  (hold your noses here)
> changes the ns:isa slot of the window to a subclass of gui::hemlock-frame and
> changes the ns:isa slot of the document to a subclass of guy::hemlock-editor-document.
> While the first seems to succeed, the second seems to cause a crash in ccl 1.11.
> 
> I notice that the original contents of these ns:isa slots are now foreign pointers, whereas previously in ccl 1.10 they were ns class objects. I also notice that sometime between
> my developing that code and ccl 1.10 coming along, a change was made to the
> hemlock-frame?s ns:isa to be a #<NS-OBJECT NSKVONotifying_HemlockFrame ?>.
> 
> So I have a few questions, I?d love to hear your helpful answers!
> 
> Is there a better way to get the effect of change-class on a NS object than to change its NS:ISA slot?
> 
> If I am to change the slot, what sort of value should be used? If a foreign pointer, then
> how do I make an appropriate one (I only know of ccl::%int-to-ptr but that probably isn?t
> appropriate and if it is then I don?t know how to get the appropriate int)
> 
> Where is that NSKVONotifying_HemlockFrame defined? Where is it used? Searches of the ccl files don?t show me anything relevant.

When you see an Objective-C class with a name starting with NSKVONotifying_, it?s because Key-Value Observing has swizzled the isa of the class itself to intercept getter/setter calls and post notifications to observers on its behalf. This can happen for any instance of a class that is observed, and of course Cocoa itself can add observers, they don?t just have to be in developer code.

That would probably also explain why your own isa-swizzling has stopped working, whatever change to the isa you?re making isn?t compatible with KVO?s own changes to the isa.

  -- Chris



From arthur.cater at ucd.ie  Thu Oct 13 09:58:03 2016
From: arthur.cater at ucd.ie (Arthur Cater)
Date: Thu, 13 Oct 2016 17:58:03 +0100
Subject: [Openmcl-devel] Hemlock and its documents and windows
In-Reply-To: <C3072351-A19B-4B81-99FF-691400081782@eschatologist.net>
References: <24A59692-C19F-4900-830A-B091C7E4C9DE@ucd.ie>
 <C3072351-A19B-4B81-99FF-691400081782@eschatologist.net>
Message-ID: <E4D1945E-473C-4A88-AD19-F83C4F94E478@ucd.ie>

Thank you Chris for the info about NSKVONotifying_?

Now I understand a little more. However it seems to me that searching the CCL
sources ought to show up uses of NS functions containing ?keyPath? or ?key-path?,
and I found a very few but none seemed related to Hemlock. From which I suppose
I must conclude that the notifying change probably occurred when I got beyond
Snow Leopard, and I just never noticed because things were still working.

The code compiled using CCL1.10 works while the same compiled using CCL1.11
doesn?t, despite the machine (& hence OS configuration) being identical. This
suggests to me that it?s a change in CCL rather than anything the OS has started to
do which is the root of my problem, and what I notice is that the CCL1.11 NS objects
have foreign pointers in their ISA slots, the CCL1.10 don?t.

I can?t see a change in the Hemlock code that causes foreign pointers to be used
in place of NS classes (I used the source comparison tool on the ccl1.10 and ccl1.11
to look). Maybe I?m being blind to something obvious to others. It happens.

Arthur

> On Oct 13, 2016, at 2:58 AM, Chris Hanson <cmhanson at eschatologist.net> wrote:
> 
> On Oct 12, 2016, at 7:43 AM, Arthur Cater <arthur.cater at ucd.ie> wrote:
>> 
>> On my mid-2015 Macbook Pro with OS X.11.5 I have been trying to move my code
>> from DarwinX8664 ccl 1.10 r16196 to ccl 1.11 r16635.
>> 
>> I have a problem with some code I contributed a few years back, clickable.lisp.
>> Specifically it uses gui::find-or-make-hemlock-view and then  (hold your noses here)
>> changes the ns:isa slot of the window to a subclass of gui::hemlock-frame and
>> changes the ns:isa slot of the document to a subclass of guy::hemlock-editor-document.
>> While the first seems to succeed, the second seems to cause a crash in ccl 1.11.
>> 
>> I notice that the original contents of these ns:isa slots are now foreign pointers, whereas previously in ccl 1.10 they were ns class objects. I also notice that sometime between
>> my developing that code and ccl 1.10 coming along, a change was made to the
>> hemlock-frame?s ns:isa to be a #<NS-OBJECT NSKVONotifying_HemlockFrame ?>.
>> 
>> So I have a few questions, I?d love to hear your helpful answers!
>> 
>> Is there a better way to get the effect of change-class on a NS object than to change its NS:ISA slot?
>> 
>> If I am to change the slot, what sort of value should be used? If a foreign pointer, then
>> how do I make an appropriate one (I only know of ccl::%int-to-ptr but that probably isn?t
>> appropriate and if it is then I don?t know how to get the appropriate int)
>> 
>> Where is that NSKVONotifying_HemlockFrame defined? Where is it used? Searches of the ccl files don?t show me anything relevant.
> 
> When you see an Objective-C class with a name starting with NSKVONotifying_, it?s because Key-Value Observing has swizzled the isa of the class itself to intercept getter/setter calls and post notifications to observers on its behalf. This can happen for any instance of a class that is observed, and of course Cocoa itself can add observers, they don?t just have to be in developer code.
> 
> That would probably also explain why your own isa-swizzling has stopped working, whatever change to the isa you?re making isn?t compatible with KVO?s own changes to the isa.
> 
>  -- Chris
> 



From arthur.cater at ucd.ie  Thu Oct 13 10:06:00 2016
From: arthur.cater at ucd.ie (Arthur Cater)
Date: Thu, 13 Oct 2016 18:06:00 +0100
Subject: [Openmcl-devel] issues with search-files dialog
Message-ID: <6FAE858E-4CC8-435A-9FCC-A298F5F062F8@ucd.ie>

Hello, me again but different issue.
On my Macbook Pro with OS X.11.5, using the search-files dialog (via cmd-shift-f) is sometimes behaving oddly.

a) conducting a second search, changing the search string, sometimes does not displace the results of the first search.

b) conducting a second search, sometimes causes the window to shrink to around a third of its previous size, trying to resize it causes it then to become around two thirds of its previous size.

c) doing a search of ccl sources sometimes behaves as I?d expect, and sometimes claims to find hundreds of thousands of matches, expanding results shows that every line of a file is present as a match.

I attach a screenshot of a newly-started run with
   ./dx86cl64 ?no-init 
   (require :cocoa)
   and a search.


Should I write one or more ticket?

Arthur

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20161013/6d6f41b9/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2016-10-13 at 5.36.10 PM.png
Type: image/png
Size: 261513 bytes
Desc: not available
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20161013/6d6f41b9/attachment.png>

From cmhanson at eschatologist.net  Thu Oct 13 10:07:12 2016
From: cmhanson at eschatologist.net (Chris Hanson)
Date: Thu, 13 Oct 2016 10:07:12 -0700
Subject: [Openmcl-devel] Hemlock and its documents and windows
In-Reply-To: <E4D1945E-473C-4A88-AD19-F83C4F94E478@ucd.ie>
References: <24A59692-C19F-4900-830A-B091C7E4C9DE@ucd.ie>
 <C3072351-A19B-4B81-99FF-691400081782@eschatologist.net>
 <E4D1945E-473C-4A88-AD19-F83C4F94E478@ucd.ie>
Message-ID: <5F9A3B55-D32F-4B35-A84D-1580901C4821@eschatologist.net>

It could be a behavior change in the system frameworks due to the SDK against which 1.11 is compiled against vs 1.10. When you link an executable, the version of the SDK used is encoded in it. That lets newer versions of the OS preserve old behaviors for binary compatibility. If CCL 1.11 was linked against a newer SDK that could this result in behavior changes for otherwise identical code.

  -- Chris

Sent from my iPad

> On Oct 13, 2016, at 9:58 AM, Arthur Cater <arthur.cater at ucd.ie> wrote:
> 
> Thank you Chris for the info about NSKVONotifying_?
> 
> Now I understand a little more. However it seems to me that searching the CCL
> sources ought to show up uses of NS functions containing ?keyPath? or ?key-path?,
> and I found a very few but none seemed related to Hemlock. From which I suppose
> I must conclude that the notifying change probably occurred when I got beyond
> Snow Leopard, and I just never noticed because things were still working.
> 
> The code compiled using CCL1.10 works while the same compiled using CCL1.11
> doesn?t, despite the machine (& hence OS configuration) being identical. This
> suggests to me that it?s a change in CCL rather than anything the OS has started to
> do which is the root of my problem, and what I notice is that the CCL1.11 NS objects
> have foreign pointers in their ISA slots, the CCL1.10 don?t.
> 
> I can?t see a change in the Hemlock code that causes foreign pointers to be used
> in place of NS classes (I used the source comparison tool on the ccl1.10 and ccl1.11
> to look). Maybe I?m being blind to something obvious to others. It happens.
> 
> Arthur
> 
>> On Oct 13, 2016, at 2:58 AM, Chris Hanson <cmhanson at eschatologist.net> wrote:
>> 
>> On Oct 12, 2016, at 7:43 AM, Arthur Cater <arthur.cater at ucd.ie> wrote:
>>> 
>>> On my mid-2015 Macbook Pro with OS X.11.5 I have been trying to move my code
>>> from DarwinX8664 ccl 1.10 r16196 to ccl 1.11 r16635.
>>> 
>>> I have a problem with some code I contributed a few years back, clickable.lisp.
>>> Specifically it uses gui::find-or-make-hemlock-view and then  (hold your noses here)
>>> changes the ns:isa slot of the window to a subclass of gui::hemlock-frame and
>>> changes the ns:isa slot of the document to a subclass of guy::hemlock-editor-document.
>>> While the first seems to succeed, the second seems to cause a crash in ccl 1.11.
>>> 
>>> I notice that the original contents of these ns:isa slots are now foreign pointers, whereas previously in ccl 1.10 they were ns class objects. I also notice that sometime between
>>> my developing that code and ccl 1.10 coming along, a change was made to the
>>> hemlock-frame?s ns:isa to be a #<NS-OBJECT NSKVONotifying_HemlockFrame ?>.
>>> 
>>> So I have a few questions, I?d love to hear your helpful answers!
>>> 
>>> Is there a better way to get the effect of change-class on a NS object than to change its NS:ISA slot?
>>> 
>>> If I am to change the slot, what sort of value should be used? If a foreign pointer, then
>>> how do I make an appropriate one (I only know of ccl::%int-to-ptr but that probably isn?t
>>> appropriate and if it is then I don?t know how to get the appropriate int)
>>> 
>>> Where is that NSKVONotifying_HemlockFrame defined? Where is it used? Searches of the ccl files don?t show me anything relevant.
>> 
>> When you see an Objective-C class with a name starting with NSKVONotifying_, it?s because Key-Value Observing has swizzled the isa of the class itself to intercept getter/setter calls and post notifications to observers on its behalf. This can happen for any instance of a class that is observed, and of course Cocoa itself can add observers, they don?t just have to be in developer code.
>> 
>> That would probably also explain why your own isa-swizzling has stopped working, whatever change to the isa you?re making isn?t compatible with KVO?s own changes to the isa.
>> 
>> -- Chris
>> 
> 
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> https://lists.clozure.com/mailman/listinfo/openmcl-devel



From arthur.cater at ucd.ie  Thu Oct 13 10:12:08 2016
From: arthur.cater at ucd.ie (Arthur Cater)
Date: Thu, 13 Oct 2016 18:12:08 +0100
Subject: [Openmcl-devel] Hemlock and its documents and windows
In-Reply-To: <5F9A3B55-D32F-4B35-A84D-1580901C4821@eschatologist.net>
References: <24A59692-C19F-4900-830A-B091C7E4C9DE@ucd.ie>
 <C3072351-A19B-4B81-99FF-691400081782@eschatologist.net>
 <E4D1945E-473C-4A88-AD19-F83C4F94E478@ucd.ie>
 <5F9A3B55-D32F-4B35-A84D-1580901C4821@eschatologist.net>
Message-ID: <0F28D04E-14DE-4C33-A309-AACFF1330B52@ucd.ie>

Aaaargh!

> On Oct 13, 2016, at 6:07 PM, Chris Hanson <cmhanson at eschatologist.net> wrote:
> 
> It could be a behavior change in the system frameworks due to the SDK against which 1.11 is compiled against vs 1.10. When you link an executable, the version of the SDK used is encoded in it. That lets newer versions of the OS preserve old behaviors for binary compatibility. If CCL 1.11 was linked against a newer SDK that could this result in behavior changes for otherwise identical code.
> 
>  -- Chris
> 
> Sent from my iPad
> 
>> On Oct 13, 2016, at 9:58 AM, Arthur Cater <arthur.cater at ucd.ie> wrote:
>> 
>> Thank you Chris for the info about NSKVONotifying_?
>> 
>> Now I understand a little more. However it seems to me that searching the CCL
>> sources ought to show up uses of NS functions containing ?keyPath? or ?key-path?,
>> and I found a very few but none seemed related to Hemlock. From which I suppose
>> I must conclude that the notifying change probably occurred when I got beyond
>> Snow Leopard, and I just never noticed because things were still working.
>> 
>> The code compiled using CCL1.10 works while the same compiled using CCL1.11
>> doesn?t, despite the machine (& hence OS configuration) being identical. This
>> suggests to me that it?s a change in CCL rather than anything the OS has started to
>> do which is the root of my problem, and what I notice is that the CCL1.11 NS objects
>> have foreign pointers in their ISA slots, the CCL1.10 don?t.
>> 
>> I can?t see a change in the Hemlock code that causes foreign pointers to be used
>> in place of NS classes (I used the source comparison tool on the ccl1.10 and ccl1.11
>> to look). Maybe I?m being blind to something obvious to others. It happens.
>> 
>> Arthur
>> 
>>> On Oct 13, 2016, at 2:58 AM, Chris Hanson <cmhanson at eschatologist.net> wrote:
>>> 
>>> On Oct 12, 2016, at 7:43 AM, Arthur Cater <arthur.cater at ucd.ie> wrote:
>>>> 
>>>> On my mid-2015 Macbook Pro with OS X.11.5 I have been trying to move my code
>>>> from DarwinX8664 ccl 1.10 r16196 to ccl 1.11 r16635.
>>>> 
>>>> I have a problem with some code I contributed a few years back, clickable.lisp.
>>>> Specifically it uses gui::find-or-make-hemlock-view and then  (hold your noses here)
>>>> changes the ns:isa slot of the window to a subclass of gui::hemlock-frame and
>>>> changes the ns:isa slot of the document to a subclass of guy::hemlock-editor-document.
>>>> While the first seems to succeed, the second seems to cause a crash in ccl 1.11.
>>>> 
>>>> I notice that the original contents of these ns:isa slots are now foreign pointers, whereas previously in ccl 1.10 they were ns class objects. I also notice that sometime between
>>>> my developing that code and ccl 1.10 coming along, a change was made to the
>>>> hemlock-frame?s ns:isa to be a #<NS-OBJECT NSKVONotifying_HemlockFrame ?>.
>>>> 
>>>> So I have a few questions, I?d love to hear your helpful answers!
>>>> 
>>>> Is there a better way to get the effect of change-class on a NS object than to change its NS:ISA slot?
>>>> 
>>>> If I am to change the slot, what sort of value should be used? If a foreign pointer, then
>>>> how do I make an appropriate one (I only know of ccl::%int-to-ptr but that probably isn?t
>>>> appropriate and if it is then I don?t know how to get the appropriate int)
>>>> 
>>>> Where is that NSKVONotifying_HemlockFrame defined? Where is it used? Searches of the ccl files don?t show me anything relevant.
>>> 
>>> When you see an Objective-C class with a name starting with NSKVONotifying_, it?s because Key-Value Observing has swizzled the isa of the class itself to intercept getter/setter calls and post notifications to observers on its behalf. This can happen for any instance of a class that is observed, and of course Cocoa itself can add observers, they don?t just have to be in developer code.
>>> 
>>> That would probably also explain why your own isa-swizzling has stopped working, whatever change to the isa you?re making isn?t compatible with KVO?s own changes to the isa.
>>> 
>>> -- Chris
>>> 
>> 
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> https://lists.clozure.com/mailman/listinfo/openmcl-devel
> 



From plkrueger at comcast.net  Thu Oct 13 10:16:59 2016
From: plkrueger at comcast.net (Paul Krueger)
Date: Thu, 13 Oct 2016 12:16:59 -0500
Subject: [Openmcl-devel] issues with search-files dialog
In-Reply-To: <6FAE858E-4CC8-435A-9FCC-A298F5F062F8@ucd.ie>
References: <6FAE858E-4CC8-435A-9FCC-A298F5F062F8@ucd.ie>
Message-ID: <83EB32B0-22C7-4714-AFD6-F5783E9C4F06@comcast.net>

I?ve run into this behavior (a and c) and I believe it is caused by entering a search string and then clicking the search button without first exiting the search string field. In theory the dialog window should ensure that when the button is pushed that every field entry is finalized so that the new search string is actually read, but it clearly does not do that. Thus you get the results from the previous string, which if null matches every line in all files. So this is a bug in the interface code for this window. The work-around is just to be sure to tab out of a field before hitting the search button. I don?t believe that I?ve seen the behavior you describe in b.

> On Oct 13, 2016, at 12:06 PM, Arthur Cater <arthur.cater at ucd.ie> wrote:
> 
> Hello, me again but different issue.
> On my Macbook Pro with OS X.11.5, using the search-files dialog (via cmd-shift-f) is sometimes behaving oddly.
> 
> a) conducting a second search, changing the search string, sometimes does not displace the results of the first search.
> 
> b) conducting a second search, sometimes causes the window to shrink to around a third of its previous size, trying to resize it causes it then to become around two thirds of its previous size.
> 
> c) doing a search of ccl sources sometimes behaves as I?d expect, and sometimes claims to find hundreds of thousands of matches, expanding results shows that every line of a file is present as a match.
> 
> I attach a screenshot of a newly-started run with
>    ./dx86cl64 ?no-init 
>    (require :cocoa)
>    and a search.
> 
> <Screen Shot 2016-10-13 at 5.36.10 PM.png>
> Should I write one or more ticket?
> 
> Arthur
> 
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> https://lists.clozure.com/mailman/listinfo/openmcl-devel



From arthur.cater at ucd.ie  Thu Oct 13 12:20:47 2016
From: arthur.cater at ucd.ie (Arthur Cater)
Date: Thu, 13 Oct 2016 20:20:47 +0100
Subject: [Openmcl-devel] issues with search-files dialog
In-Reply-To: <83EB32B0-22C7-4714-AFD6-F5783E9C4F06@comcast.net>
References: <6FAE858E-4CC8-435A-9FCC-A298F5F062F8@ucd.ie>
 <83EB32B0-22C7-4714-AFD6-F5783E9C4F06@comcast.net>
Message-ID: <55325B56-3D6D-47A9-AC4D-5F2684B07C74@ucd.ie>

Thank you Paul for the (partial) affirmation, diagnosis and remedy.
Arthur

> On Oct 13, 2016, at 6:16 PM, Paul Krueger <plkrueger at comcast.net> wrote:
> 
> I?ve run into this behavior (a and c) and I believe it is caused by entering a search string and then clicking the search button without first exiting the search string field. In theory the dialog window should ensure that when the button is pushed that every field entry is finalized so that the new search string is actually read, but it clearly does not do that. Thus you get the results from the previous string, which if null matches every line in all files. So this is a bug in the interface code for this window. The work-around is just to be sure to tab out of a field before hitting the search button. I don?t believe that I?ve seen the behavior you describe in b.
> 
>> On Oct 13, 2016, at 12:06 PM, Arthur Cater <arthur.cater at ucd.ie> wrote:
>> 
>> Hello, me again but different issue.
>> On my Macbook Pro with OS X.11.5, using the search-files dialog (via cmd-shift-f) is sometimes behaving oddly.
>> 
>> a) conducting a second search, changing the search string, sometimes does not displace the results of the first search.
>> 
>> b) conducting a second search, sometimes causes the window to shrink to around a third of its previous size, trying to resize it causes it then to become around two thirds of its previous size.
>> 
>> c) doing a search of ccl sources sometimes behaves as I?d expect, and sometimes claims to find hundreds of thousands of matches, expanding results shows that every line of a file is present as a match.
>> 
>> I attach a screenshot of a newly-started run with
>>   ./dx86cl64 ?no-init 
>>   (require :cocoa)
>>   and a search.
>> 
>> <Screen Shot 2016-10-13 at 5.36.10 PM.png>
>> Should I write one or more ticket?
>> 
>> Arthur
>> 
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> https://lists.clozure.com/mailman/listinfo/openmcl-devel
> 



From arthur.cater at ucd.ie  Thu Oct 13 12:31:51 2016
From: arthur.cater at ucd.ie (Arthur Cater)
Date: Thu, 13 Oct 2016 20:31:51 +0100
Subject: [Openmcl-devel] runtime warnings
Message-ID: <1947005C-9FE8-46A4-906E-FF80F917FE25@ucd.ie>

Sorry if you?re getting tired of hearing from me.

After running ./dx86cl64 ?no-init and loading cocoa, same session, I was trying out Paul?s advice to tab out of the search field. After a while I noticed that the Terminal window was accumulating messages, many more than the excerpt below. Something odd, is it me?

Arthur

(I?ve snipped this at both ends)

;Loading #P"ccl:cocoa-ide;fasls;start.dx64fsl.newest"...
;Loading #P"ccl:cocoa-ide;fasls;xinspector.dx64fsl.newest"...
:COCOA
("IDE-BUNDLE" "OBJC-PACKAGE" "SEQUENCE-UTILS" "NAME-TRANSLATION" "OBJC-CLOS" "OBJC-RUNTIME" "BRIDGE" "OBJC-SUPPORT" "COMPILE-HEMLOCK" "HEMLOCK" "uiop" "UIOP" "asdf" "ASDF" "COCOA")
? 2016-10-13 17:33:11.093 dx86cl64[54312:8154542] Failed to connect (searchCommentsCheckbox) outlet from (SearchFilesWindowController) to (NSButton): missing setter or instance variable
CoreAnimation: warning, deleted thread with uncommitted CATransaction; set CA_DEBUG_TRANSACTIONS=1 in environment to log backtraces.
2016-10-13 20:21:16.012 dx86cl64[54312:8175761] This application is modifying the autolayout engine from a background thread, which can lead to engine corruption and weird crashes.  This will cause an exception in a future release.
 Stack:(
	0   CoreFoundation                      0x00007fff8e4cf4f2 __exceptionPreprocess + 178
	1   libobjc.A.dylib                     0x00007fff90e57f7e objc_exception_throw + 48
	2   CoreFoundation                      0x00007fff8e5364bd +[NSException raise:format:] + 205
	3   Foundation                          0x00007fff8e0c51f1 _AssertAutolayoutOnMainThreadOnly + 79
	4   Foundation                          0x00007fff8e0c5046 -[NSISEngine withBehaviors:performModifications:] + 31
	5   AppKit                              0x00007fff936ba05e -[NSWindow(NSConstraintBasedLayout) _fromConstraintsGetWindowMinSize:maxSize:allowDynamicLayout:] + 568
	6   AppKit                              0x00007fff936b9d9b -[NSWindow(NSConstraintBasedLayout) _getConstrainedWindowMinSize:maxSize:] + 47
	7   AppKit                              0x00007fff936dd731 -[NSWindow(NSWindowResizing) _resizableEdgesForGrowing:shrinking:] + 171
	8   AppKit                              0x00007fff936dcd95 -[NSWindow(NSWindowResizing) _getEdgeResizingRects:] + 439
	9   AppKit                              0x00007fff936dcadd -[NSTitledFrame regionForOpaqueDescentsModifiedForResizing:] + 119
	10  AppKit                              0x00007fff936ddd97 -[NSTitledFrame _regionForOpaqueDescendants:forMove:forUnderTitlebar:] + 143
	11  AppKit                              0x00007fff936db007 -[NSThemeFrame _regionForOpaqueDescendants:forMove:forUnderTitlebar:] + 227
	12  AppKit                              0x00007fff936daf1c -[NSView _regionForOpaqueDescendants:forMove:] + 58
	13  AppKit                              0x00007fff937c84c2 -[NSView(NSWindowBorderView) _copyDragRegion] + 115
	14  AppKit                              0x00007fff937c8338 -[NSFrameView _resetDragMargins] + 160
	15  AppKit                              0x00007fff936d9913 -[NSThemeFrame _resetDragMargins] + 221
	16  AppKit                              0x00007fff936c3f16 -[NSThemeFrame _tileTitlebarAndRedisplay:] + 287
	17  AppKit                              0x00007fff93726baf -[NSTitledFrame _titleDidChange] + 217
	18  AppKit                              0x00007fff937264fe -[NSTitledFrame setTitle:] + 1205
	19  AppKit                              0x00007fff93725f9c -[NSThemeFrame setTitle:] + 47
	20  AppKit                              0x00007fff93725daa -[NSWindow _dosetTitle:andDefeatWrap:] + 319
	21  dx86cl64                            0x000000000001bbf3 ffcall_return + 0
)
2016-10-13 20:21:16.013 dx86cl64[54312:8175761] This application is modifying the autolayout engine from a background thread, which can lead to engine corruption and weird crashes.  This will cause an exception in a future release.
 Stack:(
	0   CoreFoundation                      0x00007fff8e4cf4f2 __exceptionPreprocess + 178
	1   libobjc.A.dylib                     0x00007fff90e57f7e objc_exception_throw + 48
	2   CoreFoundation                      0x00007fff8e5364bd +[NSException raise:format:] + 205
	3   Foundation                          0x00007fff8e0c51f1 _AssertAutolayoutOnMainThreadOnly + 79
	4   Foundation                          0x00007fff8e0c5046 -[NSISEngine withBehaviors:performModifications:] + 31
	5   AppKit                              0x00007fff9375286b __97-[NSWindow(NSConstraintBasedLayout) _fromConstraintsGetWindowMinSize:maxSize:allowDynamicLayout:]_block_invoke + 282
	6   Foundation                          0x00007fff8e0c50c2 -[NSISEngine withBehaviors:performModifications:] + 155
	7   AppKit                              0x00007fff936ba05e -[NSWindow(NSConstraintBasedLayout) _fromConstraintsGetWindowMinSize:maxSize:allowDynamicLayout:] + 568
	8   AppKit                              0x00007fff936b9d9b -[NSWindow(NSConstraintBasedLayout) _getConstrainedWindowMinSize:maxSize:] + 47
	9   AppKit                              0x00007fff936dd731 -[NSWindow(NSWindowResizing) _resizableEdgesForGrowing:shrinking:] + 171
	10  AppKit                              0x00007fff936dcd95 -[NSWindow(NSWindowResizing) _getEdgeResizingRects:] + 439
	11  AppKit                              0x00007fff936dcadd -[NSTitledFrame regionForOpaqueDescentsModifiedForResizing:] + 119
	12  AppKit                              0x00007fff936ddd97 -[NSTitledFrame _regionForOpaqueDescendants:forMove:forUnderTitlebar:] + 143
	13  AppKit                              0x00007fff936db007 -[NSThemeFrame _regionForOpaqueDescendants:forMove:forUnderTitlebar:] + 227
	14  AppKit                              0x00007fff936daf1c -[NSView _regionForOpaqueDescendants:forMove:] + 58
	15  AppKit                              0x00007fff937c84c2 -[NSView(NSWindowBorderView) _copyDragRegion] + 115
	16  AppKit                              0x00007fff937c8338 -[NSFrameView _resetDragMargins] + 160
	17  AppKit                              0x00007fff936d9913 -[NSThemeFrame _resetDragMargins] + 221
	18  AppKit                              0x00007fff936c3f16 -[NSThemeFrame _tileTitlebarAndRedisplay:] + 287
	19  AppKit                              0x00007fff93726baf -[NSTitledFrame _titleDidChange] + 217
	20  AppKit                              0x00007fff937264fe -[NSTitledFrame setTitle:] + 1205
	21  AppKit                              0x00007fff93725f9c -[NSThemeFrame setTitle:] + 47
	22  AppKit                              0x00007fff93725daa -[NSWindow _dosetTitle:andDefeatWrap:] + 319
	23  dx86cl64                            0x000000000001bbf3 ffcall_return + 0
)
2016-10-13 20:21:16.015 dx86cl64[54312:8175761] This application is modifying the autolayout engine from a background thread, which can lead to engine corruption and weird crashes.  This will cause an exception in a future release.
 Stack:(
	0   CoreFoundation                      0x00007fff8e4cf4f2 __exceptionPreprocess + 178
	1   libobjc.A.dylib                     0x00007fff90e57f7e objc_exception_throw + 48
	2   CoreFoundation                      0x00007fff8e5364bd +[NSException raise:format:] + 205
	3   Foundation                          0x00007fff8e0c51f1 _AssertAutolayoutOnMainThreadOnly + 79
	4   Foundation                          0x00007fff8e0cbf54 -[NSISEngine optimize] + 49
	5   Foundation                          0x00007fff8e0c511b -[NSISEngine withBehaviors:performModifications:] + 244

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20161013/516fe756/attachment.htm>

From plkrueger at comcast.net  Thu Oct 13 14:51:00 2016
From: plkrueger at comcast.net (Paul Krueger)
Date: Thu, 13 Oct 2016 16:51:00 -0500
Subject: [Openmcl-devel] runtime warnings
In-Reply-To: <1947005C-9FE8-46A4-906E-FF80F917FE25@ucd.ie>
References: <1947005C-9FE8-46A4-906E-FF80F917FE25@ucd.ie>
Message-ID: <A047A2F4-397E-4F16-8823-4C26448F7981@comcast.net>

The theme here is caught by the "This application is modifying the autolayout engine from a background thread ?? part of the messages. Over time, Apple has made more and more use of autolayout inside of its own interface objects. I (and I?m sure many others) have learned through hard experience that doing almost anything that affects the autolayout system on any thread other than the main thread is a recipe for crashes or other forms of aberrant behavior. As new versions of core libraries make more use of autolayout code for previously existing object classes, it becomes necessary for users of those objects to ensure that their code also runs on the main thread. These messages are simply informing us that this isn?t happening (which at some time in the future might turn into a runtime error) and the stack trace can help to identify the relevant code. As a matter of course I now do all interface code inside a call to ccl::call-in-event-process.

I have a little macro that makes that a bit easier for me:

(defmacro on-main-thread (&rest actions)
  `(ccl::call-in-event-process
     #'(lambda ()
         , at actions)))

I don?t know exactly where this should be used in your case; but given when you are seeing the messages it sounds like maybe it is in the ccl code for the search window.

> On Oct 13, 2016, at 2:31 PM, Arthur Cater <arthur.cater at ucd.ie> wrote:
> 
> Sorry if you?re getting tired of hearing from me.
> 
> After running ./dx86cl64 ?no-init and loading cocoa, same session, I was trying out Paul?s advice to tab out of the search field. After a while I noticed that the Terminal window was accumulating messages, many more than the excerpt below. Something odd, is it me?
> 
> Arthur
> 
> (I?ve snipped this at both ends)
> 
> ;Loading #P"ccl:cocoa-ide;fasls;start.dx64fsl.newest"...
> ;Loading #P"ccl:cocoa-ide;fasls;xinspector.dx64fsl.newest"...
> :COCOA
> ("IDE-BUNDLE" "OBJC-PACKAGE" "SEQUENCE-UTILS" "NAME-TRANSLATION" "OBJC-CLOS" "OBJC-RUNTIME" "BRIDGE" "OBJC-SUPPORT" "COMPILE-HEMLOCK" "HEMLOCK" "uiop" "UIOP" "asdf" "ASDF" "COCOA")
> ? 2016-10-13 17:33:11.093 dx86cl64[54312:8154542] Failed to connect (searchCommentsCheckbox) outlet from (SearchFilesWindowController) to (NSButton): missing setter or instance variable
> CoreAnimation: warning, deleted thread with uncommitted CATransaction; set CA_DEBUG_TRANSACTIONS=1 in environment to log backtraces.
> 2016-10-13 20:21:16.012 dx86cl64[54312:8175761] This application is modifying the autolayout engine from a background thread, which can lead to engine corruption and weird crashes.  This will cause an exception in a future release.
>  Stack:(
> 	0   CoreFoundation                      0x00007fff8e4cf4f2 __exceptionPreprocess + 178
> 	1   libobjc.A.dylib                     0x00007fff90e57f7e objc_exception_throw + 48
> 	2   CoreFoundation                      0x00007fff8e5364bd +[NSException raise:format:] + 205
> 	3   Foundation                          0x00007fff8e0c51f1 _AssertAutolayoutOnMainThreadOnly + 79
> 	4   Foundation                          0x00007fff8e0c5046 -[NSISEngine withBehaviors:performModifications:] + 31
> 	5   AppKit                              0x00007fff936ba05e -[NSWindow(NSConstraintBasedLayout) _fromConstraintsGetWindowMinSize:maxSize:allowDynamicLayout:] + 568
> 	6   AppKit                              0x00007fff936b9d9b -[NSWindow(NSConstraintBasedLayout) _getConstrainedWindowMinSize:maxSize:] + 47
> 	7   AppKit                              0x00007fff936dd731 -[NSWindow(NSWindowResizing) _resizableEdgesForGrowing:shrinking:] + 171
> 	8   AppKit                              0x00007fff936dcd95 -[NSWindow(NSWindowResizing) _getEdgeResizingRects:] + 439
> 	9   AppKit                              0x00007fff936dcadd -[NSTitledFrame regionForOpaqueDescentsModifiedForResizing:] + 119
> 	10  AppKit                              0x00007fff936ddd97 -[NSTitledFrame _regionForOpaqueDescendants:forMove:forUnderTitlebar:] + 143
> 	11  AppKit                              0x00007fff936db007 -[NSThemeFrame _regionForOpaqueDescendants:forMove:forUnderTitlebar:] + 227
> 	12  AppKit                              0x00007fff936daf1c -[NSView _regionForOpaqueDescendants:forMove:] + 58
> 	13  AppKit                              0x00007fff937c84c2 -[NSView(NSWindowBorderView) _copyDragRegion] + 115
> 	14  AppKit                              0x00007fff937c8338 -[NSFrameView _resetDragMargins] + 160
> 	15  AppKit                              0x00007fff936d9913 -[NSThemeFrame _resetDragMargins] + 221
> 	16  AppKit                              0x00007fff936c3f16 -[NSThemeFrame _tileTitlebarAndRedisplay:] + 287
> 	17  AppKit                              0x00007fff93726baf -[NSTitledFrame _titleDidChange] + 217
> 	18  AppKit                              0x00007fff937264fe -[NSTitledFrame setTitle:] + 1205
> 	19  AppKit                              0x00007fff93725f9c -[NSThemeFrame setTitle:] + 47
> 	20  AppKit                              0x00007fff93725daa -[NSWindow _dosetTitle:andDefeatWrap:] + 319
> 	21  dx86cl64                            0x000000000001bbf3 ffcall_return + 0
> )
> 2016-10-13 20:21:16.013 dx86cl64[54312:8175761] This application is modifying the autolayout engine from a background thread, which can lead to engine corruption and weird crashes.  This will cause an exception in a future release.
>  Stack:(
> 	0   CoreFoundation                      0x00007fff8e4cf4f2 __exceptionPreprocess + 178
> 	1   libobjc.A.dylib                     0x00007fff90e57f7e objc_exception_throw + 48
> 	2   CoreFoundation                      0x00007fff8e5364bd +[NSException raise:format:] + 205
> 	3   Foundation                          0x00007fff8e0c51f1 _AssertAutolayoutOnMainThreadOnly + 79
> 	4   Foundation                          0x00007fff8e0c5046 -[NSISEngine withBehaviors:performModifications:] + 31
> 	5   AppKit                              0x00007fff9375286b __97-[NSWindow(NSConstraintBasedLayout) _fromConstraintsGetWindowMinSize:maxSize:allowDynamicLayout:]_block_invoke + 282
> 	6   Foundation                          0x00007fff8e0c50c2 -[NSISEngine withBehaviors:performModifications:] + 155
> 	7   AppKit                              0x00007fff936ba05e -[NSWindow(NSConstraintBasedLayout) _fromConstraintsGetWindowMinSize:maxSize:allowDynamicLayout:] + 568
> 	8   AppKit                              0x00007fff936b9d9b -[NSWindow(NSConstraintBasedLayout) _getConstrainedWindowMinSize:maxSize:] + 47
> 	9   AppKit                              0x00007fff936dd731 -[NSWindow(NSWindowResizing) _resizableEdgesForGrowing:shrinking:] + 171
> 	10  AppKit                              0x00007fff936dcd95 -[NSWindow(NSWindowResizing) _getEdgeResizingRects:] + 439
> 	11  AppKit                              0x00007fff936dcadd -[NSTitledFrame regionForOpaqueDescentsModifiedForResizing:] + 119
> 	12  AppKit                              0x00007fff936ddd97 -[NSTitledFrame _regionForOpaqueDescendants:forMove:forUnderTitlebar:] + 143
> 	13  AppKit                              0x00007fff936db007 -[NSThemeFrame _regionForOpaqueDescendants:forMove:forUnderTitlebar:] + 227
> 	14  AppKit                              0x00007fff936daf1c -[NSView _regionForOpaqueDescendants:forMove:] + 58
> 	15  AppKit                              0x00007fff937c84c2 -[NSView(NSWindowBorderView) _copyDragRegion] + 115
> 	16  AppKit                              0x00007fff937c8338 -[NSFrameView _resetDragMargins] + 160
> 	17  AppKit                              0x00007fff936d9913 -[NSThemeFrame _resetDragMargins] + 221
> 	18  AppKit                              0x00007fff936c3f16 -[NSThemeFrame _tileTitlebarAndRedisplay:] + 287
> 	19  AppKit                              0x00007fff93726baf -[NSTitledFrame _titleDidChange] + 217
> 	20  AppKit                              0x00007fff937264fe -[NSTitledFrame setTitle:] + 1205
> 	21  AppKit                              0x00007fff93725f9c -[NSThemeFrame setTitle:] + 47
> 	22  AppKit                              0x00007fff93725daa -[NSWindow _dosetTitle:andDefeatWrap:] + 319
> 	23  dx86cl64                            0x000000000001bbf3 ffcall_return + 0
> )
> 2016-10-13 20:21:16.015 dx86cl64[54312:8175761] This application is modifying the autolayout engine from a background thread, which can lead to engine corruption and weird crashes.  This will cause an exception in a future release.
>  Stack:(
> 	0   CoreFoundation                      0x00007fff8e4cf4f2 __exceptionPreprocess + 178
> 	1   libobjc.A.dylib                     0x00007fff90e57f7e objc_exception_throw + 48
> 	2   CoreFoundation                      0x00007fff8e5364bd +[NSException raise:format:] + 205
> 	3   Foundation                          0x00007fff8e0c51f1 _AssertAutolayoutOnMainThreadOnly + 79
> 	4   Foundation                          0x00007fff8e0cbf54 -[NSISEngine optimize] + 49
> 	5   Foundation                          0x00007fff8e0c511b -[NSISEngine withBehaviors:performModifications:] + 244
> 
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> https://lists.clozure.com/mailman/listinfo/openmcl-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20161013/d00e36cb/attachment.htm>

From arthur.cater at ucd.ie  Fri Oct 14 03:41:33 2016
From: arthur.cater at ucd.ie (Arthur Cater)
Date: Fri, 14 Oct 2016 11:41:33 +0100
Subject: [Openmcl-devel] runtime warnings
In-Reply-To: <A047A2F4-397E-4F16-8823-4C26448F7981@comcast.net>
References: <1947005C-9FE8-46A4-906E-FF80F917FE25@ucd.ie>
 <A047A2F4-397E-4F16-8823-4C26448F7981@comcast.net>
Message-ID: <CA8F6A18-2AB6-41BC-8CEE-6844A0CBCAE4@ucd.ie>

Thank you Paul. I didn?t really think it was me but since nobody else had reported it here I entertained the possibility.
Arthur

> On Oct 13, 2016, at 10:51 PM, Paul Krueger <plkrueger at comcast.net> wrote:
> 
> The theme here is caught by the "This application is modifying the autolayout engine from a background thread ?? part of the messages. Over time, Apple has made more and more use of autolayout inside of its own interface objects. I (and I?m sure many others) have learned through hard experience that doing almost anything that affects the autolayout system on any thread other than the main thread is a recipe for crashes or other forms of aberrant behavior. As new versions of core libraries make more use of autolayout code for previously existing object classes, it becomes necessary for users of those objects to ensure that their code also runs on the main thread. These messages are simply informing us that this isn?t happening (which at some time in the future might turn into a runtime error) and the stack trace can help to identify the relevant code. As a matter of course I now do all interface code inside a call to ccl::call-in-event-process.
> 
> I have a little macro that makes that a bit easier for me:
> 
> (defmacro on-main-thread (&rest actions)
>   `(ccl::call-in-event-process
>      #'(lambda ()
>          , at actions)))
> 
> I don?t know exactly where this should be used in your case; but given when you are seeing the messages it sounds like maybe it is in the ccl code for the search window.
> 
>> On Oct 13, 2016, at 2:31 PM, Arthur Cater <arthur.cater at ucd.ie <mailto:arthur.cater at ucd.ie>> wrote:
>> 
>> Sorry if you?re getting tired of hearing from me.
>> 
>> After running ./dx86cl64 ?no-init and loading cocoa, same session, I was trying out Paul?s advice to tab out of the search field. After a while I noticed that the Terminal window was accumulating messages, many more than the excerpt below. Something odd, is it me?
>> 
>> Arthur
>> 
>> (I?ve snipped this at both ends)
>> 
>> ;Loading #P"ccl:cocoa-ide;fasls;start.dx64fsl.newest"...
>> ;Loading #P"ccl:cocoa-ide;fasls;xinspector.dx64fsl.newest"...
>> :COCOA
>> ("IDE-BUNDLE" "OBJC-PACKAGE" "SEQUENCE-UTILS" "NAME-TRANSLATION" "OBJC-CLOS" "OBJC-RUNTIME" "BRIDGE" "OBJC-SUPPORT" "COMPILE-HEMLOCK" "HEMLOCK" "uiop" "UIOP" "asdf" "ASDF" "COCOA")
>> ? 2016-10-13 17:33:11.093 dx86cl64[54312:8154542] Failed to connect (searchCommentsCheckbox) outlet from (SearchFilesWindowController) to (NSButton): missing setter or instance variable
>> CoreAnimation: warning, deleted thread with uncommitted CATransaction; set CA_DEBUG_TRANSACTIONS=1 in environment to log backtraces.
>> 2016-10-13 20:21:16.012 dx86cl64[54312:8175761] This application is modifying the autolayout engine from a background thread, which can lead to engine corruption and weird crashes.  This will cause an exception in a future release.
>>  Stack:(
>> 	0   CoreFoundation                      0x00007fff8e4cf4f2 __exceptionPreprocess + 178
>> 	1   libobjc.A.dylib                     0x00007fff90e57f7e objc_exception_throw + 48
>> 	2   CoreFoundation                      0x00007fff8e5364bd +[NSException raise:format:] + 205
>> 	3   Foundation                          0x00007fff8e0c51f1 _AssertAutolayoutOnMainThreadOnly + 79
>> 	4   Foundation                          0x00007fff8e0c5046 -[NSISEngine withBehaviors:performModifications:] + 31
>> 	5   AppKit                              0x00007fff936ba05e -[NSWindow(NSConstraintBasedLayout) _fromConstraintsGetWindowMinSize:maxSize:allowDynamicLayout:] + 568
>> 	6   AppKit                              0x00007fff936b9d9b -[NSWindow(NSConstraintBasedLayout) _getConstrainedWindowMinSize:maxSize:] + 47
>> 	7   AppKit                              0x00007fff936dd731 -[NSWindow(NSWindowResizing) _resizableEdgesForGrowing:shrinking:] + 171
>> 	8   AppKit                              0x00007fff936dcd95 -[NSWindow(NSWindowResizing) _getEdgeResizingRects:] + 439
>> 	9   AppKit                              0x00007fff936dcadd -[NSTitledFrame regionForOpaqueDescentsModifiedForResizing:] + 119
>> 	10  AppKit                              0x00007fff936ddd97 -[NSTitledFrame _regionForOpaqueDescendants:forMove:forUnderTitlebar:] + 143
>> 	11  AppKit                              0x00007fff936db007 -[NSThemeFrame _regionForOpaqueDescendants:forMove:forUnderTitlebar:] + 227
>> 	12  AppKit                              0x00007fff936daf1c -[NSView _regionForOpaqueDescendants:forMove:] + 58
>> 	13  AppKit                              0x00007fff937c84c2 -[NSView(NSWindowBorderView) _copyDragRegion] + 115
>> 	14  AppKit                              0x00007fff937c8338 -[NSFrameView _resetDragMargins] + 160
>> 	15  AppKit                              0x00007fff936d9913 -[NSThemeFrame _resetDragMargins] + 221
>> 	16  AppKit                              0x00007fff936c3f16 -[NSThemeFrame _tileTitlebarAndRedisplay:] + 287
>> 	17  AppKit                              0x00007fff93726baf -[NSTitledFrame _titleDidChange] + 217
>> 	18  AppKit                              0x00007fff937264fe -[NSTitledFrame setTitle:] + 1205
>> 	19  AppKit                              0x00007fff93725f9c -[NSThemeFrame setTitle:] + 47
>> 	20  AppKit                              0x00007fff93725daa -[NSWindow _dosetTitle:andDefeatWrap:] + 319
>> 	21  dx86cl64                            0x000000000001bbf3 ffcall_return + 0
>> )
>> 2016-10-13 20:21:16.013 dx86cl64[54312:8175761] This application is modifying the autolayout engine from a background thread, which can lead to engine corruption and weird crashes.  This will cause an exception in a future release.
>>  Stack:(
>> 	0   CoreFoundation                      0x00007fff8e4cf4f2 __exceptionPreprocess + 178
>> 	1   libobjc.A.dylib                     0x00007fff90e57f7e objc_exception_throw + 48
>> 	2   CoreFoundation                      0x00007fff8e5364bd +[NSException raise:format:] + 205
>> 	3   Foundation                          0x00007fff8e0c51f1 _AssertAutolayoutOnMainThreadOnly + 79
>> 	4   Foundation                          0x00007fff8e0c5046 -[NSISEngine withBehaviors:performModifications:] + 31
>> 	5   AppKit                              0x00007fff9375286b __97-[NSWindow(NSConstraintBasedLayout) _fromConstraintsGetWindowMinSize:maxSize:allowDynamicLayout:]_block_invoke + 282
>> 	6   Foundation                          0x00007fff8e0c50c2 -[NSISEngine withBehaviors:performModifications:] + 155
>> 	7   AppKit                              0x00007fff936ba05e -[NSWindow(NSConstraintBasedLayout) _fromConstraintsGetWindowMinSize:maxSize:allowDynamicLayout:] + 568
>> 	8   AppKit                              0x00007fff936b9d9b -[NSWindow(NSConstraintBasedLayout) _getConstrainedWindowMinSize:maxSize:] + 47
>> 	9   AppKit                              0x00007fff936dd731 -[NSWindow(NSWindowResizing) _resizableEdgesForGrowing:shrinking:] + 171
>> 	10  AppKit                              0x00007fff936dcd95 -[NSWindow(NSWindowResizing) _getEdgeResizingRects:] + 439
>> 	11  AppKit                              0x00007fff936dcadd -[NSTitledFrame regionForOpaqueDescentsModifiedForResizing:] + 119
>> 	12  AppKit                              0x00007fff936ddd97 -[NSTitledFrame _regionForOpaqueDescendants:forMove:forUnderTitlebar:] + 143
>> 	13  AppKit                              0x00007fff936db007 -[NSThemeFrame _regionForOpaqueDescendants:forMove:forUnderTitlebar:] + 227
>> 	14  AppKit                              0x00007fff936daf1c -[NSView _regionForOpaqueDescendants:forMove:] + 58
>> 	15  AppKit                              0x00007fff937c84c2 -[NSView(NSWindowBorderView) _copyDragRegion] + 115
>> 	16  AppKit                              0x00007fff937c8338 -[NSFrameView _resetDragMargins] + 160
>> 	17  AppKit                              0x00007fff936d9913 -[NSThemeFrame _resetDragMargins] + 221
>> 	18  AppKit                              0x00007fff936c3f16 -[NSThemeFrame _tileTitlebarAndRedisplay:] + 287
>> 	19  AppKit                              0x00007fff93726baf -[NSTitledFrame _titleDidChange] + 217
>> 	20  AppKit                              0x00007fff937264fe -[NSTitledFrame setTitle:] + 1205
>> 	21  AppKit                              0x00007fff93725f9c -[NSThemeFrame setTitle:] + 47
>> 	22  AppKit                              0x00007fff93725daa -[NSWindow _dosetTitle:andDefeatWrap:] + 319
>> 	23  dx86cl64                            0x000000000001bbf3 ffcall_return + 0
>> )
>> 2016-10-13 20:21:16.015 dx86cl64[54312:8175761] This application is modifying the autolayout engine from a background thread, which can lead to engine corruption and weird crashes.  This will cause an exception in a future release.
>>  Stack:(
>> 	0   CoreFoundation                      0x00007fff8e4cf4f2 __exceptionPreprocess + 178
>> 	1   libobjc.A.dylib                     0x00007fff90e57f7e objc_exception_throw + 48
>> 	2   CoreFoundation                      0x00007fff8e5364bd +[NSException raise:format:] + 205
>> 	3   Foundation                          0x00007fff8e0c51f1 _AssertAutolayoutOnMainThreadOnly + 79
>> 	4   Foundation                          0x00007fff8e0cbf54 -[NSISEngine optimize] + 49
>> 	5   Foundation                          0x00007fff8e0c511b -[NSISEngine withBehaviors:performModifications:] + 244
>> 
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com <mailto:Openmcl-devel at clozure.com>
>> https://lists.clozure.com/mailman/listinfo/openmcl-devel
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20161014/72df16db/attachment.htm>

From cmhanson at eschatologist.net  Sat Oct 15 15:17:47 2016
From: cmhanson at eschatologist.net (cmhanson at eschatologist.net)
Date: Sat, 15 Oct 2016 17:17:47 -0500
Subject: [Openmcl-devel] Hemlock and its documents and windows
In-Reply-To: <0F28D04E-14DE-4C33-A309-AACFF1330B52@ucd.ie>
References: <24A59692-C19F-4900-830A-B091C7E4C9DE@ucd.ie>
 <C3072351-A19B-4B81-99FF-691400081782@eschatologist.net>
 <E4D1945E-473C-4A88-AD19-F83C4F94E478@ucd.ie>
 <5F9A3B55-D32F-4B35-A84D-1580901C4821@eschatologist.net>
 <0F28D04E-14DE-4C33-A309-AACFF1330B52@ucd.ie>
Message-ID: <868D1DE7-CBD2-428E-831D-11A506AF2FE0@eschatologist.net>

I think the best thing to do would be to make this functionality work without isa-swizzling. That?s not the way you?d do it in Cocoa with ObjC or Swift, so it?s probably not what you want to do in Cocoa via CCL either.

One thing that might be useful is also abstracting the classes that are used to implement the IDE and editor, such that there?s a ?pure CLOS? class that the Cocoa class delegates to, and you can adjust which CLOS class is used easily. That could also make it more feasible to put the IDE atop, say, GTK+ on Linux or the Windows API on Windows as well.

(Maybe that?s already how things are designed, I haven?t looked too closely yet.)

  ? Chris

> On Oct 13, 2016, at 12:12 PM, Arthur Cater <arthur.cater at ucd.ie> wrote:
> 
> Aaaargh!
> 
>> On Oct 13, 2016, at 6:07 PM, Chris Hanson <cmhanson at eschatologist.net> wrote:
>> 
>> It could be a behavior change in the system frameworks due to the SDK against which 1.11 is compiled against vs 1.10. When you link an executable, the version of the SDK used is encoded in it. That lets newer versions of the OS preserve old behaviors for binary compatibility. If CCL 1.11 was linked against a newer SDK that could this result in behavior changes for otherwise identical code.
>> 
>> -- Chris
>> 
>> Sent from my iPad
>> 
>>> On Oct 13, 2016, at 9:58 AM, Arthur Cater <arthur.cater at ucd.ie> wrote:
>>> 
>>> Thank you Chris for the info about NSKVONotifying_?
>>> 
>>> Now I understand a little more. However it seems to me that searching the CCL
>>> sources ought to show up uses of NS functions containing ?keyPath? or ?key-path?,
>>> and I found a very few but none seemed related to Hemlock. From which I suppose
>>> I must conclude that the notifying change probably occurred when I got beyond
>>> Snow Leopard, and I just never noticed because things were still working.
>>> 
>>> The code compiled using CCL1.10 works while the same compiled using CCL1.11
>>> doesn?t, despite the machine (& hence OS configuration) being identical. This
>>> suggests to me that it?s a change in CCL rather than anything the OS has started to
>>> do which is the root of my problem, and what I notice is that the CCL1.11 NS objects
>>> have foreign pointers in their ISA slots, the CCL1.10 don?t.
>>> 
>>> I can?t see a change in the Hemlock code that causes foreign pointers to be used
>>> in place of NS classes (I used the source comparison tool on the ccl1.10 and ccl1.11
>>> to look). Maybe I?m being blind to something obvious to others. It happens.
>>> 
>>> Arthur
>>> 
>>>> On Oct 13, 2016, at 2:58 AM, Chris Hanson <cmhanson at eschatologist.net> wrote:
>>>> 
>>>> On Oct 12, 2016, at 7:43 AM, Arthur Cater <arthur.cater at ucd.ie> wrote:
>>>>> 
>>>>> On my mid-2015 Macbook Pro with OS X.11.5 I have been trying to move my code
>>>>> from DarwinX8664 ccl 1.10 r16196 to ccl 1.11 r16635.
>>>>> 
>>>>> I have a problem with some code I contributed a few years back, clickable.lisp.
>>>>> Specifically it uses gui::find-or-make-hemlock-view and then  (hold your noses here)
>>>>> changes the ns:isa slot of the window to a subclass of gui::hemlock-frame and
>>>>> changes the ns:isa slot of the document to a subclass of guy::hemlock-editor-document.
>>>>> While the first seems to succeed, the second seems to cause a crash in ccl 1.11.
>>>>> 
>>>>> I notice that the original contents of these ns:isa slots are now foreign pointers, whereas previously in ccl 1.10 they were ns class objects. I also notice that sometime between
>>>>> my developing that code and ccl 1.10 coming along, a change was made to the
>>>>> hemlock-frame?s ns:isa to be a #<NS-OBJECT NSKVONotifying_HemlockFrame ?>.
>>>>> 
>>>>> So I have a few questions, I?d love to hear your helpful answers!
>>>>> 
>>>>> Is there a better way to get the effect of change-class on a NS object than to change its NS:ISA slot?
>>>>> 
>>>>> If I am to change the slot, what sort of value should be used? If a foreign pointer, then
>>>>> how do I make an appropriate one (I only know of ccl::%int-to-ptr but that probably isn?t
>>>>> appropriate and if it is then I don?t know how to get the appropriate int)
>>>>> 
>>>>> Where is that NSKVONotifying_HemlockFrame defined? Where is it used? Searches of the ccl files don?t show me anything relevant.
>>>> 
>>>> When you see an Objective-C class with a name starting with NSKVONotifying_, it?s because Key-Value Observing has swizzled the isa of the class itself to intercept getter/setter calls and post notifications to observers on its behalf. This can happen for any instance of a class that is observed, and of course Cocoa itself can add observers, they don?t just have to be in developer code.
>>>> 
>>>> That would probably also explain why your own isa-swizzling has stopped working, whatever change to the isa you?re making isn?t compatible with KVO?s own changes to the isa.
>>>> 
>>>> -- Chris
>>>> 
>>> 
>>> _______________________________________________
>>> Openmcl-devel mailing list
>>> Openmcl-devel at clozure.com
>>> https://lists.clozure.com/mailman/listinfo/openmcl-devel
>> 
> 
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> https://lists.clozure.com/mailman/listinfo/openmcl-devel



From icerove at gmail.com  Mon Oct 17 22:00:03 2016
From: icerove at gmail.com (Ice Rove)
Date: Tue, 18 Oct 2016 01:00:03 -0400
Subject: [Openmcl-devel] Is it possible to call a function automatically
	when exit ccl?
Message-ID: <CAM+JFJRnSyCpXGAX=1cABPS0A__8XveMRCQTyOmNFmA+M0SOSg@mail.gmail.com>

Hello everyone,
Is it possible to call a function automatically when exit ccl? Both calling
(quit) or kill the process in shell. Just like sbcl's *exit-hook*
Sincerely,
Bo Yao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20161018/cbd1810b/attachment.htm>

From rme at clozure.com  Mon Oct 17 22:13:30 2016
From: rme at clozure.com (R. Matthew Emerson)
Date: Mon, 17 Oct 2016 22:13:30 -0700
Subject: [Openmcl-devel] Is it possible to call a function automatically
	when exit ccl?
In-Reply-To: <CAM+JFJRnSyCpXGAX=1cABPS0A__8XveMRCQTyOmNFmA+M0SOSg@mail.gmail.com>
References: <CAM+JFJRnSyCpXGAX=1cABPS0A__8XveMRCQTyOmNFmA+M0SOSg@mail.gmail.com>
Message-ID: <B598386B-69A4-4A7A-855C-9C017274C4D4@clozure.com>


> On Oct 17, 2016, at 10:00 PM, Ice Rove <icerove at gmail.com> wrote:
> 
> Is it possible to call a function automatically when exit ccl? Both calling (quit) or kill the process in shell. Just like sbcl's *exit-hook*

Yes.  Push your 0-argument function onto ccl:*lisp-cleanup-functions*.  Note that doing save-application quits the lisp, so any functions on this list will be called before saving a heap image.

? (push #'(lambda () (print "I'm dying!")) *lisp-cleanup-functions*)
(#<Anonymous Function #x3020004B3ADF>)
? (quit)

"I'm dying!" 

A few more variables of this nature are briefly documented at http://ccl.clozure.com/docs/ccl.html#saving-applications



From snunez at maprtech.com  Sat Oct 22 20:48:49 2016
From: snunez at maprtech.com (Steven Nunez)
Date: Sun, 23 Oct 2016 14:48:49 +1100
Subject: [Openmcl-devel] Quicklisp & CCL 1.11, possible bug?
Message-ID: <1dcba74c28b9c3ae3ad01255456823e1@mail.gmail.com>

Greetings All,



Has anyone done a recent quicklisp install with CCL 1.11? Setting up a new
environment with a fresh checkout/build today. Not sure where the error is
(CCL or QL),  but here is the problem:



? (quicklisp-quickstart:install)

; Fetching #<URL "http://beta.quicklisp.org/client/quicklisp.sexp">

; 0.82KB

==================================================

838 bytes in 0.00 seconds (1284.71KB/sec)

; Fetching #<URL "http://beta.quicklisp.org/client/2016-02-22/quicklisp.tar
">

; 240.00KB

==================================================

245,760 bytes in 0.07 seconds (3565.17KB/sec)

> Error: on #<BASIC-TCP-STREAM ISO-8859-1 (SOCKET/4) #x3020006AC25D> :

>        Connection reset by peer (error #104) during read

> While executing: SOCKET-ERROR, in process listener(1).

> Type :POP to abort, :R for a list of available restarts.

> Type :? for other options.

1 > (quit)



Anyone have any ideas on where to start?



Regards,

Steve Nunez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20161023/c4582ae7/attachment.htm>

From max at mr.gy  Tue Oct 25 18:09:28 2016
From: max at mr.gy (Max Rottenkolber)
Date: Wed, 26 Oct 2016 01:09:28 +0000 (UTC)
Subject: [Openmcl-devel] Handling SIGTERM in applications
References: <nrr8dm$5pm$1@blaine.gmane.org>
Message-ID: <nuovo8$vui$1@blaine.gmane.org>

D'oh. I meant SIGINT. SIGTERM works just fine. To reprodcuce:

(save-application
 "sigint-test"
 :toplevel-function (lambda () (loop do (sleep 1)))
 :error-handler :quit
 :purify t
 :prepend-kernel t)

$ ./sigint-test # send it SIGINT
  C-c C-c> Break: interrupt signal
> While executing: CCL::%NANOSLEEP, in process toplevel(2).
> Type :GO to continue, :POP to abort, :R for a list of available restarts.
> If continued: Return from BREAK.
> Type :? for other options.
1 >

(Note that there is no actual break loop, it just prints the above and gets
stuck, ignoring input, or a subsequent SIGINT.)


On Tue, 20 Sep 2016 12:00:54 +0000, Max Rottenkolber wrote:

> Hello everyone,
> 
> I build my application using SAVE-APPLICATION and it works fine, except that it
> enters the debugger on SIGTERM even though I supply ?:error-handler :quit?.
> 
> I feel like this is a bug.
> 
> Be it a bug or not, is there currently a way to change the signal handler
> behavior? I need my application to be a good Unix citizen. :-)
> 
> Cheers,
> Max
> 
> 
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> https://lists.clozure.com/mailman/listinfo/openmcl-devel




From max at mr.gy  Tue Oct 25 18:48:37 2016
From: max at mr.gy (Max Rottenkolber)
Date: Wed, 26 Oct 2016 01:48:37 +0000 (UTC)
Subject: [Openmcl-devel] Handling SIGTERM in applications
References: <nrr8dm$5pm$1@blaine.gmane.org> <nrrar8$5pm$2@blaine.gmane.org>
Message-ID: <nup21l$fjt$1@blaine.gmane.org>

On Tue, 20 Sep 2016 12:42:16 +0000, Max Rottenkolber wrote:

> I noticed ?:error-handler :quit? seems to be generally broken, since it also
> drops me into a debugger when I signal a regular error.
> 
> I am on Linux x86_64 by the way.

I was able to work around this using a custom APPLICATION-CLASS:

  (defclass my-app (ccl::application)
    ((command-line-arguments :initform nil)))




From max at mr.gy  Tue Oct 25 18:59:50 2016
From: max at mr.gy (Max Rottenkolber)
Date: Wed, 26 Oct 2016 01:59:50 +0000 (UTC)
Subject: [Openmcl-devel] Handling SIGTERM in applications
References: <nrr8dm$5pm$1@blaine.gmane.org> <nuovo8$vui$1@blaine.gmane.org>
Message-ID: <nup2mm$fjt$2@blaine.gmane.org>

On Wed, 26 Oct 2016 01:09:28 +0000, Max Rottenkolber wrote:

> D'oh. I meant SIGINT. SIGTERM works just fine. To reprodcuce:
> 
> (save-application
>  "sigint-test"
>  :toplevel-function (lambda () (loop do (sleep 1)))
>  :error-handler :quit
>  :purify t
>  :prepend-kernel t)
> 
> $ ./sigint-test # send it SIGINT
>   C-c C-c> Break: interrupt signal
>> While executing: CCL::%NANOSLEEP, in process toplevel(2).
>> Type :GO to continue, :POP to abort, :R for a list of available restarts.
>> If continued: Return from BREAK.
>> Type :? for other options.
> 1 >
> 
> (Note that there is no actual break loop, it just prints the above and gets
> stuck, ignoring input, or a subsequent SIGINT.)

I was able to work around this by setting two internal special variables:

  (setf ccl::*invoke-debugger-hook-on-interrupt* t)
  (setf ccl::*debugger-hook*
      (lambda (condition hook)
        (declare (ignore hook))
        (etypecase condition
          (ccl::interrupt-signal-condition (quit 130)))))