[jira] [Comment Edited] (UIMA-5115) uv3 select() api for iterators and streams over CAS contents

[Marshall Schor (JIRA)]

[ 
https://issues.apache.org/jira/browse/UIMA-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15504781#comment-15504781
 ] 

Marshall Schor edited comment on UIMA-5115 at 9/19/16 9:47 PM:
---

Does uimaFIT iteration for coveredBy(fs1) filter the result by the type of fs1? 
 That is, if fs1's begin and end specify 10 FSs, but only 3 of them are of the 
type/subtype of fs1, does the result only have those 3 FSs?  I don't believe 
UIMA's subiterator design does this filtering - it just uses the fs1 for bounds 
and for type priority ordering (not type/subtype filtering).  It would seem 
this is not needed - could be covered by just selecting the type wanted 
already, ahead in the select spec, etc.


was (Author: schor):
Does uimaFIT iteration for coveredBy(fs1) filter the result by the type of fs1? 
 That is, if fs1's begin and end specify 10 FSs, but only 3 of them are of the 
type/subtype of fs1, does the result only have those 3 FSs?  I don't believe 
UIMA's subiterator design does this filtering - it just uses the fs1 for bounds 
and for type priority ordering (not type/subtype filtering).

> 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

[Marshall Schor (JIRA)]

[ 
https://issues.apache.org/jira/browse/UIMA-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15504781#comment-15504781
 ] 

Marshall Schor commented on UIMA-5115:
--

Does uimaFIT iteration for coveredBy(fs1) filter the result by the type of fs1? 
 That is, if fs1's begin and end specify 10 FSs, but only 3 of them are of the 
type/subtype of fs1, does the result only have those 3 FSs?  I don't believe 
UIMA's subiterator design does this filtering - it just uses the fs1 for bounds 
and for type priority ordering (not type/subtype filtering).

> 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)

Re: Jenkins build is still unstable: UIMA-AS #421

[Jaroslaw Cwiklik]

Marshall, the problem with failing JUnit tests has been fixed. Also,
reduced verbosity of JUnit tests to make tests easier to review. I still
see IOException happening at the end of some tests. This is logged by an
embedded AMQ broker. In some case these are expected as brokers are being
shutdown on purpose to simulate failover and recovery.

-jerry

On Tue, Sep 6, 2016 at 11:00 AM, Jaroslaw Cwiklik  wrote:

> I will check. Not sure how to fix this yet.
> -jerry
>
> On Fri, Sep 2, 2016 at 9:28 AM, Marshall Schor  wrote:
>
>> Jerry, any chance the test framework for UIMA-AS could be upgraded
>> slightly, to
>> be more useful, by directing the huge amount of output from tests to
>> files, so
>> browsing the output can become useful again (it's way too large now...).
>>
>> -Marshall
>>
>>
>> On 9/1/2016 5:44 PM, Apache Jenkins Server wrote:
>> > See 
>> >
>> >
>>
>>
>

[jira] [Comment Edited] (UIMA-5115) uv3 select() api for iterators and streams over CAS contents

[Marshall Schor (JIRA)]

[ 
https://issues.apache.org/jira/browse/UIMA-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15504694#comment-15504694
 ] 

Marshall Schor edited comment on UIMA-5115 at 9/19/16 9:17 PM:
---

For UIMA-3724 and UIMA-3234, maybe use 3 methods:
* get() gets the single element or null
* single() gets the single element, throws if null or more than 1
* singleOrNull() gets the single element, returns null if no elements, throws 
if more than 1



was (Author: schor):
related feature requests to consider

> 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] [Issue Comment Deleted] (UIMA-5115) uv3 select() api for iterators and streams over CAS contents

[Marshall Schor (JIRA)]

 [ 
https://issues.apache.org/jira/browse/UIMA-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marshall Schor updated UIMA-5115:
-
Comment: was deleted

(was: wish lists to consider)

> 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

[Marshall Schor (JIRA)]

[ 
https://issues.apache.org/jira/browse/UIMA-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15504694#comment-15504694
 ] 

Marshall Schor commented on UIMA-5115:
--

related feature requests to consider

> 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

[Marshall Schor (JIRA)]

[ 
https://issues.apache.org/jira/browse/UIMA-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15504684#comment-15504684
 ] 

Marshall Schor commented on UIMA-5115:
--

wish lists to consider

> 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] [Created] (UIMA-5115) uv3 select() api for iterators and streams over CAS contents

[Marshall Schor (JIRA)]

Marshall Schor created UIMA-5115:


 Summary: 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] [Created] (UIMA-5114) DUCC Web Server (WS) needs better user validation for login

[Lou DeGenaro (JIRA)]

Lou DeGenaro created UIMA-5114:
--

 Summary: DUCC Web Server (WS) needs better user validation for 
login
 Key: UIMA-5114
 URL: https://issues.apache.org/jira/browse/UIMA-5114
 Project: UIMA
  Issue Type: Bug
  Components: DUCC
Reporter: Lou DeGenaro
Assignee: Lou DeGenaro
 Fix For: 2.2.0-Ducc


A user is able to login to ducc (via ldap) as first.last.  But the actual linux 
userid is First.Last, and when ducc_ling tries to employ first.last the 
switch-to-user fails.

WS could employ the command "/usr/bin/id first.last" to validate the userid 
before delegating to ldap.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (UIMA-5110) DUCC Job Driver (JD) erroneously logs ***** TIMEOUT *****

[Lou DeGenaro (JIRA)]

[ 
https://issues.apache.org/jira/browse/UIMA-5110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15503972#comment-15503972
 ] 

Lou DeGenaro commented on UIMA-5110:


Add new enum parameter comprising User and Timeout when internally handling 
user's JP exceptions in JD, to eliminate guesswork.

> DUCC Job Driver (JD) erroneously logs * TIMEOUT *
> -
>
> Key: UIMA-5110
> URL: https://issues.apache.org/jira/browse/UIMA-5110
> Project: UIMA
>  Issue Type: Bug
>  Components: DUCC
>Reporter: Lou DeGenaro
>Assignee: Lou DeGenaro
> Fix For: 2.2.0-Ducc
>
>
> In the JD log we see:
> 14 Sep 2016 10:41:29,157 ERROR JD.err - T[34] record  seqNo=2 * TIMEOUT 
> *
> [B@e9a57948
> But this log entry is not correct.  The real problem is that the JD tried to 
> convert the Exception object that occurred in "user space" into a string, but 
> that fails and the JD then makes the wrong assumption that a timeout must 
> have occurred because it finds value of null for the stringified 
> Exception...wrong!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work started] (UIMA-5110) DUCC Job Driver (JD) erroneously logs ***** TIMEOUT *****

[Lou DeGenaro (JIRA)]

 [ 
https://issues.apache.org/jira/browse/UIMA-5110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on UIMA-5110 started by Lou DeGenaro.
--
> DUCC Job Driver (JD) erroneously logs * TIMEOUT *
> -
>
> Key: UIMA-5110
> URL: https://issues.apache.org/jira/browse/UIMA-5110
> Project: UIMA
>  Issue Type: Bug
>  Components: DUCC
>Reporter: Lou DeGenaro
>Assignee: Lou DeGenaro
> Fix For: 2.2.0-Ducc
>
>
> In the JD log we see:
> 14 Sep 2016 10:41:29,157 ERROR JD.err - T[34] record  seqNo=2 * TIMEOUT 
> *
> [B@e9a57948
> But this log entry is not correct.  The real problem is that the JD tried to 
> convert the Exception object that occurred in "user space" into a string, but 
> that fails and the JD then makes the wrong assumption that a timeout must 
> have occurred because it finds value of null for the stringified 
> Exception...wrong!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (UIMA-1524) JFSIndexRepository should be enhanced with new generic methods

[Marshall Schor (JIRA)]

[ 
https://issues.apache.org/jira/browse/UIMA-1524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15503756#comment-15503756
 ] 

Marshall Schor commented on UIMA-1524:
--

Thanks, Richard, for your thoughtful dialog on these topics.  It's nice to find 
someone else interested in the arcana of principled API design :-).  

1) re: Fluctuating between positional-style and keyword style: the keyword 
style is the most "factored" style - lets one build what you want with a 
"minimal" set of keys.  So it's useful to list these as separate things (as 
done in the diagram), to see the totality of what one might reasonably "build" 
out of a minimal set of primitives, and what those primitives might be.

But the keyword style is verbose, so it seems good design to support positional 
for frequently-used idioms, for more concise/compact code.

2) Yes, your understanding of the Gliffy diagram is correct re: the object 
without a "terminal" is something supporting special methods for UIMA and also 
the stream interface.  My thought is that when you use a stream method, that 
will result in the creation of a Stream object, based on everything you've 
specified, up to that point, and from then on, it will act like a stream.

This "automatic" conversion to stream is a "convenience"; we could dispense 
with it, and require the user to explicitly write x().y().stream().a().b(). 
  where x, y are the uima specific methods, and a, b are stream methods.  It 
seems better (more concise/compact) to leave out the stream(), though.  Maybe 
it could be optional, and the documentation (for learning) could start with it 
explicitly present, and only later drop it; this could demystify the API 
slightly. 

3) It seems right that having more than one "type" spec is more likely an 
error, than a useful feature, so I agree it would be more helpful to throw an 
exception if that happened.

4) Because "type" is used frequently, I think it's a good candidate to allow it 
as a positional argument.

5) When moving keyword arguments into positional ones, should we drop the 
keyword form?  I'm a bit on the fence.  Sometimes I think users prefer an API 
style which lists arguments with their keys (as in the form type(aTypeSpec), 
uniformly, even if there are positional forms.  I don't think there's a cost to 
keeping this option, so I'm on the side of keeping it.

**Decision requirement::** dropping the *type* call - I'd say to keep it; 
throwing an exception if called twice: I'd say yes (because it's more likely an 
error than a wanted feature).

6) multiple location requirements.  I agree it would be nice, but it might be 
difficult to (efficiently) implement.   People might write forms like 
within(span1).within(span2), where the spans had some overlap.  It seems we'd 
have to go through and figure out the semantics for lots of combinations of 
method (keyword) chains...  So maybe we could not do this in version 1, and 
later figure out some often requested instances of this as a version 2 
improvement.

These are perhaps "tricky".  In the example of 
.within(sentence).following(predicateVerb), even though this sounds sensible, I 
think it's somewhat misleading.  The following(predicateVerb) completely 
specifies the position, and the .within(sentence) just serves as a boolean 
switch - is the predicateVerb location is within(sentence),   I think this is a 
confusing way to represent this versus something like:
{code}
if (sentence.contains(predicateVerb))
{code} 
or something similar that does boolean operations on spans (with or without 
typePriorities).

**Decision requirement:** allowing multiple location specs - I would severely 
restrict this in version 1 to just those easily supported by the current 
indexes/iterators, which in my mind would be just one of the 
covered/covering/moveTo(fs) kind, and one displacement kind; the semantics 
would be that the displacement operation follows the other.

7) I like "displacement" instead of "offset", I'd like even better a shorter 
word :-) ; some possibilities:  shift, shifted, shiftedBy, move, moved, movedBy 
 (the "ed" forms are more declarative, but sound a bit clumsy to me).  Of 
these, my choice is "shifted":  e.g.   
cas.select(Token.type).within(fs).shifted(3), but not a strong preference.

8) Semantics of displacement: I had not thought of the complexity of having it 
operate with respect to some other index/type; I thought of it as moving the 
point where you start by iterating moveToNext or moveToPrevious.  Our current 
mechanisms support this trivially, I think.  Also, in the form 
"cas.select(Token.type).following(predicateVerb)", the "type" of predicateVerb 
(surprised) need not even be a subtype of Token.  

**Decision requirement::** displacement meaning: I'd prefer making it just an 
interated MoveToNext or Previous.

9) Re: supporting enhanced for loop: I agree it would be good to support this. 

Jenkins build is back to normal : UIMA-DUCC #989

[Apache Jenkins Server]

See 

Jenkins build is back to normal : UIMA-DUCC » Apache UIMA DUCC: uima-ducc-agent #989

[Apache Jenkins Server]

See