dmdz

[Ellery Newcomer]

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.