Thursday, October 31, 2019

Lino kernel as a multiprocessing manager?

Just a series of thoughts…

After watching a tutorial about multiprocessing and after looking into the Django source code for the runserver command, I started thinking that Kernel should become a subclass of multiprocessing.Manager (see Managers)

This would clarify the fundamental difference between the Site and the Kernel: in a multiprocessing context there can be several instances of a same Site class, but only one kernel instance.

Hmm… maybe not a Manager but a Listener. See here

Instantiating a Site instance would check whether the “Lino daemon” is already running. Probably using a socket. If the daemon is not yet running, the Site should spawn a daemon in a subprocess, otherwise it would connect to the running daemon. This would also make linod useless because the daemon would run schedule.run_pending().

The listener daemon would be responsible for building the cache and storing global runtime settings like user preferences.

Oops, I forget that both arguments and return values of that daemon must be pickleable. So e.g. discovering actors and actions must remain in every Site instance. The Lino daemon would actually just accept listeners to Django events, and we would extend these events via linod to allother processes?

Hm… still not really clear.

Lino Avanti optimization request

I opened #3311: Johanna asked to have in their table of clients two new columns which show the date of the first meeting and the date of the evaluation test. These dates are stored in the database as trend events (Entwicklungsschritte).

New feature in lino_xl.lib.trends: When the new checkbox TrendStage.subject_column is checked, Lino will add a virtual field to lino_avanti.lib.avanti.Client (which they use as their Plugin.subject_model) which shows the date of the first event (occurrence) of this stage for this client. The columns are not visible by default but the end user can activate them.

This change required a new minor feature in lino.core.fields: VirtualField.wildcard_data_elem. Virtual fields aren’t normally used as wildcard data elements. This new attribute makes it possible to define virtual fields that are wildcard data elements.