I'm writing a test script in python that will manipulate memory in the system.
I know the m command (modify memory) exists; however, it seems extremely clunky. Our test suite does not handle input prompts very gracefully either. I believe there must be something better out there.
In your experience, what other ways are there to modify memory in VxWorks?
Target shell commands in VxWorks are no more that C functions - the shell includes a symbol table generated at build time that includes all functions with external linkage. As such the "m" command is in fact a simple a C function (see here). You could equally call memset() or memcpy() or write your own function.
To execute function calls on the target from a host, without using the target or host shell, you might consider using RPC using RPyC on the host perhaps.
Related
I want to evaluate the performance of Rascal for a given rewrite system that I've written. I'm wondering if there's a good way of doing it?
Ideally, I'd generate some compiled Java classes from the system and then run them manually against my inputs. Is there an easy or recommended way to do it?
Cheers,
One way to do this is to use the functions in the library util::Benchmark. Typically, you could write something like
cpuType( (){ call_the_function_I_want_to_observe(); } ). This will execute your function and print the cpu time used.
Note that Rascal can be executed in two ways: interpreted and compiled which makes a big difference when measuring performance. We are working hard at the moment to fully integrate the compiler in the Eclipse IDE, but a stand alone version is available as well. This can be called as java -Xss8m -jar rascal-0.8.4-SNAPSHOT.jar --compiledREPL followed by at least values for directories for sources (--src), and binaries (--bin). Here rascal-0.8.4-SNAPSHOT.jar (but most likely named differently) is downloaded from the https://update.rascal-mpl.org/console/rascal-shell-unstable.jar.
If you need more information, don't hesitate to ask for more details: this part of our tool chain is unfortunately still undocumented.
I would like to query whether a particular Dafny program verifies. Dafny is typically used to develop programs in an interactive manner inside the visual studio IDE.
However, I need to perform the query in a non-interactive manner. In particular I need to query Dafny from within a python program. Is this possible?
You can invoke dafny.exe from python, passing as an argument the name of a file that contains the dafny program that you wish to verify. Please see this other answer on how to call external commands from python.
You can get help on the dafny command line arguments by running dafny.exe with the /? switch.
You will need to parse the output of dafny to determine if the verification was successful. The dafny test suite works in this manner.
You might like to look at the code of this project which does something similar, but from Java.
I'm trying to build Premake5 on FreeBSD 10.1 from the sources. I eventually got it to compile by removing the "-dl" option and using gmake explicitly for the build. It built, but I can't get it to do anything but spit out the following error message. Doesn't matter how I invoke it. It crashes even on 'premake5 --help'.
Here's the message:
PANIC: unprotected error in call to Lua API (attempt to call a string value)
The code is buggy as all get-out. It starts by assuming linux is posix which is clearly not the case. They use linuxism all over the place so converting to posix is going to be quite a task, and until that is done it will never work satisfactorily on non-linux posix based systems.
The -ldl was obviously the first stumbling block. The next is in the function premake_locate_executable in premake.c. In this they are using the /proc filesystem which is a linuxism and since this fails on BSD they are falling back to some lua methods but they seem to be assuming that lua_tostring pops the corresponding value which it doesn't. Since their stack isn't balanced in this function the following lua_call is trying to call the garbage they've left on the stack rather than the function they intended.
Even after I fixed this issue they use getconf _NPROCESSORS_ONLN to get the number of cores to multi-job the make build but they don't actually check that this call succeeds (which it doesn't outside of Linux and MacOSX).
After fixing this issue I then ran into the problem that their makefiles aren't regular make, but GNU-make, so I had to change to using gmake to try and build.
From that point it just came unravelled because none of the premake files in the contrib directory are configured for BSD despite it being one of the legal configuration targets (i.e. it doesn't default to linux) and so there is no configuration for those components.
TLDR: BSD is not a supported platform
If I compile a regular .lua file with luac, can the result be ran without the Lua library or interpreter installed?
No. You can run it on a version of Lua that was built without the compiler, but you still need the Lua interpreter to execute the code.
Incidentally, the compiled Lua bytecode is also machine-specific; i.e. you can't compile on one architecture and then run that output on another architecture unless you understand the subtleties (endianness, sizes of types, etc.).
If your code doesn't use any dynamic load-based facility (that's loadstring, loadfile, require, etc.) you can strip Lua library to just a VM, because what compiler emits is code to be run on this virtual machine. This can easily cut Lua already small footprint to 1/3 fraction of original.
However, since this is NOT a native binary code for any currently existing architecture, you still CAN'T run it directly without assistance of VM.
Does anyone have experience developing with ESQL/C for INFORMIX-SQL, as in calling C funcs within "Perform" screen generator and "ACE" report writer?
I have ISQL without ESQL/C. I experimented compiling a perform screen, where in the instructions section I put "ON BEGINNING CALL userfunc() END" and although I don't have
ESQL/C, the Perform screen successfully compiled without errors!.. Apparently, the compiler didn't reject the C call even though there's no ESQL/C or C program linked.
Yes, I have some experience with them - dim and distant, now.
The form compiler (sformbld) has to accept any function call that you make - it cannot tell whether it will be valid or not at run time. It does not know which functions are available to the (custom) Perform runner that will be needed to run the form.
Similarly, the report compiler (saceprep) has to accept any function call that you make because it cannot tell whether it will valid or not at run time.
To run a form that contains a function call other than the built-in functions, you must create a custom runner (rather than using the standard sperform). The script to do that on Unix is 'cperf'; it will take the function definitions that you provide and build a custom runner that can call those functions. You can then run a report which uses those functions using the custom runner. If your custom code does not do any ESQL/C calls, you don't even need ESQL/C on the machine; the ISQL product is sufficient.
The parallel circumstances apply to reports; you cannot use the standard sacego but must create an appropriate custom runner with 'cace'.
Now, in the dim distant dark ages (say before 1990), you did not get the custom ACE and Perform stuff with ISQL - you had to buy ISQL and ESQL/C. But since ISQL version 4.00 was released (AFAICR, in 1988 or 1989), the custom runners and libraries were provided with ISQL and you no longer need to buy ESQL/C unless you want to build ESQL/C functions into your custom functions.
Note that you do not create a custom compiler; therefore, the compiler cannot tell what functions are available.