Build failed in Jenkins: royale-asjs_jsonly #1017

2018-06-20 Thread apacheroyaleci
See -- [...truncated 955.70 KB...] [java] [java] Jun 21, 2018 4:13:49 AM com.google.javascript.jscomp.LoggerErrorManager println [java]

Re: BinaryData and odd bytes

2018-06-20 Thread Greg Dove
Do you remember if you tried just pulling bytes one at a time? I think I did. But I would need to check an older machine at some point to see if I still have any evidence of this. I definitely recall a bit of head-scratching before I actually settled on that approach with the typed arrays, but

Re: BinaryData and odd bytes

2018-06-20 Thread Harbs
I remembered there were tests, but I forgot where. Thanks for that. I’ll try to ad a test for this... FYI, the MD5 test there now fails. I have no idea why. Maybe I messed something up with my BinaryData changes, but I can’t see what… > On Jun 21, 2018, at 12:45 AM, Greg Dove wrote: > > Hi

Re: BinaryData and odd bytes

2018-06-20 Thread Alex Harui
Hi Greg, Good to know more about the background. Do you remember if you tried just pulling bytes one at a time? For me, the key piece is that the int16s are not guaranteed to be "int-aligned" in a true byte array so we have to give up on even temporarily creating typed arrays to read the

Re: BinaryData and odd bytes

2018-06-20 Thread Greg Dove
Hi guys, some quick comments... I do recall this being difficult to get a good balance of performance whilst getting close to the ByteArray api. I did do a reasonable amount of performance tests across multiple browsers, trying multiple approaches and I ended up choosing an implementation that

Re: BinaryData and odd bytes

2018-06-20 Thread Harbs
I expect the same. Harbs > On Jun 20, 2018, at 7:01 PM, Alex Harui wrote: > > FWIW, I would expect that to be faster than creating new Typed Arrays on each > read. The Garbage Collection implications of an instantiation on each read > made me cringe. > > My 2 cents, > -Alex > > On

Re: BinaryData and odd bytes

2018-06-20 Thread Alex Harui
FWIW, I would expect that to be faster than creating new Typed Arrays on each read. The Garbage Collection implications of an instantiation on each read made me cringe. My 2 cents, -Alex On 6/20/18, 1:31 AM, "Harbs" wrote: I ended up rewriting the read methods to use simple math and

Re: Migrating Enterprise Flex Application

2018-06-20 Thread Harbs
The initial work will be getting the application to compile and removing compile errors. That’s work which can easily be divided if you have developers to help you. Once you get the basics to compile, you will have a much better idea of what work is ahead of you. Good luck! Harbs > On Jun

Re: BinaryData and odd bytes

2018-06-20 Thread Harbs
I ended up rewriting the read methods to use simple math and shift operators. It reads bytes directly from the existing Uint8Array and uses shift operators to convert unsigned ints to signed ones. Over-all the new methods should be more robust and more efficient. There is likely still issues

Re: Migrating Enterprise Flex Application

2018-06-20 Thread Prashant Kumar
One more thing, I want to focus here, that Royale has AMF support, so if your existing application using AMF services then no changes will be required on your services end. On Wed 20 Jun, 2018, 9:09 AM chembali, wrote: > Thank you for the responses from all of you. I feel confident to take this