oopic-compiler-devel

[Oopic-compiler-devel] Re: [oopic] Re: Oopic compiler issues - The low down.

[D. D. M. <dd...@mc...>]

The more I think about Dan Sandberg's idea, I like it.

The notation of 'background' as an attribute of the routine is essentially
what I was thinking of with my Delphi unit 'sections' approach.

Daniel


----- Original Message -----
From: "scottmsavage" <sms...@ho...>
To: <oo...@ya...>
Sent: Friday, 30 April 2004 10:55
Subject: [oopic] Re: Oopic compiler issues - The low down.


> --- In oo...@ya..., Dan Sandberg <x@c...> wrote:
> > With the THEORETICAL syntax I was mentioning earlier,
> > combined with the kinda of objects that the OOPic
> > already supports, we could do something like this:
> > background void activateSolenoid() {
> >      if ( button.pressed ) {
> >          solenoid = true;
> >          solenoidTimer = 5;
> >          solenoidTimer.operate = true;
> >      }
> > }
> > background void deactiveateSolenoid() {
> >      if ( solenoidTimer.operate and solenoidTimer == 0 ) {
> >          solenoid = false;
> >          solenoidTimer.operate = false;
> >      }
> > }
>
> Yes, I like it and it is really COOL!  But it is not the way the
> OOPic works.  Give me some time and maybe I will be able to figure
> out how to incorporate it.
>
> > Perhaps the root of my confusion is that I don't understand
> > why the code on the OOPic must be so slow.
>
> I am confused.  How did you miss it?  Read this page of the manual:
> http://www.oopic.com/pgchap14.htm
>
> > The OOPic is the only microcontroller I've ever used, so perhaps
> > I am missing something fundamental.
>
> Sounds to me like it is just that you want the OOPic to be something
> it is not.  I think your wish list is a cool idea, but I do not
> think that there is anything on the market right now that works that
> way.
>
> Give me some time and I may be able to change that.
>
> -Scott Savage
>

Re: [Oopic-compiler-devel] Re: [oopic] Re: Oopic compiler issues - The low down.

[Neil D. <nd...@us...>]

> Dan Sandberg wrote:
>> With the THEORETICAL syntax I was mentioning earlier,
>> combined with the kinda of objects that the OOPic
>> already supports, we could do something like this:
>>
>> background void activateSolenoid() {
>>      if ( button.pressed ) {
>>          solenoid = true;
>>          solenoidTimer = 5;
>>          solenoidTimer.operate = true;
>>      }
>> }
>> background void deactiveateSolenoid() {
>>      if ( solenoidTimer.operate and solenoidTimer == 0 ) {
>>          solenoid = false;
>>          solenoidTimer.operate = false;
>>      }
>> }


D. Daniel McGlothin wrote:
> The more I think about Dan Sandberg's idea, I like it.
> 
> The notation of 'background' as an attribute of the routine is essentially
> what I was thinking of with my Delphi unit 'sections' approach.

But what would "background" actually mean to the function?  The OOPic can't
execute these functions in the background, so it could be misleading.

Are you suggesting that basically the above example would translate into an
oWire and an oEvent, triggered by the button press?  If so, then it's a
nice idea, and cleans up the messy way you have to wire up oEvents.

The thing I dislike about this syntax is that the use of "background"
implies that the first statement in the function must be an "if", which
seems a bit kludgey to me.  Unless I'm misunderstanding you.

Another alternative would be to use an "event table", which would work a
bit like the message map system in MFC, if you've used MFC.  Basically
syntax along these lines (either transformed by preprocessor or within the
compiler itself):

EVENT_TABLE
{
    LINK(button.pressed, activateSolenoid)
}

void activateSolenoid()
{
  solenoid = true;
  solenoidT8mer = 5;
  solenoidTimer.operate = true;
}

...which would link "button.pressed" to a function (oEvent handler) called
activateSolenoid.  The first parameter of the LINK macro would be an
attribute of a named object.


The problem is that translating stuff into oEvent handlers will only work
if the "if" clauses can be easily converted into virtual circuits, and so
the whole thing can operate in the "background".  If the "if" clause relies
on scripting language expressions, then it would be non-trivial to make it
an entirely backgrounded piece of code.

Neil
-- 
Neil Durant
<nd...@us...>

Re: [Oopic-compiler-devel] more of 'background' ala Dan Sandberg

[Yahoo J. <Yah...@mc...>]

Neil,

> But what would "background" actually mean to the function?  The OOPic
can't
> execute these functions in the background, so it could be misleading.

The 'background' would be nothing more than a script syntax to clearly
identify that this bit o' script is (part of) a virtual circuit.  Perhaps
another token could be used, such as 'virtual_circuit'.  The thought is to
clearly seperate in the syntax the VC stuff from the slower scripted stuff.
That division would have helped me grasp the VC concept sooner; maybe it
would help others too (I'm recalling Scotts comment that at Trinity
Firefighting none of the OOpics were using VC).

> Are you suggesting that basically the above example would translate into
an
> oWire and an oEvent, triggered by the button press?  If so, then it's a
> nice idea, and cleans up the messy way you have to wire up oEvents.

I'm not sure at all about whether I mean that.  <grin>  I'm a VC novice.

I actually was looking for a possible syntax to seperate VC from the rest.


> The thing I dislike about this syntax is that the use of "background"
> implies that the first statement in the function must be an "if", which
> seems a bit kludgey to me.  Unless I'm misunderstanding you.

Your event_table idea is attractive.

Would there be (asks the VC ignorant guy) situations where a VC would simply
need to be setup and it runs autonomously?  Even then, I suppose that an
.Operate interface might be required/desired.

Daniel




----- Original Message -----
From: "Neil Durant" <nd...@us...>
To: <oop...@li...>
Sent: Wednesday, 05 May 2004 22:31
Subject: Re: [Oopic-compiler-devel] Re: [oopic] Re: Oopic compiler issues -
The low down.


> > Dan Sandberg wrote:
> >> With the THEORETICAL syntax I was mentioning earlier,
> >> combined with the kinda of objects that the OOPic
> >> already supports, we could do something like this:
> >>
> >> background void activateSolenoid() {
> >>      if ( button.pressed ) {
> >>          solenoid = true;
> >>          solenoidTimer = 5;
> >>          solenoidTimer.operate = true;
> >>      }
> >> }
> >> background void deactiveateSolenoid() {
> >>      if ( solenoidTimer.operate and solenoidTimer == 0 ) {
> >>          solenoid = false;
> >>          solenoidTimer.operate = false;
> >>      }
> >> }
>
>
> D. Daniel McGlothin wrote:
> > The more I think about Dan Sandberg's idea, I like it.
> >
> > The notation of 'background' as an attribute of the routine is
essentially
> > what I was thinking of with my Delphi unit 'sections' approach.
>
> But what would "background" actually mean to the function?  The OOPic
can't
> execute these functions in the background, so it could be misleading.
>
> Are you suggesting that basically the above example would translate into
an
> oWire and an oEvent, triggered by the button press?  If so, then it's a
> nice idea, and cleans up the messy way you have to wire up oEvents.
>
> The thing I dislike about this syntax is that the use of "background"
> implies that the first statement in the function must be an "if", which
> seems a bit kludgey to me.  Unless I'm misunderstanding you.
>
> Another alternative would be to use an "event table", which would work a
> bit like the message map system in MFC, if you've used MFC.  Basically
> syntax along these lines (either transformed by preprocessor or within the
> compiler itself):
>
> EVENT_TABLE
> {
>     LINK(button.pressed, activateSolenoid)
> }
>
> void activateSolenoid()
> {
>   solenoid = true;
>   solenoidT8mer = 5;
>   solenoidTimer.operate = true;
> }
>
> ...which would link "button.pressed" to a function (oEvent handler) called
> activateSolenoid.  The first parameter of the LINK macro would be an
> attribute of a named object.
>
>
> The problem is that translating stuff into oEvent handlers will only work
> if the "if" clauses can be easily converted into virtual circuits, and so
> the whole thing can operate in the "background".  If the "if" clause
relies
> on scripting language expressions, then it would be non-trivial to make it
> an entirely backgrounded piece of code.
>
> Neil
> --
> Neil Durant
> <nd...@us...>

Re: [Oopic-compiler-devel] more of 'background' ala Dan Sandberg

[Neil D. <nd...@us...>]

Yahoo Junk wrote:
> Neil,
> 
> > But what would "background" actually mean to the function?  The OOPic
> > can't execute these functions in the background, so it could be
> > misleading.
> 
> The 'background' would be nothing more than a script syntax to clearly
> identify that this bit o' script is (part of) a virtual circuit.  Perhaps
> another token could be used, such as 'virtual_circuit'.  The thought is to
> clearly seperate in the syntax the VC stuff from the slower scripted stuff.
> That division would have helped me grasp the VC concept sooner; maybe it
> would help others too (I'm recalling Scotts comment that at Trinity
> Firefighting none of the OOpics were using VC).

Again, it could be misleading because the code in those 'background'
functions are normal script, and running at normal slow script speed.

Also, suppose you have one of these background functions that gets called
when some virtual circuit triggers an event.  There's nothing to stop you
calling an 'ordinary' function from within that 'background' function,
which blurs the line between the background stuff and the ordinary stuff.

> > Are you suggesting that basically the above example would translate
> > into an oWire and an oEvent, triggered by the button press?  If so,
> > then it's a nice idea, and cleans up the messy way you have to wire up
> > oEvents.
> 
> I'm not sure at all about whether I mean that.  <grin>  I'm a VC novice.
> 
> I actually was looking for a possible syntax to seperate VC from the rest.

I don't think you can though, because the code you'd be putting in a VC is
still ordinary script.

> > The thing I dislike about this syntax is that the use of "background"
> > implies that the first statement in the function must be an "if", which
> > seems a bit kludgey to me.  Unless I'm misunderstanding you.
> 
> Your event_table idea is attractive.
> 
> Would there be (asks the VC ignorant guy) situations where a VC would
> simply need to be setup and it runs autonomously?  Even then, I suppose
> that an .Operate interface might be required/desired.

Yes, I would say this is a standard use of VCs.  Quite often you call a
setup() function in your script at startup that wires up the VCs, call
.Operate() on them, to get them going, and then leaves them to do their
work.  Not all VC setups need to trigger events in script code.

And in an ideal world, programs would call setup() and then end because all
of the functionality would be handled within VCs, with no calling of script
code at all.

Neil
-- 
Neil Durant
<nd...@us...>