-
Notifications
You must be signed in to change notification settings - Fork 0
Use cmdargs for command line parsing. #9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Ok good find with cmdargs, lets implement the scripts with no extensions. i.e. The command line interface is a little different - if we want to change the diffr interface, maybe this ought to be done with java as well. A lot of these changes were present in #8 - complete after merging 7b37fe5? It has been waiting for 4 months... |
Oh snap, I don't know why I thought those were already merged in... I think mine are potentially slightly less verbose (the code to handle the args is generated I believe through those weird annotations '&=') and also safe; I started looking at yours (and I'll do the review now for learning sake) you are doing a few potentially dangerous things, using head for lists. Jakub On Jun 23, 2013, at 2:15 PM, William Martin notifications@github.com wrote:
|
Well, the usage string is longer and more descriptive now; so it's possible to do it either way, either change haskell slightly or java; it was very late in the night, I wasn't too bothered with looking too much at the java source:p Are you ok with merging this for now, so we can start implementing the juicy bits and add the scripts later? or shall I try to do it now? Jakub On Jun 23, 2013, at 2:15 PM, William Martin notifications@github.com wrote:
|
Turns out the |
I also read the POSIX standard supports |
Hey, When I run this, it gives me the following usage: diffr version 0.1, (C) diffr 2013 diffr [COMMAND] ... [OPTIONS] Common flags: diffr diff [OPTIONS] BASEFILE NEWFILE -o -d --output-file=FILE --doutfile path to the output file diffr patch [OPTIONS] ORIGINALFILE PATCHFILE -o -p --output-file=FILE --poutfile Path to the output file where to write So the -o and --output-file is supported; just loaded it up into ghci and run this: :main diff bla bla1 -ooutputFile so the last option is supported as well :) I don't particularly like the -d and -p flags, not sure where it's getting that from... I'll see what I can force on it. Jakub On Jun 26, 2013, at 11:43 PM, William Martin notifications@github.com wrote:
|
Ok that's good. Started merging this in - couple questions:
I know we discussed this before - agree with the 'since 0.1' version, but I definitely think we need to change the first tag to 0.0 and release this later as 0.1. Otherwise a user downloads tag 0.2 and gets all the sources and |
I think I've just read in Real World Haskell that it's useful, once you start doing something fancy with the build... So I don't mind either way: http://book.realworldhaskell.org/read/writing-a-library-working-with-json-data.html <- towards the end. You mean lowercase for properties in the cabal file? I think that might've been what eclipse fp did... I didn't notice it until now. I'll have some time tomorrow to work on diffr, Agata's at work. Speak to you tomorrow. Jakub On Jun 29, 2013, at 6:04 PM, William Martin notifications@github.com wrote:
|
Changed the command line arguments parsing to use cmdargs -> http://hackage.haskell.org/package/cmdargs; tutorial -> http://hackage.haskell.org/packages/archive/cmdargs/0.10.3/doc/html/System-Console-CmdArgs-Implicit.html;
This is to try something new, and also get a load of stuff for free -> using this package generates nice usage strings, with versions, and documentation for options, examples etc.
The way this is implemented right now, we'd have the following invocations:
diffr diff OLDFILE NEWFILE -o=outputFile.diff
diffr patch OLDFILE PATCHFILE -o=outputFile
which means we could create some small wrapper scripts if we wanted to have the same interface as java version (diffr and patchr commands).
It just means that potentially the code is slightly less repetitive (no two mains, no two command args parsing methods etc.
Give it a go.
Next is enabling testing and writing the actual functionality; I am using Eclipse FP, seems to be pretty OK with haskell, not yet as nice as IntelliJ for Java, but it is pretty usable and it can manage the cabal file automatically (wizard).