royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com.INVALID>
Subject Re: Royale Compiler Brings Wrong Dependencies
Date Sun, 14 Oct 2018 21:43:42 GMT
This is a different issue.

-Alex

On 10/14/18, 2:38 PM, "Carlos Rovira" <carlosrovira@apache.org> wrote:

    Hi,
    
    That's why some months ago wanted to make Jewel not dependent of anything
    that is not needed and removed Basic from its dependency list. Although now
    Basic is again a dependency, I take care of no load anything from Basic,
    but UIBase that was carried again to Basic. I'm totally to add only
    dependencies that are needed. I just useless to have linked coded that
    you'll never will use, I prefer to add it when required. This not only is
    good for the weight of your app, the performance and the compiler memory
    and performance, but as well makes you avoid problems when create code
    since you can miss to remove some dependency from a library that you really
    don't want to use. For example, If I create a new component in Jewel from a
    component in Basic, if I don't link Basic, I'll get the error that some
    part is missing, and I'll need to create the piece for Jewel, or can choose
    to reuse the Basic one if it will not change by design at some time.
    
    Hope this issue helps to clear my position about trying to separate as much
    as possible and left users pick up what they really need.
    
    thanks
    
    Carlos
    
    
    
    El dom., 14 oct. 2018 a las 19:55, Alex Harui (<aharui@adobe.com.invalid>)
    escribió:
    
    > Subclasses just to get around this problem adds weight.  It doesn't matter
    > so much for MXRoyale, but IMO this sort of thing may crop up elsewhere.
    >  We might need to provide finer-grain control over dependencies in
    > general.  To me, the base problem is that we pile every SWC into the
    > library-path.  That really won't scale, IMO.  Imagine if there were 100
    > SWCs to load for every compile.  It would push the limits on compiler
    > memory and resolving identifiers and probably push the limits on
    > code-hinting in IDEs.
    >
    > So, if we have 100 swcs and potential CSS collisions, maybe we should
    > organize them in some way other than one single folder.  I think the
    > -library-path doesn't search subfolders, so we could group certain kinds of
    > SWCs in subfolders and have different -config.xml files that have different
    > default -library-paths.
    >
    > For that matter, we could be explicit about the SWCs in the library-path
    > in different -config.xml files.  Either royale-config.xml would not
    > reference MXRoyale or it would and we would have a basic-config.xml that
    > doesn't.
    >
    > The compiler lets you add to the library-path with +=.  I don't know if it
    > supports -= or what it would take to get that to work.
    >
    > Lots of choices.  The simplest one is to be explicit in the -config.xml
    > files.
    >
    > My 2 cents,
    > -Alex
    >
    > On 10/14/18, 10:31 AM, "Harbs" <harbs.lists@gmail.com> wrote:
    >
    >     That’s problematic. I look at it that it’s a limitation that you have
    > to declare the dependencies in Maven. I’d rather that everything should
    > just be available.
    >
    >     What about subclassing the basic classes in MXRoyale so we don’t need
    > to declare new CSS dependencies for Basic components there?
    >
    >     > On Oct 14, 2018, at 7:26 PM, Alex Harui <aharui@adobe.com.INVALID>
    > wrote:
    >     >
    >     > Ah yes, I hadn't thought about that.  Folks only using Basic should
    > probably find a way to not include MXRoyale and SparkRoyale on the
    > library-paths.
    >     >
    >     > So I think some chocies are:
    >     > -Delete the MXRoyale and SparkRoyale swcs from frameworks/libs and
    > frameworks/js/libs.
    >     > -Explicitly list which SWCs you want in your app.
    >     >
    >     > IMO, as Royale picks up more and more component sets, folks will
    > have to be more explicit about their SWC dependencies.  That's one thing
    > Maven is better at.
    >     >
    >     > -Alex
    >     >
    >     > On 10/14/18, 7:33 AM, "Yishay Weiss" <yishayjobs@hotmail.com
    > <mailto:yishayjobs@hotmail.com>> wrote:
    >     >
    >     >    Same result.
    >     >
    >     >
    >     >
    >     >    ________________________________
    >     >    From: Piotr Zarzycki <piotrzarzycki21@gmail.com>
    >     >    Sent: Sunday, October 14, 2018 4:51:56 PM
    >     >    To: dev@royale.apache.org
    >     >    Subject: Re: Royale Compiler Brings Wrong Dependencies
    >     >
    >     >    Maybe you should try point to the theme from Basic.
    >     >
    >     >    On Sun, Oct 14, 2018, 1:09 PM Yishay Weiss <
    > yishayjobs@hotmail.com> wrote:
    >     >
    >     >> No. We’re running the compiler-jx project with the following
    > arguments:
    >     >>
    >     >>
    >     >>
    >     >> +royalelib="C:\dev\flexjs\royale-asjs\frameworks"
    >     >>
    >     >> +configname=royale
    >     >>
    >     >> -debug
    >     >>
    >     >> -closure-lib=C:\dev\goog\closure-library
    >     >>
    >     >>
    >     >>
    > --js-library-path+=C:\Users\Yishay\Documents\printui-flexjs\PortedPrintUI\lib
    >     >>
    >     >>
    >     >>
    > --js-external-library-path+=C:\Users\Yishay\Documents\printui-flexjs\PortedPrintUI\typedefs
    >     >>
    >     >> --remove-circulars=true
    >     >>
    >     >> --html-template=src\resources\mdl-js-index-template.html
    >     >>
    >     >> --js-compiler-option+=--skip_type_inference
    >     >>
    >     >> --targets=JSRoyale
    >     >>
    >     >>
    >     >>
    > C:\Users\Yishay\Documents\printui-flexjs\PortedPrintUI\src\PortedPrintUI.mxml
    >     >>
    >     >>
    >     >>
    >     >> ________________________________
    >     >> From: Piotr Zarzycki <piotrzarzycki21@gmail.com>
    >     >> Sent: Sunday, October 14, 2018 12:41:41 PM
    >     >> To: dev@royale.apache.org
    >     >> Subject: Re: Royale Compiler Brings Wrong Dependencies
    >     >>
    >     >> Hi Yishay,
    >     >>
    >     >> Do you load during the build -theme?
    >     >>
    >     >> Piotr
    >     >>
    >     >> On Sun, Oct 14, 2018, 9:45 AM Yishay Weiss <yishayjobs@hotmail.com>
    > wrote:
    >     >>
    >     >>> Hi,
    >     >>>
    >     >>> We’re seeing a bug where beads from MXRoyale are loaded even
    > though the
    >     >>> project doesn’t reference MXRoyale. This results in a runtime
    > error when
    >     >>> opening a ComboBox.
    >     >>>
    >     >>> Specifically, it looks like these lines
    >     >>>
    >     >>> Basic|ComboBoxList
    >     >>> {
    >     >>>        IDataProviderItemRendererMapper:
    >     >>>
    >     >>
    > ClassReference("mx.controls.listClasses.DataItemRendererFactoryForICollectionViewData");
    >     >>>        IBeadModel:
    >     >>>
    >     >>
    > ClassReference("mx.controls.beads.models.SingleSelectionICollectionViewModel");
    >     >>> }
    >     >>>
    >     >>> Are bring read from MXRoyale’s defaults.css, changing the default
    > model
    >     >>> for ComboBoxList. I haven’t been able to reproduce this in a
    > simple [1]
    >     >>> example.
    >     >>>
    >     >>> I spent some time in the compiler trying to figure out what was
    > going on
    >     >>> but no luck so far. What I have noticed is that in
    >     >>> RoyaleJSTarget.findAllCompilationUnitsToLink() the list of found
    >     >>> dependencies includes compilation units I wouldn’t expect to find.
    > For
    >     >>> example, in the simple test [1] I created one of the dependencies
    > has the
    >     >>> AceJS compilation unit.
    >     >>>
    >     >>> Any pointers?
    >     >>>
    >     >>> [1]
    > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FN5As&amp;data=02%7C01%7Caharui%40adobe.com%7Cb4b624361e4b4f21b77b08d6321d61ca%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636751499131018368&amp;sdata=u1RPL4O6d7xtSBPIpDc1vkBo%2BcV935wpFV2mnBSEWTA%3D&amp;reserved=0
    > <
    > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FN5As&amp;data=02%7C01%7Caharui%40adobe.com%7Cb4b624361e4b4f21b77b08d6321d61ca%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636751499131018368&amp;sdata=u1RPL4O6d7xtSBPIpDc1vkBo%2BcV935wpFV2mnBSEWTA%3D&amp;reserved=0
    > >
    >
    >
    >
    
    -- 
    Carlos Rovira
    https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7Cb4b624361e4b4f21b77b08d6321d61ca%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636751499131018368&amp;sdata=Wcc9abvGWfU3HU%2FWYEV9P%2B0w600XBiXdq1n8cMWdNos%3D&amp;reserved=0
    

Mime
View raw message