From matt.brown at kitware.com Sun Nov 12 21:16:20 2017 From: matt.brown at kitware.com (Matt Brown) Date: Sun, 12 Nov 2017 21:16:20 -0500 Subject: [Kwiver-users] Window view of Vital image Message-ID: Is there an easy way to create a view into a window of a Vital image akin to what you can do in OpenCV by applying a cv::Rect to a cv::Mat? I couldn't find any examples in the repo of this being done. I was looking into the 'image_of' class, and I could use that with the appropriate step sizes. But, it would be ideal if a vital::image or even better vital::image_container had this functionality built in. Thanks, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From linus.sherrill at kitware.com Mon Nov 13 09:08:55 2017 From: linus.sherrill at kitware.com (Linus Sherrill) Date: Mon, 13 Nov 2017 09:08:55 -0500 Subject: [Kwiver-users] Window view of Vital image In-Reply-To: References: Message-ID: There has been some discussion about adding functionality to clip rectangles (bounding boxes) from images to yield another image (or image_container). If somebody is working on this, speak up :-) In any event, this is best implemented as an operator on an image(or image_container) and not a member. Thanks, -Linus On Sun, Nov 12, 2017 at 9:16 PM, Matt Brown wrote: > Is there an easy way to create a view into a window of a Vital image akin > to what you can do in OpenCV by applying a cv::Rect to a cv::Mat? I > couldn't find any examples in the repo of this being done. I was looking > into the 'image_of' class, and I could use that with the appropriate step > sizes. But, it would be ideal if a vital::image or even better > vital::image_container had this functionality built in. > > Thanks, > Matt > > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/kwiver-users > > -- *Linus Sherrill - *Staff R&D Engineer Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065-8662 E: linus.sherrill at kitware.com P: 518.881.4400 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.leotta at kitware.com Mon Nov 13 09:19:25 2017 From: matt.leotta at kitware.com (Matthew Leotta) Date: Mon, 13 Nov 2017 09:19:25 -0500 Subject: [Kwiver-users] Window view of Vital image In-Reply-To: References: Message-ID: <49F52DAD-21A7-4FF5-85F0-0E84CBD5FE57@kitware.com> The original intent was that vital::image should be just a transient container for moving data around and any real work would be done in either OpenCV, VXL, or another package. I believe both OpenCV and VXL support shallow copied crops or ?views? into a larger image. The vital::image can technically support such views as well, you just need to call some of the more complex constructors with right pointer offsets. This operation is probably common enough that it makes sense to have a helper function to make this easy. Where that code lives is another question. This might be something that best fits in the proposed ?utils? area that lives between vital and arrows. For now it could go in arrows::core. ?Matt > On Nov 13, 2017, at 9:08 AM, Linus Sherrill wrote: > > There has been some discussion about adding functionality to clip rectangles (bounding boxes) from images to yield another image (or image_container). If somebody is working on this, speak up :-) > In any event, this is best implemented as an operator on an image(or image_container) and not a member. > > Thanks, > -Linus > > On Sun, Nov 12, 2017 at 9:16 PM, Matt Brown > wrote: > Is there an easy way to create a view into a window of a Vital image akin to what you can do in OpenCV by applying a cv::Rect to a cv::Mat? I couldn't find any examples in the repo of this being done. I was looking into the 'image_of' class, and I could use that with the appropriate step sizes. But, it would be ideal if a vital::image or even better vital::image_container had this functionality built in. > > Thanks, > Matt > > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/kwiver-users > > > > > -- > Linus Sherrill - Staff R&D Engineer > Kitware, Inc. > 28 Corporate Drive > Clifton Park, NY 12065-8662 > E: linus.sherrill at kitware.com > P: 518.881.4400 > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/kwiver-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.brown at kitware.com Mon Nov 13 11:39:05 2017 From: matt.brown at kitware.com (Matt Brown) Date: Mon, 13 Nov 2017 11:39:05 -0500 Subject: [Kwiver-users] Window view of Vital image In-Reply-To: References: Message-ID: I had this same question myself. Others can correct me or add to, but I believe the idea is as follows... Arrows allow you to separate the implementation of a particular algorithm from the top-level code that uses it. Thus, you can have an OCV arrow that does image filtering or some other library implementing the particular algorithm. However, for some simpler process functionality, it isn't worth the overhead of defining a vital algorithm and dispatching to an arrow. For example, *ocv/image_viewer_process* just displays an image to the screen. Though conceivably, a process could start life as a library-specific implementation but then later be broken out into vital::algorithm and arrow if there is a desire to use different libraries for that functionality. On Mon, Nov 13, 2017 at 10:43 AM, Matt Phillips wrote: > Tbh what is the rationale for having ocv *processes*? Obviously, ocv > algos, and crop_chips is one (arrows/ocv/crop_chips.cxx). I would have > thought that Sprokit would abstract away from which particular vision > library is being used to perform some functionality. > > Matt > > On Mon, Nov 13, 2017 at 10:33 AM, Matt Brown > wrote: > >> I think for now, I will just make my process an OCV process, even though >> it is only using OCV for the cropping aspect. Once we settle on a view/crop >> utility and it makes it way into master, which I think would be great, then >> I will move it back to a core process. >> >> Thanks, >> Matt >> >> On Mon, Nov 13, 2017 at 9:27 AM, Matt Phillips > > wrote: >> >>> Hi, I've signed up for kwiver-users now, but as for this post which >>> Aaron B. kindly forwarded, I'd say this sounds like Jon C.'s >>> crop_chips/crop_detector functionality. I've written an example pipeline >>> for it, and it all lives in Jon's repo atm afaik. >>> >>> https://github.com/Erotemic/kwiver/tree/dev/CropChipsPipeline >>> >>> Matt >>> >>> >>> ---------- Forwarded message ---------- >>> From: Aaron Bray >>> Date: Mon, Nov 13, 2017 at 9:15 AM >>> Subject: Fwd: [Kwiver-users] Window view of Vital image >>> To: Matt Phillips >>> >>> >>> Are you a member of kwiver-users? >>> If not, you should sign up here : https://public.kitware.com/m >>> ailman/listinfo/kwiver-announce >>> >>> This thread sounds like your guacamole arrow... >>> >>> >>> ---------- Forwarded message ---------- >>> From: Linus Sherrill >>> Date: Mon, Nov 13, 2017 at 9:08 AM >>> Subject: Re: [Kwiver-users] Window view of Vital image >>> To: Matt Brown >>> Cc: kwiver-users at public.kitware.com >>> >>> >>> There has been some discussion about adding functionality to clip >>> rectangles (bounding boxes) from images to yield another image (or >>> image_container). If somebody is working on this, speak up :-) >>> In any event, this is best implemented as an operator on an image(or >>> image_container) and not a member. >>> >>> Thanks, >>> -Linus >>> >>> On Sun, Nov 12, 2017 at 9:16 PM, Matt Brown >>> wrote: >>> >>>> Is there an easy way to create a view into a window of a Vital image >>>> akin to what you can do in OpenCV by applying a cv::Rect to a cv::Mat? I >>>> couldn't find any examples in the repo of this being done. I was looking >>>> into the 'image_of' class, and I could use that with the appropriate step >>>> sizes. But, it would be ideal if a vital::image or even better >>>> vital::image_container had this functionality built in. >>>> >>>> Thanks, >>>> Matt >>>> >>>> _______________________________________________ >>>> Kwiver-users mailing list >>>> Kwiver-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/kwiver-users >>>> >>>> >>> >>> >>> -- >>> *Linus Sherrill - *Staff R&D Engineer >>> Kitware, Inc. >>> 28 Corporate Drive >>> >>> Clifton Park, NY 12065 >>> >>> -8662 >>> E: linus.sherrill at kitware.com >>> P: 518.881.4400 <(518)%20881-4400> >>> >>> _______________________________________________ >>> Kwiver-users mailing list >>> Kwiver-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/kwiver-users >>> >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron.bray at kitware.com Mon Nov 13 11:44:43 2017 From: aaron.bray at kitware.com (Aaron Bray) Date: Mon, 13 Nov 2017 11:44:43 -0500 Subject: [Kwiver-users] Window view of Vital image In-Reply-To: References: Message-ID: If you do not select the OCV arrow for whatever reason (such as fletch did not build OCV) You cannot have a process that uses OCV, so processes dependent on an optional library should not be part of Core On Mon, Nov 13, 2017 at 11:39 AM, Matt Brown wrote: > I had this same question myself. Others can correct me or add to, but I > believe the idea is as follows... Arrows allow you to separate the > implementation of a particular algorithm from the top-level code that uses > it. Thus, you can have an OCV arrow that does image filtering or some other > library implementing the particular algorithm. However, for some simpler > process functionality, it isn't worth the overhead of defining a vital > algorithm and dispatching to an arrow. For example, > *ocv/image_viewer_process* just displays an image to the screen. Though > conceivably, a process could start life as a library-specific > implementation but then later be broken out into vital::algorithm and arrow > if there is a desire to use different libraries for that functionality. > > > On Mon, Nov 13, 2017 at 10:43 AM, Matt Phillips > wrote: > >> Tbh what is the rationale for having ocv *processes*? Obviously, ocv >> algos, and crop_chips is one (arrows/ocv/crop_chips.cxx). I would have >> thought that Sprokit would abstract away from which particular vision >> library is being used to perform some functionality. >> >> Matt >> >> On Mon, Nov 13, 2017 at 10:33 AM, Matt Brown >> wrote: >> >>> I think for now, I will just make my process an OCV process, even though >>> it is only using OCV for the cropping aspect. Once we settle on a view/crop >>> utility and it makes it way into master, which I think would be great, then >>> I will move it back to a core process. >>> >>> Thanks, >>> Matt >>> >>> On Mon, Nov 13, 2017 at 9:27 AM, Matt Phillips < >>> matt.phillips at kitware.com> wrote: >>> >>>> Hi, I've signed up for kwiver-users now, but as for this post which >>>> Aaron B. kindly forwarded, I'd say this sounds like Jon C.'s >>>> crop_chips/crop_detector functionality. I've written an example pipeline >>>> for it, and it all lives in Jon's repo atm afaik. >>>> >>>> https://github.com/Erotemic/kwiver/tree/dev/CropChipsPipeline >>>> >>>> Matt >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Aaron Bray >>>> Date: Mon, Nov 13, 2017 at 9:15 AM >>>> Subject: Fwd: [Kwiver-users] Window view of Vital image >>>> To: Matt Phillips >>>> >>>> >>>> Are you a member of kwiver-users? >>>> If not, you should sign up here : https://public.kitware.com/m >>>> ailman/listinfo/kwiver-announce >>>> >>>> This thread sounds like your guacamole arrow... >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Linus Sherrill >>>> Date: Mon, Nov 13, 2017 at 9:08 AM >>>> Subject: Re: [Kwiver-users] Window view of Vital image >>>> To: Matt Brown >>>> Cc: kwiver-users at public.kitware.com >>>> >>>> >>>> There has been some discussion about adding functionality to clip >>>> rectangles (bounding boxes) from images to yield another image (or >>>> image_container). If somebody is working on this, speak up :-) >>>> In any event, this is best implemented as an operator on an image(or >>>> image_container) and not a member. >>>> >>>> Thanks, >>>> -Linus >>>> >>>> On Sun, Nov 12, 2017 at 9:16 PM, Matt Brown >>>> wrote: >>>> >>>>> Is there an easy way to create a view into a window of a Vital image >>>>> akin to what you can do in OpenCV by applying a cv::Rect to a cv::Mat? I >>>>> couldn't find any examples in the repo of this being done. I was looking >>>>> into the 'image_of' class, and I could use that with the appropriate step >>>>> sizes. But, it would be ideal if a vital::image or even better >>>>> vital::image_container had this functionality built in. >>>>> >>>>> Thanks, >>>>> Matt >>>>> >>>>> _______________________________________________ >>>>> Kwiver-users mailing list >>>>> Kwiver-users at public.kitware.com >>>>> http://public.kitware.com/mailman/listinfo/kwiver-users >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Linus Sherrill - *Staff R&D Engineer >>>> Kitware, Inc. >>>> 28 Corporate Drive >>>> >>>> Clifton Park, NY 12065 >>>> >>>> -8662 >>>> E: linus.sherrill at kitware.com >>>> P: 518.881.4400 <(518)%20881-4400> >>>> >>>> _______________________________________________ >>>> Kwiver-users mailing list >>>> Kwiver-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/kwiver-users >>>> >>>> >>>> >>>> >>> >> > > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/kwiver-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.brown at kitware.com Wed Nov 15 11:35:12 2017 From: matt.brown at kitware.com (Matt Brown) Date: Wed, 15 Nov 2017 11:35:12 -0500 Subject: [Kwiver-users] Time logging in KWIVER Message-ID: Do we have or can we decide on a standard practice for logging processing time debug. I have gotten into the habit of wrapping the _step in my processes with kwiver::vital::wall_timer timer; timer.start(); ... timer.stop(); double elapsed_time = timer.elapsed(); LOG_DEBUG( logger(), "Elapsed time detecting objects: " << elapsed_time ); Some questions: - Should this be TRACE or DEBUG? - Should we should wall and/or CPU timing? - Will all of this be superseded by a more-unified framework that does this automatically? Best, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.tunison at kitware.com Wed Nov 15 11:59:17 2017 From: paul.tunison at kitware.com (Paul Tunison) Date: Wed, 15 Nov 2017 11:59:17 -0500 Subject: [Kwiver-users] Time logging in KWIVER In-Reply-To: References: Message-ID: We should generally not be using wall clock timing for performance measurement. On Wed, Nov 15, 2017 at 11:35 AM, Matt Brown wrote: > Do we have or can we decide on a standard practice for logging processing > time debug. I have gotten into the habit of wrapping the _step in my > processes with > > kwiver::vital::wall_timer timer; > timer.start(); > ... > timer.stop(); > double elapsed_time = timer.elapsed(); > LOG_DEBUG( logger(), "Elapsed time detecting objects: " << elapsed_time ); > > Some questions: > > - Should this be TRACE or DEBUG? > - Should we should wall and/or CPU timing? > - Will all of this be superseded by a more-unified framework that does > this automatically? > > Best, > Matt > > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/kwiver-users > > -- Paul Tunison Senior R&D Engineer Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 USA Phone: (518) 371-3971 Ext.164 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.brown at kitware.com Wed Nov 15 12:48:22 2017 From: matt.brown at kitware.com (Matt Brown) Date: Wed, 15 Nov 2017 12:48:22 -0500 Subject: [Kwiver-users] Time logging in KWIVER In-Reply-To: References: Message-ID: > > We should generally not be using wall clock timing for performance > measurement. > Aren't there instances where wall clock time is relevant (e.g., total latency)? In a pipeline, where processing gets blocked until something finishes, it can be helpful to identify bottle necks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.leotta at kitware.com Wed Nov 15 12:59:59 2017 From: matt.leotta at kitware.com (Matthew Leotta) Date: Wed, 15 Nov 2017 12:59:59 -0500 Subject: [Kwiver-users] Time logging in KWIVER In-Reply-To: References: Message-ID: Linus should chime in here. There is an instrumentation framework for exactly this sort of pipeline timing analysis. Linus know the most about this. ?Matt > On Nov 15, 2017, at 12:48 PM, Matt Brown wrote: > > We should generally not be using wall clock timing for performance measurement. > > Aren't there instances where wall clock time is relevant (e.g., total latency)? In a pipeline, where processing gets blocked until something finishes, it can be helpful to identify bottle necks. > > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/kwiver-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.brown at kitware.com Wed Nov 15 13:05:19 2017 From: matt.brown at kitware.com (Matt Brown) Date: Wed, 15 Nov 2017 13:05:19 -0500 Subject: [Kwiver-users] Time logging in KWIVER In-Reply-To: References: Message-ID: I found Linus' response from a previous question: > There is some emerging technology (read somewhat under used and under > tested) that can instrument processes. The support is in current master > branch, but there is a branch where I started adding the instrumentation > calls. > branch: dev/add-process-instrumentation > > Unfortunately the instrumentation is invasive and requires modification > of the processes but the overhead is minimal if instrumentation is not > enabled. > Once the instrumentation calls are added, it can be activated on a per > process basis via the process config in the pipe file. > > process my_process > :: my_process_type > _instrumentation:type = logger > > The above will enable the logger style instrumentation which generates a > log message for each start_*_processing() and stop_*_processing() call. > There is another one that uses RightTrack to generate execution time-lines > for the processes, but that approach requires building an external package > and other integration issues. This one has not been used is a while. Is the approach we are going to move toward? How ready is it currently? On Wed, Nov 15, 2017 at 12:59 PM, Matthew Leotta wrote: > Linus should chime in here. There is an instrumentation framework for > exactly this sort of pipeline timing analysis. Linus know the most about > this. > > ?Matt > > On Nov 15, 2017, at 12:48 PM, Matt Brown wrote: > > We should generally not be using wall clock timing for performance >> measurement. >> > > Aren't there instances where wall clock time is relevant (e.g., total > latency)? In a pipeline, where processing gets blocked until something > finishes, it can be helpful to identify bottle necks. > > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/kwiver-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From linus.sherrill at kitware.com Wed Nov 15 13:14:51 2017 From: linus.sherrill at kitware.com (Linus Sherrill) Date: Wed, 15 Nov 2017 13:14:51 -0500 Subject: [Kwiver-users] Time logging in KWIVER In-Reply-To: References: Message-ID: The current process instrumentation support is functional and I is in master. Most of the processes have been modified to implement the instrumentation calls. The logger instrumentation provider just log messages at the start and end events for each process entry. A new implementation could be created that would give elapsed (CPU or other) time for the process method. Maybe this is the time to revive the RightTrack application and use that for timing analysis. It has been languishing for quite a while and could use some UI and functional improvements. On Wed, Nov 15, 2017 at 1:05 PM, Matt Brown wrote: > I found Linus' response from a previous question: > > >> There is some emerging technology (read somewhat under used and under >> tested) that can instrument processes. The support is in current master >> branch, but there is a branch where I started adding the instrumentation >> calls. >> branch: dev/add-process-instrumentation >> >> Unfortunately the instrumentation is invasive and requires modification >> of the processes but the overhead is minimal if instrumentation is not >> enabled. >> Once the instrumentation calls are added, it can be activated on a per >> process basis via the process config in the pipe file. >> >> process my_process >> :: my_process_type >> _instrumentation:type = logger >> >> The above will enable the logger style instrumentation which generates a >> log message for each start_*_processing() and stop_*_processing() call. >> There is another one that uses RightTrack to generate execution >> time-lines for the processes, but that approach requires building an >> external package and other integration issues. This one has not been used >> is a while. > > > Is the approach we are going to move toward? How ready is it currently? > > On Wed, Nov 15, 2017 at 12:59 PM, Matthew Leotta > wrote: > >> Linus should chime in here. There is an instrumentation framework for >> exactly this sort of pipeline timing analysis. Linus know the most about >> this. >> >> ?Matt >> >> On Nov 15, 2017, at 12:48 PM, Matt Brown wrote: >> >> We should generally not be using wall clock timing for performance >>> measurement. >>> >> >> Aren't there instances where wall clock time is relevant (e.g., total >> latency)? In a pipeline, where processing gets blocked until something >> finishes, it can be helpful to identify bottle necks. >> >> _______________________________________________ >> Kwiver-users mailing list >> Kwiver-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/kwiver-users >> >> >> > > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/kwiver-users > > -- *Linus Sherrill - *Staff R&D Engineer Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065-8662 E: linus.sherrill at kitware.com P: 518.881.4400 -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.clipp at kitware.com Wed Nov 15 13:22:43 2017 From: brian.clipp at kitware.com (Brian Clipp) Date: Wed, 15 Nov 2017 18:22:43 +0000 Subject: [Kwiver-users] Fwd: [Kwiver-announce] Best practices for passing inherited types through Sprokit Pipeline In-Reply-To: <42B741D0-CC66-49CD-B6D8-2F22EE6B3AF2@kitware.com> References: <42B741D0-CC66-49CD-B6D8-2F22EE6B3AF2@kitware.com> Message-ID: Pushing the tread over to kwiver-users. I attached the original ppt. -Brian ---------- Forwarded message --------- From: Matthew Leotta Date: Wed, Nov 15, 2017 at 1:08 PM Subject: Re: [Kwiver-announce] Best practices for passing inherited types through Sprokit Pipeline To: Matt Phillips , Brian Clipp < brian.clipp at kitware.com> Cc: Guys, 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. 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. Thanks, Matt On Nov 15, 2017, at 12:56 PM, Matt Phillips wrote: 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. Matt On Wed, Nov 15, 2017 at 12:46 PM, Brian Clipp wrote: > Hi All. > > 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. > > Thoughts? > > Brian > > _______________________________________________ > Kwiver-announce mailing list > Kwiver-announce at public.kitware.com > http://public.kitware.com/mailman/listinfo/kwiver-announce > > _______________________________________________ Kwiver-announce mailing list Kwiver-announce at public.kitware.com http://public.kitware.com/mailman/listinfo/kwiver-announce -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Inherited Types in Sprokit Pipelines.pptx Type: application/vnd.openxmlformats-officedocument.presentationml.presentation Size: 51721 bytes Desc: not available URL: From matt.leotta at kitware.com Wed Nov 15 13:53:56 2017 From: matt.leotta at kitware.com (Matthew Leotta) Date: Wed, 15 Nov 2017 13:53:56 -0500 Subject: [Kwiver-users] Fwd: [Kwiver-announce] Best practices for passing inherited types through Sprokit Pipeline In-Reply-To: References: <42B741D0-CC66-49CD-B6D8-2F22EE6B3AF2@kitware.com> Message-ID: <7203A557-CC16-4A9E-8F26-4AE17C9E978C@kitware.com> 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. 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. ?Matt > On Nov 15, 2017, at 1:22 PM, Brian Clipp wrote: > > Pushing the tread over to kwiver-users. I attached the original ppt. > > -Brian > > ---------- Forwarded message --------- > From: Matthew Leotta > > Date: Wed, Nov 15, 2017 at 1:08 PM > Subject: Re: [Kwiver-announce] Best practices for passing inherited types through Sprokit Pipeline > To: Matt Phillips >, Brian Clipp > > Cc: > > > > Guys, > > 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. > > 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. > > Thanks, > Matt > > >> On Nov 15, 2017, at 12:56 PM, Matt Phillips > wrote: >> >> 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. >> >> Matt >> >> On Wed, Nov 15, 2017 at 12:46 PM, Brian Clipp > wrote: >> Hi All. >> >> 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. >> >> Thoughts? >> >> Brian >> >> _______________________________________________ >> Kwiver-announce mailing list >> Kwiver-announce at public.kitware.com >> http://public.kitware.com/mailman/listinfo/kwiver-announce >> >> >> _______________________________________________ >> Kwiver-announce mailing list >> Kwiver-announce at public.kitware.com >> http://public.kitware.com/mailman/listinfo/kwiver-announce > > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/kwiver-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.clipp at kitware.com Wed Nov 15 14:01:22 2017 From: brian.clipp at kitware.com (Brian Clipp) Date: Wed, 15 Nov 2017 19:01:22 +0000 Subject: [Kwiver-users] Fwd: [Kwiver-announce] Best practices for passing inherited types through Sprokit Pipeline In-Reply-To: <7203A557-CC16-4A9E-8F26-4AE17C9E978C@kitware.com> References: <42B741D0-CC66-49CD-B6D8-2F22EE6B3AF2@kitware.com> <7203A557-CC16-4A9E-8F26-4AE17C9E978C@kitware.com> Message-ID: 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. 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. -Brian On Wed, Nov 15, 2017 at 1:53 PM Matthew Leotta wrote: > 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. > > 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. > > ?Matt > > On Nov 15, 2017, at 1:22 PM, Brian Clipp wrote: > > Pushing the tread over to kwiver-users. I attached the original ppt. > > -Brian > > ---------- Forwarded message --------- > From: Matthew Leotta > Date: Wed, Nov 15, 2017 at 1:08 PM > Subject: Re: [Kwiver-announce] Best practices for passing inherited types > through Sprokit Pipeline > To: Matt Phillips , Brian Clipp < > brian.clipp at kitware.com> > Cc: > > > Guys, > > 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. > > 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. > > Thanks, > Matt > > > On Nov 15, 2017, at 12:56 PM, Matt Phillips > wrote: > > 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. > > Matt > > On Wed, Nov 15, 2017 at 12:46 PM, Brian Clipp > wrote: > >> Hi All. >> >> 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. >> >> Thoughts? >> >> Brian >> >> _______________________________________________ >> Kwiver-announce mailing list >> Kwiver-announce at public.kitware.com >> http://public.kitware.com/mailman/listinfo/kwiver-announce >> >> > _______________________________________________ > Kwiver-announce mailing list > Kwiver-announce at public.kitware.com > http://public.kitware.com/mailman/listinfo/kwiver-announce > > > > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/kwiver-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From linus.sherrill at kitware.com Wed Nov 15 14:05:41 2017 From: linus.sherrill at kitware.com (Linus Sherrill) Date: Wed, 15 Nov 2017 14:05:41 -0500 Subject: [Kwiver-users] Fwd: [Kwiver-announce] Best practices for passing inherited types through Sprokit Pipeline In-Reply-To: <7203A557-CC16-4A9E-8F26-4AE17C9E978C@kitware.com> References: <42B741D0-CC66-49CD-B6D8-2F22EE6B3AF2@kitware.com> <7203A557-CC16-4A9E-8F26-4AE17C9E978C@kitware.com> Message-ID: Passing polymorphic data in sprokit is becoming more desirable. Ports on processes declare a logical type (as a string) for the data being passed, and a concrete type that is in the actual data packet which is passed as a boost::any (or equivalent). The intent of the kwiver_type_traits is to provide a baseline association between the two. The logical types are checked when the pipeline is built. the concrete types are checked by the boost::any when the value is retrieved. There may be something that could be done through the type traits to define a polymorphic type and do the type-casting and error handling. On Wed, Nov 15, 2017 at 1:53 PM, Matthew Leotta wrote: > 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. > > 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. > > ?Matt > > On Nov 15, 2017, at 1:22 PM, Brian Clipp wrote: > > Pushing the tread over to kwiver-users. I attached the original ppt. > > -Brian > > ---------- Forwarded message --------- > From: Matthew Leotta > Date: Wed, Nov 15, 2017 at 1:08 PM > Subject: Re: [Kwiver-announce] Best practices for passing inherited types > through Sprokit Pipeline > To: Matt Phillips , Brian Clipp < > brian.clipp at kitware.com> > Cc: > > > Guys, > > 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. > > 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. > > Thanks, > Matt > > > On Nov 15, 2017, at 12:56 PM, Matt Phillips > wrote: > > 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. > > Matt > > On Wed, Nov 15, 2017 at 12:46 PM, Brian Clipp > wrote: > >> Hi All. >> >> 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. >> >> Thoughts? >> >> Brian >> >> _______________________________________________ >> Kwiver-announce mailing list >> Kwiver-announce at public.kitware.com >> http://public.kitware.com/mailman/listinfo/kwiver-announce >> >> > _______________________________________________ > Kwiver-announce mailing list > Kwiver-announce at public.kitware.com > http://public.kitware.com/mailman/listinfo/kwiver-announce > > > _______________ > ________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/kwiver-users > > > > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/kwiver-users > > -- *Linus Sherrill - *Staff R&D Engineer Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065-8662 E: linus.sherrill at kitware.com P: 518.881.4400 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.leotta at kitware.com Wed Nov 15 14:10:45 2017 From: matt.leotta at kitware.com (Matthew Leotta) Date: Wed, 15 Nov 2017 14:10:45 -0500 Subject: [Kwiver-users] Fwd: [Kwiver-announce] Best practices for passing inherited types through Sprokit Pipeline In-Reply-To: References: <42B741D0-CC66-49CD-B6D8-2F22EE6B3AF2@kitware.com> <7203A557-CC16-4A9E-8F26-4AE17C9E978C@kitware.com> Message-ID: <21E2F186-5255-41FB-90C5-4696F85B2966@kitware.com> 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. ?Matt > On Nov 15, 2017, at 2:01 PM, Brian Clipp wrote: > > 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. > 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. > > -Brian > > > On Wed, Nov 15, 2017 at 1:53 PM Matthew Leotta > wrote: > 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. > > 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. > > ?Matt > > >> On Nov 15, 2017, at 1:22 PM, Brian Clipp > wrote: >> > >> Pushing the tread over to kwiver-users. I attached the original ppt. >> >> -Brian >> >> ---------- Forwarded message --------- >> From: Matthew Leotta > >> Date: Wed, Nov 15, 2017 at 1:08 PM >> Subject: Re: [Kwiver-announce] Best practices for passing inherited types through Sprokit Pipeline >> To: Matt Phillips >, Brian Clipp > >> Cc: > >> >> >> Guys, >> >> 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. >> >> 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. >> >> Thanks, >> Matt >> >> >>> On Nov 15, 2017, at 12:56 PM, Matt Phillips > wrote: >>> >>> 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. >>> >>> Matt >>> >>> On Wed, Nov 15, 2017 at 12:46 PM, Brian Clipp > wrote: >>> Hi All. >>> >>> 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. >>> >>> Thoughts? >>> >>> Brian >>> >>> _______________________________________________ >>> Kwiver-announce mailing list >>> Kwiver-announce at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/kwiver-announce >>> >>> >>> _______________________________________________ >>> Kwiver-announce mailing list >>> Kwiver-announce at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/kwiver-announce >> > >> _______________________________________________ >> Kwiver-users mailing list >> Kwiver-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/kwiver-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.clipp at kitware.com Wed Nov 15 14:15:28 2017 From: brian.clipp at kitware.com (Brian Clipp) Date: Wed, 15 Nov 2017 19:15:28 +0000 Subject: [Kwiver-users] Fwd: [Kwiver-announce] Best practices for passing inherited types through Sprokit Pipeline In-Reply-To: <21E2F186-5255-41FB-90C5-4696F85B2966@kitware.com> References: <42B741D0-CC66-49CD-B6D8-2F22EE6B3AF2@kitware.com> <7203A557-CC16-4A9E-8F26-4AE17C9E978C@kitware.com> <21E2F186-5255-41FB-90C5-4696F85B2966@kitware.com> Message-ID: 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. -B On Wed, Nov 15, 2017 at 2:10 PM Matthew Leotta wrote: > 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. > > ?Matt > > On Nov 15, 2017, at 2:01 PM, Brian Clipp wrote: > > 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. > 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. > > -Brian > > > On Wed, Nov 15, 2017 at 1:53 PM Matthew Leotta > wrote: > >> 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. >> >> 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. >> >> ?Matt >> >> On Nov 15, 2017, at 1:22 PM, Brian Clipp wrote: >> >> Pushing the tread over to kwiver-users. I attached the original ppt. >> >> -Brian >> >> ---------- Forwarded message --------- >> From: Matthew Leotta >> Date: Wed, Nov 15, 2017 at 1:08 PM >> Subject: Re: [Kwiver-announce] Best practices for passing inherited types >> through Sprokit Pipeline >> To: Matt Phillips , Brian Clipp < >> brian.clipp at kitware.com> >> Cc: >> >> >> Guys, >> >> 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. >> >> 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. >> >> Thanks, >> Matt >> >> >> On Nov 15, 2017, at 12:56 PM, Matt Phillips >> wrote: >> >> 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. >> >> Matt >> >> On Wed, Nov 15, 2017 at 12:46 PM, Brian Clipp >> wrote: >> >>> Hi All. >>> >>> 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. >>> >>> Thoughts? >>> >>> Brian >>> >>> _______________________________________________ >>> Kwiver-announce mailing list >>> Kwiver-announce at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/kwiver-announce >>> >>> >> _______________________________________________ >> Kwiver-announce mailing list >> Kwiver-announce at public.kitware.com >> http://public.kitware.com/mailman/listinfo/kwiver-announce >> >> >> >> _______________________________________________ >> Kwiver-users mailing list >> Kwiver-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/kwiver-users >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.phillips at kitware.com Wed Nov 15 14:23:31 2017 From: matt.phillips at kitware.com (Matt Phillips) Date: Wed, 15 Nov 2017 14:23:31 -0500 Subject: [Kwiver-users] Fwd: [Kwiver-announce] Best practices for passing inherited types through Sprokit Pipeline In-Reply-To: References: <42B741D0-CC66-49CD-B6D8-2F22EE6B3AF2@kitware.com> <7203A557-CC16-4A9E-8F26-4AE17C9E978C@kitware.com> <21E2F186-5255-41FB-90C5-4696F85B2966@kitware.com> Message-ID: 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. Matt On Wed, Nov 15, 2017 at 2:15 PM, Brian Clipp wrote: > 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. > > -B > > > On Wed, Nov 15, 2017 at 2:10 PM Matthew Leotta > wrote: > >> 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. >> >> ?Matt >> >> On Nov 15, 2017, at 2:01 PM, Brian Clipp wrote: >> >> 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. >> 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. >> >> -Brian >> >> >> On Wed, Nov 15, 2017 at 1:53 PM Matthew Leotta >> wrote: >> >>> 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. >>> >>> 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. >>> >>> ?Matt >>> >>> On Nov 15, 2017, at 1:22 PM, Brian Clipp >>> wrote: >>> >>> Pushing the tread over to kwiver-users. I attached the original ppt. >>> >>> -Brian >>> >>> ---------- Forwarded message --------- >>> From: Matthew Leotta >>> Date: Wed, Nov 15, 2017 at 1:08 PM >>> Subject: Re: [Kwiver-announce] Best practices for passing inherited >>> types through Sprokit Pipeline >>> To: Matt Phillips , Brian Clipp < >>> brian.clipp at kitware.com> >>> Cc: >>> >>> >>> Guys, >>> >>> 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. >>> >>> 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. >>> >>> Thanks, >>> Matt >>> >>> >>> On Nov 15, 2017, at 12:56 PM, Matt Phillips >>> wrote: >>> >>> 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. >>> >>> Matt >>> >>> On Wed, Nov 15, 2017 at 12:46 PM, Brian Clipp >>> wrote: >>> >>>> Hi All. >>>> >>>> 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. >>>> >>>> Thoughts? >>>> >>>> Brian >>>> >>>> _______________________________________________ >>>> Kwiver-announce mailing list >>>> Kwiver-announce at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/kwiver-announce >>>> >>>> >>> _______________________________________________ >>> Kwiver-announce mailing list >>> Kwiver-announce at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/kwiver-announce >>> >>> >>> _______________ >>> ________________________________ >>> Kwiver-users mailing list >>> Kwiver-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/kwiver-users >>> >>> >>> >> > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/kwiver-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.leotta at kitware.com Wed Nov 15 14:25:53 2017 From: matt.leotta at kitware.com (Matthew Leotta) Date: Wed, 15 Nov 2017 14:25:53 -0500 Subject: [Kwiver-users] Fwd: [Kwiver-announce] Best practices for passing inherited types through Sprokit Pipeline In-Reply-To: References: <42B741D0-CC66-49CD-B6D8-2F22EE6B3AF2@kitware.com> <7203A557-CC16-4A9E-8F26-4AE17C9E978C@kitware.com> <21E2F186-5255-41FB-90C5-4696F85B2966@kitware.com> Message-ID: 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. > On Nov 15, 2017, at 2:23 PM, Matt Phillips wrote: > > 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. > > Matt > > On Wed, Nov 15, 2017 at 2:15 PM, Brian Clipp > wrote: > 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. > > -B > > > On Wed, Nov 15, 2017 at 2:10 PM Matthew Leotta > wrote: > 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. > > ?Matt > >> On Nov 15, 2017, at 2:01 PM, Brian Clipp > wrote: >> >> 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. >> 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. >> >> -Brian >> >> >> On Wed, Nov 15, 2017 at 1:53 PM Matthew Leotta > wrote: >> 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. >> >> 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. >> >> ?Matt >> >> >>> On Nov 15, 2017, at 1:22 PM, Brian Clipp > wrote: >>> >> >>> Pushing the tread over to kwiver-users. I attached the original ppt. >>> >>> -Brian >>> >>> ---------- Forwarded message --------- >>> From: Matthew Leotta > >>> Date: Wed, Nov 15, 2017 at 1:08 PM >>> Subject: Re: [Kwiver-announce] Best practices for passing inherited types through Sprokit Pipeline >>> To: Matt Phillips >, Brian Clipp > >>> Cc: > >>> >>> >>> Guys, >>> >>> 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. >>> >>> 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. >>> >>> Thanks, >>> Matt >>> >>> >>>> On Nov 15, 2017, at 12:56 PM, Matt Phillips > wrote: >>>> >>>> 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. >>>> >>>> Matt >>>> >>>> On Wed, Nov 15, 2017 at 12:46 PM, Brian Clipp > wrote: >>>> Hi All. >>>> >>>> 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. >>>> >>>> Thoughts? >>>> >>>> Brian >>>> >>>> _______________________________________________ >>>> Kwiver-announce mailing list >>>> Kwiver-announce at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/kwiver-announce >>>> >>>> >>>> _______________________________________________ >>>> Kwiver-announce mailing list >>>> Kwiver-announce at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/kwiver-announce >>> >> >>> _______________________________________________ >>> Kwiver-users mailing list >>> Kwiver-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/kwiver-users >> > > > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/kwiver-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.phillips at kitware.com Wed Nov 15 14:37:11 2017 From: matt.phillips at kitware.com (Matt Phillips) Date: Wed, 15 Nov 2017 14:37:11 -0500 Subject: [Kwiver-users] Fwd: [Kwiver-announce] Best practices for passing inherited types through Sprokit Pipeline In-Reply-To: References: <42B741D0-CC66-49CD-B6D8-2F22EE6B3AF2@kitware.com> <7203A557-CC16-4A9E-8F26-4AE17C9E978C@kitware.com> <21E2F186-5255-41FB-90C5-4696F85B2966@kitware.com> Message-ID: Forget the exact signature but class feature_track_set : public ... { ... static std::string type_string() { return "feature_track_set,track_set"; } } 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. On Wed, Nov 15, 2017 at 2:25 PM, Matthew Leotta wrote: > 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. > > On Nov 15, 2017, at 2:23 PM, Matt Phillips > wrote: > > 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. > > Matt > > On Wed, Nov 15, 2017 at 2:15 PM, Brian Clipp > wrote: > >> 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. >> >> -B >> >> >> On Wed, Nov 15, 2017 at 2:10 PM Matthew Leotta >> wrote: >> >>> 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. >>> >>> ?Matt >>> >>> On Nov 15, 2017, at 2:01 PM, Brian Clipp >>> wrote: >>> >>> 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. >>> 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. >>> >>> -Brian >>> >>> >>> On Wed, Nov 15, 2017 at 1:53 PM Matthew Leotta >>> wrote: >>> >>>> 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. >>>> >>>> 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. >>>> >>>> ?Matt >>>> >>>> On Nov 15, 2017, at 1:22 PM, Brian Clipp >>>> wrote: >>>> >>>> Pushing the tread over to kwiver-users. I attached the original ppt. >>>> >>>> -Brian >>>> >>>> ---------- Forwarded message --------- >>>> From: Matthew Leotta >>>> Date: Wed, Nov 15, 2017 at 1:08 PM >>>> Subject: Re: [Kwiver-announce] Best practices for passing inherited >>>> types through Sprokit Pipeline >>>> To: Matt Phillips , Brian Clipp < >>>> brian.clipp at kitware.com> >>>> Cc: >>>> >>>> >>>> Guys, >>>> >>>> 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. >>>> >>>> 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. >>>> >>>> Thanks, >>>> Matt >>>> >>>> >>>> On Nov 15, 2017, at 12:56 PM, Matt Phillips >>>> wrote: >>>> >>>> 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. >>>> >>>> Matt >>>> >>>> On Wed, Nov 15, 2017 at 12:46 PM, Brian Clipp >>>> wrote: >>>> >>>>> Hi All. >>>>> >>>>> 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. >>>>> >>>>> Thoughts? >>>>> >>>>> Brian >>>>> >>>>> _______________________________________________ >>>>> Kwiver-announce mailing list >>>>> Kwiver-announce at public.kitware.com >>>>> http://public.kitware.com/mailman/listinfo/kwiver-announce >>>>> >>>>> >>>> _______________________________________________ >>>> Kwiver-announce mailing list >>>> Kwiver-announce at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/kwiver-announce >>>> >>>> >>>> _______________ >>>> ________________________________ >>>> Kwiver-users mailing list >>>> Kwiver-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/kwiver-users >>>> >>>> >>>> >>> >> _______________________________________________ >> Kwiver-users mailing list >> Kwiver-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/kwiver-users >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.leotta at kitware.com Wed Nov 15 14:51:01 2017 From: matt.leotta at kitware.com (Matthew Leotta) Date: Wed, 15 Nov 2017 14:51:01 -0500 Subject: [Kwiver-users] Fwd: [Kwiver-announce] Best practices for passing inherited types through Sprokit Pipeline In-Reply-To: References: <42B741D0-CC66-49CD-B6D8-2F22EE6B3AF2@kitware.com> <7203A557-CC16-4A9E-8F26-4AE17C9E978C@kitware.com> <21E2F186-5255-41FB-90C5-4696F85B2966@kitware.com> Message-ID: <87A446A7-A631-4891-B3A4-523FCAC26268@kitware.com> 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. > On Nov 15, 2017, at 2:37 PM, Matt Phillips wrote: > > Forget the exact signature but > > class feature_track_set : public ... > { > ... > static std::string type_string() { return "feature_track_set,track_set"; } > } > > 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. > > On Wed, Nov 15, 2017 at 2:25 PM, Matthew Leotta > wrote: > 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. > >> On Nov 15, 2017, at 2:23 PM, Matt Phillips > wrote: >> >> 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. >> >> Matt >> >> On Wed, Nov 15, 2017 at 2:15 PM, Brian Clipp > wrote: >> 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. >> >> -B >> >> >> On Wed, Nov 15, 2017 at 2:10 PM Matthew Leotta > wrote: >> 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. >> >> ?Matt >> >>> On Nov 15, 2017, at 2:01 PM, Brian Clipp > wrote: >>> >>> 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. >>> 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. >>> >>> -Brian >>> >>> >>> On Wed, Nov 15, 2017 at 1:53 PM Matthew Leotta > wrote: >>> 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. >>> >>> 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. >>> >>> ?Matt >>> >>> >>>> On Nov 15, 2017, at 1:22 PM, Brian Clipp > wrote: >>>> >>> >>>> Pushing the tread over to kwiver-users. I attached the original ppt. >>>> >>>> -Brian >>>> >>>> ---------- Forwarded message --------- >>>> From: Matthew Leotta > >>>> Date: Wed, Nov 15, 2017 at 1:08 PM >>>> Subject: Re: [Kwiver-announce] Best practices for passing inherited types through Sprokit Pipeline >>>> To: Matt Phillips >, Brian Clipp > >>>> Cc: > >>>> >>>> >>>> Guys, >>>> >>>> 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. >>>> >>>> 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. >>>> >>>> Thanks, >>>> Matt >>>> >>>> >>>>> On Nov 15, 2017, at 12:56 PM, Matt Phillips > wrote: >>>>> >>>>> 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. >>>>> >>>>> Matt >>>>> >>>>> On Wed, Nov 15, 2017 at 12:46 PM, Brian Clipp > wrote: >>>>> Hi All. >>>>> >>>>> 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. >>>>> >>>>> Thoughts? >>>>> >>>>> Brian >>>>> >>>>> _______________________________________________ >>>>> Kwiver-announce mailing list >>>>> Kwiver-announce at public.kitware.com >>>>> http://public.kitware.com/mailman/listinfo/kwiver-announce >>>>> >>>>> >>>>> _______________________________________________ >>>>> Kwiver-announce mailing list >>>>> Kwiver-announce at public.kitware.com >>>>> http://public.kitware.com/mailman/listinfo/kwiver-announce >>>> >>> >>>> _______________________________________________ >>>> Kwiver-users mailing list >>>> Kwiver-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/kwiver-users >>> >> >> >> _______________________________________________ >> Kwiver-users mailing list >> Kwiver-users at public.kitware.com >> http://public.kitware.com/mailman/listinfo/kwiver-users >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.clipp at kitware.com Wed Nov 15 14:51:55 2017 From: brian.clipp at kitware.com (Brian Clipp) Date: Wed, 15 Nov 2017 19:51:55 +0000 Subject: [Kwiver-users] Fwd: [Kwiver-announce] Best practices for passing inherited types through Sprokit Pipeline In-Reply-To: <87A446A7-A631-4891-B3A4-523FCAC26268@kitware.com> References: <42B741D0-CC66-49CD-B6D8-2F22EE6B3AF2@kitware.com> <7203A557-CC16-4A9E-8F26-4AE17C9E978C@kitware.com> <21E2F186-5255-41FB-90C5-4696F85B2966@kitware.com> <87A446A7-A631-4891-B3A4-523FCAC26268@kitware.com> Message-ID: Would we allow down-casting? -B On Wed, Nov 15, 2017 at 2:51 PM Matthew Leotta wrote: > 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. > > > On Nov 15, 2017, at 2:37 PM, Matt Phillips > wrote: > > Forget the exact signature but > > class feature_track_set : public ... > { > ... > static std::string type_string() { return > "feature_track_set,track_set"; } > } > > 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. > > On Wed, Nov 15, 2017 at 2:25 PM, Matthew Leotta > wrote: > >> 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. >> >> On Nov 15, 2017, at 2:23 PM, Matt Phillips >> wrote: >> >> 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. >> >> Matt >> >> On Wed, Nov 15, 2017 at 2:15 PM, Brian Clipp >> wrote: >> >>> 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. >>> >>> -B >>> >>> >>> On Wed, Nov 15, 2017 at 2:10 PM Matthew Leotta >>> wrote: >>> >>>> 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. >>>> >>>> ?Matt >>>> >>>> On Nov 15, 2017, at 2:01 PM, Brian Clipp >>>> wrote: >>>> >>>> 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. >>>> 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. >>>> >>>> -Brian >>>> >>>> >>>> On Wed, Nov 15, 2017 at 1:53 PM Matthew Leotta >>>> wrote: >>>> >>>>> 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. >>>>> >>>>> 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. >>>>> >>>>> ?Matt >>>>> >>>>> On Nov 15, 2017, at 1:22 PM, Brian Clipp >>>>> wrote: >>>>> >>>>> Pushing the tread over to kwiver-users. I attached the original ppt. >>>>> >>>>> -Brian >>>>> >>>>> ---------- Forwarded message --------- >>>>> From: Matthew Leotta >>>>> Date: Wed, Nov 15, 2017 at 1:08 PM >>>>> Subject: Re: [Kwiver-announce] Best practices for passing inherited >>>>> types through Sprokit Pipeline >>>>> To: Matt Phillips , Brian Clipp < >>>>> brian.clipp at kitware.com> >>>>> Cc: >>>>> >>>>> >>>>> Guys, >>>>> >>>>> 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. >>>>> >>>>> 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. >>>>> >>>>> Thanks, >>>>> Matt >>>>> >>>>> >>>>> On Nov 15, 2017, at 12:56 PM, Matt Phillips >>>>> wrote: >>>>> >>>>> 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. >>>>> >>>>> Matt >>>>> >>>>> On Wed, Nov 15, 2017 at 12:46 PM, Brian Clipp >>>> > wrote: >>>>> >>>>>> Hi All. >>>>>> >>>>>> 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. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> Brian >>>>>> >>>>>> _______________________________________________ >>>>>> Kwiver-announce mailing list >>>>>> Kwiver-announce at public.kitware.com >>>>>> http://public.kitware.com/mailman/listinfo/kwiver-announce >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Kwiver-announce mailing list >>>>> Kwiver-announce at public.kitware.com >>>>> http://public.kitware.com/mailman/listinfo/kwiver-announce >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Kwiver-users mailing list >>>>> Kwiver-users at public.kitware.com >>>>> http://public.kitware.com/mailman/listinfo/kwiver-users >>>>> >>>>> >>>>> >>>> >>> _______________________________________________ >>> Kwiver-users mailing list >>> Kwiver-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/kwiver-users >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.leotta at kitware.com Wed Nov 15 14:58:02 2017 From: matt.leotta at kitware.com (Matthew Leotta) Date: Wed, 15 Nov 2017 14:58:02 -0500 Subject: [Kwiver-users] Fwd: [Kwiver-announce] Best practices for passing inherited types through Sprokit Pipeline In-Reply-To: References: <42B741D0-CC66-49CD-B6D8-2F22EE6B3AF2@kitware.com> <7203A557-CC16-4A9E-8F26-4AE17C9E978C@kitware.com> <21E2F186-5255-41FB-90C5-4696F85B2966@kitware.com> <87A446A7-A631-4891-B3A4-523FCAC26268@kitware.com> Message-ID: 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. My understanding of the state of sprokit is a little outdated so someone correct me if I?m wrong about the type matching thing. ?Matt > On Nov 15, 2017, at 2:51 PM, Brian Clipp wrote: > > Would we allow down-casting? > > -B > > On Wed, Nov 15, 2017 at 2:51 PM Matthew Leotta > wrote: > 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. > > >> On Nov 15, 2017, at 2:37 PM, Matt Phillips > wrote: >> >> Forget the exact signature but >> >> class feature_track_set : public ... >> { >> ... >> static std::string type_string() { return "feature_track_set,track_set"; } >> } >> >> 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. >> >> On Wed, Nov 15, 2017 at 2:25 PM, Matthew Leotta > wrote: >> 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. >> >>> On Nov 15, 2017, at 2:23 PM, Matt Phillips > wrote: >>> >>> 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. >>> >>> Matt >>> >>> On Wed, Nov 15, 2017 at 2:15 PM, Brian Clipp > wrote: >>> 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. >>> >>> -B >>> >>> >>> On Wed, Nov 15, 2017 at 2:10 PM Matthew Leotta > wrote: >>> 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. >>> >>> ?Matt >>> >>>> On Nov 15, 2017, at 2:01 PM, Brian Clipp > wrote: >>>> >>>> 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. >>>> 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. >>>> >>>> -Brian >>>> >>>> >>>> On Wed, Nov 15, 2017 at 1:53 PM Matthew Leotta > wrote: >>>> 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. >>>> >>>> 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. >>>> >>>> ?Matt >>>> >>>> >>>>> On Nov 15, 2017, at 1:22 PM, Brian Clipp > wrote: >>>>> >>>> >>>>> Pushing the tread over to kwiver-users. I attached the original ppt. >>>>> >>>>> -Brian >>>>> >>>>> ---------- Forwarded message --------- >>>>> From: Matthew Leotta > >>>>> Date: Wed, Nov 15, 2017 at 1:08 PM >>>>> Subject: Re: [Kwiver-announce] Best practices for passing inherited types through Sprokit Pipeline >>>>> To: Matt Phillips >, Brian Clipp > >>>>> Cc: > >>>>> >>>>> >>>>> Guys, >>>>> >>>>> 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. >>>>> >>>>> 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. >>>>> >>>>> Thanks, >>>>> Matt >>>>> >>>>> >>>>>> On Nov 15, 2017, at 12:56 PM, Matt Phillips > wrote: >>>>>> >>>>>> 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. >>>>>> >>>>>> Matt >>>>>> >>>>>> On Wed, Nov 15, 2017 at 12:46 PM, Brian Clipp > wrote: >>>>>> Hi All. >>>>>> >>>>>> 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. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> Brian >>>>>> >>>>>> _______________________________________________ >>>>>> Kwiver-announce mailing list >>>>>> Kwiver-announce at public.kitware.com >>>>>> http://public.kitware.com/mailman/listinfo/kwiver-announce >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Kwiver-announce mailing list >>>>>> Kwiver-announce at public.kitware.com >>>>>> http://public.kitware.com/mailman/listinfo/kwiver-announce >>>>> >>>> >>>>> _______________________________________________ >>>>> Kwiver-users mailing list >>>>> Kwiver-users at public.kitware.com >>>>> http://public.kitware.com/mailman/listinfo/kwiver-users >>>> >>> >>> >>> _______________________________________________ >>> Kwiver-users mailing list >>> Kwiver-users at public.kitware.com >>> http://public.kitware.com/mailman/listinfo/kwiver-users >>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From linus.sherrill at kitware.com Wed Nov 15 15:39:02 2017 From: linus.sherrill at kitware.com (Linus Sherrill) Date: Wed, 15 Nov 2017 15:39:02 -0500 Subject: [Kwiver-users] Fwd: [Kwiver-announce] Best practices for passing inherited types through Sprokit Pipeline In-Reply-To: References: <42B741D0-CC66-49CD-B6D8-2F22EE6B3AF2@kitware.com> <7203A557-CC16-4A9E-8F26-4AE17C9E978C@kitware.com> <21E2F186-5255-41FB-90C5-4696F85B2966@kitware.com> <87A446A7-A631-4891-B3A4-523FCAC26268@kitware.com> Message-ID: 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. I am working on an idea to support casting data elements using the port trait infrastructure. The call would look something like auto value = get_from_port_using_trait( port-name ); 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. 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. Anyhow, it is just a concept in the early stages... On Wed, Nov 15, 2017 at 2:58 PM, Matthew Leotta wrote: > 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. > > My understanding of the state of sprokit is a little outdated so someone > correct me if I?m wrong about the type matching thing. > > ?Matt > > On Nov 15, 2017, at 2:51 PM, Brian Clipp wrote: > > Would we allow down-casting? > > -B > > On Wed, Nov 15, 2017 at 2:51 PM Matthew Leotta > wrote: > >> 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. >> >> >> On Nov 15, 2017, at 2:37 PM, Matt Phillips >> wrote: >> >> Forget the exact signature but >> >> class feature_track_set : public ... >> { >> ... >> static std::string type_string() { return >> "feature_track_set,track_set"; } >> } >> >> 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. >> >> On Wed, Nov 15, 2017 at 2:25 PM, Matthew Leotta >> wrote: >> >>> 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. >>> >>> On Nov 15, 2017, at 2:23 PM, Matt Phillips >>> wrote: >>> >>> 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. >>> >>> Matt >>> >>> On Wed, Nov 15, 2017 at 2:15 PM, Brian Clipp >>> wrote: >>> >>>> 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. >>>> >>>> -B >>>> >>>> >>>> On Wed, Nov 15, 2017 at 2:10 PM Matthew Leotta >>>> wrote: >>>> >>>>> 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. >>>>> >>>>> ?Matt >>>>> >>>>> On Nov 15, 2017, at 2:01 PM, Brian Clipp >>>>> wrote: >>>>> >>>>> 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. >>>>> 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. >>>>> >>>>> -Brian >>>>> >>>>> >>>>> On Wed, Nov 15, 2017 at 1:53 PM Matthew Leotta < >>>>> matt.leotta at kitware.com> wrote: >>>>> >>>>>> 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. >>>>>> >>>>>> 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. >>>>>> >>>>>> ?Matt >>>>>> >>>>>> On Nov 15, 2017, at 1:22 PM, Brian Clipp >>>>>> wrote: >>>>>> >>>>>> Pushing the tread over to kwiver-users. I attached the original ppt. >>>>>> >>>>>> -Brian >>>>>> >>>>>> ---------- Forwarded message --------- >>>>>> From: Matthew Leotta >>>>>> Date: Wed, Nov 15, 2017 at 1:08 PM >>>>>> Subject: Re: [Kwiver-announce] Best practices for passing inherited >>>>>> types through Sprokit Pipeline >>>>>> To: Matt Phillips , Brian Clipp < >>>>>> brian.clipp at kitware.com> >>>>>> Cc: >>>>>> >>>>>> >>>>>> Guys, >>>>>> >>>>>> 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. >>>>>> >>>>>> 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. >>>>>> >>>>>> Thanks, >>>>>> Matt >>>>>> >>>>>> >>>>>> On Nov 15, 2017, at 12:56 PM, Matt Phillips < >>>>>> matt.phillips at kitware.com> wrote: >>>>>> >>>>>> 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. >>>>>> >>>>>> Matt >>>>>> >>>>>> On Wed, Nov 15, 2017 at 12:46 PM, Brian Clipp < >>>>>> brian.clipp at kitware.com> wrote: >>>>>> >>>>>>> Hi All. >>>>>>> >>>>>>> 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. >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Kwiver-announce mailing list >>>>>>> Kwiver-announce at public.kitware.com >>>>>>> http://public.kitware.com/mailman/listinfo/kwiver-announce >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Kwiver-announce mailing list >>>>>> Kwiver-announce at public.kitware.com >>>>>> http://public.kitware.com/mailman/listinfo/kwiver-announce >>>>>> >>>>>> >>>>>> _______________ >>>>>> ________________________________ >>>>>> Kwiver-users mailing list >>>>>> Kwiver-users at public.kitware.com >>>>>> http://public.kitware.com/mailman/listinfo/kwiver-users >>>>>> >>>>>> >>>>>> >>>>> >>>> _______________________________________________ >>>> Kwiver-users mailing list >>>> Kwiver-users at public.kitware.com >>>> http://public.kitware.com/mailman/listinfo/kwiver-users >>>> >>>> >>> >>> >> >> > > _______________________________________________ > Kwiver-users mailing list > Kwiver-users at public.kitware.com > http://public.kitware.com/mailman/listinfo/kwiver-users > > -- *Linus Sherrill - *Staff R&D Engineer Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065-8662 E: linus.sherrill at kitware.com P: 518.881.4400 -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron.bray at kitware.com Thu Nov 16 08:43:15 2017 From: aaron.bray at kitware.com (Aaron Bray) Date: Thu, 16 Nov 2017 08:43:15 -0500 Subject: [Kwiver-users] Pipelines with a lot of transient file I/O Message-ID: Is there any standard way of handling a pipeline that is going to require a lot of transient file I/O For example, encapsulation of C3D for activity recognition. We are going to want to provide C3D a video file on disk to consume, and it is going to write out some binary information to disc that a post processing algorithm (potentially in another process) is going to sift through. Is there maybe a way that a pipeline can manage a folder on disk to direct its process as a working space for files, and have the option to clean up that folder when the pipeline completes. Or maybe its up to the processes to clean up the disk? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron.bray at kitware.com Thu Nov 30 10:44:36 2017 From: aaron.bray at kitware.com (Aaron Bray) Date: Thu, 30 Nov 2017 10:44:36 -0500 Subject: [Kwiver-users] kwiver config Message-ID: Much like fletch, Is there a plan (or can we make one) to put configuration options into the kwiver-config.cmake file so programs that find_package(kwiver) can test to see if that kwiver has certain arrows So I can do things like this in my DIVA cmake to make sure a user provided kwiver has everything DIVA needs: if(kwiver_ENABLED_OpenCV) I am willing to start it with things I need, but if somebody has more familiarity with the standard and all the options we want in that file, that would help too Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: