Hi Alex, do you want to send you a zip file with the js-debug versions? In order to compare both je-relase versions, my problem is that I don't know what I must look for, so is difficult to see things. In the other hand, I'm spending lots of time in this kind of Debugging what makes me unable to work on the real project, and I'm starting to be delayed...
thanks El mié., 17 oct. 2018 a las 17:19, Alex Harui (<aha...@adobe.com.invalid>) escribió: > This may be a good opportunity for folks like you to develop skills at > debugging things like this. It won't scale if it is always up to me. > IMO, I would be comparing the un-minified source to see what is > different. The release files are hard to read. > > -Alex > > On 10/17/18, 6:58 AM, "Carlos Rovira" <carlosrov...@apache.org> wrote: > > Alex, > > testing with the test change to the same jewel code and with actual > repo > states fails in release mode as expected. So clearly something has > changed > this days that makes MX RO fail in release mode. > > Using DiffMerge to compare both release .js files shows a clear red > zone > where the significant differences exists. > > I posted both js files here > > [1] Day 14 - > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FtYEj&data=02%7C01%7Caharui%40adobe.com%7C38701cdbe0a54f94806408d634388cbf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636753814815713802&sdata=QWdPCN9c8mDOdZquscvc7O%2Blafd6DiD8Ob355p7jhFg%3D&reserved=0 > [2] Day 17 - > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FAcMa&data=02%7C01%7Caharui%40adobe.com%7C38701cdbe0a54f94806408d634388cbf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636753814815713802&sdata=pf9BDreqLvqE7Sfzq9pE4ExUpJoLYwQEWd6q7onMA0U%3D&reserved=0 > > > Could you check the files and see if you see something relevant. I > don't > know how to look for. If you need the js files I can send you in email. > > Hope you find with this info the point of changes and could find some > solution so we get release mode working againg > > thanks > > Carlos > > > > El mié., 17 oct. 2018 a las 15:34, Carlos Rovira (< > carlosrov...@apache.org>) > escribió: > > > Hi Alex, > > > > Going to repos state of Oct, 14th (last commit of that day, in > compiler > > and framework, and in my project app repo as well), I can confirm all > > worked on release more and communication with server is ok > > > > for our mxroyale MX RO test: I can't get it to work in release mode > either > > adding: > > > > debug false > > > > and > > > > -js-dynamic-access-unknown-members=true > > > > or removing mx:method section that was not working right at that > time. > > > > Our test continue showing white browser screen and the error: > > > > [Error] TypeError: undefined is not an object (evaluating 'a.length') > > ez (App.js:997:141) > > Vy (App.js:996:181) > > qm (App.js:970:266) > > qr (App.js:968:323) > > mq (App.js:239:887) > > R (App.js:166:1223) > > W (App.js:511:1288) > > mw (App.js:642:796) > > Dz (App.js:1044:726) > > create (App.js:908:164) > > start (App.js:909:229) > > Código global (index.html:13) > > > > So I suppose mx:Application and other implied MX things in the > background > > are still not suited for release compilation. > > > > So after this, I changed localy all non MX RO components to Jewel, > and I > > get the test working in release mode > > Interesting thing here is that it worked without setting > > -js-dynamic-access-unknown-members=true > > So that indicates that MX RO seems does not need this itself. > > > > Next thing is go to actual code, change the example with the same > Jewel > > code, compile, test and then compare outputs with DiffMerge to see > > differences. > > > > I'll write result as I get it > > > > Carlos > > > > > > > > El mié., 17 oct. 2018 a las 10:15, Carlos Rovira (< > carlosrov...@apache.org>) > > escribió: > > > >> Hi Alex, > >> > >> the compiler params I reported was not right, were from > asconfig.json, > >> but since I'm using maven I saw there was not setup anything, so I > setup to > >> : > >> > >> <additionalCompilerOptions> > >> -source-map=true;-js-dynamic-access-unknown-members=true</ > >> additionalCompilerOptions> > >> > >> And seems the output is still the same > >> > >> [Error] TypeError: undefined is not an object (evaluating > 'a.length') > >> hz (App.js:998:141) > >> Yy (App.js:997:181) > >> rm (App.js:971:266) > >> tr (App.js:969:323) > >> pq (App.js:239:887) > >> R (App.js:166:1223) > >> W (App.js:511:1288) > >> pw (App.js:642:796) > >> Gz (App.js:1045:726) > >> create (App.js:908:164) > >> start (App.js:909:229) > >> Código global (index.html:13) > >> > >> Now, I'll try to go back in time to a previous commit where it > works and > >> compare with this output > >> > >> I'll get back with results > >> > >> Carlos > >> > >> > >> > >> > >> > >> > >> El mar., 16 oct. 2018 a las 23:44, Alex Harui > (<aha...@adobe.com.invalid>) > >> escribió: > >> > >>> Ok. Let us know what you find out. I'm curious why you are not > using > >>> -js-dynamic-access. I thought that was at least a workaround. > >>> > >>> -Alex > >>> > >>> On 10/16/18, 2:36 PM, "Carlos Rovira" <carlosrov...@apache.org> > wrote: > >>> > >>> Hi Alex, > >>> > >>> I'm starting with our simple MXRoyale RO text example and our > Java > >>> sample. > >>> I just pushed a commit to easy change between the old example > and > >>> the new > >>> MX RO test case, and enable RELEASE mode. When doing so and > running > >>> it > >>> doesn't work. this is the output > >>> > >>> [Error] TypeError: undefined is not an object (evaluating > 'a.length') > >>> hz (App.js:998:141) > >>> Yy (App.js:997:181) > >>> rm (App.js:971:266) > >>> tr (App.js:969:323) > >>> pq (App.js:239:887) > >>> R (App.js:166:1223) > >>> W (App.js:511:1288) > >>> pw (App.js:642:796) > >>> Gz (App.js:1045:726) > >>> create (App.js:908:164) > >>> start (App.js:909:229) > >>> Código global (index.html:13) > >>> > >>> The additional compiler options are: > >>> > >>> "additionalOptions": "-remove-circulars > >>> -js-output-optimization=skipAsCoercions", > >>> > >>> I must to close for today, but I think it will be more easy to > debug > >>> from > >>> this example than from my real world app that has many other > things > >>> bundled. > >>> > >>> Thanks > >>> > >>> > >>> El mar., 16 oct. 2018 a las 18:49, Alex Harui > >>> (<aha...@adobe.com.invalid>) > >>> escribió: > >>> > >>> > Hi Carlos, > >>> > > >>> > Are you saying you can see that the response from the server > was > >>> received > >>> > by XHR in the browser? > >>> > > >>> > I can't think of anything that I pushed yesterday that would > affect > >>> > response handling. IMO, the changes I made affected the > call to > >>> send(), > >>> > but not the response handling. The other change would > affect what > >>> MXML > >>> > elements were created. I guess you'll just have to debug > into it. > >>> > > >>> > If it helps, there is a -skip-transpile option that is > relatively > >>> > untested, but causes the compiler to skip over any > transpilation > >>> and just > >>> > run the Google Closure Compiler on the js-debug folder. This > >>> should allow > >>> > you to add trace statements (actually console.out) to the .JS > >>> files in the > >>> > js-debug folder and help you debug. If you are only > modifying > >>> framework > >>> > files and not the application files, you don't even need > >>> -skip-transpile, > >>> > since the framework JS files from the SWC that are in > js-debug are > >>> not > >>> > overwritten if they already exist. > >>> > > >>> > You could also revert back until you get a version that > works, or > >>> compare > >>> > the current js-debug against working js-debug, if you still > have a > >>> working > >>> > copy somewhere. > >>> > > >>> > -Alex > >>> > > >>> > On 10/16/18, 3:57 AM, "Carlos Rovira" < > carlosrov...@apache.org> > >>> wrote: > >>> > > >>> > Hi Alex > >>> > > >>> > It seems that latest changes makes MX RO not work in > >>> js-release mode. > >>> > If you remember I could by-pass this problem setting up > >>> > -js-dynamic-access-unknown-members=true > >>> > compiling my Application, but now testing js-release > it's not > >>> working > >>> > at > >>> > all, since we are in release no traces are shown > >>> > calling the operation in the backend just fails silenty. > >>> > > >>> > I only can say that call is done since I can see traces > on my > >>> java > >>> > server, > >>> > and enabling XHR in browser I can see the request is > received > >>> but in > >>> > Royale > >>> > nothing happens. I think this in an important issue (in > the > >>> end it > >>> > will be > >>> > blocking for me to go to production), do you know of > something > >>> done in > >>> > the > >>> > latest changes that could make this fail now? > >>> > > >>> > Thanks > >>> > > >>> > > >>> > > >>> > El lun., 15 oct. 2018 a las 21:17, Carlos Rovira (< > >>> > carlosrov...@apache.org>) > >>> > escribió: > >>> > > >>> > > Hi Alex, > >>> > > with your latest fixes all is working ok :) > >>> > > thanks! > >>> > > > >>> > > El lun., 15 oct. 2018 a las 20:12, Alex Harui > >>> > (<aha...@adobe.com.invalid>) > >>> > > escribió: > >>> > > > >>> > >> Either syntax should work. I just pushed changes to > >>> > AbstractService that > >>> > >> got service.echo() to work. > >>> > >> > >>> > >> -Alex > >>> > >> > >>> > >> On 10/15/18, 10:51 AM, "Carlos Rovira" < > >>> carlosrov...@apache.org> > >>> > wrote: > >>> > >> > >>> > >> Hi Alex, > >>> > >> > >>> > >> one thing I not understand is that this: > >>> > >> > >>> > >> (service.echo as Operation).send(); > >>> > >> > >>> > >> should be > >>> > >> > >>> > >> service.echo() > >>> > >> > >>> > >> I think we're trying to remove "send()" and call > >>> directly > >>> > "echo()" > >>> > >> > >>> > >> I can go to your latest commits in both compiler > and > >>> framework > >>> > and > >>> > >> try, but > >>> > >> don't understand the purpose, since calling with > send() > >>> was > >>> > what we > >>> > >> had, > >>> > >> right? > >>> > >> > >>> > >> Or maybe I'm missing something? > >>> > >> > >>> > >> thanks > >>> > >> > >>> > >> Carlos > >>> > >> > >>> > >> > >>> > >> > >>> > >> > >>> > >> > >>> > >> El lun., 15 oct. 2018 a las 19:15, Alex Harui > >>> > >> (<aha...@adobe.com.invalid>) > >>> > >> escribió: > >>> > >> > >>> > >> > About 10 hours ago, after I cast the call to > send in > >>> the > >>> > example to > >>> > >> be > >>> > >> > (service.echo as Operation).send() , it worked > for me. > >>> > >> > > >>> > >> > I see you have made several changes to the > example > >>> since. Go > >>> > back > >>> > >> to > >>> > >> > where the example was about 10 hours ago, make > that > >>> one > >>> > change to > >>> > >> > service.echo.send() and it should work. If > other > >>> things are > >>> > not > >>> > >> working, I > >>> > >> > will look into them later. > >>> > >> > > >>> > >> > -Alex > >>> > >> > > >>> > >> > On 10/15/18, 10:11 AM, "Carlos Rovira" < > >>> > carlosrov...@apache.org> > >>> > >> wrote: > >>> > >> > > >>> > >> > Hi Alex, > >>> > >> > > >>> > >> > El lun., 15 oct. 2018 a las 18:54, Alex > Harui > >>> > >> > (<aha...@adobe.com.invalid>) > >>> > >> > escribió: > >>> > >> > > >>> > >> > > There may be a couple of things affecting > you. > >>> One is > >>> > that > >>> > >> in the > >>> > >> > bug you > >>> > >> > > reported, it looks like only the first RO > is > >>> created > >>> > and the > >>> > >> others > >>> > >> > are not. > >>> > >> > > > >>> > >> > > >>> > >> > I 'm pretty sure the bug about mx:method is > not > >>> present > >>> > since I > >>> > >> test > >>> > >> > in my > >>> > >> > real project and in the example in our > repo. In > >>> the first > >>> > one I > >>> > >> don't > >>> > >> > have > >>> > >> > any mx:method and in the second I comment to > >>> test. Maybe > >>> > we > >>> > >> should > >>> > >> > comment > >>> > >> > mx:method section in the example for now. > >>> > >> > > >>> > >> > > >>> > >> > > > >>> > >> > > Second, if you notice in the example, > you'll > >>> see things > >>> > like > >>> > >> > (service.echo > >>> > >> > > as Operation).lastResult. After adding > support > >>> for > >>> > >> callProperty, > >>> > >> > the calls > >>> > >> > > now have to change to be either > (service.echo as > >>> > >> Operation).send() or > >>> > >> > > service.echo(). The current syntax in > the repo: > >>> > >> service.echo.send() > >>> > >> > will > >>> > >> > > result in an error because the compiler > cannot > >>> know if > >>> > the > >>> > >> echo > >>> > >> > property on > >>> > >> > > service is also a proxy or not. The > compiler > >>> currently > >>> > >> guesses > >>> > >> > "yes" to > >>> > >> > > make it easier for folks who have existing > >>> nested > >>> > ObjectProxy > >>> > >> data > >>> > >> > sets. > >>> > >> > > So, Royale developers will have to do more > >>> "casting" > >>> > with > >>> > >> "as" than > >>> > >> > in > >>> > >> > > Flash. > >>> > >> > > > >>> > >> > > >>> > >> > check the example since I change already to > the > >>> new > >>> > syntax to > >>> > >> help you > >>> > >> > try > >>> > >> > it. There's no "send()" anymore in the > example in > >>> our > >>> > repo. > >>> > >> > > >>> > >> > > >>> > >> > > > >>> > >> > > In Flash, the difference between proxy > access > >>> and > >>> > regular > >>> > >> property > >>> > >> > access > >>> > >> > > is handled in the runtime. The JS > runtimes do > >>> not do > >>> > this. > >>> > >> The > >>> > >> > compiler > >>> > >> > > could generate code that tests the class > at > >>> runtime, > >>> > but I > >>> > >> think > >>> > >> > that will > >>> > >> > > be too slow. > >>> > >> > > > >>> > >> > > Specific to RemoteObject, it might be > possible > >>> to > >>> > declare the > >>> > >> JS > >>> > >> > > RemoteObject to not be a Proxy and just > Dynamic > >>> and > >>> > have the > >>> > >> > constructor > >>> > >> > > and getOperation call > Object.defineProperty, > >>> but that > >>> > is not a > >>> > >> > general case > >>> > >> > > solution for Proxy. > >>> > >> > > > >>> > >> > > >>> > >> > Hi Alex, that's for me a bit far from my > >>> knowledge. I'm > >>> > sure > >>> > >> whatever > >>> > >> > you > >>> > >> > get would be the best solution. > >>> > >> > Currently mx:RO is broken and I'm working > with > >>> the repo > >>> > just > >>> > >> before the > >>> > >> > change localy to advance, hope you could > take a > >>> look and > >>> > see if > >>> > >> you > >>> > >> > can fix > >>> > >> > the issue. > >>> > >> > If not, probably is better to comment the > changes > >>> in the > >>> > >> compiler (and > >>> > >> > maybe in the framework?) to make it work > again > >>> until we > >>> > know > >>> > >> how to > >>> > >> > fix it. > >>> > >> > > >>> > >> > One thing I could test today (not related) > in the > >>> > meanwhile is > >>> > >> if mx:RO > >>> > >> > works with small messages on. The response > is > >>> not, I > >>> > think that > >>> > >> is the > >>> > >> > AMF > >>> > >> > serialization-deserialization. But I think > this > >>> is not > >>> > crucial, > >>> > >> just > >>> > >> > disabling it could be ok for now for most of > >>> folks out > >>> > there > >>> > >> (just > >>> > >> > knowing > >>> > >> > that they need to configure that to false). > >>> > >> > > >>> > >> > Thanks > >>> > >> > > >>> > >> > Carlos > >>> > >> > > >>> > >> > > >>> > >> > > > >>> > >> > > My 2 cents, > >>> > >> > > -Alex > >>> > >> > > > >>> > >> > > On 10/15/18, 4:51 AM, "Carlos Rovira" < > >>> > >> carlosrov...@apache.org> > >>> > >> > wrote: > >>> > >> > > > >>> > >> > > Hi Alex, > >>> > >> > > > >>> > >> > > I added to the RO test example the > >>> CompressedRO > >>> > test case > >>> > >> > commented to > >>> > >> > > help > >>> > >> > > you find the problem. > >>> > >> > > I couldn't test like in net RO since > now > >>> the entire > >>> > >> example is > >>> > >> > > failing, but > >>> > >> > > once the callProperty works for a > normal > >>> case > >>> > should help > >>> > >> us to > >>> > >> > check > >>> > >> > > if > >>> > >> > > the rest of RO works since it uses > >>> > >> "convertParametersHandler" > >>> > >> > > > >>> > >> > > I'll revert localy this changes in > order to > >>> advance > >>> > in my > >>> > >> real > >>> > >> > world > >>> > >> > > app in > >>> > >> > > the mean while > >>> > >> > > > >>> > >> > > thanks > >>> > >> > > > >>> > >> > > > >>> > >> > > > >>> > >> > > El lun., 15 oct. 2018 a las 13:40, > Carlos > >>> Rovira (< > >>> > >> > > carlosrov...@apache.org>) > >>> > >> > > escribió: > >>> > >> > > > >>> > >> > > > Hi Alex, > >>> > >> > > > > >>> > >> > > > I found that even if I remove > completely > >>> > >> > CompressedRemoteObject and > >>> > >> > > use > >>> > >> > > > only normal mx:RemoteObject the > error > >>> shows: > >>> > >> > > > > >>> > >> > > > [Error] TypeError: undefined is not > an > >>> object > >>> > >> (evaluating > >>> > >> > > > > >>> 'this.remoteObject.convertParametersHandler') > >>> > >> > > > > >>> > >> > > > > >>> > >> > > > > >>> > >> > > > > >>> > >> > > > El lun., 15 oct. 2018 a las 13:00, > Carlos > >>> Rovira > >>> > (< > >>> > >> > > carlosrov...@apache.org>) > >>> > >> > > > escribió: > >>> > >> > > > > >>> > >> > > >> Hi Alex, > >>> > >> > > >> > >>> > >> > > >> I'm finding a problem with > callProperty. > >>> I'm > >>> > using a > >>> > >> > > >> CompressedRemoteObjeect that uses > two > >>> hooks in > >>> > >> RemoteObject > >>> > >> > API > >>> > >> > > >> > >>> > >> > > >> public var > >>> convertParametersHandler:Function; > >>> > >> > > >> > >>> > >> > > >> and > >>> > >> > > >> public var > convertResultHandler:Function; > >>> > >> > > >> > >>> > >> > > >> this makes the call fail with > >>> > >> > > >> > >>> > >> > > >> [Error] TypeError: undefined is > not an > >>> object > >>> > >> (evaluating > >>> > >> > > >> > >>> 'this.remoteObject.convertParametersHandler') > >>> > >> > > >> send (Operation.js:109) > >>> > >> > > >> callProperty > (AbstractService.js:147:111) > >>> > >> > > >> dologin (LoginForm.js:181) > >>> > >> > > >> $EH1 (LoginForm.js:226) > >>> > >> > > >> (función anónima) > >>> > >> > > >> fireListener (events.js:744) > >>> > >> > > >> fireListenerOverride > >>> (HTMLElementWrapper.js:61) > >>> > >> > > >> handleBrowserEvent_ (events.js:870) > >>> > >> > > >> (función anónima) (events.js:289) > >>> > >> > > >> > >>> > >> > > >> So I guess the proxy is trying to > proxy > >>> all even > >>> > its > >>> > >> own > >>> > >> > member > >>> > >> > > functions > >>> > >> > > >> that should not be affected, makes > this > >>> sense? > >>> > >> > > >> > >>> > >> > > >> thanks > >>> > >> > > >> > >>> > >> > > >> > >>> > >> > > >> El lun., 15 oct. 2018 a las 7:15, > Alex > >>> Harui > >>> > >> > > (<aha...@adobe.com.invalid>) > >>> > >> > > >> escribió: > >>> > >> > > >> > >>> > >> > > >>> I pushed changes to the compiler > and > >>> framework > >>> > to try > >>> > >> to get > >>> > >> > > >>> callProperty to work. I don't > have a > >>> test case > >>> > but > >>> > >> give it > >>> > >> > a try > >>> > >> > > and see > >>> > >> > > >>> what happens. > >>> > >> > > >>> > >>> > >> > > >>> If you compare the size of the > output > >>> with and > >>> > without > >>> > >> > > >>> -js-dynamic-access, you can see > the > >>> theoretical > >>> > >> savings of > >>> > >> > not > >>> > >> > > using that > >>> > >> > > >>> option. If that savings might > matter, > >>> then it > >>> > might > >>> > >> be worth > >>> > >> > > spending some > >>> > >> > > >>> time on fixing up the issues that > >>> > -js-dynamic-access > >>> > >> "works > >>> > >> > > around". But > >>> > >> > > >>> keep in mind that there probably > isn't > >>> any way > >>> > to > >>> > >> grab all > >>> > >> > of the > >>> > >> > > >>> theoretical savings. What we > don’t > >>> know yet is > >>> > where > >>> > >> you'll > >>> > >> > > actually end > >>> > >> > > >>> up. It might even be true that > >>> > -js-dynamic-access is > >>> > >> more > >>> > >> > optimal. > >>> > >> > > >>> > >>> > >> > > >>> -Alex > >>> > >> > > >>> > >>> > >> > > >>> On 10/14/18, 3:02 PM, "Carlos > Rovira" < > >>> > >> > carlosrov...@apache.org> > >>> > >> > > wrote: > >>> > >> > > >>> > >>> > >> > > >>> Hi Alex > >>> > >> > > >>> > >>> > >> > > >>> El dom., 14 oct. 2018 a las > 23:48, > >>> Alex > >>> > Harui > >>> > >> > > >>> (<aha...@adobe.com.invalid>) > >>> > >> > > >>> escribió: > >>> > >> > > >>> > >>> > >> > > >>> > I got the resources working > so I > >>> will > >>> > look into > >>> > >> > > Proxy.callProperty. > >>> > >> > > >>> > > >>> > >> > > >>> > > >>> > >> > > >>> That's cool, I'm closing for > today, > >>> I can > >>> > try in > >>> > >> some > >>> > >> > hours if > >>> > >> > > you > >>> > >> > > >>> upload > >>> > >> > > >>> some changes. Thanks > >>> > >> > > >>> > >>> > >> > > >>> > >>> > >> > > >>> > The issue with > js-dynamic-access > >>> isn't > >>> > about MX > >>> > >> > RemoteObject > >>> > >> > > vs > >>> > >> > > >>> Basic > >>> > >> > > >>> > RemoteObject, it is > whether, if > >>> we fixed > >>> > places > >>> > >> in any > >>> > >> > of > >>> > >> > > the code > >>> > >> > > >>> where > >>> > >> > > >>> > minification breaks things, > what > >>> the > >>> > >> size/performance > >>> > >> > > trade-off > >>> > >> > > >>> would be. > >>> > >> > > >>> > Some variable names would be > >>> longer, but > >>> > some > >>> > >> other > >>> > >> > code > >>> > >> > > might be > >>> > >> > > >>> more > >>> > >> > > >>> > verbose as public vars are > >>> converted into > >>> > >> > getter/setters and > >>> > >> > > have > >>> > >> > > >>> function > >>> > >> > > >>> > call overhead. I guess > we'll > >>> find out > >>> > when we > >>> > >> get > >>> > >> > someone's > >>> > >> > > app > >>> > >> > > >>> to the > >>> > >> > > >>> > point where they are ready > to get > >>> the > >>> > production > >>> > >> > version to > >>> > >> > > run. > >>> > >> > > >>> > > >>> > >> > > >>> > >>> > >> > > >>> Well, I'll need to have my > app in > >>> > production by > >>> > >> the > >>> > >> > end/start > >>> > >> > > of the > >>> > >> > > >>> year, > >>> > >> > > >>> so we'll can check this with > mine. > >>> For now > >>> > it > >>> > >> seems I > >>> > >> > need to > >>> > >> > > left > >>> > >> > > >>> this > >>> > >> > > >>> configuration or release > version > >>> can pass > >>> > the > >>> > >> login (the > >>> > >> > mx RO > >>> > >> > > call > >>> > >> > > >>> to the > >>> > >> > > >>> server) > >>> > >> > > >>> > >>> > >> > > >>> > >>> > >> > > >>> > >>> > >> > > >>> > > >>> > >> > > >>> > -Alex > >>> > >> > > >>> > > >>> > >> > > >>> > On 10/14/18, 2:23 PM, > "Carlos > >>> Rovira" < > >>> > >> > > carlosrov...@apache.org> > >>> > >> > > >>> wrote: > >>> > >> > > >>> > > >>> > >> > > >>> > Hi Alex, > >>> > >> > > >>> > > >>> > >> > > >>> > El dom., 14 oct. 2018 a > las > >>> 18:32, > >>> > Alex > >>> > >> Harui > >>> > >> > > >>> > (<aha...@adobe.com.invalid > >) > >>> > >> > > >>> > escribió: > >>> > >> > > >>> > > >>> > >> > > >>> > > Hi Carlos, > >>> > >> > > >>> > > > >>> > >> > > >>> > > JS proxy doesn't > support > >>> > callProperty > >>> > >> yet. Feel > >>> > >> > free > >>> > >> > > to add > >>> > >> > > >>> it, or > >>> > >> > > >>> > I will > >>> > >> > > >>> > > after I finish up > >>> ResourceManager. > >>> > >> > > >>> > > > >>> > >> > > >>> > > >>> > >> > > >>> > JS proxy is > >>> mx.utlis.ObjectProxy or > >>> > you > >>> > >> mean maybe > >>> > >> > > >>> AbstractService > >>> > >> > > >>> > callProperty? > >>> > >> > > >>> > I could take a look, > but no > >>> promises > >>> > since > >>> > >> I don't > >>> > >> > know > >>> > >> > > >>> exactly how > >>> > >> > > >>> > that > >>> > >> > > >>> > works. A little of > guidance > >>> here > >>> > could me > >>> > >> make get > >>> > >> > this > >>> > >> > > done. > >>> > >> > > >>> > > >>> > >> > > >>> > > >>> > >> > > >>> > > > >>> > >> > > >>> > > I don't doubt that > >>> minification > >>> > breaks > >>> > >> lots of > >>> > >> > things > >>> > >> > > that > >>> > >> > > >>> > > js-dynamic-access > fixes. > >>> Hard to > >>> > say how > >>> > >> much > >>> > >> > smaller > >>> > >> > > your > >>> > >> > > >>> app > >>> > >> > > >>> > would be if > >>> > >> > > >>> > > we fixed anough stuff > >>> without that > >>> > option. > >>> > >> > > >>> > > > >>> > >> > > >>> > > > >>> > >> > > >>> > well, including > >>> mx:RemoteObject seems > >>> > to > >>> > >> increase > >>> > >> > > >>> significantly my > >>> > >> > > >>> > current > >>> > >> > > >>> > app in release mode > "mx" is > >>> 1'8mb > >>> > while > >>> > >> > > "org.apache.royale" is > >>> > >> > > >>> > 1'8mb...but > >>> > >> > > >>> > is ok for me since I > think is > >>> a normal > >>> > >> payload for > >>> > >> > the > >>> > >> > > base of > >>> > >> > > >>> a normal > >>> > >> > > >>> > App, and MX RO here > does an > >>> important > >>> > role > >>> > >> in my > >>> > >> > case. So > >>> > >> > > >>> happy to pay > >>> > >> > > >>> > the > >>> > >> > > >>> > price ;) > >>> > >> > > >>> > > >>> > >> > > >>> > > >>> > >> > > >>> > > >>> > >> > > >>> > > -Alex > >>> > >> > > >>> > > > >>> > >> > > >>> > > -- > >>> > >> > > >>> > > Carlos Rovira > >>> > >> > > >>> > > > >>> > >> > > >>> > > >>> > >> > > >>> > >>> > >> > > > >>> > >> > > >>> > >> > >>> > > >>> > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C38701cdbe0a54f94806408d634388cbf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636753814815713802&sdata=5VSjC5U%2FEvLIyycQIgDTOdOvKozW4cat3zvHPR%2FfTYs%3D&reserved=0 > >>> > >> > > >>> > > > >>> > >> > > >>> > > > >>> > >> > > >>> > > > >>> > >> > > >>> > > > >>> > >> > > >>> > > >>> > >> > > >>> > > >>> > >> > > >>> > > >>> > >> > > >>> > >>> > >> > > >>> -- > >>> > >> > > >>> Carlos Rovira > >>> > >> > > >>> > >>> > >> > > >>> > >>> > >> > > > >>> > >> > > >>> > >> > >>> > > >>> > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C38701cdbe0a54f94806408d634388cbf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636753814815713802&sdata=5VSjC5U%2FEvLIyycQIgDTOdOvKozW4cat3zvHPR%2FfTYs%3D&reserved=0 > >>> > >> > > >>> > >>> > >> > > >>> > >>> > >> > > >>> > >>> > >> > > >> > >>> > >> > > >> -- > >>> > >> > > >> Carlos Rovira > >>> > >> > > >> > >>> > >> > > > >>> > >> > > >>> > >> > >>> > > >>> > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C38701cdbe0a54f94806408d634388cbf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636753814815713802&sdata=5VSjC5U%2FEvLIyycQIgDTOdOvKozW4cat3zvHPR%2FfTYs%3D&reserved=0 > >>> > >> > > >> > >>> > >> > > >> > >>> > >> > > > > >>> > >> > > > -- > >>> > >> > > > Carlos Rovira > >>> > -- Carlos Rovira http://about.me/carlosrovira
