logically weird loop

[fir]

i coded soem roguelike game loop which gave me
a lot of logical trouble

imagine game has micro turns, thise micro turns are
noted by
int game_time = 0; //styart with microturn 0

if you press a key on keyboard you update variable
of chuman character: character[HUM}.action_end = game_time+300
then the not human bits should execute in thise microturns
until you reacg turn 300 then you need to read keyboard again

what work is terribly weird, maybe becouse i started
with while loop and while loops from my experience
im not sure but imo tent do be logically heavy problematic
form tiem to time..what work is

void ProcessMicroturnsUntilHuman()
{
if( game_time < character[HUM].action_end)
{
while(game_time < character[HUM].action_end)
{
DispatchActions();
game_time++;
}
if(game_time == character[HUM].action_end) //**
DispatchActions();
}

}

is there some more proper form of this loop?
(the line nioted by ** i know is not needed but
overally this loop is weird imo

[fir]

Post by fir
not human bits should execute in thise microturns
until you reacg turn 300 then you need to read

*bots

im not sure if i not overcomplicate this rogualike base
as i diviede each action as a command like 'move' 'wait'
'cut tree' and mark the time in future where it will be ended
- then on the second part i finalize this action (like replace
the bot on map)

it makes things noticably more complex but when one character meets
other character it can reaad in what state of 'doing' something
the first one is ant it gives possibility of better interactions

my older experiences should tell me it is needed though im not sure
as i dont touched roguelike koding ofr long years

[Janis Papanagnou]

Post by fir
i coded soem roguelike game loop which gave me
a lot of logical trouble
imagine game has micro turns, thise micro turns are
noted by
int game_time = 0; //styart with microturn 0
if you press a key on keyboard you update variable
of chuman character: character[HUM}.action_end = game_time+300
then the not human bits should execute in thise microturns
until you reacg turn 300 then you need to read keyboard again
what work is terribly weird, maybe becouse i started
with while loop and while loops from my experience
im not sure but imo tent do be logically heavy problematic
form tiem to time..what work is

While loops are no more problematic than any other standard
control structure with as simple an operational semantics.

Post by fir
void ProcessMicroturnsUntilHuman()
{
if( game_time < character[HUM].action_end)
{
while(game_time < character[HUM].action_end)
{
DispatchActions();
game_time++;
}
if(game_time == character[HUM].action_end) //**
DispatchActions();
}
}

(I recall to have seem exactly such a code pattern (i.e. the
'if <', 'while <', 'if =') about 40 years ago in an university
exercise, so I suppose that structure is an effect of a valid
algorithm structure property. - But that just aside. It may
soothe you.)

What I really suggest - and sorry for not literally answering
your question - is to implement (for your roguelike) an event
queue where you schedule not only your human player's actions,
but also the monsters, and other timed events in the game. I'm
aware that this might mess up your plans but I think it will
pay to have a cleaner "simulation structure", also with better
decoupling properties.[*]

Post by fir
is there some more proper form of this loop?
(the line nioted by ** i know is not needed but
overally this loop is weird imo

It looks not nice, indeed. But code structure follows demands.
And, at first glance, I see no better structural variant with
loops and conditionals.

Janis


[*] A friend of mine just recently implemented the code frame
for a roguelike and followed the suggestion of an event based
object-oriented implementation; it worked well, he told me.

[fir]

Post by Janis Papanagnou

Post by fir
i coded soem roguelike game loop which gave me
a lot of logical trouble
imagine game has micro turns, thise micro turns are
noted by
int game_time = 0; //styart with microturn 0
if you press a key on keyboard you update variable
of chuman character: character[HUM}.action_end = game_time+300
then the not human bits should execute in thise microturns
until you reacg turn 300 then you need to read keyboard again
what work is terribly weird, maybe becouse i started
with while loop and while loops from my experience
im not sure but imo tent do be logically heavy problematic
form tiem to time..what work is

While loops are no more problematic than any other standard
control structure with as simple an operational semantics.

Post by fir
void ProcessMicroturnsUntilHuman()
{
if( game_time < character[HUM].action_end)
{
while(game_time < character[HUM].action_end)
{
DispatchActions();
game_time++;
}
if(game_time == character[HUM].action_end) //**
DispatchActions();
}
}

(I recall to have seem exactly such a code pattern (i.e. the
'if <', 'while <', 'if =') about 40 years ago in an university
exercise, so I suppose that structure is an effect of a valid
algorithm structure property. - But that just aside. It may
soothe you.)

this solo looks weird imo

while(game_time < character[HUM].action_end)
{
DispatchActions();
game_time++;
}
DispatchActions();

the fact that you need add a thing outside the while loop which is
logically part of this loop.. i eman game_time after that must be
character[HUM].action_end and the DispatchActions(); need to be called
for that value too

this looks sorta unnatural and my game not worked correctly until i find
i must add that final DispatchActions();
it means imo that this while loop is here not natural and being not
natural it makes you probles when you need to debug (and even debug
sorta hard) why this logic dont work

also i must also add the previous if
it is if( game_time < character[HUM].action_end) {}
to not allow all this code to re-enter when it finally
reaches game_time == character[HUM].action_end

its all weird and unnatural..but is logically not easy to find better
way (though i not thinked on this too much only noticed this is kinda
weird imo, and i thing its baddly writen here)

Post by Janis Papanagnou
What I really suggest - and sorry for not literally answering
your question - is to implement (for your roguelike) an event
queue where you schedule not only your human player's actions,
but also the monsters, and other timed events in the game. I'm
aware that this might mess up your plans but I think it will
pay to have a cleaner "simulation structure", also with better
decoupling properties.[*]

Post by fir
is there some more proper form of this loop?
(the line nioted by ** i know is not needed but
overally this loop is weird imo

It looks not nice, indeed. But code structure follows demands.
And, at first glance, I see no better structural variant with
loops and conditionals.
Janis
[*] A friend of mine just recently implemented the code frame
for a roguelike and followed the suggestion of an event based
object-oriented implementation; it worked well, he told me.

[fir]

Post by fir

Post by Janis Papanagnou

Post by fir
i coded soem roguelike game loop which gave me
a lot of logical trouble
imagine game has micro turns, thise micro turns are
noted by
int game_time = 0; //styart with microturn 0
if you press a key on keyboard you update variable
of chuman character: character[HUM}.action_end = game_time+300
then the not human bits should execute in thise microturns
until you reacg turn 300 then you need to read keyboard again
what work is terribly weird, maybe becouse i started
with while loop and while loops from my experience
im not sure but imo tent do be logically heavy problematic
form tiem to time..what work is

While loops are no more problematic than any other standard
control structure with as simple an operational semantics.

Post by fir
void ProcessMicroturnsUntilHuman()
  {
     if( game_time < character[HUM].action_end)
     {
      while(game_time < character[HUM].action_end)
      {
          DispatchActions();
           game_time++;
      }
      if(game_time == character[HUM].action_end)     //**
         DispatchActions();
     }
  }

(I recall to have seem exactly such a code pattern (i.e. the
'if <', 'while <', 'if =') about 40 years ago in an university
exercise, so I suppose that structure is an effect of a valid
algorithm structure property. - But that just aside. It may
soothe you.)

this solo looks weird imo
  while(game_time < character[HUM].action_end)
  {
         DispatchActions();
          game_time++;
  }
  DispatchActions();
the fact that you need add a thing outside the while loop which is
logically part of this loop.. i eman game_time after that must be
character[HUM].action_end and the DispatchActions(); need to be called
for that value too
this looks sorta unnatural and my game not worked correctly until i find
i must add that final   DispatchActions();
it means imo that this while loop is here not natural and being not
natural it makes you probles when you need to debug (and even debug
sorta hard) why this logic dont work
also i must also add the previous if
it is   if( game_time < character[HUM].action_end) {}
to not allow all this code to re-enter when it finally
reaches game_time == character[HUM].action_end
its all weird and unnatural..but is logically not easy to find better
way (though i not thinked on this too much only noticed this is kinda
weird imo, and i thing its baddly writen here)

if someone has a trouble understandong that loop it may substitute
character[HUM].action_end by 300

the loop need to go thru all micro turns/tures from 0 to 300
inclusded and fire the bot 'starters' (where bts have timers on
warious random microturns to act and than put those starters
on some microturns in future)

then imaginee each pressing space turns that 300 up by another 300
and another portion of micro turns is fired/dispatched (im not sure if
the word dispatch is fully proper here (weak english) but maybe)

Post by fir

Post by Janis Papanagnou
What I really suggest - and sorry for not literally answering
your question - is to implement (for your roguelike) an event
queue where you schedule not only your human player's actions,
but also the monsters, and other timed events in the game. I'm
aware that this might mess up your plans but I think it will
pay to have a cleaner "simulation structure", also with better
decoupling properties.[*]

Post by fir
is there some more proper form of this loop?
(the line nioted by ** i know is not needed but
overally this loop is weird imo

It looks not nice, indeed. But code structure follows demands.
And, at first glance, I see no better structural variant with
loops and conditionals.
Janis
[*] A friend of mine just recently implemented the code frame
for a roguelike and followed the suggestion of an event based
object-oriented implementation; it worked well, he told me.

[fir]

Post by fir
void ProcessMicroturnsUntilHuman()
  {
     if( game_time < character[HUM].action_end)
     {
      while(game_time < character[HUM].action_end)
      {
          DispatchActions();
           game_time++;
      }
      if(game_time == character[HUM].action_end)     //**
         DispatchActions();
     }
  }

so the loop code in simplification look like

if( game_time < 300) //this is only to not alllow re-enter the
loop if you reach turn 300
{
while(game_time < 300) //game time starts form 0
{
DispatchActions();
game_time++;
}
DispatchActions(); //this runs for turn 300
}

im not sure if there is no bug here as when i press space and 300
turns into 600 then the dispatch on turn 300 would be executed
second time (?) (though in present state of things it wouldnt spoil
probably the things as dispatch if called on turn 300 starters would
change the values and they woil not fiore twice

but it all show trubles in what should be 'simple' loop

[fir]

Post by fir

Post by fir
void ProcessMicroturnsUntilHuman()
   {
      if( game_time < character[HUM].action_end)
      {
       while(game_time < character[HUM].action_end)
       {
           DispatchActions();
            game_time++;
       }
       if(game_time == character[HUM].action_end)     //**
          DispatchActions();
      }
   }

so the loop code in simplification look like
     if( game_time < 300) //this is only to not alllow re-enter the
loop if you reach turn 300
     {
      while(game_time < 300) //game time starts form 0
      {
          DispatchActions();
           game_time++;
      }
         DispatchActions();  //this runs for turn 300
     }
im not sure if there is no bug here as when i press space and 300
turns into 600 then the dispatch on turn 300 would be executed
second time (?) (though in present state of things it wouldnt spoil
probably the things as dispatch if called on turn 300 starters would
change the values and they woil not fiore twice

after considering that bug it seem that the game_time should always be
increased after this dispatch to disallow making this dispatch twice co
i could maybe just

while(game_time <= character[HUM].action_end)
{
DispatchActions();
game_time++;
}

and on key handler

void ProcessKeyDown(int key)
{
if(game_time>character[HUM].action_end )
{
if(key==VK_LEFT) AddAction(HUM, 'movl', rand2(300,300));
}
}

this roughly seem to work so probbaly this is simply more proper though
i must rethink it yet

Post by fir
but it all show trubles in what should be 'simple' loop

[Lawrence D'Oliveiro]

[*] A friend of mine just recently implemented the code frame for a
roguelike and followed the suggestion of an event based object-oriented
implementation; it worked well, he told me.

The next step would be to use coroutines so the logic of a longer-running
task, which has to wait for other events at multiple points, can be
written in a single linear stream without having to be fragmented into
multiple callbacks.

[Janis Papanagnou]

Post by Lawrence D'Oliveiro

[*] A friend of mine just recently implemented the code frame for a
roguelike and followed the suggestion of an event based object-oriented
implementation; it worked well, he told me.

The next step would be to use coroutines so the logic of a longer-running
task, which has to wait for other events at multiple points, can be
written in a single linear stream without having to be fragmented into
multiple callbacks.

Yes, indeed.

Actually, if you know Simula, coroutines are inherent part of that
language, and they based their yet more advanced process-oriented
model on these. I find it amazing what Simula provided (in 1967!)
to support such things. Object orientation[*], coroutines, etc.,
all fit together, powerful, and in a neat syntactical form. - But
"no one" is using Simula, and my friend was using C++; don't know
what C++ supports in that respect today. I know that he implemented
the "simulation" parts (queuing, time-model, etc.) in C++ himself.

Janis

[*] It was the language who invented Object Orientation - quite
naturally a concept from the simulation perspective -, but they
neither invented nor used the term "OO"; probably because it was
much more than that what they provided.

[fir]

Post by Janis Papanagnou

Post by Lawrence D'Oliveiro

[*] A friend of mine just recently implemented the code frame for a
roguelike and followed the suggestion of an event based object-oriented
implementation; it worked well, he told me.

The next step would be to use coroutines so the logic of a longer-running
task, which has to wait for other events at multiple points, can be
written in a single linear stream without having to be fragmented into
multiple callbacks.

Yes, indeed.
Actually, if you know Simula, coroutines are inherent part of that
language, and they based their yet more advanced process-oriented
model on these. I find it amazing what Simula provided (in 1967!)
to support such things. Object orientation[*], coroutines, etc.,
all fit together, powerful, and in a neat syntactical form. - But
"no one" is using Simula, and my friend was using C++; don't know
what C++ supports in that respect today. I know that he implemented
the "simulation" parts (queuing, time-model, etc.) in C++ himself.
Janis
[*] It was the language who invented Object Orientation - quite
naturally a concept from the simulation perspective -, but they
neither invented nor used the term "OO"; probably because it was
much more than that what they provided.

well i code things myself - no queue just a fileds

long action, action_start, action_end;

(where action is pseudoenum describing the action is
doin by bot in a span of action_start to action_end)

in simply if time raches action_end the action is finalized and new
action is set up.. the arguments to pass i will probably try to be none
i mean tch bot fields would store them)

i will se how it will be going - thsoe are game design decisions and its
sometimes hard to really know what is best before really coding this..so
experuiance will show

though im old and tired and i not quite devoted to coding
anyway..only sometimes i try something to kill some time

[fir]

Post by fir

Post by Janis Papanagnou

Post by Lawrence D'Oliveiro

[*] A friend of mine just recently implemented the code frame for a
roguelike and followed the suggestion of an event based object-oriented
implementation; it worked well, he told me.

The next step would be to use coroutines so the logic of a
longer-running
task, which has to wait for other events at multiple points, can be
written in a single linear stream without having to be fragmented into
multiple callbacks.

Yes, indeed.
Actually, if you know Simula, coroutines are inherent part of that
language, and they based their yet more advanced process-oriented
model on these. I find it amazing what Simula provided (in 1967!)
to support such things. Object orientation[*], coroutines, etc.,
all fit together, powerful, and in a neat syntactical form. - But
"no one" is using Simula, and my friend was using C++; don't know
what C++ supports in that respect today. I know that he implemented
the "simulation" parts (queuing, time-model, etc.) in C++ himself.
Janis
[*] It was the language who invented Object Orientation - quite
naturally a concept from the simulation perspective -, but they
neither invented nor used the term "OO"; probably because it was
much more than that what they provided.

well i code things myself - no queue just a fileds
long action, action_start, action_end;
(where action is pseudoenum describing the action is
doin by bot in a span of action_start to action_end)
in simply if time raches action_end the action is finalized and new
action is set up.. the arguments to pass i will probably try to be none
i mean tch bot fields would store them)
i will se how it will be going - thsoe are game design decisions and its
sometimes hard to really know what is best before really coding this..so
experuiance will show
though im old and tired and i not quite devoted to coding
anyway..only sometimes i try something to kill some time

there is a question qhat would be more logical (prone, suitable) here

for example it is a movement and say takes 200 mikroturns then logicall
would be to not do this as Setup() in turn 0 and finalize(0 in turn 200
but add 1/200 of distance in each turn.. but the rogualike is in
discrete space on tiles so i think setup() and finalize() is probably better

more yet in things like fight ..say one character was Setuping() a hit
which takes like 90 microturns to finalize and the defender could be
able to setup() a shield blocking or something or decide to setup a
hit too

i dont tested it yet but my [previous approach without the actions that
spans in time was much simpler and you only eventually check what last
action of given bot waas bot not which next or current is

some would say tehe simpel would suffice but in fact if soeme want model
more nice system you need that spaning action time imo...sadly the
division of myriads of this actions on setup() and finalize() is worse
to code

[Janis Papanagnou]

Post by fir
there is a question qhat would be more logical (prone, suitable) here
for example it is a movement and say takes 200 mikroturns then logicall
would be to not do this as Setup() in turn 0 and finalize(0 in turn 200
but add 1/200 of distance in each turn.. but the rogualike is in
discrete space on tiles so i think setup() and finalize() is probably better
more yet in things like fight ..say one character was Setuping() a hit
which takes like 90 microturns to finalize and the defender could be
able to setup() a shield blocking or something or decide to setup a
hit too
i dont tested it yet but my [previous approach without the actions that
spans in time was much simpler and you only eventually check what last
action of given bot waas bot not which next or current is
some would say tehe simpel would suffice but in fact if soeme want model
more nice system you need that spaning action time imo...sadly the
division of myriads of this actions on setup() and finalize() is worse
to code

My opinion on that...

For a roguelike, don't model it too detailed or too "realistic"; it
happens too often that you're getting lost in unnecessary complexity.

Keep it time-discrete (as you indicated above), define an integer of
sufficient length, don't use numeric types with fractions, define a
sensible base unit (that conforms probably to your 1/200 unit).

The start of action is the primary point in time. With "elementary"
actions (place a hit, quaff, read, loot, etc.) it's not worth to
complicate things; just consider the actual environmental situation
of the dungeon installations or individuals that affect your action
in any way.

It is an issue when _long lasting actions_ (like learning spells,
eating, etc.) will get "interrupted". Here I suggest to inspect the
Nethack code (obviously being still the "standard" roguelike), or
have a look into GnollHack (which IMO may have a more sophisticated
way to handle such interrupts). - I've not looked into the code so
I cannot give you concrete information; it's just from observation.

Practically I'd have, for example, an eating character put into a
queue at the time when its eating is supposed to get finished. In
case another actor or event pops in to affect the player (or the
[user-perceivable] environment) the player object will be taken
from the queue, its status (e.g. unfinished food consumption)
updated, and rescheduled. The actual activation-time for that may
be immediately (after) the triggering event source, or delayed
(e.g. after gotten hit by sleep or paralysis) to the time it is
required for the effect to wear off.

I think such event-queues on a time-scale makes things more easier
and more consistent to implement.

(I also think that using C for such a task is not the best choice.
C++ at least provides classes to keep things together. - But that
just aside, to not angering the audience too much.)

Janis

REACTIVATE this.player DELAY meal_time (food_item.nutrition)

[fir]

Post by Janis Papanagnou

Post by fir
there is a question qhat would be more logical (prone, suitable) here
for example it is a movement and say takes 200 mikroturns then logicall
would be to not do this as Setup() in turn 0 and finalize(0 in turn 200
but add 1/200 of distance in each turn.. but the rogualike is in
discrete space on tiles so i think setup() and finalize() is probably better
more yet in things like fight ..say one character was Setuping() a hit
which takes like 90 microturns to finalize and the defender could be
able to setup() a shield blocking or something or decide to setup a
hit too
i dont tested it yet but my [previous approach without the actions that
spans in time was much simpler and you only eventually check what last
action of given bot waas bot not which next or current is
some would say tehe simpel would suffice but in fact if soeme want model
more nice system you need that spaning action time imo...sadly the
division of myriads of this actions on setup() and finalize() is worse
to code

My opinion on that...
For a roguelike, don't model it too detailed or too "realistic"; it
happens too often that you're getting lost in unnecessary complexity.
Keep it time-discrete (as you indicated above), define an integer of
sufficient length, don't use numeric types with fractions, define a
sensible base unit (that conforms probably to your 1/200 unit).
The start of action is the primary point in time. With "elementary"
actions (place a hit, quaff, read, loot, etc.) it's not worth to
complicate things; just consider the actual environmental situation
of the dungeon installations or individuals that affect your action
in any way.
It is an issue when _long lasting actions_ (like learning spells,
eating, etc.) will get "interrupted". Here I suggest to inspect the
Nethack code (obviously being still the "standard" roguelike), or
have a look into GnollHack (which IMO may have a more sophisticated
way to handle such interrupts). - I've not looked into the code so
I cannot give you concrete information; it's just from observation.
Practically I'd have, for example, an eating character put into a
queue at the time when its eating is supposed to get finished. In
case another actor or event pops in to affect the player (or the
[user-perceivable] environment) the player object will be taken
from the queue, its status (e.g. unfinished food consumption)
updated, and rescheduled. The actual activation-time for that may
be immediately (after) the triggering event source, or delayed
(e.g. after gotten hit by sleep or paralysis) to the time it is
required for the effect to wear off.
I think such event-queues on a time-scale makes things more easier
and more consistent to implement.
(I also think that using C for such a task is not the best choice.
C++ at least provides classes to keep things together. - But that
just aside, to not angering the audience too much.)
Janis
REACTIVATE this.player DELAY meal_time (food_item.nutrition)

well im somewhat experienced in writing roguelike (never make some
finished but i wrote them i dont know in sum maybe about 3-4 months day
bay dey

previously i used thsi simpler approach and the conclusion from
experiecne was i need something that stores the action..

bothering bots i dont see as a problem but it is just needed to eb able
to bother them - not for being unable for bother them... i just need a
lot of cases when i could combine warious states for good efects

spells in turn if casted just live on their own loop so they not block
a caster if are casted

[Janis Papanagnou]

Post by fir
well im somewhat experienced in writing roguelike (never make some
finished but i wrote them i dont know in sum maybe about 3-4 months day
bay dey

Yeah, I suspected so; that's why I initially wrote about my suggestion
that "this might mess up your plans".

Post by fir
previously i used thsi simpler approach and the conclusion from
experiecne was i need something that stores the action..
bothering bots i dont see as a problem but it is just needed to eb able
to bother them - not for being unable for bother them... i just need a
lot of cases when i could combine warious states for good efects

I was tempted to suggest, for the implementation details, to (also or
better) try a post in rec.games.roguelike.development but that group
appears to be dead.

Post by fir
spells in turn if casted just live on their own loop so they not block
a caster if are casted

I would have seen a spell-cast (as opposed to learning a spell) as a
single-turn action, but that is of course a design decision.

Janis

[fir]

Post by Janis Papanagnou

Post by fir
well im somewhat experienced in writing roguelike (never make some
finished but i wrote them i dont know in sum maybe about 3-4 months day
bay dey

Yeah, I suspected so; that's why I initially wrote about my suggestion
that "this might mess up your plans".

in fact i coded roguelikes maybe more (maybe up to 6- months day bay day
in sum... its not so little.. as yoiu then got some experience with that

now im fuking out of energy and my whole body makes pain (some health
problems) s i dont even try to finish some but simply toy with some thoughts

Post by Janis Papanagnou

Post by fir
previously i used thsi simpler approach and the conclusion from
experiecne was i need something that stores the action..
bothering bots i dont see as a problem but it is just needed to eb able
to bother them - not for being unable for bother them... i just need a
lot of cases when i could combine warious states for good efects

I was tempted to suggest, for the implementation details, to (also or
better) try a post in rec.games.roguelike.development but that group
appears to be dead.

Post by fir
spells in turn if casted just live on their own loop so they not block
a caster if are casted

I would have seen a spell-cast (as opposed to learning a spell) as a
single-turn action, but that is of course a design decision.
Janis

design is especially important as to program like rogualike..becouse the
game is not "fluid" but lives on tiles and also time interactions need
to be designed its maybe not primarely important if it is simpler
scenario or more complex but the very important is the design to be
"inherently coherent"

[Lawrence D'Oliveiro]

Post by Janis Papanagnou
Actually, if you know Simula, coroutines are inherent part of that
language, and they based their yet more advanced process-oriented model
on these. I find it amazing what Simula provided (in 1967!) to support
such things. Object orientation[*], coroutines, etc., all fit together,
powerful, and in a neat syntactical form.

Wirth did include coroutines in Modula-2. And a kind of object orientation
in Oberon, I think it was.

But these are (nowadays) called “stackful” coroutines -- because a control
transfer to another coroutine can happen at any routine call, each
coroutine context needs a full-sized stack, just like a thread.

There is this newer concept of “stackless” coroutines -- not that they
have no stack, but they need less of it, since a control transfer to
another coroutine context can only happen at the point of an “await”
construct, and these are only allowed in coroutine functions, which are
declared “async”. I think Microsoft pioneered this in C♯, but it has since
been copied into JavaScript, Python and other languages.

Yes, Simula pioneered OO. But the concept has gone in different directions
since then. For example, multiple inheritance, metaclasses and classes as
objects -- all things that Python supports.

[Janis Papanagnou]

Post by Lawrence D'Oliveiro

Post by Janis Papanagnou
Actually, if you know Simula, coroutines are inherent part of that
language, and they based their yet more advanced process-oriented model
on these. I find it amazing what Simula provided (in 1967!) to support
such things. Object orientation[*], coroutines, etc., all fit together,
powerful, and in a neat syntactical form.

Wirth did include coroutines in Modula-2. And a kind of object orientation
in Oberon, I think it was.
But these are (nowadays) called “stackful” coroutines -- because a control
transfer to another coroutine can happen at any routine call, each
coroutine context needs a full-sized stack, just like a thread.

Simula has also in objects own PCs (Program Counters) to enable each
object to be interrupted and resumed. Can't tell about Modula-2 and
Oberon, but I suppose they adopted quite some things from Simula, as
C++ and other languages adopted Simula concepts.

Post by Lawrence D'Oliveiro
There is this newer concept of “stackless” coroutines -- not that they
have no stack, but they need less of it, since a control transfer to
another coroutine context can only happen at the point of an “await”
construct, and these are only allowed in coroutine functions, which are
declared “async”. I think Microsoft pioneered this in C♯, but it has since
been copied into JavaScript, Python and other languages.

Not surprising that good concepts were adopted in other languages,
and expanded by own ideas. Rather it surprised me that some basic
IMO necessities were not; e.g. that C++ had no garbage collection
but Simula (and other languages) already had it long ago.

Post by Lawrence D'Oliveiro
Yes, Simula pioneered OO. But the concept has gone in different directions
since then. For example, multiple inheritance, metaclasses and classes as
objects -- all things that Python supports.

Of course evolution will influence development of future languages,
and they may deviate or may also take new directions. Individual
language design decisions were arguable, though; I recall disputes
concerning, e.g., multiple inheritance (which is not necessary but
significantly complicates an OO language) or that "everything must
be an object" to qualify as "real" OOL, and so on. I don't want to
start or continue these discussions here. Personally I found e.g.
C++'s multiple inheritance useful; that was a language I actually
used professionally. I also find it not very surprising if Python,
a quarter centenary after Simula, supports concepts (sensible or
not) that Simula didn't have. What I find impressive [in Simula]
is not only the new "OO" modeling concept but also how all their
software patterns fit together (the already mentioned coroutines,
or the prefix blocks; just for example to make clear what I mean).
As a pioneering language, as you rightly classify it, Simula had
no paragon for many things that it invented in an impressive way.

Janis

[Michael S]

On Fri, 22 Nov 2024 00:04:32 -0000 (UTC)

Post by Lawrence D'Oliveiro

Post by Janis Papanagnou
Actually, if you know Simula, coroutines are inherent part of that
language, and they based their yet more advanced process-oriented
model on these. I find it amazing what Simula provided (in 1967!)
to support such things. Object orientation[*], coroutines, etc.,
all fit together, powerful, and in a neat syntactical form.

Wirth did include coroutines in Modula-2. And a kind of object
orientation in Oberon, I think it was.
But these are (nowadays) called “stackful” coroutines -- because a
control transfer to another coroutine can happen at any routine call,
each coroutine context needs a full-sized stack, just like a thread.
There is this newer concept of “stackless” coroutines -- not that
they have no stack, but they need less of it, since a control
transfer to another coroutine context can only happen at the point of
an “await” construct, and these are only allowed in coroutine
functions, which are declared “async”. I think Microsoft pioneered
this in C♯, but it has since been copied into JavaScript, Python and
other languages.

By chance, few days ago I was writing a small GUI panel to present a
status from the hardware board we just finished building. In C#,
because despite me knowing C++ (at least "old" C++) 10 times better
than I know C#, building simple GUI in C# still takes me less time and
the result tends to look better. It was the first time I was doing UDP
in .Net and going through docs I encountered UdpClient.ReceiveAsync
method. Got excited thinking that's exactly what I need to wait for
response from my board while still keeping GUI responsive. But it was
not obvious what exactly this async/await business is about.
Read several articles, including one quite long.
https://devblogs.microsoft.com/dotnet/how-async-await-really-works
More I read, less I understood how it helps me and what's the point.
In particular, handling timeout scenario looked especially ugly.
5-10 hours of reading were 5-12 hours wasted most unproductively.
At the end, just did it good old way by ThreadPool.QueueUserWorkItem()
with everything done synchronously by separate thread. Took me, may be,
two hours, including wrapping my head around Control.BeginInvoke and
Control.Invoke.
So much for innovations.

Post by Lawrence D'Oliveiro
Yes, Simula pioneered OO. But the concept has gone in different
directions since then. For example, multiple inheritance, metaclasses
and classes as objects -- all things that Python supports.

What I read seems to suggest that Smalltalk had bigger influence on
modern twists of OOP. But then, may be Simula influenced Smalltalk?
Anyway, I don't like OOP very much, esp. so the version of it that was
pushed down our throats in late 80s and early 90s.

[fir]

Post by Michael S
On Fri, 22 Nov 2024 00:04:32 -0000 (UTC)

Post by Lawrence D'Oliveiro

Post by Janis Papanagnou
Actually, if you know Simula, coroutines are inherent part of that
language, and they based their yet more advanced process-oriented
model on these. I find it amazing what Simula provided (in 1967!)
to support such things. Object orientation[*], coroutines, etc.,
all fit together, powerful, and in a neat syntactical form.

Wirth did include coroutines in Modula-2. And a kind of object
orientation in Oberon, I think it was.
But these are (nowadays) called “stackful” coroutines -- because a
control transfer to another coroutine can happen at any routine call,
each coroutine context needs a full-sized stack, just like a thread.
There is this newer concept of “stackless” coroutines -- not that
they have no stack, but they need less of it, since a control
transfer to another coroutine context can only happen at the point of
an “await” construct, and these are only allowed in coroutine
functions, which are declared “async”. I think Microsoft pioneered
this in C♯, but it has since been copied into JavaScript, Python and
other languages.

By chance, few days ago I was writing a small GUI panel to present a
status from the hardware board we just finished building. In C#,
because despite me knowing C++ (at least "old" C++) 10 times better
than I know C#, building simple GUI in C# still takes me less time and
the result tends to look better. It was the first time I was doing UDP
in .Net and going through docs I encountered UdpClient.ReceiveAsync
method. Got excited thinking that's exactly what I need to wait for
response from my board while still keeping GUI responsive. But it was
not obvious what exactly this async/await business is about.
Read several articles, including one quite long.
https://devblogs.microsoft.com/dotnet/how-async-await-really-works
More I read, less I understood how it helps me and what's the point.
In particular, handling timeout scenario looked especially ugly.
5-10 hours of reading were 5-12 hours wasted most unproductively.
At the end, just did it good old way by ThreadPool.QueueUserWorkItem()
with everything done synchronously by separate thread. Took me, may be,
two hours, including wrapping my head around Control.BeginInvoke and
Control.Invoke.
So much for innovations.

if yopu pity for 5-10 hours being unproductive tell you boss something
is wrong with him.. maybe start be pity after reading for 2 weeks or
month (where you more soob be bored by this reading) but not 10 hours

such time presure kills work.. its a fact ime the more slow you code the
more faster you code and the more faster you code the more slow you code

Post by Michael S

Post by Lawrence D'Oliveiro
Yes, Simula pioneered OO. But the concept has gone in different
directions since then. For example, multiple inheritance, metaclasses
and classes as objects -- all things that Python supports.

What I read seems to suggest that Smalltalk had bigger influence on
modern twists of OOP. But then, may be Simula influenced Smalltalk?
Anyway, I don't like OOP very much, esp. so the version of it that was
pushed down our throats in late 80s and early 90s.

[fir]

Post by fir

Post by Michael S
On Fri, 22 Nov 2024 00:04:32 -0000 (UTC)

Post by Lawrence D'Oliveiro

Post by Janis Papanagnou
Actually, if you know Simula, coroutines are inherent part of that
language, and they based their yet more advanced process-oriented
model on these. I find it amazing what Simula provided (in 1967!)
to support such things. Object orientation[*], coroutines, etc.,
all fit together, powerful, and in a neat syntactical form.

Wirth did include coroutines in Modula-2. And a kind of object
orientation in Oberon, I think it was.
But these are (nowadays) called “stackful” coroutines -- because a
control transfer to another coroutine can happen at any routine call,
each coroutine context needs a full-sized stack, just like a thread.
There is this newer concept of “stackless” coroutines -- not that
they have no stack, but they need less of it, since a control
transfer to another coroutine context can only happen at the point of
an “await” construct, and these are only allowed in coroutine
functions, which are declared “async”. I think Microsoft pioneered
this in C♯, but it has since been copied into JavaScript, Python and
other languages.

By chance, few days ago I was writing a small GUI panel to present a
status from the hardware board we just finished building. In C#,
because despite me knowing C++ (at least "old" C++) 10 times better
than I know C#, building simple GUI in C# still takes me less time and
the result tends to look better. It was the first time I was doing UDP
in .Net and going through docs I encountered UdpClient.ReceiveAsync
method. Got excited thinking that's exactly what I need to wait for
response from my board while still keeping GUI responsive. But it was
not obvious what exactly this async/await business is about.
Read several articles, including one quite long.
https://devblogs.microsoft.com/dotnet/how-async-await-really-works
More I read, less I understood how it helps me and what's the point.
In particular, handling timeout scenario looked especially ugly.
5-10 hours of reading were 5-12 hours wasted most unproductively.
At the end, just did it good old way by ThreadPool.QueueUserWorkItem()
with everything done synchronously by separate thread. Took me, may be,
two hours, including wrapping my head around Control.BeginInvoke and
Control.Invoke.
So much for innovations.

if yopu pity for 5-10 hours being unproductive tell you boss something
is wrong with him.. maybe start be pity after reading for 2 weeks or
month (where you more soob be bored by this reading) but not 10 hours
such time presure kills work.. its a fact ime the more slow you code the
more faster you code and the more faster you code the more slow you code

i wrotee the half of my furia compiler i got now by a month - and i
consider it fast, only becouse i was doing it slow with no
pressure..with pressure i could do that 2 years probably ;c (honestly i
dont know)

hovever the health problems are worst issue.. becouse now i totally dont
feel like being on month so concentrated to write the second (and easier
i think) part

Post by fir

Post by Michael S

Post by Lawrence D'Oliveiro
Yes, Simula pioneered OO. But the concept has gone in different
directions since then. For example, multiple inheritance, metaclasses
and classes as objects -- all things that Python supports.

What I read seems to suggest that Smalltalk had bigger influence on
modern twists of OOP. But then, may be Simula influenced Smalltalk?
Anyway, I don't like OOP very much, esp. so the version of it that was
pushed down our throats in late 80s and early 90s.

[Tim Rentsch]

Post by Michael S
On Fri, 22 Nov 2024 00:04:32 -0000 (UTC)

Yes, Simula pioneered OO. But the concept has gone in different
directions since then. For example, multiple inheritance, metaclasses
and classes as objects -- all things that Python supports.

What I read seems to suggest that Smalltalk had bigger influence on
modern twists of OOP. But then, may be Simula influenced Smalltalk?

There is no question that Simula had an influence on the development
of Smalltalk; Alan Kay has said as much -

https://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en

But the ideas of object-oriented programming came before Smalltalk
(and also before Simula). It was the ideas underlying object-oriented
programming that influenced the Smalltalk language, not the other way
around. (To be fair here I should add that other factors undoubtedly
influenced Smalltalk as well.)

Post by Michael S
Anyway, I don't like OOP very much, esp. so the version of it that was
pushed down our throats in late 80s and early 90s.

Almost everyone who took Simula and C++ as the archetype for OOP
never understood it.

[Janis Papanagnou]

Post by Tim Rentsch
Almost everyone who took Simula and C++ as the archetype for OOP
never understood it.

LOL.

(Funny [dogmatic] statement, without any substance again.)

Janis

[David Brown]

Post by Janis Papanagnou

Post by Tim Rentsch
Almost everyone who took Simula and C++ as the archetype for OOP
never understood it.

LOL.
(Funny [dogmatic] statement, without any substance again.)

If you take the position that Alan Key, as the person who is credited
with inventing the term "object oriented programming", gets to make the
definition of what OOP is, then Tim's statement is accurate. Originally
OOP meant something very different from how it is interpreted in C++.
(I don't know Simula except by reputation, so I can't comment on that.)

The original idea of OOP was to have self-contained "objects" that
communicated only by passing messages. If object A wanted object B to
do "foo", it would not call "B.foo()" in its own context, as is done in
C++. Instead, it would pass a message "foo" to B. What B does with it,
and when, is up to B. If a return value is expected, then B will send a
message with the answer back to A.

This is, I think, akin to the modern "actor" programming paradigm, and
it has connections back to Hoare's CSP (which has inspired many systems
and languages, most recently Golang). It gives you a robust, modular
system with great scalability - objects can run on different cores or
threads, or different computers connected by a network. Data races and
other concurrency issues are pretty much impossible. Different parts of
the program could be changed at run-time.

Of course, all this has significant overheads - it is not suitable for a
low-level high efficiency language. The rather different idea of OOP
represented by languages like C++ can be very much more efficient, which
is why it caught on.

Perhaps the language that is most true to the original idea is Erlang,
with its "write once, run forever" motto.

[Janis Papanagnou]

Post by David Brown

Post by Tim Rentsch
Almost everyone who took Simula and C++ as the archetype for OOP
never understood it.

If you take the position that Alan Key, as the person who is credited
with inventing the term "object oriented programming", gets to make the
definition of what OOP is, then Tim's statement is accurate. Originally
OOP meant something very different from how it is interpreted in C++. (I
don't know Simula except by reputation, so I can't comment on that.)

(For the topic discussed here I think it would be necessary, or at
least helpful, to know Simula, though.)

Post by David Brown
The original idea of OOP was to have self-contained "objects" that
communicated only by passing messages. If object A wanted object B to
do "foo", it would not call "B.foo()" in its own context, as is done in
C++. Instead, it would pass a message "foo" to B. What B does with it,
and when, is up to B. If a return value is expected, then B will send a
message with the answer back to A.

(see below)

Post by David Brown
This is, I think, akin to the modern "actor" programming paradigm, [...]
Of course, all this has significant overheads - it is not suitable for a
low-level high efficiency language. The rather different idea of OOP
represented by languages like C++ can be very much more efficient, which
is why it caught on.

Right.

Post by David Brown
Perhaps the language that is most true to the original idea is Erlang,
with its "write once, run forever" motto.

To open the knot, concerning this statement and the paragraph above
where you formulate "original idea of OOP", is to make clear what
each of us thinks would be crucial for "OOP".

If the "OO properties" are what at the time the term "OO" was coined
and associated with - which was rather late, as I think - is meant
then it would be a very limited view, focused by the inventor of the
*term* "OO". But the "OO" concepts - AFAICT - existed before the term.

If I look up various Wikipedia entries I find the properties
* Inheritance
* Polymorphism
* Encapsulation
* Abstraction
All of which have (for example) been implemented (besides some other
features that support Object Oriented Programming) already by Simula.

We find statements about separate, collaborating, communicating,
objects, about objects having attributes and "methods" (functions).

We also find statements like:
"Simula introduced important concepts that are today an essential
part of object-oriented programming, such as class and object,
inheritance, and dynamic binding."

Yet I haven't seen anyone who would dissent that Simula had been the
first implemented OO language (released 1967).

My (historic) experience with OO is that most people heard about OO
only in context of Smalltalk (1972) [Alan Kay]. Their specific (but
mostly unnecessarily introduced) terminology became common speech in
that context. And the long existing Simula wasn't even known widely.

As an anecdote: Decades ago there was an "OO expert" (B. Oestereich)
who gave (in the upcoming flourishing OO days of C++) speeches at IT
boards, he wrote books about the topic, gave interviews, and so on.
His first book started with on overview of the OO languages (with
Smalltalk as the root), and its descendants, and where it influenced
other languages. - I sent him a mail pointing to Simula (as being,
if not the root of all, at least the first OO language). Cautiously
he asked me about its features and conceded that his picture was
wrong. - The next edition of his book had that corrected.

And the whole discussion about OO had always mostly been done with
the worn blinkers. B. Stroustrup's mention of Simula in his books
somewhat contributed to get a more open minded view on OO, what it
is, and who has its most merits.

Janis

[Tim Rentsch]

Post by Janis Papanagnou

Post by Lawrence D'Oliveiro

[*] A friend of mine just recently implemented the code frame for a
roguelike and followed the suggestion of an event based object-oriented
implementation; it worked well, he told me.

The next step would be to use coroutines so the logic of a longer-running
task, which has to wait for other events at multiple points, can be
written in a single linear stream without having to be fragmented into
multiple callbacks.

Yes, indeed.
Actually, if you know Simula, coroutines are inherent part of that
language, and they based their yet more advanced process-oriented
model on these. I find it amazing what Simula provided (in 1967!)
to support such things. Object orientation[*], coroutines, etc.,
all fit together, powerful, and in a neat syntactical form. - But
"no one" is using Simula, and my friend was using C++; don't know
what C++ supports in that respect today. I know that he implemented
the "simulation" parts (queuing, time-model, etc.) in C++ himself.
[*] It was the language who invented Object Orientation [...]

No, it wasn't. First, programming in a language with classes and
objects does not imply object-oriented programming. Second, the
underlying ideas of object-oriented programming pre-date Simula 67
by five years or more. That history has been pointed out by
Alan Kay, who is the originator of the term and is responsible
for pioneering the concept.

[Janis Papanagnou]

Post by Tim Rentsch

Post by Janis Papanagnou
Actually, if you know Simula, coroutines are inherent part of that
language, and they based their yet more advanced process-oriented
model on these. I find it amazing what Simula provided (in 1967!)
to support such things. Object orientation[*], coroutines, etc.,
all fit together, powerful, and in a neat syntactical form. - But
"no one" is using Simula, and my friend was using C++; don't know
what C++ supports in that respect today. I know that he implemented
the "simulation" parts (queuing, time-model, etc.) in C++ himself.
[*] It was the language who invented Object Orientation [...]

No, it wasn't. First, programming in a language with classes and
objects does not imply object-oriented programming.

It does not necessarily imply it. But if you'd know some more about
it you might understand that it's the natural way of thinking when
simulating systems' objects, and modeling object structures. Simula
in a natural way provided the platform to program object oriented.
(As said, without coining the term or speaking about "OO".)

Post by Tim Rentsch
Second, the
underlying ideas of object-oriented programming pre-date Simula 67
by five years or more.

Of course the ideas were there before Simula was released in 1967;
the inventors (also publicly) presented their ideas five years ago.

Post by Tim Rentsch
That history has been pointed out by
Alan Kay, who is the originator of the term and is responsible
for pioneering the concept.

Yes, the Simula "OO" pioneers didn't invent the *term* "OO", but they
were (amongst) the first who spread the ideas and the first inventing
a language to model OO and work with the OO concepts that are still
used and implemented in many other OO languages nowadays.

(All the rest is [IMO] no more than dogmatic or marketing.)

If you have some substance on the topic I'm always interested to hear.

Janis

[Tim Rentsch]

Post by Tim Rentsch

Post by Janis Papanagnou
Actually, if you know Simula, coroutines are inherent part of that
language, and they based their yet more advanced process-oriented
model on these. I find it amazing what Simula provided (in 1967!)
to support such things. Object orientation[*], coroutines, etc.,
all fit together, powerful, and in a neat syntactical form. - But
"no one" is using Simula, and my friend was using C++; don't know
what C++ supports in that respect today. I know that he implemented
the "simulation" parts (queuing, time-model, etc.) in C++ himself.
[*] It was the language who invented Object Orientation [...]

No, it wasn't. First, programming in a language with classes and
objects does not imply object-oriented programming.

It does not necessarily imply it. But if you'd know some more about
it you might understand that it's the natural way of thinking when
simulating systems' objects, and modeling object structures. Simula
in a natural way provided the platform to program object oriented.
(As said, without coining the term or speaking about "OO".)

I've been doing object-oriented programming, as explained by Alan
Kay, since the late 1970s. I've written code in Simula 67, three
different versions of Smalltalk, and C++. C++ is a pale shadow
of Simula, and Simula is a pale shadow of Alan Kay's vision of
object-oriented programming. People who think programming in C++
or Simula encourages object-oriented programming don't understand
the term.

Post by Tim Rentsch
Second, the
underlying ideas of object-oriented programming pre-date Simula 67
by five years or more.

Of course the ideas were there before Simula was released in 1967;
the inventors (also publicly) presented their ideas five years ago.

The key ideas underlying object-oriented programming were not done
by the people who developed Simula.

Post by Tim Rentsch
That history has been pointed out by
Alan Kay, who is the originator of the term and is responsible
for pioneering the concept.

Yes, the Simula "OO" pioneers didn't invent the *term* "OO", but they
were (amongst) the first who spread the ideas and the first inventing
a language to model OO and work with the OO concepts that are still
used and implemented in many other OO languages nowadays.

You are confusing programming with classes and objects as being
the same as object-oriented programming. It isn't.

(All the rest is [IMO] no more than dogmatic or marketing.)
If you have some substance on the topic I'm always interested to hear.

Let me offer some stories out of my own experiences.

In the mid 1970s, I listened to Alan Kay teach his class, over two
years, officially titled Philosophy of Computing but unofficially
titled The Alan Kay Mystery Hour. A lot of times I was baffled by
why he was talking about what he was saying, but I understood what
he was saying. At least that's what I thought at the time. I might
add that there was no direct explanation of either the Smalltalk
language or object-oriented programming -- both were mentioned but
pretty much only in passing. My reaction then was mostly that here
is another guy with a favorite language but programming languages
are all basically the same. (I had already been exposed to Simula
before taking Alan's class.)

A year or so after finishing Alan's class, I took a class titled
(IIRC) "Object Oriented Programming", taught by three graduate
students who had worked in Smalltalk (which at the time must have
been Smalltalk 76). The course was basically how to program in
Simula as though it were Smalltalk. I was already proficient in
Simula before starting the class, and had no trouble following
what they were saying, programming-wise. But in one class hour
something interesting happened. Someone asked a question, and
the answer blew my mind. It was an epiphany. Suddenly lots of
the things that Alan had said fell into place; my perspective
had changed. For two years Alan had been talking over my head,
and in fact so far over that I hadn't even realized it.

Later, in the early-to-mid 1980s, I went to graduate school at
the University of North Carolina. While there I had some
conversations with Fred Brooks about (among other things)
object-oriented programming. I tried to give an example that
would let him understand the idea I was trying to explain. I
could see by his reaction that it didn't help; the idea hadn't
gotten across. A year or two later one of the groups in Fred
Brooks's programming projects course (I don't remember the
official title) chose to do their project in Smalltalk. During
the end-of-course review/demonstration, a question about was
asked about changing the behavior of one part of the program
(which had a visual representation so it could be seen as soon as
the change was done). The person demonstrating said the change
could be made in two minutes. When Brooks prompted with "Let's
see", the demonstrator made the change on the spot. That made a
strong impression on Fred Brooks; he looked over at me with an
expression that said "there really is something to what you've
been saying".

That demonstration was possible not because of classes and
objects but because Smalltalk embodies the principles of
object-oriented programming.

[Keith Thompson]

Tim Rentsch <***@z991.linuxsc.com> writes:
[...]

Post by Tim Rentsch
People who think programming in C++
or Simula encourages object-oriented programming don't understand
the term.

Or they use the term differently than you do. Language is not static.

[...]

[Kaz Kylheku]

Post by Keith Thompson
[...]

Post by Tim Rentsch
People who think programming in C++
or Simula encourages object-oriented programming don't understand
the term.

Or they use the term differently than you do. Language is not static.

Obviously, the term they don't understand is "encourages", not
"object-oriented".

[fir]

Post by Lawrence D'Oliveiro

[*] A friend of mine just recently implemented the code frame for a
roguelike and followed the suggestion of an event based object-oriented
implementation; it worked well, he told me.

The next step would be to use coroutines so the logic of a longer-running
task, which has to wait for other events at multiple points, can be
written in a single linear stream without having to be fragmented into
multiple callbacks.

i dont know to much on coroutines (what i knew i forgot as even my
memory this year is terribly bad) or simule bot from some other
reasoning i know thet "call queue" is veru good thing

possibly it may be better or at least equal in thiat coroutines or
what was in simula

in basic call queue it gioes klike this afai

for(int i=0; i<all; i++)
add_queue foo(i);

foo() are storred in queue so then can be run i pseudo parralel
mode at some point

add_queue stores function adress and argument on stack like queue

here in rogualike it would use this time variable also

DoAction(int i)
{
if(character[i].action_end > current_time) return;
// do nothing until time comes

// time has come do something
character[i],action_end += 300;
add_queue DoAction(i); //put yourself on queue


}

StartUp()
{
for(int i=0; i<all; i++) add_queue DoAction(i);

}

// in some code
run_queue // queue may add soem alelemnts but also executed things are
taken out of queue

i guess it should be something like that

[fir]

Post by fir

Post by Lawrence D'Oliveiro

[*] A friend of mine just recently implemented the code frame for a
roguelike and followed the suggestion of an event based object-oriented
implementation; it worked well, he told me.

The next step would be to use coroutines so the logic of a longer-running
task, which has to wait for other events at multiple points, can be
written in a single linear stream without having to be fragmented into
multiple callbacks.

i dont know to much on coroutines (what i knew i forgot as even my
memory this year is terribly bad) or simule bot from some other
reasoning i know thet "call queue" is veru good thing
possibly it may be better or at least equal in thiat coroutines or
what was in simula
in basic call queue it gioes klike this afai
for(int i=0; i<all; i++)
   add_queue foo(i);
foo() are storred in queue so then can be run i pseudo parralel
mode at some point
add_queue stores function adress and argument on stack like queue
here in rogualike it would use this time variable also
 DoAction(int i)
 {
   if(character[i].action_end > current_time) return;
// do nothing until time comes
// time has come do something
  character[i],action_end += 300;
 add_queue DoAction(i); //put yourself on queue
}
StartUp()
{
for(int i=0; i<all; i++) add_queue DoAction(i);
}
// in some code
 run_queue // queue may add soem alelemnts but also executed things are
taken out of queue
i guess it should be something like that

i once said probably call queues should be a god way to do
multithreading becouse say you got a routine that calculates and draw a
vertical line of mandelbrot

for(int i=0; i<1000; i++)
add_queue1 draw_mandelbrot(i);

run_queue1;

as thoise calculations are independant the run_queue may execute queue
(which is table of 1000 pointers and 1000 ints)
pararelly in 1000 threads and its very easy

when items may be dependant soem could add them to queue but also
store some tag (like group number) when eech group is independant versus
other groups so each group could be run separatelly on threads with
knowledge there is no conflict


int group ;
for(int i=0; i<1000; i++)
{
if(bot[i].x<300) group = 1;
else if(bot[i].x>700) group = 2;
else if(bot[i].x>400 && bot[i].x<600) group = 3;
else group = 4;

add_queue1[group] run_bot(i);


}

something like that but with better syntax.. it asumes bots act locally
on map and if are distant 100 distance they will not interract..than
those 4 groups can be run on 4 threads assumning nio collision is possible


something like that

[fir]

Post by fir

Post by Lawrence D'Oliveiro

[*] A friend of mine just recently implemented the code frame for a
roguelike and followed the suggestion of an event based object-oriented
implementation; it worked well, he told me.

The next step would be to use coroutines so the logic of a
longer-running
task, which has to wait for other events at multiple points, can be
written in a single linear stream without having to be fragmented into
multiple callbacks.

i dont know to much on coroutines (what i knew i forgot as even my
memory this year is terribly bad) or simule bot from some other
reasoning i know thet "call queue" is veru good thing
possibly it may be better or at least equal in thiat coroutines or
what was in simula
in basic call queue it gioes klike this afai
for(int i=0; i<all; i++)
    add_queue foo(i);
foo() are storred in queue so then can be run i pseudo parralel
mode at some point
add_queue stores function adress and argument on stack like queue
here in rogualike it would use this time variable also
  DoAction(int i)
  {
    if(character[i].action_end > current_time) return;
// do nothing until time comes
// time has come do something
   character[i],action_end += 300;
  add_queue DoAction(i); //put yourself on queue
}
StartUp()
{
for(int i=0; i<all; i++) add_queue DoAction(i);
}
// in some code
  run_queue // queue may add soem alelemnts but also executed things
are taken out of queue
i guess it should be something like that

 i once said probably call queues should be a god way to do
multithreading becouse say you got a routine that calculates and draw a
vertical line of mandelbrot
for(int i=0; i<1000; i++)
 add_queue1 draw_mandelbrot(i);
run_queue1;
as thoise calculations are independant the run_queue may execute queue
(which is table of 1000 pointers and 1000 ints)
pararelly in 1000 threads and its very easy
when items may be dependant soem could add them to queue but also
store some tag (like group number) when eech group is independant versus
other groups so each group could be run separatelly on threads with
knowledge there is no conflict
int group ;
for(int i=0; i<1000; i++)
{
if(bot[i].x<300) group = 1;
else if(bot[i].x>700) group = 2;
else if(bot[i].x>400 && bot[i].x<600) group = 3;
else group = 4;
add_queue1[group] run_bot(i);
}

now its an error becouse when gorups 1 2 3 could run in parralel group 4
can not (but someteimes when i post something i see an error but not
bother to correct as its seen)

but becouse this is error it shows that eventually something more
could or shoudl be used than raw number of groups to encode a group
dependancy (like 4 can be executed after 1,2,3..but im not sure as for now

this queue hovever as i already said seem to me probably the most
conveniant way to d multithreading in c (some extended c) -
simply you feel queue and compiler or system simply runs it and it knows
the marked things are independant... so you get easy and cklear on code
side and easy and clear on hardware side

something like that but with better syntax.. it asumes bots act locally
on map and if are distant 100 distance they will not interract..than
those 4 groups can be run on 4 threads assumning nio collision is possible
something like that