I don't get any GC logging messages when running Racket code in raket-mode in emacs.
Running the following code in DrRacket gives back a log entry while running it in Emacs REPL does not.
(define my-logger (make-log-receiver (current-logger) 'debug 'GC))
(collect-garbage)
(sync/timeout 1 my-logger)
How can I get the log messages in the Emacs REPL case?
Make sure you have a somewhat recent version of racket-mode (e.g. latest from MELPA).
Use C-c C-l a.k.a. M-x racket-logger to open a racket-logger-mode buffer.
If you have any problems or questions, feel free to open an issue.
Update: The above instructions don't really answer why your own program isn't getting a log event. This is a really interesting bug -- thanks! More conversation on the issue thread. When I figure it out, I'll try to come back here and update this answer again with something hopefully interesting and educational about Racket logging.
Update: This turned out to be a "what was I thinking?" bug in racket-mode. I was creating a new logger:
(define global-logger (make-logger))
(current-logger global-logger)
rather than just using the existing one:
(define global-logger (current-logger))
The existing logger is special, as the Racket documentation for loggers explains:
On start-up, Racket creates an initial logger that is used to record events from the core run-time system. For example, an 'debug event is reported for each garbage collection (see Garbage Collection).
I've pushed a commit to a topic branch and when I get all-green from CI I'll merge to master; it should be available via MELPA soon after.
Related
I installed an Agda compiler, binarys can be from here: http://ocvs.cfv.jp/Agda/how-to-install-windows.html
... and I'm trying to make it compile a simple hello world app (I found the Agda 'Hello World' code online)
But I've never used Emacs before, and I don't know where to begin, or which commands to use to compile and run. I'm new to Agda, which seems to have limited options for compilers, and is lacking any step by step tutorial. Below is a screenshot of the Emacs compiler with the code I found:
open import System.IO using ( _>>_ ; putStr ; commit )
module System.IO.Examples.HelloWorld where
main = putStr "Hello, World\n" >> commit
I'm looking for step by step instructions to run a simple 'Hello World' program
A working example with another compiler would also be an acceptable answer
Thanks!
This looks like you attempted something like the general M-x compile rather than any specific Agda functionality.
The Agda:run mode indicator in the Emacs mode line suggests that you have a running Agda process in another buffer, but you're not looking at it. The Agda mode probably has something like agda-eval-buffer which should pass your current program to that process, and bring up the results in the lower half of the pane. (Try switching to a buffer called something like *inferior-agda* manually if you somehow cannot reach that buffer by other means.)
The site you link to says it's Agda 1 and you should probably actually look for Agda 2 on a different site.
Below the line is my original answer, which may still provide some useful insight.
The error message indicates that you need to install make.
I'm guessing there may be additional missing dependencies after you fix this one. Ideally the documentation should explicitly specify exactly what you need to install.
make is just a wrapper to run whatever cormands are found in the local Makefile. If there is no such file, you will probably want to change the compilation command to something else. (Typically Emacs asks you for a command to run, but supplies a plausible default.)
Given I am running on Linux and am no agda expert, this solution might not be worth it. But still I will give it a try.
When I installed agda and agda-stdlib on my system, it provides me with a file called agda2.el in /usr/share/agda/emacs-mode. That said I just had the following in my ~/.emacs.d/init.el file:
(load-file (let ((coding-system-for-read 'utf-8))
(shell-command-to-string "agda-mode locate")))
Since, you already have agada mode setup in Emacs the above wont be useful unless your version of agda mode is old.
We can compile the current file you have opened in Emacs using M-x agda2-compile. Doing this will open up another prompt asking you for a Backend. I used GHC as input and it compiled it. Yes, and I got some errors I don't know how to fix. So, I queried on a search engine and came up with:
module memo where
open import IO.Primitive using (IO; putStrLn)
open import Data.String using (toCostring; String)
open import Foreign.Haskell using (Unit)
main : IO Unit
main = putStrLn (toCostring "Hello, Agda!")
I need to point out that the first line module memo where should be same as the filename which for your case is memo.agda.
I now have a hello world program running on my machiene.
The following code compiles and works
open import Common.IO
main = putStrLn "Hello, world, strings working!"
is the code, stored in the file 'hello.agda', which I compile in emacs to 'hello'. I compile in emacs by selecting agda > compile, an option that is available on emacs when agda is installed correctly.
I can't give a detailed tutorial as to how to install agda on emacs as a friend did it for me, but the above code works, and compiles on emacs on linux, which is the set up which is working for me.
I am not meaning cleaning up the text output of REPL; I mean cleaning up all evaluated results in REPL. During developing, repeatedly C-c C-q and C-c M-j is low efficiency.
UPDATE
There may be some bad debug behaviour of mine. I am not sure how other people develop progs with CIDER, but I really need the functionality mentioned above. I guess other developers also encounter same problems as mine.
For example, at the top of a clojure prog unit, I use declare to declare a function foo, which is used by another function bar, and foo is implemented after bar. Then, I C-c C-k, etc, and the prog goes well. Later, I removed the forward declaration of foo occasionally. What does happen? The prog still goes well. REALLY? Then, I commit my whole job and terminate the CIDER REPL session happily.
Disaster on morning: Symbol foo not found!
That's my story. So, nobody has ever encountered similar problems?
Try the (refresh) function in the clojure.tools.namespace.repl namespace:
The refresh function will scan all the directories on the classpath for Clojure source files, read their ns declarations, build a graph of their dependencies, and load them in dependency order.
https://github.com/clojure/tools.namespace#reloading-code-usage
It doesn't seem to remove the vars declared in the user namespace, which I've typed into the REPL, but it does:
...unload (remove) the namespaces that changed to clear out any old
definitions.
We generally add that plus a few other useful things to the user namespace, so it's loaded into the REPL on startup:
(ns user
(:require [clojure.tools.namespace.repl :refer [refresh]]
[clojure.repl :refer [doc source]]
[clojure.pprint :refer [pprint pp]]
[midje.repl :as midje]
[clojure.stacktrace :as st]))
To keep that code separate from your main and test sources, put that in a file at <project root>/dev/user.clj, then add the following to your lein project.clj file:
:profiles {:dev {:source-paths ["dev"]}}
(p.s. although it's not the question you want answered, for those seeing this answer and wanting to clear the text in the Cider REPL, it's C-c M-o (https://github.com/clojure-emacs/cider)
In EMACS when I works with Clojure in cider-mode, I use:
C-c M-o in the repl buffer
it is bound to cider-repl-clear-buffer
Like others have already pointed out, the 'proper' solution is to use Stuart Sierra's component library.
But since you're running in CIDER, you can use C-c C-x to run cider-refresh, which will reload your project and thereby recreate your initial state.
If you're dealing with a large number of things which have state which you want to clear to have a clean developing environment you might consider doing one of the following:
1.) Reassess your design and see how much of that state is actually necessary. In many situations you might be using atoms, refs, or other stateful items unnecessarily and if you adopt a more functional approach, you won't find yourself needing to clear up your development environment as often.
Presuming legitimate reasons for using state:
2.) You can wipe out a namespace and all of it's contents by using the clojure function remove-ns: e.g. for a namespace called user.fancy-namespace you can clean the NS out by running (remove-ns 'user.fancy-namespace') and then simply re-evaluating the namespace. This works well for cleaning up a single namespace, but if the stateful items you need cleaned are in other namespaces, it can get tedious to do this for every namespace involved.
3.) Stuart Sierra's component library was designed to manage components which involve state. Very useful for managing DB connections, memcache clients, etc, but will require a re-architecting of your project in order to make full use of it.
As mentioned by others, it is only necessary to clear the repl if you have variables which are holding state information. For non-state carrying components, just reloading the source buffer (re-evaluating it) is sufficient.
One very interesting way to manage a workflow which does have components that track state is Stuart Seirra's component framework. See http://youtu.be/13cmHf_kt-Q
Another approach is to write your code using defonce rather than def, which will allow you to reload your source code without redefining state variables.
If on the other hand, you want to do this to clean up defn or defmacro definitions you don't need i.e. clean out 'polution' from your repl, then to be honest, I wouldn't bother. If nothing is calling a defn or macro, it really doesn't matter.
I constantly find myself doing multiple manual (require '[my.lib :as foo]) right after I start cider with M-x cider-jack-in in my clojure projects. I suspect there must be a hook to run some code on a successful connection. Is there? The alternative would be to put all requires in an external file and just (use 'that.namespace) but lazy as I am, I want to even skip that step if possible.
UPDATE:
Putting the forms in .lein/profiles.clj :injections is fine as long as one uses them exclusively in the Repl (as per lein repl). To make them available from the nrepl in emacs one must use the second solution named by arrdem below.
Here is some more comprehensive info.
Leiningen's :injections feature is the cannonical way to pull this one off. Once Lein boots a Clojure instance, the code in :injections gets evaluated allowing you as you say to populate the user namespace with libraries that you use all the time.
Another approach is to (ab)use the file user.clj by adding a :dev profile with a dev-only source path that "happens" to contain a user.clj with preloading code in it. This is done in Grimoire with the file dev/user.clj which serves to create some utility functions in the REPL.
I often find my self starting some long running process from the REPL and then wish I could carry on using the REPL for other tasks while it was running. Can I use slime to background the current thread or start a new REPL control thread? Starting an additional REPL buffer would be fine as well.
Edit:
Hm, I somehow managed to miss the Clojure tag on your question. I would be very suprised if the solution below worked for Clojure, since, as you probably know, the Clojure community unfortunately (at least for those of us using Clojure and CL) maintains its own version of Slime. I won't delete the answer, because it might be helpful for CL programmers searching for this functionality.
Unless there is a similar solution for Clojure, which allows multiple REPLs multiplexed over a single socket, you could maybe just start a second Swank server by hand (from the *inferior-lisp* buffer) and connect to it via slime-connect as a workaround. (Can't test this ATM, since I stopped using Slime with Clojure a while ago.)
Did you try the slime-mrepl contrib? I have not actually used it myself, but a quick test worked for me under CCL/Win/Emacs 24.
I tested it like this: M-x slime, enter (sleep 10) in the REPL, switch buffer, M-x slime-new-mrepl.
Please forgive me for a somewhat trite and non-slime specific answer; on the upside it will work with any clojure REPL.
When I know in advance I am starting a long running task from the REPL then I start the computation using future and check with future-done? before deref-ing it.
This might not answer your question, but it might be helpful to realize that as long as (slime-communication-style) is :spawn, evaluations done using C-x C-e always spawn their own thread and can run in parallel to whatever is happening in the REPL thread. Output (from println etc.) will appear in the REPL buffer.
I'm currently in the process of adding functionality to an existing J2EE webapp, in a Tomcat container, and I'm writing my additions using Clojure. My setup is simple: I just add calls to static methods generated by clojure, and code all the hard work from the clojure side. The build process consists in compiling clojure code (lein uberjar) and then compiling the java code with that jar on the classpath.
In the webapp init, I have a call to a generated class that fires up a swank server with a (swank/start-repl). I'd like to be able to connect my Aquamacs' slime to that server, and work interactively from there (up to a point, I won't try nothing that requires a java-side recompilation). But I have a situation that I don't quite understand. If I do a \M-x slime-connect, I get a REPL prompt (after being notified that there's no inferior lisp process, which I think it's ok, since the inferior lisp process is running outside emacs control). I can evaluate forms perfectly, and I can even inspect things like my.own.namespace/my-var. However, if I visit a file with an already compiled clojure code, I can't seem to make slime recognize it as its source. Consider a simple clojure file:
(ns my.namespace
(:gen-class
:name my.namespace
:methods [#^{:static true} [testFunc [] void]]))
(def *secret* "shhhh")
(defn -testFunc []
(println (str "our secret is: " secret)))
Assuming that this was compiled and included in the uberjar loaded by the webapp, I can eval/inspect my.namespace/*secret*. But If I try to eval inside the code buffer, Slime thinks I'm on the user namespace (which can even make sense!). But now I'm left with a single working option - I have to evaluate - one by one, all the forms in the file! \C-c \C-l (loading the source file) won't do nothing - apparently just returns nil and outputs nothing else. Compiling everything seems to do just that - it compiles, shows errors if it finds them, but won't change my namespace. And the strangest is the \C-~ (sync package and directory), which using Common Lisp it does just what I want, but here it freezes the clojure REPL for good.
There's always the option of switching to the REPL, typing (in-ns 'my.namespace), and then all works properly. But that simply isn't practical enough when the clojure files are growing in number (as the namespace of the code buffer won't change automatically!)
My question is, then, whether I'm lacking a basic command/configuration - or if there's an obvious reason for this behavior to happen as such.
I may be misunderstanding your problem, but can't you (while visiting this hypothetical buffer in emacs), hit C-c C-k to compile the buffer in your current Clojure instance (what Slime is connected to)?
Then, in the Slime buffer, switch to this namespace with a (in-ns 'my.namespace). Then you should have access to what you compiled in that namespace.
Switching namespaces automatically on compile has never been the default for swank-clojure, though it might be an optional slime feature that happened to work with Clojure. But C-c M-p to switch the repl to the current buffer's namespace has always worked for me, and I've never heard of anyone having trouble with it.
Are you running on the latest stable versions of clojure-mode and slime-repl? Do you have swank-clojure.el installed? (You shouldn't need it.) It sounds like this could be due to mismatched versions of the elisp libs. If that's not the problem it could be an Aquamacs bug; swank-clojure is designed to work with GNU Emacs. It could also be a bug in slime if you are running from trunk rather than the latest elpa release.
I've just found out that removing the culprit for this issue: slime-redirect-inferior-output, from slime-repl.el, was being called from a hook I had setup. It turns out that it doesn't play well without an inferior-lisp-process (read, a swank server started from within emacs).
So a quick workaround hack is just to remove the error form from that function, like this. Now the hook proceeds, and the namespaces are automatically calculated. As intended. Thank you for the suggestions, nevertheless - they led me to this solution!