On FEI machine, dark field tilts are done by changing "beam LX", "beam LY", "beam UX", "beam UY" defelectors. Are there commands to access this tilt?
I tested out using EMGetBeamTilt(x,y). There is no change on those numbers when changing DF tilt.
Also tried "void EMGetProjectorShift(number x, number y)". This command does not exist in GMS 1.x.
Using "EMSetBeamTilt(x,y)" works to achieve the similar result. I am looking for that way to emulate the DF control used on FEI. Reason 1 is the speed. EMSetBeamTilt is very slow on FEI. Reason 2, hysteresis is strong. Reason 3, it is nice to sync the hardware knob and the script to enhance interactive capability.
GMS 1.x is very, very outdated (on par with WinXP) and didn't even have a supported script-interface for microscope control. (It did have unofficial commands though.)
Microscope control commands were officially introduced and supported with GMS 2.3 ~2012 and going forward, but they are limited in nature as they represent the common denominator of various microscope vendor's hardware interfaces. (i.e. they have to work with all microscopes).
Documentation has since been pretty up-to-date, with some commands being added over time in higher GMS versions. So the short answer to the actual question is:
You have the commands that are documented in the F1 help documentation and there are generally no additional commands.
Depending on your system there might be crude workarounds, though.
f.e. if you system has it's own interface for Python or VisualBasic, one can write a script command to call those interfaces. (Python since GMS 3.4)
Related
I sometimes test Python modules as I develop them by running a Python interactive prompt in a terminal, importing my new module and testing out the functionality. Of course, since my code is in development there are bugs, and frequent restarts of the interpreter are required. This isn't too painful when I've only executed a couple of interpreter lines before restarting: my key sequence when the interpreter restart looks like Up Up Enter Up Up Enter... but extrapolate it to 5 or more statements to be repeated and it gets seriously painful!
Of course I could put my test code into a script which I execute with python -i, but this is such a scratch activity that it doesn't seem quite "above threshold" for opening a text editor :) What I'm really pining for is the Ctrl-r behaviour from the bash shell: executing a sequence of 10 commands in sequence in bash involves finding the command in history (repeated Up or Ctrl-r for a search -- both work in the Python interpreter shell) and then just pressing Ctrl-o ten times. One of my favourite bash shell features.
The problem is that while lots of other readline binding functionality like Ctrl-a, Ctrl-e, Ctrl-r, and Ctrl-s work in the Python interpreter, Ctrl-o does not. I've not been able to find any references to this online, although perhaps the readline module can be used to add this functionality to the python prompt. Any suggestions?
Edit: Yes, I know that using the interactive interpreter is not a development methodology that scales beyond a few lines! But it is convenient for small tests, and IMO the interactiveness can help to work out whether a developing API is natural and convenient, or too heavy. So please confine the answers to the technical question of whether readline history-stepping can be made to work in python, rather than the side-opinion of whether one should or shouldn't choose to (sometimes) work this way!
Edit: Since posting I realised that I am already using the readline module to make some Python interpreter history functions work. But the Ctrl-o binding to the operate-and-get-next readline command doesn't seem to be supported, even if I put readline.parse_and_bind("Control-o: operate-and-get-next") in my PYTHONSTARTUP file.
I often test Python modules as I develop them by running a Python interactive prompt in a terminal, importing my new module and testing out the functionality.
Stop using this pattern and start writing your test code in a file and your life will be much easier.
No matter what, running that file will be less trouble.
If you make the checks automatic rather than reading the results, it will be quicker and less error-prone to check your code.
You can save that file when you're done and run it whenever you change your code or environment.
You can perform metrics on the tests, like making sure you don't have parts of your code you didn't test.
Are you familiar with the unittest module?
Answering my own question, after some discussion on the python-ideas list: despite contradictory information in some readline documentation it seems that the operate-and-get-next function is in fact defined as a bash extension to readline, not by core readline.
So that's why Ctrl-o neither behaves as hoped by default when importing the readline module in a Python interpreter session, nor when attempting to manually force this binding: the function doesn't exist in the readline library to be bound.
A Google search reveals https://bugs.launchpad.net/ipython/+bug/382638, on which the GNU readline maintainer gives reasons for not adding this functionality to core readline and says that it should be implemented by the calling application. He also says "its implementation is not complicated", although it's not obvious to me how (or whether it's even possible) to do this as a pure Python extension to the readline module behaviour.
So no, this is not possible at the moment, unless the operate-and-get-next function from bash is explicitly implemented in the Python readline module or in the interpreter itself.
This isn't exactly an answer to your question, but if that is your development style you might want to look at DreamPie. It is a GUI wrapper for the Python terminal that provides various handy shortcuts. One of these is the ability to drag-select across the interpreter display and copy only the code (not the output). You can then paste this code in and run it again. I find this handy for the type of workflow you describe.
Your best bet will be to check that project : http://ipython.org
This is an example with a history search with Ctrl+R :
EDIT
If you are running debian or derivated :
sudo apt-get install ipython
I'm looking for some powerful programming environment for C/C++. In fact the only think i need is powerful source navigating + creating tool. Doesn't matter if its free or commercial. I prefer some linux tool, but it doesn't have to be necessary linux app.
What i need is some kind of editor with following capabilities:
more open files + tabs/buffers switching
highlighting (+ bracket matching, folding, etc...)
save sessions
preview window(when the cursors stops on some symbol, i have also an preview window, that shows me the definition of that symbol)
searching for uses of the symbol through code
intelligent completion (must support c++ 14!)
What would be nice:
code beautifizier or something similar
utf-8 support
editor templates(for example automatic comment header for modules, functions...)
other editor scripting
a terminal/console accessible from program || compiling debugging capabilities(just for to be able to compile the whole project without switching extensively to command line)
program flow visualization
Please do anyone around the whole world knows anything, that knows all of that?
I've tried several editors/IDEs, but all of them misses something. I've decided to emphasise missing support for new c++14 - it's now probably the biggest problem:
VIM
Amazing scripting capabilities
4 and 6: i've tried to use vim+ctags+cscope and vim+gtags + omnicomplete. But its not that usable. This doesn't work properly. Vim doesn't know c++ and it does not know the symbol context. Though i've been able to achieve basically the desired behaviour after hours of learning vim scripting, i'm not able to use it in even a little more complicated manner.(Lets say i have global variable and local variable with same names and different types - vim ofc does not recognize if im seeing now global or local only variable. And i'm not even talking about namespaces, etc....). Actually VIM now support c++14 with the help of clang(libclang) and there is awesome plugin called YouCompleteMe, that can use libclang, and its auto-complete really workds with c++14 code! And it makes the vim the only editor supporting c++14.. This plugin is now more or less usable in more editors(vim, emacs, sublime). It adds autocomplete, jump to definition and error messages.
c++14 supported
Source Insight
Amazing highlighting capabilities(different font for highlighting is amazing(especially for function names in function defintion header for example), also there is possibility to assign keyboard shortcut to cancel font differences, and leave only color highlighting(when you are bothered with different code alignment(due to different fonts)
Problems with 1) (though a hacked library for this called TabsSiPlus exists)
no terminal/console
Software is not maintained anymore, its not open source(and even not free) :(((
c++14 support missing
SlickEdit
Amazing customizing possibilities, can emulate vim editing style(WOW!)
no terminal/console(actually there is one, but not that good, however it has builtin compiling capabilities
it has strange GUI - a lot of space is occupied by scrollbars, different window captions, etc..
its kinda expensive(comparing to others)
c++14 support missing
Kdevelop4
Very pleasant GUI, nice console, very fast, can emulate vi editing style(not too well though)
miss force rescan/retag project (sometimes there are wrong symbol references, especially in bigger projects - this bugs me a lot)
its preview window doesn't show definition, only reference to definition, the definition then is showed in main editing window.. - cannot see actual code and the symbol definition at once :((
c++14 support missing
Eclipse
nice environment with lots of functionality.
don't have ad4), however it has some sort of preview bubble. When you hover mouse cursor upon symbol, it will show a bubble with symbol definition. Its nice functionality, but unfortunately you need to use mouse, and its noway that user friendly as separate preview window.
also its a little slow, but i think its due to realtime syntax checking, and it probably will be disablable.
c++14 support missing
Emacs
Support c++14 by similar plugins as vim(YouCompleteMe)(see in Vim section).
Please can some proficient Emacs user fill in this section?
c++14 supported
Sublime Text 3
Not free
Support c++14 by similar plugins as vim(YouCompleteMe)(see in Vim section). Though i had some problems with it. Plugin was more unstable than in Vim for me.
Through different plugins it support more or less the same functionality(from user view) as vim.
c++14 supported
Do any of you use some different editor, that can do anything from the list above, or maybe some plugins/scripts that can achieve the demanded functionality?
Regarding VIm and your point 6, I have heard that clang_complete, which is leveraging clang from LLVM compiler was quite accurate but I have not yet tested myself.
Try Eclipse, can handle almost everything (from Java to C with GNU Tools)
Eclipse supports c++14, all you need to do is to add -std=c++1y in your prefrences->C/C++->Build->Settings->Discovery
for "CDT Cross GCC Built-in Compiler Setting" add "-std=c++1y" at the end of compiler specs.
You also set the dialects in your project setting to support c++14,
Go to your project setting->C/C++ Build->Settings->GCC C++ Compiler->Dialect and select -std=c++1y
This is a multi-part question to SO folks before I engage more with core team.
Summary: On OS X, pdfs should be created using quartz, not postscript. Files are smaller, anti-aliased better, OS fonts including opentype are readily available, encoding is less painful, overall I think it’s a better device. On other platforms, it would be reasonable to use cairo, again a more modern pdf-writing device.
Consider the behavior of the png() device. Although it is allegedly slated to move out of x11.R, it handles c("cairo", "Xlib", "quartz") with a default (options("bitmapType")) set by zzz.R (quartz if capabilities("aqua"), cairo if available, Xlib otherwise). PDF needs to behave the same way, so that in Sweave (or babel or whatever) my pdf figures can be generated using the appropriate device.
My Sweave png patch works because png() takes care of getting the device option. An earlier version of the patch (which I still use) flips the device in Sweave, but I was smacked down for this and I know it’s sort of the wrong the place to do it.
There’s some alias cairo_pdf() (also in x11.R) that probably should not be there, shouldn’t that be merged into a device-switching pdf() ?
One approach is to add option "pdfType", which in turn I think should probably be more general – there is already a default device, it’s just that pdf() ignores it! I’m especially wary of introducing new global options because they are more likely to be rejected by core.
I don't think you'd need to implement a device driver. Mostly it sounds like you want to alias pdf() so that it calls quartz() or cairo() as appropriate. The quartz() device already supports PDF output to a file (among others) on OS X.
For your own personal use (I doubt this would find its way into core) you could just alias pdf() to take the appropriate action on each of your platforms and bring it in as a package or in your Rprofile.
pdf.orig = pdf
pdf = function(...) {
// Insert code here
}
Recently (about a month ago) I was trying to introduce new constructs to my company's in-house extension language, and struggling with a couple of reduce-reduce errors. While I eventually solved this problem, digging into the y.output file was no picnic.
As an experiment, I tried using Bison's --graph=<file> option to output a DOT file (note that our standard build uses Byacc, not Bison). As I'm on a 'turnkey' Linux box, I didn't have a Graphviz installation and could not easily install from RPMs (working on Red Hat Enterprise Linux 4). Instead, I built it from source.
As an initial experiment, I tried to run dotty with an output of Postscript. Now our internal language is your average home-grown, Turing-complete, dynamically typed scripting language, but I was unprepared for what followed. The dotty run took over four hours (2GHz dual core AMD64 box)! And when it was done, the graph that was rendered was not what I would call readable.
So, quite simply, I'm looking for advice. Are there a set of switches which would improve the outcome over the 'default' approach I took? I'm looking for experience in
optimizing 'render' time
improving readability of the graph
possible advice on better graphical viewers
I imagine you've already seen this link, but just for completeness, there is a list of viewers etc. at: http://graphviz.org/resources/ or see https://web.archive.org/web/20131005020548/http://graphviz.org/Resources.php for an archived copy.
I'm working on automation tools for an ERP program running on SCO Unix.
See my questions on Expect:
(Tcl/Expect) clear screen after exit
Expect - get variable from screen region based on row and column
Where can I find (either locally or on the web) resources for understanding what control characters are used in a session, and more specifically, determining a field location on the screen during an interaction with the ERP program?
The specific control characters for a given terminal type are stored in the terminfo database. curses reads the value of $TERM when initializing and uses it to find and extract the relevant sequences for the various terminal operations.
I'm not really clear what you are asking, but one source of documentation on curses is the GNU implementation at http://www.gnu.org/software/ncurses. As far as 'control characters' go, well that depends on what terminal you use - yours probably understands ANSI codes - see http://en.wikipedia.org/wiki/ANSI_escape_code.
I just found out that the X/Open Group released a new version of their standard in November 2009 (previous version was released in 1996), and it is available free on the web from their bookstore as Technical Standard - X/Open Curses, Issue 7. You have to register, but access is free (and registration does not lead to an inundation of email, etc).
The previous version, Issue 4, Version 2 (from July 1996), is no longer available from X/Open. Given the newness of Issue 7, the new features are unlikely to be widely implemented yet, but look for changes in the next few years.