I would like to launch a Scala Swing application from the command line, then after the application is started, drop into the Scala REPL to use as a control interface.
Ideally I would also like to pre-bind some variable names. Even better would be using a Java2D terminal emulator for the REPL, but I couldn't find anything appropriate.
Does the Scala REPL have a public API?
You are may be asking about the same thing, as this question, are you? There is other stuff you can do. There's a way to just call REPL with a code, and get an answer back, which, depending on what you want, may be more appropriate. If that's what you want, just clarify it and I'll research into it.
As for Java2D terminal, I think it is enough to use Console's setIn, setOut and setErr, but I might be mistaken. You might want to take a look at how some other efforts which embed REPL in the environment do. I think there are at least three of them, but a quick search only Kojo, which is based on Netbeans.
Related
I am adding a homemade programming language to VS Code, and can't get the interpreter to run my files. The goal is for the extension to run "myinterpreter.exe ${file}" or equivalent, when the user hits Debug (or Run, I have no debugging features implemented, so I am going to just ignore any debug information.) I have very little in the way of ideas on how to do this, but I think it should be mostly possible with just package.json. How would I do this?
I think these docs cover what you need. What happens when the user hits "Run" or "Debug" is defined in client/.vscode/launch.json. "runtimeExecutable" is what you can populate with "myinterpreter.exe ${file}"
I'm trying to do some basic spreadsheet tasks within OpenOffice for which the standard functions won't suffice, so I'd like to write my own macro in BASIC.
However, my function doesn't work. How do I go about debugging it? I tried inserting MsgBox("something") throughout my code but this has no effect (no message box appears when I call the function from Calc.
I also tried placing breakpoints throughout the function, which Calc simply ignores.
How can I debug my function?
The debugging guides seem to be more about subroutines than functions. I noticed that many people have commented that python would be a better option. Is that because the Basic implementation in OpenOffice is poor? Am I encoutering IDE bugs or are these features?
I can't reproduce this behavior. If I have a Function created in the IDE then I can use all what you say you can't: MsgBox and the observer. For using the observer of course the IDE has to remain open. See screenshot:
I have called the function as =MYFUNC(23) in a Calc cell, then I have fetched the IDE window to front and have run the code step by step.
Whether and how python would be a better option, you should ask the people which comment this would be so much better ;-). It is not my opinion.
Little introduction how to use python with openoffice:
https://wiki.openoffice.org/wiki/Extensions_development_python
Is there a way to restore all escreen screens and window configurations on emacs startup?
I tried to add the (escreen-configuration-alist) to desktop-saved-globals with no result.
I also tried to execute some code manually, but whenever I run (escreen-restore-screen-map screen-map) with screen-map being export of current escreen screen map, I get "wrong argument type window-configuration-p".
Not an elisp expert and a little bit stuck.
If there's no luck with escreen, maybe el-screen has the needed functionality?
Thanks.
Actually, escreen use the window configuration as defined in Emacs. Unfortunately window configuration is hard coded in C and there is no serialization. So you cannot save/restore between sessions but simply register it.
The only way is to rewrite window configuration in Emacs Lisp. HIROSE Yuuji wrote his own window configuration and it works great! I enhanced it to support frames and escreen case and post it on github: https://github.com/martialboniou/revive-plus
I provided this package WITHOUT ANY WARRANTY. No unit test, for instance, but it should work. Let me know (it's a fresh hack so there will be refactoring soon)!
I built tfs.el to allow developers to do TFS things (checkout, checkin, etc) from within emacs.
There are 13 interactive commands in the tfs package, like tfs/checkout, tfs/rename, tfs/diff, and so on, and I'd like to be able to provide help on all of them in a single place. An overview of all the available functions.
What's the "emacs way" of doing that? I thought of defining an additional function, like tfs/help , that would invoke describe-function-1 on each of the tfs functions, and then present all that in a TFS-Help buffer.
Is there a better way?
Well, there are many "Emacs way"s.
The most polished would be to write an info page, see the page "Info for Experts", which basically says to use Texinfo and convert that into an info page. You can be as verbose as you want there, and the user can search, use hyperlinks, etc. The user can easily get there via C-h F tfs/checkout.
Another way some folks seem to do it is to write short documentation strings for each of the commands, ending with "see documentation for tfs-mode for details" and put all the common documentation in the docstring for tfs-mode.
Another way some packages document things is with a big comment at the top of the tfs.el file.
Take your pick, they all have trade-offs.
You can use
(describe-bindings "\C-xv")
You have multiple, related commands. So far, I guess, they are related only by their names.
Two possibilities come to mind:
Create a mode for this stuff. Document everything in the doc string of the command that turns the mode on/off. It could be a major mode or a minor mode. If a minor mode it could be buffer-local or global.
Create a group (defgroup) for this stuff and document everything in its doc string.
The basic idea is to somehow actually relate these commands: bundle them together in some way, so you can document them together as the doc for the bundle.
Offhand, without knowing more, my guess is that you might want to create a global minor mode.
I am new to Clojure, and am beginning to experiment with building an application.
So far, everything I've seen about tutorials on compiling Clojure programs involves interactivity. For example, "load up the REPL and type (load-file "this-or-that") to run. This is fine, but it's not enough.
I am so used to the edit-compile-run idioms of languages like C or Delphi, that I am instinctively driven to make edits, then hit "M-x compile".
The problem is that "lein uberjar", which I understand is the equivalent to "make", is painfully slow to execute even for a hello world. So I'm going to have to figure out how this "interactive development" stuff works, stop using the uberjar like it's quick make, and save it only for the end of the day.
Another thing I noticed while building (using lein uberjar) is that the small GUI app I am working on pops up frames in the compilation process, as if they are executing while compiling. It just seems a bit counterintuitive to me; it is not quite as analogous to "make" as I had thought.
I know the Lisp way of developing things is interactively working in the REPL, and I am not trying to change that: I would like to adapt to this way of life. Unfortunately, I have seen little in the form of documentation on how to do so. For instance, how to reset the current state of the machine. It just seems kind of messy to just keep compiling individual snippets on the fly without being able to do some sort of reset.
Most tutorials I have seen on Clojure (and Lisp) in general seem to focus on hacking in the REPL. Best practices on the deployment of applications remains a mystery to me. My users are just going to be users; they are not going to be developers that are going to load files into a REPL.
So here is my question: any resources for good information or tutorials on the entire process of building a Clojure application, including deployment?
(Note: I have all of the prerequisites installed and working (e.g. Emacs, Slime, Leiningen, etc.), so this is not a question about that).
A couple of quick hints, then some links:
Don't use lein uberjar during development; prefer lein jar. The difference is that lein uberjar puts all your dependencies in the generated jar (including Clojure itself), so that your single jar is an entirely self contained package with your app inside; lein jar only jars your own code. The uberjar approach has obvious benefits for deployment, but for development, you should be able to just use the appropriate classpath when running your app, saving yourself the time necessary to prepare an uberjar. If you don't want to hand-manage the classpath for test runs, check out the lein run plugin.
Also, most likely the majority of your code should not actually be AOT compiled. AOT is necessary in some Java interop scenarios, but most of the time it brings one a slight boost in startup speed and annoying problems with binary compatibility with different releases of Clojure. I suppose the latter issue is not relevant to an uberjar-ed standalone app kind of project, but any library code at least should be left to be JIT-ed if at all possible. With Leiningen, you can put a :namespaces clause in the defproject form in project.clj to determine which namespaces are to be compiled; whatever you leave out will currently be JIT-ed by default. Older versions of Leiningen used to compile everything by default, which is actually a good reason to upgrade!
As for the windows popping out during compilation, I would guess that you're either running window-out-popping code during macro expansion time or outside of any function definition or similar construct. (Something like a (println "Foo!") at the top level.) That's just something you shouldn't do, I suppose -- unless you are planning to run your code as a script, anyway. To avoid the problem, wrap side-effecting code up in function definitions and provide an entry point to your application using the :main clause in project.clj. (If you say :main foo, then the -main function from the foo namespace will be used as the entry point to your app. That's the default, anyway, and at least the above mentioned lein run seems to have the name hardcoded -- not sure about lein itself.)
As for resetting the state of the REPL -- you can just restart it. With SLIME, M-x slime-restart-inferior-lisp will do just that while maintaining all other state of your Emacs session.
See also these discussions on the Clojure Google group:
Clojure for system administration
Prepping clojure for packaging (was: Re: Clojure for system administration)
Leiningen, Clojure and libraries: what am I missing?
No, you do not enter functions on the REPL.
You edit your source files, just as usual. The Lisp advantage is that you have the system running in the background at the same time, so you can compile individual functions from your source file and put them into the running system, or even replace them there.
If you use Slime, you press C-c C-c in your source file to compile and load the function at point. You can then switch to the REPL to test and explore, but anything you want to persist as source, you put into your source files.
Tutorials usually start by typing things on the REPL, because there is not much you need to set up for this, but serious development integrates the running system and source file management.
Just to illustrate, my usual workflow (I am using Common Lisp, but Clojure is similar) is like this:
Start Emacs
M-x slime to start Slime, the Lisp system, and connect the two via Swank
, (command) load-system foo to load the current project (compiling only if necessary) into the image
C-x b switch to a source buffer
C-c ~ make the source directory the current directory and the source package the current package of the REPL
Now, I'm set up with my system running in the background. Working is then:
change or add a function or class definition
C-c C-c to compile and load it into the image
switch to REPL, test
debug
There are no significant compilation pauses, because I never compile the whole thing at once, just individual definitions.