New Aseba Switch #777
Comments
|
New feature:
|
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. |
|
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. |
|
@ypiguet-epfl concerning #777 (comment), the method API PUT /nodes/{node}/program in the v1 API being implemented suggests
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). |
|
Thanks, David. Yes, it would, unless the uploaded bytecode and symbol table are needlessly constrained by a strict validator. |
|
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. |
|
Hello, before going in perhaps complicated thing (excuse me if I understand wrong) what are really the need? @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? |
|
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. |
|
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. |
|
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. |
|
@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? |
|
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. |
|
New feature:
I can provide a patch for |
|
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). |
|
@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). |
|
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. |
This issue is the place for the general discussion on the new Aseba Switch to be released in 1.7.
The text was updated successfully, but these errors were encountered: