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 <harbs.li...@gmail.com> 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
