Tobias Horsmann created UIMA-4504:
-
Summary: CpePipeline: Number of cores for multi-threading is fixed
Key: UIMA-4504
URL: https://issues.apache.org/jira/browse/UIMA-4504
Project: UIMA
Issue
If type inferencing from the surrounding context wasn't done, and the user
needed to cast the result, the user would be exposed to the same runtime
error. So, unless there's some other pros/cons, it seems to me it would be
best to allow generic type inferencing in cases where there's a
I agree that (3) is not safe. However it imposes a burden on the user
(assuming they want to use some method that's in the type but not in TOP) to
cast the result to the type. This cast could also throw a runtime error, of
course.
So, what I'm thinking is that there's no particular value in
On 08.07.2015, at 17:11, Marshall Schor m...@schor.com wrote:
I think that similar arguments apply to other getters, such as
getAnnotationIndex(some-type-spec).
These are currently defined to be generic methods so they do type inferencing.
True.
Mind, I'm arguing for the conservative and
I think that similar arguments apply to other getters, such as
getAnnotationIndex(some-type-spec).
These are currently defined to be generic methods so they do type inferencing.
-Marshall
On 7/8/2015 9:24 AM, Marshall Schor wrote:
More about the signatures and type inference.
We have the
On 08.07.2015, at 17:14, Marshall Schor m...@schor.com wrote:
I agree that (3) is not safe. However it imposes a burden on the user
(assuming they want to use some method that's in the type but not in TOP) to
cast the result to the type. This cast could also throw a runtime error, of
So long as the Runtime error is meaningful and documented then I vote for
option 3. T extends TOP still limits the user to the family of the UIMA
universe so to speak without limiting them to an explicit FS inheritance which
is a useful flexibility in spite of the risk of a casting error.
[
https://issues.apache.org/jira/browse/UIMA-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lou DeGenaro updated UIMA-4476:
---
Description:
Noticed was 45 JDs on apache-ducc using linux command. There should never be
more than
Hi,
the method JCasFactory.createJCas() calls CasCreationUtils.createCas()
only with null values for type priorities. Shouldn't there be a call of
createTypePriorities() like for the typesystem descriptor? How can I
include type priorities when I create a JCas with uimaFIT? Did I miss
Richard Eckart de Castilho created UIMA-4505:
Summary: JCasFactory does not use auto-detection for type
priorities and indexes
Key: UIMA-4505
URL: https://issues.apache.org/jira/browse/UIMA-4505
[
https://issues.apache.org/jira/browse/UIMA-4505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Eckart de Castilho reassigned UIMA-4505:
Assignee: Richard Eckart de Castilho
JCasFactory does not use
[
https://issues.apache.org/jira/browse/UIMA-4505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Eckart de Castilho resolved UIMA-4505.
--
Resolution: Fixed
Fixed for createJCas() and documented that no
See
https://builds.apache.org/job/UIMA-uimaFIT/org.apache.uima$uimafit-core/209/changes
See https://builds.apache.org/job/UIMA-uimaFIT/209/changes
[
https://issues.apache.org/jira/browse/UIMA-4505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Eckart de Castilho updated UIMA-4505:
-
Fix Version/s: 2.1.1uimaFIT
JCasFactory does not use auto-detection for
[
https://issues.apache.org/jira/browse/UIMA-4299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor resolved UIMA-4299.
--
Resolution: Fixed
improve generics for UIMA indexes and iterators
[
https://issues.apache.org/jira/browse/UIMA-4299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor reopened UIMA-4299:
--
fix JCas APIs that were incorrectly switched to FeatureStructure to TOP or
T extends TOP, per
OK. Based on the previous discussion in this thread, and at least one other
person posting their view in favor of type inferencing (vs. safety), I'm going
to allow (3) to have type inference.
-Marshall
On 7/8/2015 11:17 AM, Richard Eckart de Castilho wrote:
On 08.07.2015, at 17:11, Marshall
I think I see another reason to allow type inferencing, which is less user code
starts failing to compile when adopting 2.8.0 from 2.7.0. This is because user
code in 2.7.0 could have done:
FSIteratorMyAnnot = myJCas.getJfsRepository().getAllIndexedFS(MyAnnot.type);
and it would work in 2.7.0
On 08.07.2015, at 22:47, Peter Klügl peter.klu...@averbis.com wrote:
Hi,
the method JCasFactory.createJCas() calls CasCreationUtils.createCas() only
with null values for type priorities. Shouldn't there be a call of
createTypePriorities() like for the typesystem descriptor? How can I
20 matches
Mail list logo
