-
Notifications
You must be signed in to change notification settings - Fork 202
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
Simplify generic parameterization on some operations #176
Comments
I think it would be worth it to make this simplification yes, but the rule might be a bit more tricky. In fact, a generic parameter should be enforced if any input or output of the method should share the same parameter. In other words:
Even if a single parameter is not bound to Operand<TFloat> toFloat(Operand<? extends TNumber> input) So this logic must be added to the C++ op generator. |
@karllessard do you have any idea when you would get to this? Should we wait for it before merging in the Kotlin API? |
Hey @rnett , I was not necessarily planning to do this work anytime soon, do you want to give it a try? |
I can take a look, at least. Do you have any recommendations on IDE setup? I had issues getting bazel to work with CLion when I tried it. |
When I was doing more C/C++ code than Java for TensorFlow, I was using Eclipse which supports well both languages, even in the same project (at that time, I had to edit the project file manually to enable this hybridity, I don't know if that can be done differently now). |
@karllessard I've got this mostly working, I think, but Javadocs aren't being generated any more, even on |
(oh yes I recall now, you need to pass the path to the library as well as an argument, that's something relatively new.) But you need to pass both dirs in the |
Ok, It looks like it should be |
Also, for anyone else trying to use the bazel project, I got it working w/ an old version of CLion (so that I could use the bazel plugin), as long as ran @karllessard do you think we should make a |
Yes, we've mentioned that during the last meeting, we definitely need better documentation when it comes to build from sources and guide the users in the process, we have a lot of issues raised by them that would probably be avoided by just having this documentation, please feel free to start it! |
I'm working on the
reified
generation for the Kotlin API, and I'm noticing that lots of methods have unnecessary type parameters that makes thereified
usage much less nice (since you have to specify all type parameters if you specify one). The best example is probablycast
, which has the signiture:T
is completely unnecessary and could be replaced with?
without issue, but it preventscast<TInx32>(x)
usage from Kotlin. This shows up in a number of Ops, mostly with the unnecessary type parameters on the input. It essentially needs a "is this type param only bounded by TType and only used on inputs" check.Originally posted by @rnett in #174 (comment)
The text was updated successfully, but these errors were encountered: