safirsdk / safir-sdk-core Goto Github PK

Convert Sate to use Qt instead of dotnet. This will remove the last dependency to dotnet so that users, for example only interested in C++, don't need to bother with dotnet/mono at all.

Reported by: anderswiden

Original SourceForge Ticket #27: safir/tickets/27

The dose test suite is very susceptible to timing errors, which means that on a slow or virtualized computer we quite often get false errors. Analyzing these errors is quite time consuming, so it would be better to make the suite more stable.

One issue is that currently the test actions are sent as messages or udp multicast messages with a fixed interval of time between them. It would be better to use tcp or acked udp singlecast and make the sequencer wait until the partner says it is okay to continue, i.e. until after the action has been performed.

It should also be possible to specify in the xml file that for a specific action the sequencer does not need to wait.

Reported by: DonOregano

Original SourceForge Ticket #2: safir/tickets/2

Improve the dots parsing.

This includes removal of the dependency to expat and to make it more convenient to use the parsing module in stand-alone tools like the Bume-editor, Doit etc.

Reported by: anderswiden

Original SourceForge Ticket #25: safir/tickets/25

Provide a script that makes it easy to collect all necessary crash dump data, related to SDK Core, from a "tower" installation.
Today the normal installation structure is that SDK Core and the application specific binaries all are located under runtime/bin. Zipping this directory means that project specific information (e.g pdb-files on Windows) could get included in the zip which might be inappropriate in some situations.

Reported by: anderswiden

Original SourceForge Ticket #50: safir/tickets/50

System.Windows.Forms.dll is used by dose_dotnet to display message boxes.
Use panic logging instead.

Reported by: DonOregano

Original SourceForge Ticket #32: safir/tickets/32

ClassDescription::GetParameterIndexFromName probably contains a bug for inherited parameters.
The row: return NumberOfInheritedParameters() + BaseClass()->GetParameterIndexFromName(name);
NumberOfInheritedParameters shouldn't be added to the result.

Solved in revision 1931.

Original ticket opened by Joel Ottosson

Original Sourceforge ticket: https://sourceforge.net/p/safir/tickets/1/

The StartupSynchronizer in lluf_utils has a race condition which may allow multiple processes to call the Create() function!
This can cause all sorts of problems, where multiple process initialize shared memory at the same time etc.

Needs to be fixed in 4.3.10 and 5.0!

Reported by: DonOregano

Original SourceForge Ticket #42: safir/tickets/42

Most parts are already tested in no_ace branch, but among other things the ada interfaces need to be tested.

Reported by: DonOregano

Original SourceForge Ticket #9: safir/tickets/9

Make the XML serialization format to be more in line with a "normal" style.

Reported by: anderswiden

Original SourceForge Ticket #26: safir/tickets/26

The ExitDispatch functionality should be described in the User's Guide.

Reported by: anderswiden

Original SourceForge Ticket #41: safir/tickets/41

Try to mitigate the problems related to the combination of multithreaded apps and shared memory locks.

This might include:
Better handling of signals.
User documentation with descriptions on how apps should be designed.

Reported by: anderswiden

Original SourceForge Ticket #29: safir/tickets/29

xmlada-config -v returns "3.2" instead of "4.1", which is the installed version.

Reported by: DonOregano

Original SourceForge Ticket #13: safir/tickets/13

There is a crash when calling GetQueueSize for the queue that is the "source" of the current callback. This has been observed when calling GetQueueSize in an OnMessage callback.

Note that it hasn't been verified that this problem occurs only when the inquired queue is the same as the dispatch one, it could be that there is a problem when asking any queue in a dispatch callback. Further tests are necessary.

Reported by: anderswiden

Original SourceForge Ticket #40: safir/tickets/40

Tests for file persistence exist in no_ace branch, but we still need to test against database.

Reported by: DonOregano

Original SourceForge Ticket #7: safir/tickets/7

dots_v (the program behind the dobmake command) is implemented in Ada which means that an Ada compilator is necessary in order to build Safir SDK Core from source even when you have no intention to use Ada for your own application code.

Reported by: anderswiden

Original SourceForge Ticket #28: safir/tickets/28

Entities that have been deleted can still be stored in dope in the following cases:

• Dope or the node that dope is running on goes down. While dope is down some entities are deleted by the owner. Dope comes up and starts to store persistent entities, but the deleted ones are still in dope:s store.
• When an entity owner makes a delete in OnInjectedNew the entity is not removed from dope (DeletelByOwner=false).
• When ghosts are removed during a split/join the corresponding entities in dope are not removed. Node1 has entities 1,2 and Node2 has 3,4. Node2 winns and Node1 and Node2 have 3,4 after join, but in dope there is 1,2,3,4 if dope is running on Node1 or an other node that had connection with Node1. This happens because the ghost is deleted implicitly (DeletelByOwner=false in subscription response).

Either something must be done in the special subscription dope is using, or dope must have some sort of garbage collection to remove obsolete entities.

Reported by: DonOregano

Original SourceForge Ticket #46: safir/tickets/46

TimestampOperations::MergeMember() needs to make a predictable choise when the timestamps don't differ. The suggested solution is to look at the member data.

Reported by: DonOregano

Original SourceForge Ticket #48: safir/tickets/48

I shall be possible to call Connection.Dispatch with a maximum time limit for the call.

Reported by: joelottosson

Original SourceForge Ticket #44: safir/tickets/44

Make Safir SDK Core run on the Android platform.

Reported by: anderswiden

Original SourceForge Ticket #24: safir/tickets/24

Running dobmake with added new dou files but without the rebuild flag set fails, at least on linux.
Have not tried on windows.

Reported by: DonOregano

Original SourceForge Ticket #10: safir/tickets/10

A Close followed by an Open may cause dose_main to loose track of the process in the lluf ProcessMonitor, since Close is handled asynchronously and Open is synchronous dose_main may handle them in the wrong order which is okay in all other respects, but will cause the process to drop out of process monitoring if that connection was the only connection in the process.

Reported by: DonOregano

Original SourceForge Ticket #35: safir/tickets/35

Some tests exist in no_ace branch, but more are needed for full coverage.

Reported by: DonOregano

Original SourceForge Ticket #8: safir/tickets/8

Make a separate column for small objects, so that we need fewer reads for the normal case.

Reported by: DonOregano

Original SourceForge Ticket #34: safir/tickets/34

Since dobmake tries to build multiple projects in the same directory there appears to be quite a few data races, where different projects are attempting to modify the same file at the same time.

This should be resolved. Currently all build machines have been set to only have one cpu, so that we avoid multithreading...

Reported by: DonOregano

Original SourceForge Ticket #45: safir/tickets/45

Activities

1. Design and implement a relevant, repeatable and automated benchmark test.
2. Make an analysis of the requirements and performance scenarios imposed by SjöC 3.0 and transform it into performance requirements for the Dob.

Reported by: anderswiden

Original SourceForge Ticket #14: safir/tickets/14

Add a syslog facility to swre_library to allow logging to be directed to the system logs.
A first implementation exists in a branch, but further analysis of system impact is needed.

Reported by: DonOregano

Original SourceForge Ticket #37: safir/tickets/37

See ticket #2

Reported by: DonOregano

Original SourceForge Ticket #38: safir/tickets/38

Check what level of backup is provided by Sourceforge regarding tickets, wiki etc.

The SVN repository on Sourceforge is just a mirror so that is no issue.

Reported by: anderswiden

Original SourceForge Ticket #23: safir/tickets/23

Some paths, for example in dots_generated, tend to get quite long, and when running jenkins it is not that difficult to bump into the 240char file name length limit, which causes builds to fail.
See if the use of boost filesystem 3 has solved this (maybe it uses the wide-interfaces, which do not have this limitation).

Reported by: DonOregano

Original SourceForge Ticket #5: safir/tickets/5

Add support for 64 bit Ada and Java applications.

Reported by: anderswiden

Original SourceForge Ticket #21: safir/tickets/21

We need automatic tests for olib, and they should test both unixodbc and iodbc when run on linux, and MS odbc on windows.
They should also tests all the databases that we support.

Reported by: DonOregano

Original SourceForge Ticket #6: safir/tickets/6

Add a map-like type to the type system. This is probably more useful than the dynamic array type that was the original suggestion.

Reported by: anderswiden

Original SourceForge Ticket #22: safir/tickets/22

RequestInQueue needs to be emptied of responses before the queue is removed in the case of sending one response and then unregistering the handler.

dose_main would like to do this.

Reported by: DonOregano

Original SourceForge Ticket #49: safir/tickets/49

There is something very strange going on with the DOSE_CONN_OR_OUT semaphore in dose_internal Signals.cpp.
When running a Debug build on 32 bit Ubuntu Precise it simply does not work.

Either a compiler bug or some wierd memory corruption seems to be the only explanation.

For example: start dose_main, and then dope_main. They do not seem to connect (in fact adding logging it seems that the DOSE_CONN_OR_OUT semaphore signal does not propagate). Then run a program that just signals the semaphore, and it all works. Very odd...

Reported by: DonOregano

Original SourceForge Ticket #31: safir/tickets/31

See ticket [#2]

Reported by: DonOregano

Original SourceForge Ticket #39: safir/tickets/39

It is not possible to shut down dose_com in a controlled fashion. When dose_main exits all dose_com threads are just left to die randomly.
This could cause a crash on exit or similar.

Reported by: DonOregano

Original SourceForge Ticket #4: safir/tickets/4

We must add testcases for the local context functionality.

Reported by: anderswiden

Original SourceForge Ticket #51: safir/tickets/51

We want the debug info in a separate file on linux release files.

Reported by: DonOregano

Original SourceForge Ticket #18: safir/tickets/18

Do this when boostpro puts up a working 1.50 on their download page.
The one that was there actually installed 32bit instead of 64bit dlls.

Reported by: DonOregano

Original SourceForge Ticket #33: safir/tickets/33

Remove the CHECKED_LOCKS preprocessor symbol and make the lock checks default enabled on debug builds.

This means that we get the lock checks enabled on our automatic tests without further work.
If it turns out to be too much overhead we may have to break it into a different configuration and make the jenkins builds aware of it to get tests to run. But it would be much easier if it worked okay in the debug builds...

Reported by: DonOregano

Original SourceForge Ticket #16: safir/tickets/16

Consider using jom http://qt-project.org/wiki/jom instead of nmake to reduce the complexity of the build script and dobmake.
Unlike nmake jom is capable of running several build jobs at once (like make -j), which would remove the need the fiddling with generation of visual studio solutions for certain projects to speed up builds.
We might be able to use jom straight off for all building on windows.

We probably want to fall back on nmake if jom is not available, but if jom is installed we get the speedup.

Reported by: DonOregano

Original SourceForge Ticket #11: safir/tickets/11

Improve the Dob to better support split/join and system configurations with nodes that have different behaviour regarding connectivity, timing and performance.

These improvements affects the node detection and communication level (dose_com) as well as the split/join functionality.

The first task is to produce a relevant set of requirements.

Reported by: anderswiden

Original SourceForge Ticket #19: safir/tickets/19

For some reason calling a stored procedure with output parameters to mysql needs a different calling convention.
"call procedure(?,?,?)" must be called instead of "{call procedure(?,?,?)}" as suggested in, e.g., http://msdn.microsoft.com/en-us/library/windows/desktop/ms710100(v=vs.85).aspx

If curly-brackets are used the procedure will be called, but output parameters are not correctly set.

Reported by: aminallalou

Original SourceForge Ticket #47: safir/tickets/47

Configure for matrix builds etc.
Use the new svn.

Reported by: DonOregano

Original SourceForge Ticket #12: safir/tickets/12

We want to be able to analyse unexpected Dob crashes.

This makes it possible to find bugs even in released systems at a customer site.

One idea is to use Google breakpad as a foundation for the crash reporting functionality.

Reported by: anderswiden

Original SourceForge Ticket #17: safir/tickets/17

Enable 64 bit builds on Windows. In a first step support only for the C++ and C# interfaces is needed.

Implemented in trunk.

Reported by: anderswiden

Original SourceForge Ticket #20: safir/tickets/20

There is some elaboration error when building with GNAT 2012 on 32 bit win7.

+ Build Release src/dots/dots_ada.ss: 'nmake /NOLOGO'
Setting environment for using Microsoft Visual Studio 2010 x86 tools.
Scanning dependencies of target dots_ada
[100%] Building dots_ada using gnatmake

C:\jenkins\WORKSP~1\WIN7BU~1\Config\Release\label\WIN7-3~1\src\dots\dots_ada.ss\shared\safir-dob-typesystem-object-factory.adb:125:81: info: access to "Create_Object" during elaboration
C:\jenkins\WORKSP~1\WIN7BU~1\Config\Release\label\WIN7-3~1\src\dots\dots_ada.ss\shared\safir-dob-typesystem-object-factory.adb:125:81: info: implicit pragma Elaborate_All for "Safir.Dob.Typesystem.Object" generated

error: elaboration circularity detected
info:    "safir.dob.typesystem.object.factory (body)" must be elaborated before "safir.dob.typesystem.object.factory (body)"
info:       reason: implicit Elaborate_All in unit "safir.dob.typesystem.object.factory (body)"
info:       recompile "safir.dob.typesystem.object.factory (body)" with -gnatwl for full details
info:          "safir.dob.typesystem.object.factory (body)"
info:             must be elaborated along with its spec:
info:          "safir.dob.typesystem.object.factory (spec)"
info:             which is withed by:
info:          "safir.dob.typesystem.object (body)"
info:             which must be elaborated along with its spec:
info:          "safir.dob.typesystem.object (spec)"
info:             which is withed by:
info:          "safir.dob.typesystem.object.factory (body)"

gnatmake: could not bind standalone library dots_ada
NMAKE : fatal error U1077: 'C:\GNAT\2012\bin\gnatmake.EXE' : return code '0x4'
Stop.
NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual Studio 10.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual Studio 10.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
Failure, return code is 2

Reported by: DonOregano

Original SourceForge Ticket #30: safir/tickets/30

For non-array members container proxies are used, but for array members we don't use container proxies. This results in syntax differences.
For non-arrays it is possible to do

obj.member() = 10

but for arrays

obj.array()[3] = 10

does not work, instead you have to do

obj.array()[3].SetVal(10)

Maybe not very important, but it is a bit ugly...

To fix this the ArrayContainer has to be rewritten.

Reported by: DonOregano

Original SourceForge Ticket #3: safir/tickets/3

There is an old, probably unused, subsystem in lluf, lluf_socket_mix.ss, which I would like to remove.
It is an Ada socket wrapper, which we do not maintain, and have never built.

We need to check with Saab if it is used, and if it is not used we should remove it.

Reported by: DonOregano

Original SourceForge Ticket #43: safir/tickets/43

Instead of enabling debug info for release builds maybe we should build the RelWithDebInfo configuration.
I don't know if this causes any unwanted side-effects, though.

Reported by: DonOregano

Original SourceForge Ticket #15: safir/tickets/15