<div dir="ltr">Processes like the muxer implement a method that is called when the connection is attempted. It then looks at the requested type for the port and can dynamically create a port with that data type string. The process also needs to deal with the actual data type that is being passed. These flow control processes (e.g. mux, collate) just pass the input data item to an output port without actually extracting it from the boost::any in the data packet. <div><br></div><div>I am working on an idea to support casting data elements using the port trait infrastructure. The call would look something like</div><div><br></div><div><font face="monospace, monospace">auto value = get_from_port_using_trait<desired-type>( port-name );</font></div><div><br></div><div>This would extract the value from the port based on the type specified in the trait and then attempt to cast it to the desired type. Will need to determine how to handle errors when the cast fails. This approach does not address how to deal with the logical data type string associated with the port.</div><div><br></div><div>One approach would be to specific type strings that refer to the base types (e.g. track_set) and then expect the processes to use above call to convert to desired type. Presumably this situation would not be all that common that a polymorphic type would be passed.</div><div><br></div><div>Anyhow, it is just a concept in the early stages...</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 15, 2017 at 2:58 PM, Matthew Leotta <span dir="ltr"><<a href="mailto:matt.leotta@kitware.com" target="_blank">matt.leotta@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">I don’t think we should. The right way to handle this (in your case) is to pass through the input port type to the output. I believe I remember seeing examples of this in sprokit for more generic processes, like a muxer and demuxer. Those processes say “I don’t care what the input type is, but the output type needs to match whatever the input type was”. What I don’t know is whether we do both the input/output type matching and the specify type requirements at the same time.<div><br></div><div>My understanding of the state of sprokit is a little outdated so someone correct me if I’m wrong about the type matching thing.</div><div><br></div><div>—Matt</div><div><div class="h5"><div><br><div><div><blockquote type="cite"><div>On Nov 15, 2017, at 2:51 PM, Brian Clipp <<a href="mailto:brian.clipp@kitware.com" target="_blank">brian.clipp@kitware.com</a>> wrote:</div><br class="m_-3259541637880788673Apple-interchange-newline"><div><div dir="ltr">Would we allow down-casting? <div><br></div><div>-B</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 15, 2017 at 2:51 PM Matthew Leotta <<a href="mailto:matt.leotta@kitware.com" target="_blank">matt.leotta@kitware.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">I would prefer a string the makes the derivation order explicit rather than just an arbitrary list, like “track_set.feature”, but I could be convinced otherwise. This way you can just match substrings from the front until you find a match.</div><div style="word-wrap:break-word"><div><br></div><div><br><div><blockquote type="cite"><div>On Nov 15, 2017, at 2:37 PM, Matt Phillips <<a href="mailto:matt.phillips@kitware.com" target="_blank">matt.phillips@kitware.com</a>> wrote:</div><br class="m_-3259541637880788673m_6730911477147631406Apple-interchange-newline"><div><div dir="ltr">Forget the exact signature but<div><br></div><div>class feature_track_set : public ...</div><div>{</div><div> ...</div><div> static std::string type_string() { return "feature_track_set,track_set"; }</div><div>}</div><div><br></div><div>Is one way to do it, just turn the name into a list of (permissible) names. This creates coupling issues but there can be an early runtime check to ensure that given "A,B", B is actually a base of A.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 15, 2017 at 2:25 PM, Matthew Leotta <span dir="ltr"><<a href="mailto:matt.leotta@kitware.com" target="_blank">matt.leotta@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Yes, exactly. That what I was getting at with the earlier idea of substring processing on the type strings, but there is probably a better way to implement it than that.<div><div class="m_-3259541637880788673m_6730911477147631406h5"><div><br><div><blockquote type="cite"><div>On Nov 15, 2017, at 2:23 PM, Matt Phillips <<a href="mailto:matt.phillips@kitware.com" target="_blank">matt.phillips@kitware.com</a>> wrote:</div><br class="m_-3259541637880788673m_6730911477147631406m_2399934893185032530Apple-interchange-newline"><div><div dir="ltr">So this new idea is simpler but more permissive than it needs to be. feature_track_set is a track_set but isn't a object_track_set. Only the former would be allowed, so Sprokit's type-checking system would have to be made to understand the inheritance relationships somehow, but what you just described Brian would be prohibited.<div><br></div><div>Matt</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 15, 2017 at 2:15 PM, Brian Clipp <span dir="ltr"><<a href="mailto:brian.clipp@kitware.com" target="_blank">brian.clipp@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Yeah, I'm not a fan of calling every flavor of track_set a track_set. That could allow us to connect object_track_set ports to feature_track_set ports. We could catch that when constructing the graph.<span class="m_-3259541637880788673m_6730911477147631406m_2399934893185032530HOEnZb"><font color="#888888"><div><br></div><div>-B</div><div><br></div></font></span></div><div class="m_-3259541637880788673m_6730911477147631406m_2399934893185032530HOEnZb"><div class="m_-3259541637880788673m_6730911477147631406m_2399934893185032530h5"><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 15, 2017 at 2:10 PM Matthew Leotta <<a href="mailto:matt.leotta@kitware.com" target="_blank">matt.leotta@kitware.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">I’d rather not tell sprokit to ignore type checking on some subset of types, but not others. However, equivalently you could define all track_set types to be “track_set” regardless of the specific derived class. Then each process would need to check at run time if the track_set it got can be down cast to the type it was expecting. That approach is equivalent, but probably less of a hack. It’s still not ideal.<div><br></div><div>—Matt</div></div><div style="word-wrap:break-word"><div><br><div><blockquote type="cite"><div>On Nov 15, 2017, at 2:01 PM, Brian Clipp <<a href="mailto:brian.clipp@kitware.com" target="_blank">brian.clipp@kitware.com</a>> wrote:</div><br class="m_-3259541637880788673m_6730911477147631406m_2399934893185032530m_6067411255523973816m_-1648763884981422571Apple-interchange-newline"><div><div dir="ltr">Agreed. Matt P. had an interesting suggestion. What if Sprokit's graph type checking would allow some potentially wrong graphs through to allow for up-casting? It could catch really egregious issues, e.g. int passed into a port expecting a string, but not subtle issues like a track_set passed into a feature_track set port where the track set is in fact an object_track_set. <div>Basically, the type checker would consider up-casts and down-casts as being equivalent types. Most errors would be caught at pipeline construction time but a few might only be caught at run-time.<div><br></div><div>-Brian</div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 15, 2017 at 1:53 PM Matthew Leotta <<a href="mailto:matt.leotta@kitware.com" target="_blank">matt.leotta@kitware.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">This has been a long standing issue with sprokit, from what I recall. It seems to me that we need a mechanism for allowing sprokit type checking to allow for casting up the inheritance hierarchy. A feature_track_set is a track_set, so any process that can process a track_set should also be able to process a feature_track_set. I’m not sure if there is an easy way of checking this because I think sprokit just does string name comparison for type checking. Maybe the type name strings could be “track_set”, “track_set.feature”, “track_set.object” and we could do substring comparison? Anyway, that is probably a discussion for another day. In your case, the issue is more challenging because there is also down casting involved. Ideally you want to encode that the input and output types for this process must be 1) the same exact type and 2) a track_set or some derivative of it. I’m not sure that we can do that in sprokit yet.<div><br></div><div>I mostly agree with the best practices rules in the PPTX, except that I’d like to see sprokit improved so that the first rule is not needed. For now, I think your Option 2 (slide 4) makes the most sense.<div><br></div><div>—Matt</div><div><br><div><blockquote type="cite"></blockquote></div></div></div></div><div style="word-wrap:break-word"><div><div><div><blockquote type="cite"><div>On Nov 15, 2017, at 1:22 PM, Brian Clipp <<a href="mailto:brian.clipp@kitware.com" target="_blank">brian.clipp@kitware.com</a>> wrote:</div><br class="m_-3259541637880788673m_6730911477147631406m_2399934893185032530m_6067411255523973816m_-1648763884981422571m_4263137262730716485Apple-interchange-newline"></blockquote></div></div></div></div><div style="word-wrap:break-word"><div><div><div><blockquote type="cite"><div><div dir="ltr">Pushing the tread over to kwiver-users. I attached the original ppt.<div><br></div><div>-Brian<br><br><div class="gmail_quote"><div dir="ltr">---------- Forwarded message ---------<br>From: Matthew Leotta <<a href="mailto:matt.leotta@kitware.com" target="_blank">matt.leotta@kitware.com</a>><br>Date: Wed, Nov 15, 2017 at 1:08 PM<br>Subject: Re: [Kwiver-announce] Best practices for passing inherited types through Sprokit Pipeline<br>To: Matt Phillips <<a href="mailto:matt.phillips@kitware.com" target="_blank">matt.phillips@kitware.com</a>>, Brian Clipp <<a href="mailto:brian.clipp@kitware.com" target="_blank">brian.clipp@kitware.com</a>><br>Cc: <<a href="mailto:kwiver-announce@public.kitware.com" target="_blank">kwiver-announce@public.<wbr>kitware.com</a>><br></div><br><br><div style="word-wrap:break-word">Guys,<div><br></div><div>Let’s take this discussion to the kwiver-users list rather than kwiver-announce. kwiver-annouce is supposed to be for major announcements, like new versions.</div><div><br></div><div>Of course this make me wonder if we really need kwiver-announce anymore. Is there anyone on this mailing list who is not also on kwiver-users and who only wants to receive very infrequent notifications about KWIVER releases and other major announcements? If this describes you, please send me a response privately. If I get no responses in a week or so, I think we should retire this list and use only kwiver-users. That pattern aligns better with what our other open source projects do for mailing lists.</div><div><br></div><div>Thanks,</div><div>Matt</div></div><div style="word-wrap:break-word"><div><br></div><div><br><div><blockquote type="cite"><div>On Nov 15, 2017, at 12:56 PM, Matt Phillips <<a href="mailto:matt.phillips@kitware.com" target="_blank">matt.phillips@kitware.com</a>> wrote:</div><br class="m_-3259541637880788673m_6730911477147631406m_2399934893185032530m_6067411255523973816m_-1648763884981422571m_4263137262730716485m_7155049012537094721Apple-interchange-newline"><div><div dir="ltr">Is the issue here just slicing when derived class objects are passed to Keyframe selector? I'm not familiar off the top of my head with how sprokit does serialization/deserialization but might making that 'slice-proof' be the answer? By e.g. storing type information and using factory methods at construction.<div><br></div><div>Matt</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 15, 2017 at 12:46 PM, Brian Clipp <span dir="ltr"><<a href="mailto:brian.clipp@kitware.com" target="_blank">brian.clipp@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi All.<div><br></div><div>I ran into a case yesterday where I had a process that output a child class and a process that expected an input from it of the parent class. Sprokit's type checking fails in that case. It lead me to spend some time thinking about what types to pass between processes. After some discussion with Aaron and Matt B. these are some suggestions I've arrived at. </div><div><br></div><div>Thoughts?</div><span class="m_-3259541637880788673m_6730911477147631406m_2399934893185032530m_6067411255523973816m_-1648763884981422571m_4263137262730716485m_7155049012537094721HOEnZb"><font color="#888888"><div><br></div><div>Brian</div></font></span></div>
<br>______________________________<wbr>_________________<br>
Kwiver-announce mailing list<br>
<a href="mailto:Kwiver-announce@public.kitware.com" target="_blank">Kwiver-announce@public.<wbr>kitware.com</a><br>
<a href="http://public.kitware.com/mailman/listinfo/kwiver-announce" rel="noreferrer" target="_blank">http://public.kitware.com/<wbr>mailman/listinfo/kwiver-<wbr>announce</a><br>
<br></blockquote></div><br></div>
______________________________<wbr>_________________<br>Kwiver-announce mailing list<br><a href="mailto:Kwiver-announce@public.kitware.com" target="_blank">Kwiver-announce@public.<wbr>kitware.com</a><br><a href="http://public.kitware.com/mailman/listinfo/kwiver-announce" target="_blank">http://public.kitware.com/<wbr>mailman/listinfo/kwiver-<wbr>announce</a><br></div></blockquote></div><br></div></div></div></div></div>
</div></blockquote></div></div></div></div><div style="word-wrap:break-word"><div><div><div><blockquote type="cite"><div><span id="m_-3259541637880788673m_6730911477147631406m_2399934893185032530m_6067411255523973816m_-1648763884981422571m_4263137262730716485cid:15fc0eaed97bfec7ed31"><Inherited Types in Sprokit Pipelines.pptx></span>_______________<wbr>______________________________<wbr>__<br>Kwiver-users mailing list<br><a href="mailto:Kwiver-users@public.kitware.com" target="_blank">Kwiver-users@public.kitware.<wbr>com</a><br><a href="http://public.kitware.com/mailman/listinfo/kwiver-users" target="_blank">http://public.kitware.com/<wbr>mailman/listinfo/kwiver-users</a><br></div></blockquote></div><br></div></div></div></blockquote></div>
</div></blockquote></div><br></div></div></blockquote></div>
</div></div><br>______________________________<wbr>_________________<br>
Kwiver-users mailing list<br>
<a href="mailto:Kwiver-users@public.kitware.com" target="_blank">Kwiver-users@public.kitware.<wbr>com</a><br>
<a href="http://public.kitware.com/mailman/listinfo/kwiver-users" rel="noreferrer" target="_blank">http://public.kitware.com/<wbr>mailman/listinfo/kwiver-users</a><br>
<br></blockquote></div><br></div>
</div></blockquote></div><br></div></div></div></div></blockquote></div><br></div>
</div></blockquote></div><br></div></div></blockquote></div>
</div></blockquote></div><br></div></div></div></div></div><br>______________________________<wbr>_________________<br>
Kwiver-users mailing list<br>
<a href="mailto:Kwiver-users@public.kitware.com">Kwiver-users@public.kitware.<wbr>com</a><br>
<a href="http://public.kitware.com/mailman/listinfo/kwiver-users" rel="noreferrer" target="_blank">http://public.kitware.com/<wbr>mailman/listinfo/kwiver-users</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><font color="#888888"><b>Linus Sherrill - </b></font><font color="#888888">Staff R&D Engineer<br></font><font color="#888888">Kitware, Inc.<br>28 Corporate Drive<br>Clifton Park, NY 12065-8662<br>E: <a href="mailto:linus.sherrill@kitware.com" target="_blank">linus.sherrill@kitware.com</a><br>P: 518.881.4400<br></font></div></div></div></div></div>
</div>