fir
2024-04-06 14:54:34 UTC
yesterday i got nice remark related to
teh idea of "call queue" i described before
i will maybe remember that idea of call queue is
like that
void foo()
{
for(int i=0; i<10;i++)
queued f(i);
}
f(i) here abowe is not fired but each "call"
just stores a pointer to thsi function and argument
in "queue call" array - and the queue is then run
after the foo ends (or eventually maybe in some other
moment if that would be good) - the queue can be
called in sequential order but also could be
run in parralel covering multithreading in neat
form imo
what i noticed yesterday was like that:
i liek agent systems - i mean as i said also recently
the coding in is in good extent a metter of good coposition
and i find agents potentially as a very nice method
of composition
and here it shows if you have agent system you in fact
need something like call queue but not a temporal like
in those previose examples but permament i mean if
for(int i=0; i<10;i++)
queued f(i);
setups queue for 10 entries (each entry holds
function all) and you will not just execute whole queue
once and remove pointers but just execute it in loop
its good base for agent system
note you got 10 entries (agent update points) here and
each agents eventually could kill itself by removing
its pointer from the queue , also could like spawn
itself (by adding another cpointer to queue, like
increasing queue form 10 to 11 entries and so on)
so it is basic environment for such things as born, die,
spawn etc... i find it interesting..it seem to confirm
that the call queue idea is good and important thing
i started to think how i would write basic agent
system using that..posiibly queue should hold not only
update points but maybe also "state variables" of
given agent? im not sure - this is related
to thing i once wrote on this - imagine some simple
agent like say something which is drawed as a white
pixel on 2d black bitmap screen.. such agents could
be described by some entities (variables) that it has full
right to write by its own code but it also will be
described by some variables that shouldnt be
given for it to freally changed - as agents must
be managed by some "ruler" - and this is a whole side
topic to consider.. (not strictly the topic of
permement queue but somewhat partially also related
if the wuestion is how to design it all)
teh idea of "call queue" i described before
i will maybe remember that idea of call queue is
like that
void foo()
{
for(int i=0; i<10;i++)
queued f(i);
}
f(i) here abowe is not fired but each "call"
just stores a pointer to thsi function and argument
in "queue call" array - and the queue is then run
after the foo ends (or eventually maybe in some other
moment if that would be good) - the queue can be
called in sequential order but also could be
run in parralel covering multithreading in neat
form imo
what i noticed yesterday was like that:
i liek agent systems - i mean as i said also recently
the coding in is in good extent a metter of good coposition
and i find agents potentially as a very nice method
of composition
and here it shows if you have agent system you in fact
need something like call queue but not a temporal like
in those previose examples but permament i mean if
for(int i=0; i<10;i++)
queued f(i);
setups queue for 10 entries (each entry holds
function all) and you will not just execute whole queue
once and remove pointers but just execute it in loop
its good base for agent system
note you got 10 entries (agent update points) here and
each agents eventually could kill itself by removing
its pointer from the queue , also could like spawn
itself (by adding another cpointer to queue, like
increasing queue form 10 to 11 entries and so on)
so it is basic environment for such things as born, die,
spawn etc... i find it interesting..it seem to confirm
that the call queue idea is good and important thing
i started to think how i would write basic agent
system using that..posiibly queue should hold not only
update points but maybe also "state variables" of
given agent? im not sure - this is related
to thing i once wrote on this - imagine some simple
agent like say something which is drawed as a white
pixel on 2d black bitmap screen.. such agents could
be described by some entities (variables) that it has full
right to write by its own code but it also will be
described by some variables that shouldnt be
given for it to freally changed - as agents must
be managed by some "ruler" - and this is a whole side
topic to consider.. (not strictly the topic of
permement queue but somewhat partially also related
if the wuestion is how to design it all)