Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add catch-all create methods for all sampling ports, alls queuing ports and all {a,}periodic processes #25

Open
wucke13 opened this issue Jul 19, 2023 · 4 comments
Assignees

Comments

@wucke13
Copy link
Contributor

wucke13 commented Jul 19, 2023

I think quite often one just wants to initialize all ports/processes. Currently, this can not be done programmatically, as these are distinct fields/methods in the Context object. It would be good if we could either loop over them (maybe with a closure?) and/or just ctx.create_all_periodic_processes().

@dadada
Copy link
Collaborator

dadada commented Jul 19, 2023

I am also missing something like this. The issue is that the names of the ports are generated, so it is not possible to iterate through them at the use-site of the proc-macro. I was thinking about initializing all ports by default, if no start macro is called, but this is non-obvious behaviour. I dislike the idea of having a function that does the initialization of all available resources for a similar reason. What if you initialize some of the ports and then call the function. Would we attempt to recreate them? What does the APEX say about creating ports twice? Should this be idempotent or should the previous ref to the port object be overwritten?

@sevenautumns
Copy link
Collaborator

What does the APEX say about creating ports twice?

According to the Standard, a NO_ACTION error is emitted when creating an already existent port.

How about an annotation to the ports/processes themself? Consider this, when adding the optional auto_init (naming up for debate):

  • no create function is made available in the start context struct
  • these ports/processes will be initialized before the user defined start function
  • contexts in processes do not hold an Option to these annotated ports/processes, but the ports/processes themself (no more unwrap)

@wucke13
Copy link
Contributor Author

wucke13 commented Jul 21, 2023

@sevenautumns I kind of like this idea. I'm a bit afraid however that the fluctuating behavior of Context might confuse some users.

@sevenautumns
Copy link
Collaborator

if no start macro is called

I still fancy the idea of no start function. I am against auto initialization if no start function is defined, but if the start function would be empty anyways, it could just be omitted

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants