Prev: Programming Job Openings
Next: Generate UUID that fits on 37 digits [0-9]
From: Robert Maas, http://tinyurl.com/uh3t on 6 May 2008 18:07
In conjunction with my ProxHash R&D project,
in late April I started work on a new dataflow automatic-updater
utilty which is somewhat like the Unix 'make' utility.

Background: Unix's 'make' uses a list of dependencies between various
disk files to automatically update a final output file such as an
executable. Typical use is to make sure each source file is compiled
to yield a more recent compiled file, and to make sure each
executable file is at least as recent as all compiled modules it's
built from. The Java's 'ant' utility goes further to support
updating of JAR files containing Class files in a similar manner.

But each of those utilities works *only* in using dependencies
between various disk files, and each effectively runs like a shell
script, starting a new utility (compiler, loader, JAR updater) for
each step in the dataflow that needs to be re-done.

New: My new utility 2008-4-MayLoad.lisp checks dependencies between
both disk files and in-memory data values (in a Lisp environment),
relating in-memory data values with the precursor data needed to
compute them and/or disk files used to back them up to avoid
time-consuming re-calculation. It does all its work from within
that single Lisp environment, not needing to start up any other
executables.

The first draft of my description of the algorithms is here:
<http://www.rawbw.com/~rem/NewPub/MayLoadSpec.txt>
I'm soliciting feedback in two areas:
- Any obvious flaws in the algorithms, especially where I claim
that some fact is "provably true". Can you produce any
counterexample? Based on the described algorithms, can you find
any case where any value is unnecessarily re-calculated or
re-loaded or re-saved?
- Any suggested changes in wording to make the description easier
to understand without changing the meaning.

Also I'm curious whether anybody else has already written a utility
like this, and if not I'm curious whether anybody likes my idea and
might have a practical use for it and would like to beta-test it
later when the code is more stable.
From: Leslie P. Polzer on 7 May 2008 03:32
On May 7, 12:07 am, make1.5.CalRob...(a)SpamGourmet.Com (Robert Maas,
tables.
>
> The first draft of my description of the algorithms is here:
> <http://www.rawbw.com/~rem/NewPub/MayLoadSpec.txt>
> I'm soliciting feedback in two areas:
> - Any obvious flaws in the algorithms, especially where I claim
> that some fact is "provably true". Can you produce any
> counterexample? Based on the described algorithms, can you find
> any case where any value is unnecessarily re-calculated or
> re-loaded or re-saved?
> - Any suggested changes in wording to make the description easier
> to understand without changing the meaning.

I'm going to take a look at it. In the meantime, do you know this
paper:

http://cs-www.cs.yale.edu/homes/dvm/papers/lisp05.pdf


> Also I'm curious whether anybody else has already written a utility
> like this, and if not I'm curious whether anybody likes my idea and
> might have a practical use for it and would like to beta-test it
> later when the code is more stable.

I'm very sure I will have use for this, please include me in that
testing phase.

Leslie
From: Pascal J. Bourguignon on 7 May 2008 03:39
make1.5.CalRobert(a)SpamGourmet.Com (Robert Maas, http://tinyurl.com/uh3t) writes:

> In conjunction with my ProxHash R&D project,
> in late April I started work on a new dataflow automatic-updater
> utilty which is somewhat like the Unix 'make' utility.
>
> Background: Unix's 'make' uses a list of dependencies between various
> disk files to automatically update a final output file such as an
> executable. Typical use is to make sure each source file is compiled
> to yield a more recent compiled file, and to make sure each
> executable file is at least as recent as all compiled modules it's
> built from. The Java's 'ant' utility goes further to support
> updating of JAR files containing Class files in a similar manner.

Well, it goes further only if you mean >=, but not >.
make is also able to update ar files containing .o files in a similar manner.
You just have to say so, using the syntax: libmine.a(fun.o)

-*- mode: compilation; default-directory: "/tmp/" -*-
Compilation started at Wed May 7 09:34:41

cd /tmp ; cat Makefile ; make clean all
#-------------------------
all:libmine.a
libmine.a:libmine.a(fun.o)
libmine.a(fun.o):fun.c
clean:
rm -f libmine.a
#-------------------------
rm -f libmine.a
cc -c -o fun.o fun.c
ar rv libmine.a fun.o
ar: creating libmine.a
a - fun.o
rm fun.o

Compilation finished at Wed May 7 09:34:41


> The first draft of my description of the algorithms is here:
> <http://www.rawbw.com/~rem/NewPub/MayLoadSpec.txt

> - :DATE = The timestamp (Universal Time) for which this data is correct

ant uses checksums, because timestamps don't have enough resolution
anymore. That's even more true when you work in RAM instead of
launching external disk based processes.

> Requesting a particular item of live data to be "current" traces backwards
> recursively through the dataflow to make sure all inputs are "current",
> per the following algorithm at each control point:

I can hear Kenny crying "Cells!" here...


--
__Pascal Bourguignon__
From: Leslie P. Polzer on 7 May 2008 04:49
On May 7, 12:07 am, make1.5.CalRob...(a)SpamGourmet.Com (Robert Maas,

> I'm soliciting feedback in two areas:
> - Any obvious flaws in the algorithms, especially where I claim
> that some fact is "provably true". Can you produce any
> counterexample? Based on the described algorithms, can you find
> any case where any value is unnecessarily re-calculated or
> re-loaded or re-saved?
> - Any suggested changes in wording to make the description easier
> to understand without changing the meaning.

What is "precursor data"? Can you give an example?

From: Robert Maas, http://tinyurl.com/uh3t on 7 May 2008 05:09
> From: "Leslie P. Polzer" <leslie.pol...(a)gmx.net>
> do you know this paper:
> http://cs-www.cs.yale.edu/homes/dvm/papers/lisp05.pdf

I have no way to read PDF files here.

> I'm very sure I will have use for this, please include me in that
> testing phase.

Google Groups doesn't show your full e-mail address, so I needed to
TELNET to a regular NNTP server to pull up your article. I found:
leslie.polzer(a)gmx.net
I suppose I could have guessed that from your family name,
but it's 4 hours past my bed time and I'm not fully alert.
I'll make a memo of your address to contact you by direct e-mail, OK?
 |  Next  |  Last
Pages: 1 2
Prev: Programming Job Openings
Next: Generate UUID that fits on 37 digits [0-9]