clocc-devel

Re: New member!

[Sam S. <sd...@gn...>]

>>>> In message <200...@is....>
>>>> On the subject of "Re: New member!"
>>>> Sent on Thu Jan 27 14:28:42 EST 2000
>>>> Honorable Don Cohen <do...@co...> writes:
 >> 
 >> I suggest maintaining one readme file in which the entire contents
 >> of the archive are listed.  You should be able to download that and
 >> then search for what you want, rather than having to download many
 >> different subdirectories.

the archiving provided by sourceforge is quite adequate, so I suggest we
use it.

 >> A comment on one of the requirements for code in this repository:
 >>     Self-contained, i.e. does not require packages not in this
 >>     repository,
 >> I suggest that even reliance on this repository be minimized.

NO WAY!!!!
then each and every package in CLOCC will reimplement the same stuff
over and over again.
I suggest mandatory support of defsystem by each package - this way we
can more or less be sure that people can get what they want to compile. 

 >> I like the others, but is there such a thing as totally unlicensed
 >> code?  Do you have to put something on the top in order to make it
 >> qualify as that?  What's "public domain"?  I'm open to suggestions.

*IANAL*

1. everything you write is automatically (c) by you.

2. "unlicensed" means that you do not give *anyone* any permission to
   use the code.

3. PD means that you explicitly declared that anyone can take it.  e.g.,
   if you state in your header "this code is placed in the public domain
   by the author", I can take the code and do whatever I want with it,
   and you will never be able to prevent me from doing it (I am not sure
   I can (c) what you wrote, but I can certainly base a proprietary
   system on it).

4. I suggest GPL for "end user code" and LGP for what other programmers
   will want to use.

 >> A few other suggestions:
 >> - Each piece of code, as much as possible should do one thing, so you
 >> can take what you need without having to get a lot of extra stuff.

do you want 100000 different files? :-)
memory is cheap.


-- 
Sam Steingold (http://www.podval.org/~sds)
Micros**t is not the answer.  Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
186,000 Miles per Second.  It's not just a good idea.  IT'S THE LAW.

Re: New member!

[<do...@co...>]

So who's on this list so far?
I can't seem to find out.  (Authentication fails?)
I see one undigested member of clocc-list.

I suggest maintaining one readme file in which the entire contents of
the archive are listed.  You should be able to download that and then
search for what you want, rather than having to download many
different subdirectories.  
I notice a good many empty subdirectories under src.  Is there some
organizational plan?

A comment on one of the requirements for code in this repository:
    Self-contained, i.e. does not require packages not in this
    repository, 
I suggest that even reliance on this repository be minimized.

I like the others, but is there such a thing as totally unlicensed
code?  Do you have to put something on the top in order to make it
qualify as that?  What's "public domain"?  I'm open to suggestions.

A few other suggestions:
- Each piece of code, as much as possible should do one thing, so you
can take what you need without having to get a lot of extra stuff.
- Each piece (meant to be used as part of a larger system) should be
in its own package (which most of my code violates so far, but which
I'll try to fix before I send it in) with documented external
interfaces.
- Each piece should minimize its impact on the rest of the system.
Acceptable impact is adding a new package, adding a new element to
*modules*.  It's real bad to change the meaning/value of anything in
the standard environment (like changing *features*, *print-pretty*, 
or the standard readtables) unless the package is only meant to do
that one thing.  Even then, e.g., if you provide a new readmacro,
it's best to provide a function that will install it if/when/where
the user wants.

Perhaps we can try to agree on some standards and post them somewhere.
I look forward to hearing additional suggestions.

Now finally to get around to answering the original message:

  Tell us about your intended code contributions.

I guess I should look around and find out.  I should also look at the 
things I find in order to make sure they're in shape for the library.

Below is the first (and smallest) installment for your consideration
and reading pleasure.  It's meant for very low level optimization,
where you want to find out how long some tiny piece of code takes to
run and look at its disassembly.  It measures the time by running the
code in a loop, doing it more and more times looking for a stable
result.  I think in this special case it's reasonable to leave the
code in the user package cause this is not meant to be called by other
programs or to be saved as part of a larger application.
Please send me your opinions/suggestions/complaints/...

================
;;; -*- Mode: Common-Lisp; Package: USER; -*-

(in-package :user)

#|
Measure-usec returns the time it takes to do something in microseconds,
e.g., (measure-usec '(length *features*))
will do (length *features*) enough times (compiled) to estimate with
reasonable accuracy how long it takes.  

The bindings argument allows you to time things that use local variables:
(measure-usec '(+ x y) :bindings '((x 1) (y 2)))

The precision argument describes the desired accuracy, e.g., .1 means
within 10%.  Of course, a much smaller value, e.g., .01, may never 
converge.  (However the max-time argument will override that.)

Other keyword arguments are a maximum time (seconds) allowed to do the
measurement, a minimal number of times to run the code, and the
compiler optimization settings, e.g., ((speed 3) (debug 0))

It's worth mentioning that compilers can sometimes optimize out more
than you want for such a test.  For instance, in the example above
they may realize that x and y never change during the computation, so
the + really computes a constant.  Even worse, they might recognize
that the loop is really useless.

Obviously there's overhead in measurement.  For very fast operations
the actual results should not be taken too seriously.  However the
difference between the results for similar forms does seem pretty
reliable.  Note, however, that the time for accessing variables may
depend on where they're bound and how.  So it's really only fair to
compare forms that access the same variables in the same way the same
number of times. 

The return values are:
- the number of microseconds per iteration
- the number of iterations used to get this average
- the time (get-internal-run-time) that many iterations took
|#

(provide :measure-usec)

(defvar *PRODUCTION-COMPILER-OPTIONS*
 '(:speed 3 :safety 1 :space 1 :debug 1))

(defun measure-usec (code &key &allow-other-keys (precision .05)
                               bindings (max-time 10) (min-n 0) optimize)
  (funcall
   (compile
    nil
    `(lambda (&aux (time1 0) time2 (n 1) ,.bindings)
       (declare (optimize ,.optimize))
       (labels ((rtime (&aux (tmp (get-internal-run-time)))
                  (run n)
                  (- (get-internal-run-time)
                     tmp))
                (run (n) (dotimes (i n) ,code)))
         (setf time2 (rtime))
         (loop until
               (or (> time2 ,(* (/ max-time 4)
                                internal-time-units-per-second))
                   ;; if that iteration took > .25 max, all earlier
                   ;; ones might have taken > .25 max, and the next
                   ;; will take > .5 max giving a total > max
                   (and (> n ,min-n) (> time2 ,(/ 1.0 precision))
                        (< (* time1 ,(* 2.0 (- 1.0 precision)))
                           time2
                           (* time1 ,(* 2.0 (+ 1.0 precision)))))
                   ;; e.g., consider it to have converged within 10%
                   ;; if new time within 10% of double previous time
                   ;; first few times should take care of paging etc.
                   )
             do (setf n (+ n n) time1 time2 time2 (rtime))))
       (values (* 1000000.0 (/ time2 n internal-time-units-per-second))
               n time2)))))

;; show disassembly of code
(defun show-asm (code &key bindings optimize)
  (disassemble
   (compile nil
            `(lambda () (declare (optimize ,.optimize))
                     (let ,bindings ,code)))))


================

The next piece (I'll try to get it in shape by tomorrow) is something
I have called at various times record-calls and monitor-calls.  It's a
monitoring package somewhat similar to the one in the repository now,
but instead of the traditional overall summary statistics (which show
you how much various functions cost in total and on average), this
records the individual calls.  It's meant for finding out WHICH calls
are taking a long time, and is also useful for debugging (you see a
history of calls with their inputs and outputs).

New member!

[Stefan <st...@hi...>]

Hi devels,

I would like to introduce Don Cohen to you.

Hi Don!

Tell us about your intended code contributions.


Bye,

Stefan

Re: [clocc-devel] [clocc-devel]

[Peter V. E. <pva...@de...>]

On Thu, Jan 27, 2000 at 11:25:00AM +0100, Martin Cracauer wrote:
> Yes, the Sender: line is much better for automatic filtering anyway
> and the long subject line is a problem for my mailer setup, which
> displays date, From, subject etc. in 80 chars.

IMHO I would use the 
List-Id:  <clocc-devel.lists.sourceforge.net>
line from the header...

Groetjes, Peter

-- 
It's logic Jim, but not as we know it. | pva...@de... for pleasure,
"God, root, what is difference?" - Pitr|
"God is more forgiving." - Dave Aronson| http://cvs2.cons.org/~pvaneynd/

Re: [clocc-devel] [clocc-devel]

[Martin C. <cra...@co...>]

In <Pin...@hi...>, Stefan wrote: 
> Hi,
> 
> Shall I remove the [clocc-devel] - part in 
> the Subject - line for all posts?

Yes, the Sender: line is much better for automatic filtering anyway
and the long subject line is a problem for my mailer setup, which
displays date, From, subject etc. in 80 chars.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cra...@co...> http://www.cons.org/cracauer/
  Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536

[clocc-devel] [clocc-devel]

[Stefan <st...@hi...>]

Hi,

Shall I remove the [clocc-devel] - part in 
the Subject - line for all posts?

Bye,

Stefan

[clocc-devel] Test

[Stefan <st...@hi...>]

Hi,

does it work??? :-)