Skip to content

Conversation

jkozlowski
Copy link
Member

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).

@w-martin
Copy link
Member

Ok good find with cmdargs, lets implement the scripts with no extensions. i.e. diffr not diffr.sh?

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.
Usage: diffr <original-file> <new-file> diffr <original-file> <new-file> -o <output-file>
Usage: patchr <original-file> <patch-file> patchr <original-file> <patch-file> -o <output-file>

A lot of these changes were present in #8 - complete after merging 7b37fe5? It has been waiting for 4 months...

@jkozlowski
Copy link
Member Author

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:

Ok good find with cmdargs, lets implement the scripts with no extensions. i.e. diffr not diffr.sh?

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.
Usage:
diffr
diffr -o
Usage:
patchr
patchr -o

A lot of these changes were present in #8 - complete after merging 7b37fe5? It has been waiting for 4 months...


Reply to this email directly or view it on GitHub.

@jkozlowski
Copy link
Member Author

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:

Ok good find with cmdargs, lets implement the scripts with no extensions. i.e. diffr not diffr.sh?

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.
Usage:
diffr
diffr -o
Usage:
patchr
patchr -o

A lot of these changes were present in #8 - complete after merging 7b37fe5? It has been waiting for 4 months...


Reply to this email directly or view it on GitHub.

@w-martin
Copy link
Member

Turns out the -o outputFile format is the POSIX standard, from c getopt() function (which means we can also use that in diffr-c). For this reason, I'd like to stick with the original format. Can this be done? What do you think?

@w-martin
Copy link
Member

I also read the POSIX standard supports -ooutputFile as well as -o outputFile, since the options have to be single-letter - so that may also be worth supporting depending on what we decide.

@jkozlowski
Copy link
Member Author

Hey,

When I run this, it gives me the following usage:

diffr version 0.1, (C) diffr 2013

diffr [COMMAND] ... [OPTIONS]
An intelligent diff/patch tool that knows how to copy and move, has an 'r' at
the end of its name and is written in Haskell.

Common flags:
-h --help Display help message
-v --version Print version information

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
the patched file

So the -o and --output-file is supported; just loaded it up into ghci and run this:

:main diff bla bla1 -ooutputFile
Diff {baseFile = "bla", newFile = "bla1", dOutFile = Just "outputFile"}

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:

I also read the POSIX standard supports -ooutputFile as well as -o outputFile, since the options have to be single-letter - so that may also be worth supporting depending on what we decide.


Reply to this email directly or view it on GitHub.

@w-martin
Copy link
Member

Ok that's good. Started merging this in - couple questions:

  • Is Setup.hs needed? We can run cabal configure; cabal build to build, Setup.hs doesn't seem necessary: runhaskell Setup configure; runhaskell Setup build. If it is needed, lets write the instructions in INSTALL.md
  • Convention change in diffr.cabal? Previously followed convention from here: http://www.haskell.org/haskellwiki/How_to_write_a_Haskell_program - don't mind, let's agree on one?

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 -version referring to 0.1. Will create a separate issue for this.

@jkozlowski
Copy link
Member Author

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:

Ok that's good. Started merging this in - couple questions:

Is Setup.hs needed? We can run cabal configure; cabal build to build, Setup.hs doesn't seem necessary: runhaskell Setup configure; runhaskell Setup build. If it is needed, lets write the instructions in INSTALL.md
Convention change in diffr.cabal? Previously followed convention from here: http://www.haskell.org/haskellwiki/How_to_write_a_Haskell_program - don't mind, let's agree on one?
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 -version referring to 0.1. Will create a separate issue for this.


Reply to this email directly or view it on GitHub.

@w-martin w-martin closed this in 51b2118 Jun 29, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants