HI Alex, El jue., 18 oct. 2018 a las 0:26, Alex Harui (<aha...@adobe.com.invalid>) escribió:
> Hi Carlos, > > Well, that is my suggestion for how you can figure this out. In theory, > there should be relatively few differences in js-debug and those few > differences are likely to be the difference in the js-release version. > > ok > Also, in theory, the source-maps work and running the js-release in the > debugger should show where in the js-debug the exception is coming from. > > There's no source-maps on release version, I talked about this with Josh and point me that was not point in having source maps on release version, so I removed in the compiler, since from that point of view was a thing left undone when he did source maps. In fact debug is not working ok and I asked Josh to solve the actual issues. > Hopefully your time budget considered that Royale is still beta quality. > This is, hopefully, a relatively straightforward issue and having more > people understand how to debug production code is a good thing for the > community. It can't always be me. > Well, you know that sell a development to a final client is not as easy as that. I tried to put in balance if the things needed to get the project done was in place. I thought at that time that is true, since the things still to be done are, dependent of my work on Jewel mostly (end DropDownList, create autocomplete bead for ComboBox,...), but things like this was not considered since at that time this problem wasn't exists. At the end, if I put on table all things that could be show stoppers, we could end many months / years to start a real project, and I think that's not real too. I consider the help of this community, since that kind of things is what I'm finding as arguments inside my company to not go with Royale. I think as you that I as many others here, must be self sufficient at many levels. Taking into account that each one nature, make be more capable in some aspects than in others. For example, I think I can ask you to make more "designer" things in the website or in themes, since I think, correct me if I'm wrong, is not in your skill set, but you can do something of that kind in certain circumstances. I think this is the same. I can try to do this, and will do, of course, but I think there's a certain amount of probabilities that I'm not successful in getting what is going wrong. Hope I'll be wrong in my research...I'll let you know > > Good luck, > -Alex > > On 10/17/18, 11:19 AM, "Carlos Rovira" <carlosrov...@apache.org> wrote: > > 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%7Cc01ffc8e334943c65c7d08d6345d234b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636753971960008346&sdata=nUvm817M8DOGllSRz8fj8kQ%2Friec5jvTkH2Kz7P1AWk%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%7Cc01ffc8e334943c65c7d08d6345d234b%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636753971960008346&sdata=i3zV%2FoOc2ObIzmlaCO6pEZRuQoL7fMFOQT9v%2FonE3x4%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 > -- Carlos Rovira http://about.me/carlosrovira
