[jira] [Commented] (UIMA-5115) uv3 select() api for iterators and streams over CAS contents
[ https://issues.apache.org/jira/browse/UIMA-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1554#comment-1554 ] Marshall Schor commented on UIMA-5115: -- for now, I'll keep the offset, but add a limit( n ) to the set of builder-keywords supported by select (rather than converting to stream.limit) - this will allow forms like: {code}cas.select(MyType.class).limit(3).coveredBy(fs).toArray(){code} > uv3 select() api for iterators and streams over CAS contents > > > Key: UIMA-5115 > URL: https://issues.apache.org/jira/browse/UIMA-5115 > Project: UIMA > Issue Type: New Feature > Components: Core Java Framework >Reporter: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDKexp > > > Design and implement a select() API based on uimaFIT's select, integrated > well with Java 8 concepts. Initial discussions in UIMA-1524. Wiki with > diagram: https://cwiki.apache.org/confluence/display/UIMA/UV3+Iterator+support -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (UIMA-5115) uv3 select() api for iterators and streams over CAS contents
[ https://issues.apache.org/jira/browse/UIMA-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533213#comment-15533213 ] Marshall Schor edited comment on UIMA-5115 at 9/29/16 4:58 PM: --- even though limit( n ) is a stream thing, we don't need to implement it that way. So we have a choice. was (Author: schor): even though limit(n) is a stream thing, we don't need to implement it that way. So we have a choice. > uv3 select() api for iterators and streams over CAS contents > > > Key: UIMA-5115 > URL: https://issues.apache.org/jira/browse/UIMA-5115 > Project: UIMA > Issue Type: New Feature > Components: Core Java Framework >Reporter: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDKexp > > > Design and implement a select() API based on uimaFIT's select, integrated > well with Java 8 concepts. Initial discussions in UIMA-1524. Wiki with > diagram: https://cwiki.apache.org/confluence/display/UIMA/UV3+Iterator+support -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (UIMA-5115) uv3 select() api for iterators and streams over CAS contents
[ https://issues.apache.org/jira/browse/UIMA-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533213#comment-15533213 ] Marshall Schor commented on UIMA-5115: -- even though limit(n) is a stream thing, we don't need to implement it that way. So we have a choice. > uv3 select() api for iterators and streams over CAS contents > > > Key: UIMA-5115 > URL: https://issues.apache.org/jira/browse/UIMA-5115 > Project: UIMA > Issue Type: New Feature > Components: Core Java Framework >Reporter: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDKexp > > > Design and implement a select() API based on uimaFIT's select, integrated > well with Java 8 concepts. Initial discussions in UIMA-1524. Wiki with > diagram: https://cwiki.apache.org/confluence/display/UIMA/UV3+Iterator+support -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (UIMA-5115) uv3 select() api for iterators and streams over CAS contents
[ https://issues.apache.org/jira/browse/UIMA-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533199#comment-15533199 ] Richard Eckart de Castilho commented on UIMA-5115: -- limit() is a Stream API method and offset() is not. So I guess after calling limit() we are in stream-land and no longer in SelectFS-land... at least unless we employ covariant return-types... and even if use covariant return types we'd always need to have limit() as a separate call... so I'd tend a bit more towards keeping the offset as the positional parameter... unsure... > uv3 select() api for iterators and streams over CAS contents > > > Key: UIMA-5115 > URL: https://issues.apache.org/jira/browse/UIMA-5115 > Project: UIMA > Issue Type: New Feature > Components: Core Java Framework >Reporter: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDKexp > > > Design and implement a select() API based on uimaFIT's select, integrated > well with Java 8 concepts. Initial discussions in UIMA-1524. Wiki with > diagram: https://cwiki.apache.org/confluence/display/UIMA/UV3+Iterator+support -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (UIMA-5115) uv3 select() api for iterators and streams over CAS contents
[ https://issues.apache.org/jira/browse/UIMA-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533169#comment-15533169 ] Marshall Schor commented on UIMA-5115: -- uimaFIT has a param for following/preceding that limits the number of annotations returned. The general "positioning" alternatives include a FS, begin/end, and those two plus a possible "offset". These seem to possibly confict when designing APIs. (offset(n) here means after positioning the iterator to some start position, before starting, do "n" moveToPrevious/Next() operations). I tend to think that limit(n) is more popular than offset(n); if so, perhaps we should offer it the optional positional parameter spot uniformly in all the API variants instead of offset? Examples: {code} cas.select(MyType.class).startAt(begin, end, limit).offset(3) // limit is (optional) positional, offset via keyword cas.select(MyType.class).startAt(begin, end, offset).limit(4) // offset is (optional) positional, limit via keyword cas.select(MyType.class).following(begin, end, limit).offset(3) // limit is (optional) positional, offset via keyword cas.select(MyType.class).following(begin, end, offset).limit(4) // offset is (optional) positional, limit via keyword {code} Other ideas or preferences? I don't have a strong preference, except I'm slightly in favor of being consistent. * The inconsistent approach would be to have it one way for, say,, coveredBy, and the other way for following. > uv3 select() api for iterators and streams over CAS contents > > > Key: UIMA-5115 > URL: https://issues.apache.org/jira/browse/UIMA-5115 > Project: UIMA > Issue Type: New Feature > Components: Core Java Framework >Reporter: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDKexp > > > Design and implement a select() API based on uimaFIT's select, integrated > well with Java 8 concepts. Initial discussions in UIMA-1524. Wiki with > diagram: https://cwiki.apache.org/confluence/display/UIMA/UV3+Iterator+support -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (UIMA-5124) DUCC-MON doesn'y display the Reason for WaitingForResources for jobs
[ https://issues.apache.org/jira/browse/UIMA-5124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Burn Lewis closed UIMA-5124. > DUCC-MON doesn'y display the Reason for WaitingForResources for jobs > > > Key: UIMA-5124 > URL: https://issues.apache.org/jira/browse/UIMA-5124 > Project: UIMA > Issue Type: Bug > Components: DUCC >Reporter: Burn Lewis >Assignee: Burn Lewis >Priority: Minor > Fix For: future-DUCC > > > The "no resources available" reason is shown for reservations but is missing > for jobs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (UIMA-5124) DUCC-MON doesn'y display the Reason for WaitingForResources for jobs
[ https://issues.apache.org/jira/browse/UIMA-5124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Burn Lewis resolved UIMA-5124. -- Resolution: Fixed Set the reason for jobs waiting for resources > DUCC-MON doesn'y display the Reason for WaitingForResources for jobs > > > Key: UIMA-5124 > URL: https://issues.apache.org/jira/browse/UIMA-5124 > Project: UIMA > Issue Type: Bug > Components: DUCC >Reporter: Burn Lewis >Assignee: Burn Lewis >Priority: Minor > Fix For: future-DUCC > > > The "no resources available" reason is shown for reservations but is missing > for jobs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (UIMA-5124) DUCC-MON doesn'y display the Reason for WaitingForResources for jobs
Burn Lewis created UIMA-5124: Summary: DUCC-MON doesn'y display the Reason for WaitingForResources for jobs Key: UIMA-5124 URL: https://issues.apache.org/jira/browse/UIMA-5124 Project: UIMA Issue Type: Bug Components: DUCC Reporter: Burn Lewis Assignee: Burn Lewis Priority: Minor Fix For: future-DUCC The "no resources available" reason is shown for reservations but is missing for jobs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (UIMA-5115) uv3 select() api for iterators and streams over CAS contents
[ https://issues.apache.org/jira/browse/UIMA-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15532099#comment-15532099 ] Richard Eckart de Castilho commented on UIMA-5115: -- For the moment, I would suggest that "coveredBy" and "following" be of the same category "location constraint" and are mutually exclusive. > uv3 select() api for iterators and streams over CAS contents > > > Key: UIMA-5115 > URL: https://issues.apache.org/jira/browse/UIMA-5115 > Project: UIMA > Issue Type: New Feature > Components: Core Java Framework >Reporter: Marshall Schor >Priority: Minor > Fix For: 3.0.0SDKexp > > > Design and implement a select() API based on uimaFIT's select, integrated > well with Java 8 concepts. Initial discussions in UIMA-1524. Wiki with > diagram: https://cwiki.apache.org/confluence/display/UIMA/UV3+Iterator+support -- This message was sent by Atlassian JIRA (v6.3.4#6332)