You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Jörn Kottmann <ko...@gmail.com> on 2010/12/02 16:51:06 UTC
Re: Next release candidate
Hi - I'm ready to do another release candidate of the uimaj java sdk.
> I love your optimism :-) ...
>
> I'll wait till Friday - looking for your closing of 1875.
UIMA-1875 is now closed, there is still one minor issue
which must be tested and closed. I will do that later today.
Looks good that we are ready for the next RC tomorrow
from my side.
Jörn
Re: Next release candidate
Posted by Marshall Schor <ms...@schor.com>.
Let's defer these fixes until we get 2.3.1 out - I'm trying to get a release
candidate to go, today :-)
-Marshall Schor
On 12/3/2010 4:24 AM, Tommaso Teofili wrote:
> Well, I agree with you that I don't want too complicated over optimized code
> where it's not needed but I partially disagree since .."abc" + "def"... is
> both slower and uglier and replacing it with ...new
> StringBuilder("abc").append("def")... doesn't seem to me to make it so
> complicated.
> Most part of UIMA code looks good but I think it would be also good to spend
> a few cycles, from time to time, to make it look nicer, that usually
> bringing to more extensible and readable code.
> My 2 cents,
> Tommaso
>
> 2010/12/3 Jörn Kottmann <ko...@gmail.com>
>
>> On 12/3/10 9:48 AM, Tommaso Teofili wrote:
>>
>>> For example in DocumentAnalayzer most of messages are builded like that.
>>>
>>> At the moment I found such string concatenation in:
>>> uimaj-cpe: CheckPointConfig, CheckPoint
>>> uimaj-tools: CpmPanel, AnnotationViewerDialog, DocumentAnalyzer,
>>> AnnotationViewerMain
>>> uimaj-ep-configurator: TypeSection, MultiPageEditor
>>> jVinci: ServiceRegistry
>>>
>>> if you agree, I'm going to fix them,
>>>
>> I actually was only worried about the new tag drawing code
>> in the Cas Editor which is frequently executed and
>> should be a little faster.
>>
>> I think it does not make sense to optimize code
>> too much when the optimization is not needed.
>> Optimizing code makes it usually more complicated,
>> which only makes sense if it ends up with a noticeable or
>> measureable change in execution time.
>>
>> Jörn
>>
Re: Next release candidate
Posted by Tommaso Teofili <to...@gmail.com>.
Well, I agree with you that I don't want too complicated over optimized code
where it's not needed but I partially disagree since .."abc" + "def"... is
both slower and uglier and replacing it with ...new
StringBuilder("abc").append("def")... doesn't seem to me to make it so
complicated.
Most part of UIMA code looks good but I think it would be also good to spend
a few cycles, from time to time, to make it look nicer, that usually
bringing to more extensible and readable code.
My 2 cents,
Tommaso
2010/12/3 Jörn Kottmann <ko...@gmail.com>
> On 12/3/10 9:48 AM, Tommaso Teofili wrote:
>
>> For example in DocumentAnalayzer most of messages are builded like that.
>>
>> At the moment I found such string concatenation in:
>> uimaj-cpe: CheckPointConfig, CheckPoint
>> uimaj-tools: CpmPanel, AnnotationViewerDialog, DocumentAnalyzer,
>> AnnotationViewerMain
>> uimaj-ep-configurator: TypeSection, MultiPageEditor
>> jVinci: ServiceRegistry
>>
>> if you agree, I'm going to fix them,
>>
>
> I actually was only worried about the new tag drawing code
> in the Cas Editor which is frequently executed and
> should be a little faster.
>
> I think it does not make sense to optimize code
> too much when the optimization is not needed.
> Optimizing code makes it usually more complicated,
> which only makes sense if it ends up with a noticeable or
> measureable change in execution time.
>
> Jörn
>
Re: Next release candidate
Posted by Jörn Kottmann <ko...@gmail.com>.
On 12/3/10 9:48 AM, Tommaso Teofili wrote:
> For example in DocumentAnalayzer most of messages are builded like that.
>
> At the moment I found such string concatenation in:
> uimaj-cpe: CheckPointConfig, CheckPoint
> uimaj-tools: CpmPanel, AnnotationViewerDialog, DocumentAnalyzer,
> AnnotationViewerMain
> uimaj-ep-configurator: TypeSection, MultiPageEditor
> jVinci: ServiceRegistry
>
> if you agree, I'm going to fix them,
I actually was only worried about the new tag drawing code
in the Cas Editor which is frequently executed and
should be a little faster.
I think it does not make sense to optimize code
too much when the optimization is not needed.
Optimizing code makes it usually more complicated,
which only makes sense if it ends up with a noticeable or
measureable change in execution time.
Jörn
Re: Next release candidate
Posted by Tommaso Teofili <to...@gmail.com>.
For example in DocumentAnalayzer most of messages are builded like that.
At the moment I found such string concatenation in:
uimaj-cpe: CheckPointConfig, CheckPoint
uimaj-tools: CpmPanel, AnnotationViewerDialog, DocumentAnalyzer,
AnnotationViewerMain
uimaj-ep-configurator: TypeSection, MultiPageEditor
jVinci: ServiceRegistry
if you agree, I'm going to fix them,
Tommaso
2010/12/3 Jörn Kottmann <ko...@gmail.com>
> On 12/3/10 9:04 AM, Tommaso Teofili wrote:
>
>> it looks good to me, only I'm doing some code review to check out if we
>> can
>> make it cleaner/faster somewhere.
>> For example I'm seeing there are string concatenations based on
>> "something"
>> + "else" whereas we could improve performance using StringBuilder (or
>> StringBuffer if text is to be accessed by multiple threads).
>>
>
> Can you point me to the line?
>
> Jörn
>
Re: Next release candidate
Posted by Jörn Kottmann <ko...@gmail.com>.
On 12/3/10 9:04 AM, Tommaso Teofili wrote:
> it looks good to me, only I'm doing some code review to check out if we can
> make it cleaner/faster somewhere.
> For example I'm seeing there are string concatenations based on "something"
> + "else" whereas we could improve performance using StringBuilder (or
> StringBuffer if text is to be accessed by multiple threads).
Can you point me to the line?
Jörn
Re: Next release candidate
Posted by Tommaso Teofili <to...@gmail.com>.
it looks good to me, only I'm doing some code review to check out if we can
make it cleaner/faster somewhere.
For example I'm seeing there are string concatenations based on "something"
+ "else" whereas we could improve performance using StringBuilder (or
StringBuffer if text is to be accessed by multiple threads).
Tommaso
2010/12/2 Marshall Schor <ms...@schor.com>
> :-) ! -Marshall
>
> On 12/2/2010 10:51 AM, Jörn Kottmann wrote:
> > Hi - I'm ready to do another release candidate of the uimaj java sdk.
> >> I love your optimism :-) ...
> >>
> >> I'll wait till Friday - looking for your closing of 1875.
> >
> > UIMA-1875 is now closed, there is still one minor issue
> > which must be tested and closed. I will do that later today.
> > Looks good that we are ready for the next RC tomorrow
> > from my side.
> >
> > Jörn
> >
> >
>
Re: Next release candidate
Posted by Marshall Schor <ms...@schor.com>.
:-) ! -Marshall
On 12/2/2010 10:51 AM, Jörn Kottmann wrote:
> Hi - I'm ready to do another release candidate of the uimaj java sdk.
>> I love your optimism :-) ...
>>
>> I'll wait till Friday - looking for your closing of 1875.
>
> UIMA-1875 is now closed, there is still one minor issue
> which must be tested and closed. I will do that later today.
> Looks good that we are ready for the next RC tomorrow
> from my side.
>
> Jörn
>
>