search

aseba-community / aseba

Aseba is a set of tools which allow beginners to program robots easily and efficiently. To contact us, please open an issue.
http://aseba.wikidot.com
GNU Lesser General Public License v3.0
49 stars 62 forks source link

New Aseba Switch #777

Open stephanemagnenat opened 6 years ago

stephanemagnenat commented 6 years ago

This issue is the place for the general discussion on the new Aseba Switch to be released in 1.7.

davidjsherman commented 6 years ago

Design

Features

Bugs

ypiguet-epfl commented 6 years ago

New feature:

stephanemagnenat commented 6 years ago

http-level support for sendBytecode (message ASEBA_MESSAGE_SET_BYTECODE) to open Aseba Switch to alternative compilers

We discussed that with @davidjsherman in the initial design, as this is interesting but also makes it much easier for people to create and send broken bytecode through HTTP. For that reason we decided not to implement it in the first version, but we have an open mind I would say. The best would be to have a bytecode verification mechanism, but of course this is a major work in itself.

ypiguet-epfl commented 6 years ago

But we want to send bytecode you might consider to be broken, without your permission. We want multitasking. We want coroutines. We want local variables. We want recursion. We want 2D arrays. We want more types, booleans obviously, fixed point, floating point, structures, whatever. We want some freedom, we want it quickly, and we'll have it.

davidjsherman commented 6 years ago

@ypiguet-epfl concerning https://github.com/aseba-community/aseba/issues/777#issuecomment-363062467, the method API PUT /nodes/{node}/program in the v1 API being implemented suggests

A future extension will accept application/json requests containing a Symbol Table and a Bytecode

Would this meet your needs.

Note that both a Symbol Table and a Bytecode need to be supplied, in order to not break reflection (see GET /nodes/{node}/program).

ypiguet-epfl commented 6 years ago

Thanks, David. Yes, it would, unless the uploaded bytecode and symbol table are needlessly constrained by a strict validator.

davidjsherman commented 6 years ago

My fondest dream is that someday this API would be burned into the robot firmware, where practically speaking there would be no processing power for the compiler, much less a validator.

In a microservices architecture, compilation and validation would be the responsibility of a service, possibly even two different services. If a guarantee of validity were needed, I expect that they would be provided by a small certificate as part of the payload. For example a JSON Web Token (JWT) claim as defined in RFC 7519. The certificate would be the “proof” that the program was valid.

A validating compiler in the switch, like the one being implemented now, would trust itself and wouldn't need to provide a certificate.

mbonani commented 6 years ago

Hello, before going in perhaps complicated thing (excuse me if I understand wrong) what are really the need? @ypiguet-epfl what is the minimum to have for your development plan? can we perhaps have more details?

@all could we imaging a two phases plan for external compilation, one just sending bytecode without symbol table and validator and a second with a good implementation with perhaps also a certificate?

stephanemagnenat commented 6 years ago

The symbol table should go with sending the bytecode (otherwise there is a missing piece for building web-based IDEs), but actually it is not a lot of work to implement. The validator should be a further refinement, if we need/want it.

stephanemagnenat commented 6 years ago

And to clarify for people who accuse us of not being open-minded: as pointed by David we did think of the bytecode and we did put it in the specification. What I said is that we decided to not implement it in the first version, that is, the bare minimum for running properly Blockly, Scratch and co.

davidjsherman commented 6 years ago

I want to accept responsibility for not doing a good job in broadcasting the API and asking for public comments. I propose that I add a repository aseba-community/aseba-rest-api for the specification, with a CI job to format it properly, and issues for comments.

ypiguet-epfl commented 6 years ago

@mbonani I don't have yet frozen development plans. I'm trying to understand what's possible inside aseba-community, or outside with some friendly support (hooks to benefit from existing parts), or outside without support. Of course the limits are fuzzy. I understand very well that the contributors have different needs, priorities and constraints, but sometimes I feel there must be something else. My question about bytecode wasn't gratuitous, it's well within the options we might consider and asebahttp looks like the easiest way to interface with the Thymio, as corroborated by Blockly and Scratch. It isn't a matter of days, but when I see that local variables were discussed in 2012 #111 and I don't see much progress, maybe welcoming more external contributions could be beneficial. For me, clearly PR aren't an option anymore for anything significant.

To be more concrete, should we wish to develop an alternative textual language (let's say with coroutines and less emphasis on events), or an alternative graphical language implementation (let's say web-based), could we do it easily without the risk that Studio, asebahttp or the Thymio firmware locks what's possible now because it's deemed improper or bad for the children?

stephanemagnenat commented 6 years ago

I am very much in favour of making the Aseba technology open to new languages, and that is why @davidjsherman and I designed the Symbol Table and Bytecode interface in the HTTP protocol. I also think it makes a lot of sense to do it through the web, and we designed the new Switch with an interactive HTML-based IDE in mind. I also added the websocket wish #626 as a way to bring message-level communication on the web.

Regarding aseba-community and outside, we are working towards letting the continuous integration build pull requests including binary packages. That way, third parties can make a pull request with their own needs and take advantage of our build infrastructure, even if their changes are not planned to be merged into master.

Regarding local variables, I would be very happy to have them. Just they are not trivial to implement, as the necessary support is not required only in the compiler but also in Studio as the variable display tree needs to be synchronized. I am very sensitive to half-implemented features, because currently Aseba is a promise of a consistent experience and I think that it is a strength to keep.

Finally, the reason it went slowly is that there was little dedicated funding for Aseba for years.

ypiguet-epfl commented 6 years ago

New feature:

I can provide a patch for asebahttp if it helps.

stephanemagnenat commented 6 years ago

Serving static files makes sense indeed. Note that the basic HTTP example in Dashel does it (see https://github.com/aseba-community/dashel/blob/master/examples/dws.cpp).

retornaz commented 6 years ago

@ypiguet-epfl with a such feature list, you might want to consider using another VM than the aseba one. Such as: micropython ( https://github.com/micropython/micropython/tree/master/ports/pic16bit ) or lua/elua (plain C, would work on pic24).

ypiguet-epfl commented 6 years ago

Thanks, @retornaz. For the moment I want to keep the stock firmware. From a technical point of view, a lot can still be done by the compiler.