Recent changes to tickets

#17 Ini-file reader/writer for PSM settings

Nils Paulsson — Sun, 26 Nov 2023 08:44:11 -0000

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

Nils Paulsson — Sun, 26 Nov 2023 08:43:43 -0000

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

#26 A better log solution for the PSM

Nils Paulsson — Sun, 19 Nov 2023 11:12:32 -0000

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

Nils Paulsson — Sun, 19 Nov 2023 11:09:55 -0000

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

Nils Paulsson — Sun, 19 Nov 2023 11:09:55 -0000

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

Nils Paulsson — Sun, 06 Nov 2022 10:32:27 -0000

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

Nils Paulsson — Tue, 30 Nov 2021 19:57:36 -0000

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

Nils Paulsson — Tue, 26 Oct 2021 18:06:53 -0000

status: open --> closed

Benchmark WiKi

Nils Paulsson — Mon, 05 Jul 2021 18:55:31 -0000

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

#19 Configurable object pool sizes

Nils Paulsson — Wed, 02 Jun 2021 21:06:27 -0000

Milestone: 2.0 --> 3.0