When I want to read in an S-expression stored in a file into a running Common Lisp program, I do the following:
(defun load-file (filename)
"Loads data corresponding to a s-expression in file with name FILENAME."
(with-open-file (stream filename)
(read stream)))
If, for example, I have a file named foo.txt that contains the S-expression (1 2 3), the above function will return that S-expression if called as follows: (load-file "foo.txt").
I've been searching and searching and have not found an equally elegant solution in Clojure. Any ideas?
Thanks!
You can do e.g.
(require '[clojure.contrib.io :as io])
(io/with-in-reader (io/file "foo.txt") (read))
; => (1 2 3)
Note that you'll likely want to rebind *read-eval* to false first. Also note that the above works with current contrib HEAD (and will almost certainly work in 1.2 when it's released); for Clojure 1.1, the same functionality is available in the clojure.contrib.duck-streams and clojure.contrib.java-utils namespaces.
I found a solution here: How do you evaluate a string as a clojure expression?
(read-string (slurp "foo.txt"))
Sorry to bother you, folks ^_^
Related
Dealing with files of different C flavours, I defined the following function and a keyboard mapping to invoke it:
(defun my-c-set-gnu-style ()
"doc string"
(interactive)
(setq tab-width 8
indent-tabs-mode t)
(c-set-style "gnu")
)
(global-set-key (kbd "C-x :") 'my-c-set-gnu-style)
Now when I open a C file with emacs, and then type C-x: then nothing happens. Only after I hit some key (and thus I change the code, which is really bad), emacs will re-draw the code according to the new style.
How can I achieve that emacs will re-indent the code right after the respective command has been issued? The need to change the file is really bad.
Version is GNU Emacs 26.3.
The issue isn't related to c-set-style. Changing the TABs mode like in (setq tab-width 8 indent-tabs-mode t) should also have an immediate visual effect — which it does not have.
Using (redisplay t) didn't solve the problem, but what worked is (force-window-update) at the end of the defun. Dunno if that's supposed to be issued by hand or whether the requirement is an Emacs bug, though.
On my Windows XP box with sbcl-1.4.14 I've installed the ASDF using
(load "C:\\Program Files\\clisp-2.49\\asdf\\asdf.lisp")
(require :asdf)
(push "C:\\Documents and Settings\\mayhem\\lisp\\iterate\\" asdf:*central-registry*)
On SLIME
(require :iterate)
(iterate (for i from 1 to 5) (collect (* i i)))
gives The variable I is unbound error
If I do (in-package :iterate), the code above works fine but this time familiar functions such as exit and other functions which I've defined in .sbclrc cease to work, they give The function ITERATE::EXIT is undefined type of errors, for example.
If I do (use-package :iterate), then it gives [Condition of type NAME-CONFLICT] error.
So I began to use the package like this:
(iterate:iterate (iterate:for i from 1 to 5) (iterate:collect (* i i)))
But I think you'll agree that it's a bad style.
How to use the iterate correctly?
Note: I've seen the post about the very similar problem but it didn't help. There aren't many posts or articles about this particular problem.
You need to say (use-package :iterate) before you try to refer to unqualified symbols from the iterate package.
What has happened in your case is this.
You've loaded the iterate system into the running Lisp, creating a package called "ITERATE".
In the "CL-USER" package you've typed (iterate ...), and the reader has worked out that it needs to find or create a symbol whose name is "ITERATE" and which is accessible in the "CL-USER" package.
There is no such symbol, so it creates a new one, CL-USER::ITERATE.
This is not ITERATE:ITERATE so you get an error from the evaluator as it's trying to evaluate the arguments to a function (which doesn't exist, but it doesn't know that yet). In fact the error you're getting is while it's evaluating the first argument in the (for i ...) subform.
Now you say (use-package :iterate) to tell the system to add the "ITERATE" package to "CL-USER"'s search list.
Now there's a conflict: should iterate refer to the existing CL-USER::ITERATE or the newly-accessible ITERATE::ITERATE? (And there are some other conflicts too, probably).
So the system signals an error, and there should be some useful ways to proceed from that, one of which is probably 'unintern all the conflicting "CL-USER" symbols', but you didn't take that option, I suppose.
So now everything is messed up.
And the answer is: use the packages you want to refer to unqualified symbols from before you try to refer to those symbols unqualified.
(Also: Windows XP? I'm impressed by your retroness.)
I've been working on making auto-complete-mode work with Semantic nicely but know I'm completely stuck. I've succesfully had semantic autocomplete through semantic-ia-complete-symbol (though for some reason it can't complete malloc(), which is weird).
Some .emacs snippets:
(add-to-list 'ac-dictionary-directories "~/emacs-src/auto-complete-1.3.1/")
(ac-config-default)
(ac-set-trigger-key "TAB")
(add-to-list 'ac-sources 'ac-source-semantic)
(add-to-list 'ac-sources 'ac-source-gtags)
(add-hook 'c-mode-hook
(defun my-c-mode-hook ()
(auto-complete-mode)
(setq ac-sources '(ac-source-semantic))
(ac-complete-semantic)))
How do I make auto-complete-mode work together with Semantic?
If I understand you correctly, Semantic is working and you're only struggling with setting up auto-complete. For doing the latter, simply start with
(require 'auto-complete-config)
(setq-default ac-sources '(ac-source-semantic-raw))
Note that you have to use "setq-default" for setting ac-sources. You should then be able to do
M-x auto-complete-mode
in a C/C++ buffer and auto-complete should query Semantic for completions.
Try debugging the auto-completion failure by:
M-x semantic-analyze-debug-assist RET
and see what it says. Look at \include\stdlib.h to see what the parser thinks of the file. If while there you do:
M-x bovinate RET
then you can search to see if malloc is there. If not, there is probably a parsing bug, or some miscellaneous #define that isn't set up correctly. Using the above you can usually find at a header file to see where things start to break down.
For testing purposes, I need to share some definitions between Tcl and C. Is it possible to include C style include file in Tcl scripts? Any alternative suggestion will be welcomed, but I prefer not to write a parser for C header file.
SWIG supports Tcl so possibly you can make use of that. Also I remember seeing some code to parse C headers on the Tcl wiki - so you might try looking at the Parsing C page there. That should save you writing one from scratch.
If you're doing a full API of any complexity, you'd be best off using SWIG (or critcl†) to do the binding. SWIG can do a binding between a C API and Tcl with very little user input (often almost none). It should be noted though that the APIs it produces are not very natural from a Tcl perspective (because Tcl isn't C and has different idioms).
Yet if you are instead after some way of handling just the simplest parts of definitions — just the #defines of numeric constants — then the simplest way to deal with that is via a bit of regular expression parsing:
proc getDefsFromIncludeFile {filename} {
set defs {}
set f [open $filename]
foreach line [split [read $f] "\n"] {
# Doesn't handle all edge cases, but does do a decent job
if {[regexp {^\s*#\s*define\s+(\w+)\s+([^\s\\]+)} $line -> def val]} {
lappend defs $def [string trim $val "()"]
}
}
close $f
return $defs
}
It does a reasonably creditable job on Tcl's own headers. (Handling conditional definitions and nested #include statements is left as an exercise; I suggest you try to arrange your C headers so as to make that exercise unnecessary.) When I do that, the first few definitions extracted are:
TCL_ALPHA_RELEASE 0 TCL_BETA_RELEASE 1 TCL_FINAL_RELEASE 2 TCL_MAJOR_VERSION 8
† Critcl is a different way of doing Tcl/C bindings, and it works by embedding the C language inside Tcl. It can produce very natural-working Tcl interfaces to C code; I think it's great. However, I don't think it's likely to be useful for what you are trying to do.
I am trying to make a script that tells me all the functions in C codebase that contain a call of of function X.
My strategy is to call rgrep and from te output determine from which functions the searched string is called.
I know little to no lisp so this is an educational experience too for me so please don give answers meaning something along the lines of "USE AWK NOOB"
Did you try cscope? http://cscope.sourceforge.net/
This function worked for finding the function name given that the point is in the function :D
(defun search-fun () (interactive)
(search-backward-regexp "[a-zA-Z_][a-zA-Z0-9_]*[ \n\t]+\\([a-zA-Z_][a-zA-Z0-9_]*\\)[ \n\t]*([^<>=]*)[ \n\t]*{")
(setq str (match-string 1))
(if (string= str "if") (search-fun ) (return str)))