using a global internal event within code/await

[Luke Whittlesey]

I'm trying to get ceu to compile the following:

```

event none global_event;

code/await Test (none) -> none do
  await global_event;
  escape;
end

```

.. and somewhere else I will `emit global_event;`

but I end up with the error: internal identifier "global_event" is not declared

I would like to use internal events that are external to the code/await abstraction. Is this permitted somehow?

-Thanks

[Francisco Sant'anna]

Hi Luke,

You need to prefix the identifier with "outer." :

await outer.global_event;

Regards,

Francisco

[Luke Whittlesey]

Francisco,

That works, thank you.

Just out of curiosity is it also legal to pass event identifiers into a code/await abstraction?

```

code/await Test (event none a) -> none do
  await a;
  escape;
end

```

The compiler accepts the syntax for the code/await declaration, but how would I instantiate it?

```

event none my_event;

await Test(my_event);

```

This gives me the error : invalid call : argument #1 : unexpected context for event "my_event"

Thanks,

Luke

--

---
You received this message because you are subscribed to the Google Groups "The Programming Language Céu" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceu-lang+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceu-lang/CAD4QiZuWa0AciNhOEW2BA4DK7-CLgAkT-wo69RGffzpjqNLDUw%40mail.gmail.com.

[Francisco Sant'anna]

On Tue, Sep 3, 2019 at 10:32 AM Luke Whittlesey <luke.wh...@gmail.com> wrote:

Just out of curiosity is it also legal to pass event identifiers into a code/await abstraction?

```

code/await Test (event none a) -> none do
  await a;
  escape;
end

```

The compiler accepts the syntax for the code/await declaration, but how would I instantiate it?

```

event none my_event;

await Test(my_event);

```

This gives me the error : invalid call : argument #1 : unexpected context for event "my_event"

You cannot "copy" an event. The event inside "Test" is a local event.

You need to pass by reference:

await Test(&my_event);

The signature of "Test" also needs to change:

code/await Test (event& none e)

[Luke Whittlesey]

That's great. The more I use ceu, the more impressed I am with it.

Thanks.

--

---
You received this message because you are subscribed to the Google Groups "The Programming Language Céu" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceu-lang+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceu-lang/CAD4QiZvRjyn4opJeXYy4H%3Dt89RzS1G4P%3DfofM7%3Dd_0Z4BC3M3w%40mail.gmail.com.

[Francisco Sant'anna]

On Tue, Sep 3, 2019, 11:37 Luke Whittlesey <luke.wh...@gmail.com> wrote:

That's great. The more I use ceu, the more impressed I am with it.

Thanks.

Thank you!

What's your interest in using Céu?

Francisco

[Luke Whittlesey]

> What's your interest in using Céu?

I see a lot of utility in the programming model. I think Ceu brings some things that C is sorely missing. Easy to use cooperative threads/continuations with automatic cancellation, finalization, and a deterministic (and easy to understand) sequencing. I think the static memory usage is a big deal too. For some problems the reactive/parallel style of programming is just easier for me to think about.

An area I haven't explored, but would like to, is using Ceu to drive unit tests for reactive code. I think the deterministic execution model combined with being able to locally emit events and time is interesting.

Now, I do have to admit that right now I am using Ceu mostly as an extension to C. I still write most of my code in C and then use Ceu to control it. I think as I get more comfortable I will move more into Ceu directly. I like that I can still write code in C; even if it does have fewer safety guarantees.

As a side thought, and since I have you on the line:) Would it be useful to have some sort of buffered mailboxes available in Ceu? Since events are ephemeral there is the possibility of missing events. Dataflow patterns could use this. Of course thought would have to be given to the possibility of unbounded memory use.

Ex:

loop do

  await data;

  await b;  // what if I don't want to miss a single data event

end

If I don't want to miss an event I have to manually capture the event and then set and check flags; which I guess is not a big deal, but it's more code and possibly a common pattern.

var bool data_avail = false;

var int data;

par do

  // latch in the data

    loop do

      data = await data_event;

      data_avail = true;

    end

  // use the data

  with

    loop do

        if (!data_avail) then

          data = await data_event;

        end

        data_avail = false;

        // use data ...

        await something_else;

    end

end

--

---
You received this message because you are subscribed to the Google Groups "The Programming Language Céu" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceu-lang+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceu-lang/CAD4QiZvTRo9YrH2nEYZf%2BCu-J8h8%3DKHomf9ncdEiaW67cBGUpA%40mail.gmail.com.

[Francisco Sant'anna]

On Tue, Sep 3, 2019 at 3:06 PM Luke Whittlesey <luke.wh...@gmail.com> wrote:

> What's your interest in using Céu?

I see a lot of utility in the programming model. I think Ceu brings some things that C is sorely missing. Easy to use cooperative threads/continuations with automatic cancellation, finalization, and a deterministic (and easy to understand) sequencing. I think the static memory usage is a big deal too. For some problems the reactive/parallel style of programming is just easier for me to think about.

Thanks, that's a detailed answer!

(I was asking more about if you are using for research purposes or something else).

Now, I do have to admit that right now I am using Ceu mostly as an extension to C. I still write most of my code in C and then use Ceu to control it. I think as I get more comfortable I will move more into Ceu directly. I like that I can still write code in C; even if it does have fewer safety guarantees.

We are working on improving the typesystem of Céu to something more modern, something in between OOP and FP.

I think that would improve the usability of the language a lot. But that's still a long shot and don't expect to release a new version until the next year.

As a side thought, and since I have you on the line:) Would it be useful to have some sort of buffered mailboxes available in Ceu? Since events are ephemeral there is the possibility of missing events. Dataflow patterns could use this. Of course thought would have to be given to the possibility of unbounded memory use.

Ex:

loop do

  await data;

  await b;  // what if I don't want to miss a single data event

end

Typically you would use a pool of code/awaits here:

pool[] Handler hs;

every x in data do

    spawn Handler(x) in hs;

end

code/await Handler (...) do

    await b;

    ...

end

You can even restrict the memory with a bounded pool (ex., pool[10]).

 

If I don't want to miss an event I have to manually capture the event and then set and check flags; which I guess is not a big deal, but it's more code and possibly a common pattern.

var bool data_avail = false;

var int data;

par do

  // latch in the data

    loop do

      data = await data_event;

      data_avail = true;

    end

  // use the data

  with

    loop do

        if (!data_avail) then

          data = await data_event;

        end

        data_avail = false;

        // use data ...

        await something_else;

    end

end

That's an alternative.

You could also use a ring buffer:

var[10*] int vec;

par do

    every data in data_event do

        vec = vec..[data];

    end

with

    ...

    data = vec[0];

    $vec = $vec - 1;

    ...

end

[Daniel Austin]

What's the best way to know about the latest features of Ceu that haven't yet made it into the manuals?  The manuals are filled with TODOs on the latest features, like ring buffers.  I think it's a blind spot for people like myself who are eager to use Ceu and even contribute back to its design and implementation, but feel like there's a secret world of implemented but undocumented capability that prevents me from feeling like I have a complete picture of the language's current state.  It keeps me from feeling like I have a solid understanding of the current conventions and idioms.

Thanks,

Dan

--

---
You received this message because you are subscribed to the Google Groups "The Programming Language Céu" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceu-lang+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceu-lang/CAD4QiZvm-T-qvHTGJY3mp3_GqWr21hRT3kAR%3DrrZwBUUzzWyDA%40mail.gmail.com.

[Luke Whittlesey]

> (I was asking more about if you are using for research purposes or something else)

Professionally I suppose. Right now I'm using ceu on an offboard controller (rPi) for a drone. It's a nice fit for managing the complexity of the asynchronous control messages I get from the flight controller. It is a bit of a risk to use ceu, given that ceu is young, but my current client has faith that a) I can get it to work, or b) I can rewrite it to work. Other than the learning curve I really haven't had any troubles. Ceu has been great.

--

---
You received this message because you are subscribed to the Google Groups "The Programming Language Céu" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceu-lang+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceu-lang/CAD4QiZvm-T-qvHTGJY3mp3_GqWr21hRT3kAR%3DrrZwBUUzzWyDA%40mail.gmail.com.

[Francisco Sant'anna]

On Tue, Sep 3, 2019, 17:22 Daniel Austin <daniel....@gmail.com> wrote:

What's the best way to know about the latest features of Ceu that haven't yet made it into the manuals?

Unfortunately I have no satisfactory answer for this question.

Since I'm currently redesigning the syntax and type system, it would be a lot of extra documentation work that would become obsolete very fast.

I'm afraid the mailing list is the only source of information for now.

Regards,

Francisco

[Daniel Austin]

Might I recommend an update email to the mailing list with what you are working on or a description of what problems you are trying to solve?  Or perhaps periodic blog posts to the website?  We would get more visibility into the activity of the community that I don't think is effectively communicated through github and a chat channel.  I've been on the mailing list since February and the traffic is pretty light.

I understand a "Ceu Newsletter" would invite a lot of feedback and brainstorming, and you might be trying to avoid that to prevent a design-by-committee experience, but the alternative is that it feels like there is almost no active community for this language.  That's a shame because Ceu engenders so much excitement from a small niche of developers that can see how much potential it has to relieve many of the pain points of time-focused interactive applications (great!), but it seems as if these developers are shut out of participating in the language evolution itself (not so great).

Ok, that's my rant and $.02.  I'll stop hijacking this thread now.

Dan

--

---
You received this message because you are subscribed to the Google Groups "The Programming Language Céu" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceu-lang+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceu-lang/CAD4QiZsW-fxbQzw%2B44FUu-%3Dq8p1sQO3RVMfv-K_exDmzNHOQfg%40mail.gmail.com.

[Francisco Sant'anna]

On Wed, Sep 4, 2019 at 12:01 AM Daniel Austin <daniel....@gmail.com> wrote:

Might I recommend an update email to the mailing list with what you are working on or a description of what problems you are trying to solve?  Or perhaps periodic blog posts to the website?  We would get more visibility into the activity of the community that I don't think is effectively communicated through github and a chat channel.  I've been on the mailing list since February and the traffic is pretty light.

That's a good idea. I'll try to do that. But...

I understand a "Ceu Newsletter" would invite a lot of feedback and brainstorming, and you might be trying to avoid that to prevent a design-by-committee experience, but the alternative is that it feels like there is almost no active community for this language.

... It's not only about design but mostly about research (in the end this is my job). Since (my) research ideas are typically bad and are immediately thrown away, I don't think that this level of noise would be fruitful.

The lack of more stable and modern alternatives to Esterel/Céu is a big problem because I'm always trying to occupy the research and industry spaces.

Of course I can still write something occasionally and I'll try to do that.

  That's a shame because Ceu engenders so much excitement from a small niche of developers that can see how much potential it has to relieve many of the pain points of time-focused interactive applications (great!), but it seems as if these developers are shut out of participating in the language evolution itself (not so great).

That's also something I can think about. Maybe start with proposing some orthogonal features that could be developed in parallel and merged without pain.

Thanks!

[Job van der Zwan]

On Tuesday, 3 September 2019 22:22:55 UTC+2, Daniel Austin wrote:

It keeps me from feeling like I have a solid understanding of the current conventions and idioms.

Another way to think about this: since Céu is partially a research language you can liberate yourself from the shackles of conventions and idioms and feel free develop your own ;). I'm sure that Francisco would love to hear your feedback on what works and what doesn't, what confuses or doesn't, etc.

Also, I'm seconding what others have said here: I would love it if you shared your design ideas and the overall research process more, Francisco! Like an open "request for comments" discussion, even before implementing anything. It would also be nice to see how you reason about things. We are a small group of enthusiastic people here, so I don't think ou really have to worry about the problem of the internet hivemind trying to strong-arm their uninformed opinions on you either.

/Job

[tyr.b...@gmail.com]

Is there a particular reason that you cannot copy events? Or is it just cases like this one? What determines whether an event can be copied or not?

Kind regards

[tyr.b...@gmail.com]

I'm not sure if it was clear but the above question about copying events was a reply to this older message:

[Francisco Sant'anna]

On Mon, Jan 20, 2020 at 12:55 AM <tyr.b...@gmail.com> wrote:
>
> I'm not sure if it was clear but the above question about copying events was a reply to this older message:

I'm confused now.
You cannot copy an event. An event is not data. Can you give me an
example where it would make sense to copy an event?
However, you can share an event with the `&` operator as the example
illustrates.

>
> > You cannot "copy" an event. The event inside "Test" is a local event.
>
> > You need to pass by reference:
>
> > await Test(&my_event);
>
> > The signature of "Test" also needs to change:
>
> > code/await Test (event& none e)
>

> --
>
> ---
> You received this message because you are subscribed to the Google Groups "The Programming Language Céu" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ceu-lang+u...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/ceu-lang/3aa6a22f-5e21-4663-a021-7457ec8b9b31%40googlegroups.com.