Example:
(defmain [&rest args]
(print "now we're having a fun time!")
(print args))
Which outputs:
$ hy test.hy
now we're having a fun time!
(['test.hy'],)
Includes documentation and tests.
The hy2py tool has been very useful for me, but most of the time, it's
only a part of its output that one is interested in. The whole output,
with source code, AST and python code together is one big monstrosity.
So instead of printing all that, lets have a few handy command-line
options to control which part gets printed.
By default, only the generated python source is, as that's what the name
of the tool implies.
Also, don't run it. That's what hy is for.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
There's no reason why one would need to choose between --spy and -i, so
pass down options.spy to run_icommand, and then to HyREPL, so we can
have both.
Signed-off-by: Gergely Nagy <algernon@balabit.hu>
This version is much simpler.
At the point that the exception is raised, we don't have access to
the actual source, just the current expression. but as the
exception percolates up, we can intercept it, add the source and
the re-raise it.
Then at the final point, in the cmdline handler, we can choose to
let the entire traceback print, or just the simpler, direct error
message.
And even with the full traceback, the last bit is nicely formatted
just like the shorter, simpler message.
The error message is colored if clint is installed, but to avoid
yet another dependency, you get monochrome without clint.
I'm sure there is a better way to do the markup, the current method
is kludgy but works.
I wish there was more shared code between HyTypeError and LexException
but they are kind of different in some fundamental ways.
This doesn't work (yet) with runtime errors generated from Python,
like NameError, but I have a method that can catch NameError and turn it
into a more pleasing output.
Finally, there is no obvious way to raise HyTypeError from pure Hy code,
so methods in core/language.hy throw ugly TypeError/ValueError.
`hy --spy` fails on hy 0.9.11.
$ hy --spy
hy 0.9.11
=> (type "hy")
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/hy/cmdline.py", line 68, in print_python_code
import astor.codegen
ImportError: No module named astor.codegen
This adds real command line handling to 'hyc' for issue #256
This fix catches missing/unreadable files and prints a nice
error message instead of a nasty stack trace when trying to
compile a non-existent file.
Also add this non-existent file check to hy to prevent the
current stack trace from something like "hy foobarbaz" when
"foobarbaz" doesn't exist.
also changes the failure return value to 2 to match Python.
Summary: This update does away with the scripts in bin and changes
setup.py to use entry_points in cmdline.py for the scripts 'hy' and
'hyc'.
This fixes installing and running on Windows.
The tests are updated to run the 'hy' script produced by setup.py
and not from bin/hy. This is more correct and makes the tox tests
run on both Window and *nix.
For running hy or nosetests directly in the source tree, you do have
to run 'python setup.py develop' first. But since tox runs and builds
dists, all tox tests pass on all platforms.
Also, since there is no built-in readline on Windows, the setup.py
only on Windows requires 'pyreadline' as a replacement.
Switched from optparse to argparse in cmdline.py
Instead of trying to manually separate args meant for
hy from args meant for a hy script, this switches from
optparse to argparse for the CLI.
argparse automatically peels out args meant for hy and leaves
the rest, including the user hy script in options.args.
This fixes the issue @paultag found running "hy foo" where
foo is not a real file. Also added a test that makes sure
trying to run a non-existent script exits instead of dropping
the user into the REPL.
Added argparse as setup.py resource (and removed from tox.ini) as well as removed uses of deprecated setf
