dmdz

[Ellery Newcomer]

On 03/17/2010 03:53 PM, Andrei Alexandrescu wrote:
> Thanks for replying to this. I'd been afraid that I was coming off too
> critical. (I counted the ANTLR files as modules, and I think that's
> fair.) To give you an idea on where I come from, distributing dmdz with
> dmd is also a message to users on how things are getting done in D.

dang right you are. If you're going to count the antlr runtime, then 
maybe you should also be counting druntime and the sections of phobos 
that I used?

>
> For the problem "Compile a D file and all its dependents, link, and run"
> the solution rdmd has 469 lines. It seems quite much to me, but I
> couldn't find ways to make it much smaller.

user wouldn't know that from any dmd distribution I've ever seen.

>
> For the problem "Given a zip file containing a D program, build it" the
> dmdz solution is quite large. If we count everything:
>
> $ wc --lines dmdz.d import/antlrrt/*.d lexd.g opts.d sed.sh
> 782 dmdz.d
> 891 import/antlrrt/collections.d
> 551 import/antlrrt/exceptions.d
> 1253 import/antlrrt/lexing.d
> 2085 import/antlrrt/parsing.d
> 10 import/antlrrt/runtime.d
> 600 import/antlrrt/utils.d
> 436 lexd.g
> 88 opts.d
> 13 sed.sh
> 6709 total

forgot generated/*.d

should bump it up to 11 or 12 k.

>
> Arguably we can discount the import stuff, although I'd already raise
> some objections:
>
> $ wc --lines dmdz.d lexd.g opts.d sed.sh
> 782 dmdz.d
> 436 lexd.g
> 88 opts.d
> 13 sed.sh
> 1319 total
>

lexd.g and sed.sh are only there for reference. I hate it when machine 
generated source code is in a project, but the source grammar isn't.

> That would suggest that it's about three times as difficult to build
> stuff present in a zip file than to deduce dependencies and build stuff
> not in a zip file. I find that difficult to swallow because to me
> building stuff in a zip file should be in some ways easier because there
> are no dependencies to deduce - they can be assumed to be in the zip file.
>
> I looked more through the program and it looks like it uses the zip
> library (honestly I would have used system("unzip...")), which does add
> some aggravation for arguably a good reason. (But I also see there's no
> caching, which is an important requirement.)

eh?

>
> Nice, but I don't know why you need to understand dmd's flags instead of
> simply forwarding them to dmd. You could define dmdz-specific flags
> which you parse and understand, and then dump everything else to dmd,
> which will figure its own checking and error messages and all that.
>

filtering out flags that screw things up for the build in question; 
knowing where the resultant executable is supposed to be;

>
> I think it would be great to remove all stuff that's not necessary. I
> paste at the end of this message my two baselines: a shell script and a
> D program. They compare poorly with your program, but are extremely
> simple. I think it may be useful to see how much impact each feature
> that these programs lack is adding size to your solution.
>
>
> Andrei

You come at this problem like "It should be an eloquent showcase of what 
D has to offer."

I come at it like "I want this to be generally useful. To me."

In my opinion, how well it works trumps how many lines of code it took 
to write. But for the aforementioned bug, I never would have looked at 
rdmd's source, and even then I didn't notice how many lines of code it 
was. The way dmdz was written is based on the needs that presented 
themselves to me at the time. So far I've run it against three different 
projects and I'm happy with it the way it's turned out.

1. dmdz

toy example. not much here.

2. dexcelapi

port of jexcelapi, 90k loc (that thing must have shrunk when I wasn't 
looking, I was sure it was 200k), ~ 400 source files. Big. Dumping 
everything to dmd is easy enough to implement one way or another, but 
when I hit an Out of Memory Error I need what -piecemeal has to offer. I 
found the offending file (still don't know what's up with it), commented 
it out, and I can dump everything to dmd again. Without it, I probably 
would have given up on D for another year and a half.

3. dcrypt

Today, I wanted to play with it, so I checked it out, popped dmdz.conf 
and a main.d in the directory and zipped the whole thing up.

dmdz dcrypt.zip

It worked. Without me doing anything to dmdz or dcrypt (except adding a 
string alias, &&^%^ tango).


I was kind of hoping others would try it and give their opinions, but 
apparently nobody else cares. Or they're on vacation, like I should be. 
Or they're giving the infamous 'silent approval'. Who knows.