Re: Problems dealing with bead substitution in Royale

Then this is a really bad subject line. If you want to replace our event subsystem with true DOM events, feel free to do so. I think it is safe to do so now that we no longer have to support IE10 or older. If, after that work has been done and bead events are still too heavy, then we can

Jenkins build is back to normal : royale-asjs_MXTests #523

See

Build failed in Jenkins: royale-asjs_MXTests #522

See -- [...truncated 2.02 MB...] [mxmlc] using source file:

Re: Heads-up on coming updates to reflection and AMF

Yeah, I think so, but I think that's no problem since we want in this part maximum compatibility so people could use royale with the server they use for flex with almost not changes (just use ArrayCollection if they use MX or use ArrayList if they use normal Royale UI APIs) El jue., 21 feb. 2019

Re: Heads-up on coming updates to reflection and AMF

Thanks for the ideas Harbs. I'll suggest that it will be easier to discuss these after I push to a remote branch and you can take a look. My aim was to keep the writeData ('writeBinaryData') and readData ('readBinaryData') signatures the same as the originals (original readBytes/writeBytes) for

Re: Heads-up on coming updates to reflection and AMF

Sounds good, Carlos. Actually as another implication... This does mean that I am also adding IExternalizable to org.apache.royale.collections.ArrayList and obviously uncommenting/adding to mx.collections.AC mx.collections.AL I don't think there is any 'PAYG' way to do that which would be

Re: Heads-up on coming updates to reflection and AMF

Maybe the type of “data” should be platform specific? Then you could use: bd2.writeData(bd1.data); > On Feb 21, 2019, at 7:18 PM, Greg Dove wrote: > > The main thought was for things like xhr.response which is ArrayBuffer and > can be used directly. > That could be changed if it was preferred.

Re: Heads-up on coming updates to reflection and AMF

The main thought was for things like xhr.response which is ArrayBuffer and can be used directly. That could be changed if it was preferred. I kept it the same as it was the native 'bytearray' implementation for the target platform and that seemed to correspond more to ArrayBuffer than Uint8Array.

Re: Heads-up on coming updates to reflection and AMF

Hi Greg, that's great. In that way I can test about our app as a first step, then if all goes ok, I can try a second time turning on small messages to try IExternalizable. Finally I can as well enable compression :) El jue., 21 feb. 2019 a las 17:54, Greg Dove () escribió: > Hi Carlos, > >

Re: Heads-up on coming updates to reflection and AMF

What’s the reason you are using ArrayBuffer instead of Uint8Array on the JS side? If you’d use Uint8Array instead, the method could be used like so: bd2.writeData(bd1.array); > On Feb 21, 2019, at 6:40 PM, Greg Dove wrote: > > Hi Harbs, > > Part of the reason for posting this was to

Re: Heads-up on coming updates to reflection and AMF

Hi Carlos, Thanks for your comments. Sure, I have things set up in a local branch, I was just hoping to get feedback as to whether I needed to use that remotely or not. So I will do that. On Thu, Feb 21, 2019 at 10:13 PM Carlos Rovira wrote: > Hi Greg, > > that sounds to me like an amazing

Re: Heads-up on coming updates to reflection and AMF

Hi Harbs, Part of the reason for posting this was to surface any concerns early. This is my fault because when I added these methods a few years back I thought it seemed ok to use BinaryData as the 'bytes' argument type in them at the time. But the issue there is that it breaks compatibility with

Re: VSCode Build Taking Really Long

What are you using to compile? If you’re compiling using the VS Code extension, try installing asconfigc separately. > On Feb 21, 2019, at 4:29 PM, Yishay Weiss wrote: > > Hi Guys, > > We have a really simple app which takes Piotr and Olaf less than half a > minute to compile using VSCode.

VSCode Build Taking Really Long

Hi Guys, We have a really simple app which takes Piotr and Olaf less than half a minute to compile using VSCode. The same app takes me somewhere between 2.5 and 5 minutes. Can you round up the usual suspects? My computer isn’t slower than theirs and until recently we’ve been using the same

Build failed in Jenkins: royale-asjs_MXTests #521

See -- [...truncated 2.02 MB...] [mxmlc] using source file:

Re: Does Oracle's new 2019 Java licensing affects Royale?

I switched to OpenSDK 11.02 [1] now and the build of our Royale app still works for me. I noticed a significant build time improvement for our small app from 28s to 15s. Unfortunately, I've done some clean-up on my machine at the same time, so I am not sure if the build performance improvement is

Re: Does Oracle's new 2019 Java licensing affects Royale?

Hi Carlos, > And for me the need of 8 was more an "external need" than something in Royale Compiler itself Just to avoid misunderstandings: There's no way here to go with Java 6,7,... I am not allowed to run outdated Java versions on my machine and from now on, any company has to pay for

Re: Does Oracle's new 2019 Java licensing affects Royale?

Hi Olaf, I have different SDKs in my system, to cover version 6. 7, 8 and 10 of Java, since I use home-brew in Mac and want easy install/unistall and updates. So checking with jenv (another great tool to switch between JDKs in Mac) , I see I have oracle for 6,8 and 10, but OpenJDK for 7 (I

Re: Does Oracle's new 2019 Java licensing affects Royale?

Hi Piotr, > From the user perspective everything was working fine. That's good news! I'll follow this path! Thanks, Olaf -- Sent from: http://apache-royale-development.20373.n8.nabble.com/

Re: Does Oracle's new 2019 Java licensing affects Royale?

Hi Olaf, I just spent some time on testing OpenJDK wich I had for a longer time 11.0.2. I have switched my whole system to OpenJDK - JAVA_HOME etc. I did switch JAVA in Moonshine as well. From the user perspective everything was working fine. I was able to build Royale project, code intelligence

Re: Does Oracle's new 2019 Java licensing affects Royale?

Hi Carlos, > but IICRC the changes was for new Java 11 version ... The changes affect also Java 8, public updates of JDK 8 will end in January of 2019 [1]. @all: I would like to summarize my assumptions: - The Royale project is not affected because it's a non-commercial project - Companies

Re: Heads-up on coming updates to reflection and AMF

Hi Greg, that sounds to me like an amazing work. Thanks for working on this. I think the best way to integrate this should be creating a branch so Harbs and others could adapt the other code to the new API changes, and commit to that branch that fixes (if there are located in our repo) so all is

Re: Heads-up on coming updates to reflection and AMF

What did you change? I’m using these methods, so it’s significant to me. > On Feb 21, 2019, at 7:20 AM, Greg Dove wrote: > > I had to change the writeBytes/readBytes method signatures. > The original method signature is still available but will become > writeBinaryData/readBinaryData

Re: Problems dealing with bead substitution in Royale

Thanks for your thoughts. My motivation for doing this has very little to do with removing beads. I have not been happy with the event system of strands and beads for a long time. I’d be OK with removing removeBead from IStrand, but as it stands now, I think it makes sense to remove the