date:20190718

Re: Concerned about the LGPL dependency in Webkit

2019-07-18 Thread 申远

If there is no other comments here, we will work out to separate
JavaScriptCore.so from the binary of weex_sdk as planned, which is also
weeks of workload. Maybe @ddy199726 shall give us a hand.

Best Regards,
York Shen

申远

在 2019年7月18日，11:22，York Shen  写道：

Just some further information about what @ddy199726 said.

The relationship between weex and JavaScriptCore is similar to the
relationship between any Java Project and JDK.


   - If one want to run a Java program, he/she must have a JDK/JRE to
   interpret Java byte code.
   - If one want to run a Weex program, he/she must have a JavaScript
   interpretator to interpret JavaScript. Here we choose JavaScriptCore.
   - Like any Java program must import some Java Class in the standard
   JDK/JRE, weex has to import the some API (.h file) in JavaScriptCore. All
   those API itself is under BSD License. @ddy199726 and I have doubled
   checked it.
   - The only problem I see here is that JavaScriptCore is inside the
   binary of Weex, which should not happen anymore. We plan to decouple it
   from Weex then users must include weex_sdk and JavaScriptCore together in
   their product.


Best Regards,
York Shen

申远

在 2019年7月17日，15:16，dyy199...@gmail.com 写道：

Hey I'm a developer of incubator-weex

Weex used to use JavaScriptCore's source code directly to execute
JavaScript like this way .


JSValue returnValue = evaluate(globalObject->globalExec(),
makeSource(source, sourceOrigin, url), JSValue(),
evaluationException);

in this case, globalObject is inner object of JavaScriptCore,
And makeSource is inline api of JavaScriptCore.

So Weex has to add all JavaScriptCore's source code to weex'
s repo to make it work normally. There is an function call chain like
Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL.apiD is true at
that time.

But now, Weex has refactoring the way we use JavaScriptCore.
Weex just use JavaScriptCore public api. And All JavaScriptCore source code
has been removed from weex's repo.

We just include JavaScriptCore's publish api only.

So this function chain
Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL.apiD is not
existed now.

Now Function chain is Weex.apiA -> JavaScriptCore.BSD.apiB ->
JavaScriptCore.so

So there is no webkit license and Webkit *.h in weex's repo now

you can checkout the source code from here
https://weex.apache.org/download/download.html#_0-26-0 <
https://weex.apache.org/download/download.html#_0-26-0>
javaScriptCore's api directory is
weex_core/Source/include/JavaScriptCore/API

Weex's logic that use JavaScriptCore's api is here
weex_core/Source/js_runtime

FYI, JavaScriptCore itself is under dual License too, at least Weex include
files under BSD License from JavaScriptCore




在 2019年7月16日，下午6:48，Myrle Krantz  写道：

Hey all,

First of all: congratulations on your recent release!

I wanted to circle back to this to make sure it gets resolved before the
next release.

First a summary of what has happened as I see it.  If my summary is
incorrect, please let me know:
* At some point in the past Weex introduced a run-time and a compile-time
dependency to Webkit.  When adding the Webkit *.h to the repo, the correct
license of those files was accidentally overwritten.
* More recently, this mistake was discovered and a license review of Webkit
as a dependency was made in which it was realized that Webkit:
"As Webkit is under dual license, and it's almost impossible for us to
figure out whether there is an function call chain like
Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL.apiD. I'd like to
know our proposed change is enough to fix the Category X dependency."
(
https://lists.apache.org/thread.html/babe010a7814d4cf3d3d92588bee9dd22277b610daf83733d2622c91@%3Cgeneral.incubator.apache.org%3E
)
* The question of whether Webkit could release like this was raised to the
incubator and then to legal.
* Despite the lack of resolution to this question, Weex was still allowed
to make it's most recent release, because Weex is still in incubation.

While reviewing the release, it became clear to me that Weex is including
WebKit for it's JavaScriptCore.  Within WebKit, JavaScriptCore is
LGPL-licensed.  So it is likely that your functional call chains will
include LGPL-licensed code (after all that's the code you're including
WebKit for).

Is there an alternative implementation of JavaScriptCore that a user could
use in place of the LGPL-licensed portions of WebKit?

Best Regards,
Myrle

Re: [Discuss] Lint rules should be kept or removed

2019-07-18 Thread 王仁敏

Thanks for your advice.

York Shen  于2019年7月19日周五 上午11:52写道：

> I’d like the idea of code lint(C++/OC/Java/etc…) in Travis CI. What’s
> more, you could improve your PR [1] in the following aspect:
>
> Fix the lint issues especially lint errors in before enabling the Lint in
> Travis
> Output the code lint result in Danger and make the Danger failed if there
> is an error lint. I think people rarely read the log of Travis if the build
> successes.
>
> I think the default Android lint is good enough, as for OCLint, maybe
> someone with iOS experienced could give some suggestion.
>
> [1] https://github.com/apache/incubator-weex/pull/2731 <
> https://github.com/apache/incubator-weex/pull/2731>
>
> Best Regards,
> York Shen
>
> 申远
>
> > 在 2019年7月19日，10:11，王仁敏  写道：
> >
> > I think in OCLint, the following rules should be disabled.
> >
> >
> >   - Size 
> >  - HighCyclomaticComplexity
> >  <
> http://docs.oclint.org/en/stable/rules/size.html#highcyclomaticcomplexity>
> >  - LongClass
> >  
> >  - LongLine <
> http://docs.oclint.org/en/stable/rules/size.html#longline>
> >  - LongMethod
> >  
> >  - HighNcssMethod
> >  
> >  - DeepNestedBlock
> >  
> >  - HighNPathComplexity
> >  <
> http://docs.oclint.org/en/stable/rules/size.html#highnpathcomplexity>
> >  - TooManyFields
> >  
> >  - TooManyMethods
> >  
> >  - TooManyParameters
> >   >
> >   - Naming 
> >  - LongVariableName
> >  <
> http://docs.oclint.org/en/stable/rules/naming.html#longvariablename>
> >  - ShortVariableName
> >  <
> http://docs.oclint.org/en/stable/rules/naming.html#shortvariablename>
> >
> >
> > 王仁敏  于2019年7月19日周五 上午9:50写道：
> >
> >> Hi there,
> >>
> >>
> >> I'm trying to add some static lint checks to CI, now OCLint(for c, c++
> >> and objective-c) and AndroidLint already get ready in CI.
> >>
> >> But OCLint and AndroidLint have too many rules, many of which have
> little
> >> impact. so maybe should we discuss about which rules to keep or which
> rules
> >> to remove.
> >>
> >>
> >> OCLint Rule List: http://docs.oclint.org/en/stable/rules/index.html
> >>
> >> AndroidLint Rule List: http://tools.android.com/tips/lint-checks
> >>
> >> AndroidLint Help: http://www.androiddocs.com/tools/help/lint.html
> >>
> >>
> >> The below is the doctest
> >>  reference
> for
> >> OCLint：
> >>
> >> ```
> >>
> >> -disable-rule=ShortVariableName \
> >>
> >>  -disable-rule=LongLine \
> >>
> >>  -disable-rule=LongMethod \
> >>
> >>  -disable-rule=HighNcssMethod \
> >>
> >>  -disable-rule=LongVariableName \
> >>
> >>  -disable-rule=HighCyclomaticComplexity \
> >>
> >>  -disable-rule=HighNPathComplexity \
> >>
> >>  -disable-rule=UnusedLocalVariable \
> >>
> >>  -disable-rule=DoubleNegative \
> >>
> >>  -disable-rule=MultipleUnaryOperator \
> >>
> >>  -disable-rule=DeepNestedBlock \
> >>
> >> ```
> >>
> >>
> >> Best Wishes.
> >>
> >> RenMin Wang
> >>
> >>
> >>
>
>

Re: [Discuss] Lint rules should be kept or removed

2019-07-18 Thread York Shen

I’d like the idea of code lint(C++/OC/Java/etc…) in Travis CI. What’s more, you 
could improve your PR [1] in the following aspect:

Fix the lint issues especially lint errors in before enabling the Lint in Travis
Output the code lint result in Danger and make the Danger failed if there is an 
error lint. I think people rarely read the log of Travis if the build successes.

I think the default Android lint is good enough, as for OCLint, maybe someone 
with iOS experienced could give some suggestion.

[1] https://github.com/apache/incubator-weex/pull/2731 


Best Regards,
York Shen

申远

> 在 2019年7月19日，10:11，王仁敏  写道：
> 
> I think in OCLint, the following rules should be disabled.
> 
> 
>   - Size 
>  - HighCyclomaticComplexity
>  
> 
>  - LongClass
>  
>  - LongLine 
>  - LongMethod
>  
>  - HighNcssMethod
>  
>  - DeepNestedBlock
>  
>  - HighNPathComplexity
>  
>  - TooManyFields
>  
>  - TooManyMethods
>  
>  - TooManyParameters
>  
>   - Naming 
>  - LongVariableName
>  
>  - ShortVariableName
>  
> 
> 
> 王仁敏  于2019年7月19日周五 上午9:50写道：
> 
>> Hi there,
>> 
>> 
>> I'm trying to add some static lint checks to CI, now OCLint(for c, c++
>> and objective-c) and AndroidLint already get ready in CI.
>> 
>> But OCLint and AndroidLint have too many rules, many of which have little
>> impact. so maybe should we discuss about which rules to keep or which rules
>> to remove.
>> 
>> 
>> OCLint Rule List: http://docs.oclint.org/en/stable/rules/index.html
>> 
>> AndroidLint Rule List: http://tools.android.com/tips/lint-checks
>> 
>> AndroidLint Help: http://www.androiddocs.com/tools/help/lint.html
>> 
>> 
>> The below is the doctest
>>  reference for
>> OCLint：
>> 
>> ```
>> 
>> -disable-rule=ShortVariableName \
>> 
>>  -disable-rule=LongLine \
>> 
>>  -disable-rule=LongMethod \
>> 
>>  -disable-rule=HighNcssMethod \
>> 
>>  -disable-rule=LongVariableName \
>> 
>>  -disable-rule=HighCyclomaticComplexity \
>> 
>>  -disable-rule=HighNPathComplexity \
>> 
>>  -disable-rule=UnusedLocalVariable \
>> 
>>  -disable-rule=DoubleNegative \
>> 
>>  -disable-rule=MultipleUnaryOperator \
>> 
>>  -disable-rule=DeepNestedBlock \
>> 
>> ```
>> 
>> 
>> Best Wishes.
>> 
>> RenMin Wang
>> 
>> 
>>

Re: [Discuss] Lint rules should be kept or removed

2019-07-18 Thread 王仁敏

I think in OCLint, the following rules should be disabled.


   - Size 
  - HighCyclomaticComplexity
  

  - LongClass
  
  - LongLine 
  - LongMethod
  
  - HighNcssMethod
  
  - DeepNestedBlock
  
  - HighNPathComplexity
  
  - TooManyFields
  
  - TooManyMethods
  
  - TooManyParameters
  
   - Naming 
  - LongVariableName
  
  - ShortVariableName
  


王仁敏  于2019年7月19日周五 上午9:50写道：

> Hi there,
>
>
> I'm trying to add some static lint checks to CI, now OCLint(for c, c++
> and objective-c) and AndroidLint already get ready in CI.
>
> But OCLint and AndroidLint have too many rules, many of which have little
> impact. so maybe should we discuss about which rules to keep or which rules
> to remove.
>
>
> OCLint Rule List: http://docs.oclint.org/en/stable/rules/index.html
>
> AndroidLint Rule List: http://tools.android.com/tips/lint-checks
>
> AndroidLint Help: http://www.androiddocs.com/tools/help/lint.html
>
>
> The below is the doctest
>  reference for
> OCLint：
>
> ```
>
> -disable-rule=ShortVariableName \
>
>   -disable-rule=LongLine \
>
>   -disable-rule=LongMethod \
>
>   -disable-rule=HighNcssMethod \
>
>   -disable-rule=LongVariableName \
>
>   -disable-rule=HighCyclomaticComplexity \
>
>   -disable-rule=HighNPathComplexity \
>
>   -disable-rule=UnusedLocalVariable \
>
>   -disable-rule=DoubleNegative \
>
>   -disable-rule=MultipleUnaryOperator \
>
>   -disable-rule=DeepNestedBlock \
>
> ```
>
>
> Best Wishes.
>
> RenMin Wang
>
>
>

[Discuss] Lint rules should be kept or removed

2019-07-18 Thread 王仁敏

Hi there,


I'm trying to add some static lint checks to CI, now OCLint(for c, c++ and
objective-c) and AndroidLint already get ready in CI.

But OCLint and AndroidLint have too many rules, many of which have little
impact. so maybe should we discuss about which rules to keep or which rules
to remove.


OCLint Rule List: http://docs.oclint.org/en/stable/rules/index.html

AndroidLint Rule List: http://tools.android.com/tips/lint-checks

AndroidLint Help: http://www.androiddocs.com/tools/help/lint.html


The below is the doctest
 reference for
OCLint：

```

-disable-rule=ShortVariableName \

  -disable-rule=LongLine \

  -disable-rule=LongMethod \

  -disable-rule=HighNcssMethod \

  -disable-rule=LongVariableName \

  -disable-rule=HighCyclomaticComplexity \

  -disable-rule=HighNPathComplexity \

  -disable-rule=UnusedLocalVariable \

  -disable-rule=DoubleNegative \

  -disable-rule=MultipleUnaryOperator \

  -disable-rule=DeepNestedBlock \

```


Best Wishes.

RenMin Wang

Re: App freezing with 0.26 sdk update

2019-07-18 Thread Vipul Gupta

sure York Shen.

On Thu, Jul 18, 2019 at 3:19 PM York Shen  wrote:

> I think @lucky-then is helping you in this problems. Please give as much
> information as possible as he suggested. And we shall move the conversation
> to Github[1] if we are going to talk about detail of code.
>
> [1]
> https://github.com/apache/incubator-weex/issues/2718#issuecomment-512654624
> <
> https://github.com/apache/incubator-weex/issues/2718#issuecomment-512654624
> >
>
> Best Regards,
> York Shen
>
> 申远
>
> > 在 2019年7月17日，18:26，Vipul Gupta  写道：
> >
> > Sure York shen.
> > Please find link to Github -
> > https://github.com/apache/incubator-weex/issues/2718 <
> https://github.com/apache/incubator-weex/issues/2718>
> >
> >
> > On Wed, Jul 17, 2019 at 2:43 PM York Shen  shenyua...@gmail.com>> wrote:
> >
> >> Well, please report bug using Github Issue with the default template[1]
> >> and provide a reproducible demo. As a developer, you might understand
> that
> >> there is nothing we can do before reproducing the potential problems.
> >>
> >> [1] https://github.com/apache/incubator-weex/issues/new/choose <
> https://github.com/apache/incubator-weex/issues/new/choose> <
> >> https://github.com/apache/incubator-weex/issues/new/choose <
> https://github.com/apache/incubator-weex/issues/new/choose>>
> >>
> >> Best Regards,
> >> York Shen
> >>
> >> 申远
> >>
> >>> 在 2019年7月17日，01:12，Vipul Gupta  写道：
> >>>
> >>> Hi Team,
> >>>
> >>> We have updated our app with 0.26 sdk update, post which the app is
> >>> responding slower to click events.
> >>> Also, the rendering is slower as compared to previous versions.
> >>> Request your support in this regard.
> >>>
> >>> --
> >>> Regards,
> >>> Vipul Gupta
> >>> Senior Technical Lead
> >>> 8802232975
> >>
> >>
> >
> > --
> > Regards,
> > Vipul Gupta
> > Senior Technical Lead
> > 8802232975
>
>

-- 
Regards,
Vipul Gupta
Senior Technical Lead
8802232975

Re: App freezing with 0.26 sdk update

2019-07-18 Thread York Shen

I think @lucky-then is helping you in this problems. Please give as much 
information as possible as he suggested. And we shall move the conversation to 
Github[1] if we are going to talk about detail of code.

[1] https://github.com/apache/incubator-weex/issues/2718#issuecomment-512654624 


Best Regards,
York Shen

申远

> 在 2019年7月17日，18:26，Vipul Gupta  写道：
> 
> Sure York shen.
> Please find link to Github -
> https://github.com/apache/incubator-weex/issues/2718 
> 
> 
> 
> On Wed, Jul 17, 2019 at 2:43 PM York Shen  > wrote:
> 
>> Well, please report bug using Github Issue with the default template[1]
>> and provide a reproducible demo. As a developer, you might understand that
>> there is nothing we can do before reproducing the potential problems.
>> 
>> [1] https://github.com/apache/incubator-weex/issues/new/choose 
>>  <
>> https://github.com/apache/incubator-weex/issues/new/choose 
>> >
>> 
>> Best Regards,
>> York Shen
>> 
>> 申远
>> 
>>> 在 2019年7月17日，01:12，Vipul Gupta  写道：
>>> 
>>> Hi Team,
>>> 
>>> We have updated our app with 0.26 sdk update, post which the app is
>>> responding slower to click events.
>>> Also, the rendering is slower as compared to previous versions.
>>> Request your support in this regard.
>>> 
>>> --
>>> Regards,
>>> Vipul Gupta
>>> Senior Technical Lead
>>> 8802232975
>> 
>> 
> 
> -- 
> Regards,
> Vipul Gupta
> Senior Technical Lead
> 8802232975

Re: Concerned about the LGPL dependency in Webkit

Re: [Discuss] Lint rules should be kept or removed

Re: [Discuss] Lint rules should be kept or removed

Re: [Discuss] Lint rules should be kept or removed

[Discuss] Lint rules should be kept or removed

Re: App freezing with 0.26 sdk update

Re: App freezing with 0.26 sdk update

7 matches

Site Navigation

Mail list logo

Footer information