0003 LGTM.
0004 can be simplified:
(setf (fdefn-fun (find-or-create-fdefn name)) ...) is (setf (fdefinition
name) ...
The reason install-guard-function uses a circumlocution is that (setf
(fdefinition ...)) is required to signal an error when attempting to
perform (setf (fdefinition 'my-fun) (symbol-function 'some-macro)).
Your case doesn't have that issue because you're assigning a good function.
I haven't thought about the build issues yet.

Jan Moringen <jmoringe@...> writes:
> Two suggestions:
>
> 1. Can you try to turn the example into a test case for the sb-bsd
> -sockets test suite?
> 2. Can you put the general cleanup that is currently in your first
> patch into a separate commit?
Thanks for your suggestions and here are my results.
Best regards.

On Thu, 2015-07-30 at 20:27 -0400, Douglas Katzman wrote:
> Thanks for this; I'll have a look.
Thanks.
> Also I found a bug, and I've a question about intent.
> [...]
0004-….patch is what I cargoculted based on install-guard-function.
> And my question is whether you were trying to retain useful
> information for the source locations in 'setup-{function/variable}
> -for-final-deprecation'. As it stands, it will be record the location
> of the 'setup-' function which is not helpful. It would probably make
> more sense just to store a NIL, or else you'd have to go to some
> effort to capture the source location of the proclamation
> itself. (This works only for DECLAIM - Stas made it do that)
The recorded source locations are indeed less than helpful. In 0003
-….patch, I changed the SETUP-*-IN-FINAL-DEPRECATION to not record
source locations when possible.
In addition, I slightly changed %PROCLAIM to record useful source
locations for DEPRECATED declarations (when done via DECLAIM). With a
minor tweak of SB-INTROSPECT:FIND-DEFINITION-SOURCES-BY-NAME, these
show up as
(DECLAIM name DEPRECATED (FUNCTION | VARIABLE | TYPE))
in slime-xref, which is probably good enough.
Could you have another look and let me know what you think?
Thanks in advance and kind regards,
Jan

Thanks for this; I'll have a look.
Also I found a bug, and I've a question about intent.
In setup-function-in-final-deprecation, (setf %fun-name) does not change a
closure name - it affects the name of the underlying simple-fun that the
closure points to, so they'll all collide. You'll find an example of what
you want to do in 'install-guard-function' which is used for macros and
special operators.
The underlying issue is that naming a closure does not work the way it
ought, to alter the closure. I'm not keen on allocating an extra word in
every closure to allow for the possibility of a name (since so few are
named), therefore naming one must allocate a new closure, and you have to
use that, not the original one.
And my question is whether you were trying to retain useful information for
the source locations in 'setup-{function/variable}-for-final-deprecation'.
As it stands, it will be record the location of the 'setup-' function which
is not helpful.
It would probably make more sense just to store a NIL, or else you'd have
to go to some effort to capture the source location of the proclamation
itself. (This works only for DECLAIM - Stas made it do that)

On Thu, 2015-07-30 at 01:03 -0400, Douglas Katzman wrote:
> A bunch of that stuff is probably going to need to move out of
> early-extensions.
>
> It causes new warnings -
> ; Undefined types:
> ; CLASS ERROR PARSE-DEPRECATED-TYPE
>
> I'm sort of ok with warnings during make-host-1, but not so much with
> make-host-2, because those warnings imply that target was not
> compiled exactly the same as would have been had the real target
> compiler compiled itself. All the above types should have been known.
I'm still not entirely comfortable with build-order and bootstrapping
issues, but I tried to address the problems anyway. The attached patch
splits the deprecation stuff into two files [early-]deprecation.lisp.
As far as I can tell, the constraints are
* src/code/early-deprecation.lisp
* before src/compiler/globaldb.lisp (globaldb uses
deprecation-info type)
* before the compiler (compiler calls check-deprecated-*)
* src/code/deprecation.lisp
* after src/code/condition.lisp (signals deprecation
conditions)
* after src/code/late-type.lisp
* before proclaim (proclaim calls check-deprecated-*,
setup-*-in-final-deprecation)
* after src/compiler/proclaim.lisp (this file calls sb
-c:proclaim-type)
* after src/code/macros.lisp (this file calls sb
-c::%define-symbol-macro)
The last two constraints are not currently satisfied. Should I add forw
ard declarations for these two functions?
Also, cross-compilation still complains about CLASS and CLASS-NAME
which seem to come from PCL. What can I do about those?
Thanks and kind regards,
Jan

Hi,
thanks for your patches.
On Wed, 2015-07-29 at 17:25 +0200, Manuel Giraud wrote:
> Here is a patch to have some multicast IP capability in
> sb-bsd-sockets. Here is a usage example:
>
> [...]
>
> I have just tested it on openbsd, so I think it need testing on linux
> too.
Two suggestions:
1. Can you try to turn the example into a test case for the sb-bsd
-sockets test suite?
2. Can you put the general cleanup that is currently in your first
patch into a separate commit?
After that, please send the full series of revised patches to sbcl
-devel, again.
Thanks and kind regards,
Jan

The function, slot-missing, is located in slots.lisp in the sbcl source.
It would be great if this function would also include the list of available
slots in the error message.
something like “When attempting to read the slot X is missing from the
object #<abc>, the available slot names are (U V W P2::X Y Z)”
BTW, in sbcl, given an instance, how can I find the list of slot names?
(defmethod slot-missing
((class t) instance slot-name operation &optional new-value)
(error "~@<When attempting to ~A, the slot ~S is missing from the ~
object ~S.~@:>"
(ecase operation
(slot-value "read the slot's value (slot-value)")
(setf (format nil
"set the slot's value to ~S (SETF of SLOT-VALUE)"
new-value))
(slot-boundp "test to see whether slot is bound (SLOT-BOUNDP)")
(slot-makunbound "make the slot unbound (SLOT-MAKUNBOUND)"))
slot-name
instance))

SANO Masatoshi <snmsts@...> writes:
> I see sbcl repository are looked properly tagged and
> http://www.sbcl.org/platform-table.html have been changed for the
> release.
>
> But I can't download source and binary of the version from
> sourceforge.
> Please fix the situation if possible.
As I explained in my e-mail announcing the release, uploads to the file
release section of Sourceforge are currently not available, and
therefore I cannot fix the situation until that is rectified. The
current ETA for that as given by Sourceforge at
<http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration-update-for-728/&gt;
is the end of the day of 31st July.
Best wishes,
Christophe

Hi,
I see sbcl repository are looked properly tagged and
http://www.sbcl.org/platform-table.html have been changed for the release.
But I can't download source and binary of the version from sourceforge.
Please fix the situation if possible.
Thanks.

A bunch of that stuff is probably going to need to move out of
early-extensions.
It causes new warnings -
; Undefined types:
; CLASS ERROR PARSE-DEPRECATED-TYPE
I'm sort of ok with warnings during make-host-1, but not so much with
make-host-2, because those warnings imply that target was not compiled
exactly the same as would have been had the real target compiler compiled
itself. All the above types should have been known.

Hi all,
I've set sbcl-bugs to munge Reply-To to sbcl-devel: not sure if that's
the right thing either, but maybe it will reduce the number of
conversations where only one half gets on the list... until I go
though the pending posts again.
If this is deemed a bad idea, I'll change it back.
Another alternative might be to simply add all non-spammers who post
there to the Allow-posting filter.
Cheers,
-- nikodemus

Christophe Rhodes <csr21@...> writes:
> Assuming that this gets through relatively soon: the sourceforge outage
> might be nearing its end (or might not). In case it is: could testing
> of the current contents of master (from
> e.g. <https://github.com/sbcl/sbcl&gt;) be done as if we were in freeze, so
> that any issues picked up might be quickly resolvable in time for an
> end-of-the-month release?
Alright. Now that developers have had a chance to commit their queues,
I'd like to freeze properly for the sbcl-1.2.14 release. I'd take a
patch that gives the &optional/&key style warning its own condition
class, but I'd understand it if whoever maintains the clx that quicklisp
uses would prefer to take out the no-style-warning enforcement instead.
If users find any other regressions or serious bugs, please let the list
know and we'll consider remedies.
I hope to release towards the middle of next week.
Best wishes,
Christophe

On Wed, 2015-07-22 at 22:57 -0400, Douglas Katzman wrote:
> You're adding (wanted to add?) a specific condition-class for this,
> or was I imagining that ?
That was for compiler macros being defined after calls to the
corresponding function have already been compiled. I do think that
having a specific condition class for this makes sense, though.
If nobody else wants to/has time to, I can add this condition class.
However, I would like to focus on getting the deprecation stuff done,
if possible (I'm currently pondering changes to the loader-deprecation
warnings - the rest is mostly finalized).
> It seems to be people's favorite warning to suppress.
Plausible. We even had a discussion about whether to signal this style
warning at all (see #sbcl logs).
Kind regards,
Jan

I checked the last message in sourceforge malinglist and found that the
text is rather messy, all kinds of html tags make the text unreadable,
maybe in your mailbox it's readable ,but I decide to retext them again
without any formatting things.
Sorry if this bored you.
I would like to propose a bug fix, as follows.
The problem has been discussed before, the link is
https://groups.google.com/d/topic/sbcl-devel/1iK5viNnw1g/discussion
I can't reply to that message, so i started this new thread.
The problem is when I type Ctrl+C in windows 32bit SBCL, it crashes. And
also, when a foreign thread calls 'alien-callback' into lisp code, the same
problem occurs. So it looks like a alien-callback problem.
These days I inspected this problem carefully and at last found out the
reason. It's in the x86/win32 run-time part, specifically the function
'callback_wrapper_trampoline'. I think Matt is right, it's introduced by
commit 476c3ffe49564c007b513485f6e2f27f8a6e586b. Details follow.
In short, the problem is caused by GCC optimization. Disassemble
callback_wrapper_trampoline and compare it with the C code, we can find
what happens.
In the following C function, when 'th' is null, attach_os_thread will
assign a new value to it. And detach_os_thread will use the new 'th' to do
some clean work. BUT gcc is too smart, it optimizes out the first line of
detach_os_thread, and uses the old 'th' value directly (the one in the
first line of callback_wrapper_trampoline), which is NULL. The crash
happens in undo_init_new_thread, null pointer accessed.
void callback_wrapper_trampoline( lispobj arg0, lispobj arg1, lispobj
arg2)
{
struct thread* th = arch_os_get_current_thread(); ///*** NULL
if (!th) { /* callback invoked in non-lisp thread */
init_thread_data scribble;
attach_os_thread(&scribble);
funcall3(StaticSymbolFunction(ENTER_FOREIGN_CALLBACK),
arg0,arg1,arg2);
detach_os_thread(&scribble);
return;
}
}
void detach_os_thread(init_thread_data *scribble)
{
struct thread *th = arch_os_get_current_thread(); ///*** this line
optimized out
undo_init_new_thread(th, scribble);
odxprint(misc, "deattach_os_thread: detached");
pthread_setspecific(lisp_thread, (void *)0);
thread_sigmask(SIG_SETMASK, &scribble->oldset, 0);
}
Have a look at the corresponding assemble code, it's clear that after
funcall3, undo_init_new_thread is called directly, the line which gets new
'th' value is gone.
Dump of assembler code for function callback_wrapper_trampoline:
0x00416e20 <+0>: push %ebp
0x00416e21 <+1>: mov %esp,%ebp
0x00416e23 <+3>: push %edi
0x00416e24 <+4>: push %esi
0x00416e25 <+5>: push %ebx
0x00416e26 <+6>: sub $0x1c,%esp
0x00416e29 <+9>: mov 0x10(%ebp),%ebx
0x00416e2c <+12>: call 0x41cb40 <pthread_np_notice_thread>
0x00416e31 <+17>: mov %fs:0xf0c,%eax ;;read th
0x00416e37 <+23>: test %eax,%eax
0x00416e39 <+25>: je 0x416ed1 <callback_wrapper_trampoline+177>
;; ... other lines
0x00416ed1 <+177>: lea -0x18(%ebp),%esi ;;
0x00416ed4 <+180>: mov %esi,(%esp)
0x00416ed7 <+183>: call 0x416b50 <attach_os_thread>
0x00416edc <+188>: mov 0xc(%ebp),%eax
0x00416edf <+191>: mov %ebx,0xc(%esp)
0x00416ee3 <+195>: mov %eax,0x8(%esp)
0x00416ee7 <+199>: mov 0x8(%ebp),%eax
0x00416eea <+202>: mov %eax,0x4(%esp)
0x00416eee <+206>: mov 0x22100664,%eax
0x00416ef3 <+211>: and $0xfffffff8,%eax
0x00416ef6 <+214>: mov 0x8(%eax),%eax
0x00416ef9 <+217>: mov %eax,(%esp)
0x00416efc <+220>: call 0x403440 <funcall3> ;;funcall3
0x00416f01 <+225>: mov 0x4420d4,%ebx
0x00416f07 <+231>: test %ebx,%ebx
0x00416f09 <+233>: jne 0x416f50 <callback_wrapper_trampoline+304>
0x00416f0b <+235>: xor %eax,%eax
0x00416f0d <+237>: mov %esi,%edx
0x00416f0f <+239>: call 0x4166d0 <undo_init_new_thread>
0x00416f14 <+244>: mov 0x4420d4,%ecx
0x00416f1a <+250>: test %ecx,%ecx
0x00416f1c <+252>: je 0x416f2a <callback_wrapper_trampoline+266>
0x00416f1e <+254>: movl $0x43ec7e,(%esp)
In the commit "476c3ffe49564c007b513485f6e2f27f8a6e586b", the function
callback_wrapper_trampoline was moved from safe-point.c to file thread.c,
which is the file other related functions such as attach_os_thread,
detach_os_thread reside,
this gives chances to gcc to apply the optimization.
Before the commit , the whole function of detach_os_thread is called
directly by callback_wrapper_trampoline (can be verified in disassemble
code of versions before 1.2.7), so every thing was OK.
To solve this problem, I think the best way is to add a 'volatile'
declaration in arch_os_get_current_thread as in the following code, this
can disable the gcc optimization, it works in my test.
static inline struct thread *arch_os_get_current_thread(void)
{
register struct thread *me=0;
__asm__ volatile ("movl %%fs:0xE10+(4*63), %0" : "=r"(me) :);
return me;
}
Best regards
Naurril

Stas Boukarev <stassats@...> writes:
> Jan Moringen <jmoringe@...> writes:
>
>> On Wed, 2015-07-22 at 19:14 +0300, Stas Boukarev wrote:
>>> Zach Beane <xach@...> writes:
>>>
>>> > Christophe Rhodes <csr21@...> writes:
>>> >
>>> > > Hi,
>>> > >
>>> > > Assuming that this gets through relatively soon: the sourceforge
>>> > > outage
>>> > > might be nearing its end (or might not). In case it is: could
>>> > > testing
>>> > > of the current contents of master (from
>>> > > e.g. <https://github.com/sbcl/sbcl&gt;) be done as if we were in
>>> > > freeze, so
>>> > > that any issues picked up might be quickly resolvable in time for
>>> > > an
>>> > > end-of-the-month release?
>>> >
>>> > I just built the latest SBCL from github. I can't do this:
>>> >
>>> > (ql:quickload "clx" :verbose t)
>>> >
>>> > I believe it's because clx's system file upgrades style-warnings to
>>> > full warnings. I see some style warnings in the compilation output
>>> > related to &optional and &key in the same lambda list -- is that
>>> > new in recent SBCL? Is it possible something else is triggering a
>>> > new style -warning since 1.2.13?
>>> >
>>> That was a style-warning for some time now, but there were some
>>> changes regarding it this cycle.
>>
>> The difference could be a new style-warning for &optional and &key in a
>> *destructuring* lambda (and by extension macro lambda list, etc.) list
>> since Doug rewrote ds-bind and related code.
> Right, it's coming from a macro HOLDING-LOCK, previously only functions
> were affected.
> This is an internal symbol, so it can be changed to only use &keys.
I think I may just drop CLX's promotion of style-warnings to full
warnings entirely.
Zach

Jan Moringen <jmoringe@...> writes:
> On Wed, 2015-07-22 at 19:14 +0300, Stas Boukarev wrote:
>> Zach Beane <xach@...> writes:
>>
>> > Christophe Rhodes <csr21@...> writes:
>> >
>> > > Hi,
>> > >
>> > > Assuming that this gets through relatively soon: the sourceforge
>> > > outage
>> > > might be nearing its end (or might not). In case it is: could
>> > > testing
>> > > of the current contents of master (from
>> > > e.g. <https://github.com/sbcl/sbcl&gt;) be done as if we were in
>> > > freeze, so
>> > > that any issues picked up might be quickly resolvable in time for
>> > > an
>> > > end-of-the-month release?
>> >
>> > I just built the latest SBCL from github. I can't do this:
>> >
>> > (ql:quickload "clx" :verbose t)
>> >
>> > I believe it's because clx's system file upgrades style-warnings to
>> > full warnings. I see some style warnings in the compilation output
>> > related to &optional and &key in the same lambda list -- is that
>> > new in recent SBCL? Is it possible something else is triggering a
>> > new style -warning since 1.2.13?
>> >
>> That was a style-warning for some time now, but there were some
>> changes regarding it this cycle.
>
> The difference could be a new style-warning for &optional and &key in a
> *destructuring* lambda (and by extension macro lambda list, etc.) list
> since Doug rewrote ds-bind and related code.
Right, it's coming from a macro HOLDING-LOCK, previously only functions
were affected.
This is an internal symbol, so it can be changed to only use &keys.
--
With best regards, Stas.

On Wed, 2015-07-22 at 19:14 +0300, Stas Boukarev wrote:
> Zach Beane <xach@...> writes:
>
> > Christophe Rhodes <csr21@...> writes:
> >
> > > Hi,
> > >
> > > Assuming that this gets through relatively soon: the sourceforge
> > > outage
> > > might be nearing its end (or might not). In case it is: could
> > > testing
> > > of the current contents of master (from
> > > e.g. <https://github.com/sbcl/sbcl&gt;) be done as if we were in
> > > freeze, so
> > > that any issues picked up might be quickly resolvable in time for
> > > an
> > > end-of-the-month release?
> >
> > I just built the latest SBCL from github. I can't do this:
> >
> > (ql:quickload "clx" :verbose t)
> >
> > I believe it's because clx's system file upgrades style-warnings to
> > full warnings. I see some style warnings in the compilation output
> > related to &optional and &key in the same lambda list -- is that
> > new in recent SBCL? Is it possible something else is triggering a
> > new style -warning since 1.2.13?
> >
> That was a style-warning for some time now, but there were some
> changes regarding it this cycle.
The difference could be a new style-warning for &optional and &key in a
*destructuring* lambda (and by extension macro lambda list, etc.) list
since Doug rewrote ds-bind and related code.