We're working on a project with a number of applets that has to work across a large range of OS (WIndows, Mac, Linux), browsers (IE, FF, Safari, etc) and Java versions (1.5+), and it often happens that a fix we apply will cause some sort of security exception an another platform or some other error.
Is there any way for us to prepare automated tests to immediately catch those problems in different platforms? I think it's not necessary to check that the gui parts are appearing as intended, but just to detect whether unexpected exceptions are occuring.
Related
I am looking for advice on how to do unit testing on my STM32F7 platform. What have people done in the past? What horror stories do you have? What would you do differently? What is problematic with my current plan?
My Setup
STM32 Nucleo-144 with a custom carrier PCB
arm-atollic-eabi-gcc compiler (no C++, for now)
Using Atollic TrueStudio as an IDE
Development done from Ubuntu 16.04
Running FreeRTOS on the board
My Testing Plan
There are different levels of testing; I am specifically talking about unit testing a library / set of functionality that does NOT depend on external hardware. Things like "does my ring buffer implementation correctly handle rolling over without memory leaks" and "does this bit-shift operation result in the correct endianness in the resulting variable"? So I am focused on those kinds of tests.
Convert my project to compile with C++ (and all the associated extern C required)
Refactor my code into a "library" portion and an "application" portion.
Build googletest (this is what we use for other parts of our system) and link my library into it for testing.
Run the unit tests on the device while running a debug session through Atollic.
You should revisit the question if you really have to do the unit testing on an embedded target at all as you wrote that unit tests are planned (as usual) in order to test
a set of functionality that does NOT depend on external hardware.
Things like "does my ring buffer implementation correctly handle rolling over without memory leaks?" and "does this bit-shift operation result in the correct endianness in the resulting variable?"
These are (potential) errors will happen on a PC architecture (x86, ...) in virtually the same way as on STM32.
At the same time, you should ask yourself how many errors will occur accidentally while you
Convert [the] project to compile with C++ (and all the associated extern C required)
Refactor my code into a "library" portion and an "application" portion.
Don't get me wrong - the latter point may improve the quality of the software considerably if it is done well (and in the ideal phase of the project).
I've been developing software with functional-safety relevance (IEC61508, SIL3) for many years now - and while there might be some special cases when you cannot move all unit testing to a different HW platform (your PC), I have never encountered such an example myself.
Instead, we could always perform our unit tests on some PC and complement these unit tests by some sort of integration tests on the original hardware.
Please note that in such (complementary) integration tests, you don't have to focus on library-internal logic errors any more, but mostly on HW/SW integration and system integration.
Is it possible to compile a swift binary from an OS X computer so that it runs on a server running Linux as a single binary without no extra libraries that need to be dynamically linked?
I'm thinking something like passing a -target to the swift command and passing another parameter to let it statically link all dependencies, but I'm not sure what the exact commands are.
The exact value for -target seems to be rather elusive.
Do I need to know the exact target distribution to be able to pass the correct string to the -target parameter?
From reading the sources on github
target would be Linux
machine would be x86_64
This gets called by the primary build script
This how ever answers a part of the question
The exact value for -target seems to be rather elusive.
Install a GCC toolchain for Mac OSX that can retarget Linux, one repo that I can see is OSXCross, for example.
Supply the values to the environment variables to GCC prior to running the script, that references that toolchain.
Unfortunately, that does not guarantee it will work, but give it a try and see what happens.
Is it possible to compile a swift binary from an OS X computer so that it runs on a server running Linux as a single binary without no extra libraries that need to be dynamically linked?
The short answer? Of course it is! Anything is possible when you put your heart to it!
Is it efficient? Inherently, no.
While I'm sure everyone here is familiar with what a compiler does, for the sake of this question and its newest of users, a compiler is an application that converts human readable code and maps it to a binary format that a computer can understand. However it should be worth mentioning that not all computers are the same. Each computer operating system has a different binary mapping than the other so a simple operation like copying values could be expressed as 1010 on one machine, and 0101 on another. As stated before in many questions prior, and for example this one, many programming languages are buildable across a variety of machines, but very few of them are portable across them because each computer has a different binary mapping.
~~~~~~~
So how do we fix this?
~~~~~~~
Well there are a number of solutions to fix this. The most obvious
method is to simply make your environment the target environment and
build your program to your hearts content. You obviously already did
this through a virtual machine and this typically what many
developers will do. This is by far the easiest solution but it
defeats the purpose of the question where you want to simply build
from your OSX machine.
Earlier you said you heard people talking about compiling windows programs on linux machines. Cygwin is a a development platform aimed at obtaining the windows framework that is not normally present on linux machines and allows many programs to be built with the windows framework in mind. However all its doing is adding binaries so that the compiler has some proper places to map to when windows only commands are found within a configuration. All its doing is introducing the binary configurations necessary for a program to successfully be ported over. This ties into the second option.
Secondly comes a compiler that supports cross platform compilation.
While I am currently uninformed and/or unfamiliar with such
compilers, this is technically a valid solution but would I call it
reliable? Probably not. If anything you're just adding more work to
your compiler as not only does it have to correctly map the syntax of
one computer program for one computer, it has to waste time linking
it to the new binaries. Additionally you would need to have the
compiler remember these linking's which could entail more wasted
memory space for having this one compiler.
Even then, systems like these are few and far between and whether its guaranteed to work depends upon how well the compilers maintainer knows their stuff, how frequently they update it etc. etc. And the chances that they even performed to correct mappings of binaries in the first place is not something I'd stake my life on.
The third and perhaps most ideal solution is to look into container technologies such as docker. Their containers are essentially ways for you to build your app and port it to new machines without having to change or modify anything about how you build and compile it. Simply build one, store it in a container, port it to your machine of choice and integrate it into your current project. Come to think of it, container systems like docker were built to prevent the very thing that you are currently experiencing, where you have a source code working on your one machine but no place else. Something like docker will be able to run your code on any machine without having to recompile it for each new machine.
Docker provides an interesting framework for container to container communication, application examples and has a fairly straightforward documentation that it would be worthwhile to look at to see if your project could have some of its parts ported to docker.
This being said, there are multiple ways to fix the issue you are currently facing, so as you being a software engineer, its up to you in what would be the most ideal way of handling your project.
// EDIT //
Will edit this to be a better response once im not drop-dead tired.
As a personal learning project, I want to port an existing x86 emulator library to JavaScript and then run a very simple operating system on top of it.
My only requirement for the library is that it should be written in C\C++, as I want to use emscripten and asm.js to compile the source files to JavaScript. The library should at least be able to interpret x86 opcodes; the specific environment details for JavaScript (memory, GUI, interrupts etc.) I can implement myself. The operating system doesn't have any requirement, as long as it is simple enough and can run on the emulator.
So far in my research, Softx86 seems like the most viable solution, as it seems simple enough to port to JavaScript (it only does CPU emulation). The simplest 16 bit real-mode operating system I can find is MikeOS, the only problem being that it requires a 386 processor, which Softx86 cannot emulate and I am not sure if they are completely compatible.
My question is if anyone knows an alternate combination of emulator-OS that is simple enough to be ported to JavaScript.
For anyone who will come across this thread in the future, I've decided to port Fake86 to JavaScript, and use MS-DOS as the operating system.
You can see a live demo here
It runs very, very slowly, and currently only runs on Firefox, but it works nonetheless.
You can see the full source code here
I wish to use the application known as Processing to create interactive graphs and figures to use in a presentation for the Arizona JSHS competition. I have used the widely popular LiveWeb application to be able to embed java into the power-point. But when I do the same thing with Java applications made with Processing it gives an error.
"Error: Unexpected identifier or string. http://localhost/applet/index.html"
I have tested it with locally hosted Java applets and Processing applets, both work run normally. But only the Java applet (which is very similar to the processing applet) works in LiveWeb.
Does anyone have suggestions to get around this? Do you think I could import processing library's into Eclipse and work from there?
One potential solution would be processing.js. It is a javascript version of processing that may fit your needs.
we start to write plug in for eclipse to work with some java frame work like hadoop (we want to edit hadoop eclipse plug in and merge it with other. our plug in must work in Linux operating system. Generally writing plug in for eclipse depend on operating system or not? if depend what benefits to write it for Linux?
Well, the previous answer is correct... in most cases. You should specifically check all the interfaces with the operating system.
SWT is a Java wrapper over native OS widgets. It behaves almost the same on all OSs, but not exactly. There are subtleties. For example, events that might be fired a bit differently, drawing of widgets, etc. My experience shows that you have to check on all OSs to be sure that it works as it should, especially if you are doing more complex UI rendering. In many cases I had to do some fine tuning to get it right. It is not a great deal of effort, but it should be considered.
Another issue is working with the file system. For example, make sure you are composing files paths correctly. It is always a good idea to test that part as well.
Eclipse plugins are platform independent (you are writing them in Java), unless your plugin requires some low-level calls to the operating system (i.e. JNI) or to invoke some tool found only in the Linux OS.
The only part of Eclipse tied - in part - to the OS is the SWT toolkit, since it's optimized for the graphic environment you are running it, but if Eclipse can run in the OS you are interested in, you should not be bothered by this.