cl-ppcre-devel March 2005

cl-ppcre-devel@common-lisp.net

4 participants
9 discussions

RE: TR: [cl-ppcre-devel] New release 1.2.4
by Kick Damien-DKICK1 09 Mar '05

09 Mar '05

Edi Weitz [edi(a)agharta.de] wrote: > On Tue, 8 Mar 2005 13:17:41 -0600, Kick Damien-DKICK1 > <DKICK1(a)motorola.com> wrote: > > > New code: (EVAL-WHEN (EVAL COMPILE LOAD) > > (DEFVAR *STANDARD-SPEED-AND-SAFETY* > > '((SPEED 0) (SAFETY 3)))) > > (DEFUN FOO () > > (DECLARE (OPTIMIZE #.*STANDARD-SPEED-AND-SAFETY*)) > > ...) > > Looks cool to me. How about a patch for CL-PPCRE? So (optimize #.*standard-speed-and-safety*) does not actually work because it gives (optimize ((speed 0) (safety 3))) so I changed it to something like the following: (defvar *standard-speed-and-safety* '(optimize (speed 0) (safety 3))) (defun foo () (declare #.*standard-speed-and-safety*) ...) because I don't know of any way to "splice" the *standard-speed-and-safety* into the optimize form. Anyway, I've successfully run "(cl-ppcre-test:test)", with and without convincing Python to actually attempt optimization, but I've not rerun the benchmarks. BTW, instead of having two DEFPACKAGE forms in "packages.lisp", one with uninterned symbols and the other with srings, why not simply have one DEFPACKAGE form with srings? Anyway, I've attached a patch. Please let me know how it looks. -- Damien Kick

2 2

RE: TR: [cl-ppcre-devel] New release 1.2.4
by Kick Damien-DKICK1 09 Mar '05

09 Mar '05

Edi Weitz [edi(a)agharta.de] wrote: > > On Tue, 8 Mar 2005 13:17:41 -0600, Kick Damien-DKICK1 > <DKICK1(a)motorola.com> wrote: > > > New code: (EVAL-WHEN (EVAL COMPILE LOAD) > > (DEFVAR *STANDARD-SPEED-AND-SAFETY* > > '((SPEED 0) (SAFETY 3)))) > > (DEFUN FOO () > > (DECLARE (OPTIMIZE #.*STANDARD-SPEED-AND-SAFETY*)) > > ...) > > Looks cool to me. How about a patch for CL-PPCRE? I'd be more than happy to be able to help with something like this. Should be able to find spare time to put something together by <pause> I dunno, next week. -- Damien Kick

2 1

RE: TR: [cl-ppcre-devel] New release 1.2.4
by Kick Damien-DKICK1 08 Mar '05

08 Mar '05

I'll do a version based on read time evaluation first because it looks like the easiest thing to do. I'm going to want to experiment with the macro expanding to a LOCALLY expression anyway, for my own edification, so maybe I'll put together two different versions... -- Damien Kick -----Original Message----- From: Edi Weitz [mailto:edi@agharta.de] Sent: Tuesday, 08 March, 2005 14:49 To: gwking(a)metabang.com Cc: ML CL-PPCRE; Kick Damien-DKICK1 Subject: Re: TR: [cl-ppcre-devel] New release 1.2.4 On Tue, 8 Mar 2005 14:43:36 -0500, Gary King <gwking(a)metabang.com> wrote: > I suggest taking a page from GBBopen's book and using something > like: > > (defmacro with-standard-optimization (&body body) > `(locally (declare (optimize (speed 1) (safety 3) (debug 1))) > ,@body)) > > (defun foo () > (with-standard-optimization > ...)) > > this has the advantage of not requiring the read time evaluation of #. > which some view as a security risk. I have to admit that I find the #. approach more aesthetically pleasing - one reason is that it doesn't introduce a new level of nesting. I fail to see the security risk - we're not talking about data entered from a random website or somesuch. Cheers, Edi.

1 0

RE: TR: [cl-ppcre-devel] New release 1.2.4
by Kick Damien-DKICK1 08 Mar '05

08 Mar '05

Edi Weitz [edi(a)agharta.de] wrote: > On Tue, 8 Mar 2005 10:52:47 -0600, Kick Damien-DKICK1 > <DKICK1(a)motorola.com> wrote: > > > Personally, I still would like to know of an easy way to change > > these settings. > > Me too. If there's a simple idiom for this I'll be happy to > incorporate it into CL-PPCRE. Silly Damien, RTFM. There was a X3J13 issue <http://tinyurl.com/6mw2d> in which the ability to write macros that expanded into declaration forms was removed. The discussion of the issue includes examples of how to acheive the wanted affect. For the moment, the following is my favorite: Another tactic would be: Old code: (EVAL-WHEN (EVAL COMPILE LOAD) (DEFVAR *SPEEDY* NIL)) (DEFMACRO USE-STANDARD-SPEED-AND-SAFETY () (IF *SPEEDY* `(DECLARE (OPTIMIZE (SPEED 3) (SAFETY 0))) `(DECLARE (OPTIMIZE (SPEED 0) (SAFETY 3))))) (DEFUN FOO () (USE-STANDARD-SPEED-AND-SAFETY) ...) New code: (EVAL-WHEN (EVAL COMPILE LOAD) (DEFVAR *STANDARD-SPEED-AND-SAFETY* '((SPEED 0) (SAFETY 3)))) (DEFUN FOO () (DECLARE (OPTIMIZE #.*STANDARD-SPEED-AND-SAFETY*)) ...) -- Damien Kick

3 3

RE: TR: [cl-ppcre-devel] New release 1.2.4
by Kick Damien-DKICK1 08 Mar '05

08 Mar '05

-----Original Message----- From: Gary King [mailto:gwking@metabang.com] Sent: Tuesday, 08 March, 2005 13:44 To: Edi Weitz Cc: ML CL-PPCRE; Kick Damien-DKICK1 Subject: Re: TR: [cl-ppcre-devel] New release 1.2.4 I suggest taking a page from GBBopen's book and using something like: (defmacro with-standard-optimization (&body body) `(locally (declare (optimize (speed 1) (safety 3) (debug 1))) ,@body)) (defun foo () (with-standard-optimization ...)) this has the advantage of not requiring the read time evaluation of #. which some view as a security risk. Hmmm... if one can write a macro that expands to a LOCALLY form in the same place and for the same reason as would might've done with DECLARE, then what is the point of having disallowed one from writing a macro that expands into a DECLARE <http://tinyurl.com/6v4v3> http://tinyurl.com/6v4v3? <shrug> I suppose it doesn't matter; it does seem better to be able to write a macro that conditionally expands into different values of optimization settings than use read time evaluation. I'll try riffing off of this GBBopen approach. -- Damien Kick

2 1

RE: TR: [cl-ppcre-devel] New release 1.2.4
by Kick Damien-DKICK1 08 Mar '05

08 Mar '05

Edi Weitz [edi(a)agharta.de] wrote: > On Tue, 8 Mar 2005 10:52:47 -0600, Kick Damien-DKICK1 > <DKICK1(a)motorola.com> wrote: > > > Personally, I still would like to know of an easy way to change > > these settings. > > Me too. If there's a simple idiom for this I'll be happy to > incorporate it into CL-PPCRE. Well, I suppose that something like the following might be a step in the right direction. (defun f (x y) (+ x y)) (defun g (x y z) (+ x y z)) (locally (declare (optimize speed (safety 0) (debug 0))) (defun f* (x y) (declare (fixnum x y) (values fixnum)) (+ x y)) (defun g* (x y z) (declare (fixnum x y z) (values fixnum)) (+ x y z))) One still has to crank up Emacs to recompile with a different setting but at least one can effect many defuns by making a change in one place. I suppose that one would have to do something like the following to allow one to make such a change without having to use Emacs. ;; keywords seem to be the easiest to "parse" (defmacro equivocally ((&whole values) &body forms) ...) (equivocally (:speed *cl-ppcre-speed-declaration-setting* :debug *cl-ppcre-debug-declaration-setting*) (defun frobnicate (frob) (equivocate (optimize speed debug)) (twiddle (this frob)))) EQUIVOCALLY would have to be a macro that would walk the code, looking for EQUIVOCATE forms, substituting an equivalent DECLARE with the values from the forms used in the EQUIVOCALLY form in place of the EQUIVOCATE. -- Damien Kick

1 0

RE: TR: [cl-ppcre-devel] New release 1.2.4
by Kick Damien-DKICK1 08 Mar '05

08 Mar '05

Edi Weitz [edi(a)agharta.de] wrote: > On Tue, 8 Mar 2005 11:23:11 +0100, Sebastien Saint-Sevin > <seb-cl-mailist(a)matchix.com> wrote: > > > Can you give us a brief feedback on the kind of problems you faced > > with DEBUG set to 0? Or the reasons that motivated this move. > > No real problems. It just turned out that with (DEBUG 0) tools like > SLIME couldn't show the arglists of CL-PPCRE functions which is a > feature that I like to have. Also, from tests with CMUCL it seems > that you don't loose performance due to this change. Personally, I still would like to know of an easy way to change these settings. For example, if something like the following would work: (defun frobnicate (frob) (declare (optimize (speed *cl-ppcre-speed*) (debug *cl-ppcre-debug*))) (twiddle (this frob)) (tweak (that frob))) A while back, when I was having my Lisp run-time die in some code that was using CL-PPCRE, I went and changed all of the optimization settings for saftey/debug to get some kind of stack trace, but I had to find/change all of the settings with Emacs. There has got to be an easier way to do this; is there really no Common Lisp paradigm for this? I've tried asking on comp.lang.lisp but don't remember getting a reply. Would one have to write a macro? (defun frobnicate (frob) (with-declaration ((speed-level *cl-ppcre-speed*) (debug-level *cl-ppcre-debug*)) (optimize (speed speed-level) (debug debug-level)) (twiddle (this frob) (tweak (that frob))))) -- Damien Kick

2 1

TR: [cl-ppcre-devel] New release 1.2.4
by Sebastien Saint-Sevin 08 Mar '05

08 Mar '05

Hi Edi, Can you give us a brief feedback on the kind of problems you faced with DEBUG set to 0? Or the reasons that motivated this move. Cheers, Sebastien. -----Message d'origine----- De : cl-ppcre-devel-bounces(a)common-lisp.net [mailto:cl-ppcre-devel-bounces@common-lisp.net]De la part de Edi Weitz Envoye : lundi 7 mars 2005 23:10 A : cl-ppcre-devel(a)common-lisp.net; cl-ppcre-announce(a)common-lisp.net Objet : [cl-ppcre-devel] New release 1.2.4 ChangeLog: Version 1.2.4 2005-03-07 Changed DEBUG optimize quality from 0 to 1 Download: <http://weitz.de/files/cl-ppcre.tar.gz> Cheers, Edi. _______________________________________________ cl-ppcre-devel site list cl-ppcre-devel(a)common-lisp.net http://common-lisp.net/mailman/listinfo/cl-ppcre-devel

2 1

[cl-ppcre-devel] New release 1.2.4
by Edi Weitz 07 Mar '05

07 Mar '05

ChangeLog: Version 1.2.4 2005-03-07 Changed DEBUG optimize quality from 0 to 1 Download: <http://weitz.de/files/cl-ppcre.tar.gz> Cheers, Edi.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

cl-ppcre-devel March 2005