The one at http://www.digitalmars.com/d/2.0/rdmd.html has the following code:

int eval(string todo)
{
    auto progname = tmpDir~"/eval.d";
    std.file.write(progname, todo);
    scope(exit) std.file.remove(progname);
    run("dmd -run " ~ progname);
    return 0;
}

I think this is a problem when there are several users.
Probably eval.d could be in a directory with a temporary name.

Georg Wrede wrote:
> The one at http://www.digitalmars.com/d/2.0/rdmd.html has the following code:
> 
> int eval(string todo)
> {
>     auto progname = tmpDir~"/eval.d";
>     std.file.write(progname, todo);
>     scope(exit) std.file.remove(progname);
>     run("dmd -run " ~ progname);
>     return 0;
> }
> 
> I think this is a problem when there are several users.
> Probably eval.d could be in a directory with a temporary name.

Yah, I changed it to:

int eval(string todo)
{
    MD5_CTX context;
    context.start();
    context.update(todo);
    ubyte digest[16];
    context.finish(digest);
    auto progname = std.path.join(tmpDir,
            "rdmd_eval" ~ digestToString(digest) ~ ".d");

    std.file.write(progname, todo);
    scope(exit) std.file.remove(progname);
    run("dmd -run " ~ progname);
    return 0;
}

By the way, md5 is so tedious to use. Five lines!! Should be one line to get a digest string. It's like, "let's see how to define an API that would take the most lines of code possible to use". Sigh.

Anyway, now with md5 in place I can reuse the executable filename such that successive calls to e.g. rdmd --eval "writeln(1 + 1)" do not compile anything. Can I assume the tmp directory will get cleaned in reasonable time by the system on both Windows and Unix?


Andrei

Andrei Alexandrescu wrote:
> [...]
> 
> Can I assume the tmp directory will get cleaned in reasonable time by the system on both Windows and Unix?
> 
> 
> Andrei

Not under Windows.  It waits until you're out of hard drive space, and then it pops up a wizard that says "You're out of disk space; please wait while I compute your savings!".

Usually, it then comes back and tells you "you can free 0 MB" because you ran it yesterday and it's too stupid to remember.

Sometimes, I wonder if there isn't someone at Microsoft whose job it is to come up with the single most effective way to aggravate users.  *sigh*

But yeah, in so far as I know, you'll have to manually manage the temp file cache.

  -- Daniel

Andrei Alexandrescu wrote:
> By the way, md5 is so tedious to use. Five lines!! Should be one line to get a digest string. It's like, "let's see how to define an API that would take the most lines of code possible to use". Sigh.

It is the way it is because it is the most straightforward possible translation of the RFC C code. This means that someone using the RFC C code would have no trouble translating their code to D.

Daniel Keep wrote:
> Andrei Alexandrescu wrote:
>>
>> Can I assume the tmp directory will get cleaned in
>> reasonable time by the system on both Windows and Unix?

> But yeah, in so far as I know, you'll have to manually manage the temp
> file cache.

The "original" rdmd saved files in ~/.rdmd and naturally had to manage the file cache itself.

My solution was to on each run check for old files and delete them. Any binary not used in six months got nuked. And any other kind of file got nuked if it had not been looked at in the last half hour.

The latter made debugging and tweaking very easy.

For example, to implement rdmd shebang for files not ending in .d I copied the original text file into ~/.rdmd with a .d suffix, and compiled it there. Also a copy of compiler error output was stored there.