From: Nikodemus S. <nik...@ra...> - 2007-06-29 12:20:35
|
I have a patch that implements a way to globally restrict policicies in SBCL: (restrict-compile-policy 'safety 1) will override any local declarations or global proclamations of SAFETY 0. The point is to make it easy to recompile large bodies of code with eg. a given mininum SAFETY or DEBUG policy. Does someone have significant reservations about merging this to SBCL? Cheers, -- Nikodemus |
From: Zach B. <xa...@xa...> - 2007-06-29 13:05:26
|
On Fri, Jun 29, 2007 at 03:20:29PM +0300, Nikodemus Siivola wrote: > I have a patch that implements a way to globally restrict > policicies in SBCL: > > (restrict-compile-policy 'safety 1) > > will override any local declarations or global proclamations > of SAFETY 0. > > The point is to make it easy to recompile large bodies > of code with eg. a given mininum SAFETY or DEBUG policy. > > Does someone have significant reservations about merging > this to SBCL? I would really love something like this. Zach |
From: Nikodemus S. <nik...@ra...> - 2007-06-29 13:35:43
|
Nikodemus Siivola wrote: > I have a patch that implements a way to globally restrict > policicies in SBCL: > > (restrict-compile-policy 'safety 1) > > will override any local declarations or global proclamations > of SAFETY 0. > > The point is to make it easy to recompile large bodies > of code with eg. a given mininum SAFETY or DEBUG policy. > > Does someone have significant reservations about merging > this to SBCL? As a random data-point of the goodness of having something like this, this catches type-errors in SBCL itself, which are normally hidden by local (SAFETY 0) policies. Cheers, -- Nikodemus |
From: Nikodemus S. <nik...@ra...> - 2007-06-29 15:24:16
|
Richard M Kreuter wrote: > * Does/can the compiler policy produce warnings or similar when local > policies conflict with global restrictions? I could, I don't think that would be a good idea, since several of the OPTIMIZE declarations which would give warnings are going to be in SBCL internals... > * Additionally, why not have the interface to the compiler policy be > available as named optimization qualities like minimum-safety, > minimum-debug, and so forth, so that people could proclaim them? This > way, compiler policy settings could occur as normal code (i.e., not in > read-time conditional expressions), which makes processing Lisp source > files under other implementations and languages easier. I think I prefer the functional interface, because a) doing that requires only one new symbol instead of one symbol per policy. b) since this is very much about restricting the effect of future proclamations, it seems wrong to use proclaim as the interface. c) I envision that this would mostly be used interactively from the REPL. Cheers, -- Nikodemus |
From: Nikodemus S. <nik...@ra...> - 2007-06-29 15:50:46
|
Nikodemus Siivola wrote: > I have a patch that implements a way to globally restrict > policicies in SBCL: > > (restrict-compile-policy 'safety 1) > > will override any local declarations or global proclamations > of SAFETY 0. Patch: http://random-state.net/tmp/policy.patch 1.0.7.3.restrict-compiler-policy: RESTRICT-COMPILER-POLICY * Allow users to set a global minimum for optimization qualities, overriding declarations and proclamations. The intended use is to make it easy to recompile large bodies of code with many local optimization declarations with a minimum SAFETY or DEBUG everywhere. * Delete some unused functions: READ-SEQUENCE-OR-DIE, RENAME-KEY-ARGS. * Changes to SBCL itself to allow building with SBCL that has minimum safety set to 3: -- Second argument of %MORE-KW-ARG is a negative: DEFKNOWN it as a FIXNUM, not INDEX. -- We don't have a deftype for SB-VM::POSITIVE-FIXNUM -- it's only a backend type. Use (AND UNSIGNED-BYTE FIXNUM) instead. I'll merge this soonish absent any cries of horror. Cheers, -- Nikodemus |
From: Liam H. <ln...@he...> - 2007-06-29 16:29:11
|
Would it be possible to have a warning or note issued when a declaration is overridden due to the policy? Many a head-scratching debugging has resulted when a global setting overrides a local one. My experience with emacs programming for example is that I set a variable I think does what I want, and there is absolutely no effect because of some global setting I didn't realize took precedence. On 6/29/07, Nikodemus Siivola <nik...@ra...> wrote: > > Nikodemus Siivola wrote: > > I have a patch that implements a way to globally restrict > > policicies in SBCL: > > > > (restrict-compile-policy 'safety 1) > > > > will override any local declarations or global proclamations > > of SAFETY 0. > > Patch: > > http://random-state.net/tmp/policy.patch > > 1.0.7.3.restrict-compiler-policy: RESTRICT-COMPILER-POLICY > > * Allow users to set a global minimum for optimization qualities, > overriding declarations and proclamations. > > The intended use is to make it easy to recompile large bodies of > code with many local optimization declarations with a minimum > SAFETY or DEBUG everywhere. > > * Delete some unused functions: READ-SEQUENCE-OR-DIE, > RENAME-KEY-ARGS. > > * Changes to SBCL itself to allow building with SBCL that has minimum > safety set to 3: > > -- Second argument of %MORE-KW-ARG is a negative: DEFKNOWN it as a > FIXNUM, not INDEX. > > -- We don't have a deftype for SB-VM::POSITIVE-FIXNUM -- it's only > a backend type. Use (AND UNSIGNED-BYTE FIXNUM) instead. > > I'll merge this soonish absent any cries of horror. > > Cheers, > > -- Nikodemus > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > |
From: Nikodemus S. <nik...@ra...> - 2007-06-29 16:59:10
|
Liam Healy wrote: > Would it be possible to have a warning or note issued when a declaration is > overridden due to the policy? Many a head-scratching debugging has > resulted > when a global setting overrides a local one. My experience with emacs > programming for example is that I set a variable I think does what I want, > and there is absolutely no effect because of some global setting I didn't > realize took precedence. I'm not sure I follow you. Given that the _only_ thing RESTRICT-COMPILER-POLICY does is override local optimization qualities (adjusting them upwards), giving a warning for that seems rather redundant. Also: only change in semantics that R-C-P can cause is better error-detection. Can you give an example of the kind of confusion you envision, and how a warning would help you solve it? Cheers, -- Nikodemus |
From: Liam H. <ln...@he...> - 2007-06-29 17:31:25
|
OK given that it is only better error detection then a warning is not needed. I mistakenly assumed policy might also be applicable to other compiler settings like speed. Liam On 6/29/07, Nikodemus Siivola <nik...@ra...> wrote: > > Liam Healy wrote: > > > Would it be possible to have a warning or note issued when a declaration > is > > overridden due to the policy? Many a head-scratching debugging has > > resulted > > when a global setting overrides a local one. My experience with emacs > > programming for example is that I set a variable I think does what I > want, > > and there is absolutely no effect because of some global setting I > didn't > > realize took precedence. > > I'm not sure I follow you. > > Given that the _only_ thing RESTRICT-COMPILER-POLICY does is override > local > optimization qualities (adjusting them upwards), giving a warning for that > seems rather redundant. Also: only change in semantics that R-C-P can > cause > is better error-detection. > > Can you give an example of the kind of confusion you envision, and how > a warning would help you solve it? > > Cheers, > > -- Nikodemus > > |
From: Nikodemus S. <nik...@ra...> - 2007-06-29 20:47:41
|
Liam Healy wrote: > OK given that it is only better error detection then a warning is not > needed. I mistakenly assumed policy might also be applicable to other > compiler settings like speed. Um, it is applicable to all optimization qualities -- though I'm considering restricting it to the standard CL ones (and not the SBCL internal derived qualities.) ...but only allowed semantic difference between different qualities (as far as I know) is between "safe" and "unsafe" code. Cheers, -- Nikodemus > Liam > > On 6/29/07, Nikodemus Siivola <nik...@ra...> wrote: >> >> Liam Healy wrote: >> >> > Would it be possible to have a warning or note issued when a >> declaration >> is >> > overridden due to the policy? Many a head-scratching debugging has >> > resulted >> > when a global setting overrides a local one. My experience with emacs >> > programming for example is that I set a variable I think does what I >> want, >> > and there is absolutely no effect because of some global setting I >> didn't >> > realize took precedence. >> >> I'm not sure I follow you. >> >> Given that the _only_ thing RESTRICT-COMPILER-POLICY does is override >> local >> optimization qualities (adjusting them upwards), giving a warning for >> that >> seems rather redundant. Also: only change in semantics that R-C-P can >> cause >> is better error-detection. >> >> Can you give an example of the kind of confusion you envision, and how >> a warning would help you solve it? >> >> Cheers, >> >> -- Nikodemus >> >> > |
From: Nikodemus S. <nik...@ra...> - 2007-06-30 09:25:47
|
Nikodemus Siivola wrote: > I have a patch that implements a way to globally restrict > policicies in SBCL: > > (restrict-compile-policy 'safety 1) > > will override any local declarations or global proclamations > of SAFETY 0. > > The point is to make it easy to recompile large bodies > of code with eg. a given mininum SAFETY or DEBUG policy. This has now been merged as 1.0.7.4. Please report any issues you have with the interface or the functionality itself. Cheers, -- Nikodemus |
From: Thomas F. B. <tf...@oc...> - 2007-07-01 12:44:20
|
On 6/29/07, Nikodemus Siivola <nik...@ra...> wrote: > I have a patch that implements a way to globally restrict > policicies in SBCL: > > (restrict-compile-policy 'safety 1) > > will override any local declarations or global proclamations > of SAFETY 0. > > The point is to make it easy to recompile large bodies > of code with eg. a given mininum SAFETY or DEBUG policy. This looks great, and extremely useful. However, I'd also like to be able to restrict the upper values. For example, (restrict-compile-policy 'debug '<= 2) or something. |
From: Nikodemus S. <nik...@ra...> - 2007-07-01 12:48:45
|
Thomas F. Burdick wrote: > On 6/29/07, Nikodemus Siivola <nik...@ra...> wrote: >> I have a patch that implements a way to globally restrict >> policicies in SBCL: >> >> (restrict-compile-policy 'safety 1) >> >> will override any local declarations or global proclamations >> of SAFETY 0. >> >> The point is to make it easy to recompile large bodies >> of code with eg. a given mininum SAFETY or DEBUG policy. > > This looks great, and extremely useful. However, I'd also like to be > able to restrict the upper values. For example, > (restrict-compile-policy 'debug '<= 2) or something. I'm not too averse to this, but it gets tricky as it means that you'll be able to make safe code unsafe, when other parts may be relying on some error-checking guaranteed by the said safe code... ...and saying that upper limit affects all other qualities except safety is just tacky. It might be the way to go, though. Or it might be that some sort of warnings are in order after all. Cheers, -- Nikodemus |
From: Thomas F. B. <tf...@oc...> - 2007-07-01 14:38:40
|
On 7/1/07, Nikodemus Siivola <nik...@ra...> wrote: > Thomas F. Burdick wrote: > > On 6/29/07, Nikodemus Siivola <nik...@ra...> wrote: > >> I have a patch that implements a way to globally restrict > >> policicies in SBCL: > >> > >> (restrict-compile-policy 'safety 1) > >> > >> will override any local declarations or global proclamations > >> of SAFETY 0. > >> > >> The point is to make it easy to recompile large bodies > >> of code with eg. a given mininum SAFETY or DEBUG policy. > > > > This looks great, and extremely useful. However, I'd also like to be > > able to restrict the upper values. For example, > > (restrict-compile-policy 'debug '<= 2) or something. > > I'm not too averse to this, but it gets tricky as it means that > you'll be able to make safe code unsafe, when other parts may > be relying on some error-checking guaranteed by the said safe > code... > > ...and saying that upper limit affects all other qualities except > safety is just tacky. It might be the way to go, though. Or it > might be that some sort of warnings are in order after all. I think warnings are definitely called for either way, since a naive user could stick (restrict-compile-policy 'speed 3) in their .sbclrc or their build script and horribly break code that specifies (optimize (speed 2) (safety 2)) for example. |
From: <wil...@ai...> - 2007-07-01 18:50:41
|
On Sun, Jul 01, 2007 at 03:48:36PM +0300, Nikodemus Siivola wrote: > Thomas F. Burdick wrote: > > On 6/29/07, Nikodemus Siivola <nik...@ra...> wrote: > >> I have a patch that implements a way to globally restrict > >> policicies in SBCL: > >> > >> (restrict-compile-policy 'safety 1) > >> > >> will override any local declarations or global proclamations > >> of SAFETY 0. > >> > >> The point is to make it easy to recompile large bodies > >> of code with eg. a given mininum SAFETY or DEBUG policy. > > > > This looks great, and extremely useful. However, I'd also like to be > > able to restrict the upper values. For example, > > (restrict-compile-policy 'debug '<= 2) or something. > > I'm not too averse to this, but it gets tricky as it means that > you'll be able to make safe code unsafe, when other parts may > be relying on some error-checking guaranteed by the said safe > code... > > ...and saying that upper limit affects all other qualities except > safety is just tacky. It might be the way to go, though. Or it > might be that some sort of warnings are in order after all. I'm enthusiastic about the basic idea of this patch, but because of issues like TFB raised (his issue, and another mentioned in a reply) I am somewhat skeptical about getting such a patch right the first time. It's not that it's hard to keep it from being a solid mass of showstopper bugs, but it might take a while to settle on a spec where you don't end up saying "working as designed" too often. (In my experience anything policy-related where you have settings which override other settings --- not just in compiler behavior, but in networking or security or scheduling priority or error handling or whatever --- tends to be tricky this way.) I don't think we have any particularly well-developed tradition for things which are particularly tricky this way, but for this patch I think it might be a good idea to invent something. Perhaps a status like "useful but currently experimental and unstable: if you hassle us for changing the interface in four months, we will laugh at you either to your face or behind your back or both..." -- William Harold Newman <wil...@ai...> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C Ubi saeva indignatio ulterius cor lacerare nequit. -- Jonathan Swift's epitaph |
From: Nikodemus S. <nik...@ra...> - 2007-07-01 19:01:00
|
William Harold Newman wrote: > I'm enthusiastic about the basic idea of this patch, but because of > issues like TFB raised (his issue, and another mentioned in a reply) I > am somewhat skeptical about getting such a patch right the first time. > It's not that it's hard to keep it from being a solid mass of > showstopper bugs, but it might take a while to settle on a spec where > you don't end up saying "working as designed" too often. (In my > experience anything policy-related where you have settings which > override other settings --- not just in compiler behavior, but in > networking or security or scheduling priority or error handling or > whatever --- tends to be tricky this way.) While it is a slightly different topic, I submit a substantial dislike of the optimization policy space: there are just too many combinations to keep straight. No, I don't have any clear ideas about what should or could be done. > I don't think we have any particularly well-developed tradition for > things which are particularly tricky this way, but for this patch I > think it might be a good idea to invent something. Perhaps a status > like "useful but currently experimental and unstable: if you hassle us > for changing the interface in four months, we will laugh at you either > to your face or behind your back or both..." I'm not sure if sbcl-devel swallowed my message about having committed an experimental version of this as 1.0.7.4... Here's what the docstring says: "Assing a minimum value to an optimization quality. QUALITY is the name of the optimization quality to restrict, and MIN (defaulting to zero) is the minimum allowed value. Returns the alist describing the current policy restrictions. If QUALITY is NIL or not given, nothing is done. Otherwise, if MIN is zero or not given, any existing restrictions of QUALITY are removed. If MIN is between one and three inclusive, it becomes the new minimum value for the optimization quality: any future proclamations or declarations of the quality with a value less then MIN behave as if the value was MIN instead. This is intended to be used interactively, to facilitate recompiling large bodies of code with eg. a known minimum safety. EXPERIMENTAL INTERFACE: Subject to change." Cheers, -- Nikodemus |
From: <wil...@ai...> - 2007-07-02 18:11:34
|
On Sun, Jul 01, 2007 at 10:00:47PM +0300, Nikodemus Siivola wrote: > William Harold Newman wrote: > > >I'm enthusiastic about the basic idea of this patch, but because of > >issues like TFB raised (his issue, and another mentioned in a reply) I > >am somewhat skeptical about getting such a patch right the first time. > >It's not that it's hard to keep it from being a solid mass of > >showstopper bugs, but it might take a while to settle on a spec where > >you don't end up saying "working as designed" too often. (In my > >experience anything policy-related where you have settings which > >override other settings --- not just in compiler behavior, but in > >networking or security or scheduling priority or error handling or > >whatever --- tends to be tricky this way.) > > While it is a slightly different topic, I submit a substantial dislike > of the optimization policy space: there are just too many combinations > to keep straight. Indeed. And besides that, I'd nominate the way that there seems to be no completely satisfactory way to DECLAIM OPTIMIZE on a single source file or compilation unit. I'll also be the Nth programmer to lament that the CLTL2 facilities for introspection (?) on optimization policy were dropped on the floor. > No, I don't have any clear ideas about what should or could be done. nor I > >I don't think we have any particularly well-developed tradition for > >things which are particularly tricky this way, but for this patch I > > I'm not sure if sbcl-devel swallowed my message about having committed > an experimental version of this as 1.0.7.4... > EXPERIMENTAL INTERFACE: Subject to change." Aha, I missed that, sorry. Yes, that's basically what I had in mind. -- William Harold Newman <wil...@ai...> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C <lukego> listen to us both trying to be conciliatry when we should be fighting to the death on a rotating platform with retractable spikes :) -- http://tunes.org/~nef/logs/lisp/07.06.23 |
From: Nikodemus S. <nik...@ra...> - 2007-12-11 18:15:50
|
On Jul 2, 2007 6:16 PM, William Harold Newman <wil...@ai...> wrote: > On Sun, Jul 01, 2007 at 10:00:47PM +0300, Nikodemus Siivola wrote: > > While it is a slightly different topic, I submit a substantial dislike > > of the optimization policy space: there are just too many combinations > > to keep straight. > > Indeed. And besides that, I'd nominate the way that there seems to be > no completely satisfactory way to DECLAIM OPTIMIZE on a single source > file or compilation unit. I'll also be the Nth programmer to lament > that the CLTL2 facilities for introspection (?) on optimization policy > were dropped on the floor. To the extent that I've been thinking about this, I'm starting to believe that if not the right thing, a decent approximation would be to document the various derived policies we define in policies.lisp, export them, and allow users to say just what they mean. Exporting all of them might be a bit much (esp. the ones that deal with implementation details), but things like TYPE-CHECK, STACK-ALLOCATE- DYNAMIC-EXTENT, MERGE-TAIL-CALLS, and RECOGNIZE-SELF-CALLS sound like good candidates. Cheers, -- Nikodemus |