[sword-devel] osis2mod change

Fri Sep 28 08:00:28 MST 2007

Troy,

very good decision.

mg

Am Freitag, 28. September 2007 schrieb Troy A. Griffitts:
> Sorry this is escalating and an emotional issue.  I'm not sure why it is
> such.
>
> Thanks for all the buzz words.  20 lines added and commited.
>
> DM Smith <dmsmith555 at yahoo.com> wrote:
> >On Sep 27, 2007, at 1:49 PM, Troy A. Griffitts wrote:
> >> DM,
> >>
> >> I'm sorry.  I never intended to 'stifle community contribution'.  I
> >> was
> >> merely trying to make a technical decision.  If you describe to me a
> >> benefit of importing 475 lines which we did not write or have any idea
> >> if it is crossplatform-- to check 4 command line options to a tool
> >> that
> >> is only total 840 lines, then I might consider.
> >
> >You asked for one. Here is a bunch.
> >
> >Pros:
> >Industry standard command line code.
> >Reusable code.
> >Becomes a pattern for new utilities, perhaps for existing utilities.
> >Stable/proven code.
> >POSIX standard.
> >Usage is well-known,  understood and used by many programmers.
> >Easy to use.
> >Easy to maintain.
> >Easy to extend.
> >Favorable license.
> >
> >Cons:
> >Would need to be proven on various platforms.
> >Not invented here.
> >
> >>   But it seems to me we
> >> could simple add a 20 line for loop to do the same.  And I'm not
> >> sure we
> >> wouldn't still need to add the 20 line for loop if we imported this
> >> code.  Checking commandline arguments in C is not that hard.  I don't
> >> need a library to do it for me-- especially when our input
> >> arguments are
> >> neither lengthy, nor complex.
> >
> >Yes, checking command line options is not all that hard in C. But why
> >reinvent the wheel?
> >
> >create a loop that
> >checks first characters of argument for - or --,
> >look for match against expected set of values
> >when match found determine whether it requires an argument,
> >if so get the argument and determine how to convert it to an
> >appropriate internal representation
> >based upon what was successfully passed determine whether
> >disambiguation needs to occur,
> >if so, disambiguate, saving value as appropriate.
> >on error, report error and post usage statement.
> >
> >Granted some of the above needs to be done regardless of which
> >implementation is used.
> >
> >> Please understand I'm only trying to make a technical decision.
> >
> >Another reason, I have further plans to enhance osis2mod to also take
> >a valid OSIS commentary. I'm anticipating that will require more flag
> >changes. Also, with Chris' change to do normalization, it may be
> >necessary to pass in whether the encoding is UTF-8 or Latin-1.
> >
> >>         -Troy.
> >>
> >> DM Smith wrote:
> >>> Troy,
> >>>
> >>> I'm not sure what the dependency would be. The code is self-contained
> >>> and 475 lines. The getsubopt.c is not needed unless getopt.h is
> >>> used as
> >>> is. As Chris notes, it can be isolated in the utilities directory not
> >>> injecting dependency anywhere. The only other possible dependency is
> >>> that of the license. If that is a problem, I will keep looking for a
> >>> version with one that is not.
> >>>
> >>> Please don't stifle community contribution.
> >>>
> >>> DM
> >>>
> >>> Troy A. Griffitts wrote:
> >>>> I think I would like to conclude this thread with deciding that
> >>>> we are
> >>>> not willing to introduce a dependency to iterate simple program
> >>>> args.
> >>>> Thank you all for the suggestion.
> >>>>
> >>>>         -Troy.
> >>>>
> >>>> DM Smith wrote:
> >>>>> How about this implementation, as it is pretty short:
> >>>>>
> >>>>> Header:
> >>>>> http://www.mirbsd.org/cvs.cgi/src/include/getopt.h?
> >>>>> rev=1.1.1.1;content-type=text%2Fplain
> >>>>>
> >>>>> Code:
> >>>>> http://www.mirbsd.org/cvs.cgi/src/lib/libc/stdlib/getopt_long.c?
> >>>>> rev=1.1.1.3;content-type=text%2Fplain
> >>>>> http://www.mirbsd.org/cvs.cgi/src/lib/libc/stdlib/getsubopt.c?
> >>>>> rev=1.3;content-type=text%2Fplain
> >>>>>
> >>>>> It is a BSD license that is compatible with GPL (some BSD are
> >>>>> not) and
> >>>>> it is self contained in one file.
> >>>>>
> >>>>> -- DM
> >>>>>
> >>>>> On Sep 26, 2007, at 5:15 PM, Chris Little wrote:
> >>>>>> But Windows lacks it, I believe.
> >>>>>> I suppose we could absorb some BSD code, assuming it were
> >>>>>> short, to
> >>>>>> achieve the same end, but we can't just #include <unistd.h>.
> >>>>>>
> >>>>>> --Chris
> >>>>>>
> >>>>>> Sergio QUEIROZ wrote:
> >>>>>>> getopt without GNU extensions is a part of the Unix Base
> >>>>>>> Specifications
> >>>>>>> and should be available mostly everywhere.
> >>>>>>>
> >>>>>>> http://www.opengroup.org/onlinepubs/009695399/functions/
> >>>>>>> getopt.html
> >>>>>>>
> >>>>>>> Yours,
> >>>>>>>
> >>>>>>> Sergio
> >>>>>>>
> >>>>>>> Le mercredi 26 septembre 2007 à 11:35 -0700, Chris Little a
> >>>>>>>
> >>>>>>> écrit :
> >>>>>>>> Eeli Kaikkonen wrote:
> >>>>>>>>> On Tue, 25 Sep 2007, Troy A. Griffitts wrote:
> >>>>>>>>>> As DM has said previously, it
> >>>>>>>>>> would be really nice to have normal -options which are not
> >>>>>>>>>> order
> >>>>>>>>>> dependent.
> >>>>>>>>>
> >>>>>>>>> Using GNU getopt?
> >>>>>>>>> http://www.gnu.org/software/libc/manual/html_node/Getopt.html
> >>>>>>>>
> >>>>>>>> Using anything from GNU would be a bad idea. Enduring "the chore
> >>>>>>>> involved in parsing typical unix command line options" makes
> >>>>>>>> our code
> >>>>>>>> more portable and avoids the need to license additional
> >>>>>>>> libraries.
> >>>>>>>>
> >>>>>>>> Writing a simple command line option parser isn't especially
> >>>>>>>> difficult
> >>>>>>>> or burdensome, anyway.
> >>>>>>>>
> >>>>>>>> --Chris
> >>>
> >>> _______________________________________________
> >>> sword-devel mailing list: sword-devel at crosswire.org
> >>> http://www.crosswire.org/mailman/listinfo/sword-devel
> >>> Instructions to unsubscribe/change your settings at above page
> >>
> >> _______________________________________________
> >> sword-devel mailing list: sword-devel at crosswire.org
> >> http://www.crosswire.org/mailman/listinfo/sword-devel
> >> Instructions to unsubscribe/change your settings at above page
> >
> >_______________________________________________
> >sword-devel mailing list: sword-devel at crosswire.org
> >http://www.crosswire.org/mailman/listinfo/sword-devel
> >Instructions to unsubscribe/change your settings at above page
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page