0.7 warns to use revise.jl, but on its documentation I just can't find a command to just say "clean it all".
Yes, I can sure just restart Julia, but in an IDE is several clicks away, while sometimes I just want to clean all variables/modules previously defined..
Yes, I can sure just restart Julia, but in an IDE is several clicks away
Assuming you are using Juno,
press Ctrl+j then Ctrl+k.
Docs
This kills the julia process, which will then automatically restart.
It is fairly fast
One possibility is to work with your code inside a module MyModule, then use Atom/Juno's inbuilt ability to define the working module in the left-most part of the bottom bar. Reevaluating the module should clear everything.
You can add this to your startup.jl file, and workspace() should work essentially the same as on previous Julia releases:
function workspace()
atexit() do
run(`$(Base.julia_cmd())`)
end
exit()
end
Related
I use the atom-runner package, which runs scripts when I click alt+x:
Now, I also installed the gpp-compiler package, which runs c++ files when I click F5:
It is confusing to have two different key-bindings for running. I would like to use alt+x both for gpp-compiler and for atom-runner, based on the file: if it's a c/c++ file then run gpp-compiler, otherwise run atom-runner.
Is this possible?
You are in luck. I was doing something similar to this recently and thought that this could be done.
I've made an Atom package to do what you're looking for. You can find it at https://atom.io/packages/multi-hotkey. The default hotkey is Ctrl-M.
Currently only one hotkey is possible, but with customization available for four different user-inputted file extensions and corresponding commands, and a final command for anything not matching the preceding extensions.
RGTK2 block user input while processing its explain how to block user input using RGTK2 but I dont know how to add that code to my GUI code, im using tcltk. What I want same like in RGTK2 block user input while processing but using tcltk2
I use this code to run button "filter cluster" and the command function is filter (function to do something)
tkpack(tkbutton(f4, text='Filter Cluster', command=filter), side='left',padx= 5, pady = 20)
In tcltk, you would use tkgrab.set on a non-responsive window and tkfocus on a window that has a binding on the <Key> event that prevents further processing. An inconspicuous tkframe is great for that sort of thing — set it to size 1×1, but ensure it is on the screen — as it has no default behaviour to get in the way. (You'll also want to make a bunch of cosmetic changes, such as marking the widgets as disabled and setting the cursor to watch.) In 8.6, there's tk busy (call with tcl("tk","busy",…) since the Tcl tk command appears to not have a convenient mapping) which makes this all much easier (though I don't know if/how that's mapped into R). The simplest way to release a grabbed window is to destroy it, but you can also tkgrab.release.
Do not use a global grab. They're easy to get wrong and can cause you a lot of grief. (If you insist, you're strongly recommended to make mouse activity cancel it and to test very thoroughly. Locking up your display is not a pleasant experience!) The default local grabs are less of a problem, since you can switch to another program and kill off a stuck app if necessary.
The full documentation for Tk (and Tcl) is online; pick the version of the docs for the version of the library that you're using, probably 8.5, hopefully 8.6 ('cos it has some nice extras) and possibly 8.4 (old skool!) As the R documentation for tcltk says, you can invoke anything in Tcl or Tk through tcl(…), passing in the words of the command name and arguments as many strings… (Tcl is a naturally var-args language and uses that extensively.) The limited scope of the default convenience mapping should not hinder you substantively.
General advice, not so closely related to your question
Most Tk programmers try to write their code to not lock users out that way if possible. You get a better user experience if you can keep the GUI responsive and instead just temporarily disable (via the state option on most reactive widgets) the parts that would otherwise trigger reentrancy problems for the duration. (The long-running processing might be also event-driven, or put in another thread, or even delegated to a sub-process. Just remember, Tk GUIs are strictly single threaded — the implementation assumes this very deeply, though it's possible to have wholly independent apps in different threads, if rather hairy to get working right — so you've got to come back to the GUI thread to update anything in the GUI.)
Rstudio has a great code completion feature. It provides a quick view of functions that start with a given string, as well as function and parameter definitions.
ESS is powerful enough, familiar to me, and integrated into Emacs, where I conduct most of my work - so I am hesitant to move, but this feature is making me consider such a move.
Is it possible to integrate this feature into Emacs ESS?
Is there anything similar to this for Emacs ESS?
Any hope that there will be (and if so, how could I support such an effort?)
You do get the completion thanks to the rcompgen package by Deepayan (now "promoted" into base R as part of the utils package). So when I type
lm(
and hit TAB a new buffer opens which gets me the left-hand side of your window above: the available options to the function at hand. I don't think you can show the help directly though.
There is / was also a way to get context-sensitive help in the mini-buffer when typing but I have forgottten how/where that gets turned on.
[EDIT: This is an old answer and auto-complete package dropped out of fashion since then. Please use company-mode instead. It should work by default. Wiki configuration entry is here.]
Recent versions of ESS (> v.12.02) integrate with auto-complete package out of the box (you need not configure anything, just install auto-complete). It provides help on arguments as well as function help. I added detailed instructions to the wiki
Ess-eldoc was also rewritten and from v.12.02 it's active by default, so you don't need to configure anything.
Or maybe we should all use search:
Emacs autocomplete-mode extension for ESS and R
I don't want to be grumpy, I found this few hours ago and I'm still shocked. It works like a charm. Though I still prefer the old-style pop-ups. =)
While I am writing .R functions I constantly need to manually write source("funcname.r") to get the changes reflected in the workspace. I am sure it must be possible to do this automatically. So what I would like would be just to make changes in my function, save the function and be able to use the new function in R workspace without manually "sourcing" this function. How can I do that?
UPDATE: I know about selecting appropriate lines of code and pressing CTRL+R in R Editor (RGui) or using Notepad++ and executing the lines into R. But this approach has a disadvantage of making my workspace console "muddled". I would like to stop this practice if at all possible.
You can use R studio which has a source on save option.
If you are prepared to package your functions into a package, you may enjoy exploring Hadley's devtools package. This provides a suite of tools to write, test and document
packages.
https://github.com/hadley/devtools
This approach offer many advantages, but mainly reloading the package with a minimum of retyping.
You will still have to type load_all("yourpackage") but I find this small amount of typing is small beer compared to the advantages of devtools.
For additional information, including how to setup devtools, have a look at https://github.com/hadley/devtools/wiki/development
If you're using Eclipse + StatET, you can press CTRL+R+S, which saves your script and sources it. As close to automatic as I can get.
If you can get your text editor to run a system command after it saves the file, then you could use something like AutoIt (on Windows) or a batch script (on UNIX-derivative) to pass a call to source off to all running copies of R. But that's a heck of a lot of work for not much gain.
Still, I think it's much more likely to work being event-driven on the text editor end vs. having R constantly scan for updates (or somehow interface with the OS's update-event-messaging-system).
This is likely not possible (automatically detecting disc changes without intervention or running at least one line).
R needs to read into memory functions, so a change on the disc wouldn't be reflected in the workspace without reloading your functions.
If you are into developing R functions, some amount of messiness during your development process will be likely inevitable, but perhaps I could suggest that you try writing an R-package to house your functions?
This has the advantage of being able to robustly document your functions, using lazy loading so that you have access to your functions/datasets immediately without sourcing them.
Don't be afraid of making a package, it's easy with package.skeleton() and doesn't have to go on CRAN but could be for your own personal use without distribution! Just have fun!
Try to accept some messiness during development knowing you are working towards your goal and fighting the good fight of code organization and documentation!
We are only imperfect people, in an imperfect world, but we mean well!
I have been using UNIX for years and the dcop command only recently came to my attention. What is its primary purpose and is using it in any process a sign of poor design?
is using it in any process a sign of poor design?
Probably not, as long as you're using DCOP to perform some task that would ordinarily be done with a mouse click or hotkey. It's certainly way better design than trying to control the mouse to do what you want to do with the program!
But if you use DCOP to do something really simple that could be done directly with a shell command or a few lines of C code, without invoking a KDE application at all, it's probably better to just do it the direct way. (e.g. don't use DCOP to tell Konqueror to remove a directory tree, just run rm -rf)
I suspect it mainly exists because everything in UNIX ought to be accessible from the command line.
The Wikipedia article on dcop is worth a read.
It's great for any scripts to use to control processes, there's also good information on controlling Amarok via dcop.