Muffling conditions outside the compiler?

Hi,

Does anybody have strong objections to extending the scope of
SB-EXT:MUFFLE-CONDITIONS to include conditions raised outside of
compilation proper?

Thanks,
Richard

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Re: Muffling conditions outside the compiler?

On Jun 18, 2008, at 9:27, Richard M Kreuter wrote:

> Does anybody have strong objections to extending the scope of
> SB-EXT:MUFFLE-CONDITIONS to include conditions raised outside of
> compilation proper?

Do you mean this?

   (locally
     (declare (sb-ext:muffle-conditions warning))
     (warn "foo" #| will be muffled |#))

If so, I object. It seems to me that (outside of interpreted mode)  
the two sorts of warnings are almost always unrelated, and extending  
muffle-conditions to runtime warnings would create more subtle bugs  
than it would improve readability over using both MUFFLE-CONDITIONS  
and HANDLER-BIND in the event that you actually want this behavior.

That said, this seems like a rather strange thing to want to me, so  
perhaps I have misunderstood what you're proposing.

--

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Re: Fix :REPORT undefined function style-warnings

Zach Beane <xach <at> xach.com> writes:

> On Mon, Jun 16, 2008 at 11:30:32PM +0100, Christophe Rhodes wrote:
>> Do the symptoms that you've observed go away if instead you patch the
>> expansion of DEFINE-CONDITION to look like
>>   (progn 
>>     (eval-when (:compile-toplevel :execute)
>>       (%compiler-define-condition ...))
>>     (eval-when (:load-toplevel :execute)
>>       (%define-condition ...)))
>
> Yes, this works perfectly for both LOAD and at the REPL. Thanks for
> looking at it!

OK, but I don't think this is the whole story.  With this as the
expansion, at the repl now %compiler-define-condition gets run twice,
which I think is wasteful.

My next stab at the solution was to expand into (the moral equivalent of)
  (progn
    (eval-when (:compile-toplevel)
      (%compiler-define-condition ...))
    (eval-when (:load-toplevel :execute)
      (%define-condition ... (locally (declare (ftype (function (t) t) , <at> all-readers)) ...))))
in other words, to use a ftype declaration around the report function
to inform the compiler about those functions.  However, I discovered
that this doesn't work; the compiler's process-ftype-decl will cause
an undefined reference if it can't find an already-existing function
at compile-time, from find-global-fun.

Re: Muffling conditions outside the compiler?

Richard M Kreuter <kreuter <at> progn.net> writes:

> Hi,
> 
> Does anybody have strong objections to extending the scope of
> SB-EXT:MUFFLE-CONDITIONS to include conditions raised outside of
> compilation proper?

Presumably you mean only a very limited set of conditions
(eg. redefinition warnings), not having it apply to everything? This
has been discussed a bit before.

http://thread.gmane.org/gmane.lisp.steel-bank.devel/8013

--

-- 
Juho Snellman

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Re: Muffling conditions outside the compiler?

On Wed, Jun 18, 2008 at 4:53 PM, Kevin Reid <kpreid <at> mac.com> wrote:
> On Jun 18, 2008, at 9:27, Richard M Kreuter wrote:
>
>> Does anybody have strong objections to extending the scope of
>> SB-EXT:MUFFLE-CONDITIONS to include conditions raised outside of
>> compilation proper?
>
> Do you mean this?
>
>   (locally
>     (declare (sb-ext:muffle-conditions warning))
>     (warn "foo" #| will be muffled |#))
>
> If so, I object. It seems to me that (outside of interpreted mode)

If so, me too...

But if it means that

 (proclaim '(sb-ext:muffle-conditions warning))

 (warn "will be muffled")

...then I'm ok with it.

I don't particularly object if it only applies to not WARN, but some
SB-INT:MAGIC-WARN -- though I don't like that option overmuch. The
overall design seems cleaner to me, and easier to understand from user
POV the less special casing has: no reason why this mechanism should
not work for to muffle warnings (and other mufflable conditions!) from

Re: Muffling conditions outside the compiler?

"Nikodemus Siivola" <nikodemus <at> random-state.net> writes:

> On Wed, Jun 18, 2008 at 4:53 PM, Kevin Reid <kpreid <at> mac.com> wrote:
>> On Jun 18, 2008, at 9:27, Richard M Kreuter wrote:
>>
>>> Does anybody have strong objections to extending the scope of
>>> SB-EXT:MUFFLE-CONDITIONS to include conditions raised outside of
>>> compilation proper?
>>
>> Do you mean this?
>>
>>   (locally
>>     (declare (sb-ext:muffle-conditions warning))
>>     (warn "foo" #| will be muffled |#))
>>
>> If so, I object. It seems to me that (outside of interpreted mode)
>
> If so, me too...
>
> But if it means that
>
>  (proclaim '(sb-ext:muffle-conditions warning))
>
>  (warn "will be muffled")
>
> ...then I'm ok with it.

I want to know the semantics intended for the locally form, and how a
mental model can be built linking it to the globally-proclaimed form,
before expressing an opinion.

Re: Muffling conditions outside the compiler?

Juho Snellman writes:
> Richard M Kreuter <kreuter <at> progn.net> writes:
> 
> > Hi,
> > 
> > Does anybody have strong objections to extending the scope of
> > SB-EXT:MUFFLE-CONDITIONS to include conditions raised outside of
> > compilation proper?
> 
> Presumably you mean only a very limited set of conditions
> (eg. redefinition warnings), not having it apply to everything?

Configurably handling redefinition warnings is the proximate goal, yes.
However, it seemed to me that if there's one context in which the user
might want to have a customizable muffling of conditions, then maybe
he'd want it all the time (i.e., rather than allowing muffling of
conditions only in the compiler or only in the compiler and in LOAD,
allowing it to be done globally).

> This has been discussed a bit before.
> 
> http://thread.gmane.org/gmane.lisp.steel-bank.devel/8013

I don't see much consensus in that thread, except perhaps that everybody
agrees that annoying warnings are annoying.  ISTM that rather than
negotiating just when to signal the warning, it's simpler to always
signal a warning containing enough information to support
separately-maintained definitions of uninterestingness, and to give the
user a global knob for using his preferred definition of uninteresting
decide what to muffle.

sb-posix:fcntl is not implemented on Windows port 1.0.13

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

_______________________________________________
Sbcl-devel mailing list
Sbcl-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Re: sb-posix:fcntl is not implemented on Windows port 1.0.13

"Andrei Stebakov" writes:

> I was trying to compile hunchentoot on Windows using the 1.0.13 sbcl,
> everything compiled except SSL support which required sb-posix:fcntl to be
> implemented.
> Are there any plans to implement it for Windows?

IIRC, the last time I looked, fcntl wasn't available on Windows, though
at least some of fcntl's functionality is present on Windows in some
form.  Which bits of fcntl does Hunchentoot need?

--
Richard

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Re: Muffling conditions outside the compiler?

Christophe Rhodes writes:

> The point here is that there is no need for the interface for run-time
> conditions to be a proclamation or declaration.

Okay.  Somebody suggested asking about adapting SB-EXT:MUFFLE-CONDITIONS
for this purpose, but I'd be fine with a variable (though I'd rather it
be a type specifier than a list of type specifiers, for resemblance to
*BREAK-ON-SIGNALS*).

Regards,
Richard

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php