Hi Alex, one thing to take into account, you talk about to compare debug versions, but the problem is that debug versions works right, so I think you'll didn't find nothing related to the real problem there. Thanks
El mié., 17 oct. 2018 a las 17:48, Carlos Rovira (<carlosrov...@apache.org>) escribió: > 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 > > -- Carlos Rovira http://about.me/carlosrovira
