On Sunday, 3 February 2013 at 15:07:50 UTC, Dicebot wrote:
> On Sunday, 3 February 2013 at 14:51:59 UTC, Danny Arends wrote:
>> Perhaps I should create an requirements outline after reading the source:
>> From the post David links to:
>>
>> "2) Could somebody read the source and document the quirks of the
>> parser in painstaking detail, so that somebody else can do a
>> clean room implementation?"
>>
>> Gr,
>> Danny
>
> Yes, this is a common practice for avoiding copyright issues - one man reads the source and provides detailed spec, second re-implements needed stuff based on the spec without having a single look into original sources.

Yes, this is what I meant. Sorry, I should have made this clearer in the original post.

It's not like we realistically have to be afraid of Symantec suing anybody over that piece of code, but ideally Walter would be able to accept that rewritten piece of code back into DMD without having to fear any licensing issues.

David

On Sunday, 3 February 2013 at 14:51:59 UTC, Danny Arends wrote:
> Perhaps I should create an requirements outline after reading the source:

This would be great!

I want to avoid getting in touch with any non-free compiler code as much as possible as Walter generally seems very conscious of licensing issues and I don't want to jeopardize the future of LDC. Otherwise, I'd have done the boring part (writing up the spec) myself long ago.

The general mechanics of response files are well understood, so a spec wouldn't have to describe that extensively. The interesting points are the details like handling of quotes, recursion, …

David

On Sunday, 3 February 2013 at 00:37:55 UTC, David Nadlinger wrote:
>  1) Provide an Open Source clean-room implementation of response_expand, the function the DMD frontend uses to parse response files. Unfortunately, it is under the copyright belongs (partly?) to Symantec, so Walter can't simply re-license it for use in GDC/LDC, where it is needed to provide DMD compatibility (gdmd/ldmd). For the full discussion, see: http://forum.dlang.org/thread/kdce69%24303k%241@digitalmars.com

DMD response files use the same escaping syntax as the CommandLineToArgvW function.

Here is how rdmd constructs the file:
https://github.com/D-Programming-Language/tools/blob/master/rdmd.d#L367

I had looked at the DMD code, although it was a while ago and today I honestly couldn't say anything specific about it today. That's probably still not good enough for a clean-room reimplementation, though.

On 2/3/2013 6:31 PM, David Nadlinger wrote:
> It's not like we realistically have to be afraid of Symantec suing anybody over
> that piece of code, but ideally Walter would be able to accept that rewritten
> piece of code back into DMD without having to fear any licensing issues.

It's more about doing the right thing than acting out of fear of being sued.

I don't think we need to go so far as having a clean room team communicating with a dev team through a 3rd team of lawyers, but a common sense and good faith effort to not infringe is likely sufficient.

On 2/3/2013 6:52 PM, David Nadlinger wrote:
> I want to avoid getting in touch with any non-free compiler code as much as
> possible as Walter generally seems very conscious of licensing issues and I
> don't want to jeopardize the future of LDC.

Having D be IP-clean is essential to the future of D.

BTW, one thing I like very much about github is it provides an audit trail of where contributed code comes from, for all to see.

On 2/26/2013 4:50 PM, Vladimir Panteleev wrote:
> On Sunday, 3 February 2013 at 00:37:55 UTC, David Nadlinger wrote:
>>  1) Provide an Open Source clean-room implementation of response_expand, the
>> function the DMD frontend uses to parse response files. Unfortunately, it is
>> under the copyright belongs (partly?) to Symantec, so Walter can't simply
>> re-license it for use in GDC/LDC, where it is needed to provide DMD
>> compatibility (gdmd/ldmd). For the full discussion, see:
>> http://forum.dlang.org/thread/kdce69%24303k%241@digitalmars.com
>
> DMD response files use the same escaping syntax as the CommandLineToArgvW function.

As I recall, that was the intent. I wrote it, however, before there was a CommandLineToArgvW function, so much of its behavior was determined by trial and error on how DOS dealt with command lines.

Such is inferrable from its intent, which was to enable command lines longer than DOS allowed.