-
-
Notifications
You must be signed in to change notification settings - Fork 925
Commit
- 9.4.12.0
- 9.4.11.0
- 9.4.10.0
- 9.4.9.0
- 9.4.8.0
- 9.4.7.0
- 9.4.6.0
- 9.4.5.0
- 9.4.4.0
- 9.4.3.0
- 9.4.2.0
- 9.4.1.0
- 9.4.0.0
- 9.3.15.0
- 9.3.14.0
- 9.3.13.0
- 9.3.12.0
- 9.3.11.0
- 9.3.10.0
- 9.3.9.0
- 9.3.8.0
- 9.3.7.0
- 9.3.6.0
- 9.3.5.0
- 9.3.4.0
- 9.3.3.0
- 9.3.2.0
- 9.3.1.0
- 9.3.0.0
- 9.2.21.0
- 9.2.20.1
- 9.2.20.0
- 9.2.19.0
- 9.2.18.0
- 9.2.17.0
- 9.2.16.0
- 9.2.15.0
- 9.2.14.0
- 9.2.13.0
- 9.2.12.0
- 9.2.11.1
- 9.2.11.0
- 9.2.10.0
- 9.2.9.0
- 9.2.8.0
- 9.2.7.0
- 9.2.6.0
- 9.2.5.0
- 9.2.4.1
- 9.2.4.0
- 9.2.3.0
- 9.2.2.0
- 9.2.1.0
- 9.2.0.0
- 9.1.17.0
- 9.1.16.0
- 9.1.15.0
- 9.1.14.0
- 9.1.13.0
- 9.1.12.0
- 9.1.11.0
- 9.1.10.0
- 9.1.9.0
- 9.1.8.0
- 9.1.7.0
- 9.1.6.0
- 9.1.5.0
- 9.1.4.0
- 9.1.3.0
- 9.1.2.0
- 9.1.1.0
- 9.1.0.0
- 9.0.5.0
There are no files selected for viewing
8 comments
on commit 053458a
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. Plus returns a lambda. If I send INVOKE - will it be better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I think that would work - but I worry we're just trying random things until they work. Maybe we should have a document with what objects look like in different languages, and how they should respond to different messages, and then add tests for that to the TCK. I imagine in writing that document we would discover that some things are contradictory.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I am trying to document how interop messages should behave. The simple ones 1st: https://lafo.ssw.uni-linz.ac.at/hg/truffle/rev/5857f5ee9486 - is there anything (Ruby specific) you want to add to the text? Btw. the Javadoc is at http://lafo.ssw.uni-linz.ac.at/javadoc/truffle/latest/com/oracle/truffle/api/interop/Message.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did my best at https://lafo.ssw.uni-linz.ac.at/hg/truffle/rev/cc195dd45121, anything to change from Ruby point of view?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great to me. I have a question about why we need to pass the number of arguments but that's unrelated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The messages all look well documented. I think what we need to document now is what the different languages send for different syntax, and what things like the Java interop will send. On the Ruby side the protocol is currently very fragile. I'll start documenting how Ruby responds to messages and the messages it sends.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to add some examples with languages I knew (e.g. Java, C, possibly JavaScript) into the Truffle documentation. Do you want to have your own document (pros: you control it, cons: nobody finds it) or would you consider to add the sample Ruby code into the Javadoc of Truffle?
NetBeans has a concept of non-normative sections in Javadoc (like createAndOpen and addRecursiveListener). It tries to explain how some API concept are really implemented in parts of the system that don't have their own API/documentation, but are essential for understanding how the API behaves.
Maybe it would be beneficial to include the Ruby samples next to the Message elements (pros: instantly ready for API readers, cons: hard to keep them in sync)!?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll certainly start to write them - we can tweak where they live at any point. They probably belong in Truffle documentation because people are going to want to know how key languages will respond to them, and if we have a range of languages they can also use that to determine what they should do for their own languages.
@jtulach this is what I had to do in the end to get the TCK compound object test passing. I think the Java interop system specifically calls read and then execute, so for
plus
I'm having to explicitly return a function, like you would in JS. We're going to have to think about how to make this work well for all languages, as the current system seems very much like hard-coded JS semantics.