On 07/08/2013 11:43 AM, eles wrote:
> Well, it worked! Thanks a lot!

Excellent. :-)

> I never properly succeed into accomplishing all these steps. It patched, but it never compiled to the end. Thank you for the new method.

I also struggled for a long time with patching the sources.  I suspect part of the problem was that I could not tell whether the build failures I was experiencing were because I hadn't patched the sources properly, or for other reasons.  At any rate, I never built gdc-4.7 successfully. :-\

Once I realized that I could use gcc-snapshot with gdc master, somehow it all came together.  Now that gcc 4.8 has been officially released, of course, we don't have to bother with that any more (... and there was much rejoicing:-).

> Kudos, Iain!

Also Johannes and Alex, and others.  It's been a big team effort :-)

On Mon, Jul 08, 2013 at 12:50:02PM +0200, Joseph Rushton Wakeling wrote:
> On 07/08/2013 11:45 AM, eles wrote:
> > Just me alone, I do not feel that I have enough time and competence to do that.  But, what about to form a venture, the three of us? (JRW, HST and me, Iain already has a lot of job to do)
> > 
> > The goal would be to D-ify the gdmd.
> > 
> > I will learn some Perl in the process, but that's life...
> 
> My main concern is about regularity of time/attention I can give.  As you can see from my contributions to Phobos, I tend to have brief periods of furious activity and then long activity deserts -- which are mostly to do with commitments elsewhere.
> 
> Anyway, I'll happily give it a go if the two of you are up for it, and understand that at certain points I may just vanish for a while, at least contribution-wise :-)
> 
> I figure it's something we can all learn something by doing and once this is started we might be able to get others in as well.
[...]

I forked GDMD on github and took a first stab at D-ifying it:

	https://github.com/quickfur/GDMD/tree/dport

The new code is in gdmd.d -- I haven't updated the Makefile to build it yet, so you'll have to compile it by hand.  It can do very simple compiles now (list of .d files -> executable), including compile itself. :) It can read dmd.conf and setup environment variables accordingly, though I haven't actually tested whether it's really doing what I think it's doing.  (Anybody up for writing unittests? ;-))

However, NO command-line options are parsed right now, so it can't handle anything beyond just a list of .d files.  I also haven't tested anything on Windows in spite of the version(Windows) blocks; so I've no idea if that code actually works.  But it's a start. :)

I decided to write idiomatic D instead of a 1-to-1 translation of the Perl version, so I took some liberties in the program structure.  But I do use the Perl version as the go-to reference at each point, so it *should* in theory be identical in functionality at the end.

Comments / flames / pull requests welcome. ;-)


T

-- 
Tell me and I forget. Teach me and I remember. Involve me and I understand. -- Benjamin Franklin

On 07/10/2013 02:07 AM, H. S. Teoh wrote:
> I forked GDMD on github and took a first stab at D-ifying it:
> 
> 	https://github.com/quickfur/GDMD/tree/dport

Nice -- I'll try and have a play with that later :-)

First thing that strikes me -- and I know you're taking this from the original script -- what's with the references to dmd.conf?  GDC has no dmd.conf that I can recall (don't know whether it used to once upon a time), so this part of the script may even be dangerous if it winds up trying to find a config file that exists for dmd but not gdc/gdmd.

I'd have thought this could be deleted without problem.  If there _is_ a conf script that needs using, it should be renamed to avoid potential clashes with DMD proper.

> The new code is in gdmd.d -- I haven't updated the Makefile to build it yet, so you'll have to compile it by hand.  It can do very simple compiles now (list of .d files -> executable), including compile itself. :) It can read dmd.conf and setup environment variables accordingly, though I haven't actually tested whether it's really doing what I think it's doing.  (Anybody up for writing unittests? ;-))

I think that unittests can focus first on checking that gdmd input translates into correct gdc output (as in, what you get right now running gdmd --someoptions -vdmd).  That is, we can check each of the gdmd options singly and ensure they translate to correct gdc call strings.

I'm not sure to what extent we'd need to test combinations of gdmd flags as opposed to single flags.  There's also the whole bogeyman of contradictory flags (e.g. one turns on the optimizations, one turns them off...).

> However, NO command-line options are parsed right now, so it can't handle anything beyond just a list of .d files.  I also haven't tested anything on Windows in spite of the version(Windows) blocks; so I've no idea if that code actually works.  But it's a start. :)

Start with an "unrecognized switch" error that applies to everything? :-)

If I recall right, Phobos has some flag-parsing stuff in there, so we should be able to get that up and running fairly soon.

> I decided to write idiomatic D instead of a 1-to-1 translation of the Perl version, so I took some liberties in the program structure.  But I do use the Perl version as the go-to reference at each point, so it *should* in theory be identical in functionality at the end.

I think writing idiomatically from the get-go is a good idea.

> Comments / flames / pull requests welcome. ;-)

I'll be back with my big flaming torch and pitchfork after I've tested later today ... ;-)

Thanks for getting this under way!

Best wishes,

    -- Joe

On 07/10/2013 10:03 AM, Joseph Rushton Wakeling wrote:
> I'll be back with my big flaming torch and pitchfork after I've tested later today ... ;-)

Not your fault, but that delimited string inside printUsage() runs into a lovely syntax highlighting bug in d.vim: https://github.com/JesseKPhillips/d.vim/issues/18

On 10 July 2013 11:05, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
> On 07/10/2013 10:03 AM, Joseph Rushton Wakeling wrote:
>> I'll be back with my big flaming torch and pitchfork after I've tested later today ... ;-)
>
> Not your fault, but that delimited string inside printUsage() runs into a lovely syntax highlighting bug in d.vim: https://github.com/JesseKPhillips/d.vim/issues/18
>


Which reminds me, need to implement delimited strings in cgdb.... :)


--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 07/10/2013 02:07 AM, H. S. Teoh wrote:
> Comments / flames / pull requests welcome. ;-)

    string findGDC(string argv0)
    {
        // FIXME: this does not work 100% of the time.
        auto c = match(baseName(argv0), `^(.*-)?g?dmd(-.*)?$`).captures;
        auto targetPrefix = c[1];
        auto gdcDir = absolutePath(dirName(argv0));
        return buildNormalizedPath(gdcDir, targetPrefix ~ "gdc" ~ c[2]);
    }

The "obvious" solution is to have a gdmd.conf file which specifies what gdc executable to use and where to find it.  This should get round problems such as gdc being installed in /opt/gdc/bin and gdmd being in /usr/local/bin.

The default would be to select the gdc used to actually build gdmd, with an option to configure for alternative locations.

findGDC() should probably prioritize in this order:

    * If there's a gdmd.conf, use the gdcDir specified.  There probably
      needs to be a search priority of where to find the .conf file.

    * If not, use which gdc to identify what gdc to call
      (and possibly display a warning that there's no gdmd.conf?)

On a related note, can you clarify what the issues are with findScriptPath ... ?

    string findScriptPath(string argv0)
    {
        // FIXME: this is not 100% reliable; we need equivalent functionality to
        // Perl's FindBin.
        return absolutePath(dirName(argv0));
    }

On 10 July 2013 11:24, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
> On 07/10/2013 02:07 AM, H. S. Teoh wrote:
>> Comments / flames / pull requests welcome. ;-)
>
>     string findGDC(string argv0)
>     {
>         // FIXME: this does not work 100% of the time.
>         auto c = match(baseName(argv0), `^(.*-)?g?dmd(-.*)?$`).captures;
>         auto targetPrefix = c[1];
>         auto gdcDir = absolutePath(dirName(argv0));
>         return buildNormalizedPath(gdcDir, targetPrefix ~ "gdc" ~ c[2]);
>     }
>
> The "obvious" solution is to have a gdmd.conf file which specifies what gdc executable to use and where to find it.  This should get round problems such as gdc being installed in /opt/gdc/bin and gdmd being in /usr/local/bin.
>

Search all bin locations in $PATH for ./gdc - I'd imagine this is how Perl's FindBin works...


--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 07/10/2013 12:28 PM, Iain Buclaw wrote:
> On 10 July 2013 11:24, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
>> On 07/10/2013 02:07 AM, H. S. Teoh wrote:
>>> Comments / flames / pull requests welcome. ;-)
>>
>>     string findGDC(string argv0)
>>     {
>>         // FIXME: this does not work 100% of the time.
>>         auto c = match(baseName(argv0), `^(.*-)?g?dmd(-.*)?$`).captures;
>>         auto targetPrefix = c[1];
>>         auto gdcDir = absolutePath(dirName(argv0));
>>         return buildNormalizedPath(gdcDir, targetPrefix ~ "gdc" ~ c[2]);
>>     }
>>
>> The "obvious" solution is to have a gdmd.conf file which specifies what gdc executable to use and where to find it.  This should get round problems such as gdc being installed in /opt/gdc/bin and gdmd being in /usr/local/bin.
> 
> Search all bin locations in $PATH for ./gdc - I'd imagine this is how Perl's FindBin works...

In this case you need to take account of the possibility of multiple gdc/gdmd versions being installed in different places.  So, ideally, a given install of gdmd should be wedded to a given gdc.

On 10 July 2013 11:47, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
> On 07/10/2013 12:28 PM, Iain Buclaw wrote:
>> On 10 July 2013 11:24, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
>>> On 07/10/2013 02:07 AM, H. S. Teoh wrote:
>>>> Comments / flames / pull requests welcome. ;-)
>>>
>>>     string findGDC(string argv0)
>>>     {
>>>         // FIXME: this does not work 100% of the time.
>>>         auto c = match(baseName(argv0), `^(.*-)?g?dmd(-.*)?$`).captures;
>>>         auto targetPrefix = c[1];
>>>         auto gdcDir = absolutePath(dirName(argv0));
>>>         return buildNormalizedPath(gdcDir, targetPrefix ~ "gdc" ~ c[2]);
>>>     }
>>>
>>> The "obvious" solution is to have a gdmd.conf file which specifies what gdc executable to use and where to find it.  This should get round problems such as gdc being installed in /opt/gdc/bin and gdmd being in /usr/local/bin.
>>
>> Search all bin locations in $PATH for ./gdc - I'd imagine this is how Perl's FindBin works...
>
> In this case you need to take account of the possibility of multiple gdc/gdmd versions being installed in different places.  So, ideally, a given install of gdmd should be wedded to a given gdc.

You think too hard about things that simply don't matter. You should instead match behaviour of how shells such as bash or csh work when there are more than one executable named 'foo' in /bin, /usr/bin, and /usr/local/bin.

Incase you weren't aware, it is first match wins.


--
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 07/10/2013 12:56 PM, Iain Buclaw wrote:
> You think too hard about things that simply don't matter.

... scratches head furiously and thinks about how to respond to this ...

:-P