Thilo Goetz wrote:
Eddie Epstein wrote:
On 5/14/07, Adam Lally <[EMAIL PROTECTED]> wrote:
I prefer that we deprecate addToIndexes() and removeFromIndexes() but
take reasonable steps to make the methods behave is closely to the
current behavior as possible. If Marshall is willing to imp
Eddie Epstein wrote:
> On 5/14/07, Adam Lally <[EMAIL PROTECTED]> wrote:
>> I prefer that we deprecate addToIndexes() and removeFromIndexes() but
>> take reasonable steps to make the methods behave is closely to the
>> current behavior as possible. If Marshall is willing to implement
>> something
On 5/14/07, Adam Lally <[EMAIL PROTECTED]> wrote:
I prefer that we deprecate addToIndexes() and removeFromIndexes() but
take reasonable steps to make the methods behave is closely to the
current behavior as possible. If Marshall is willing to implement
something a little more complex that reduce
Marshall Schor wrote:
Marshall Schor wrote:
Adam Lally wrote:
On 5/13/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
Before:
---
MyAnnotation x = new MyAnnotation(someView_1);
aView_1.addFsToIndexes(x);
aView_2.addFsToIndexes(x);
// removes from
On 5/14/07, Eddie Epstein <[EMAIL PROTECTED]> wrote:
JCas objects are broken if an FS instance can belong to multiple
views, because 1) addToIndexes() is ambiguous and 2) hashed JCas
instances are not shared across views. The suggestions above do not
fix the situation for all scenarios, for examp
Eddie Epstein wrote:
On 5/14/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
I don't think there is a significant performance savings. So I'm
willing to go with the following
(let's see if I get this right...)
Changes:
1) 1 map from CAS objects to JCas cover objects, shared by all views
2) The g
On 5/14/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
I don't think there is a significant performance savings. So I'm
willing to go with the following
(let's see if I get this right...)
Changes:
1) 1 map from CAS objects to JCas cover objects, shared by all views
2) The getters from the iterat
Marshall Schor wrote:
Adam Lally wrote:
On 5/13/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
Before:
---
MyAnnotation x = new MyAnnotation(someView_1);
aView_1.addFsToIndexes(x);
aView_2.addFsToIndexes(x);
// removes from view_1
aView_2.getAllIn
On 5/14/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
Changes:
1) 1 map from CAS objects to JCas cover objects, shared by all views
2) The getters from the iterators would *update* the _Type ref to be the
view associated with the iterator
* this might be implemented by changing the generato
Adam Lally wrote:
On 5/13/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
Before:
---
MyAnnotation x = new MyAnnotation(someView_1);
aView_1.addFsToIndexes(x);
aView_2.addFsToIndexes(x);
// removes from view_1
aView_2.getAllIndexedFS(MyAnnotation.ty
On 5/13/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
Before:
---
MyAnnotation x = new MyAnnotation(someView_1);
aView_1.addFsToIndexes(x);
aView_2.addFsToIndexes(x);
// removes from view_1
aView_2.getAllIndexedFS(MyAnnotation.type).get().removeFro
Adam Lally wrote:
On 5/11/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
Adam Lally wrote:
> Another thought: Is it possible to have separate instances of _Type
> for each view, but to have only one, shared, set of generators?
>
> The FSGenerator.createFS method is passed a CAS reference - is th
On 5/11/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
Adam Lally wrote:
> Another thought: Is it possible to have separate instances of _Type
> for each view, but to have only one, shared, set of generators?
>
> The FSGenerator.createFS method is passed a CAS reference - is this a
> reference to
Adam Lally wrote:
Another thought: Is it possible to have separate instances of _Type
for each view, but to have only one, shared, set of generators?
The FSGenerator.createFS method is passed a CAS reference - is this a
reference to the view? If so, it seems like only one generator is
needed -
Another thought: Is it possible to have separate instances of _Type
for each view, but to have only one, shared, set of generators?
The FSGenerator.createFS method is passed a CAS reference - is this a
reference to the view? If so, it seems like only one generator is
needed - it could look up t
On 5/11/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
Adam wrote:
> Next thought... what if instead of the separate _Type objects, you
> maintained in the JCasImpl a map from JCas object to "home view". As
> above you only need to do this for non-annotation objects that have
> indexes defined
Adam Lally wrote:
On 5/10/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
While working on the class-loader switching code, we have revisited an
issue with the way JCas objects work with respect to views.
Currently, for each view, there is a separate set of xxx_Type objects, a
separate set of "ca
On 5/10/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
While working on the class-loader switching code, we have revisited an
issue with the way JCas objects work with respect to views.
Currently, for each view, there is a separate set of xxx_Type objects, a
separate set of "cached" cover objects
Marshall Schor wrote:
While working on the class-loader switching code, we have revisited an
issue with the way JCas objects work with respect to views.
Currently, for each view, there is a separate set of xxx_Type objects,
a separate set of "cached" cover objects (which are identical to other
While working on the class-loader switching code, we have revisited an
issue with the way JCas objects work with respect to views.
Currently, for each view, there is a separate set of xxx_Type objects, a
separate set of "cached" cover objects (which are identical to other
view's objects, excep
20 matches
Mail list logo
