> On Wed, Jul 05, 2023 at 03:28:54PM +0200, felix.winkelm...@bevuta.com wrote:
> > The first patch provides the event-queue mechanism and cleans up the
> > scheduler a bit (hiding internal variables while also exposing ##sys#...
> > procedures to access them). This also defines hooks that a
On Thu, Jul 06, 2023 at 02:51:43PM +0200, felix.winkelm...@bevuta.com wrote:
> That is indeed a shortcoming of the API. I must say that I'm not
> too keen on the "guardian" approach, though, or your suggested hacky
> workaround. There would be too many meanings attached to the
> argument for the
On Wed, Jul 05, 2023 at 03:28:54PM +0200, felix.winkelm...@bevuta.com wrote:
> The first patch provides the event-queue mechanism and cleans up the
> scheduler a bit (hiding internal variables while also exposing ##sys#...
> procedures to access them). This also defines hooks that a threading
>
> Perhaps simply we can just return two values? The first a polling
> procedure and the second a procedure to add new objects to the
> finalizer? You can just receive the polling procedure in a
> single-value context and ignore the object-adder if you don't want
> to use it.
That was also my
> On Wed, Jul 05, 2023 at 03:28:54PM +0200, felix.winkelm...@bevuta.com wrote:
> > The first patch provides the event-queue mechanism and cleans up the
> > scheduler a bit (hiding internal variables while also exposing ##sys#...
> > procedures to access them). This also defines hooks that a
On Wed, Jul 05, 2023 at 07:27:43PM +0200, felix.winkelm...@bevuta.com wrote:
> Reported by "acdw": make "tail?" more robust. Also generalizes
> it to accept all types of data, remove unneeded fast path expecting
> proper list argument.
Thanks, pushed!
Cheers,
Peter
signature.asc
Description: