34.8
Defect and Failure Analysis of the Bow Visor Structure of the M. V. "Estonia"
by the Laboratory for Materials Technology and Welding
Techniques of the University of the Armed Forces, HamburgAs a further consequence of the finding that the Atlantic lock would only be exposed to excessive loads if the visor hinges had partly or completely failed, the Laboratory for Materials Technology and Welding Techniques of the University of the Armed Forces, Hamburg was instructed to examine the hinge remains which had meanwhile been cut off the visor at Hangö and transported to the Royal Technical Institute (KTH), Stockholm.
The investigation was subsequently extended to the connecting and supporting structural elements between the visor and hull, i.e. in addition to the visor hinges also the visor actuator mountings on D-deck, the side lock locations between visor and hull, the Atlantic lock location between visor and hull and the visor stempost area were examined. The investigations also included a visual examination of the parts cut off the MARE BALTICUM ex DIANA II. The results of the difficult and long lasting examinations, partly carried out at KTH, Stockholm, shall be summarised as follows:(1) The visor stempost
The welds between stempost and shell plating of the visor had failed already during normal service by a spectrum of cyclic loading providing tensile stress at the crack initiation points together with long term corrosive action of seawater after opening of the welds. As a consequence the stempost had not only been separated from the shell plating during normal service but the stempost being a vital part in its load-carrying function was in itself found to be split up into four parts by crack development well before the casualty. The drawing on the next page shows the cracks F1 - F4 of which F1 had penetrated the thickness of the stempost to about 40% and blue paint was found inside the crack. It could be verified that these traces of blue paint originated from penetration of the outside paint into the crack opening at the time the crack had penetrated the stempost already to the extent of about 40% of its thickness.Note: Reference is made to Section 12.5 where the application of ice paint INERTA is explained in January 1994, when the ESTONIA had been in the shipyard for the last time, thus at that time the stempost was already cracked by ca. 40%.
The investigation of fracture F1 - F4 ascertained that all the transverse fracture had started and penetrated from the outside by corrosion assisted fatigue cracking. In addition, fractures F2 and F3 reveal major bending displacements of their flanks, in particular fracture F3 reveals a specific bending angle of about 70° combined with severe bending deformation following the original crack development.
(2) The Atlantic lock
The inspection of the original lug remains recovered from the wreck of the ESTONIA at KTH, Stockholm revealed that the failure of the Atlantic lock took place by rupture of the 3 lugs welded to the forepeak deck of the ferry, viz. at first to their circular welds to the housing/bushing, subsequently in the remaining cross sections by overload shear at about 40° to the mounting plane on forepeak deck, whereby also bending distortion prior to final cracking of the assembly was found.
The visor mating lug was found to be deformed by bending of about 15°-20° to starboard whereby apparently a crack had opened in the weld between the visor bottom plating and a vertical support stiffener.
The bore of this mating lug had an original diameter of 85 mm, however, which was measured to be 91 x 105 mm with an oval deformation towards forward indicating the main force direction to have been aft.Note: This is a confirmation of the structural analysis of the visor by the FE method - see Enclosure 34.2.430 - according to which the force direction at the Atlantic lock was found to be aft as long as the visor hinges were intact.
Another downward bending movement of about 8°-10° was found which indicated forward tilting of the visor bottom prior to the failure of the lock.
Note: This is only possible if the hinges had failed already.
It was further found that the position and shape of the visor's mating lug did not fully comply with the available drawings, thus changes had been made during the life of the vessel.
Further examinations revealed that about 90% of the length of welds between the lugs on the forepeak deck and the bushing/housing had been pre-cracked by fatigue. The crack propagation together with the corrosion showed a similar picture as found on the visor stempost.
In summary of the above it can be concluded that the welding seams between the lugs on the forepeak deck and the bushing/housing as well as the welding seams between when the visor lug and the visor bottom have been considerable pre-cracked by fatigue.
Deformation indicate a sideways and downwards movement of the visor during final failure of the Atlantic lock.(3) The side locks
The starboard lug has been torn off the visor bulkhead in such a way that the crack started at the upper edge of the weld between the lug and the visor plating, then propagation in a downward direction, being inclined to starboard by about 20° against the vertical, leaving a steel tongue at an angle of more than 90° to the bulkhead surface before final separation of the lug from the visor plating.
The port lug location indicates a more vertical down tearing movement during crack propagation without leaving a steel tongue before failure. No detailed investigation of the character of the fractures have been performed nor were the welding seam remains examined.(4) Actuator mountings on B-deck
The starboard actuator was torn off from the supporting B-deck structure, whereby the welds failed first and the vertical stiffeners below the B-deck plating subsequently, leaving strongly deformed steel tongues behind. Inspection of the dismounted port actuator revealed a repair weld in way of the vertical stiffener at a location with possible high stress during the opening procedure. Investigation revealed the fatigue cracked area to cover 50-70% of the total load-carrying area of this weld.(5) Actuator hinges at the visor arms
At a distance of 1300 mm forward of the visor's main hinges the actuator hinges (fastening) were fitted underneath the visor arms and permitted the actuators' sideways movements up to an angle of 15°. No specific structural failures could be found by visual inspection. Severe scratch marks were found with complete removal of the paint at an angle of 8-10° against the horizontal. At the linear forward edges of the lug plates deeper surface damage had been caused as compared to the curved aft edges. It can be concluded that these scratch marks are a result of the cutting process of the lug plates through the forecastle deck plating. The scratch mark inclination of 8°-10° against the visor arm would coincide with a forward rotation of the visor around the Atlantic lock while the lug plates were cutting through the deck structure and the side locks had failed already.(6) The visor hinges
The visor's hinge system design consisted of the starboard and port side hinge arms fabricated from structural platings, with two attached lug plates on each side, carrying support bushings with bronze liners in the respective bore holes. The support bushings were welded to the lug plates with circular fillet welds. The visor hinge lugs were mated by deck hinge fittings, represented by lugs welded to the forecastle deck. The mechanical connection was one bolt on each side. The video image below shows the starboard hinge arm shortly be- fore the accident.
The following picture shows the broken port visor lug plates with the frac-tures A1, A2, A5 and A6.
The outer port side shows a vertical to slightly horizontal bending to port side at the fracture at the lower part of the remaining bore. The inner port side lug and both starboard lugs - see picture below - did not exhibit significant bending deformations. The picture below shows the broken starboard visor lug plates with fractures A3, A4, A7, A8:
The failure of the visor hinges occurred by fractures A1-A8 of the visor lug plates together with the fillet welds to the support bushings. The bolts had been ripped out of the hinges, together with the bushings.
The four visor lug plates revealed various amounts of macroscopic deformation and necking at the fracture locations.
The fractures A1-A4 of the upper locations of the remaining bores were indicating considerable less necking as compared to the lower fractures A5-A8. In particular, the upper fractures A3,A4 of the starboard lugs exhibited only very small fracture edge contractions, yielding substantially identical cross sections of the fractures and the plates as taken from the design drawing. Fracture A4, shows delaminations originating from longitudinally to rolling direction orientated inclusions.
The respective upper fractures of the port side lugs A1, A2 showed visible necking with some reduction of local cross sections. the lower fracture of the outer port side lug A5, was considerable necked representing a typical shear failure.
The lower fractures A6 of both the inner port side and the outer starboard lug A8 were heavily deformed by bending and hammering. As a particular feature, the inner starboard upper fracture A3, was accompanied by numerous secondary cracks. Some of them even penetrated the lug plate in radial direction without significant macroscopic deformation.
The visual investigation of the failed fillet welds between the hinge lugs and the support bushings revealed different cracking modes at the upper and lower fractures of the hinge plates. Close to the upper hinge lug plate fractures, A1-A4, the fillet welds had failed mostly by cracks parallel to either the hinge or the bushing surface.
The cracks propagated also very often below the respective base material surfaces. At the lower fracture areas of the hinge plates A5-A8, the fillet welds seemed to have failed more by a shear fracture of the weld metal, revealing thicknesses between 5 and 7 mm. However, there were also hammering effects on the weld crack surfaces in this area which was more subjected to compression than to tensile stress.
One bushing had been recovered from the wreck while the remaining visor hinge lug plates had been removed from the visor for investigation at the Institut för Hållfasthetslära of KTH, Stockholm.
The fractures and cracks of the upper locations A1-A4 of both the starboard and port side hinge lug plates exhibit ratchet marks and fatigue bench marks which demonstrate the start of fatigue cracking from flame cutting marks in the inner bore of the lugs. This applies also to the lower fracture of the inner starboard lug, A8.
For further identification of the cracking mechanism, a section was removed from the inner starboard upper fracture A3 area containing the above mentioned secondary cracks. As from the metallographic investigation, fig. 46, the cracks developed stepwise and showed side branching with corrosion products being typical for corrosion supported cracking.
The investigation of one of the secondary cracks (A3) revealed numerous smaller secondary cracks also starting from the inner asymmetrically applied deep flame cuts. The formation of respective ratchet marks can be clearly demonstrated at the crack initiation points, which show successive striation marks at various locations of the secondary cracks being created by stepwise crack propagation in radial direction of the visor hinges.
The fatigue cracks of the visor hinge plates did however also initiate from the outer surface of the hinge plates. The inner bore holes of the hinge plates were originally drilled by machining, however, the surfaces visible outside of these areas were noted as having been destroyed by inadequate application of flame cutting.
The fracture of the recovered hinge bushing was fitting to the fracture of the inner starboard hinge lug. It exhibits a gap of about 4-6 mm between lug bore and support bushing. This gap is almost entirely filled with corrosion products, presumably magnetite, which is also found in thick layers at a location where both hinge late and fillet weld failure are represented together with some excess weld metal, see arrow on the picture below which may have provided a local notch effect.
In another cross section, also severe corrosion inside the gap is identified and the surface of the hinge bore and the bushing exhibit a considerable misalignment, which, during welding of the left fillet weld, was overcome by a buffering layer. The misalignment corresponds to asymmetric burning marks, for example of the inner starboard hinge.
For closer investigation only a small part of an adhering fillet weld of the support bushing was available. It included both a full crack of the hinge plate material and a secondary crack close to the weld metal and showed also the flame cut surface of the hinge plate bore hole. While the full crack revealed plastic shear at its flanks, the secondary crack had started from the heat affected flame cut surface and propagated close to the heat affected zone of the weld in radial direction.
Based on the evidence provided by the above investigation, the following conclusions can be drawn:- The fillet welds between the hinge plates and the bushings seem to have partially failed a considerable time before the casualty due to corrosion supported fatigue.
- The partial failure of these fillet welds provided access of seawater to the gap between the hinge plates and the bushings and caused reduction of load carrying capacity of the hinges.
- Both effects facilitated the start and propagation of extensive corrosion fatigue cracking of the hinge plates at another location which occurred also a considerable time before the casualty as demonstrated by the corroded appearance of the fracture of the inner starboard hinge.
- It has to be assumed that the inner starboard hinge may have failed first with only a small macroscopic plastic deformation at the edges of the fracture and without leaving bending of the rest of the hinge plate.
- As the port inner hinge plate was found to be bent to port and plastic necking at the fracture was noted, it has to be assumed that the port hinges failed after the starboard hinges.The above explained investigation of the various parts of the ESTONIA visor system has provided sufficient evidence that the visor hinges, in particular, the starboard hinge lugs, were severely precracked, before the casualty. There is also evidence that the fillet welds between the visor hinge lugs and the support bushings failed due to corrosion assisted fatigue.
In order to determine the required strength assessments, a Finite Element Calculation of the stresses in the above welds was carried out which considered four different directions of loads on the hinge lugs and established the location of the maximum fracture inducing radial stresses in the fillet welds for each direction and for various applied loads. The thickness of the fillet welds were taken as 7 mm.
For example, the normal visor opening procedure created a vertical down force of maximum 375 kN on each hinge lug based on nominal visor weight and respective leverages and resulted in maximum radial stress in the fillet weld found at the location as marked by the circle in the drawing below together with the stress distribution in radial direction. Accordingly the opening procedure would thus create a local radial weld joint stress of 75 N/mm².
It is thus obvious that, during opening of the visor, the location of maximum radial fillet weld stress is found in the same region where fatigue cracking of those fillet welds initiated. However, also the other assumed directions of loads on the visor hinges would provide maximum radial stress locations. In particular, a similar stress range as for the opening procedure would result from an assumed aftwards force on the hinges. Such an aftwards load could have created the conditions for crack initiation and failure of the hinge plates, following the failure of the fillet.
From the present investigation the following conclusions are drawn:- The ESTONIA bow visor system contained considerable amounts of fatigue cracking which was created by dynamic loads during normal service. The visor hinges showed the largest amount of pre-damage, together with the mountings of the hydraulic actuators.
- The failure of the bow visor hinges was initiated by failure of the fillet welds which were vital supporting joints between the visor hinge plates and the supporting bushings.
- The failure of the hinge fillet welds at locations of high stress was initiated by corrosion fatigue a considerable time before the casualty.
- The dynamically loaded hinge plates failed by fatigue cracking and subsequent plastic overloading of the remaining weakened cross sections. The fatigue crack initiation at the hinge plates was favourised by corrosion, reduced load-carrying capacity and burning marks.
- In addition to the visor hinges and the actuator mountings, there were various other pre-damaged locations, in particular, the stempost and the bottom lock area, which may have contributed to overloading of the hinge locations.The complete Report is attached as Enclosure 30.417.


A moment ago i released a new DEV version that fixes, hopefully, the Firefox 30+ bug with BBLog.
I need some test results:
* If you use FF v30+, report if BBLog work again and correct, especially the stored settings
* If you use FF before v30/Chrome/Opera, report if BBLog work still fine and all settings are still saved correctly
There was a need of big changes in the core to fix this issue.
Krayziesoldier
played around a bit and it seems to be working all fine on FF 28.0


The Survivor Expense Tool is designed to give you a look into your finances, so you can
figure out your monthly expenditures, and break the cycle by regaining your financial security.
Using this tool, you'll be able to track and see what your monthly expeditures are, and use this
information to plan for your future and relocation. Enter in your bills, expenses, and keep track of
them right inside the calculator.
Before starting, take a moment to gather any and all bills, expenses, and payments you'll be responsible for.
Use this list to help you figure out what you'll need to keep track of.


{% extends 'layout-lab-3-pregnant.html' %} {% block pageTitle %} Pregnancy - Being pregnant - Food and drink - NHS.UK {% endblock %} {% block beforeContent %} {% from 'details/macro.njk' import details %} {% endblock %} {% block content %} Home Health A to Z Pregnancy Being pregnant Being pregnant Food and drink in pregnancy There are foods to avoid or take care with when you're pregnant, as they might make you ill or harm your baby. Shortcuts Have a healthy diet in pregnancy Food and drink to avoid in pregnancy Can I eat soya products during pregnancy? Should pregnant and breastfeeding women avoid some types of fish? How can I avoid food poisoning during pregnancy? Vitamins, supplements and nutrition in pregnancy Why do I need folic acid in pregnancy? Find health start vitamins services {% endblock %}
Being pregnant
There are foods to avoid or take care with when you're pregnant, as they might make you ill or harm your baby.


AArch64 TAGGED ADDRESS ABI¶
- Authors: Vincenzo Frascino<EMAIL_ADDRESS>Catalin Marinas<EMAIL_ADDRESS>Date: 21 August 2019
This document describes the usage and semantics of the Tagged Address ABI on AArch64 Linux.
1. Introduction¶
On AArch64 the TCR_EL1.TBI0
bit is set by default, allowing
userspace (EL0) to perform memory accesses through 64-bit pointers with
a non-zero top byte. This document describes the relaxation of the
syscall ABI that allows userspace to pass certain tagged pointers to
kernel syscalls.
2. AArch64 Tagged Address ABI¶
From the kernel syscall interface perspective and for the purposes of this document, a “valid tagged pointer” is a pointer with a potentially non-zero top-byte that references an address in the user process address space obtained in one of the following ways:
mmap()
syscall where either:flags have the
MAP_ANONYMOUS
bit set orthe file descriptor refers to a regular file (including those returned by
memfd_create()
) or/dev/zero
brk()
syscall (i.e. the heap area between the initial location of the program break at process creation and its current location).any memory mapped by the kernel in the address space of the process during creation and with the same restrictions as for
mmap()
above (e.g. data, bss, stack).
The AArch64 Tagged Address ABI has two stages of relaxation depending on how the user addresses are used by the kernel:
User addresses not accessed by the kernel but used for address space management (e.g.
mprotect()
,madvise()
). The use of valid tagged pointers in this context is allowed with the exception ofbrk()
,mmap()
and thenew_address
argument tomremap()
as these have the potential to alias with existing user addresses.NOTE: This behaviour changed in v5.6 and so some earlier kernels may incorrectly accept valid tagged pointers for the
brk()
,mmap()
andmremap()
system calls.User addresses accessed by the kernel (e.g.
write()
). This ABI relaxation is disabled by default and the application thread needs to explicitly enable it viaprctl()
as follows:PR_SET_TAGGED_ADDR_CTRL
: enable or disable the AArch64 Tagged Address ABI for the calling thread.The
(unsigned int) arg2
argument is a bit mask describing the control mode used:PR_TAGGED_ADDR_ENABLE
: enable AArch64 Tagged Address ABI. Default status is disabled.
Arguments
arg3
,arg4
, andarg5
must be 0.PR_GET_TAGGED_ADDR_CTRL
: get the status of the AArch64 Tagged Address ABI for the calling thread.Arguments
arg2
,arg3
,arg4
, andarg5
must be 0.
The ABI properties described above are thread-scoped, inherited on clone() and fork() and cleared on exec().
Calling
prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0)
returns-EINVAL
if the AArch64 Tagged Address ABI is globally disabled bysysctl abi.tagged_addr_disabled=1
. The defaultsysctl abi.tagged_addr_disabled
configuration is 0.
When the AArch64 Tagged Address ABI is enabled for a thread, the following behaviours are guaranteed:
All syscalls except the cases mentioned in section 3 can accept any valid tagged pointer.
The syscall behaviour is undefined for invalid tagged pointers: it may result in an error code being returned, a (fatal) signal being raised, or other modes of failure.
The syscall behaviour for a valid tagged pointer is the same as for the corresponding untagged pointer.
A definition of the meaning of tagged pointers on AArch64 can be found in Tagged virtual addresses in AArch64 Linux.
3. AArch64 Tagged Address ABI Exceptions¶
The following system call parameters must be untagged regardless of the ABI relaxation:
prctl()
other than pointers to user data either passed directly or indirectly as arguments to be accessed by the kernel.ioctl()
other than pointers to user data either passed directly or indirectly as arguments to be accessed by the kernel.shmat()
andshmdt()
.brk()
(since kernel v5.6).mmap()
(since kernel v5.6).mremap()
, thenew_address
argument (since kernel v5.6).
Any attempt to use non-zero tagged pointers may result in an error code being returned, a (fatal) signal being raised, or other modes of failure.
4. Example of correct usage¶
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/prctl.h>
#define PR_SET_TAGGED_ADDR_CTRL 55
#define PR_TAGGED_ADDR_ENABLE (1UL << 0)
#define TAG_SHIFT 56
int main(void)
{
int tbi_enabled = 0;
unsigned long tag = 0;
char *ptr;
/* check/enable the tagged address ABI */
if (!prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0))
tbi_enabled = 1;
/* memory allocation */
ptr = mmap(NULL, sysconf(_SC_PAGE_SIZE), PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
if (ptr == MAP_FAILED)
return 1;
/* set a non-zero tag if the ABI is available */
if (tbi_enabled)
tag = rand() & 0xff;
ptr = (char *)((unsigned long)ptr | (tag << TAG_SHIFT));
/* memory access to a tagged address */
strcpy(ptr, "tagged pointer\n");
/* syscall with a tagged pointer */
write(1, ptr, strlen(ptr));
return 0;
}


Welcome to SkinStore!
 SIZE 1oz
$62
QTY
1
2
3
4
5
6
ADD TO CART


Classes | |
| class | ClassLoaderCreationException |
| class | GUIAction |
| class | MoteRelation |
| class | ParseProjectsException |
| class | PluginConstructionException |
| class | RunnableInEDT< T > |
| class | SimulationCreationException |
| class | StartPluginGUIAction |
Public Member Functions | |
| Cooja (JDesktopPane desktop) | |
| void | addMoteHighlightObserver (Observer newObserver) |
| void | deleteMoteHighlightObserver (Observer observer) |
| void | setVisualizedInFrame (boolean visualized) |
| File | getLastOpenedFile () |
| File[] | getFileHistory () |
| void | addToFileHistory (File file) |
| JDesktopPane | getDesktopPane () |
| void | registerMoteType (Class<?extends MoteType > moteTypeClass) |
| void | unregisterMoteTypes () |
| Vector< Class<?extends MoteType > > | getRegisteredMoteTypes () |
| boolean | registerPositioner (Class<?extends Positioner > positionerClass) |
| void | unregisterPositioners () |
| Vector< Class<?extends Positioner > > | getRegisteredPositioners () |
| boolean | registerRadioMedium (Class<?extends RadioMedium > radioMediumClass) |
| void | unregisterRadioMediums () |
| Vector< Class<?extends RadioMedium > > | getRegisteredRadioMediums () |
| void | reparseProjectConfig () throws ParseProjectsException |
| ProjectConfig | getProjectConfig () |
| COOJAProject[] | getProjects () |
| void | showPlugin (final Plugin plugin) |
| void | closeMotePlugins (Mote mote) |
| void | removePlugin (final Plugin plugin, final boolean askUser) |
| Plugin | tryStartPlugin (final Class<?extends Plugin > pluginClass, final Cooja argGUI, final Simulation argSimulation, final Mote argMote) |
| Plugin | startPlugin (final Class<?extends Plugin > pluginClass, final Cooja argGUI, final Simulation argSimulation, final Mote argMote) throws PluginConstructionException |
| void | unregisterPlugin (Class<?extends Plugin > pluginClass) |
| boolean | registerPlugin (final Class<?extends Plugin > pluginClass) |
| void | unregisterPlugins () |
| Plugin | getPlugin (String classname) |
| Plugin | getStartedPlugin (String classname) |
| Plugin[] | getStartedPlugins () |
| JMenu | createMotePluginsSubmenu (Class<?extends Plugin > pluginClass) |
| JMenu | createMotePluginsSubmenu (Mote mote) |
| Simulation | getSimulation () |
| void | setSimulation (Simulation sim, boolean startPlugins) |
| void | doCreateMoteType (Class<?extends MoteType > moteTypeClass) |
| void | doCreateMoteType (Class<?extends MoteType > moteTypeClass, boolean addMotes) |
| boolean | doRemoveSimulation (boolean askForConfirmation) |
| void | doLoadConfig (boolean askForConfirmation, final boolean quick, File configFile, Long manualRandomSeed) |
| void | reloadCurrentSimulation (final boolean autoStart, final long randomSeed) |
| void | reloadCurrentSimulation (boolean autoStart) |
| File | doSaveConfig (boolean askForConfirmation) |
| void | doAddMotes (MoteType moteType) |
| void | doCreateSimulation (boolean askForConfirmation) |
| void | doQuit (boolean askForConfirmation) |
| void | doQuit (boolean askForConfirmation, int exitCode) |
| Simulation | loadSimulationConfig (File file, boolean quick, Long manualRandomSeed) throws UnsatisfiedLinkError, SimulationCreationException |
| Simulation | loadSimulationConfig (Element root, boolean quick, Long manualRandomSeed) throws SimulationCreationException |
| void | saveSimulationConfig (File file) |
| Element | extractSimulationConfig () |
| Collection< Element > | getPluginsConfigXML () |
| boolean | verifyProjects (Collection< Element > configXML, boolean visAvailable) |
| boolean | setPluginsConfigXML (Collection< Element > configXML, Simulation simulation, boolean visAvailable) |
| void | signalMoteHighlight (Mote m) |
| void | addMoteRelation (Mote source, Mote dest) |
| void | addMoteRelation (Mote source, Mote dest, Color color) |
| void | removeMoteRelation (Mote source, Mote dest) |
| MoteRelation[] | getMoteRelations () |
| void | addMoteRelationsObserver (Observer newObserver) |
| void | deleteMoteRelationsObserver (Observer observer) |
| File | createPortablePath (File file) |
| File | createPortablePath (File file, boolean allowConfigRelativePaths) |
| File | restorePortablePath (File file) |
| void | loadQuickHelp (final Object obj) |
Static Public Member Functions | |
| static boolean | isVisualized () |
| static Container | getTopParentContainer () |
| static boolean | isVisualizedInFrame () |
| static URL | getAppletCodeBase () |
| static boolean | isVisualizedInApplet () |
| static void | setLookAndFeel () |
| static Simulation | quickStartSimulationConfig (File config, boolean vis, Long manualRandomSeed) |
| static int | getExternalToolsSettingsCount () |
| static String | getExternalToolsSettingName (int index) |
| static String | getExternalToolsSetting (String name) |
| static String | getExternalToolsSetting (String name, String defaultValue) |
| static String | getExternalToolsDefaultSetting (String name, String defaultValue) |
| static void | setExternalToolsSetting (String name, String newVal) |
| static void | loadExternalToolsDefaultSettings () |
| static void | loadExternalToolsUserSettings () |
| static void | saveExternalToolsUserSettings () |
| static File | findJarFile (File projectDir, String jarfile) |
| static String | getDescriptionOf (Object object) |
| static String | getDescriptionOf (Class<?extends Object > clazz) |
| static String | getAbstractionLevelDescriptionOf (Class<?extends MoteType > clazz) |
| static void | main (String[] args) |
| static boolean | showErrorDialog (final Component parentComponent, final String title, final Throwable exception, final boolean retryAvailable) |
| static File | restoreConfigRelativePath (File configFile, File portable) |
| static void | setProgressMessage (String msg) |
| static void | setProgressMessage (String msg, int type) |
Public Attributes | |
| ClassLoader | projectDirClassLoader |
| File | currentConfigFile = null |
Static Public Attributes | |
| static final String | EXTERNAL_TOOLS_SETTINGS_FILENAME = "/external_tools.config" |
| static final String | EXTERNAL_TOOLS_WIN32_SETTINGS_FILENAME = "/external_tools_win32.config" |
| static final String | EXTERNAL_TOOLS_MACOSX_SETTINGS_FILENAME = "/external_tools_macosx.config" |
| static final String | EXTERNAL_TOOLS_FREEBSD_SETTINGS_FILENAME = "/external_tools_freebsd.config" |
| static final String | EXTERNAL_TOOLS_LINUX_SETTINGS_FILENAME = "/external_tools_linux.config" |
| static final String | EXTERNAL_TOOLS_LINUX_64_SETTINGS_FILENAME = "/external_tools_linux_64.config" |
| static final String | EXTERNAL_TOOLS_USER_SETTINGS_FILENAME = ".cooja.user.properties" |
| static File | externalToolsUserSettingsFile |
| static final String | LOG_CONFIG_FILE = "log4j_config.xml" |
| static String | PROJECT_DEFAULT_CONFIG_FILENAME = null |
| static final String | PROJECT_CONFIG_FILENAME = "cooja.config" |
| static final FileFilter | SAVED_SIMULATIONS_FILES |
| static Properties | defaultExternalToolsSettings |
| static Properties | currentExternalToolsSettings |
Protected Attributes | |
| GUIEventHandler | guiEventHandler = new GUIEventHandler() |
Main file of COOJA Simulator. Typically contains a visualizer for the simulator, but can also be started without visualizer.
This class loads external Java classes (in extension directories), and handles the COOJA plugins as well as the configuration system. If provides a number of help methods for the rest of the COOJA system, and is the starting point for loading and saving simulation configs.
|
inline |
Creates a new COOJA Simulator GUI.
| desktop | Desktop pane |
|
inline |
Add mote highlight observer.
| newObserver | New observer |
Adds directed relation between given motes.
| source | Source mote |
| dest | Destination mote |
Adds directed relation between given motes.
| source | Source mote |
| dest | Destination mote |
| color | The color to use when visualizing the mote relation |
|
inline |
Adds mote relation observer. Typically used by visualizer plugins.
| newObserver | Observer |
|
inline |
Close all mote plugins for given mote.
| mote | Mote |
|
inline |
|
inline |
Tries to convert given file to be "portable". The portable path is either relative to Contiki, or to the configuration (.csc) file.
If this method fails, it returns the original file.
| file | Original file |
|
inline |
Delete mote highlight observer.
| observer | Observer to delete |
|
inline |
Removes mote relation observer. Typically used by visualizer plugins.
| observer | Observer |
|
inline |
Add new mote to current simulation
|
inline |
Creates a new mote type of the given mote type class. This may include displaying a dialog for user configurations.
If mote type is created successfully, the add motes dialog will appear.
| moteTypeClass | Mote type class |
|
inline |
Creates a new mote type of the given mote type class. This may include displaying a dialog for user configurations.
| moteTypeClass | Mote type class |
| addMotes | Show add motes dialog after successfully adding mote type |
|
inline |
Create a new simulation
| askForConfirmation | Should we ask for confirmation if a simulation is already active? |
|
inline |
Load a simulation configuration file from disk
| askForConfirmation | Ask for confirmation before removing any current simulation |
| quick | Quick-load simulation |
| configFile | Configuration file to load, if null a dialog will appear |
|
inline |
Quit program
| askForConfirmation | Should we ask for confirmation before quitting? |
|
inline |
Remove current simulation
| askForConfirmation | Should we ask for confirmation if a simulation is already active? |
|
inline |
Save current simulation configuration to disk
| askForConfirmation | Ask for confirmation before overwriting file |
|
inlinestatic |
Help method that returns the abstraction level description for given mote type class.
| clazz | Class |
|
inlinestatic |
Help method that returns the description for given object. This method reads from the object's class annotations if existing. Otherwise it returns the simple class name of object's class.
| object | Object |
|
inlinestatic |
Help method that returns the description for given class. This method reads from class annotations if existing. Otherwise it returns the simple class name.
| clazz | Class |
|
inline |
|
inlinestatic |
| name | Name of setting |
| defaultValue | Default value |
|
inlinestatic |
| name | Name of setting |
|
inlinestatic |
| name | Name of setting |
| defaultValue | Default value |
|
inlinestatic |
Get name of external tools setting at given index.
| index | Setting index |
|
inlinestatic |
|
inline |
|
inline |
Returns started plugin that ends with given class name, if any.
| classname | Class name |
|
inline |
Returns started plugins config.
|
inline |
Returns the current extension configuration common to the entire simulator.
|
inline |
Returns the current extension directories common to the entire simulator.
|
inline |
|
inline |
|
inline |
|
inline |
|
inline |
Returns started plugin with given class name, if any.
| classname | Class name |
|
inlinestatic |
|
inlinestatic |
Load external tools settings from default file.
|
inlinestatic |
Load user values from external properties file
|
inline |
Load quick help for given object or identifier. Note that this method does not show the quick help pane.
| obj | If string: help identifier. Else, the class name of the argument is used as help identifier. |
|
inline |
Loads a simulation configuration from given file.
When loading Contiki mote types, the libraries must be recompiled. User may change mote type settings at this point.
| file | File to read |
| UnsatisfiedLinkError | If associated libraries could not be loaded |
|
inlinestatic |
Load configurations and create a GUI.
| args | null |
|
inline |
Register new mote type class.
| moteTypeClass | Class to register |
|
inline |
Register a plugin to be included in the GUI.
| pluginClass | New plugin to register |
|
inline |
Register new positioner class.
| positionerClass | Class to register |
|
inline |
Register new radio medium class.
| radioMediumClass | Class to register |
|
inline |
Reload currently configured simulation. Reloading a simulation may include recompiling Contiki.
| autoStart | Start executing simulation when loaded |
| randomSeed | Simulation's next random seed |
|
inline |
Reload currently configured simulation. Reloading a simulation may include recompiling Contiki. The same random seed is used.
| autoStart | Start executing simulation when loaded |
Removes the relations between given motes.
| source | Source mote |
| dest | Destination mote |
|
inline |
Remove a plugin from working area.
| plugin | Plugin to remove |
| askUser | If plugin is the last one, ask user if we should remove current simulation also? |
|
inline |
Builds new extension configuration using current extension directories settings. Reregisters mote types, plugins, positioners and radio mediums. This method may still return true even if all classes could not be registered, but always returns false if all extension directory configuration files were not parsed correctly.
|
inline |
Tries to restore a previously "portable" file to be "absolute". If the given file already exists, no conversion is performed.
| file | Portable file |
|
inlinestatic |
Save external tools user settings to file.
|
inline |
Saves current simulation configuration to given file and notifies observers.
| file | File to write |
|
inlinestatic |
| name | Name of setting |
| newVal | New value |
|
inline |
Starts plugins with arguments in given config.
| configXML | Config XML elements |
| simulation | Simulation on which to start plugins |
|
inline |
Tries to create/remove simulator visualizer.
| visualized | Visualized |
|
inlinestatic |
A simple error dialog with compilation output and stack trace.
| parentComponent | Parent component |
| title | Title of error window |
| exception | Exception causing window to be shown |
| retryAvailable | If true, a retry option is presented |
|
inline |
Show a started plugin in working area.
| plugin | Plugin |
|
inline |
This method can be used by various different modules in the simulator to indicate for example that a mote has been selected. All mote highlight listeners will be notified. An example application of mote highlightinh is a simulator visualizer that highlights the mote.
| m | Mote to highlight |
|
inline |
Unregister all mote type classes.
|
inline |
Unregister a plugin class. Removes any plugin menu items links as well.
| pluginClass | Plugin class |
|
inline |
Unregister all plugin classes
|
inline |
Unregister all positioner classes.
|
inline |
Unregister all radio medium classes.
|
static |
External tools default FreeBSD settings filename.
|
static |
External tools default Linux/Unix settings filename for 64 bit architectures. Tested on Intel 64-bit Gentoo Linux.
|
static |
External tools default Linux/Unix settings filename.
|
static |
External tools default Mac OS X settings filename.
|
static |
External tools configuration.
|
static |
External tools user settings filename.
|
static |
External tools default Win32 settings filename.
|
static |
Logger settings filename.
|
static |
User extension configuration filename.
|
static |
Default extension configuration filename.
|
static |
File filter only showing saved simulations files (*.csc).


MPOC to promote benefits of palm oil in schools, says minister
KUALA LUMPUR, Nov 6 — The Malaysian Palm Oil Council (MPOC) will go to the ground to promote palm oil and its benefits through outreach programmes involving school children, possibly, including it as a co-curriculum programme.
Primary Industries Minister Teresa Kok Suh Sim said the MPOC would sit down, discuss and strategise with headmasters and teachers on how to make this possible.
“This could be a way to defend our commodity from the negative perception of the west. We need to start from the school to educate Malaysians about palm oil,” she told reporters after the launch of the Palm Oil Student Ambassador Programme at Sekolah Jenis Kebangsaan (C) Choong Wen here today.
Kok also presented certificates to Palm Oil Student Ambassador trainers to engage Malaysian students to spread awareness on the palm oil industry’s significance to the nation and unfounded accusations against palm oil, particularly the unfair anti-palm oil campaign by non-governmental organisations in the west.
In the past, she said similar programmes were organised in Sekolah Kebangsaan Taman Desa and SMK Seri Sentosa, and these schools have even put up a palm oil information wall to educate their students.
The programme today was organised by the MPOC to raise awareness among school children on the importance of palm oil.
It also aims to empower students with accurate knowledge on palm oil, instill pride in the nation’s biggest commodity and equip the younger generation with correct information to counter allegations and share knowledge with others. — Bernama


Parse Utils
v0.1a
A library of utilities for writing parsers in C and C++
Main Page
Classes
Files
Class List
Class Index
Class Hierarchy
Class Members
Class Hierarchy
Go to the textual class hierarchy
Generated on Fri Jun 22 2012 12:32:13 for Parse Utils by
1.7.3
All
Classes
Files
Functions
Variables
Typedefs
Friends


Full Name
Number of customers
Average Customer Satisfaction
Last Five Customers
Vincent Williamson
31
90%
95%
Joseph Smith
27
86%
85%
Justin Black
26
79%
90%
Sean Guzman
25
66%
40%
Keith Carter
20
81%
75%
Austin Medina
32
79%
88%
Vincent Williamson
31
68%
72%
Joseph Smith
27
93%
95%


|
2020 Robot Code
|
Static Public Member Functions | |
| static Twist2d | forwardKinematics (double left_wheel_delta, double right_wheel_delta) |
| static Twist2d | forwardKinematics (double left_wheel_delta, double right_wheel_delta, double delta_rotation_rads) |
| static Twist2d | forwardKinematics (Rotation2d prev_heading, double left_wheel_delta, double right_wheel_delta, Rotation2d current_heading) |
| static Pose2d | integrateForwardKinematics (Pose2d current_pose, Twist2d forward_kinematics) |
| static DriveSignal | inverseKinematics (Twist2d velocity) |
Static Private Attributes | |
| static final double | kEpsilon = 1E-9 |
Provides forward and inverse kinematics equations for the robot modeling the wheelbase as a differential drive (with a corrective factor to account for skidding).
|
static |
Forward kinematics using only encoders, rotation is implicit (less accurate than below, but useful for predicting motion)
|
static |
|
static |
|
static |
For convenience, integrate forward kinematics with a Twist2d and previous rotation.
|
static |
|
staticprivate |


I worked in a team at Viasat during summer 2017. Our task was to design an app for Viasat's commercial internet service, Exede. Currently, users only had a website, which was not effective in solving easy problems, such as paying bills or troubleshooting. The goal was to provide an easy experience for customers to quickly access all their internet needs.
that my team had designed. At this stage, the app was to mainly be used as a troubleshooting tool, to help people understand why their internet might not be working.
I joined in time for our first round of user testing. I wrote the interview procedure and questions, conducted and documented the interviews, and recommended design changes.
based of the feedback we received.
After three rounds of testing, with 9 users, We...
Is my favorite because users did not follow a simple task to click a button as we expected them to do. They thought they had to physically unplug/replug the modem. I recommended that we...
I was working on another project trying to use artificial intelligence to cut customer care costs. I was surprised that most of the calls were billing issues that could easily be solved by an intuitive app or website. After creating use case flows, I designed screens that allowed users to easily manage their payment methods, and understand their bills.


Structs
The following structs are available globally.
-
Session variables are accessed and updated with a SessionVar. All registered Session variables of a page are statically accessible by name from the Session struct. A Session variable is shared with all run instances of a session.
See also
SessionDeclaration
Swift
public struct SessionVar
-
The page run receives PageEvent items on events like uploads or errors.
See moreDeclaration
Swift
public struct PageEvent
-
For each registered cookie there is a property with the cookies name in the Cookie struct.
See moreSee also
CookieVarDeclaration
Swift
public struct Cookie
-
For each registered post variable there is a property with the variables name in the Post struct.
See moreSee also
PostVarDeclaration
Swift
public struct Post
-
For each registered get variable there is a property with the variables name in the Get struct.
See moreSee also
GetVarDeclaration
Swift
public struct Get
-
Get variables are accessed and updated with a GetVar. All registered get variables of a page are statically accessible by name from the Get struct.
See moreSee also
GetDeclaration
Swift
public struct GetVar : CustomStringConvertible
-
Post variables are accessed and updated with a PostVar. All registered post variables of a page are statically accessible by name from the Post struct.
See moreSee also
PostDeclaration
Swift
public struct PostVar : CustomStringConvertible
-
PageFileCache is used to cache the result of a page run with a file.
See moreDeclaration
Swift
public struct PageFileCache : StringData
-
Single cookie values are accessed, updated or removed with a CookieVar. All registered cookies of a page are statically accessible by name from the Cookie struct.
See moreSee also
CookieDeclaration
Swift
public struct CookieVar : CustomStringConvertible


This is why I'm Broke
This is a short paragraph
Angelina's
Harvest
Empire
Dominos
Pizza Hut
Angelina's
Harvest
Empire
Dominos
Pizza Hut


What We Do:
LeaderClasses harnesses the world's best career advancement &
leadership development resources to provide you expert knowledge,
practical guidance & actionable insights from extraordinary
leaders & world class institutions.
We provide specialized, affordable, online & offline programs
that are custom crafted to accelerate your career and transform you
into a better & more effective leader.
To facilitate this, LeaderClasses relentlessly tracks and
learns from:
-
100+ Fulltime and Executive Development Programs at Pre-eminent
universities like Harvard, MIT, Yale, Oxford, Stanford, and many
others.
-
Economy and Globalization Enablers like the World Economic
Forum, The Aspen Institute, Brookings, and the Ewing Marion
Kauffman Foundation.
-
50+ High Potential (Hi-Po) & Executive Leadership
Development programs of Top Tier Organisations like Google,
Apple, Amazon, and Microsoft.
-
Thoughts, Actions, & Advice of 500 of the foremost leaders,
visionaries, and pioneers like Ratan Tata, Warren Buffet, and
Dr. Michio Kaku, to name a few.