RTS option parsing

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

RTS option parsing

David Laing
Hi,

I'm brand new to GHC development, and have been looking at:
  http://ghc.haskell.org/trac/ghc/ticket/4243

I was initially thinking of something like getopt_long_only, as per:
  http://linux.die.net/man/3/getopt_long
however it looks like the portability of that function isn't the greatest,
and from looking at rts/RtsFlags.c:procRtsOpts(...) it might not be the
best solution.

Unless I've missed something, it seems that the processing of each flag is
independent of the others, at least once we get into procRtsOpts(...), and
the processing of a flag either mutates the RtsFlags variable or results in
an error.

If that's not likely / wanted to change I think there are some nifty ways
to abstract that, as long as function pointers aren't frowned on in the RTS
code :)

Since it looks like it would be a sizeable patch, should I put together a
proof-of-concept and ask for feedback sooner rather than later?  I'd hate
to emerge from my codecave with a fully-formed but unacceptable solution.

While I'm at it - does anyone have any thoughts or wishlists for a cleaned
up option parser?

Cheers,

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130809/02fc8dda/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

RTS option parsing

Edward Z. Yang
Hi David,

> I was initially thinking of something like getopt_long_only, as per:
>   http://linux.die.net/man/3/getopt_long
> however it looks like the portability of that function isn't the greatest,
> and from looking at rts/RtsFlags.c:procRtsOpts(...) it might not be the
> best solution.

That's not necessarily true; we target MingW for Windows compilation,
so if you can make sure it works there getopt_long may be viable.  On
the other hand, maintaining backwards compatibility may be tricky.
Some investigation is probably necessary.

Edward



Reply | Threaded
Open this post in threaded view
|

RTS option parsing

David Laing
Hi Edward,

I was more worried about the effect that it would have on the 2nd tier
platforms, some of which don't have getopt_long_only - which I think is
desirable due to the two-character short options that need to be dealt
with.

My feeling is that writing and maintaining a correct getopt_long_only as a
fallback for those platforms - which I assume someone would have to do -
might take more effort than putting togther something less general / more
tailored to how the RTS parses the options.

I've been idly thinking about how to approach this problem enough that I
think I'm going to put some proof-of-concept code together just to test the
ideas / so my metaphorical teeth stop itching.

At the core of the idea is the options would be stored in an array of
structs of the form
  {option-string, has_argument, is_safe, function_pointer_to_handler}
where the function pointer is probably of the form
  int(RtsFlags*, some-error-info-struct*)
or possibly
  int(RtsFlags*, some-cross-option-information-sharing-struct*,
some-error-info-struct*)

I've been in the C++ world for a while now, so I'll need to double check
the standard / idiomatic way to express that in C.

If options don't effect anything but the flags or the error state, it seems
to me that the overall complexity of the option parsing code would drop.  I
don't know what the priority of option parsing performance is, but there
are quite a few optimisations available that wouldn't complicate the code
all that much.

If anyone has any thoughts on this, I'd love to hear them before I get too
far along.

Cheers,

Dave


On Sat, Aug 10, 2013 at 10:09 AM, Edward Z. Yang <ezyang at mit.edu> wrote:

> Hi David,
>
> > I was initially thinking of something like getopt_long_only, as per:
> >   http://linux.die.net/man/3/getopt_long
> > however it looks like the portability of that function isn't the
> greatest,
> > and from looking at rts/RtsFlags.c:procRtsOpts(...) it might not be the
> > best solution.
>
> That's not necessarily true; we target MingW for Windows compilation,
> so if you can make sure it works there getopt_long may be viable.  On
> the other hand, maintaining backwards compatibility may be tricky.
> Some investigation is probably necessary.
>
> Edward
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130810/5765fc2b/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

RTS option parsing

Simon Marlow-7
It's probably best not to rely on external libraries for this.

I'd be happy with representing the options as data rather than code,
along with a generic parser.  Performance is very likely a non-issue,
but you could always do something really simple like bucketing the
options based on the first character.

Cheers,
        Simon

On 10/08/13 02:54, David Laing wrote:

> Hi Edward,
>
> I was more worried about the effect that it would have on the 2nd tier
> platforms, some of which don't have getopt_long_only - which I think is
> desirable due to the two-character short options that need to be dealt
> with.
>
> My feeling is that writing and maintaining a correct getopt_long_only as
> a fallback for those platforms - which I assume someone would have to do
> - might take more effort than putting togther something less general /
> more tailored to how the RTS parses the options.
>
> I've been idly thinking about how to approach this problem enough that I
> think I'm going to put some proof-of-concept code together just to test
> the ideas / so my metaphorical teeth stop itching.
>
> At the core of the idea is the options would be stored in an array of
> structs of the form
>    {option-string, has_argument, is_safe, function_pointer_to_handler}
> where the function pointer is probably of the form
>    int(RtsFlags*, some-error-info-struct*)
> or possibly
>    int(RtsFlags*, some-cross-option-information-sharing-struct*,
> some-error-info-struct*)
>
> I've been in the C++ world for a while now, so I'll need to double check
> the standard / idiomatic way to express that in C.
>
> If options don't effect anything but the flags or the error state, it
> seems to me that the overall complexity of the option parsing code would
> drop.  I don't know what the priority of option parsing performance is,
> but there are quite a few optimisations available that wouldn't
> complicate the code all that much.
>
> If anyone has any thoughts on this, I'd love to hear them before I get
> too far along.
>
> Cheers,
>
> Dave
>
>
> On Sat, Aug 10, 2013 at 10:09 AM, Edward Z. Yang <ezyang at mit.edu
> <mailto:ezyang at mit.edu>> wrote:
>
>     Hi David,
>
>      > I was initially thinking of something like getopt_long_only, as per:
>      > http://linux.die.net/man/3/getopt_long
>      > however it looks like the portability of that function isn't the
>     greatest,
>      > and from looking at rts/RtsFlags.c:procRtsOpts(...) it might not
>     be the
>      > best solution.
>
>     That's not necessarily true; we target MingW for Windows compilation,
>     so if you can make sure it works there getopt_long may be viable.  On
>     the other hand, maintaining backwards compatibility may be tricky.
>     Some investigation is probably necessary.
>
>     Edward
>
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>