I am new to Clojure and want to debug a Clojure file abc.clj that will take user arguments. To run the file, i will do
lein run [arg1 arg2 ..]
I have tried emacs-cider and lighttable, but haven't found a way to input user argument from the beginning.
Maybe you can try the Debux library, and use your REPL to observe results. Seems to me that Clojure is really about the REPL and interactive development.
If I understand what you're trying to do, you should be able to sprinkle debug macros (dbg) throughout your code, then run your code with whatever changes to your args. The various results from the dbg macros will show in your REPL. I'm not sure if you can do this straight from lein, however.
From the README page:
Basic usage
This is a simple example. The macro dbg prints an original form and
pretty-prints the evaluated value on the REPL window. Then it returns
the value without interfering with the code execution.
If you wrap the code with dbg like this,
(* 2 (dbg (+ 10 20))) ; => 60
the following will be printed in the REPL window.
REPL output:
dbg: (+ 10 20) => 30
Related
I'm writing a language interpreter in Haskell, and for the most part it works (hooray!). But some of the tests fail in an odd way that depends on whether stdout is sent to the terminal or a pipe...
I'm using tasty-golden to test the REPL. There are text files with pasted REPL sessions like this:
Welcome to the ShortCut interpreter!
Type :help for a list of the available commands.
shortcut >> v1 = "one"
shortcut >> v2 = "two"
shortcut >> v3 = [v1, v2]
shortcut >> :show
v1 = "one"
v2 = "two"
v3 = [v1, v2]
shortcut >> :rdepends v1
v3 = [v1, v2]
shortcut >> :quit
Bye for now!
I have a function that reads those files and splits them into user input (anything after shortcut >>) and what the program should print to stdout. It passes the input lines to the REPL, captures stdout using the silently package, intercalates them, and checks that the combined output is the same as that file.
Everything works, but only if I pipe the overall program output through less! When printing directly to the terminal, certain lines slip through and are actually printed, then the tests fail because they aren't part of the captured output.
I think it might be a bug in the interaction between Tasty and Silently, which both do fancy things with terminal output, but have no idea how to debug it or write a reproducible example.
Here's the complete output run in three different ways:
Copied directly from the terminal
Piped through less and copied from the terminal
Piped through tee and copied from the resulting file
As you can see:
Each FAIL is preceded by printing part of the REPL output to the terminal instead of capturing it
less somehow gets around that and the tests pass
tee misses the printed bits (they end up in terminal but not the file)
Any ideas about what could be going on? I can post any parts of the code you think might be relevant, but didn't want to muddy the question with hundreds and hundreds of mostly-unrelated lines.
Update: tried replacing Silently's hCapture_ with this function from another question:
catchOutput :: IO () -> IO String
catchOutput action = do
tmpd <- getTemporaryDirectory
(tmpf, tmph) <- openTempFile tmpd "haskell_stdout"
stdout_dup <- hDuplicate stdout
hDuplicateTo tmph stdout
hClose tmph
action
hDuplicateTo stdout_dup stdout
str <- readFile tmpf
removeFile tmpf
return str
Unfortunately it does the same thing.
Update 2:
Well, figured it out. Sorry for everyone who tried to puzzle through it, as I don't think I gave enough information! The bug was in my REPL monad, which was defined like this:
type ReplM a = StateT CutState (MaybeT (InputT IO)) a
runReplM :: ReplM a -> CutState -> IO (Maybe CutState)
runReplM r s = runInputT defaultSettings $ runMaybeT $ execStateT r s
prompt :: String -> ReplM (Maybe String)
prompt = lift . lift . getInputLine
print :: String -> ReplM ()
print = lift . lift . outputStrLn
I noticed that all the erroneous prints came from functions that use print, whereas a couple cases where I used liftIO . putStrLn instead worked as expected. So I just redefined print as that:
print :: String -> ReplM ()
print = liftIO . putStrLn
I still don't really get why the other version didn't work though, so I'll give the answer to whoever can explain it. outputStrLn is defined in Haskeline.hs.
For example, consider the following debugging session:
(gdb) break foo
Breakpoint 1 at 0x4004f1: file tst.c, line 5.
(gdb) run
Starting program: /tmp/tst
Breakpoint 1, foo () at tst.c:5
5 return ary[i++];
(gdb) finish
Run till exit from #0 foo () at tst.c:5
Value returned is $1 = 1
(gdb) cont
Continuing.
Breakpoint 1, foo () at tst.c:5
5 return ary[i++];
(gdb) finish
Run till exit from #0 foo () at tst.c:5
Value returned is $2 = 3
After executing a finish command, I get the return value assigned to a
convenience variable (e.g. $1 or $2). Unfortunately, every time the command
is executed, the value is assigned to a different variable. That's the problem,
I cannot write a script which examines the returned value cause I don't know
what variable the value was assigned to.
Why do I need that? I want to set a breakpoint at a certain function but to
stop program execution only if the function has returned a specific value. Something
like this:
break foo
commands
finish
if ($return_value != 42)
continue;
end
end
So the question is: Is there any way to examine in a script the value returned
from a function?
This isn't easy to do from the gdb CLI. Maybe it is impossible purely using the traditional CLI -- because you can have inferior control commands like finish in a breakpoint's commands. This is a longstanding gdb issue.
However, like most automation problems in gdb, it can be solved using the Python API. Now, unfortunately, this approach requires a bit of work on your part.
Essentially what you want to do is subclass the Python FinishBreakpoint class to have it do what you want. In particular you want to write a new command that will set a regular breakpoint in some function; then when this breakpoint is hit, it will instantiate your new FinishBreakpoint class. Your class will have a stop method that will use the return_value of the finish breakpoint as you like.
The first part of your question is straightforward: just use $ to access the most recent value in gdb's value history.
From GDB: Value History
The values printed are given history numbers by which you can refer to them. These are successive integers starting with one. print shows you the history number assigned to a value by printing ‘$num = ’ before the value; here num is the history number.
To refer to any previous value, use ‘$’ followed by the value's history number. The way print labels its output is designed to remind you of this. Just $ refers to the most recent value in the history, and $$ refers to the value before that. $$n refers to the nth value from the end.
But, executing commands following a finish command in a breakpoint command list may not currently be possible; see Tom Tromey's answer for a workaround.
I'm calling a Lisp function (and a few other thing) from a shell script. For brevity, below is relevant part of the script :
./gcl -load /tmp/calendrica-3.0.cl -batch -eval '(format T "~a"
(CC3::sunset (CC3::fixed-from-gregorian (CC3::gregorian-date 1996
CC3::february 25)) CC3::jerusalem))'
728714.7349874675
The above code works fine but I had to append the package name CC3 for every symbol that is used; which makes the code unwieldy and hard to type.
I tried to simplify it like so, using use-package :
./gcl -load /tmp/calendrica-3.0.cl -batch -eval '(format T "~a"
(use-package "CC3") (sunset (fixed-from-gregorian (gregorian-date 1996 february 25)) jerusalem))'
Much easier to read and type, but unfortunately it doesn't work. I've tried all sorts of ways to include the use-package directive but so far no success.
Is it even possible to include a use-package directive while launching a Lisp program via the GNU Common Lisp's (gcl) load directive?
Update:
The solution is to use multiple evals as suggested by the accepted answer.
./gcl -load /tmp/calendrica-3.0.cl -batch -eval
'(use-package "CC3")' -eval '(format T "~a" (sunset
(fixed-from-gregorian (gregorian-date 1996 february 25)) jerusalem))'
Maybe you could use multiple eval, here is what I do with sbcl.
#!/bin/sh
sbcl --noinform \
--eval '(load "boot.lisp")' \
--eval '(in-package #:my-pkg)' \
--eval "(do-something-useful)" # do-something-useful is in my-pkg
It's maybe possible to do that but it will be ugly.
If you give it a form form evaluation, it will read the form first. Thus it then is too late during evaluation to change the reader (telling new packages, ...). Thus it needs to be done before.
CL-USER 1 > (eval (read-from-string "(foo::bar)"))
Error: Reader cannot find package FOO.
Better:
CL-USER 5 > (eval '(progn (defpackage foo (:use "CL"))
(read-from-string "(foo::bar)")))
(FOO::BAR)
So, if you want to pass a single form to eval, you would write which first creates the package and then reads/evals from a string, which is encoded in the form. Tricky.
Alternatives:
maybe the Lisp allows at startup multiple -eval forms? Do whatever you need to initialize Lisp to know about the packages in the first -eval form. Then have the code to execute in the second form.
write a file and put the necessary forms there. Load it. Since a file can contain multiple forms, you can have DEFPACKAGE, IN-PACKAGE or similar on top and then have the rest of the code in the file depending on it.
I've got to learn how-to-design-program for a while.But once I started to use my Emacs to learn htdp, I met some problem.
THE PROBLEM IS THAT:
I typed #lang racket , but it just show:
> stdin::7: read: #lang not enabled in the current context
context...:
/usr/share/racket/collects/racket/private/misc.rkt:87:7
> racket: undefined;
cannot reference undefined identifier
context...:
/usr/share/racket/collects/racket/private/misc.rkt:87:7
And I use 'require' to load path.
stdin::30: cannot open module file
module path: #<path:/Desktop/htdp/convert.rkt>
path: /Desktop/htdp/convert.rkt
system error: No such file or directory; errno=2
context...:
standard-module-name-resolver
/usr/share/racket/collects/racket/private/misc.rkt:87:7
Also it can not work.
Can you help me to solve it?
P.S my system is Fedora20.
When you're running a racket script from the console, you shouldn't need to define the language on the first line. This flag
racket -I <language>
can be used to specify a language when running from the command line. #lang racket should be the default, so just remove the line and run your script from the command line using the racket command.
from the link https://docs.racket-lang.org/guide/Module_Syntax.html#%28part._hash-lang%29
it says:
The #lang at the start of a module file begins a shorthand for a module form, much like ' is a shorthand for a quote form. Unlike ', the #lang shorthand does not work well in a REPL, in part because it must be terminated by an end-of-file, but also because the longhand expansion of #lang depends on the name of the enclosing file.
I have the following Common Lisp code:
(defun micro-read-eval-print ()
(format t "Micro > ")
(let ((form (read-line)))))
When I run it, I get the following:
CL-USER> (micro-read-eval-print)
(m-quote a)
Micro > NIL
Note that I typed in "(m-quote a)", while the Lisp interpreter output "Micro > NIL".
Now, I would have expected these events to happen in the reverse order. I would have expected "Micro > " to have been printed first since the format statement comes first. Why isn't it printed first? And what do I have to do to make sure it is printed first?
Try adding
(defun micro-read-eval-print ()
(format t "Micro > ")
(finish-output)
(let ((form (read-line)))))
I believe you are encountering the buffering of standard io (stdio) which, in C, is commonly bypassed via fflush() in that language.
finish-output appears to be the Common Lisp equivalent of C standard library's fflush.