Re: compc compiler error

[Alex Harui]

I would expect that there are a bunch of threads all waiting on each other.  
JSTarget is the entry point to creating all of these threads (one per source 
file, including already compiled files from SWCs).   IIRC, the last person who 
had this problem was able to take a bunch of his classes out of the set being 
compiled for a  SWC and found that the compilation then completed (with few 
enough errors to generate a useful API report).  Apparently some of those files 
were resulting in the deadlock.  Which ones we won't know until we get more 
verbose output.

HTH,
-Alex

On 7/20/18, 5:56 PM, "bhau"  wrote:

It is hanging in Target class (workSet.size never gets to count 0) to find
dependencies.
May be I am missing something here. Do I have to remove all adobe class
dependencies in my module source classes before running compc command ? 

Thanks,
--Bhau



--
Sent from: 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2Fdata=02%7C01%7Caharui%40adobe.com%7C2e3d100eb6d54fbcf43308d5eea4c86a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636677313854887793sdata=H83WyP4bKg31fDds2TrLUJJ6rsu5ygcXd8pOKxp1AxQ%3Dreserved=0

Re: compc compiler error

[bhau]

It is hanging in Target class (workSet.size never gets to count 0) to find
dependencies.
May be I am missing something here. Do I have to remove all adobe class
dependencies in my module source classes before running compc command ? 

Thanks,
--Bhau



--
Sent from: http://apache-royale-development.20373.n8.nabble.com/

Re: compc compiler error

[Alex Harui]

Hi,

Other folks have said that compc is hanging for them as well.  I hope to try to 
get more verbose output into the compiler next week.  As a workaround, try 
removing some classes from the set of files being compiled.

I'm pretty sure the issue is not cyclic dependencies as much as it is how the 
threads in the compiler can deadlock in certain scenarios  I already fixed one 
bug like that.  There is probably at least another one out there.  The compiler 
appears to be using a single mechanism at all places that aren't threadsafe 
which doesn't seem very wise to me.

HTH,
-Alex

On 7/20/18, 1:24 PM, "bhau"  wrote:

I am able to generate api-report. But compc is hanging forever. After 
digging
more, it seems cyclic dependencies might cause this problem. Is there any
option to ignore cyclic dependencies ?

Thanks,
--Bhau



--
Sent from: 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2Fdata=02%7C01%7Caharui%40adobe.com%7C0aecdc139a2a40c0bebd08d5ee7ebfd1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636677150509665072sdata=TG266q6sDKitxf%2FwW%2Fgl%2B7FmC8s9SWrBkIED%2Bj5JlDY%3Dreserved=0

Re: compc compiler error

[bhau]

I am able to generate api-report. But compc is hanging forever. After digging
more, it seems cyclic dependencies might cause this problem. Is there any
option to ignore cyclic dependencies ?

Thanks,
--Bhau



--
Sent from: http://apache-royale-development.20373.n8.nabble.com/

RE: Query on Royale dependency generation

[Frost, Andrew]

Yes good point: so to protect ourselves it might be that we need to try to 
mimic what the avmplus does and just call a 'class initialiser' method to set 
up all the static properties, when the class is first referenced. Although I'm 
not sure whether we can detect from JavaScript when the class is first 
referenced..?!

In terms of trying to make the dependency emitter a little more clever: aren't 
we always going to face problems if there really are two classes that have a 
reference to each other? So a real circular reference that can't be resolved? 
Maybe this isn't so common in real life... I guess if it doesn't yet know that 
it's emitting a static initializer then yes there's a more basic issue to 
address!

thanks

   Andrew


-Original Message-
From: Alex Harui [mailto:aha...@adobe.com.INVALID] 
Sent: 20 July 2018 15:55
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Query on Royale dependency generation

Personally, I'm not convinced the problem is truly different in SWF vs JS, 
other than that in JS, the google closure compiler and 
goog.provides/requires/addDependency don't really let you specify the 
difference between static and non-static initializer dependencies.  I think you 
may have seen that when you played with the "verifyAll" setting.

The main difference, AIUI, is that the Flash runtime only initializes the 
statics on a class when first used instead of when loaded.  JS initializes all 
statics when loaded.  But I think that the order in many cases still matters in 
the SWF.  I see code in the SWF output section of the compiler that figures out 
the order of classes to output into the SWF.  There is a DependencyGraph that 
is managed by the compiler.  It is possible that the problem is simply a matter 
of translating that SWF order into the goog.provides/requires/addDependency.

I think that at Emitter time, we can know that we are initializing a static 
initializer and can record that information in the output for use in 
GoogDepsWriter.

I worry that the workaround in #2 may not always work.  The workaround changes 
when the initializer runs, but I wonder if there will be scenarios where the 
initializers are still going to be needed "early".

Whether we do #2 or #3, the Emitter logic still needs to detect that it is 
outputting a static initializer.  So it isn't clear that it is worth the 
overhead of outputting different code vs just leaving more data for 
GoogDepsWriter.

My 2 cents,
-Alex

On 7/20/18, 6:49 AM, "Frost, Andrew"  wrote:

Hi guys

Thanks for the details. Harbs, I see what you mean now, and yes I can work 
around it in the source code by changing how the variable is initialised.

I guess circular dependencies are a little tricky from a JavaScript 
perspective! It's easier in ActionScript due to the way the player sets things 
up (although when we tried the "verifyAll" setting in avmplus, we ran into 
similar problems with some SWCs...)

In terms of the options, I guess my preference would be '2', where the 
static initialisers are output using the pattern that Harbs suggests. For now I 
can switch to that pattern manually, but I can add that idea to the list of 
things to investigate when we have more time..


thanks

   Andrew




-Original Message-
From: Alex Harui [mailto:aha...@adobe.com.INVALID] 
Sent: 19 July 2018 18:04
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Query on Royale dependency generation

For sure, there are probably still bugs in the remove-circulars 
calculation.  But, before debugging these problems, make sure you remove the 
entire bin/js-debug folder.  The JS files in there are modified by the 
dependency management code and could get stale.

The fundamental problem is that goog.provides, goog.requires, and 
goog.addDependency result in 

Re: Migrating Enterprise Flex Application

[Alex Harui]

The process of building your application in Royale should be the same as in 
Flex.  You should be able to build the SWCs in the same order.  I don't think 
we have anyone trying to use Gradle right now, but I think it should work, and 
I would be interested in making it work if it doesn't.  So try Gradle and tell 
us what errors you run into and we'll see what needs to be tweaked.

Royale's COMPC will build a SWC that contains both a library.swf (for the 
compiler to understand what classes are in the SWC) and a pile of JS files.  
Those SWCs are used just like Flex SWCs and at the end, when you use MXMLC to 
build the main app, all of the JS files packaged in the SWCs will be added to 
the output JS.

HTH,
-Alex

On 7/20/18, 2:00 AM, "chembali"  wrote:

My application consists of a number of components. Each of these components
has got a UI portion which is in Flex. For e.g I have got components like
FlexUIPlatform, Directory, ProcessModel etc. Here FlexUIPlatform is the
lowest in the hierarchy and does not have any dependency on other components
for building. Directory component uses FlexUIPlatform and has a dependency
on FlexUIPlatform for component build. Our current build process ( Gradle )
builds the FlexUIPlatform first using the compc compiler and creates the
.swc library. This swc library is used in the build of the Directory
component. The build process generates the Directory.swc library. The
FlexUIPlatform.swc and Directory.swc are used in the build of the
ProcessModel component and so on. 

Now my goal is to get my application ( all components ) compiled in the
Royale environment. Here is my question. Should I try to use Royale compc
and compile my components one by one? Would this create a swc library (
containing .js classes? ) if successful? Can I use/link the generated swc
during the building of the higher level component? I hope my questions make
sense.



--
Sent from: 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2Fdata=02%7C01%7Caharui%40adobe.com%7Cdcddc35d449f4ca4d47a08d5ee1f4bf1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636676740543817299sdata=F2tfg3Dclz4hVndvCq8sr9ifQE7Ih2JFfDaamQA6eeM%3Dreserved=0

Re: Query on Royale dependency generation

[Alex Harui]

Personally, I'm not convinced the problem is truly different in SWF vs JS, 
other than that in JS, the google closure compiler and 
goog.provides/requires/addDependency don't really let you specify the 
difference between static and non-static initializer dependencies.  I think you 
may have seen that when you played with the "verifyAll" setting.

The main difference, AIUI, is that the Flash runtime only initializes the 
statics on a class when first used instead of when loaded.  JS initializes all 
statics when loaded.  But I think that the order in many cases still matters in 
the SWF.  I see code in the SWF output section of the compiler that figures out 
the order of classes to output into the SWF.  There is a DependencyGraph that 
is managed by the compiler.  It is possible that the problem is simply a matter 
of translating that SWF order into the goog.provides/requires/addDependency.

I think that at Emitter time, we can know that we are initializing a static 
initializer and can record that information in the output for use in 
GoogDepsWriter.

I worry that the workaround in #2 may not always work.  The workaround changes 
when the initializer runs, but I wonder if there will be scenarios where the 
initializers are still going to be needed "early".

Whether we do #2 or #3, the Emitter logic still needs to detect that it is 
outputting a static initializer.  So it isn't clear that it is worth the 
overhead of outputting different code vs just leaving more data for 
GoogDepsWriter.

My 2 cents,
-Alex

On 7/20/18, 6:49 AM, "Frost, Andrew"  wrote:

Hi guys

Thanks for the details. Harbs, I see what you mean now, and yes I can work 
around it in the source code by changing how the variable is initialised.

I guess circular dependencies are a little tricky from a JavaScript 
perspective! It's easier in ActionScript due to the way the player sets things 
up (although when we tried the "verifyAll" setting in avmplus, we ran into 
similar problems with some SWCs...)

In terms of the options, I guess my preference would be '2', where the 
static initialisers are output using the pattern that Harbs suggests. For now I 
can switch to that pattern manually, but I can add that idea to the list of 
things to investigate when we have more time..


thanks

   Andrew




-Original Message-
From: Alex Harui [mailto:aha...@adobe.com.INVALID] 
Sent: 19 July 2018 18:04
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Query on Royale dependency generation

For sure, there are probably still bugs in the remove-circulars 
calculation.  But, before debugging these problems, make sure you remove the 
entire bin/js-debug folder.  The JS files in there are modified by the 
dependency management code and could get stale.

The fundamental problem is that goog.provides, goog.requires, and 
goog.addDependency result in 

RE: Query on Royale dependency generation

[Frost, Andrew]

Hi guys

Thanks for the details. Harbs, I see what you mean now, and yes I can work 
around it in the source code by changing how the variable is initialised.

I guess circular dependencies are a little tricky from a JavaScript 
perspective! It's easier in ActionScript due to the way the player sets things 
up (although when we tried the "verifyAll" setting in avmplus, we ran into 
similar problems with some SWCs...)

In terms of the options, I guess my preference would be '2', where the static 
initialisers are output using the pattern that Harbs suggests. For now I can 
switch to that pattern manually, but I can add that idea to the list of things 
to investigate when we have more time..


thanks

   Andrew




-Original Message-
From: Alex Harui [mailto:aha...@adobe.com.INVALID] 
Sent: 19 July 2018 18:04
To: dev@royale.apache.org
Subject: [EXTERNAL] Re: Query on Royale dependency generation

For sure, there are probably still bugs in the remove-circulars calculation.  
But, before debugging these problems, make sure you remove the entire 
bin/js-debug folder.  The JS files in there are modified by the dependency 
management code and could get stale.

The fundamental problem is that goog.provides, goog.requires, and 
goog.addDependency result in 

Re: Migrating Enterprise Flex Application

[chembali]

My application consists of a number of components. Each of these components
has got a UI portion which is in Flex. For e.g I have got components like
FlexUIPlatform, Directory, ProcessModel etc. Here FlexUIPlatform is the
lowest in the hierarchy and does not have any dependency on other components
for building. Directory component uses FlexUIPlatform and has a dependency
on FlexUIPlatform for component build. Our current build process ( Gradle )
builds the FlexUIPlatform first using the compc compiler and creates the
.swc library. This swc library is used in the build of the Directory
component. The build process generates the Directory.swc library. The
FlexUIPlatform.swc and Directory.swc are used in the build of the
ProcessModel component and so on. 

Now my goal is to get my application ( all components ) compiled in the
Royale environment. Here is my question. Should I try to use Royale compc
and compile my components one by one? Would this create a swc library (
containing .js classes? ) if successful? Can I use/link the generated swc
during the building of the higher level component? I hope my questions make
sense.



--
Sent from: http://apache-royale-development.20373.n8.nabble.com/

Re: Bead Docs etc.

[Alex Harui]

To automatically solve that problem, we could try to teach the asdoc emitter to 
try to sniff out the tag in a createElement method.  But otherwise, we could 
add a new ASDoc tag that describes that is injected into the DOM.

My 2 cents,
-Alex

On 7/19/18, 10:36 AM, "Harbs"  wrote:

I think they were looking for “select”. They were trying to use 
intellisense (in VS Code) to find it.

I’m not sure how to solve that problem.


> On Jul 19, 2018, at 8:29 PM, Alex Harui  wrote:
> 
> Ask them where they would have looked for the answers.  IMO, having smart 
searching in ASDoc would have helped.  Type in "dropdown" and see all classes 
with "dropdown" in the name.  Type in "disable" see all classes with "disable" 
in the name.  Could they work on improving the ASDoc app?
> 
> -Alex
> 
> On 7/19/18, 10:20 AM, "Harbs" mailto:harbs.li...@gmail.com>> wrote:
> 
>Problems they’ve run into today:
> 
>Finding a dropdown component.
> 
>Figuring out DisableBead and how to fade (DisabledAlphaBead).
> 
>> Also keep in mind that ASDoc is an app for Royale so we can add more 
asdoc tags and filter and do other visualizations on those tags.
> 
>Yes. I was wondering something along these lines.
> 
>> On Jul 19, 2018, at 8:16 PM, Alex Harui  wrote:
>> 
>> I'm not sure how it can be "self-documenting". Beads can be re-used by 
any strand.  Sometimes it will work, sometimes it won't.  There is no way for 
the bead author to list all strands it is known to work on, nor is the a way 
for a strand to list all beads that will work with it.  You can write up a list 
of what you know at the time, but it will get stale and require lots of energy 
to maintain.  I have the same concern for a list in our docs as well.  I think 
it will get stale and not describe the full range of possibilities.
>> 
>> I feel like you didn't really state the fundamental question.  What 
problem are they actually running into?  IOW, are they really looking for a 
list of assumptions or invariants a bead has?  That might be describable at 
author time.  Could it be discovered by the compiler so that is 
self-documenting?  Not sure about that.  We could list the interface 
dependencies or something like that.
>> 
>> Many folks write code by trial-and-error, and beads were meant to be 
easy to add and remove.  Try it, oops, it doesn't work, try another one.
>> 
>> Also keep in mind that ASDoc is an app for Royale so we can add more 
asdoc tags and filter and do other visualizations on those tags.
>> 
>> My 2 cents,
>> -Alex
>> 
>> On 7/19/18, 5:03 AM, "Harbs" mailto:harbs.li...@gmail.com> >> wrote:
>> 
>>   Well, duh. I forgot about the royal-docs repo… 
>> 
>>   They can just fork that and submit pull requests.
>> 
>>   I do think that we should have some of this self documenting from the 
source code though. I’d like to explore that.
>> 
>>   Thanks!
>>   Harbs
>> 
>>> On Jul 19, 2018, at 2:23 PM, Andrew Wetmore mailto:cottag...@gmail.com>> wrote:
>>> 
>>> Starting a page in the docs project and putting together material would 
be
>>> great. Then we can link it into the published docs when it is ready. I 
am
>>> not sure who grants permissions/access for that.
>>> 
>>> a
>>> 
>>> On Thu, Jul 19, 2018 at 8:14 AM, Harbs mailto:harbs.li...@gmail.com>> wrote:
>>> 
 I just started some folks (my daughter and some friends) on some Royale
 work. They’re still getting into things. Hopefully as they get more 
into
 things, they will be able to contribute.
 
 One of the big things they are struggling with is discovering what
 components there are and what bead can work with which components. If 
I was
 not here to help them, it would be almost impossible to get going. One 
of
 them expressed interest in helping writing documentation for this as 
they
 are learning.
 
 What’s the best way for her to do that? It doesn’t really fit into the
 wiki. I’m not sure how to give her access to the docs.
 
 I think ideally, this should be something that the code self-documents.
 
 Thoughts?
 
 Harbs
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Andrew Wetmore
>>> 
>>> 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcottage14.blogspot.com%2Fdata=02%7C01%7Caharui%40adobe.com%7Cc52ab38bd9d248dd52b608d5ed6f94d4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636675985850576041sdata=ECkPC4lmBreJPnEMhIKIMbJApeHy1eATT5vzoPYkXS8%3Dreserved=0
 

Re: compc compiler error

[Alex Harui]

This document tries to describe how to generate an API report: 
https://github.com/apache/royale-asjs/wiki/Generating-an-API-Report

COMPJSCRoyale is probably the wrong place to be adding verbose output.  There 
is already console output as it writes out each file.  But much earlier in 
"buildApplication" it calls the "build" method on the JSTarget which causes all 
of these threads to be created (one per compilation unit) and these threads are 
probably deadlocking somehow.

If you are using "ant all" from the royale-asjs folder, then it should run the 
copy-compiler task that copies the latest compiler jars into the royale-asjs 
lib and js/lib folders.  And then if you are using the compiler from 
royale-asjs/js/bin it should output that it is using jars from js/lib.

HTH,
-Alex

On 7/19/18, 12:33 PM, "bhau"  wrote:

Other that hanging compilation with compc command, I am trying to generate
api-report and could not find right command for that.
Is there any documentation to generate api-report?

Thanks,
--Bhau



--
Sent from: 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2Fdata=02%7C01%7Caharui%40adobe.com%7C73a837585fe14cb8f87d08d5edae7c49%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636676256023218782sdata=ChV%2FL9pnwf3aLS0HFDGaRihah7r0%2FbuFbMVw3dP8R%2Fo%3Dreserved=0