Main class in clojure, leiningan (Conway's game of life) - syntax
Hi guys! I'm running Conway's game of life - but I think I had to modify the original version here: https://github.com/sebastianbenz/clojure-game-of-life to reference field.clj (rather than run.clj) in the project.clj file. After doing so, I can start the game by running
repl> (run-game)
However, it crashes on this method, which has no comments regarding input arguments.
Thus, my question is: what does this form (appear to do) from a Clojure syntax perspective?
(defn run-game
([engine seed]
(run-game engine seed
{:columns 50 :rows 50 :speed 500 :cellsize 10}))
([engine seed options]
(let [panel (field-panel engine seed options)
frame (field-frame panel)
timer (Timer. (options :speed) panel)]
(.start timer))))
UPDATE _
Why is "[engine-seed]" nested in a parentheses?
Why is this function recursive?
any other syntax level insights to how this function is designed?
I'm not 100% sure what you're asking, but it basically defines a function that either takes engine and seed arguments or engine, seed and options arguments.
If the option argument isn't specified, the function creates a default map {:columns 50 :rows 50 :speed 500 :cellsize 10} and calls the second form.
You'll have to look at the code to determine what engine and seed should be set to.
Then you can call it as:
(run-game engine seed)
or
(run-game engine seed {:columns 75 :rows 75 :speed 750 :cellsize 15})
Does that help?
Related
Elisp (void-variable\]) when trying to evaluate a function in property list
In my Spacemacs configuration, I configure my org layer to scale any latex it generates like so
(org :variables
org-format-latex-options '(:foreground "#90ee90" :background default :scale 2.0
:html-foreground default
:html-background "Transparent" :html-scale 1 :matchers
("begin" "$1" "$" "$$" "\\(" "\\["))
I use this configuration on multiple machines, and I like different scaling's for different displays, so I wrote a little function
(defun switch-scale ()
(cond
((equal (system-name) "WMachine") 5.0)
(t 2.0) ;; default
)
)
And rewrote the above code to call the function in the :scale property, like so
org-format-latex-options '(:foreground "#90ee90" :background default :scale (switch-scale)
...
When I test switch-scale in a scratch buffer, it works fine (returns 5.0), but when I add it to my configuration it triggers the following error when trying to generate latex in org mode
Debugger entered--Lisp error: (void-variable \])
eval(\] nil)
elisp--eval-last-sexp(nil)
eval-last-sexp(nil)
funcall-interactively(eval-last-sexp nil)
call-interactively(eval-last-sexp nil nil)
command-execute(eval-last-sexp)
I'm stuck as to what's happening, it seems like (switch-scale) just isn't being evaluated???
Answer was I don't understand elisps evaluation system ... so because it was in a quoted list everything inside that list was literal, so I actually needed to use a backquote to quote the list and then use a comma to evaluate the (switch-scale) function, as explained here https://www.gnu.org/software/emacs/manual/html_node/elisp/Backquote.html
Unable to Call Function in Go debugger
I am following the "Little Go Book" by Karl Seguin, in order to learn Go.
My working environment is Visual Studio Code.
Upon debugging, when I try to call a function from the debug console, i get the following error:
"function calls not allowed without using 'call'", if I try using "call fib(10)", i get "Unable to eval expression: "1:6: expected 'EOF', found fib".
This is the function I am trying to evaluate:
//Fibonnaci
func fib(n int) int64 {
if n == 0 {
return 0
} else if n == 1 {
return 1
} else {
return fib(n-1) + fib(n-2)
}
}
If i try to call the function from the code itself ( from the main() for instance, it works perfectly).
However, if I set a breakpoint and try to call the same function from the debugger console, I get the below error:
Eval error: function calls not allowed without using 'call'
call fib(10)
Unable to eval expression: "1:6: expected 'EOF', found fib"
Failed to eval expression: {
"Expr": "call fib(10)",
"Scope": {
"goroutineID": 1,
"frame": 0
},
"Cfg": {
"followPointers": true,
"maxVariableRecurse": 1,
"maxStringLen": 64,
"maxArrayValues": 64,
"maxStructFields": -1
}
}
Looks like "Function calls via delve 'call' are not supported" yet github issue in microsoft/vscode-go repo :(
The issue vscode-go issue 100 "debug: support function calls via delve 'call'" just got closed with PR 101 and commit 5a7752c / CL 249377 Delve supports function calls. Even though it is still experimental and can be applied only to a limited set of functions, this is a useful feature, many vscode-go users long for. Unlike other javascript/typescript debuggers, delve treats function calls specially and requires different call paths than usual expression evaluation. That is because Go is a compiled, runtime-managed GC language, calling a function safely from debugger is complex. DAP and VS Code UI does not distinguish function calls and other expression evaluation either, so we have to implement this in the same evaluateRequest context. We use a heuristic to guess which route (call or expression evaluation) we need to take based on evaluateRequest's request. This is part of the 0.17.0 milestone, yet to be released, and available for now in the nightly build.
Two apparently equal test cases coming back failed. What can cause that?
Below are a few lines from my test case. The first assertion comes back as false, but why? The second does not.
result=Parser.parse_subject(##lexicon.scan("kill princess"), Pair.new(:noun, "bear"))
assert_equal(Parser.parse_subject(##lexicon.scan("kill princess"), Pair.new(:noun, "bear")),Parser.parse_subject(##lexicon.scan("kill princess"), Pair.new(:noun, "bear")))
assert_equal(result,result)
Here is the actual error:
Run options:
# Running tests:
.F.
Finished tests in 0.004000s, 750.0000 tests/s, 1750.0000 assertions/s.
1) Failure:
test_parse_subject(ParserTests) [test_fournineqa.rb:30]:
Sentence:0x21ad958 #object="princess", #subject="bear", #verb="kill" expect
ed but was
Sentence:0x21acda0 #object="princess", #subject="bear", #verb="kill".
3 tests, 7 assertions, 1 failures, 0 errors, 0 skips
It looks like you have defined a class Sentence but have provided no way to compare two Sentence instances, leaving assert_equal comparing the identities of two objects to discover that they are not the same instance. A simple fix would be something like: class Sentence def ==(sentence) #subject == sentence.subject and #verb == sentence.verb and #object == sentence.object end end
The first assertion compares two different objects with the same content whereas the second assertion compares two identical objects. Apparently equal in this context means "identical objects". (Check the implementation.)
Forcing a package's function to use user-provided function
I'm running into a problem with the MNP package which I've traced to an unfortunate call to deparse (whose maximum width is limited to 500 characters).
Background (easily skippable if you're bored)
Because mnp uses a somewhat idiosyncratic syntax to allow for varying choice sets (you include cbind(choiceA,choiceB,...) in the formula definition), the left hand side of my formula call is 1700 characters or so when model.matrix.default calls deparse on it. Since deparse supports a maximum width.cutoff of 500 characters, the sapply(attr(t, "variables"), deparse, width.cutoff = 500)[-1L] line in model.matrix.default has as its first element:
[1] "cbind(plan1, plan2, plan3, plan4, plan5, plan6, plan7, plan8, plan9, plan10, plan11, plan12, plan13, plan14, plan15, plan16, plan17, plan18, plan19, plan20, plan21, plan22, plan23, plan24, plan25, plan26, plan27, plan28, plan29, plan30, plan31, plan32, plan33, plan34, plan35, plan36, plan37, plan38, plan39, plan40, plan41, plan42, plan43, plan44, plan45, plan46, plan47, plan48, plan49, plan50, plan51, plan52, plan53, plan54, plan55, plan56, plan57, plan58, plan59, plan60, plan61, plan62, plan63, "
[2] " plan64, plan65, plan66, plan67, plan68, plan69, plan70, plan71, plan72, plan73, plan74, plan75, plan76, plan77, plan78, plan79, plan80, plan81, plan82, plan83, plan84, plan85, plan86, plan87, plan88, plan89, plan90, plan91, plan92, plan93, plan94, plan95, plan96, plan97, plan98, plan99, plan100, plan101, plan102, plan103, plan104, plan105, plan106, plan107, plan108, plan109, plan110, plan111, plan112, plan113, plan114, plan115, plan116, plan117, plan118, plan119, plan120, plan121, plan122, plan123, "
[3] " plan124, plan125, plan126, plan127, plan128, plan129, plan130, plan131, plan132, plan133, plan134, plan135, plan136, plan137, plan138, plan139, plan140, plan141, plan142, plan143, plan144, plan145, plan146, plan147, plan148, plan149, plan150, plan151, plan152, plan153, plan154, plan155, plan156, plan157, plan158, plan159, plan160, plan161, plan162, plan163, plan164, plan165, plan166, plan167, plan168, plan169, plan170, plan171, plan172, plan173, plan174, plan175, plan176, plan177, plan178, plan179, "
[4] " plan180, plan181, plan182, plan183, plan184, plan185, plan186, plan187, plan188, plan189, plan190, plan191, plan192, plan193, plan194, plan195, plan196, plan197, plan198, plan199, plan200, plan201, plan202, plan203, plan204, plan205, plan206, plan207, plan208, plan209, plan210, plan211, plan212, plan213, plan214, plan215, plan216, plan217, plan218, plan219, plan220, plan221, plan222, plan223, plan224, plan225, plan226, plan227, plan228, plan229, plan230, plan231, plan232, plan233, plan234, plan235, "
[5] " plan236, plan237, plan238, plan239, plan240, plan241, plan242, plan243, plan244, plan245, plan246, plan247, plan248, plan249, plan250, plan251, plan252, plan253, plan254, plan255, plan256, plan257, plan258, plan259, plan260, plan261, plan262, plan263, plan264, plan265, plan266, plan267, plan268, plan269, plan270, plan271, plan272, plan273, plan274, plan275, plan276, plan277, plan278, plan279, plan280, plan281, plan282, plan283, plan284, plan285, plan286, plan287, plan288, plan289, plan290, plan291, "
[6] " plan292, plan293, plan294, plan295, plan296, plan297, plan298, plan299, plan300, plan301, plan302, plan303, plan304, plan305, plan306, plan307, plan308, plan309, plan310, plan311, plan312, plan313)"
When model.matrix.default tests this against the variables in the data.frame, it returns an error.
The problem
To get around this, I've written a new deparse function:
deparse <- function (expr, width.cutoff = 60L, backtick = mode(expr) %in%
c("call", "expression", "(", "function"), control = c("keepInteger",
"showAttributes", "keepNA"), nlines = -1L) {
ret <- .Internal(deparse(expr, width.cutoff, backtick, .deparseOpts(control), nlines))
paste0(ret,collapse="")
}
However, when I run mnp again and step through, it returns the same error for the same reason (base::deparse is being run, not my deparse).
This is somewhat surprising to me, as what I expect is more typified by this example, where the user-defined function temporarily over-writes the base function:
> print <- function() {
+ cat("user-defined print ran\n")
+ }
> print()
user-defined print ran
I realize the right way to solve this problem is to rewrite model.matrix.default, but as a tool for debugging I'm curious how to force it to use my deparse and why the anticipated (by me) behavior is not happening here.
The functions fixInNamespace and assignInNamespace are provided to allow editing of existing functions. You could try ... but I will not since mucking with deparse looks too dangerous:
assignInNamespace("deparse",
function (expr, width.cutoff = 60L, backtick = mode(expr) %in%
c("call", "expression", "(", "function"), control = c("keepInteger",
"showAttributes", "keepNA"), nlines = -1L) {
ret <- .Internal(deparse(expr, width.cutoff, backtick, .deparseOpts(control), nlines))
paste0(ret,collapse="")
} , "base")
There is an indication on the help page that the use of such functions has restrictions and I would not be surprised that such core function might have additional layers of protection. Since it works via side-effect, you should not need to assign the result.
This is how packages with namespaces search for functions, as described in Section 1.6, Package Namespaces of Writing R Extensions Namespaces are sealed once they are loaded. Sealing means that imports and exports cannot be changed and that internal variable bindings cannot be changed. Sealing allows a simpler implementation strategy for the namespace mechanism. Sealing also allows code analysis and compilation tools to accurately identify the definition corresponding to a global variable reference in a function body. The namespace controls the search strategy for variables used by functions in the package. If not found locally, R searches the package namespace first, then the imports, then the base namespace and then the normal search path.
Clojure compile-time escape mechanism
The language Forth offers a "compile-time" escape mechanism where code can be executed immediately, while the compiler is running (not at run-time). You can include print statements, for example, to debug tricky syntax or type errors). Does Clojure have anything similar? I am getting a compile-time IllegalArgumentException in one of my function calls and would like to add a compile-time print statement to determine the argument type ((.getClass)). Thanks. UPDATE: Here is the complete defn that is failing compilation: (ns my.ns.name (:gen-class :main true) (:use [clojure.contrib.str-utils2 :only (join)]) (:import [java.io PrintWriter] [java.net URL] [java.util.concurrent Executors] [java.util.jar Manifest] [org.apache.commons.cli CommandLine HelpFormatter Options Option ParseException PosixParser])) (defn set-version "Set the version variable to the build number." [] (def version (-> (str "jar:" (.. my.ns.name (getProtectionDomain) (getCodeSource) (getLocation)) "!/META-INF/MANIFEST.MF") (URL.) (.openStream) (Manifest.) (.. getMainAttributes) (.getValue "Build-number")))) This defn works: (defn set-version "Set the version variable to the build number." [] (println (str (.getClass my.ns.name))) (def version (-> (str "jar:" (-> my.ns.name (.getProtectionDomain) (.getCodeSource) (.getLocation)) "!/META-INF/MANIFEST.MF") (URL.) (.openStream) (Manifest.) (.. getMainAttributes) (.getValue "Build-number"))))
Printing the class of things during compilation is pretty restricted to special cases. You will mostly get Symbols and Seqs. Only literals have a meaningful type during compilation. You can execute arbitrary code during compilation via macros. (defmacro debug-type [x] (println (type x)) x) However as I said: this will normally not be very helpful. And no: in general you cannot wrap x in an eval, eg. if x is a symbol refering to a let-local. EDIT: Update for updated question. (def version (-> (str "jar:" (-> *ns* (.getProtectionDomain) (.getCodeSource) (.getLocation)) "!/META-INF/MANIFEST.MF") (URL.) (.openStream) (Manifest.) (.getMainAttributes) (.getValue "Build-number"))) Try this. There is no need for a function. def inside defn should ring alarm bells.