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.
Related
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)
I was trying to get the default printer through VBA and I came across the Windows API GetProfileString function:
GetProfileString documentation
On one website I found a working example that retrieves the printer name:
returnedChars = GetProfileString("Windows", ByVal "device", vbNullString, printerName, Len(printerName))
The site I linked states that on Windows Server 2003, Windows XP and Windows 2000 (and later versions as well, I assume - the documentation probably isn't up-to-date) the values that GetProfileString return may be taken from the registry if certain conditions are met. I opened the Registry Editor and found the correct section - ...\IniFileMapping\win.ini\Windows. To my surprise, there is no key named device. I re-read the documentation a couple of times, but it didn't help. I don't have a corresponding section in my win.ini file.
Can anyone explain how this function exactly works? It looks like it could come in handy in numerous situations, so it would be nice to know how to use it properly.
This function is one giant backwards compatibility shim. The idea is for legacy code to continue working by picking up values that were moved to the registry when Windows moved from 16-bit to 32-bit.
The documentation makes this pretty clear:
Note This function is provided only for compatibility with 16-bit Windows-based applications, therefore this function should not be called from server code. Applications should store initialization information in the registry.
The message is clear. Do not use this function.
You ask how the function works, when it reads from the registry. That is covered in some detail by the documentation and I don't think there's much to be gained by trying to re-phrase that documentation.
It would be nice to know how to use it properly.
Use the function properly by never calling it!
i recently read one Book "CODE Reading The open Source Perspective ", wiki link is here.
I notice that it use a
netbsd "netbsd export-19980407"
as its source to dig into.
My question is how to get the precise version of that netbsd?
So i an get more precise code-relating and field experience when use this book.
Since this is an ''export'' it probably means it was a CVS export of the main NetBSD tree.
See: http://netbsd.org/releases/formal.html
A date of 1998 / April / 07 (this is how I read the date of the export) - so that would be a CVS version between NetBSD 1.3.1 and NetBSD 1.3.2.
Make of that what you will, since I am not a NetBSD expert (but I have installed and used it a dozen times already).
FWIW, NetBSD newest version is 6.1 - yes, 1998 was 15 years ago, and I was much younger then...
Context
As a university project we want to change the the pharo vm to use an object-table and see what happens.
We use a pharo-vm clone from github and VMMaker. Building the VM works fine.
To get started we added a primitive that returns an incremented Integer:
InterpreterPrimitives>>primitiveIntegerIncrement
"increments an integer"
self pushInteger: self popInteger + 1 .
and modified StackInterpreter class>>initializePrimitiveTable accordingly
MaxPrimitiveIndex := 576.
"... and so on ..."
(575 primitiveFail)
(576 primitiveIntegerIncrement))
And it works.
Problem
When we make changes to the VM we want to test-run already in the SmalltalkImage so we do not need to compile and see it did not work.
Something like:
StackInterpreter test: '1 inc'
And then I can debug if the primitive is wrong or an error occurs. Of course there needs to be done much more but how can I achieve this?
What we tried
category VMMaker-InterpreterSimulation class StackInterpreterSimulator. Trying the code in the comments
DoIt
^ (StackInterpreterSimulator new openOn: Smalltalk imageName) test
errors:
displayForm := 'Display has not yet been installed' asDisplayText form.
the ByteString does not understand asDisplayText
(CogVMSimulator new openOn: Smalltalk imageName) test
(InterpreterSimulator new openOn: Smalltalk imageName) test
error:
PrimitiveFailed: primitive #basicNew: in Array class failed
I also found this screen cast but it only debugs the VM from outside using gbd: http://vimeo.com/22485382#
Our project is hosted here: http://smalltalkhub.com/#!/~kirstin/PharoObjectTable
Current Status
We started implementing an object table. The lookup of attributes can go throught the object table. Full object table support and no usage of direct pointes is very tricky since pointers are expected everywhere. So we use pointers into the object table to identify when a lookup should go through the OT. We also found all object creation primitives and add new objects to the table.
How long is your project and how many people are you ? To me what you try to do is quite some work. Do you have good knowledge about low level behavior ?
To answer your question, the main problem here is that the cog simulator is not maintained in the pharo vm fork. This is because no one in the pharo crew use the simulator. We only use external debugging from gdb. In fact the pharo folks work mostly on VM plugins, the core of the VM is mainly maintained and developed by Eliot Miranda which works on Squeak. Therefore we report to him when there's a bug in the VM core.
For your project you would have to split it in at least 2 steps:
step 1: make the object table work with the stack VM
step 2: make the JIT work with your object table
Note that for step 2 I would recommend not to change the way an object access its header, therefore having a VW-like object table where you have the fixed size header on the one in the the object table, and the fields of the objects (and maybe header extensions) in the heap.
So use the StackVMSimulator and build the StackVM first. When everything will work (including context), you can think about hacking the JIT. Recently Guillermo Polito ported the Stack VM to the build process (see PharoSVMBuilder instead of PharoVMBuilder), a guy reported problems with this builder but you could hack it a bit to make it work.
Now to make the simulator work on Pharo 2.0 (which is the Pharo version of the generator image you have), you have to open the monticello browser and merge from Eliot's branch the Cog package (repo MCHttpRepository location: 'http: //source. squeak. org/VMMaker'), but not the latest Cog, the one at around the same date as the current VMMaker package of pharo-vm because the latest Cog and VMMaker of Eliot's branch are not stable.
The alternative being to start from Eliot's build image and merge things from the pharo branch. Here are infos about how to build the squeak development image (http://www.mirandabanda.org/cogblog/build-image/).
Then Eliot gave me this script once:
| cos |
cos := CogVMSimulator newWithOptions: #(Cogit SistaStackToRegisterMappingCogit).
cos desiredNumStackPages: 8.
cos openOn: 'my/favourite.image'.
cos openAsMorph; toggleTranscript; halt; run
You don't need the SistaStackToRegisterMappingCogit option. I guess some similar script with the StackVMSimulator should work.
Lastly there are some documentation about the simulator but it is only for the CogSimulator (these documentations expects you already knows how the StackSimulator works, and just give you hints about how to use it with the JIT):
http://www.mirandabanda.org/cogblog/2008/12/12/simulate-out-of-the-bochs/
and in one of the video named "Cog VM (part x)", x being from 1 to 6, Eliot shows how he uses the simulator to disassemble x86, print the stack and inspect the heap.
Another tip, ask your questions on the pharo mailing list (pharo users or pharo dev), because here no one may notice your question (fortunately someone pointed me out your question this time).
And tell on the pharo mailing list if you managed to run the simulator in Pharo 2.0, some people (as me) are very interested in it. I was planning to do it at some point.
Good luck ! Nice project anyway.
The last time I tried to use the simulator is roughly a year ago, and I did not make it work.
However, there are a few patches, which I assume never got integrated that might be of help:
https://code.google.com/p/cog/issues/detail?id=106
https://code.google.com/p/cog/issues/detail?id=107
https://code.google.com/p/cog/issues/detail?id=108
Issue 107 includes a patch for your asDisplayText issue.
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.