Strange issue with custom extension and loop operator
Hi community,
I recently tried to run my own operator within a loop operator ("Loop Parameters"). It generates a set of strings of a particular length and amount. The loop operator is configured with different combinations of length and amount.
What I would expect:
Multiple sets of amount strings that fits the respective length, whereby the two parameters are different between different iterations.
What happens:
I only get the SAME amount of strings with the SAME length in each iteration. Additionally RapidMiner shows me a warning (StringGen is my custom operator):
Jun 7, 2017 5:53:08 PM WARNING: No such operator: 'StringGen'
Jun 7, 2017 5:53:08 PM WARNING: No such operator: 'StringGen'
If I use the StringGen operator without a loop operator it works perfectly. It simply seems to fail replacing the default parameter settings with the current configuration of each loop.
System:
I'm using RapidMiner Studio 7.4.000 on Windows 8 (x64).
I've already searched the forum but without any success. So I would be glad if anyone at least knows this issue ;-)
Thank's a lot in advance!
Cheers,
Lars
Answers
Dear Lars,
any chance we can peek into the source code? One thing i ran into was that all operators are one instance of a class. so they share the internal objects.
Best,
Martin
Dortmund, Germany
Dear Martin,
thank you very much for the fast reply. Of course, we could peek into the source code. But I'm afraid that the issue is not limited to my own operator. I've tested the same workflow composition with the built-in operator "Print to Console". My description in the previous post was simplified in terms of the operator nesting. Actually I have three operator levels:
This leads to the mentioned warning message, i.e. "PM WARNING: No such operator: <operator name>". I'm not sure if this is a feature or a bug. :manwink:
If I turn "parallel excution" off, everything works as expected.
I have not checked this issue with the most recent version of RapidMiner Studio, which is why I have not reported any bug. But this behavior seems odd.
Cheers,
Lars
Hi,
this has been identified as a bug and is being worked on.
Regards,
Marco