please find them attached until our server hosting becomes more stable.
meanwhile gitweb is available at: http://dwim.hu/gitweb/gitweb.cgi?p=cl-irregsexp;a=summary
Hi Attila,
Thanks for the patches. I've looked them over.
Attila Lendvai attila.lendvai@gmail.com writes: [...]
Subject: [PATCH] don't abbreviate in integer &key max-len. also propagate them to make them usable as (foo (integer :max-length 2))
Propagation looks good.
However, why do you feel the need to rename max-len and min-len? They are used already and there are still many variables called x-len . . .
I guess I should add specialised float matchers too.
[...]
Subject: [PATCH] some care for replace.lisp, notably get rid of the single usage of iterate
What's wrong with iterate?
You change it to an nreverse!
[...]
-(defmacro match-replace-helper ( string &rest match-replacements) +(defmacro match-replace-helper (string &body match-replacements)
Why are you using BODY here for a non-code form?
- (with-unique-names (before replacement-text after)
- `(let (,replacement-text)
(if-match-bind (,before (or,@(loop for (match replacement) in match-replacementscollect `(progn ,match '(setf ,replacement-text (force-to-target-sequence ,replacement))))(last)),after),string(values ,before ,replacement-text ,after)nil))))-(defun-speedy concat-byte-vector (seqs)
- (cond ((rest seqs)
(let ((len (loop for s in seqs summing (length (the byte-vector s)))))(let ((ret (make-byte-vector len)) (i 0))(loop for a in seqs do (let ((s (force-simple-byte-vector a))) (replace ret s :start1 i) (incf i (length s))))ret)))- (t
(force-byte-vector (first seqs)))))-(defun-speedy concat-string (seqs)
- (apply 'concatenate 'string seqs))
+(defun-speedy concatenate-sequences (prototype sequences)
- (etypecase prototype
- (string
(let ((*print-pretty* nil))
This makes no difference I believe ^^^^
(with-output-to-string (out)(dolist (el sequences)(write-string el out)))))
This rewrite seems in aid of faster string concatenation. I have a good strcat somewhere, I can put that in. Do you have a benchmark?
[...]
However, why do you feel the need to rename max-len and min-len? They are used already and there are still many variables called x-len . . .
abbreviations are bad, because there are a million of them while there's only on non-abbreviated form (ideally, if the naming is obvious).
arguably in this case it should be :maximum-length but max/min is so well spread that it's one of the very few abbreviations that we accept internally in public API. but it's your lib... my patches are only suggestions! :)
Subject: [PATCH] some care for replace.lisp, notably get rid of the single usage of iterate
What's wrong with iterate?
well, not much, except that it feels a bit like an oddball in the code with the iter: package prefixes. and it's one more dependency for a single use... otherwise i don't have much against iter (except that it screws up the environment which brakes various things inside its body, but that's a whole different story)
You change it to an nreverse!
do some profiling... ;)
it's not faster for sure, but i doubt you'll be able to point out the difference.
Why are you using BODY here for a non-code form?
it plays much better with slime indentation, but that's about all.
i usually freely exchange &body and &rest as they have no other effects than that (and documentation-wise it's arguable that the body there really is a body, that body is just a DSL not lisp...)
This makes no difference I believe ^^^^
profile it. on sbcl with-output-to-string creates a string-output-stream which is more expensive when pretty-printing stuff is initialized.
This rewrite seems in aid of faster string concatenation. I have a good strcat somewhere, I can put that in. Do you have a benchmark?
not for this specific case, but i went through quite a few profiling sessions and it seemed to be the fastest string concatenation (on sbcl).
Hi Attila,
Attila Lendvai attila.lendvai@gmail.com writes: [...]
arguably in this case it should be :maximum-length but max/min is so well spread that it's one of the very few abbreviations that we accept internally in public API. but it's your lib... my patches are only suggestions! :)
I should revisit the code anyway to add single and double floats and as you are so nice about it, I accept your suggestion :-)
[...]
You change it to an nreverse!
do some profiling... ;)
it's not faster for sure, but i doubt you'll be able to point out the difference.
Thinking about it the whole idea of building up a list of things to concatenate (now with nreverse) and then concatenating them in a weird way is wrong. (The nreverse should be high up on the profile and if it's not then that's a bug showing that the rest is too slow.)
There shouldn't be the big difference between byte-vectors and strings either.
I will get together a benchmark and make a better implementation.
[...]
Why are you using BODY here for a non-code form?
it plays much better with slime indentation, but that's about all.
i usually freely exchange &body and &rest as they have no other effects than that (and documentation-wise it's arguable that the body there really is a body, that body is just a DSL not lisp...)
That makes sense. Good points.
This makes no difference I believe ^^^^
profile it. on sbcl with-output-to-string creates a string-output-stream which is more expensive when pretty-printing stuff is initialized.
Thanks for the info!
This rewrite seems in aid of faster string concatenation. I have a good strcat somewhere, I can put that in. Do you have a benchmark?
not for this specific case, but i went through quite a few profiling sessions and it seemed to be the fastest string concatenation (on sbcl).
Before tpd2 dumped strings altogether I had a fast strcat.
However, copying strings multiple times for no reason surely isn't a good idea, and that's what's happening here. I will try to come up with a better way.
Should be done before Monday, if not shout!
However, copying strings multiple times for no reason surely isn't a good idea, and that's what's happening here. I will try to come up with a better way.
Should be done before Monday, if not shout!
great!
although i must note that it has no direct effect on me currently, so don't fall in the trap of too early, too much and unprofiled optimization...
the only reason i've touched that part of the code is the iter dependency, which is arguable anyway. we like and use iter more than loop, but it's at the bottom of our TODO to write an iter lib using a proper walker and properly updating the lexenv...
we have several transitive cl-ppcre dependencies, and all our own usages are in non-performance-critical code, so for now we don't bring in cl-irregsexp as a +1 dep.
cl-irregsexp-devel@common-lisp.net
-
Attila Lendvai -
John Fremlin