Heh.

https://www.haskell.org/haskellwiki/Hierarchical_module_names

Hackage complains when you upload.

Ex:

Compare minor jQuery versions to each other, and runs out of memory.

Need to either finish, then port to a faster lang, or incorporate some sort of piece by piece (file storage) method, or something I don't know about.

• Stable and fully tested code bases
• Website and Docs are sufficient
• API is set in stone
• Support for Tree structure comparison (vs single dimensional arrays)? (convenient)

• Put up on various registries. Bower?
• Make sure all works client side, and are wrapped as AMD/CommonJS modules.

Some edge cases, unit/integration tests if needed, etc.

Since I am using keyword arguments.

• Is this really needed?
• Is not comparing the compiled JavaScript the same (or close)?
• Else, generate a CS tokenized list or ast graph
• Set appropriate syntax weights (if applicable)

While it is more succinct to try and guess, it might be optimal to use a switch vs checking if a (potentially long string) exists as a file.

Hard to search for.

https://github.com/tautologistics/node-htmlparser

Once CI server works for all langs...

http://guillaume-nargeot.github.io/haskell/2014/04/01/haskell-code-coverage-coveralls-support/

https://www.haskell.org/haskellwiki/Haskell_program_coverage

It should be -m like in the Haskell implementation (since the package I used does not support different short and long option starting characters).

Lol, a sort of side, but:

You could score against words, sentences. I.e. -l natural

Probably a fun exercise rather than helpful.

Ruby support is currently slower.

Might as well just write it in Ruby for that support. Not that much, and testing and coverage all works, and no overhead between shelljs.

Stuff like HTML/CSS could be done in CS, but even Haskell could be done in itself.

That way, a Gem can be made, etc.

Note: Perhaps the CS library can still be the go to, and bridge to gem, etc, yet recommend those in favour if you are strictly dealing in that language. (or even just keep one-to-one CLIs/libs and map through a sh script?).

This may be a UX issue, and make users think the package did not successfully install, when in fact it does:

~/src/manowar(master)$ sudo npm install -g synt
/usr/local/bin/synt -> /usr/local/lib/node_modules/synt/bin/cli

> [email protected] postinstall /usr/local/lib/node_modules/synt
> npm run compile && (cd ruby && (bundle --without development && bundle config --local without '') || true) && cd ../


> [email protected] compile /usr/local/lib/node_modules/synt
> bin/compile

/Users/brent/.rvm/rubies/ruby-2.1.2/lib/ruby/2.1.0/rubygems/dependency.rb:298:in `to_specs': Could not find 'bundler' (>= 0) among 13 total gem(s) (Gem::LoadError)
    from /Users/brent/.rvm/rubies/ruby-2.1.2/lib/ruby/2.1.0/rubygems/dependency.rb:309:in `to_spec'
    from /Users/brent/.rvm/rubies/ruby-2.1.2/lib/ruby/2.1.0/rubygems/core_ext/kernel_gem.rb:53:in `gem'
    from /Users/brent/.rvm/gems/ruby-2.1.2/bin/bundle:22:in `<main>'
    from /Users/brent/.rvm/gems/ruby-2.1.2/bin/ruby_executable_hooks:15:in `eval'
    from /Users/brent/.rvm/gems/ruby-2.1.2/bin/ruby_executable_hooks:15:in `<main>'
[email protected] /usr/local/lib/node_modules/synt
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected] ([email protected])
├── [email protected] ([email protected])
└── [email protected] ([email protected], [email protected], [email protected])

Workaround: (in README) use: rvmsudo npm install -g synt

It just parses the path and compares that.

• Add system tests for perf.
• Add code coverage.
• Add any other necessary tests.

Pros:

• Speeds up install (no compiling of CoffeeScript).
• Removes CoffeeScript as a runtime dependency.

Cons:

• Compiled files could mistakenly be slightly dated (ex: during rebase and you don't compile to fix a trivial thing)
• Adds duplicate bloat to the repo, and could be confusing.

Compromise?

• Create a deploy script that either compiles and fails to publish if git changes, or compiles, commits JS files alongside package.json update.

This still sucks as JS files won't match CS files until a release..

A lot of setup/compile scripts presume shell/bash/sudo exists.

Might not be the case for Windows (out of the box).

Need to look into this more, maybe switch to Gulp or something.

For example in JS:

function XXX() { could be weighted extra

this could also allow for user input

or is a strict comparison algorithm that is already developed acceptable?

In general?

http://www.serpentine.com/criterion/ (Haskell)

https://gemnasium.com

Vs using coverage based on compiled JS.

WTF. Need to look into this. 0.1.7 works fine ATM.

e0b2b1c

Pretty sure the haskell CLI shell out does nothing, and defaults to the CS compare function.

Going to fix this, if so, in a testing branch that is flushing out all tests.

This is OK to leave, as this has not been published. 0.2.2 is still good.

Example: Esprima json notation.

Once multiple languages.

We need a lot more integration/unit focused tests, and also system level tests for the CLI portion of the app (including shelling out to rb/hs ports).

Currently the coverage is a false positive, since some modules are not included.

Having issues. Need to look into more.

~/src/synt/haskell(haskell)$ cabal install
Resolving dependencies...
Configuring haskell-src-exts-1.16.0.1...
cabal: The program 'happy' version >=1.17 is required but the version of
/Users/brent/src/synt/haskell/.cabal-sandbox/bin/happy could not be
determined.
Failed to install haskell-src-exts-1.16.0.1
cabal: Error: some packages failed to install:
haskell-src-exts-1.16.0.1 failed during the configure step. The exception was:
ExitFailure 1
synt-0.1.0 depends on haskell-src-exts-1.16.0.1 which failed to install.

Which, apparently you can get around with installing it globally:

Linking dist/build/happy/happy ...
ld: warning: ignoring file /Users/brent/.cabal/lib/transformers-0.4.1.0/ghc-7.8.3/libHStransformers-0.4.1.0.a, file was built for archive which is not the architecture being linked (x86_64): /Users/brent/.cabal/lib/transformers-0.4.1.0/ghc-7.8.3/libHStransformers-0.4.1.0.a
Installing executable(s) in /Users/brent/.cabal/bin
BFD: unable to read unknown load command 0x2a
BFD: unable to read unknown load command 0x28
BFD: unable to read unknown load command 0x29
BFD: unable to read unknown load command 0x2b
Installed happy-1.19.4

Then:

~/src/synt(haskell)$ happy
bash: /Users/brent/.cabal/bin/happy: Bad CPU type in executable

I implemented both, but, they are essentially the same.

Possible research points:

http://en.wikipedia.org/wiki/S%C3%B8rensen%E2%80%93Dice_coefficient
http://en.wikipedia.org/wiki/N-gram (edit distance)

https://github.com/reworkcss/css

It is not even really doing anything much (max point gen needs to be legit), because the bulk of the original code went into src/similar.coffee.