On Wed, Jul 10, 2013 at 06:23:54PM +0200, Joseph Rushton Wakeling wrote:
> On 07/10/2013 05:25 PM, Johannes Pfau wrote:
> > Getting the real application path is not simple and not portable, but if you really want to do that:
> 
> I found the same links and was wondering about that, but to be honest -- I think Iain is right and this kind of stuff is overkill.
> 
> Let gdmd just be a script that invokes the default system gdc (i.e. the first in the path).  To do that, we just need to get the PATH variable, and we don't even need to care about where gdmd itself is located.

Yeah that what I've decided to go with. No point sweating over such peripheral details when I should be more worried about the core functionality of making gdmd actually work. :)


T

-- 
It always amuses me that Windows has a Safe Mode during bootup. Does that mean that Windows is normally unsafe?

On Fri, Jul 19, 2013 at 09:26:17PM +0100, Iain Buclaw wrote:
> On 19 July 2013 20:05, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> > On Fri, Jul 19, 2013 at 10:53:27AM +0200, eles wrote:
[...]
> >> What about you getting the keys of the main gdmd repo and move there the D-port of gdmd?
> >>
> >> You already did tremendous amount of work, to the point that the
> >> old version of gdmd (the Perl script) could be already dropped (or
> >> kept for historical reasons).
> >
> > Not really, there are still some dmd options that dmd-script supports, but gdmd.d doesn't yet.
[...]
> So are you two guys axeoth and quickfur?
[...]

I'm quickfur. I'm guessing eles is axeoth.


T

-- 
Marketing: the art of convincing people to pay for what they didn't need before which you can't deliver after.

On 19 July 2013 21:39, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> On Fri, Jul 19, 2013 at 09:26:17PM +0100, Iain Buclaw wrote:
>> On 19 July 2013 20:05, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
>> > On Fri, Jul 19, 2013 at 10:53:27AM +0200, eles wrote:
> [...]
>> >> What about you getting the keys of the main gdmd repo and move there the D-port of gdmd?
>> >>
>> >> You already did tremendous amount of work, to the point that the
>> >> old version of gdmd (the Perl script) could be already dropped (or
>> >> kept for historical reasons).
>> >
>> > Not really, there are still some dmd options that dmd-script supports, but gdmd.d doesn't yet.
> [...]
>> So are you two guys axeoth and quickfur?
> [...]
>
> I'm quickfur. I'm guessing eles is axeoth.
>

Added you to Team GDMD.  =)


--
Iain Buclaw

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

On Mon, Jul 22, 2013 at 10:38:36AM +0200, eles wrote:
> On Friday, 19 July 2013 at 19:06:41 UTC, H. S. Teoh wrote:
[...]
> >Not really, there are still some dmd options that dmd-script supports, but gdmd.d doesn't yet.
> 
> Do you mind making a list of those (here) and suggest how to
> distribute those between us?
> 
> This will avoid duplicate work and will allow us keeping some focus.

Actually, I haven't had time to do much with gdmd for the past week or so, and probably won't have that much time this week either. If you want to work on it this week, please go ahead.

As for what is/isn't implemented yet: if you look at parseArgs(), there's a bunch of "TBD" comments that indicate which options are currently recognized but not implemented.

I basically went through the corresponding code in dmd-script in the order it appears in the latter, and currently I've gotten to -op. So pretty much everything that follows -op in dmd-script isn't recognized yet, and needs to be implemented (in addition to the above options that are currently recognized but not yet implemented).

Besides the actual options themselves, I'm not very happy with the current implementation of parseArgs(). The most egregious fault with it is that it's using a bunch of regexes that matches *both* options *and* filenames. I'm pretty sure there are some obscure corner cases where this is going to cause bugs. This function really should first check the first character of each command-line argument, and if it begins with "-", call the code that parses options, otherwise, call the code that parses filenames.

Besides that, I think the majority of the options can be put into a static AA for fast lookup of options without arguments. Unfortunately, due to DMD's idiosyncratic command-line syntax, we can't do this for options with arguments, so we'll still have to use regexes for that. Alternatively, another approach is to parse it char-by-char until we reach the argument part of the option, then use slicing to pick up the latter. This would be more tedious, though, and I'm not sure it's worth the effort (this *is* just parsing command-line options, not a performance critical inner loop). Probably the AA lookup + regexes approach is Good Enough(tm).


> BTW: I think it is better to start a new thread, maybe: "gdmd port"

Done.


T

-- 
Heads I win, tails you lose.

On Wed, Jul 31, 2013 at 01:40:31PM +0200, Joseph Rushton Wakeling wrote:
> On 07/19/2013 09:05 PM, H. S. Teoh wrote:
> > Not really, there are still some dmd options that dmd-script supports, but gdmd.d doesn't yet.
> 
> On that note, is there a reason not to use std.getopt for the option parsing?  Perhaps that it doesn't support single-hyphen option flags of more than one character, such as dmd uses?

The main reason is that dmd command-line syntax is somewhat incompatible with std.getopt. (And also that std.getopt has some quirks w.r.t. to "usual" Posix-style command-line arguments, but then again, dmd itself is rather quirky so that's moot.) The biggest problem is multi-character flags that take arguments without an intervening space, like -ofprogram.exe, which std.getopt simply can't handle.


T

-- 
English has the lovely word "defenestrate", meaning "to execute by throwing someone out a window", or more recently "to remove Windows from a computer and replace it with something useful". :-) -- John Cowan