Hi Harbs,

To answer your question about vector index checking... please see docs:

https://apache.github.io/royale-docs/create-an-application/optimizations/compiler-configuration-settings.html#vector-index-checking


or
https://apache.github.io/royale-docs/create-an-application/optimizations/doc-comment-directives.html#royalesuppressvectorindexcheck


But I am concerned about a potential bug.

Are you seeing the index checking code being generated with
'-js-vector-emulation-class=Array'  set for all your builds? If so, that's
a bug, and I'd be keen to repro it and fix.





On Tue, Jul 2, 2019 at 5:31 AM Harbs <[email protected]> wrote:

> I’m using a custom build of TLF.
>
> I added that argument, but. I’m still getting:
>
> this._handlers[this._handlers[org.apache.royale.utils.Language.CHECK_INDEX](idx)]
> = handler;
>
> How do I get rid of the index checking?
>
> > On Jul 1, 2019, at 7:40 PM, Greg Dove <[email protected]> wrote:
> >
> > Harbs, I set TLF to be legacy vector-as-array in the framework, and
> tested
> > it with (iirc) the TLFEditor manual test.
> >
> > -js-vector-emulation-class=Array
> >
> > I suggest you check this first, by removing that setting in the build of
> > the TLF framework lib.
> > I only put the vector-as-array setting like that in TLF lib because it
> was
> > one of the framework libs which was using Vector, and the original
> approach
> > used, and figured it might be a good place to retain it, but it may not
> be
> > depending on the code. I did explain this at the time of the Vector
> > addition, but it was a minor point amongst many updates, so would have
> been
> > easily overlooked.
> > So you might want to remove that setting above from TLF build, or you if
> > not it sounds like you probably need to use the same setting everywhere
> > else in your external code.
> >
> > The problem with 'vectorEmulationClass' in general is that if a Vector is
> > exposed anywhere, it can be an incompatible type wtih how Vector is
> > represented in another build. If it is used in a library, the type should
> > never be exposed on a public api surface.
> > This sounds like exactly the sort of problem you are experiencing.
> >
> > In terms of tuning options for Vector performance, I did ask about
> > preferred options for that already in another thread started by Yishay.
> But
> > I guess that thread went to other topics and discussion stalled. I will
> > start a new thread later today, just focused on Vector optimizations.
> >
> >
> >
> >
> > On Tue, Jul 2, 2019 at 3:35 AM Harbs <[email protected]> wrote:
> >
> >> I just spent a few hours trying to track down why TLF is not working for
> >> me.
> >>
> >> It looks like it has something to do with runtime Vector type checking.
> >> TLF uses Vector.<String>. That appears to be causing some values to be
> NaN
> >> for range checking. I have not traced the problem all the way down. I’d
> >> just like to turn off the runtime checking. I’m still not clear on how I
> >> turn that off.
> >>
> >> Any pointers?
> >> Harbs
>
>

Reply via email to