On 03/17/2010 08:49 PM, Andrei Alexandrescu wrote:
Well that's generated. I counted what's needed to get things going.
Unless you meant that ironically...
Yes I was speaking in jest up to this point.
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.
My understanding is that lexd.g is your code so it should be included in
the size of the solution, whereas the generated code should not.
Yeah, you're right there.
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?
The idea is to not extract the files every time you build. If they are
in place already, the tool should recognize that.
It does that, but on a per-file basis.
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."
The tool shouldn't be a showcase. Obviously the primary purpose is for
the tool to be useful. The shell script and the D script are useful. I
am sure your tool is useful, but I think it doesn't hit the right
balance. I simply don't think it takes that much code to achieve what
the tool needs to achieve.
All right. I'll try cutting things out and see where I end up.
I'm not contending the tool is not useful. I'm just saying it is too big
for what it does, and that that does matter with regard to distributing
it with dmd.
I still don't see why (other than lexd.g adds ~ 10k loc just to get the
line 'module foo.bar;' out of a source file)
BTW Walter made a very nice suggestion: make a .zip file in the command
line be equivalent to listing all files in that zip in the command line.
I think it's this kind of idea that greatly simplifies things.
Andrei
Fair enough.
