Pb with setCode with a generic type

Hi,

When calling exec.setCode on a Inst node defined with a generic port (§TYPE$[]) an error is returned (calling exec.getErrorCount() and exec.getError(0) ):
"port array has an unresolved type"

How can I set the code of of node with a generic type without having an error raised?
It is part a the functionalities to have a generic type, and I understand the code can't be checked before the node is used... maybe you should introduce a warning message....

Pierre

Comments

  • borjaborja Administrator, Fabric Employee Posts: 480 admin

    Hi Pierre

    We have a ticket (FE-5806) to make it possible to define the datatype of a subgraph beforehand. This would avoid these kind of errors.

    Borja Morales
    Technical Product Manager
    Fabric Software Inc.

  • craouettecraouette Posts: 113

    Hi borja,

    Not really... The problem I am facing:
    I am creating a dynamic node to go from items to array (and vice-versa). So, the node is created with a generic type $TYPE$ for the input and $TYPE$[] for the output, and the code is set to dfgEntry { out.resize(0); }. When setting the code, I got an error.
    When a connection is established, I determine the type, and set the code to dfgEntry { out.resize(1); out[0] = in0; }, but the type is defined (except if I am connecting a generic output). For me, I understand that the compilation could not be done, but setting the code on a generic node should not raised an error because there is no error (a warning, saying that it is not possible to know if there is an error in the code or not before the types are defined, is ok, but it requires changes in the API)!!

  • borjaborja Administrator, Fabric Employee Posts: 480 admin

    I see Pierre, the previous ticket is for a different use case :). I am sorry about that.

    For your particular use case, I have filed FE-5847 to discuss on making this a warning instead of an error

    Borja Morales
    Technical Product Manager
    Fabric Software Inc.

  • craouettecraouette Posts: 113

    there is nothing to be sorry about.... Warning are the best solution, from my point of view, because they can be used latter to report potential problems in the code, but they requires a changes in the API.
    In the mean time, I will probably do a setCode function which is not reporting errors to the end user (but write them in the logs) for my case, and another "normal" one, which is reporting errors, to be used when the user is creating/editing a function node.

Sign In or Register to comment.