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)

fir wrote:
>
>
> 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)

i can write such basic matrix lke that

#include<stdio.h>
#include "green-fire.h"

int IsInsideFrame(int x, int y)
{
if(x<0|x>=frame_size_x|y<0|y>=frame_size_y) return 0;
return 1;
}
/////////

typedef void (*qp)(int) ;

qp* permament_queue = NULL;
int permament_queue_size = 0;

void permament_queue_resize(int size)
{
permament_queue=(qp*)realloc(permament_queue,
(permament_queue_size=size)*sizeof(qp));
}
void permament_queue_add(qp entry)
{
permament_queue_resize(permament_queue_size+1);
permament_queue[permament_queue_size-1] = entry;
}
void RunPermamentQueue()
{
for(int i=0; i< permament_queue_size; i++) permament_queue[i](i);
}

///////////

struct Agent {int x; int y;};

Agent* agents = NULL;
int agents_size = 0;

void agents_resize(int size)
{
agents=(Agent*)realloc(agents, (agents_size=size)*sizeof(Agent));
}

void agents_add(int x, int y)
{
agents_resize(agents_size+1);
agents[agents_size-1] = {x,y};
}

/////////

extern void AgentEntryPoint(int whom);
void CreateAgent(int x, int y)
{
permament_queue_add(AgentEntryPoint);
agents_add(x,y);
}

///////////////////////////

void AgentEntryPoint(int who)
{

int new_x = agents[who].x + rand2(-1,1);
int new_y = agents[who].y + rand2(-1,1);
if(!IsInsideFrame) return;

SetPixelSafe(agents[who].x, agents[who].y, 0x336633);
agents[who] = {new_x, new_y};
SetPixelSafe(agents[who].x, agents[who].y, 0xffffff);

}

// void DrawAgents()
// {
// for(int i=0; i<agents_size; i++)
// SetPixelSafe(agents[i].x, agents[i].y, 0xffffff);
//
// }

void CreateAgents()
{ static int initialised = 0; if(initialised) return; initialised=1;
for(int i=0; i<100; i++) CreateAgent(100+i*2,100);
}

void MouseMove(int x, int y) {}
void KeyDown(int key) {}

void RunFrame(int n)
{ CreateAgents();

// ClearFrameData(0);

RunPermamentQueue();
// DrawAgents();

}

void OnResize() { }

int main(int argc, char* argv[])
{

RegisterMouseMove( MouseMove );
RegisterKeyDown( KeyDown );
RegisterOnResize( OnResize );
RegisterRunFrame( RunFrame );
SetSleepValue(10);
SetScaleOnResize(1);
SetupWindow4(" MATRIX by fir (spring 2024) ", 10, 10, .9, .9,
300 );

return 0;
}

back then i wanted to make something liek strategic game for this bots
to fight but not get a much idea

some idea could be for example :
1) allow the agents to splity on parts or group into one (say one has
100 points (though this is kinda internal value as each one has always 1
pixel size) but can split out on 100 1point ot 3 x 30 points + one of
10 points and any possible way of dividing and gruping
2) the smaller move faster 1-points are fastest 100-point one is slowest
3) when two enemy ships met the stronger destroys the weaker
4) each one has limited radious of vision
5) they can collect food spred randomly over the map
6) the goal may be to localize enemy base and hit it with say 5 points

meybe something like that could give soem sane rules of "war"
i dont know

the idea is to make something interesting out of this but it not
necessary must be interestuing sadly

On Sat, 06 Apr 2024 16:54:34 +0200, fir wrote:

> for(int i=0; i<10;i++)
> queued f(i);

Other languages have async/await and event-loop APIs. Not something that
will ever come to C.

Lawrence D'Oliveiro wrote:
> On Sat, 06 Apr 2024 16:54:34 +0200, fir wrote:
>
>> for(int i=0; i<10;i++)
>> queued f(i);
>
> Other languages have async/await and event-loop APIs. Not something that
> will ever come to C.
>
buiilt in language?

i know async and event loop form winapi and know it as like that but
this call queue is somewhat different thing and its better imo - its
more like lov level and its better integrated...could or should be on
language level same as stack is

as to coming to c it shouldnt as c shouldnt be changed as c is c,
changing c will make confusion as then you dont know what c is
(only small errors should be changed imo)

On Sun, 07 Apr 2024 11:49:08 +0200, fir wrote:

> Lawrence D'Oliveiro wrote:
>
>> Other languages have async/await and event-loop APIs.
>>
> buiilt in language?

Quiet a few, e.g. Python. It provides a standard event-loop API
<https://docs.python.org/3/library/asyncio.html> which is pluggable with
alternative event loops. For example, every GUI already has its own event
loop: simply give that an asyncio-compatible wrapper, and you have the
concept of “event-loop-agnostic” code, which can run on any asyncio-
compatible event loop.

> this call queue is somewhat different thing and its better imo - its
> more like lov level and its better integrated.

You can build all that on top of an event loop. The nice thing about a
generalized event loop is that the result can coexist with other async
code.

Lawrence D'Oliveiro wrote:
> On Sun, 07 Apr 2024 11:49:08 +0200, fir wrote:
>
>> Lawrence D'Oliveiro wrote:
>>
>>> Other languages have async/await and event-loop APIs.
>>>
>> buiilt in language?
>
> Quiet a few, e.g. Python. It provides a standard event-loop API
> <https://docs.python.org/3/library/asyncio.html> which is pluggable with
> alternative event loops. For example, every GUI already has its own event
> loop: simply give that an asyncio-compatible wrapper, and you have the
> concept of “event-loop-agnostic” code, which can run on any asyncio-
> compatible event loop.
>
>> this call queue is somewhat different thing and its better imo - its
>> more like lov level and its better integrated.
>
> You can build all that on top of an event loop. The nice thing about a
> generalized event loop is that the result can coexist with other async
> code.
>
i know python only slightly but you can write if you say how it looks in
ppython - liek pice of code or something, if you want

i also know a event queue how it looks in winapi - and that would be all
what i know about event queues - but this is osmething different thing
then what i say here

(in fact i say about two things one is this "temporary call queue"
who waorks a bit like stack (in two versions, one thread, and parrallel)
and thsi "permanent queue" which may be used liek host
for agents/agent systems

in winapi in fact the queue works differently aa you only "add" one
pointer: WndProc and yet your app has this loop
GetMessage/DispatchMessage as far as i remember ..so this is like
something more complex ..in fact i dont know if this paradigm would not
be cleaner if there would be no this busy loop but just a registration
of events but i would need to think on this

i like agent paradigm a lot...also the idea of such queues show to ba
good (as there is hope as i said to allow doint multithreading in real
clean/neat way) but i dont know how it realy fits together on low lewel

programming is in a big aextent amtter of composition, when you got good
composition you hav it all clean and nice not a mess where you can
dwell/stick into like is some way probably some codes today are still
into that swamp at least partially

On Mon, 08 Apr 2024 14:55:10 +0200, fir wrote:

> i also know a event queue how it looks in winapi - and that would be all
> what i know about event queues - but this is osmething different thing
> then what i say here

I was talking about an “event loop”. It runs concurrent tasks, to handle
different things like GUI interaction, network communication and so on.
Tasks can communicate with each other, and synchronize on each other, and
so on. But they don’t block each other unnecessarily.