Re: Re: Package, Class and Method renaming

[vincent]

Bonjour,

En congés jusqu'au 4 septembre, je prendrais connaissance de votre message à 
mon retour.

Cordialement,

Vincent/AFTER24

Re: Package, Class and Method renaming

[Alex Harui]

I'm not sure I understand your proposal, but FWIW, I believe I have found
one way to control renaming of getters and setters.  I just pushed changes
that collect property names used by MXML and data binding.  Those
properties are set as properties on Object.prototype in a custom externs
file and that prevents GCC from renaming those properties in the
getter/setter structures for Object.defineProperties.

So, we could do more experiments with turning off @export for more SWCs
and see if we can tell when we need to prevent their renaming and generate
the fake externs to prevent their renaming, but I'm about to see if I can
get a true non-unloadable module to work and it will need the thing that
loads the module to not have renamed variables.

Anyway, these changes should allow any getters and setters that aren't
used by MXML and data binding to be renamed.  So see if that causes
sufficient obfuscation for you.  And then see if it actually runs.  I was
sure I'd seen that references from non-getter/setters to getters were
sometimes being given different names, but maybe that is no longer true
now that the actual code for getters and setters are all in prototype
methods.

HTH,
Alex

On 8/10/17, 10:03 AM, "Harbs"  wrote:

>Is there some way we can declare MXML differently so GCC can know that
>we’re using properties? Maybe instead of strings we can use object
>literals with proper references?
>
>> On Aug 10, 2017, at 6:39 PM, Alex Harui 
>>wrote:
>> 
>> FWIW, I found out that some of that savings is because when something no
>> longer has @export, it is eligible for dead code removal.  That's sort
>>of
>> good, except that GCC's dead code removal can't detect usage from MXML
>>and
>> data binding so it removed stuff it shouldn't.  The main SWCs may have
>>to
>> always export everything for cross-module usage.
>> 
>> Of course, I could be wrong...
>> -Alex
>> 
>> On 8/10/17, 1:45 AM, "Harbs"  wrote:
>> 
>>> For kicks I tried modifying the compiler to not emit @export for my
>>>code
>>> (it still has the @exports for SDK code).
>>> 
>>> The result on code size was more than 50KB smaller AFTER gzipping.
>>>That’s
>>> a reduction of more than 10%. Pretty significant. That’s without any
>>> class renaming.
>>> 
>>> Anyway, it blew up my app on properties that were used in data binding
>>>in
>>> MXML. I didn’t fix that to see the next place it blew up.
>>> 
>>> If we go this route, we probably need to make MXML output smarter…
>>> 
 On Aug 10, 2017, at 12:31 AM, Alex Harui 
 wrote:
 
 I've seen GCC not track renames before.  The Object.defineProperty is
 just
 a data structure and doesn't add to the set of APIs for a class
 definition.
 
 I just realized that the class names are used by SimpleCSSValuesImpl
to
 determine the type selectors.  So if you rename those strings you will
 have to change your CSS.
 
 Also, I have not removed the exportSymbol calls on each class yet.  I
 will
 try that as well.
 
 -Alex
 
 
 On 8/9/17, 2:11 PM, "Harbs"  wrote:
 
> 
>> On Aug 9, 2017, at 11:56 PM, Alex Harui 
>> wrote:
>> 
>> The change I just made should only be for MXML.  But I think I saw
>> that
>> I
>> never did remove the @export for getters and setters in AS.
>>However,
>> doing so would probably break MXML setting of those properties.
>> 
>> I don't think you can tell when compiling a SWC which properties
>> someone
>> is going to use from MXML, so I'm not sure passing through @export
>>or
>> somehow marking certain APIs as "don't rename" is going to be
>>useful.
> 
> It would be useful for client code because I do know which properties
> my
> MXML will use.
> 
>> On
>> the other hand, MXML does know every property that you accessed from
>> MXML
>> so maybe that's what I'll try next.  I think I see an API in GCC
>>where
>> you
>> can tell it things that shouldn't be renamed.
> 
> That sounds interesting.
> 
>> IMO, this is a bug or missing capability in GCC.  They don't see
>> Object.defineProperties as part of the class definition so they
>>don't
>> track the renames properly.  So, removing @exports from getters in
>>AS
>> may
>> also just fail in calls from other AS classes.
> 
> I lost you. Where did you see that GCC doesn’t track the definitions?
> 
>> Regarding obfuscation, if we have to export getters, is that really
>> exposing important secrets?
> 
> Not sure, but I’d like to keep the code as difficult to follow as
> possible.
> 
>> The actual code for a getter/setter is
>> elsewhere in the output file.  It might be possible to do string
>> replacement on the exported names after 

Re: [FlexJS][Docs] Started with some docs using a github repo

[Olaf Krueger]

>Go for it! :-)

Done! [1]
Looking forward to following the steps by myself.
If I'll be successful I'll add a working FlexJS example to the wiki.

Olaf

[1]
https://github.com/ok-at-github/flexjs-docs/wiki/Adapting-HTML-CSS-JS-project




--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-Docs-Started-with-some-docs-using-a-github-repo-tp63786p63818.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS][Docs] Started with some docs using a github repo

[Olaf Krueger]

Forget about this:

>The advantage of MXML is that we can declare both JS code and the CSS in
the same file.

I think you mean AS instead of JS?!

Thanks,
Olaf



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-Docs-Started-with-some-docs-using-a-github-repo-tp63786p63819.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: FlexJS more problematic CSS

[Harbs]

Bingo. I didn’t know what namespace could work.

I’ll change the tutorial.

> On Aug 11, 2017, at 5:51 PM, Alex Harui  wrote:
> 
> First thing to try is to provide a namespace for all type selectors.
> 
>  @namespace "http://www.w3.org/1999/xhtml;;
> 
> Must be used for all native HTML elements.
> 
> HTH,
> -Alex 
> 
> On 8/11/17, 6:20 AM, "Harbs"  wrote:
> 
>> The CSS in my tutorial here[1] does not compile inside a fx:Style block.
>> 
>> Can one of our compiler gurus take a look at that? ;-)
>> 
>> Harbs
>> 
>> [1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.g
>> oogle.com%2Fdocument%2Fd%2F1pW599xo-Icys-xXEeNi6tbTcH-iMepbTR6WcviLy7i8%2F
>> edit%23heading%3Dh.un4iqbgnan3b=02%7C01%7C%7C1406dc634e344d8b6c3808d4
>> e0bbb902%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636380544255831241
>> data=yL9%2F9V5lDoHxutNIHVu9DjlNBvGL%2FDvkmONO4d89CE4%3D=0
>> > gle.com%2Fdocument%2Fd%2F1pW599xo-Icys-xXEeNi6tbTcH-iMepbTR6WcviLy7i8%2Fed
>> it%23heading%3Dh.un4iqbgnan3b=02%7C01%7C%7C1406dc634e344d8b6c3808d4e0
>> bbb902%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636380544255831241
>> ta=yL9%2F9V5lDoHxutNIHVu9DjlNBvGL%2FDvkmONO4d89CE4%3D=0>
> 

Re: FlexJS more problematic CSS

[Alex Harui]

First thing to try is to provide a namespace for all type selectors.

  @namespace "http://www.w3.org/1999/xhtml;;

Must be used for all native HTML elements.

HTH,
-Alex 

On 8/11/17, 6:20 AM, "Harbs"  wrote:

>The CSS in my tutorial here[1] does not compile inside a fx:Style block.
>
>Can one of our compiler gurus take a look at that? ;-)
>
>Harbs
>
>[1]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.g
>oogle.com%2Fdocument%2Fd%2F1pW599xo-Icys-xXEeNi6tbTcH-iMepbTR6WcviLy7i8%2F
>edit%23heading%3Dh.un4iqbgnan3b=02%7C01%7C%7C1406dc634e344d8b6c3808d4
>e0bbb902%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636380544255831241
>data=yL9%2F9V5lDoHxutNIHVu9DjlNBvGL%2FDvkmONO4d89CE4%3D=0
>gle.com%2Fdocument%2Fd%2F1pW599xo-Icys-xXEeNi6tbTcH-iMepbTR6WcviLy7i8%2Fed
>it%23heading%3Dh.un4iqbgnan3b=02%7C01%7C%7C1406dc634e344d8b6c3808d4e0
>bbb902%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636380544255831241
>ta=yL9%2F9V5lDoHxutNIHVu9DjlNBvGL%2FDvkmONO4d89CE4%3D=0>

Re: FlexJS more problematic CSS

[Olaf Krueger]

This is also really helpful!! 
I will try it out by myself and will add it to the docs!

Thanks,
Olaf



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-more-problematic-CSS-tp63810p63814.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: FlexJS more problematic CSS

[Harbs]

Yes. I have a css file in src/assets/defaults.css.

The css file is copied to bin/js-debug and bin/js-release when I compile.

In src/resources/template.html I have in the header:
http://apache-flex-development.247.n4.nabble.com/FlexJS-more-problematic-CSS-tp63810p63812.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: FlexJS more problematic CSS

[Olaf Krueger]

>To work around bugs in the compiler (which get fixed as they are
discovered), I have a separate CSS file >that I include with my app which
contains CSS that has trouble being compiled.

Just to make sure that I understand it right:

Does that mean, that it works if we just outsource the CSS that doesn't
compile into a separate file instead 
of embedding it in mxml?

Thanks,
Olaf





--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-more-problematic-CSS-tp63810p63812.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

FlexJS more problematic CSS

[Harbs]

The CSS in my tutorial here[1] does not compile inside a fx:Style block.

Can one of our compiler gurus take a look at that? ;-)

Harbs

[1]https://docs.google.com/document/d/1pW599xo-Icys-xXEeNi6tbTcH-iMepbTR6WcviLy7i8/edit#heading=h.un4iqbgnan3b
 

Re: FlexJS more problematic CSS

[vincent]

Bonjour,

En congés jusqu'au 4 septembre, je prendrais connaissance de votre message à 
mon retour.

Cordialement,

Vincent/AFTER24

Re: [FlexJS][Docs] Started with some docs using a github repo

[Harbs]

Go for it! :-)

> On Aug 11, 2017, at 3:26 PM, Olaf Krueger  wrote:
> 
> This is an awesome tutorial, thanks Harbs!
> Hope I'll have some time to follow these steps by myself.
> 
> However, if I'll get your permission I will definitely help to put in on the
> github wiki.
> 
> Maybe we're also able to build a working example including a live demo... 
> 
> Thanks,
> Olaf
> 
> 
> 
> --
> View this message in context: 
> http://apache-flex-development.247.n4.nabble.com/FlexJS-Docs-Started-with-some-docs-using-a-github-repo-tp63786p63808.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS][Docs] Started with some docs using a github repo

[Olaf Krueger]

This is an awesome tutorial, thanks Harbs!
Hope I'll have some time to follow these steps by myself.

However, if I'll get your permission I will definitely help to put in on the
github wiki.

Maybe we're also able to build a working example including a live demo... 

Thanks,
Olaf



--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-Docs-Started-with-some-docs-using-a-github-repo-tp63786p63808.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS][Docs] Started with some docs using a github repo

[Harbs]

Let’s just focus on getting documentation written for now. It can always be 
re-organized later.

I just wrote what I think is a useful tutorial on using random HTML/CSS/JS. 
This should probably be included somehow…

https://docs.google.com/document/d/1pW599xo-Icys-xXEeNi6tbTcH-iMepbTR6WcviLy7i8/edit?usp=sharing
 


> On Aug 11, 2017, at 9:55 AM, piotrz  wrote:
> 
> Olaf,
> 
> I have in my head that we should some day create such website using FlexJS,
> but it would require some longer time.
> 
> Focusing on your documentation idea is the better one for now. I hope when
> it will be full we could automatically somehow generate some website and
> push to Apache everything. :)
> 
> Thanks,
> Piotr
> 
> 
> 
> -
> Apache Flex PMC
> piotrzarzyck...@gmail.com
> --
> View this message in context: 
> http://apache-flex-development.247.n4.nabble.com/FlexJS-Docs-Started-with-some-docs-using-a-github-repo-tp63786p63806.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS][Docs] Started with some docs using a github repo

[piotrz]

Olaf,

I have in my head that we should some day create such website using FlexJS,
but it would require some longer time.

Focusing on your documentation idea is the better one for now. I hope when
it will be full we could automatically somehow generate some website and
push to Apache everything. :)

Thanks,
Piotr



-
Apache Flex PMC
piotrzarzyck...@gmail.com
--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-Docs-Started-with-some-docs-using-a-github-repo-tp63786p63806.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.

Re: [FlexJS][Docs] Started with some docs using a github repo

[Olaf Krueger]

Nicholas Kwiatkowski-2 wrote
> The current site is actually managed by a static-site generator using
> markdown.

What do you think about creating a site that is dedicated to FlexJS?

@Piotr
I've started to put some docs together for the mdl:badge bead. [1]
It's not complete and only a first shot.
Maybe we found some better pattern.
But I think we should find one documentation pattern that we could apply to
all other beads and components that fit for all component sets in the same
way.
I also don't know if it's a good idea to do the documentation of properties
manually... but we have to start with something.

Thanks,
Olaf 

[1] 
https://github.com/ok-at-github/flexjs-docs/wiki/MDL-Badges





--
View this message in context: 
http://apache-flex-development.247.n4.nabble.com/FlexJS-Docs-Started-with-some-docs-using-a-github-repo-tp63786p63805.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.