You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Piotr Zarzycki <pi...@gmail.com> on 2017/07/11 08:14:35 UTC
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are
assumed to be POST
Hi Yishay,
I think you could use constant here -> HTTPConstants.POST
Thanks, Piotr
2017-07-11 10:09 GMT+02:00 <yi...@apache.org>:
> Repository: flex-asjs
> Updated Branches:
> refs/heads/develop cc098932c -> 3b5053f91
>
>
> Uploads are assumed to be POST
>
>
> Project: http://git-wip-us.apache.org/repos/asf/flex-asjs/repo
> Commit: http://git-wip-us.apache.org/repos/asf/flex-asjs/commit/3b5053f9
> Tree: http://git-wip-us.apache.org/repos/asf/flex-asjs/tree/3b5053f9
> Diff: http://git-wip-us.apache.org/repos/asf/flex-asjs/diff/3b5053f9
>
> Branch: refs/heads/develop
> Commit: 3b5053f91f869a7fd4cd1eccf80e696e5171b532
> Parents: cc09893
> Author: DESKTOP-RH4S838\Yishay <yi...@hotmail.com>
> Authored: Tue Jul 11 11:08:32 2017 +0300
> Committer: DESKTOP-RH4S838\Yishay <yi...@hotmail.com>
> Committed: Tue Jul 11 11:08:32 2017 +0300
>
> ----------------------------------------------------------------------
> .../src/main/flex/org/apache/flex/file/beads/FileUploader.as | 1 +
> 1 file changed, 1 insertion(+)
> ----------------------------------------------------------------------
>
>
> http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/
> 3b5053f9/frameworks/projects/Network/src/main/flex/org/
> apache/flex/file/beads/FileUploader.as
> ----------------------------------------------------------------------
> diff --git a/frameworks/projects/Network/src/main/flex/org/apache/flex/file/beads/FileUploader.as
> b/frameworks/projects/Network/src/main/flex/org/apache/flex/
> file/beads/FileUploader.as
> index e9aad3c..194a1d6 100644
> --- a/frameworks/projects/Network/src/main/flex/org/apache/flex/
> file/beads/FileUploader.as
> +++ b/frameworks/projects/Network/src/main/flex/org/apache/flex/
> file/beads/FileUploader.as
> @@ -80,6 +80,7 @@ package org.apache.flex.file.beads
> // }
> var binaryUploader:URLBinaryLoader = new
> URLBinaryLoader();
> var req:URLRequest = new URLRequest();
> + req.method = "POST";
> req.data = (host.model as FileModel).blob;
> req.url = url;
> binaryUploader.addEventListener(Event.COMPLETE,
> completeHandler);
>
>
RE: git commit: [flex-asjs] [refs/heads/develop] - Uploads are
assumed to be POST
Posted by Yishay Weiss <yi...@hotmail.com>.
Normally I would agree, but I was trying to be strict about PAYG in these commits. Let’s see what the others say.
From: piotrz<ma...@gmail.com>
Sent: Tuesday, July 11, 2017 12:05 PM
To: dev@flex.apache.org<ma...@flex.apache.org>
Subject: RE: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST
I just think that we should use const whenever we can, but won't fight for
that if no one think similar. :) If I found such code around my interest my
natural move would be change it :)
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Re-git-commit-flex-asjs-refs-heads-develop-Uploads-are-assumed-to-be-POST-tp63070p63078.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST
Posted by Harbs <ha...@gmail.com>.
I don’t know. I don’t use logging nearly as much as I probably should.
I was just pointing out the goog.log package on the JS side in case you want to implement something.
Thanks,
Harbs
> On Jul 12, 2017, at 10:39 AM, Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
>> It might be nice to have a generic cross-platform logging package.
>
> Like mx.logging perhaps? Or Apache common logging as there's an AS version of that? I don’t imagine either would be hard to make cross platform.
>
> Thanks,
> Justin
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are
assumed to be POST
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> It might be nice to have a generic cross-platform logging package.
Like mx.logging perhaps? Or Apache common logging as there's an AS version of that? I don’t imagine either would be hard to make cross platform.
Thanks,
Justin
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST
Posted by Harbs <ha...@gmail.com>.
There is a goog.log package.[1]
Unless I’m mistaken, those calls are removed by the compiler.
It might be nice to have a generic cross-platform logging package.
[1]https://google.github.io/closure-library/api/goog.log.html <https://google.github.io/closure-library/api/goog.log.html>
> On Jul 12, 2017, at 10:06 AM, Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
>> Once we’re on this topic, there’s something that I had wanted to bring up for a long time: I think trace statements should disappear in the release JS build. Should we put all the JS trace code inside an if(goog.DEBUG) block?
>
> I’d suggest putting in a static Log class/method that is does nothing if goog.DEBUG is false and traces goog.DEBUG is true. That way it makes easier to move to a real logging system at some point in the future.
>
> Thanks,
> Justin
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are
assumed to be POST
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Once we’re on this topic, there’s something that I had wanted to bring up for a long time: I think trace statements should disappear in the release JS build. Should we put all the JS trace code inside an if(goog.DEBUG) block?
I’d suggest putting in a static Log class/method that is does nothing if goog.DEBUG is false and traces goog.DEBUG is true. That way it makes easier to move to a real logging system at some point in the future.
Thanks,
Justin
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST
Posted by Harbs <ha...@gmail.com>.
Like I said, it would be nice to figure out how to remove it completely.
It’s not awfully expensive though. It’s a simple copy of an array with a single string.
> On Jul 12, 2017, at 11:52 AM, Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
>> function uM(a){a=Array.prototype.slice.call(arguments,0)}w('org.apache.flex.utils.Language.trace',uM);
>
> I could be wrong but wouldn’t the call to Array.prototype.slice still be rather expensive?
>
> Thanks,
> Justin
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are
assumed to be POST
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> function uM(a){a=Array.prototype.slice.call(arguments,0)}w('org.apache.flex.utils.Language.trace',uM);
I could be wrong but wouldn’t the call to Array.prototype.slice still be rather expensive?
Thanks,
Justin
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST
Posted by Harbs <ha...@gmail.com>.
I actually realized that if I don’t do a clean before a regular compile, the release is built from the modified JS files in the framework.
I moved "if (!goog.DEBUG)return;” to the very beginning of the function and removed the @export tag. With that change, all traces of trace are removed. (pun intended) ;-)
I think the takeaway should be that we should have some kind of metadata that the compiler recognizes to not insert the @export tag and insert a bailout if goog.DEBUG is false. That would allow us to define arbitrary functions to run on a debug build and be automatically stripped out for release.
A @debug comment before the function declaration is probably the simplest solution and fits with the current conventions.
I’m not sure what this would all look like for a swf compile.
Harbs
> On Jul 13, 2017, at 12:35 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Bummer. It looks like you are using a custom template and I never tried
> that. I think you can just check for a null mainCU and get past that.
>
> On 7/12/17, 10:11 AM, "Harbs" <ha...@gmail.com> wrote:
>
>> Maybe I’m doing something wrong, but I get the following error when I
>> tried using -skip-transpile:
>>
>> [java] java.lang.NullPointerException
>> org.apache.flex.compiler.internal.projects.FlexJSProject.computeTargetAttr
>> ibutes(FlexJSProject.java:354)org.apache.flex.compiler.internal.codegen.mx
>> ml.flexjs.MXMLFlexJSPublisher.writeTemplate(MXMLFlexJSPublisher.java:554)o
>> rg.apache.flex.compiler.internal.codegen.mxml.flexjs.MXMLFlexJSPublisher.p
>> ublish(MXMLFlexJSPublisher.java:345)org.apache.flex.compiler.clients.MXMLJ
>> SCFlex.compile(MXMLJSCFlex.java:387)org.apache.flex.compiler.clients.MXMLJ
>> SCFlex._mainNoExit(MXMLJSCFlex.java:245)org.apache.flex.compiler.clients.M
>> XMLJSCFlex.mainNoExit(MXMLJSCFlex.java:202)org.apache.flex.compiler.client
>> s.MXMLJSC._mainNoExit(MXMLJSC.java:352)org.apache.flex.compiler.clients.MX
>> MLJSC.mainNoExit(MXMLJSC.java:287)org.apache.flex.compiler.clients.MXMLJSC
>> .staticMainNoExit(MXMLJSC.java:247)org.apache.flex.compiler.clients.MXMLJS
>> C.main(MXMLJSC.java:229)
>> [java]
>> [java]
>> [java] Java Result: 3
>>
>>> On Jul 12, 2017, at 7:48 PM, Alex Harui <ah...@adobe.com.INVALID>
>>> wrote:
>>>
>>> Trace supports multiple parameters and concatenates them with " "
>>> in-between.
>>>
>>> If you want to investigate more, you can use -sdk-js-lib to point to a
>>> hacked version of Language.js with goog.DEBUG around the "rest" code.
>>>
>>> I think you can also just modify what is in bin/js-debug and run the
>>> compiler with the -skip-transpile option and it won't re-transpile and
>>> just pass js-debug files to GCC and generate a new js-release output.
>>>
>>> -Alex
>>>
>>> On 7/12/17, 9:11 AM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>>> That line was what was left of the trace function.
>>>>
>>>> The reason the trace function is not completely empty is because it has
>>>> this code generated from "…rest” at the start of the function:
>>>> rest = Array.prototype.slice.call(arguments, 0);
>>>>
>>>> I have no idea why that code is necessary. Maybe if it was not
>>>> generated
>>>> and the function was truly empty, the trace calls would be stripped out
>>>> as well?
>>>>
>>>> Leftover trace calls elsewhere in the code look something like this:
>>>> uM('unexpected condition in deferredBindingsHandler’);
>>>>
>>>>> On Jul 12, 2017, at 6:08 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>>> wrote:
>>>>>
>>>>> If it were up to me, we'd strip traces based on the optimize compiler
>>>>> option. I think that's how it worked in the Flex SDK.
>>>>>
>>>>> I thought GCC had enough dead-code-removal logic to remove
>>>>> Language.trace
>>>>> once it saw that trace effectively did nothing.
>>>>>
>>>>> I can't seem to piece together from this thread what the original AS
>>>>> was
>>>>> and what the un-minified JS output was. Maybe there's something about
>>>>> the
>>>>> JS output that isn't right. It is strange to see the string name of
>>>>> the
>>>>> trace function.
>>>>>
>>>>> Regarding a logging system, I think folks are just used to trace and
>>>>> the
>>>>> cool thing about JS right now is that you can replace functions at
>>>>> runtime, so a logging bead would just replace Language.trace().
>>>>>
>>>>> -Alex
>>>>>
>>>>> On 7/12/17, 6:44 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>
>>>>>> Interesting scenarios. I would not have thought of that.
>>>>>>
>>>>>> If we could figure out how to strip the function call and leave the
>>>>>> parameter, the compiler would strip out the contents if it could be
>>>>>> safely removed.
>>>>>>
>>>>>> So trace(“something”) would become “something” which is en empty
>>>>>> statement and would be stripped out.
>>>>>>
>>>>>> Of course, I have no idea how to go about doing that… ;-)
>>>>>>
>>>>>> Harbs
>>>>>>
>>>>>>> On Jul 12, 2017, at 4:32 PM, Josh Tynjala <jo...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Probably the same with function calls too:
>>>>>>>
>>>>>>> trace(someFunction());
>>>>>>>
>>>>>>> They wanted this to remain:
>>>>>>>
>>>>>>> someFunction();
>>>>>>>
>>>>>>> - Josh
>>>>>>>
>>>>>>> On Wed, Jul 12, 2017 at 6:22 AM, Josh Tynjala
>>>>>>> <jo...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> One thing to keep in mind with stripping out trace() calls is that
>>>>>>>> some
>>>>>>>> developers expect any modifications to variables that happen inside
>>>>>>>> the
>>>>>>>> arguments to remain. I remember a while back someone at Adobe
>>>>>>>> mentioning
>>>>>>>> that people complained when something like this was completely
>>>>>>>> stripped out:
>>>>>>>>
>>>>>>>> trace(doSomething++);
>>>>>>>>
>>>>>>>> Because they expected this part to remain:
>>>>>>>>
>>>>>>>> doSomething++;
>>>>>>>>
>>>>>>>> - Josh
>>>>>>>>
>>>>>>>> On Wed, Jul 12, 2017 at 12:24 AM, Harbs <ha...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> My bad. It does in fact compile down to this:
>>>>>>>>>
>>>>>>>>> function
>>>>>>>>> uM(a){a=Array.prototype.slice.call(arguments,0)}w('org.apach
>>>>>>>>> e.flex.utils.Language.trace',uM);
>>>>>>>>>
>>>>>>>>> So trace does not actually do anything. Great! :-)
>>>>>>>>>
>>>>>>>>> However, it’s still being called by the client code. (It just does
>>>>>>>>> nothing.) Not super important, but it would be nice if at some
>>>>>>>>> point
>>>>>>>>> we can
>>>>>>>>> figure out if there’s a way to strip out the calls completely.
>>>>>>>>>
>>>>>>>>>> On Jul 12, 2017, at 10:07 AM, Harbs <ha...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Oof. I think I’m still waking up. ;-)
>>>>>>>>>>
>>>>>>>>>> I did not realize what I was looking at with the goog.DEBUG. My
>>>>>>>>> recollection is that trace statements are still being used in the
>>>>>>>>> release,
>>>>>>>>> but I’ll double check that.
>>>>>>>>>>
>>>>>>>>>>> On Jul 12, 2017, at 9:56 AM, Alex Harui
>>>>>>>>>>> <ah...@adobe.com.INVALID>
>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Well, the goal of using goog.DEBUG in Language.as trace() was to
>>>>>>>>> convince
>>>>>>>>>>> GCC to eliminate trace(). I haven't checked whether it is
>>>>>>>>>>> working
>>>>>>>>>>> or
>>>>>>>>> not.
>>>>>>>>>>> Requiring everyone to use goog.DEBUG around trace statements
>>>>>>>>>>> sounds
>>>>>>>>> like
>>>>>>>>>>> a pain. Probably better to teach the publisher to remove it if
>>>>>>>>>>> GCC
>>>>>>>>> can't
>>>>>>>>>>> be taught to do it. We visit almost every line of the JS output
>>>>>>>>>>> in
>>>>>>>>>>> the
>>>>>>>>>>> publishers right now.
>>>>>>>>>>>
>>>>>>>>>>> My 2 cents,
>>>>>>>>>>> -Alex
>>>>>>>>>>>
>>>>>>>>>>> On 7/11/17, 11:47 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> On Jul 12, 2017, at 8:20 AM, Alex Harui
>>>>>>>>>>>>> <ah...@adobe.com.INVALID>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Again, though, I think this optimization isn't urgent.
>>>>>>>>>>>>
>>>>>>>>>>>> I completely agree. That’s why I have not been bringing this up
>>>>>>>>> despite
>>>>>>>>>>>> it being on my mind. When the discussion came up, I couldn’t
>>>>>>>>>>>> help
>>>>>>>>>>>> but
>>>>>>>>>>>> join. ;-)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> goog.DEBUG is already being used in Language.as.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks! I hadn’t noticed. I was missing an import of of
>>>>>>>>>>>> goog.DEBUG
>>>>>>>>>>>> in
>>>>>>>>>>>> COMPILE::JS I’m guessing the imports of goog.bind and
>>>>>>>>>>>> goog.global
>>>>>>>>>>>> was
>>>>>>>>>>>> enough to make goog.DEBUG visible to the compiler in
>>>>>>>>>>>> Language.as.
>>>>>>>>>>>>
>>>>>>>>>>>> Once we’re on this topic, there’s something that I had wanted
>>>>>>>>>>>> to
>>>>>>>>> bring up
>>>>>>>>>>>> for a long time: I think trace statements should disappear in
>>>>>>>>>>>> the
>>>>>>>>> release
>>>>>>>>>>>> JS build. Should we put all the JS trace code inside an
>>>>>>>>>>>> if(goog.DEBUG)
>>>>>>>>>>>> block?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Harbs
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are
assumed to be POST
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Bummer. It looks like you are using a custom template and I never tried
that. I think you can just check for a null mainCU and get past that.
On 7/12/17, 10:11 AM, "Harbs" <ha...@gmail.com> wrote:
>Maybe I’m doing something wrong, but I get the following error when I
>tried using -skip-transpile:
>
> [java] java.lang.NullPointerException
>org.apache.flex.compiler.internal.projects.FlexJSProject.computeTargetAttr
>ibutes(FlexJSProject.java:354)org.apache.flex.compiler.internal.codegen.mx
>ml.flexjs.MXMLFlexJSPublisher.writeTemplate(MXMLFlexJSPublisher.java:554)o
>rg.apache.flex.compiler.internal.codegen.mxml.flexjs.MXMLFlexJSPublisher.p
>ublish(MXMLFlexJSPublisher.java:345)org.apache.flex.compiler.clients.MXMLJ
>SCFlex.compile(MXMLJSCFlex.java:387)org.apache.flex.compiler.clients.MXMLJ
>SCFlex._mainNoExit(MXMLJSCFlex.java:245)org.apache.flex.compiler.clients.M
>XMLJSCFlex.mainNoExit(MXMLJSCFlex.java:202)org.apache.flex.compiler.client
>s.MXMLJSC._mainNoExit(MXMLJSC.java:352)org.apache.flex.compiler.clients.MX
>MLJSC.mainNoExit(MXMLJSC.java:287)org.apache.flex.compiler.clients.MXMLJSC
>.staticMainNoExit(MXMLJSC.java:247)org.apache.flex.compiler.clients.MXMLJS
>C.main(MXMLJSC.java:229)
> [java]
> [java]
> [java] Java Result: 3
>
>> On Jul 12, 2017, at 7:48 PM, Alex Harui <ah...@adobe.com.INVALID>
>>wrote:
>>
>> Trace supports multiple parameters and concatenates them with " "
>> in-between.
>>
>> If you want to investigate more, you can use -sdk-js-lib to point to a
>> hacked version of Language.js with goog.DEBUG around the "rest" code.
>>
>> I think you can also just modify what is in bin/js-debug and run the
>> compiler with the -skip-transpile option and it won't re-transpile and
>> just pass js-debug files to GCC and generate a new js-release output.
>>
>> -Alex
>>
>> On 7/12/17, 9:11 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>>> That line was what was left of the trace function.
>>>
>>> The reason the trace function is not completely empty is because it has
>>> this code generated from "…rest” at the start of the function:
>>> rest = Array.prototype.slice.call(arguments, 0);
>>>
>>> I have no idea why that code is necessary. Maybe if it was not
>>>generated
>>> and the function was truly empty, the trace calls would be stripped out
>>> as well?
>>>
>>> Leftover trace calls elsewhere in the code look something like this:
>>> uM('unexpected condition in deferredBindingsHandler’);
>>>
>>>> On Jul 12, 2017, at 6:08 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>> wrote:
>>>>
>>>> If it were up to me, we'd strip traces based on the optimize compiler
>>>> option. I think that's how it worked in the Flex SDK.
>>>>
>>>> I thought GCC had enough dead-code-removal logic to remove
>>>> Language.trace
>>>> once it saw that trace effectively did nothing.
>>>>
>>>> I can't seem to piece together from this thread what the original AS
>>>>was
>>>> and what the un-minified JS output was. Maybe there's something about
>>>> the
>>>> JS output that isn't right. It is strange to see the string name of
>>>>the
>>>> trace function.
>>>>
>>>> Regarding a logging system, I think folks are just used to trace and
>>>>the
>>>> cool thing about JS right now is that you can replace functions at
>>>> runtime, so a logging bead would just replace Language.trace().
>>>>
>>>> -Alex
>>>>
>>>> On 7/12/17, 6:44 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>
>>>>> Interesting scenarios. I would not have thought of that.
>>>>>
>>>>> If we could figure out how to strip the function call and leave the
>>>>> parameter, the compiler would strip out the contents if it could be
>>>>> safely removed.
>>>>>
>>>>> So trace(“something”) would become “something” which is en empty
>>>>> statement and would be stripped out.
>>>>>
>>>>> Of course, I have no idea how to go about doing that… ;-)
>>>>>
>>>>> Harbs
>>>>>
>>>>>> On Jul 12, 2017, at 4:32 PM, Josh Tynjala <jo...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Probably the same with function calls too:
>>>>>>
>>>>>> trace(someFunction());
>>>>>>
>>>>>> They wanted this to remain:
>>>>>>
>>>>>> someFunction();
>>>>>>
>>>>>> - Josh
>>>>>>
>>>>>> On Wed, Jul 12, 2017 at 6:22 AM, Josh Tynjala
>>>>>><jo...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> One thing to keep in mind with stripping out trace() calls is that
>>>>>>> some
>>>>>>> developers expect any modifications to variables that happen inside
>>>>>>> the
>>>>>>> arguments to remain. I remember a while back someone at Adobe
>>>>>>> mentioning
>>>>>>> that people complained when something like this was completely
>>>>>>> stripped out:
>>>>>>>
>>>>>>> trace(doSomething++);
>>>>>>>
>>>>>>> Because they expected this part to remain:
>>>>>>>
>>>>>>> doSomething++;
>>>>>>>
>>>>>>> - Josh
>>>>>>>
>>>>>>> On Wed, Jul 12, 2017 at 12:24 AM, Harbs <ha...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> My bad. It does in fact compile down to this:
>>>>>>>>
>>>>>>>> function
>>>>>>>> uM(a){a=Array.prototype.slice.call(arguments,0)}w('org.apach
>>>>>>>> e.flex.utils.Language.trace',uM);
>>>>>>>>
>>>>>>>> So trace does not actually do anything. Great! :-)
>>>>>>>>
>>>>>>>> However, it’s still being called by the client code. (It just does
>>>>>>>> nothing.) Not super important, but it would be nice if at some
>>>>>>>>point
>>>>>>>> we can
>>>>>>>> figure out if there’s a way to strip out the calls completely.
>>>>>>>>
>>>>>>>>> On Jul 12, 2017, at 10:07 AM, Harbs <ha...@gmail.com>
>>>>>>>>>wrote:
>>>>>>>>>
>>>>>>>>> Oof. I think I’m still waking up. ;-)
>>>>>>>>>
>>>>>>>>> I did not realize what I was looking at with the goog.DEBUG. My
>>>>>>>> recollection is that trace statements are still being used in the
>>>>>>>> release,
>>>>>>>> but I’ll double check that.
>>>>>>>>>
>>>>>>>>>> On Jul 12, 2017, at 9:56 AM, Alex Harui
>>>>>>>>>><ah...@adobe.com.INVALID>
>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Well, the goal of using goog.DEBUG in Language.as trace() was to
>>>>>>>> convince
>>>>>>>>>> GCC to eliminate trace(). I haven't checked whether it is
>>>>>>>>>>working
>>>>>>>>>> or
>>>>>>>> not.
>>>>>>>>>> Requiring everyone to use goog.DEBUG around trace statements
>>>>>>>>>> sounds
>>>>>>>> like
>>>>>>>>>> a pain. Probably better to teach the publisher to remove it if
>>>>>>>>>> GCC
>>>>>>>> can't
>>>>>>>>>> be taught to do it. We visit almost every line of the JS output
>>>>>>>>>> in
>>>>>>>>>> the
>>>>>>>>>> publishers right now.
>>>>>>>>>>
>>>>>>>>>> My 2 cents,
>>>>>>>>>> -Alex
>>>>>>>>>>
>>>>>>>>>> On 7/11/17, 11:47 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On Jul 12, 2017, at 8:20 AM, Alex Harui
>>>>>>>>>>>> <ah...@adobe.com.INVALID>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Again, though, I think this optimization isn't urgent.
>>>>>>>>>>>
>>>>>>>>>>> I completely agree. That’s why I have not been bringing this up
>>>>>>>> despite
>>>>>>>>>>> it being on my mind. When the discussion came up, I couldn’t
>>>>>>>>>>>help
>>>>>>>>>>> but
>>>>>>>>>>> join. ;-)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> goog.DEBUG is already being used in Language.as.
>>>>>>>>>>>
>>>>>>>>>>> Thanks! I hadn’t noticed. I was missing an import of of
>>>>>>>>>>> goog.DEBUG
>>>>>>>>>>> in
>>>>>>>>>>> COMPILE::JS I’m guessing the imports of goog.bind and
>>>>>>>>>>>goog.global
>>>>>>>>>>> was
>>>>>>>>>>> enough to make goog.DEBUG visible to the compiler in
>>>>>>>>>>>Language.as.
>>>>>>>>>>>
>>>>>>>>>>> Once we’re on this topic, there’s something that I had wanted
>>>>>>>>>>>to
>>>>>>>> bring up
>>>>>>>>>>> for a long time: I think trace statements should disappear in
>>>>>>>>>>>the
>>>>>>>> release
>>>>>>>>>>> JS build. Should we put all the JS trace code inside an
>>>>>>>>>>> if(goog.DEBUG)
>>>>>>>>>>> block?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Harbs
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are
assumed to be POST
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I'm unable to gather from this thread what code is being generated and
what errors are being generated when it doesn't work.
-Alex
On 7/12/17, 12:39 PM, "Harbs" <ha...@gmail.com> wrote:
>I tried on a simpler project and the only thing being output is a trace
>declaration with an empty function:
>u('org.apache.flex.utils.Language.trace',m());
>
>All calls to trace() are stripped out by the google compiler.
>
>This looks to be the case even without modifying the Language.trace
>output.
>
>FWIW, This is with -remove-circulars. When I tried to compile without
>-remove-circulars it had all kinds of runtime errors including calls to
>non-existent trace functions. I don’t know hwy. The project is really
>simple, and I’d think -remove-circulars should not be required.
>
>I have no idea why my more complex project outputs trace differently…
>
>Harbs
>
>> On Jul 12, 2017, at 8:11 PM, Harbs <ha...@gmail.com> wrote:
>>
>> Maybe I’m doing something wrong, but I get the following error when I
>>tried using -skip-transpile:
>>
>> [java] java.lang.NullPointerException
>>org.apache.flex.compiler.internal.projects.FlexJSProject.computeTargetAtt
>>ributes(FlexJSProject.java:354)org.apache.flex.compiler.internal.codegen.
>>mxml.flexjs.MXMLFlexJSPublisher.writeTemplate(MXMLFlexJSPublisher.java:55
>>4)org.apache.flex.compiler.internal.codegen.mxml.flexjs.MXMLFlexJSPublish
>>er.publish(MXMLFlexJSPublisher.java:345)org.apache.flex.compiler.clients.
>>MXMLJSCFlex.compile(MXMLJSCFlex.java:387)org.apache.flex.compiler.clients
>>.MXMLJSCFlex._mainNoExit(MXMLJSCFlex.java:245)org.apache.flex.compiler.cl
>>ients.MXMLJSCFlex.mainNoExit(MXMLJSCFlex.java:202)org.apache.flex.compile
>>r.clients.MXMLJSC._mainNoExit(MXMLJSC.java:352)org.apache.flex.compiler.c
>>lients.MXMLJSC.mainNoExit(MXMLJSC.java:287)org.apache.flex.compiler.clien
>>ts.MXMLJSC.staticMainNoExit(MXMLJSC.java:247)org.apache.flex.compiler.cli
>>ents.MXMLJSC.main(MXMLJSC.java:229)
>> [java]
>> [java]
>> [java] Java Result: 3
>>
>>> On Jul 12, 2017, at 7:48 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>wrote:
>>>
>>> Trace supports multiple parameters and concatenates them with " "
>>> in-between.
>>>
>>> If you want to investigate more, you can use -sdk-js-lib to point to a
>>> hacked version of Language.js with goog.DEBUG around the "rest" code.
>>>
>>> I think you can also just modify what is in bin/js-debug and run the
>>> compiler with the -skip-transpile option and it won't re-transpile and
>>> just pass js-debug files to GCC and generate a new js-release output.
>>>
>>> -Alex
>>>
>>> On 7/12/17, 9:11 AM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>>> That line was what was left of the trace function.
>>>>
>>>> The reason the trace function is not completely empty is because it
>>>>has
>>>> this code generated from "…rest” at the start of the function:
>>>> rest = Array.prototype.slice.call(arguments, 0);
>>>>
>>>> I have no idea why that code is necessary. Maybe if it was not
>>>>generated
>>>> and the function was truly empty, the trace calls would be stripped
>>>>out
>>>> as well?
>>>>
>>>> Leftover trace calls elsewhere in the code look something like this:
>>>> uM('unexpected condition in deferredBindingsHandler’);
>>>>
>>>>> On Jul 12, 2017, at 6:08 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>>> wrote:
>>>>>
>>>>> If it were up to me, we'd strip traces based on the optimize compiler
>>>>> option. I think that's how it worked in the Flex SDK.
>>>>>
>>>>> I thought GCC had enough dead-code-removal logic to remove
>>>>> Language.trace
>>>>> once it saw that trace effectively did nothing.
>>>>>
>>>>> I can't seem to piece together from this thread what the original AS
>>>>>was
>>>>> and what the un-minified JS output was. Maybe there's something
>>>>>about
>>>>> the
>>>>> JS output that isn't right. It is strange to see the string name of
>>>>>the
>>>>> trace function.
>>>>>
>>>>> Regarding a logging system, I think folks are just used to trace and
>>>>>the
>>>>> cool thing about JS right now is that you can replace functions at
>>>>> runtime, so a logging bead would just replace Language.trace().
>>>>>
>>>>> -Alex
>>>>>
>>>>> On 7/12/17, 6:44 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>
>>>>>> Interesting scenarios. I would not have thought of that.
>>>>>>
>>>>>> If we could figure out how to strip the function call and leave the
>>>>>> parameter, the compiler would strip out the contents if it could be
>>>>>> safely removed.
>>>>>>
>>>>>> So trace(“something”) would become “something” which is en empty
>>>>>> statement and would be stripped out.
>>>>>>
>>>>>> Of course, I have no idea how to go about doing that… ;-)
>>>>>>
>>>>>> Harbs
>>>>>>
>>>>>>> On Jul 12, 2017, at 4:32 PM, Josh Tynjala <jo...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Probably the same with function calls too:
>>>>>>>
>>>>>>> trace(someFunction());
>>>>>>>
>>>>>>> They wanted this to remain:
>>>>>>>
>>>>>>> someFunction();
>>>>>>>
>>>>>>> - Josh
>>>>>>>
>>>>>>> On Wed, Jul 12, 2017 at 6:22 AM, Josh Tynjala
>>>>>>><jo...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> One thing to keep in mind with stripping out trace() calls is that
>>>>>>>> some
>>>>>>>> developers expect any modifications to variables that happen
>>>>>>>>inside
>>>>>>>> the
>>>>>>>> arguments to remain. I remember a while back someone at Adobe
>>>>>>>> mentioning
>>>>>>>> that people complained when something like this was completely
>>>>>>>> stripped out:
>>>>>>>>
>>>>>>>> trace(doSomething++);
>>>>>>>>
>>>>>>>> Because they expected this part to remain:
>>>>>>>>
>>>>>>>> doSomething++;
>>>>>>>>
>>>>>>>> - Josh
>>>>>>>>
>>>>>>>> On Wed, Jul 12, 2017 at 12:24 AM, Harbs <ha...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> My bad. It does in fact compile down to this:
>>>>>>>>>
>>>>>>>>> function
>>>>>>>>> uM(a){a=Array.prototype.slice.call(arguments,0)}w('org.apach
>>>>>>>>> e.flex.utils.Language.trace',uM);
>>>>>>>>>
>>>>>>>>> So trace does not actually do anything. Great! :-)
>>>>>>>>>
>>>>>>>>> However, it’s still being called by the client code. (It just
>>>>>>>>>does
>>>>>>>>> nothing.) Not super important, but it would be nice if at some
>>>>>>>>>point
>>>>>>>>> we can
>>>>>>>>> figure out if there’s a way to strip out the calls completely.
>>>>>>>>>
>>>>>>>>>> On Jul 12, 2017, at 10:07 AM, Harbs <ha...@gmail.com>
>>>>>>>>>>wrote:
>>>>>>>>>>
>>>>>>>>>> Oof. I think I’m still waking up. ;-)
>>>>>>>>>>
>>>>>>>>>> I did not realize what I was looking at with the goog.DEBUG. My
>>>>>>>>> recollection is that trace statements are still being used in the
>>>>>>>>> release,
>>>>>>>>> but I’ll double check that.
>>>>>>>>>>
>>>>>>>>>>> On Jul 12, 2017, at 9:56 AM, Alex Harui
>>>>>>>>>>><ah...@adobe.com.INVALID>
>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Well, the goal of using goog.DEBUG in Language.as trace() was
>>>>>>>>>>>to
>>>>>>>>> convince
>>>>>>>>>>> GCC to eliminate trace(). I haven't checked whether it is
>>>>>>>>>>>working
>>>>>>>>>>> or
>>>>>>>>> not.
>>>>>>>>>>> Requiring everyone to use goog.DEBUG around trace statements
>>>>>>>>>>> sounds
>>>>>>>>> like
>>>>>>>>>>> a pain. Probably better to teach the publisher to remove it if
>>>>>>>>>>> GCC
>>>>>>>>> can't
>>>>>>>>>>> be taught to do it. We visit almost every line of the JS
>>>>>>>>>>>output
>>>>>>>>>>> in
>>>>>>>>>>> the
>>>>>>>>>>> publishers right now.
>>>>>>>>>>>
>>>>>>>>>>> My 2 cents,
>>>>>>>>>>> -Alex
>>>>>>>>>>>
>>>>>>>>>>> On 7/11/17, 11:47 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> On Jul 12, 2017, at 8:20 AM, Alex Harui
>>>>>>>>>>>>> <ah...@adobe.com.INVALID>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Again, though, I think this optimization isn't urgent.
>>>>>>>>>>>>
>>>>>>>>>>>> I completely agree. That’s why I have not been bringing this
>>>>>>>>>>>>up
>>>>>>>>> despite
>>>>>>>>>>>> it being on my mind. When the discussion came up, I couldn’t
>>>>>>>>>>>>help
>>>>>>>>>>>> but
>>>>>>>>>>>> join. ;-)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> goog.DEBUG is already being used in Language.as.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks! I hadn’t noticed. I was missing an import of of
>>>>>>>>>>>> goog.DEBUG
>>>>>>>>>>>> in
>>>>>>>>>>>> COMPILE::JS I’m guessing the imports of goog.bind and
>>>>>>>>>>>>goog.global
>>>>>>>>>>>> was
>>>>>>>>>>>> enough to make goog.DEBUG visible to the compiler in
>>>>>>>>>>>>Language.as.
>>>>>>>>>>>>
>>>>>>>>>>>> Once we’re on this topic, there’s something that I had wanted
>>>>>>>>>>>>to
>>>>>>>>> bring up
>>>>>>>>>>>> for a long time: I think trace statements should disappear in
>>>>>>>>>>>>the
>>>>>>>>> release
>>>>>>>>>>>> JS build. Should we put all the JS trace code inside an
>>>>>>>>>>>> if(goog.DEBUG)
>>>>>>>>>>>> block?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Harbs
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST
Posted by Harbs <ha...@gmail.com>.
I tried on a simpler project and the only thing being output is a trace declaration with an empty function:
u('org.apache.flex.utils.Language.trace',m());
All calls to trace() are stripped out by the google compiler.
This looks to be the case even without modifying the Language.trace output.
FWIW, This is with -remove-circulars. When I tried to compile without -remove-circulars it had all kinds of runtime errors including calls to non-existent trace functions. I don’t know hwy. The project is really simple, and I’d think -remove-circulars should not be required.
I have no idea why my more complex project outputs trace differently…
Harbs
> On Jul 12, 2017, at 8:11 PM, Harbs <ha...@gmail.com> wrote:
>
> Maybe I’m doing something wrong, but I get the following error when I tried using -skip-transpile:
>
> [java] java.lang.NullPointerException org.apache.flex.compiler.internal.projects.FlexJSProject.computeTargetAttributes(FlexJSProject.java:354)org.apache.flex.compiler.internal.codegen.mxml.flexjs.MXMLFlexJSPublisher.writeTemplate(MXMLFlexJSPublisher.java:554)org.apache.flex.compiler.internal.codegen.mxml.flexjs.MXMLFlexJSPublisher.publish(MXMLFlexJSPublisher.java:345)org.apache.flex.compiler.clients.MXMLJSCFlex.compile(MXMLJSCFlex.java:387)org.apache.flex.compiler.clients.MXMLJSCFlex._mainNoExit(MXMLJSCFlex.java:245)org.apache.flex.compiler.clients.MXMLJSCFlex.mainNoExit(MXMLJSCFlex.java:202)org.apache.flex.compiler.clients.MXMLJSC._mainNoExit(MXMLJSC.java:352)org.apache.flex.compiler.clients.MXMLJSC.mainNoExit(MXMLJSC.java:287)org.apache.flex.compiler.clients.MXMLJSC.staticMainNoExit(MXMLJSC.java:247)org.apache.flex.compiler.clients.MXMLJSC.main(MXMLJSC.java:229)
> [java]
> [java]
> [java] Java Result: 3
>
>> On Jul 12, 2017, at 7:48 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> Trace supports multiple parameters and concatenates them with " "
>> in-between.
>>
>> If you want to investigate more, you can use -sdk-js-lib to point to a
>> hacked version of Language.js with goog.DEBUG around the "rest" code.
>>
>> I think you can also just modify what is in bin/js-debug and run the
>> compiler with the -skip-transpile option and it won't re-transpile and
>> just pass js-debug files to GCC and generate a new js-release output.
>>
>> -Alex
>>
>> On 7/12/17, 9:11 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>>> That line was what was left of the trace function.
>>>
>>> The reason the trace function is not completely empty is because it has
>>> this code generated from "…rest” at the start of the function:
>>> rest = Array.prototype.slice.call(arguments, 0);
>>>
>>> I have no idea why that code is necessary. Maybe if it was not generated
>>> and the function was truly empty, the trace calls would be stripped out
>>> as well?
>>>
>>> Leftover trace calls elsewhere in the code look something like this:
>>> uM('unexpected condition in deferredBindingsHandler’);
>>>
>>>> On Jul 12, 2017, at 6:08 PM, Alex Harui <ah...@adobe.com.INVALID>
>>>> wrote:
>>>>
>>>> If it were up to me, we'd strip traces based on the optimize compiler
>>>> option. I think that's how it worked in the Flex SDK.
>>>>
>>>> I thought GCC had enough dead-code-removal logic to remove
>>>> Language.trace
>>>> once it saw that trace effectively did nothing.
>>>>
>>>> I can't seem to piece together from this thread what the original AS was
>>>> and what the un-minified JS output was. Maybe there's something about
>>>> the
>>>> JS output that isn't right. It is strange to see the string name of the
>>>> trace function.
>>>>
>>>> Regarding a logging system, I think folks are just used to trace and the
>>>> cool thing about JS right now is that you can replace functions at
>>>> runtime, so a logging bead would just replace Language.trace().
>>>>
>>>> -Alex
>>>>
>>>> On 7/12/17, 6:44 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>
>>>>> Interesting scenarios. I would not have thought of that.
>>>>>
>>>>> If we could figure out how to strip the function call and leave the
>>>>> parameter, the compiler would strip out the contents if it could be
>>>>> safely removed.
>>>>>
>>>>> So trace(“something”) would become “something” which is en empty
>>>>> statement and would be stripped out.
>>>>>
>>>>> Of course, I have no idea how to go about doing that… ;-)
>>>>>
>>>>> Harbs
>>>>>
>>>>>> On Jul 12, 2017, at 4:32 PM, Josh Tynjala <jo...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Probably the same with function calls too:
>>>>>>
>>>>>> trace(someFunction());
>>>>>>
>>>>>> They wanted this to remain:
>>>>>>
>>>>>> someFunction();
>>>>>>
>>>>>> - Josh
>>>>>>
>>>>>> On Wed, Jul 12, 2017 at 6:22 AM, Josh Tynjala <jo...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> One thing to keep in mind with stripping out trace() calls is that
>>>>>>> some
>>>>>>> developers expect any modifications to variables that happen inside
>>>>>>> the
>>>>>>> arguments to remain. I remember a while back someone at Adobe
>>>>>>> mentioning
>>>>>>> that people complained when something like this was completely
>>>>>>> stripped out:
>>>>>>>
>>>>>>> trace(doSomething++);
>>>>>>>
>>>>>>> Because they expected this part to remain:
>>>>>>>
>>>>>>> doSomething++;
>>>>>>>
>>>>>>> - Josh
>>>>>>>
>>>>>>> On Wed, Jul 12, 2017 at 12:24 AM, Harbs <ha...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> My bad. It does in fact compile down to this:
>>>>>>>>
>>>>>>>> function
>>>>>>>> uM(a){a=Array.prototype.slice.call(arguments,0)}w('org.apach
>>>>>>>> e.flex.utils.Language.trace',uM);
>>>>>>>>
>>>>>>>> So trace does not actually do anything. Great! :-)
>>>>>>>>
>>>>>>>> However, it’s still being called by the client code. (It just does
>>>>>>>> nothing.) Not super important, but it would be nice if at some point
>>>>>>>> we can
>>>>>>>> figure out if there’s a way to strip out the calls completely.
>>>>>>>>
>>>>>>>>> On Jul 12, 2017, at 10:07 AM, Harbs <ha...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> Oof. I think I’m still waking up. ;-)
>>>>>>>>>
>>>>>>>>> I did not realize what I was looking at with the goog.DEBUG. My
>>>>>>>> recollection is that trace statements are still being used in the
>>>>>>>> release,
>>>>>>>> but I’ll double check that.
>>>>>>>>>
>>>>>>>>>> On Jul 12, 2017, at 9:56 AM, Alex Harui <ah...@adobe.com.INVALID>
>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Well, the goal of using goog.DEBUG in Language.as trace() was to
>>>>>>>> convince
>>>>>>>>>> GCC to eliminate trace(). I haven't checked whether it is working
>>>>>>>>>> or
>>>>>>>> not.
>>>>>>>>>> Requiring everyone to use goog.DEBUG around trace statements
>>>>>>>>>> sounds
>>>>>>>> like
>>>>>>>>>> a pain. Probably better to teach the publisher to remove it if
>>>>>>>>>> GCC
>>>>>>>> can't
>>>>>>>>>> be taught to do it. We visit almost every line of the JS output
>>>>>>>>>> in
>>>>>>>>>> the
>>>>>>>>>> publishers right now.
>>>>>>>>>>
>>>>>>>>>> My 2 cents,
>>>>>>>>>> -Alex
>>>>>>>>>>
>>>>>>>>>> On 7/11/17, 11:47 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On Jul 12, 2017, at 8:20 AM, Alex Harui
>>>>>>>>>>>> <ah...@adobe.com.INVALID>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Again, though, I think this optimization isn't urgent.
>>>>>>>>>>>
>>>>>>>>>>> I completely agree. That’s why I have not been bringing this up
>>>>>>>> despite
>>>>>>>>>>> it being on my mind. When the discussion came up, I couldn’t help
>>>>>>>>>>> but
>>>>>>>>>>> join. ;-)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> goog.DEBUG is already being used in Language.as.
>>>>>>>>>>>
>>>>>>>>>>> Thanks! I hadn’t noticed. I was missing an import of of
>>>>>>>>>>> goog.DEBUG
>>>>>>>>>>> in
>>>>>>>>>>> COMPILE::JS I’m guessing the imports of goog.bind and goog.global
>>>>>>>>>>> was
>>>>>>>>>>> enough to make goog.DEBUG visible to the compiler in Language.as.
>>>>>>>>>>>
>>>>>>>>>>> Once we’re on this topic, there’s something that I had wanted to
>>>>>>>> bring up
>>>>>>>>>>> for a long time: I think trace statements should disappear in the
>>>>>>>> release
>>>>>>>>>>> JS build. Should we put all the JS trace code inside an
>>>>>>>>>>> if(goog.DEBUG)
>>>>>>>>>>> block?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Harbs
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST
Posted by Harbs <ha...@gmail.com>.
Maybe I’m doing something wrong, but I get the following error when I tried using -skip-transpile:
[java] java.lang.NullPointerException org.apache.flex.compiler.internal.projects.FlexJSProject.computeTargetAttributes(FlexJSProject.java:354)org.apache.flex.compiler.internal.codegen.mxml.flexjs.MXMLFlexJSPublisher.writeTemplate(MXMLFlexJSPublisher.java:554)org.apache.flex.compiler.internal.codegen.mxml.flexjs.MXMLFlexJSPublisher.publish(MXMLFlexJSPublisher.java:345)org.apache.flex.compiler.clients.MXMLJSCFlex.compile(MXMLJSCFlex.java:387)org.apache.flex.compiler.clients.MXMLJSCFlex._mainNoExit(MXMLJSCFlex.java:245)org.apache.flex.compiler.clients.MXMLJSCFlex.mainNoExit(MXMLJSCFlex.java:202)org.apache.flex.compiler.clients.MXMLJSC._mainNoExit(MXMLJSC.java:352)org.apache.flex.compiler.clients.MXMLJSC.mainNoExit(MXMLJSC.java:287)org.apache.flex.compiler.clients.MXMLJSC.staticMainNoExit(MXMLJSC.java:247)org.apache.flex.compiler.clients.MXMLJSC.main(MXMLJSC.java:229)
[java]
[java]
[java] Java Result: 3
> On Jul 12, 2017, at 7:48 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Trace supports multiple parameters and concatenates them with " "
> in-between.
>
> If you want to investigate more, you can use -sdk-js-lib to point to a
> hacked version of Language.js with goog.DEBUG around the "rest" code.
>
> I think you can also just modify what is in bin/js-debug and run the
> compiler with the -skip-transpile option and it won't re-transpile and
> just pass js-debug files to GCC and generate a new js-release output.
>
> -Alex
>
> On 7/12/17, 9:11 AM, "Harbs" <ha...@gmail.com> wrote:
>
>> That line was what was left of the trace function.
>>
>> The reason the trace function is not completely empty is because it has
>> this code generated from "…rest” at the start of the function:
>> rest = Array.prototype.slice.call(arguments, 0);
>>
>> I have no idea why that code is necessary. Maybe if it was not generated
>> and the function was truly empty, the trace calls would be stripped out
>> as well?
>>
>> Leftover trace calls elsewhere in the code look something like this:
>> uM('unexpected condition in deferredBindingsHandler’);
>>
>>> On Jul 12, 2017, at 6:08 PM, Alex Harui <ah...@adobe.com.INVALID>
>>> wrote:
>>>
>>> If it were up to me, we'd strip traces based on the optimize compiler
>>> option. I think that's how it worked in the Flex SDK.
>>>
>>> I thought GCC had enough dead-code-removal logic to remove
>>> Language.trace
>>> once it saw that trace effectively did nothing.
>>>
>>> I can't seem to piece together from this thread what the original AS was
>>> and what the un-minified JS output was. Maybe there's something about
>>> the
>>> JS output that isn't right. It is strange to see the string name of the
>>> trace function.
>>>
>>> Regarding a logging system, I think folks are just used to trace and the
>>> cool thing about JS right now is that you can replace functions at
>>> runtime, so a logging bead would just replace Language.trace().
>>>
>>> -Alex
>>>
>>> On 7/12/17, 6:44 AM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>>> Interesting scenarios. I would not have thought of that.
>>>>
>>>> If we could figure out how to strip the function call and leave the
>>>> parameter, the compiler would strip out the contents if it could be
>>>> safely removed.
>>>>
>>>> So trace(“something”) would become “something” which is en empty
>>>> statement and would be stripped out.
>>>>
>>>> Of course, I have no idea how to go about doing that… ;-)
>>>>
>>>> Harbs
>>>>
>>>>> On Jul 12, 2017, at 4:32 PM, Josh Tynjala <jo...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Probably the same with function calls too:
>>>>>
>>>>> trace(someFunction());
>>>>>
>>>>> They wanted this to remain:
>>>>>
>>>>> someFunction();
>>>>>
>>>>> - Josh
>>>>>
>>>>> On Wed, Jul 12, 2017 at 6:22 AM, Josh Tynjala <jo...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> One thing to keep in mind with stripping out trace() calls is that
>>>>>> some
>>>>>> developers expect any modifications to variables that happen inside
>>>>>> the
>>>>>> arguments to remain. I remember a while back someone at Adobe
>>>>>> mentioning
>>>>>> that people complained when something like this was completely
>>>>>> stripped out:
>>>>>>
>>>>>> trace(doSomething++);
>>>>>>
>>>>>> Because they expected this part to remain:
>>>>>>
>>>>>> doSomething++;
>>>>>>
>>>>>> - Josh
>>>>>>
>>>>>> On Wed, Jul 12, 2017 at 12:24 AM, Harbs <ha...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> My bad. It does in fact compile down to this:
>>>>>>>
>>>>>>> function
>>>>>>> uM(a){a=Array.prototype.slice.call(arguments,0)}w('org.apach
>>>>>>> e.flex.utils.Language.trace',uM);
>>>>>>>
>>>>>>> So trace does not actually do anything. Great! :-)
>>>>>>>
>>>>>>> However, it’s still being called by the client code. (It just does
>>>>>>> nothing.) Not super important, but it would be nice if at some point
>>>>>>> we can
>>>>>>> figure out if there’s a way to strip out the calls completely.
>>>>>>>
>>>>>>>> On Jul 12, 2017, at 10:07 AM, Harbs <ha...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Oof. I think I’m still waking up. ;-)
>>>>>>>>
>>>>>>>> I did not realize what I was looking at with the goog.DEBUG. My
>>>>>>> recollection is that trace statements are still being used in the
>>>>>>> release,
>>>>>>> but I’ll double check that.
>>>>>>>>
>>>>>>>>> On Jul 12, 2017, at 9:56 AM, Alex Harui <ah...@adobe.com.INVALID>
>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Well, the goal of using goog.DEBUG in Language.as trace() was to
>>>>>>> convince
>>>>>>>>> GCC to eliminate trace(). I haven't checked whether it is working
>>>>>>>>> or
>>>>>>> not.
>>>>>>>>> Requiring everyone to use goog.DEBUG around trace statements
>>>>>>>>> sounds
>>>>>>> like
>>>>>>>>> a pain. Probably better to teach the publisher to remove it if
>>>>>>>>> GCC
>>>>>>> can't
>>>>>>>>> be taught to do it. We visit almost every line of the JS output
>>>>>>>>> in
>>>>>>>>> the
>>>>>>>>> publishers right now.
>>>>>>>>>
>>>>>>>>> My 2 cents,
>>>>>>>>> -Alex
>>>>>>>>>
>>>>>>>>> On 7/11/17, 11:47 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Jul 12, 2017, at 8:20 AM, Alex Harui
>>>>>>>>>>> <ah...@adobe.com.INVALID>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Again, though, I think this optimization isn't urgent.
>>>>>>>>>>
>>>>>>>>>> I completely agree. That’s why I have not been bringing this up
>>>>>>> despite
>>>>>>>>>> it being on my mind. When the discussion came up, I couldn’t help
>>>>>>>>>> but
>>>>>>>>>> join. ;-)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> goog.DEBUG is already being used in Language.as.
>>>>>>>>>>
>>>>>>>>>> Thanks! I hadn’t noticed. I was missing an import of of
>>>>>>>>>> goog.DEBUG
>>>>>>>>>> in
>>>>>>>>>> COMPILE::JS I’m guessing the imports of goog.bind and goog.global
>>>>>>>>>> was
>>>>>>>>>> enough to make goog.DEBUG visible to the compiler in Language.as.
>>>>>>>>>>
>>>>>>>>>> Once we’re on this topic, there’s something that I had wanted to
>>>>>>> bring up
>>>>>>>>>> for a long time: I think trace statements should disappear in the
>>>>>>> release
>>>>>>>>>> JS build. Should we put all the JS trace code inside an
>>>>>>>>>> if(goog.DEBUG)
>>>>>>>>>> block?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Harbs
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are
assumed to be POST
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Trace supports multiple parameters and concatenates them with " "
in-between.
If you want to investigate more, you can use -sdk-js-lib to point to a
hacked version of Language.js with goog.DEBUG around the "rest" code.
I think you can also just modify what is in bin/js-debug and run the
compiler with the -skip-transpile option and it won't re-transpile and
just pass js-debug files to GCC and generate a new js-release output.
-Alex
On 7/12/17, 9:11 AM, "Harbs" <ha...@gmail.com> wrote:
>That line was what was left of the trace function.
>
>The reason the trace function is not completely empty is because it has
>this code generated from "…rest” at the start of the function:
>rest = Array.prototype.slice.call(arguments, 0);
>
>I have no idea why that code is necessary. Maybe if it was not generated
>and the function was truly empty, the trace calls would be stripped out
>as well?
>
>Leftover trace calls elsewhere in the code look something like this:
>uM('unexpected condition in deferredBindingsHandler’);
>
>> On Jul 12, 2017, at 6:08 PM, Alex Harui <ah...@adobe.com.INVALID>
>>wrote:
>>
>> If it were up to me, we'd strip traces based on the optimize compiler
>> option. I think that's how it worked in the Flex SDK.
>>
>> I thought GCC had enough dead-code-removal logic to remove
>>Language.trace
>> once it saw that trace effectively did nothing.
>>
>> I can't seem to piece together from this thread what the original AS was
>> and what the un-minified JS output was. Maybe there's something about
>>the
>> JS output that isn't right. It is strange to see the string name of the
>> trace function.
>>
>> Regarding a logging system, I think folks are just used to trace and the
>> cool thing about JS right now is that you can replace functions at
>> runtime, so a logging bead would just replace Language.trace().
>>
>> -Alex
>>
>> On 7/12/17, 6:44 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>>> Interesting scenarios. I would not have thought of that.
>>>
>>> If we could figure out how to strip the function call and leave the
>>> parameter, the compiler would strip out the contents if it could be
>>> safely removed.
>>>
>>> So trace(“something”) would become “something” which is en empty
>>> statement and would be stripped out.
>>>
>>> Of course, I have no idea how to go about doing that… ;-)
>>>
>>> Harbs
>>>
>>>> On Jul 12, 2017, at 4:32 PM, Josh Tynjala <jo...@gmail.com>
>>>>wrote:
>>>>
>>>> Probably the same with function calls too:
>>>>
>>>> trace(someFunction());
>>>>
>>>> They wanted this to remain:
>>>>
>>>> someFunction();
>>>>
>>>> - Josh
>>>>
>>>> On Wed, Jul 12, 2017 at 6:22 AM, Josh Tynjala <jo...@gmail.com>
>>>> wrote:
>>>>
>>>>> One thing to keep in mind with stripping out trace() calls is that
>>>>>some
>>>>> developers expect any modifications to variables that happen inside
>>>>>the
>>>>> arguments to remain. I remember a while back someone at Adobe
>>>>> mentioning
>>>>> that people complained when something like this was completely
>>>>> stripped out:
>>>>>
>>>>> trace(doSomething++);
>>>>>
>>>>> Because they expected this part to remain:
>>>>>
>>>>> doSomething++;
>>>>>
>>>>> - Josh
>>>>>
>>>>> On Wed, Jul 12, 2017 at 12:24 AM, Harbs <ha...@gmail.com>
>>>>>wrote:
>>>>>
>>>>>> My bad. It does in fact compile down to this:
>>>>>>
>>>>>> function
>>>>>>uM(a){a=Array.prototype.slice.call(arguments,0)}w('org.apach
>>>>>> e.flex.utils.Language.trace',uM);
>>>>>>
>>>>>> So trace does not actually do anything. Great! :-)
>>>>>>
>>>>>> However, it’s still being called by the client code. (It just does
>>>>>> nothing.) Not super important, but it would be nice if at some point
>>>>>> we can
>>>>>> figure out if there’s a way to strip out the calls completely.
>>>>>>
>>>>>>> On Jul 12, 2017, at 10:07 AM, Harbs <ha...@gmail.com> wrote:
>>>>>>>
>>>>>>> Oof. I think I’m still waking up. ;-)
>>>>>>>
>>>>>>> I did not realize what I was looking at with the goog.DEBUG. My
>>>>>> recollection is that trace statements are still being used in the
>>>>>> release,
>>>>>> but I’ll double check that.
>>>>>>>
>>>>>>>> On Jul 12, 2017, at 9:56 AM, Alex Harui <ah...@adobe.com.INVALID>
>>>>>> wrote:
>>>>>>>>
>>>>>>>> Well, the goal of using goog.DEBUG in Language.as trace() was to
>>>>>> convince
>>>>>>>> GCC to eliminate trace(). I haven't checked whether it is working
>>>>>>>> or
>>>>>> not.
>>>>>>>> Requiring everyone to use goog.DEBUG around trace statements
>>>>>>>>sounds
>>>>>> like
>>>>>>>> a pain. Probably better to teach the publisher to remove it if
>>>>>>>>GCC
>>>>>> can't
>>>>>>>> be taught to do it. We visit almost every line of the JS output
>>>>>>>>in
>>>>>>>> the
>>>>>>>> publishers right now.
>>>>>>>>
>>>>>>>> My 2 cents,
>>>>>>>> -Alex
>>>>>>>>
>>>>>>>> On 7/11/17, 11:47 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Jul 12, 2017, at 8:20 AM, Alex Harui
>>>>>>>>>><ah...@adobe.com.INVALID>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Again, though, I think this optimization isn't urgent.
>>>>>>>>>
>>>>>>>>> I completely agree. That’s why I have not been bringing this up
>>>>>> despite
>>>>>>>>> it being on my mind. When the discussion came up, I couldn’t help
>>>>>>>>> but
>>>>>>>>> join. ;-)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> goog.DEBUG is already being used in Language.as.
>>>>>>>>>
>>>>>>>>> Thanks! I hadn’t noticed. I was missing an import of of
>>>>>>>>>goog.DEBUG
>>>>>>>>> in
>>>>>>>>> COMPILE::JS I’m guessing the imports of goog.bind and goog.global
>>>>>>>>> was
>>>>>>>>> enough to make goog.DEBUG visible to the compiler in Language.as.
>>>>>>>>>
>>>>>>>>> Once we’re on this topic, there’s something that I had wanted to
>>>>>> bring up
>>>>>>>>> for a long time: I think trace statements should disappear in the
>>>>>> release
>>>>>>>>> JS build. Should we put all the JS trace code inside an
>>>>>>>>> if(goog.DEBUG)
>>>>>>>>> block?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Harbs
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>
>
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST
Posted by Harbs <ha...@gmail.com>.
That line was what was left of the trace function.
The reason the trace function is not completely empty is because it has this code generated from "…rest” at the start of the function:
rest = Array.prototype.slice.call(arguments, 0);
I have no idea why that code is necessary. Maybe if it was not generated and the function was truly empty, the trace calls would be stripped out as well?
Leftover trace calls elsewhere in the code look something like this:
uM('unexpected condition in deferredBindingsHandler’);
> On Jul 12, 2017, at 6:08 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> If it were up to me, we'd strip traces based on the optimize compiler
> option. I think that's how it worked in the Flex SDK.
>
> I thought GCC had enough dead-code-removal logic to remove Language.trace
> once it saw that trace effectively did nothing.
>
> I can't seem to piece together from this thread what the original AS was
> and what the un-minified JS output was. Maybe there's something about the
> JS output that isn't right. It is strange to see the string name of the
> trace function.
>
> Regarding a logging system, I think folks are just used to trace and the
> cool thing about JS right now is that you can replace functions at
> runtime, so a logging bead would just replace Language.trace().
>
> -Alex
>
> On 7/12/17, 6:44 AM, "Harbs" <ha...@gmail.com> wrote:
>
>> Interesting scenarios. I would not have thought of that.
>>
>> If we could figure out how to strip the function call and leave the
>> parameter, the compiler would strip out the contents if it could be
>> safely removed.
>>
>> So trace(“something”) would become “something” which is en empty
>> statement and would be stripped out.
>>
>> Of course, I have no idea how to go about doing that… ;-)
>>
>> Harbs
>>
>>> On Jul 12, 2017, at 4:32 PM, Josh Tynjala <jo...@gmail.com> wrote:
>>>
>>> Probably the same with function calls too:
>>>
>>> trace(someFunction());
>>>
>>> They wanted this to remain:
>>>
>>> someFunction();
>>>
>>> - Josh
>>>
>>> On Wed, Jul 12, 2017 at 6:22 AM, Josh Tynjala <jo...@gmail.com>
>>> wrote:
>>>
>>>> One thing to keep in mind with stripping out trace() calls is that some
>>>> developers expect any modifications to variables that happen inside the
>>>> arguments to remain. I remember a while back someone at Adobe
>>>> mentioning
>>>> that people complained when something like this was completely
>>>> stripped out:
>>>>
>>>> trace(doSomething++);
>>>>
>>>> Because they expected this part to remain:
>>>>
>>>> doSomething++;
>>>>
>>>> - Josh
>>>>
>>>> On Wed, Jul 12, 2017 at 12:24 AM, Harbs <ha...@gmail.com> wrote:
>>>>
>>>>> My bad. It does in fact compile down to this:
>>>>>
>>>>> function uM(a){a=Array.prototype.slice.call(arguments,0)}w('org.apach
>>>>> e.flex.utils.Language.trace',uM);
>>>>>
>>>>> So trace does not actually do anything. Great! :-)
>>>>>
>>>>> However, it’s still being called by the client code. (It just does
>>>>> nothing.) Not super important, but it would be nice if at some point
>>>>> we can
>>>>> figure out if there’s a way to strip out the calls completely.
>>>>>
>>>>>> On Jul 12, 2017, at 10:07 AM, Harbs <ha...@gmail.com> wrote:
>>>>>>
>>>>>> Oof. I think I’m still waking up. ;-)
>>>>>>
>>>>>> I did not realize what I was looking at with the goog.DEBUG. My
>>>>> recollection is that trace statements are still being used in the
>>>>> release,
>>>>> but I’ll double check that.
>>>>>>
>>>>>>> On Jul 12, 2017, at 9:56 AM, Alex Harui <ah...@adobe.com.INVALID>
>>>>> wrote:
>>>>>>>
>>>>>>> Well, the goal of using goog.DEBUG in Language.as trace() was to
>>>>> convince
>>>>>>> GCC to eliminate trace(). I haven't checked whether it is working
>>>>>>> or
>>>>> not.
>>>>>>> Requiring everyone to use goog.DEBUG around trace statements sounds
>>>>> like
>>>>>>> a pain. Probably better to teach the publisher to remove it if GCC
>>>>> can't
>>>>>>> be taught to do it. We visit almost every line of the JS output in
>>>>>>> the
>>>>>>> publishers right now.
>>>>>>>
>>>>>>> My 2 cents,
>>>>>>> -Alex
>>>>>>>
>>>>>>> On 7/11/17, 11:47 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>> On Jul 12, 2017, at 8:20 AM, Alex Harui <ah...@adobe.com.INVALID>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Again, though, I think this optimization isn't urgent.
>>>>>>>>
>>>>>>>> I completely agree. That’s why I have not been bringing this up
>>>>> despite
>>>>>>>> it being on my mind. When the discussion came up, I couldn’t help
>>>>>>>> but
>>>>>>>> join. ;-)
>>>>>>>>
>>>>>>>>
>>>>>>>>> goog.DEBUG is already being used in Language.as.
>>>>>>>>
>>>>>>>> Thanks! I hadn’t noticed. I was missing an import of of goog.DEBUG
>>>>>>>> in
>>>>>>>> COMPILE::JS I’m guessing the imports of goog.bind and goog.global
>>>>>>>> was
>>>>>>>> enough to make goog.DEBUG visible to the compiler in Language.as.
>>>>>>>>
>>>>>>>> Once we’re on this topic, there’s something that I had wanted to
>>>>> bring up
>>>>>>>> for a long time: I think trace statements should disappear in the
>>>>> release
>>>>>>>> JS build. Should we put all the JS trace code inside an
>>>>>>>> if(goog.DEBUG)
>>>>>>>> block?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Harbs
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>
>
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are
assumed to be POST
Posted by Alex Harui <ah...@adobe.com.INVALID>.
If it were up to me, we'd strip traces based on the optimize compiler
option. I think that's how it worked in the Flex SDK.
I thought GCC had enough dead-code-removal logic to remove Language.trace
once it saw that trace effectively did nothing.
I can't seem to piece together from this thread what the original AS was
and what the un-minified JS output was. Maybe there's something about the
JS output that isn't right. It is strange to see the string name of the
trace function.
Regarding a logging system, I think folks are just used to trace and the
cool thing about JS right now is that you can replace functions at
runtime, so a logging bead would just replace Language.trace().
-Alex
On 7/12/17, 6:44 AM, "Harbs" <ha...@gmail.com> wrote:
>Interesting scenarios. I would not have thought of that.
>
>If we could figure out how to strip the function call and leave the
>parameter, the compiler would strip out the contents if it could be
>safely removed.
>
>So trace(“something”) would become “something” which is en empty
>statement and would be stripped out.
>
>Of course, I have no idea how to go about doing that… ;-)
>
>Harbs
>
>> On Jul 12, 2017, at 4:32 PM, Josh Tynjala <jo...@gmail.com> wrote:
>>
>> Probably the same with function calls too:
>>
>> trace(someFunction());
>>
>> They wanted this to remain:
>>
>> someFunction();
>>
>> - Josh
>>
>> On Wed, Jul 12, 2017 at 6:22 AM, Josh Tynjala <jo...@gmail.com>
>>wrote:
>>
>>> One thing to keep in mind with stripping out trace() calls is that some
>>> developers expect any modifications to variables that happen inside the
>>> arguments to remain. I remember a while back someone at Adobe
>>>mentioning
>>> that people complained when something like this was completely
>>>stripped out:
>>>
>>> trace(doSomething++);
>>>
>>> Because they expected this part to remain:
>>>
>>> doSomething++;
>>>
>>> - Josh
>>>
>>> On Wed, Jul 12, 2017 at 12:24 AM, Harbs <ha...@gmail.com> wrote:
>>>
>>>> My bad. It does in fact compile down to this:
>>>>
>>>> function uM(a){a=Array.prototype.slice.call(arguments,0)}w('org.apach
>>>> e.flex.utils.Language.trace',uM);
>>>>
>>>> So trace does not actually do anything. Great! :-)
>>>>
>>>> However, it’s still being called by the client code. (It just does
>>>> nothing.) Not super important, but it would be nice if at some point
>>>>we can
>>>> figure out if there’s a way to strip out the calls completely.
>>>>
>>>>> On Jul 12, 2017, at 10:07 AM, Harbs <ha...@gmail.com> wrote:
>>>>>
>>>>> Oof. I think I’m still waking up. ;-)
>>>>>
>>>>> I did not realize what I was looking at with the goog.DEBUG. My
>>>> recollection is that trace statements are still being used in the
>>>>release,
>>>> but I’ll double check that.
>>>>>
>>>>>> On Jul 12, 2017, at 9:56 AM, Alex Harui <ah...@adobe.com.INVALID>
>>>> wrote:
>>>>>>
>>>>>> Well, the goal of using goog.DEBUG in Language.as trace() was to
>>>> convince
>>>>>> GCC to eliminate trace(). I haven't checked whether it is working
>>>>>>or
>>>> not.
>>>>>> Requiring everyone to use goog.DEBUG around trace statements sounds
>>>> like
>>>>>> a pain. Probably better to teach the publisher to remove it if GCC
>>>> can't
>>>>>> be taught to do it. We visit almost every line of the JS output in
>>>>>>the
>>>>>> publishers right now.
>>>>>>
>>>>>> My 2 cents,
>>>>>> -Alex
>>>>>>
>>>>>> On 7/11/17, 11:47 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>> On Jul 12, 2017, at 8:20 AM, Alex Harui <ah...@adobe.com.INVALID>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Again, though, I think this optimization isn't urgent.
>>>>>>>
>>>>>>> I completely agree. That’s why I have not been bringing this up
>>>> despite
>>>>>>> it being on my mind. When the discussion came up, I couldn’t help
>>>>>>>but
>>>>>>> join. ;-)
>>>>>>>
>>>>>>>
>>>>>>>> goog.DEBUG is already being used in Language.as.
>>>>>>>
>>>>>>> Thanks! I hadn’t noticed. I was missing an import of of goog.DEBUG
>>>>>>>in
>>>>>>> COMPILE::JS I’m guessing the imports of goog.bind and goog.global
>>>>>>>was
>>>>>>> enough to make goog.DEBUG visible to the compiler in Language.as.
>>>>>>>
>>>>>>> Once we’re on this topic, there’s something that I had wanted to
>>>> bring up
>>>>>>> for a long time: I think trace statements should disappear in the
>>>> release
>>>>>>> JS build. Should we put all the JS trace code inside an
>>>>>>>if(goog.DEBUG)
>>>>>>> block?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Harbs
>>>>>>
>>>>>
>>>>
>>>>
>>>
>
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST
Posted by Harbs <ha...@gmail.com>.
Interesting scenarios. I would not have thought of that.
If we could figure out how to strip the function call and leave the parameter, the compiler would strip out the contents if it could be safely removed.
So trace(“something”) would become “something” which is en empty statement and would be stripped out.
Of course, I have no idea how to go about doing that… ;-)
Harbs
> On Jul 12, 2017, at 4:32 PM, Josh Tynjala <jo...@gmail.com> wrote:
>
> Probably the same with function calls too:
>
> trace(someFunction());
>
> They wanted this to remain:
>
> someFunction();
>
> - Josh
>
> On Wed, Jul 12, 2017 at 6:22 AM, Josh Tynjala <jo...@gmail.com> wrote:
>
>> One thing to keep in mind with stripping out trace() calls is that some
>> developers expect any modifications to variables that happen inside the
>> arguments to remain. I remember a while back someone at Adobe mentioning
>> that people complained when something like this was completely stripped out:
>>
>> trace(doSomething++);
>>
>> Because they expected this part to remain:
>>
>> doSomething++;
>>
>> - Josh
>>
>> On Wed, Jul 12, 2017 at 12:24 AM, Harbs <ha...@gmail.com> wrote:
>>
>>> My bad. It does in fact compile down to this:
>>>
>>> function uM(a){a=Array.prototype.slice.call(arguments,0)}w('org.apach
>>> e.flex.utils.Language.trace',uM);
>>>
>>> So trace does not actually do anything. Great! :-)
>>>
>>> However, it’s still being called by the client code. (It just does
>>> nothing.) Not super important, but it would be nice if at some point we can
>>> figure out if there’s a way to strip out the calls completely.
>>>
>>>> On Jul 12, 2017, at 10:07 AM, Harbs <ha...@gmail.com> wrote:
>>>>
>>>> Oof. I think I’m still waking up. ;-)
>>>>
>>>> I did not realize what I was looking at with the goog.DEBUG. My
>>> recollection is that trace statements are still being used in the release,
>>> but I’ll double check that.
>>>>
>>>>> On Jul 12, 2017, at 9:56 AM, Alex Harui <ah...@adobe.com.INVALID>
>>> wrote:
>>>>>
>>>>> Well, the goal of using goog.DEBUG in Language.as trace() was to
>>> convince
>>>>> GCC to eliminate trace(). I haven't checked whether it is working or
>>> not.
>>>>> Requiring everyone to use goog.DEBUG around trace statements sounds
>>> like
>>>>> a pain. Probably better to teach the publisher to remove it if GCC
>>> can't
>>>>> be taught to do it. We visit almost every line of the JS output in the
>>>>> publishers right now.
>>>>>
>>>>> My 2 cents,
>>>>> -Alex
>>>>>
>>>>> On 7/11/17, 11:47 PM, "Harbs" <ha...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>> On Jul 12, 2017, at 8:20 AM, Alex Harui <ah...@adobe.com.INVALID>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Again, though, I think this optimization isn't urgent.
>>>>>>
>>>>>> I completely agree. That’s why I have not been bringing this up
>>> despite
>>>>>> it being on my mind. When the discussion came up, I couldn’t help but
>>>>>> join. ;-)
>>>>>>
>>>>>>
>>>>>>> goog.DEBUG is already being used in Language.as.
>>>>>>
>>>>>> Thanks! I hadn’t noticed. I was missing an import of of goog.DEBUG in
>>>>>> COMPILE::JS I’m guessing the imports of goog.bind and goog.global was
>>>>>> enough to make goog.DEBUG visible to the compiler in Language.as.
>>>>>>
>>>>>> Once we’re on this topic, there’s something that I had wanted to
>>> bring up
>>>>>> for a long time: I think trace statements should disappear in the
>>> release
>>>>>> JS build. Should we put all the JS trace code inside an if(goog.DEBUG)
>>>>>> block?
>>>>>>
>>>>>> Thanks,
>>>>>> Harbs
>>>>>
>>>>
>>>
>>>
>>
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are
assumed to be POST
Posted by Josh Tynjala <jo...@gmail.com>.
Probably the same with function calls too:
trace(someFunction());
They wanted this to remain:
someFunction();
- Josh
On Wed, Jul 12, 2017 at 6:22 AM, Josh Tynjala <jo...@gmail.com> wrote:
> One thing to keep in mind with stripping out trace() calls is that some
> developers expect any modifications to variables that happen inside the
> arguments to remain. I remember a while back someone at Adobe mentioning
> that people complained when something like this was completely stripped out:
>
> trace(doSomething++);
>
> Because they expected this part to remain:
>
> doSomething++;
>
> - Josh
>
> On Wed, Jul 12, 2017 at 12:24 AM, Harbs <ha...@gmail.com> wrote:
>
>> My bad. It does in fact compile down to this:
>>
>> function uM(a){a=Array.prototype.slice.call(arguments,0)}w('org.apach
>> e.flex.utils.Language.trace',uM);
>>
>> So trace does not actually do anything. Great! :-)
>>
>> However, it’s still being called by the client code. (It just does
>> nothing.) Not super important, but it would be nice if at some point we can
>> figure out if there’s a way to strip out the calls completely.
>>
>> > On Jul 12, 2017, at 10:07 AM, Harbs <ha...@gmail.com> wrote:
>> >
>> > Oof. I think I’m still waking up. ;-)
>> >
>> > I did not realize what I was looking at with the goog.DEBUG. My
>> recollection is that trace statements are still being used in the release,
>> but I’ll double check that.
>> >
>> >> On Jul 12, 2017, at 9:56 AM, Alex Harui <ah...@adobe.com.INVALID>
>> wrote:
>> >>
>> >> Well, the goal of using goog.DEBUG in Language.as trace() was to
>> convince
>> >> GCC to eliminate trace(). I haven't checked whether it is working or
>> not.
>> >> Requiring everyone to use goog.DEBUG around trace statements sounds
>> like
>> >> a pain. Probably better to teach the publisher to remove it if GCC
>> can't
>> >> be taught to do it. We visit almost every line of the JS output in the
>> >> publishers right now.
>> >>
>> >> My 2 cents,
>> >> -Alex
>> >>
>> >> On 7/11/17, 11:47 PM, "Harbs" <ha...@gmail.com> wrote:
>> >>
>> >>>
>> >>>> On Jul 12, 2017, at 8:20 AM, Alex Harui <ah...@adobe.com.INVALID>
>> >>>> wrote:
>> >>>>
>> >>>> Again, though, I think this optimization isn't urgent.
>> >>>
>> >>> I completely agree. That’s why I have not been bringing this up
>> despite
>> >>> it being on my mind. When the discussion came up, I couldn’t help but
>> >>> join. ;-)
>> >>>
>> >>>
>> >>>> goog.DEBUG is already being used in Language.as.
>> >>>
>> >>> Thanks! I hadn’t noticed. I was missing an import of of goog.DEBUG in
>> >>> COMPILE::JS I’m guessing the imports of goog.bind and goog.global was
>> >>> enough to make goog.DEBUG visible to the compiler in Language.as.
>> >>>
>> >>> Once we’re on this topic, there’s something that I had wanted to
>> bring up
>> >>> for a long time: I think trace statements should disappear in the
>> release
>> >>> JS build. Should we put all the JS trace code inside an if(goog.DEBUG)
>> >>> block?
>> >>>
>> >>> Thanks,
>> >>> Harbs
>> >>
>> >
>>
>>
>
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are
assumed to be POST
Posted by Josh Tynjala <jo...@gmail.com>.
One thing to keep in mind with stripping out trace() calls is that some
developers expect any modifications to variables that happen inside the
arguments to remain. I remember a while back someone at Adobe mentioning
that people complained when something like this was completely stripped out:
trace(doSomething++);
Because they expected this part to remain:
doSomething++;
- Josh
On Wed, Jul 12, 2017 at 12:24 AM, Harbs <ha...@gmail.com> wrote:
> My bad. It does in fact compile down to this:
>
> function uM(a){a=Array.prototype.slice.call(arguments,0)}w('org.
> apache.flex.utils.Language.trace',uM);
>
> So trace does not actually do anything. Great! :-)
>
> However, it’s still being called by the client code. (It just does
> nothing.) Not super important, but it would be nice if at some point we can
> figure out if there’s a way to strip out the calls completely.
>
> > On Jul 12, 2017, at 10:07 AM, Harbs <ha...@gmail.com> wrote:
> >
> > Oof. I think I’m still waking up. ;-)
> >
> > I did not realize what I was looking at with the goog.DEBUG. My
> recollection is that trace statements are still being used in the release,
> but I’ll double check that.
> >
> >> On Jul 12, 2017, at 9:56 AM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >>
> >> Well, the goal of using goog.DEBUG in Language.as trace() was to
> convince
> >> GCC to eliminate trace(). I haven't checked whether it is working or
> not.
> >> Requiring everyone to use goog.DEBUG around trace statements sounds like
> >> a pain. Probably better to teach the publisher to remove it if GCC
> can't
> >> be taught to do it. We visit almost every line of the JS output in the
> >> publishers right now.
> >>
> >> My 2 cents,
> >> -Alex
> >>
> >> On 7/11/17, 11:47 PM, "Harbs" <ha...@gmail.com> wrote:
> >>
> >>>
> >>>> On Jul 12, 2017, at 8:20 AM, Alex Harui <ah...@adobe.com.INVALID>
> >>>> wrote:
> >>>>
> >>>> Again, though, I think this optimization isn't urgent.
> >>>
> >>> I completely agree. That’s why I have not been bringing this up despite
> >>> it being on my mind. When the discussion came up, I couldn’t help but
> >>> join. ;-)
> >>>
> >>>
> >>>> goog.DEBUG is already being used in Language.as.
> >>>
> >>> Thanks! I hadn’t noticed. I was missing an import of of goog.DEBUG in
> >>> COMPILE::JS I’m guessing the imports of goog.bind and goog.global was
> >>> enough to make goog.DEBUG visible to the compiler in Language.as.
> >>>
> >>> Once we’re on this topic, there’s something that I had wanted to bring
> up
> >>> for a long time: I think trace statements should disappear in the
> release
> >>> JS build. Should we put all the JS trace code inside an if(goog.DEBUG)
> >>> block?
> >>>
> >>> Thanks,
> >>> Harbs
> >>
> >
>
>
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST
Posted by Harbs <ha...@gmail.com>.
My bad. It does in fact compile down to this:
function uM(a){a=Array.prototype.slice.call(arguments,0)}w('org.apache.flex.utils.Language.trace',uM);
So trace does not actually do anything. Great! :-)
However, it’s still being called by the client code. (It just does nothing.) Not super important, but it would be nice if at some point we can figure out if there’s a way to strip out the calls completely.
> On Jul 12, 2017, at 10:07 AM, Harbs <ha...@gmail.com> wrote:
>
> Oof. I think I’m still waking up. ;-)
>
> I did not realize what I was looking at with the goog.DEBUG. My recollection is that trace statements are still being used in the release, but I’ll double check that.
>
>> On Jul 12, 2017, at 9:56 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> Well, the goal of using goog.DEBUG in Language.as trace() was to convince
>> GCC to eliminate trace(). I haven't checked whether it is working or not.
>> Requiring everyone to use goog.DEBUG around trace statements sounds like
>> a pain. Probably better to teach the publisher to remove it if GCC can't
>> be taught to do it. We visit almost every line of the JS output in the
>> publishers right now.
>>
>> My 2 cents,
>> -Alex
>>
>> On 7/11/17, 11:47 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>>>
>>>> On Jul 12, 2017, at 8:20 AM, Alex Harui <ah...@adobe.com.INVALID>
>>>> wrote:
>>>>
>>>> Again, though, I think this optimization isn't urgent.
>>>
>>> I completely agree. That’s why I have not been bringing this up despite
>>> it being on my mind. When the discussion came up, I couldn’t help but
>>> join. ;-)
>>>
>>>
>>>> goog.DEBUG is already being used in Language.as.
>>>
>>> Thanks! I hadn’t noticed. I was missing an import of of goog.DEBUG in
>>> COMPILE::JS I’m guessing the imports of goog.bind and goog.global was
>>> enough to make goog.DEBUG visible to the compiler in Language.as.
>>>
>>> Once we’re on this topic, there’s something that I had wanted to bring up
>>> for a long time: I think trace statements should disappear in the release
>>> JS build. Should we put all the JS trace code inside an if(goog.DEBUG)
>>> block?
>>>
>>> Thanks,
>>> Harbs
>>
>
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST
Posted by Harbs <ha...@gmail.com>.
Oof. I think I’m still waking up. ;-)
I did not realize what I was looking at with the goog.DEBUG. My recollection is that trace statements are still being used in the release, but I’ll double check that.
> On Jul 12, 2017, at 9:56 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Well, the goal of using goog.DEBUG in Language.as trace() was to convince
> GCC to eliminate trace(). I haven't checked whether it is working or not.
> Requiring everyone to use goog.DEBUG around trace statements sounds like
> a pain. Probably better to teach the publisher to remove it if GCC can't
> be taught to do it. We visit almost every line of the JS output in the
> publishers right now.
>
> My 2 cents,
> -Alex
>
> On 7/11/17, 11:47 PM, "Harbs" <ha...@gmail.com> wrote:
>
>>
>>> On Jul 12, 2017, at 8:20 AM, Alex Harui <ah...@adobe.com.INVALID>
>>> wrote:
>>>
>>> Again, though, I think this optimization isn't urgent.
>>
>> I completely agree. That’s why I have not been bringing this up despite
>> it being on my mind. When the discussion came up, I couldn’t help but
>> join. ;-)
>>
>>
>>> goog.DEBUG is already being used in Language.as.
>>
>> Thanks! I hadn’t noticed. I was missing an import of of goog.DEBUG in
>> COMPILE::JS I’m guessing the imports of goog.bind and goog.global was
>> enough to make goog.DEBUG visible to the compiler in Language.as.
>>
>> Once we’re on this topic, there’s something that I had wanted to bring up
>> for a long time: I think trace statements should disappear in the release
>> JS build. Should we put all the JS trace code inside an if(goog.DEBUG)
>> block?
>>
>> Thanks,
>> Harbs
>
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are
assumed to be POST
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Well, the goal of using goog.DEBUG in Language.as trace() was to convince
GCC to eliminate trace(). I haven't checked whether it is working or not.
Requiring everyone to use goog.DEBUG around trace statements sounds like
a pain. Probably better to teach the publisher to remove it if GCC can't
be taught to do it. We visit almost every line of the JS output in the
publishers right now.
My 2 cents,
-Alex
On 7/11/17, 11:47 PM, "Harbs" <ha...@gmail.com> wrote:
>
>> On Jul 12, 2017, at 8:20 AM, Alex Harui <ah...@adobe.com.INVALID>
>>wrote:
>>
>> Again, though, I think this optimization isn't urgent.
>
>I completely agree. That’s why I have not been bringing this up despite
>it being on my mind. When the discussion came up, I couldn’t help but
>join. ;-)
>
>
>> goog.DEBUG is already being used in Language.as.
>
>Thanks! I hadn’t noticed. I was missing an import of of goog.DEBUG in
>COMPILE::JS I’m guessing the imports of goog.bind and goog.global was
>enough to make goog.DEBUG visible to the compiler in Language.as.
>
>Once we’re on this topic, there’s something that I had wanted to bring up
>for a long time: I think trace statements should disappear in the release
>JS build. Should we put all the JS trace code inside an if(goog.DEBUG)
>block?
>
>Thanks,
>Harbs
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST
Posted by Harbs <ha...@gmail.com>.
> On Jul 12, 2017, at 8:20 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> Again, though, I think this optimization isn't urgent.
I completely agree. That’s why I have not been bringing this up despite it being on my mind. When the discussion came up, I couldn’t help but join. ;-)
> goog.DEBUG is already being used in Language.as.
Thanks! I hadn’t noticed. I was missing an import of of goog.DEBUG in COMPILE::JS I’m guessing the imports of goog.bind and goog.global was enough to make goog.DEBUG visible to the compiler in Language.as.
Once we’re on this topic, there’s something that I had wanted to bring up for a long time: I think trace statements should disappear in the release JS build. Should we put all the JS trace code inside an if(goog.DEBUG) block?
Thanks,
Harbs
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are
assumed to be POST
Posted by Greg Dove <gr...@gmail.com>.
Reflection support was opt-in. Hopefully it still is. As in, if your app
doesn't call any code that uses the reflection data structures they are
not in the minified output.
I had not realised that (nor had I checked), that sounds great.
On Wed, Jul 12, 2017 at 5:20 PM, Alex Harui <ah...@adobe.com.invalid>
wrote:
> Reflection support was opt-in. Hopefully it still is. As in, if your app
> doesn't call any code that uses the reflection data structures they are
> not in the minified output.
>
> DataBinding in general requires exports. Any use of bracket access does
> as well. But yes, I believe a smarter compiler can reduce the number of
> exports.
>
> I'm pretty sure --generate_exports is required to turn our @export
> notation into symbols in the minified output. But the main app has a
> generated exportSymbol call so --generate_exports will not always be
> required for FlexJS.
>
> Again, though, I think this optimization isn't urgent.
>
> goog.DEBUG is already being used in Language.as.
>
> -Alex
>
> On 7/11/17, 4:01 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
> >I'll try those things, I have not tried any of those options so far.
> >
> >Future need to support modules has been mentioned as a reason for keeping
> >@export before.
> >
> >Another is to support reflection (in its current form). Reflection support
> >probably needs to be opt-in, I think this has been discussed before also.
> >
> >Perhaps another in this case might be to support constant bindings.
> >This is one area that could probably benefit from jx-compiler optimisation
> >for primitive constant lookups - iirc I *think* that constant bindings are
> >still happening via bracket access, and probably could simply be replaced
> >by the literal values for string, number etc.
> >
> >
> >
> >
> >On Wed, Jul 12, 2017 at 9:57 AM, Harbs <ha...@gmail.com> wrote:
> >
> >> Hi Greg,
> >>
> >> There probably is too much use of @export. @const is probably more
> >>correct
> >> than @export — as long as we are sure that there’s no use of bracket
> >> notation anywhere. I’d be interested in hearing your findings.
> >>
> >> Personally, I’m not sure there’s a lot of value to be using @export at
> >>all
> >> unless an app is using modules of some sort (which I’m not even sure
> >>how to
> >> do with FlexJS). (but I might be missing something with the @export tag)
> >>
> >> What happens if the compiler is run without --generate_exports? Do the
> >> @exports get stripped out? If yes, is there some kind of “super export”?
> >> There needs to be some way to invoke the app…
> >>
> >> Harbs
> >>
> >> > On Jul 11, 2017, at 11:40 PM, Greg Dove <gr...@gmail.com> wrote:
> >> >
> >> > Guys, we certainly have been here before.
> >> >
> >> > From a js release 'size' perspective, I don't think it matters
> >>whether we
> >> > use constants or liteterals, I think the main difference is that if
> >>the
> >> > static const exists it will also be included in the release output as
> >>I
> >> > expect it has an @export annotation. This means it should be
> >> 'reflectable'
> >> > via array/bracket access syntax via its original package/class naming.
> >> But
> >> > in terms of usage sites within the codebase, it should already be
> >> optimised
> >> > via GCC, becuase GCC is already capable of inlining anything annotated
> >> as a
> >> > constant [1].
> >> > So I would expect it to already be inlined in the js-release, and we
> >> > *should not need* to write any code in the jx compiler to do that,
> >>unless
> >> > we specifically need this inlining (for some reason) in the debug
> >>version
> >> > of the js output.
> >> >
> >> > GCC also creates a single short named variable to refer to repeated
> >> > literals througout the compiled codebase, so I would expect the
> >>inlining
> >> of
> >> > consts would get this as a 2nd optimization pass as well. In the end I
> >> > expect the only output difference between the two approaches should be
> >> that
> >> > we also get an extra exported constant that retains the same naming
> >> > convention of lookups etc because we are @export-ing it.
> >> >
> >> > I'm pretty sure this is correct, but I might be wrong. I will check
> >>all
> >> > this later today, and report back.
> >> >
> >> > 1.
> >> >
> >>https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgithub.c
> >>om%2Fgoogle%2Fclosure-compiler%2Fwiki%2F&data=02%
> 7C01%7C%7Cb1383499ae944d
> >>36cc6808d4c8b34fc5%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636354119
> >>847040656&sdata=1J07jc05ULQcd8VP01X2D4b6B62UHc
> EDTA71CS51O3s%3D&reserved=0
> >> Annotating-JavaScript-for-the-Closure-Compiler#const-const-type
> >> >
> >> >
> >> >
> >> > On Wed, Jul 12, 2017 at 3:47 AM, Harbs <ha...@gmail.com> wrote:
> >> >
> >> >> +1.
> >> >>
> >> >> I also think that we have bigger fish to fry first.
> >> >>
> >> >> My point was not to force one way or the other. Rather that the way
> >>it
> >> >> currently stands there’s a valid reason to use string literals. I was
> >> not
> >> >> suggesting changing anything.
> >> >>
> >> >> Thanks,
> >> >> Harbs
> >> >>
> >> >>> On Jul 11, 2017, at 6:33 PM, Josh Tynjala <jo...@gmail.com>
> >> wrote:
> >> >>>
> >> >>> That sounds like the proper way to handle this! We should be able to
> >> >>> reference constants in our ActionScript so that we can get
> >>compile-time
> >> >>> errors from typos, while the compiler makes sure that generated
> >> >> JavaScript
> >> >>> can be properly minified.
> >> >>>
> >> >>> - Josh
> >> >>>
> >> >>> On Tue, Jul 11, 2017 at 8:20 AM, Alex Harui
> >><ah...@adobe.com.invalid>
> >> >>> wrote:
> >> >>>
> >> >>>> AIUI, there is a cost in the minified JS to using constants.
> >> >>>>
> >> >>>> However, there is a cost to screwing up the typing of a string
> >>literal
> >> >> as
> >> >>>> well.
> >> >>>>
> >> >>>> The best answer for now, IMO, is to not care whether folks use
> >> constants
> >> >>>> or string literals. There are much bigger fish to fry. I don't
> >>want
> >> to
> >> >>>> see sweeping changes of replacing all string literals with
> >>constants
> >> or
> >> >>>> vice versa. If you've got that kind of time on your hands, learn
> >>the
> >> >>>> compiler code and see if you can make the cross-compiler replace
> >>all
> >> >>>> constants with string literals. IMO, that's the right answer.
> >> >>>>
> >> >>>> -Alex
> >> >>>>
> >> >>>> On 7/11/17, 5:37 AM, "Harbs" <ha...@gmail.com> wrote:
> >> >>>>
> >> >>>>> Here’s what is output in the minimized code:
> >> >>>>>
> >> >>>>> function
> >> >>>>> fqa(){}w('org.apache.flex.net.HTTPConstants.GET','GET');
> >> >>>> w('org.apache.flex
> >> >>>>> .net.HTTPConstants.POST','POST');w('org.apache.flex.net.
> >> >>>> HTTPConstants.PUT'
> >> >>>>> ,'PUT');w('org.apache.flex.net.HTTPConstants.FORM_URL_
> >> >>>> ENCODED',Fm);w('org.
> >> >>>>> apache.flex.net.HTTPConstants.DELETE','DELETE'
> >> >>>> );w('org.apache.flex.net.HTT
> >> >>>>> PConstants.OPEN','open');w('org.apache.flex.net.
> >> >>>> HTTPConstants.COMPLETE',Bt
> >> >>>>> );w('org.apache.flex.net.HTTPConstants.COMMUNICATION_
> >> >>>> ERROR',At);w('org.apa
> >> >>>>> che.flex.net.HTTPConstants.IO_ERROR','ioError');
> >> >>>>> w('org.apache.flex.net.HTTPConstants.SECURITY_ERROR',
> >> >>>> 'securityError');w('o
> >> >>>>> rg.apache.flex.net.HTTPConstants.STATUS',Fx);w('
> >> >>>> org.apache.flex.net.HTTPCo
> >> >>>>> nstants.RESPONSE_STATUS','httpResponseStatus');fqa.
> >> >>>> prototype.h={names:[{na
> >> >>>>> me:'HTTPConstants',i:IF,kind:g}]};w(IF,fqa);
> >> >>>>>
> >> >>>>> elsewhere:
> >> >>>>> IF='org.apache.flex.net.HTTPConstants’,
> >> >>>>>
> >> >>>>> That’s 807 bytes. That’s quite a penalty for avoiding typing
> >>“POST”…
> >> >>>>>
> >> >>>>> No idea what wiki you are referring to.
> >> >>>>>
> >> >>>>> Harbs
> >> >>>>>
> >> >>>>>> On Jul 11, 2017, at 2:36 PM, Justin Mclean <
> >> justin@classsoftware.com>
> >> >>>>>> wrote:
> >> >>>>>>
> >> >>>>>> Hi,
> >> >>>>>>
> >> >>>>>>> As it stands now, use of constants result in more JS code after
> >> >>>>>>> compiled.
> >> >>>>>>
> >> >>>>>> Debug yes but not optimised / release.
> >> >>>>>>
> >> >>>>>>> It’s possible that this can be optimized, but currently the most
> >> >>>>>>> efficient JS code is produced if using string literals rather
> >>than
> >> >>>>>>> constants. (The Google compiler created variables for string
> >> literals
> >> >>>>>>> used more than once.)
> >> >>>>>>
> >> >>>>>> That's not we found in a previous thread on this list, the google
> >> >>>>>> compiler optimises the constants and there is no penalty in using
> >> >> them.
> >> >>>>>> You mind provide examples that show the above is the actually
> >>case
> >> and
> >> >>>>>> document it on the wiki?
> >> >>>>>>
> >> >>>>>> My vote would be not the duplicate the strings everywhere and use
> >> >>>>>> constants as there is no cost and increased safety.
> >> >>>>>>
> >> >>>>>> Thanks,
> >> >>>>>> Justin
> >> >>>>>
> >> >>>>
> >> >>>>
> >> >>
> >> >>
> >>
> >>
>
>
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are
assumed to be POST
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Reflection support was opt-in. Hopefully it still is. As in, if your app
doesn't call any code that uses the reflection data structures they are
not in the minified output.
DataBinding in general requires exports. Any use of bracket access does
as well. But yes, I believe a smarter compiler can reduce the number of
exports.
I'm pretty sure --generate_exports is required to turn our @export
notation into symbols in the minified output. But the main app has a
generated exportSymbol call so --generate_exports will not always be
required for FlexJS.
Again, though, I think this optimization isn't urgent.
goog.DEBUG is already being used in Language.as.
-Alex
On 7/11/17, 4:01 PM, "Greg Dove" <gr...@gmail.com> wrote:
>I'll try those things, I have not tried any of those options so far.
>
>Future need to support modules has been mentioned as a reason for keeping
>@export before.
>
>Another is to support reflection (in its current form). Reflection support
>probably needs to be opt-in, I think this has been discussed before also.
>
>Perhaps another in this case might be to support constant bindings.
>This is one area that could probably benefit from jx-compiler optimisation
>for primitive constant lookups - iirc I *think* that constant bindings are
>still happening via bracket access, and probably could simply be replaced
>by the literal values for string, number etc.
>
>
>
>
>On Wed, Jul 12, 2017 at 9:57 AM, Harbs <ha...@gmail.com> wrote:
>
>> Hi Greg,
>>
>> There probably is too much use of @export. @const is probably more
>>correct
>> than @export — as long as we are sure that there’s no use of bracket
>> notation anywhere. I’d be interested in hearing your findings.
>>
>> Personally, I’m not sure there’s a lot of value to be using @export at
>>all
>> unless an app is using modules of some sort (which I’m not even sure
>>how to
>> do with FlexJS). (but I might be missing something with the @export tag)
>>
>> What happens if the compiler is run without --generate_exports? Do the
>> @exports get stripped out? If yes, is there some kind of “super export”?
>> There needs to be some way to invoke the app…
>>
>> Harbs
>>
>> > On Jul 11, 2017, at 11:40 PM, Greg Dove <gr...@gmail.com> wrote:
>> >
>> > Guys, we certainly have been here before.
>> >
>> > From a js release 'size' perspective, I don't think it matters
>>whether we
>> > use constants or liteterals, I think the main difference is that if
>>the
>> > static const exists it will also be included in the release output as
>>I
>> > expect it has an @export annotation. This means it should be
>> 'reflectable'
>> > via array/bracket access syntax via its original package/class naming.
>> But
>> > in terms of usage sites within the codebase, it should already be
>> optimised
>> > via GCC, becuase GCC is already capable of inlining anything annotated
>> as a
>> > constant [1].
>> > So I would expect it to already be inlined in the js-release, and we
>> > *should not need* to write any code in the jx compiler to do that,
>>unless
>> > we specifically need this inlining (for some reason) in the debug
>>version
>> > of the js output.
>> >
>> > GCC also creates a single short named variable to refer to repeated
>> > literals througout the compiled codebase, so I would expect the
>>inlining
>> of
>> > consts would get this as a 2nd optimization pass as well. In the end I
>> > expect the only output difference between the two approaches should be
>> that
>> > we also get an extra exported constant that retains the same naming
>> > convention of lookups etc because we are @export-ing it.
>> >
>> > I'm pretty sure this is correct, but I might be wrong. I will check
>>all
>> > this later today, and report back.
>> >
>> > 1.
>> >
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
>>om%2Fgoogle%2Fclosure-compiler%2Fwiki%2F&data=02%7C01%7C%7Cb1383499ae944d
>>36cc6808d4c8b34fc5%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636354119
>>847040656&sdata=1J07jc05ULQcd8VP01X2D4b6B62UHcEDTA71CS51O3s%3D&reserved=0
>> Annotating-JavaScript-for-the-Closure-Compiler#const-const-type
>> >
>> >
>> >
>> > On Wed, Jul 12, 2017 at 3:47 AM, Harbs <ha...@gmail.com> wrote:
>> >
>> >> +1.
>> >>
>> >> I also think that we have bigger fish to fry first.
>> >>
>> >> My point was not to force one way or the other. Rather that the way
>>it
>> >> currently stands there’s a valid reason to use string literals. I was
>> not
>> >> suggesting changing anything.
>> >>
>> >> Thanks,
>> >> Harbs
>> >>
>> >>> On Jul 11, 2017, at 6:33 PM, Josh Tynjala <jo...@gmail.com>
>> wrote:
>> >>>
>> >>> That sounds like the proper way to handle this! We should be able to
>> >>> reference constants in our ActionScript so that we can get
>>compile-time
>> >>> errors from typos, while the compiler makes sure that generated
>> >> JavaScript
>> >>> can be properly minified.
>> >>>
>> >>> - Josh
>> >>>
>> >>> On Tue, Jul 11, 2017 at 8:20 AM, Alex Harui
>><ah...@adobe.com.invalid>
>> >>> wrote:
>> >>>
>> >>>> AIUI, there is a cost in the minified JS to using constants.
>> >>>>
>> >>>> However, there is a cost to screwing up the typing of a string
>>literal
>> >> as
>> >>>> well.
>> >>>>
>> >>>> The best answer for now, IMO, is to not care whether folks use
>> constants
>> >>>> or string literals. There are much bigger fish to fry. I don't
>>want
>> to
>> >>>> see sweeping changes of replacing all string literals with
>>constants
>> or
>> >>>> vice versa. If you've got that kind of time on your hands, learn
>>the
>> >>>> compiler code and see if you can make the cross-compiler replace
>>all
>> >>>> constants with string literals. IMO, that's the right answer.
>> >>>>
>> >>>> -Alex
>> >>>>
>> >>>> On 7/11/17, 5:37 AM, "Harbs" <ha...@gmail.com> wrote:
>> >>>>
>> >>>>> Here’s what is output in the minimized code:
>> >>>>>
>> >>>>> function
>> >>>>> fqa(){}w('org.apache.flex.net.HTTPConstants.GET','GET');
>> >>>> w('org.apache.flex
>> >>>>> .net.HTTPConstants.POST','POST');w('org.apache.flex.net.
>> >>>> HTTPConstants.PUT'
>> >>>>> ,'PUT');w('org.apache.flex.net.HTTPConstants.FORM_URL_
>> >>>> ENCODED',Fm);w('org.
>> >>>>> apache.flex.net.HTTPConstants.DELETE','DELETE'
>> >>>> );w('org.apache.flex.net.HTT
>> >>>>> PConstants.OPEN','open');w('org.apache.flex.net.
>> >>>> HTTPConstants.COMPLETE',Bt
>> >>>>> );w('org.apache.flex.net.HTTPConstants.COMMUNICATION_
>> >>>> ERROR',At);w('org.apa
>> >>>>> che.flex.net.HTTPConstants.IO_ERROR','ioError');
>> >>>>> w('org.apache.flex.net.HTTPConstants.SECURITY_ERROR',
>> >>>> 'securityError');w('o
>> >>>>> rg.apache.flex.net.HTTPConstants.STATUS',Fx);w('
>> >>>> org.apache.flex.net.HTTPCo
>> >>>>> nstants.RESPONSE_STATUS','httpResponseStatus');fqa.
>> >>>> prototype.h={names:[{na
>> >>>>> me:'HTTPConstants',i:IF,kind:g}]};w(IF,fqa);
>> >>>>>
>> >>>>> elsewhere:
>> >>>>> IF='org.apache.flex.net.HTTPConstants’,
>> >>>>>
>> >>>>> That’s 807 bytes. That’s quite a penalty for avoiding typing
>>“POST”…
>> >>>>>
>> >>>>> No idea what wiki you are referring to.
>> >>>>>
>> >>>>> Harbs
>> >>>>>
>> >>>>>> On Jul 11, 2017, at 2:36 PM, Justin Mclean <
>> justin@classsoftware.com>
>> >>>>>> wrote:
>> >>>>>>
>> >>>>>> Hi,
>> >>>>>>
>> >>>>>>> As it stands now, use of constants result in more JS code after
>> >>>>>>> compiled.
>> >>>>>>
>> >>>>>> Debug yes but not optimised / release.
>> >>>>>>
>> >>>>>>> It’s possible that this can be optimized, but currently the most
>> >>>>>>> efficient JS code is produced if using string literals rather
>>than
>> >>>>>>> constants. (The Google compiler created variables for string
>> literals
>> >>>>>>> used more than once.)
>> >>>>>>
>> >>>>>> That's not we found in a previous thread on this list, the google
>> >>>>>> compiler optimises the constants and there is no penalty in using
>> >> them.
>> >>>>>> You mind provide examples that show the above is the actually
>>case
>> and
>> >>>>>> document it on the wiki?
>> >>>>>>
>> >>>>>> My vote would be not the duplicate the strings everywhere and use
>> >>>>>> constants as there is no cost and increased safety.
>> >>>>>>
>> >>>>>> Thanks,
>> >>>>>> Justin
>> >>>>>
>> >>>>
>> >>>>
>> >>
>> >>
>>
>>
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are
assumed to be POST
Posted by Greg Dove <gr...@gmail.com>.
I'll try those things, I have not tried any of those options so far.
Future need to support modules has been mentioned as a reason for keeping
@export before.
Another is to support reflection (in its current form). Reflection support
probably needs to be opt-in, I think this has been discussed before also.
Perhaps another in this case might be to support constant bindings.
This is one area that could probably benefit from jx-compiler optimisation
for primitive constant lookups - iirc I *think* that constant bindings are
still happening via bracket access, and probably could simply be replaced
by the literal values for string, number etc.
On Wed, Jul 12, 2017 at 9:57 AM, Harbs <ha...@gmail.com> wrote:
> Hi Greg,
>
> There probably is too much use of @export. @const is probably more correct
> than @export — as long as we are sure that there’s no use of bracket
> notation anywhere. I’d be interested in hearing your findings.
>
> Personally, I’m not sure there’s a lot of value to be using @export at all
> unless an app is using modules of some sort (which I’m not even sure how to
> do with FlexJS). (but I might be missing something with the @export tag)
>
> What happens if the compiler is run without --generate_exports? Do the
> @exports get stripped out? If yes, is there some kind of “super export”?
> There needs to be some way to invoke the app…
>
> Harbs
>
> > On Jul 11, 2017, at 11:40 PM, Greg Dove <gr...@gmail.com> wrote:
> >
> > Guys, we certainly have been here before.
> >
> > From a js release 'size' perspective, I don't think it matters whether we
> > use constants or liteterals, I think the main difference is that if the
> > static const exists it will also be included in the release output as I
> > expect it has an @export annotation. This means it should be
> 'reflectable'
> > via array/bracket access syntax via its original package/class naming.
> But
> > in terms of usage sites within the codebase, it should already be
> optimised
> > via GCC, becuase GCC is already capable of inlining anything annotated
> as a
> > constant [1].
> > So I would expect it to already be inlined in the js-release, and we
> > *should not need* to write any code in the jx compiler to do that, unless
> > we specifically need this inlining (for some reason) in the debug version
> > of the js output.
> >
> > GCC also creates a single short named variable to refer to repeated
> > literals througout the compiled codebase, so I would expect the inlining
> of
> > consts would get this as a 2nd optimization pass as well. In the end I
> > expect the only output difference between the two approaches should be
> that
> > we also get an extra exported constant that retains the same naming
> > convention of lookups etc because we are @export-ing it.
> >
> > I'm pretty sure this is correct, but I might be wrong. I will check all
> > this later today, and report back.
> >
> > 1.
> > https://github.com/google/closure-compiler/wiki/
> Annotating-JavaScript-for-the-Closure-Compiler#const-const-type
> >
> >
> >
> > On Wed, Jul 12, 2017 at 3:47 AM, Harbs <ha...@gmail.com> wrote:
> >
> >> +1.
> >>
> >> I also think that we have bigger fish to fry first.
> >>
> >> My point was not to force one way or the other. Rather that the way it
> >> currently stands there’s a valid reason to use string literals. I was
> not
> >> suggesting changing anything.
> >>
> >> Thanks,
> >> Harbs
> >>
> >>> On Jul 11, 2017, at 6:33 PM, Josh Tynjala <jo...@gmail.com>
> wrote:
> >>>
> >>> That sounds like the proper way to handle this! We should be able to
> >>> reference constants in our ActionScript so that we can get compile-time
> >>> errors from typos, while the compiler makes sure that generated
> >> JavaScript
> >>> can be properly minified.
> >>>
> >>> - Josh
> >>>
> >>> On Tue, Jul 11, 2017 at 8:20 AM, Alex Harui <ah...@adobe.com.invalid>
> >>> wrote:
> >>>
> >>>> AIUI, there is a cost in the minified JS to using constants.
> >>>>
> >>>> However, there is a cost to screwing up the typing of a string literal
> >> as
> >>>> well.
> >>>>
> >>>> The best answer for now, IMO, is to not care whether folks use
> constants
> >>>> or string literals. There are much bigger fish to fry. I don't want
> to
> >>>> see sweeping changes of replacing all string literals with constants
> or
> >>>> vice versa. If you've got that kind of time on your hands, learn the
> >>>> compiler code and see if you can make the cross-compiler replace all
> >>>> constants with string literals. IMO, that's the right answer.
> >>>>
> >>>> -Alex
> >>>>
> >>>> On 7/11/17, 5:37 AM, "Harbs" <ha...@gmail.com> wrote:
> >>>>
> >>>>> Here’s what is output in the minimized code:
> >>>>>
> >>>>> function
> >>>>> fqa(){}w('org.apache.flex.net.HTTPConstants.GET','GET');
> >>>> w('org.apache.flex
> >>>>> .net.HTTPConstants.POST','POST');w('org.apache.flex.net.
> >>>> HTTPConstants.PUT'
> >>>>> ,'PUT');w('org.apache.flex.net.HTTPConstants.FORM_URL_
> >>>> ENCODED',Fm);w('org.
> >>>>> apache.flex.net.HTTPConstants.DELETE','DELETE'
> >>>> );w('org.apache.flex.net.HTT
> >>>>> PConstants.OPEN','open');w('org.apache.flex.net.
> >>>> HTTPConstants.COMPLETE',Bt
> >>>>> );w('org.apache.flex.net.HTTPConstants.COMMUNICATION_
> >>>> ERROR',At);w('org.apa
> >>>>> che.flex.net.HTTPConstants.IO_ERROR','ioError');
> >>>>> w('org.apache.flex.net.HTTPConstants.SECURITY_ERROR',
> >>>> 'securityError');w('o
> >>>>> rg.apache.flex.net.HTTPConstants.STATUS',Fx);w('
> >>>> org.apache.flex.net.HTTPCo
> >>>>> nstants.RESPONSE_STATUS','httpResponseStatus');fqa.
> >>>> prototype.h={names:[{na
> >>>>> me:'HTTPConstants',i:IF,kind:g}]};w(IF,fqa);
> >>>>>
> >>>>> elsewhere:
> >>>>> IF='org.apache.flex.net.HTTPConstants’,
> >>>>>
> >>>>> That’s 807 bytes. That’s quite a penalty for avoiding typing “POST”…
> >>>>>
> >>>>> No idea what wiki you are referring to.
> >>>>>
> >>>>> Harbs
> >>>>>
> >>>>>> On Jul 11, 2017, at 2:36 PM, Justin Mclean <
> justin@classsoftware.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>>> As it stands now, use of constants result in more JS code after
> >>>>>>> compiled.
> >>>>>>
> >>>>>> Debug yes but not optimised / release.
> >>>>>>
> >>>>>>> It’s possible that this can be optimized, but currently the most
> >>>>>>> efficient JS code is produced if using string literals rather than
> >>>>>>> constants. (The Google compiler created variables for string
> literals
> >>>>>>> used more than once.)
> >>>>>>
> >>>>>> That's not we found in a previous thread on this list, the google
> >>>>>> compiler optimises the constants and there is no penalty in using
> >> them.
> >>>>>> You mind provide examples that show the above is the actually case
> and
> >>>>>> document it on the wiki?
> >>>>>>
> >>>>>> My vote would be not the duplicate the strings everywhere and use
> >>>>>> constants as there is no cost and increased safety.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Justin
> >>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST
Posted by Harbs <ha...@gmail.com>.
Hi Greg,
There probably is too much use of @export. @const is probably more correct than @export — as long as we are sure that there’s no use of bracket notation anywhere. I’d be interested in hearing your findings.
Personally, I’m not sure there’s a lot of value to be using @export at all unless an app is using modules of some sort (which I’m not even sure how to do with FlexJS). (but I might be missing something with the @export tag)
What happens if the compiler is run without --generate_exports? Do the @exports get stripped out? If yes, is there some kind of “super export”? There needs to be some way to invoke the app…
Harbs
> On Jul 11, 2017, at 11:40 PM, Greg Dove <gr...@gmail.com> wrote:
>
> Guys, we certainly have been here before.
>
> From a js release 'size' perspective, I don't think it matters whether we
> use constants or liteterals, I think the main difference is that if the
> static const exists it will also be included in the release output as I
> expect it has an @export annotation. This means it should be 'reflectable'
> via array/bracket access syntax via its original package/class naming. But
> in terms of usage sites within the codebase, it should already be optimised
> via GCC, becuase GCC is already capable of inlining anything annotated as a
> constant [1].
> So I would expect it to already be inlined in the js-release, and we
> *should not need* to write any code in the jx compiler to do that, unless
> we specifically need this inlining (for some reason) in the debug version
> of the js output.
>
> GCC also creates a single short named variable to refer to repeated
> literals througout the compiled codebase, so I would expect the inlining of
> consts would get this as a 2nd optimization pass as well. In the end I
> expect the only output difference between the two approaches should be that
> we also get an extra exported constant that retains the same naming
> convention of lookups etc because we are @export-ing it.
>
> I'm pretty sure this is correct, but I might be wrong. I will check all
> this later today, and report back.
>
> 1.
> https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler#const-const-type
>
>
>
> On Wed, Jul 12, 2017 at 3:47 AM, Harbs <ha...@gmail.com> wrote:
>
>> +1.
>>
>> I also think that we have bigger fish to fry first.
>>
>> My point was not to force one way or the other. Rather that the way it
>> currently stands there’s a valid reason to use string literals. I was not
>> suggesting changing anything.
>>
>> Thanks,
>> Harbs
>>
>>> On Jul 11, 2017, at 6:33 PM, Josh Tynjala <jo...@gmail.com> wrote:
>>>
>>> That sounds like the proper way to handle this! We should be able to
>>> reference constants in our ActionScript so that we can get compile-time
>>> errors from typos, while the compiler makes sure that generated
>> JavaScript
>>> can be properly minified.
>>>
>>> - Josh
>>>
>>> On Tue, Jul 11, 2017 at 8:20 AM, Alex Harui <ah...@adobe.com.invalid>
>>> wrote:
>>>
>>>> AIUI, there is a cost in the minified JS to using constants.
>>>>
>>>> However, there is a cost to screwing up the typing of a string literal
>> as
>>>> well.
>>>>
>>>> The best answer for now, IMO, is to not care whether folks use constants
>>>> or string literals. There are much bigger fish to fry. I don't want to
>>>> see sweeping changes of replacing all string literals with constants or
>>>> vice versa. If you've got that kind of time on your hands, learn the
>>>> compiler code and see if you can make the cross-compiler replace all
>>>> constants with string literals. IMO, that's the right answer.
>>>>
>>>> -Alex
>>>>
>>>> On 7/11/17, 5:37 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>
>>>>> Here’s what is output in the minimized code:
>>>>>
>>>>> function
>>>>> fqa(){}w('org.apache.flex.net.HTTPConstants.GET','GET');
>>>> w('org.apache.flex
>>>>> .net.HTTPConstants.POST','POST');w('org.apache.flex.net.
>>>> HTTPConstants.PUT'
>>>>> ,'PUT');w('org.apache.flex.net.HTTPConstants.FORM_URL_
>>>> ENCODED',Fm);w('org.
>>>>> apache.flex.net.HTTPConstants.DELETE','DELETE'
>>>> );w('org.apache.flex.net.HTT
>>>>> PConstants.OPEN','open');w('org.apache.flex.net.
>>>> HTTPConstants.COMPLETE',Bt
>>>>> );w('org.apache.flex.net.HTTPConstants.COMMUNICATION_
>>>> ERROR',At);w('org.apa
>>>>> che.flex.net.HTTPConstants.IO_ERROR','ioError');
>>>>> w('org.apache.flex.net.HTTPConstants.SECURITY_ERROR',
>>>> 'securityError');w('o
>>>>> rg.apache.flex.net.HTTPConstants.STATUS',Fx);w('
>>>> org.apache.flex.net.HTTPCo
>>>>> nstants.RESPONSE_STATUS','httpResponseStatus');fqa.
>>>> prototype.h={names:[{na
>>>>> me:'HTTPConstants',i:IF,kind:g}]};w(IF,fqa);
>>>>>
>>>>> elsewhere:
>>>>> IF='org.apache.flex.net.HTTPConstants’,
>>>>>
>>>>> That’s 807 bytes. That’s quite a penalty for avoiding typing “POST”…
>>>>>
>>>>> No idea what wiki you are referring to.
>>>>>
>>>>> Harbs
>>>>>
>>>>>> On Jul 11, 2017, at 2:36 PM, Justin Mclean <ju...@classsoftware.com>
>>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>> As it stands now, use of constants result in more JS code after
>>>>>>> compiled.
>>>>>>
>>>>>> Debug yes but not optimised / release.
>>>>>>
>>>>>>> It’s possible that this can be optimized, but currently the most
>>>>>>> efficient JS code is produced if using string literals rather than
>>>>>>> constants. (The Google compiler created variables for string literals
>>>>>>> used more than once.)
>>>>>>
>>>>>> That's not we found in a previous thread on this list, the google
>>>>>> compiler optimises the constants and there is no penalty in using
>> them.
>>>>>> You mind provide examples that show the above is the actually case and
>>>>>> document it on the wiki?
>>>>>>
>>>>>> My vote would be not the duplicate the strings everywhere and use
>>>>>> constants as there is no cost and increased safety.
>>>>>>
>>>>>> Thanks,
>>>>>> Justin
>>>>>
>>>>
>>>>
>>
>>
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are
assumed to be POST
Posted by Greg Dove <gr...@gmail.com>.
Guys, we certainly have been here before.
From a js release 'size' perspective, I don't think it matters whether we
use constants or liteterals, I think the main difference is that if the
static const exists it will also be included in the release output as I
expect it has an @export annotation. This means it should be 'reflectable'
via array/bracket access syntax via its original package/class naming. But
in terms of usage sites within the codebase, it should already be optimised
via GCC, becuase GCC is already capable of inlining anything annotated as a
constant [1].
So I would expect it to already be inlined in the js-release, and we
*should not need* to write any code in the jx compiler to do that, unless
we specifically need this inlining (for some reason) in the debug version
of the js output.
GCC also creates a single short named variable to refer to repeated
literals througout the compiled codebase, so I would expect the inlining of
consts would get this as a 2nd optimization pass as well. In the end I
expect the only output difference between the two approaches should be that
we also get an extra exported constant that retains the same naming
convention of lookups etc because we are @export-ing it.
I'm pretty sure this is correct, but I might be wrong. I will check all
this later today, and report back.
1.
https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler#const-const-type
On Wed, Jul 12, 2017 at 3:47 AM, Harbs <ha...@gmail.com> wrote:
> +1.
>
> I also think that we have bigger fish to fry first.
>
> My point was not to force one way or the other. Rather that the way it
> currently stands there’s a valid reason to use string literals. I was not
> suggesting changing anything.
>
> Thanks,
> Harbs
>
> > On Jul 11, 2017, at 6:33 PM, Josh Tynjala <jo...@gmail.com> wrote:
> >
> > That sounds like the proper way to handle this! We should be able to
> > reference constants in our ActionScript so that we can get compile-time
> > errors from typos, while the compiler makes sure that generated
> JavaScript
> > can be properly minified.
> >
> > - Josh
> >
> > On Tue, Jul 11, 2017 at 8:20 AM, Alex Harui <ah...@adobe.com.invalid>
> > wrote:
> >
> >> AIUI, there is a cost in the minified JS to using constants.
> >>
> >> However, there is a cost to screwing up the typing of a string literal
> as
> >> well.
> >>
> >> The best answer for now, IMO, is to not care whether folks use constants
> >> or string literals. There are much bigger fish to fry. I don't want to
> >> see sweeping changes of replacing all string literals with constants or
> >> vice versa. If you've got that kind of time on your hands, learn the
> >> compiler code and see if you can make the cross-compiler replace all
> >> constants with string literals. IMO, that's the right answer.
> >>
> >> -Alex
> >>
> >> On 7/11/17, 5:37 AM, "Harbs" <ha...@gmail.com> wrote:
> >>
> >>> Here’s what is output in the minimized code:
> >>>
> >>> function
> >>> fqa(){}w('org.apache.flex.net.HTTPConstants.GET','GET');
> >> w('org.apache.flex
> >>> .net.HTTPConstants.POST','POST');w('org.apache.flex.net.
> >> HTTPConstants.PUT'
> >>> ,'PUT');w('org.apache.flex.net.HTTPConstants.FORM_URL_
> >> ENCODED',Fm);w('org.
> >>> apache.flex.net.HTTPConstants.DELETE','DELETE'
> >> );w('org.apache.flex.net.HTT
> >>> PConstants.OPEN','open');w('org.apache.flex.net.
> >> HTTPConstants.COMPLETE',Bt
> >>> );w('org.apache.flex.net.HTTPConstants.COMMUNICATION_
> >> ERROR',At);w('org.apa
> >>> che.flex.net.HTTPConstants.IO_ERROR','ioError');
> >>> w('org.apache.flex.net.HTTPConstants.SECURITY_ERROR',
> >> 'securityError');w('o
> >>> rg.apache.flex.net.HTTPConstants.STATUS',Fx);w('
> >> org.apache.flex.net.HTTPCo
> >>> nstants.RESPONSE_STATUS','httpResponseStatus');fqa.
> >> prototype.h={names:[{na
> >>> me:'HTTPConstants',i:IF,kind:g}]};w(IF,fqa);
> >>>
> >>> elsewhere:
> >>> IF='org.apache.flex.net.HTTPConstants’,
> >>>
> >>> That’s 807 bytes. That’s quite a penalty for avoiding typing “POST”…
> >>>
> >>> No idea what wiki you are referring to.
> >>>
> >>> Harbs
> >>>
> >>>> On Jul 11, 2017, at 2:36 PM, Justin Mclean <ju...@classsoftware.com>
> >>>> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>>> As it stands now, use of constants result in more JS code after
> >>>>> compiled.
> >>>>
> >>>> Debug yes but not optimised / release.
> >>>>
> >>>>> It’s possible that this can be optimized, but currently the most
> >>>>> efficient JS code is produced if using string literals rather than
> >>>>> constants. (The Google compiler created variables for string literals
> >>>>> used more than once.)
> >>>>
> >>>> That's not we found in a previous thread on this list, the google
> >>>> compiler optimises the constants and there is no penalty in using
> them.
> >>>> You mind provide examples that show the above is the actually case and
> >>>> document it on the wiki?
> >>>>
> >>>> My vote would be not the duplicate the strings everywhere and use
> >>>> constants as there is no cost and increased safety.
> >>>>
> >>>> Thanks,
> >>>> Justin
> >>>
> >>
> >>
>
>
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST
Posted by Harbs <ha...@gmail.com>.
+1.
I also think that we have bigger fish to fry first.
My point was not to force one way or the other. Rather that the way it currently stands there’s a valid reason to use string literals. I was not suggesting changing anything.
Thanks,
Harbs
> On Jul 11, 2017, at 6:33 PM, Josh Tynjala <jo...@gmail.com> wrote:
>
> That sounds like the proper way to handle this! We should be able to
> reference constants in our ActionScript so that we can get compile-time
> errors from typos, while the compiler makes sure that generated JavaScript
> can be properly minified.
>
> - Josh
>
> On Tue, Jul 11, 2017 at 8:20 AM, Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
>> AIUI, there is a cost in the minified JS to using constants.
>>
>> However, there is a cost to screwing up the typing of a string literal as
>> well.
>>
>> The best answer for now, IMO, is to not care whether folks use constants
>> or string literals. There are much bigger fish to fry. I don't want to
>> see sweeping changes of replacing all string literals with constants or
>> vice versa. If you've got that kind of time on your hands, learn the
>> compiler code and see if you can make the cross-compiler replace all
>> constants with string literals. IMO, that's the right answer.
>>
>> -Alex
>>
>> On 7/11/17, 5:37 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>>> Here’s what is output in the minimized code:
>>>
>>> function
>>> fqa(){}w('org.apache.flex.net.HTTPConstants.GET','GET');
>> w('org.apache.flex
>>> .net.HTTPConstants.POST','POST');w('org.apache.flex.net.
>> HTTPConstants.PUT'
>>> ,'PUT');w('org.apache.flex.net.HTTPConstants.FORM_URL_
>> ENCODED',Fm);w('org.
>>> apache.flex.net.HTTPConstants.DELETE','DELETE'
>> );w('org.apache.flex.net.HTT
>>> PConstants.OPEN','open');w('org.apache.flex.net.
>> HTTPConstants.COMPLETE',Bt
>>> );w('org.apache.flex.net.HTTPConstants.COMMUNICATION_
>> ERROR',At);w('org.apa
>>> che.flex.net.HTTPConstants.IO_ERROR','ioError');
>>> w('org.apache.flex.net.HTTPConstants.SECURITY_ERROR',
>> 'securityError');w('o
>>> rg.apache.flex.net.HTTPConstants.STATUS',Fx);w('
>> org.apache.flex.net.HTTPCo
>>> nstants.RESPONSE_STATUS','httpResponseStatus');fqa.
>> prototype.h={names:[{na
>>> me:'HTTPConstants',i:IF,kind:g}]};w(IF,fqa);
>>>
>>> elsewhere:
>>> IF='org.apache.flex.net.HTTPConstants’,
>>>
>>> That’s 807 bytes. That’s quite a penalty for avoiding typing “POST”…
>>>
>>> No idea what wiki you are referring to.
>>>
>>> Harbs
>>>
>>>> On Jul 11, 2017, at 2:36 PM, Justin Mclean <ju...@classsoftware.com>
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>>> As it stands now, use of constants result in more JS code after
>>>>> compiled.
>>>>
>>>> Debug yes but not optimised / release.
>>>>
>>>>> It’s possible that this can be optimized, but currently the most
>>>>> efficient JS code is produced if using string literals rather than
>>>>> constants. (The Google compiler created variables for string literals
>>>>> used more than once.)
>>>>
>>>> That's not we found in a previous thread on this list, the google
>>>> compiler optimises the constants and there is no penalty in using them.
>>>> You mind provide examples that show the above is the actually case and
>>>> document it on the wiki?
>>>>
>>>> My vote would be not the duplicate the strings everywhere and use
>>>> constants as there is no cost and increased safety.
>>>>
>>>> Thanks,
>>>> Justin
>>>
>>
>>
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are
assumed to be POST
Posted by Josh Tynjala <jo...@gmail.com>.
That sounds like the proper way to handle this! We should be able to
reference constants in our ActionScript so that we can get compile-time
errors from typos, while the compiler makes sure that generated JavaScript
can be properly minified.
- Josh
On Tue, Jul 11, 2017 at 8:20 AM, Alex Harui <ah...@adobe.com.invalid>
wrote:
> AIUI, there is a cost in the minified JS to using constants.
>
> However, there is a cost to screwing up the typing of a string literal as
> well.
>
> The best answer for now, IMO, is to not care whether folks use constants
> or string literals. There are much bigger fish to fry. I don't want to
> see sweeping changes of replacing all string literals with constants or
> vice versa. If you've got that kind of time on your hands, learn the
> compiler code and see if you can make the cross-compiler replace all
> constants with string literals. IMO, that's the right answer.
>
> -Alex
>
> On 7/11/17, 5:37 AM, "Harbs" <ha...@gmail.com> wrote:
>
> >Here’s what is output in the minimized code:
> >
> >function
> >fqa(){}w('org.apache.flex.net.HTTPConstants.GET','GET');
> w('org.apache.flex
> >.net.HTTPConstants.POST','POST');w('org.apache.flex.net.
> HTTPConstants.PUT'
> >,'PUT');w('org.apache.flex.net.HTTPConstants.FORM_URL_
> ENCODED',Fm);w('org.
> >apache.flex.net.HTTPConstants.DELETE','DELETE'
> );w('org.apache.flex.net.HTT
> >PConstants.OPEN','open');w('org.apache.flex.net.
> HTTPConstants.COMPLETE',Bt
> >);w('org.apache.flex.net.HTTPConstants.COMMUNICATION_
> ERROR',At);w('org.apa
> >che.flex.net.HTTPConstants.IO_ERROR','ioError');
> >w('org.apache.flex.net.HTTPConstants.SECURITY_ERROR',
> 'securityError');w('o
> >rg.apache.flex.net.HTTPConstants.STATUS',Fx);w('
> org.apache.flex.net.HTTPCo
> >nstants.RESPONSE_STATUS','httpResponseStatus');fqa.
> prototype.h={names:[{na
> >me:'HTTPConstants',i:IF,kind:g}]};w(IF,fqa);
> >
> >elsewhere:
> >IF='org.apache.flex.net.HTTPConstants’,
> >
> >That’s 807 bytes. That’s quite a penalty for avoiding typing “POST”…
> >
> >No idea what wiki you are referring to.
> >
> >Harbs
> >
> >> On Jul 11, 2017, at 2:36 PM, Justin Mclean <ju...@classsoftware.com>
> >>wrote:
> >>
> >> Hi,
> >>
> >>> As it stands now, use of constants result in more JS code after
> >>>compiled.
> >>
> >> Debug yes but not optimised / release.
> >>
> >>> It’s possible that this can be optimized, but currently the most
> >>>efficient JS code is produced if using string literals rather than
> >>>constants. (The Google compiler created variables for string literals
> >>>used more than once.)
> >>
> >> That's not we found in a previous thread on this list, the google
> >>compiler optimises the constants and there is no penalty in using them.
> >>You mind provide examples that show the above is the actually case and
> >>document it on the wiki?
> >>
> >> My vote would be not the duplicate the strings everywhere and use
> >>constants as there is no cost and increased safety.
> >>
> >> Thanks,
> >> Justin
> >
>
>
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are
assumed to be POST
Posted by Alex Harui <ah...@adobe.com.INVALID>.
AIUI, there is a cost in the minified JS to using constants.
However, there is a cost to screwing up the typing of a string literal as
well.
The best answer for now, IMO, is to not care whether folks use constants
or string literals. There are much bigger fish to fry. I don't want to
see sweeping changes of replacing all string literals with constants or
vice versa. If you've got that kind of time on your hands, learn the
compiler code and see if you can make the cross-compiler replace all
constants with string literals. IMO, that's the right answer.
-Alex
On 7/11/17, 5:37 AM, "Harbs" <ha...@gmail.com> wrote:
>Here’s what is output in the minimized code:
>
>function
>fqa(){}w('org.apache.flex.net.HTTPConstants.GET','GET');w('org.apache.flex
>.net.HTTPConstants.POST','POST');w('org.apache.flex.net.HTTPConstants.PUT'
>,'PUT');w('org.apache.flex.net.HTTPConstants.FORM_URL_ENCODED',Fm);w('org.
>apache.flex.net.HTTPConstants.DELETE','DELETE');w('org.apache.flex.net.HTT
>PConstants.OPEN','open');w('org.apache.flex.net.HTTPConstants.COMPLETE',Bt
>);w('org.apache.flex.net.HTTPConstants.COMMUNICATION_ERROR',At);w('org.apa
>che.flex.net.HTTPConstants.IO_ERROR','ioError');
>w('org.apache.flex.net.HTTPConstants.SECURITY_ERROR','securityError');w('o
>rg.apache.flex.net.HTTPConstants.STATUS',Fx);w('org.apache.flex.net.HTTPCo
>nstants.RESPONSE_STATUS','httpResponseStatus');fqa.prototype.h={names:[{na
>me:'HTTPConstants',i:IF,kind:g}]};w(IF,fqa);
>
>elsewhere:
>IF='org.apache.flex.net.HTTPConstants’,
>
>That’s 807 bytes. That’s quite a penalty for avoiding typing “POST”…
>
>No idea what wiki you are referring to.
>
>Harbs
>
>> On Jul 11, 2017, at 2:36 PM, Justin Mclean <ju...@classsoftware.com>
>>wrote:
>>
>> Hi,
>>
>>> As it stands now, use of constants result in more JS code after
>>>compiled.
>>
>> Debug yes but not optimised / release.
>>
>>> It’s possible that this can be optimized, but currently the most
>>>efficient JS code is produced if using string literals rather than
>>>constants. (The Google compiler created variables for string literals
>>>used more than once.)
>>
>> That's not we found in a previous thread on this list, the google
>>compiler optimises the constants and there is no penalty in using them.
>>You mind provide examples that show the above is the actually case and
>>document it on the wiki?
>>
>> My vote would be not the duplicate the strings everywhere and use
>>constants as there is no cost and increased safety.
>>
>> Thanks,
>> Justin
>
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST
Posted by Harbs <ha...@gmail.com>.
Here’s what is output in the minimized code:
function fqa(){}w('org.apache.flex.net.HTTPConstants.GET','GET');w('org.apache.flex.net.HTTPConstants.POST','POST');w('org.apache.flex.net.HTTPConstants.PUT','PUT');w('org.apache.flex.net.HTTPConstants.FORM_URL_ENCODED',Fm);w('org.apache.flex.net.HTTPConstants.DELETE','DELETE');w('org.apache.flex.net.HTTPConstants.OPEN','open');w('org.apache.flex.net.HTTPConstants.COMPLETE',Bt);w('org.apache.flex.net.HTTPConstants.COMMUNICATION_ERROR',At);w('org.apache.flex.net.HTTPConstants.IO_ERROR','ioError');
w('org.apache.flex.net.HTTPConstants.SECURITY_ERROR','securityError');w('org.apache.flex.net.HTTPConstants.STATUS',Fx);w('org.apache.flex.net.HTTPConstants.RESPONSE_STATUS','httpResponseStatus');fqa.prototype.h={names:[{name:'HTTPConstants',i:IF,kind:g}]};w(IF,fqa);
elsewhere:
IF='org.apache.flex.net.HTTPConstants’,
That’s 807 bytes. That’s quite a penalty for avoiding typing “POST”…
No idea what wiki you are referring to.
Harbs
> On Jul 11, 2017, at 2:36 PM, Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
>> As it stands now, use of constants result in more JS code after compiled.
>
> Debug yes but not optimised / release.
>
>> It’s possible that this can be optimized, but currently the most efficient JS code is produced if using string literals rather than constants. (The Google compiler created variables for string literals used more than once.)
>
> That's not we found in a previous thread on this list, the google compiler optimises the constants and there is no penalty in using them. You mind provide examples that show the above is the actually case and document it on the wiki?
>
> My vote would be not the duplicate the strings everywhere and use constants as there is no cost and increased safety.
>
> Thanks,
> Justin
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are
assumed to be POST
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> As it stands now, use of constants result in more JS code after compiled.
Debug yes but not optimised / release.
> It’s possible that this can be optimized, but currently the most efficient JS code is produced if using string literals rather than constants. (The Google compiler created variables for string literals used more than once.)
That's not we found in a previous thread on this list, the google compiler optimises the constants and there is no penalty in using them. You mind provide examples that show the above is the actually case and document it on the wiki?
My vote would be not the duplicate the strings everywhere and use constants as there is no cost and increased safety.
Thanks,
Justin
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are
assumed to be POST
Posted by piotrz <pi...@gmail.com>.
Thanks for explanation. I will try to be careful in usage. I think this
natural move to use constant is more from AS3 world than JS :)
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Re-git-commit-flex-asjs-refs-heads-develop-Uploads-are-assumed-to-be-POST-tp63070p63082.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST
Posted by Harbs <ha...@gmail.com>.
This is worthy of a discussion.
As it stands now, use of constants result in more JS code after compiled. It’s possible that this can be optimized, but currently the most efficient JS code is produced if using string literals rather than constants. (The Google compiler created variables for string literals used more than once.)
My preference would be to try to stick to string literals in Framework code. This has two advantages:
1. There’s no calls to constants in the compiled code so we save bytes.
2. The constant classes are not required, so they are not included in the compiled code unless client code uses them.
As long as we’re careful to use the correct strings, this should not be an issue. If the strings are complex and/or subject to change, then they should be declared once and constants should be used. Otherwise, I think the advantages of using string literals outweigh the “correctness” of using constants.
Thanks,
Harbs
> On Jul 11, 2017, at 11:46 AM, piotrz <pi...@gmail.com> wrote:
>
> I just think that we should use const whenever we can, but won't fight for
> that if no one think similar. :) If I found such code around my interest my
> natural move would be change it :)
>
> Piotr
>
>
>
> -----
> Apache Flex PMC
> piotrzarzycki21@gmail.com
> --
> View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Re-git-commit-flex-asjs-refs-heads-develop-Uploads-are-assumed-to-be-POST-tp63070p63078.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
RE: git commit: [flex-asjs] [refs/heads/develop] - Uploads are
assumed to be POST
Posted by piotrz <pi...@gmail.com>.
I just think that we should use const whenever we can, but won't fight for
that if no one think similar. :) If I found such code around my interest my
natural move would be change it :)
Piotr
-----
Apache Flex PMC
piotrzarzycki21@gmail.com
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Re-git-commit-flex-asjs-refs-heads-develop-Uploads-are-assumed-to-be-POST-tp63070p63078.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
RE: git commit: [flex-asjs] [refs/heads/develop] - Uploads are
assumed to be POST
Posted by Yishay Weiss <yi...@hotmail.com>.
I was trying to save an extra import. Will wait for more thoughts on this.
From: Piotr Zarzycki<ma...@gmail.com>
Sent: Tuesday, July 11, 2017 11:15 AM
To: dev@flex.apache.org<ma...@flex.apache.org>
Subject: Re: git commit: [flex-asjs] [refs/heads/develop] - Uploads are assumed to be POST
Hi Yishay,
I think you could use constant here -> HTTPConstants.POST
Thanks, Piotr
2017-07-11 10:09 GMT+02:00 <yi...@apache.org>:
> Repository: flex-asjs
> Updated Branches:
> refs/heads/develop cc098932c -> 3b5053f91
>
>
> Uploads are assumed to be POST
>
>
> Project: http://git-wip-us.apache.org/repos/asf/flex-asjs/repo
> Commit: http://git-wip-us.apache.org/repos/asf/flex-asjs/commit/3b5053f9
> Tree: http://git-wip-us.apache.org/repos/asf/flex-asjs/tree/3b5053f9
> Diff: http://git-wip-us.apache.org/repos/asf/flex-asjs/diff/3b5053f9
>
> Branch: refs/heads/develop
> Commit: 3b5053f91f869a7fd4cd1eccf80e696e5171b532
> Parents: cc09893
> Author: DESKTOP-RH4S838\Yishay <yi...@hotmail.com>
> Authored: Tue Jul 11 11:08:32 2017 +0300
> Committer: DESKTOP-RH4S838\Yishay <yi...@hotmail.com>
> Committed: Tue Jul 11 11:08:32 2017 +0300
>
> ----------------------------------------------------------------------
> .../src/main/flex/org/apache/flex/file/beads/FileUploader.as | 1 +
> 1 file changed, 1 insertion(+)
> ----------------------------------------------------------------------
>
>
> http://git-wip-us.apache.org/repos/asf/flex-asjs/blob/
> 3b5053f9/frameworks/projects/Network/src/main/flex/org/
> apache/flex/file/beads/FileUploader.as
> ----------------------------------------------------------------------
> diff --git a/frameworks/projects/Network/src/main/flex/org/apache/flex/file/beads/FileUploader.as
> b/frameworks/projects/Network/src/main/flex/org/apache/flex/
> file/beads/FileUploader.as
> index e9aad3c..194a1d6 100644
> --- a/frameworks/projects/Network/src/main/flex/org/apache/flex/
> file/beads/FileUploader.as
> +++ b/frameworks/projects/Network/src/main/flex/org/apache/flex/
> file/beads/FileUploader.as
> @@ -80,6 +80,7 @@ package org.apache.flex.file.beads
> // }
> var binaryUploader:URLBinaryLoader = new
> URLBinaryLoader();
> var req:URLRequest = new URLRequest();
> + req.method = "POST";
> req.data = (host.model as FileModel).blob;
> req.url = url;
> binaryUploader.addEventListener(Event.COMPLETE,
> completeHandler);
>
>