Recent changes to tickets

#17 Ini-file reader/writer for PSM settings

2023-11-26T08:44:11.054000Z

Description has changed:

Diff:

--- old
+++ new
@@ -1 +1,3 @@
 Add an existing or write s simple INI-file reader/writer to provide run-time configuration parameters to a PSM. This module is preferably a simple, minimalistic implementation, having nothing more than what is needed to only deal with INI-files.
+
+One possible API to integrate is https://github.com/brofield/simpleini

#17 Ini-file reader/writer for PSM settings

2023-11-26T08:43:43.369000Z

One possible API to integrate is https://github.com/brofield/simpleini

#26 A better log solution for the PSM

2023-11-19T11:12:32.099000Z

Description has changed:

Diff:

--- old
+++ new
@@ -1,3 +1,5 @@
-There is a need for a better log solution for the PSM. The current one is just a simplistic message printer, essentially  without any logic for saving to file, supressing repetitive messages, selectable time stamp source, etc. There are quite a few open source libraries that may be a good approach for integration. Also, it turns out that there may be a case for the PSM to be able to generate exceptions. Not as a generic solution for error handling, but as a mean of integrate expected error generation with the testing framework (Catch 2). Catch can catch (hep) exceptions but critical erros such as SIGABRT is not as easy to catch and test by the testing framework. Exceptions as such shall however NOT be elevated to the PIM and there is a very simple reason for that. Exceptions, callbacks, SIG*** are all asynchronous, or of-sequence execution paths. I.e. they break the expected instruction sequence defined by a procedure (i.e. a program). 
+There is a need for a better log solution for the PSM. The current one is just a simplistic message printer, essentially  without any logic for saving to file, supressing repetitive messages, selectable time stamp source, etc. There are quite a few open source libraries that may be a good approach for integration. Also, it turns out that there may be a case for the PSM to be able to generate exceptions. Not as a generic solution for error handling, but as a mean of integrate expected error generation with the testing framework (Catch 2). Catch can catch (hep) exceptions but critical erros such as SIGABRT is not as easy to catch and test by the testing framework. Exceptions as such shall however NOT be elevated to the PIM.

-The fundamental computer architecture execution is based on history-preserving procedures. That is the reason we have a stack, a.k.a. a LIFO-queue. Exceptions et al, are not preserving history, but are history agnostic and asynchronous. The PIM already has a solidly defined support for that - The event driven state machiens, which is the same as a FIFO-queue. Thus, if the underlaying PSM need to generate an exception, this shall be converted to an event in the PIM.
+One log-library candidate is https://github.com/SergiusTheBest/plog
+
+Exceptions, callbacks, SIG*** are all asynchronous, or of-sequence execution paths. I.e. they break the expected instruction sequence defined by a procedure (i.e. a program). The fundamental computer architecture execution is based on history-preserving procedures. That is the reason we have a stack, a.k.a. a LIFO-queue. Exceptions et al, are not preserving history, but are history agnostic and asynchronous. The PIM already has a solidly defined support for that - The event driven state machiens, which is the same as a FIFO-queue. Thus, if the underlaying PSM need to generate an exception, this shall be converted to an event in the PIM.

A better log solution for the PSM

2023-11-19T11:09:55.076000Z

There is a need for a better log solution for the PSM. The current one is just a simplistic message printer, essentially without any logic for saving to file, supressing repetitive messages, selectable time stamp source, etc. There are quite a few open source libraries that may be a good approach for integration. Also, it turns out that there may be a case for the PSM to be able to generate exceptions. Not as a generic solution for error handling, but as a mean of integrate expected error generation with the testing framework (Catch 2). Catch can catch (hep) exceptions but critical erros such as SIGABRT is not as easy to catch and test by the testing framework. Exceptions as such shall however NOT be elevated to the PIM and there is a very simple reason for that. Exceptions, callbacks, SIG*** are all asynchronous, or of-sequence execution paths. I.e. they break the expected instruction sequence defined by a procedure (i.e. a program).

The fundamental computer architecture execution is based on history-preserving procedures. That is the reason we have a stack, a.k.a. a LIFO-queue. Exceptions et al, are not preserving history, but are history agnostic and asynchronous. The PIM already has a solidly defined support for that - The event driven state machiens, which is the same as a FIFO-queue. Thus, if the underlaying PSM need to generate an exception, this shall be converted to an event in the PIM.

A better log solution for the PSM

2023-11-19T11:09:55.076000Z

Ticket 26 has been modified: A better log solution for the PSM
Edited By: Nils Paulsson (lonfield)
Description updated:
--- description-old

+++ description-new

@@ -1,3 +1,5 @@

-There is a need for a better log solution for the PSM. The current one is just a simplistic message printer, essentially without any logic for saving to file, supressing repetitive messages, selectable time stamp source, etc. There are quite a few open source libraries that may be a good approach for integration. Also, it turns out that there may be a case for the PSM to be able to generate exceptions. Not as a generic solution for error handling, but as a mean of integrate expected error generation with the testing framework (Catch 2). Catch can catch (hep) exceptions but critical erros such as SIGABRT is not as easy to catch and test by the testing framework. Exceptions as such shall however NOT be elevated to the PIM and there is a very simple reason for that. Exceptions, callbacks, SIG*** are all asynchronous, or of-sequence execution paths. I.e. they break the expected instruction sequence defined by a procedure (i.e. a program).
+There is a need for a better log solution for the PSM. The current one is just a simplistic message printer, essentially without any logic for saving to file, supressing repetitive messages, selectable time stamp source, etc. There are quite a few open source libraries that may be a good approach for integration. Also, it turns out that there may be a case for the PSM to be able to generate exceptions. Not as a generic solution for error handling, but as a mean of integrate expected error generation with the testing framework (Catch 2). Catch can catch (hep) exceptions but critical erros such as SIGABRT is not as easy to catch and test by the testing framework. Exceptions as such shall however NOT be elevated to the PIM.

-The fundamental computer architecture execution is based on history-preserving procedures. That is the reason we have a stack, a.k.a. a LIFO-queue. Exceptions et al, are not preserving history, but are history agnostic and asynchronous. The PIM already has a solidly defined support for that - The event driven state machiens, which is the same as a FIFO-queue. Thus, if the underlaying PSM need to generate an exception, this shall be converted to an event in the PIM.
+One log-library candidate is https://github.com/SergiusTheBest/plog
+
+Exceptions, callbacks, SIG*** are all asynchronous, or of-sequence execution paths. I.e. they break the expected instruction sequence defined by a procedure (i.e. a program). The fundamental computer architecture execution is based on history-preserving procedures. That is the reason we have a stack, a.k.a. a LIFO-queue. Exceptions et al, are not preserving history, but are history agnostic and asynchronous. The PIM already has a solidly defined support for that - The event driven state machiens, which is the same as a FIFO-queue. Thus, if the underlaying PSM need to generate an exception, this shall be converted to an event in the PIM.

The QueuedBridgeT use case is ambigious

2022-11-06T10:32:27.763000Z

The template QueuedBridgeT provide a queue. In the case of a distributed bridge it is not clear what the queue shall be used for. On the requiring side there is a need for a dynamic queue to prevent a lock when issuing a new signal between e.g. the ZMQ Request & Reply. On the Providing side it would be good to have a small, but still, queue to reduce the probability for a lock when the provider's scheduler has much to do. Thus, these two use cases are not the same and thus the meaning of a queued bridge is ambuigious.

Add deadlock protection in bridges

2021-11-30T19:57:36.180000Z

When 2 domains are sending signals to each other (in opposit direction) there is a possibility for a deadlock when both FIFO:s (Domain A -> Domain B, Domain B -> Domain A) are full. Add some form of protection to prevent deadlock.

#22 Remove event wrappers

2021-10-26T18:06:53.106000Z

status: open --> closed

Benchmark WiKi

2021-07-05T18:55:31.164000Z

Write a wiki page for benchmark results. Shall cover Intel 6600, AMD Threadripper, Raspberry Pi 4, Raspberry Pi 2.

#19 Configurable object pool sizes

2021-06-02T21:06:27.440000Z

Milestone: 2.0 --> 3.0