Re: [HELP] Failed to upgrade SDK to 0.16.0

[Raphael Bircher]

Hi

The mailing list program cut attachments of. Can you upload your  
screenshot somewhere, and just send a link?


Regards Raphael

Am .10.2017, 07:56 Uhr, schrieb xiaowei.chai :



Re-attach the exception log screenshot.


发件人: "xiaowei.chai" 
答复: 
日期: 2017年10月25日 星期三 13:53
至: 
主题: [HELP] Failed to upgrade SDK to 0.16.0



We recently tried to upgrade weex SDK to 0.16.0 from 0.11.0. After  
upgraded, we found all weex pages turns blank and an exception log:









--
My introduction https://youtu.be/Ln4vly5sxYU

Re: [HELP] Failed to upgrade SDK to 0.16.0

[xiaowei.chai]

Re-attach the exception log screenshot.

 

发件人: "xiaowei.chai" 
答复: 
日期: 2017年10月25日 星期三 13:53
至: 
主题: [HELP] Failed to upgrade SDK to 0.16.0

 


We recently tried to upgrade weex SDK to 0.16.0 from 0.11.0. After upgraded, we 
found all weex pages turns blank and an exception log:

 

[HELP] Failed to upgrade SDK to 0.16.0

[xiaowei.chai]

Hi,

 

We recently tried to upgrade weex SDK to 0.16.0 from 0.11.0. After upgraded, we 
found all weex pages turns blank and an exception log:

 

 

It seems we lost some file(s) which should provide invokeInitFramework method.

Do you guys know how to resolve this problem?

BTW, we use Android Studio.

 

Thanks for any help.

 

Xiao-Wei Chai

www.zhaopin.com

 

 

 

柴晓伟 

北京市朝阳区阜荣街10号望京首开广场5层智联总部

Email：xiaowei.c...@zhaopin.com.cn

Tel：（010）50833044 ext. 68363

Website: www.zhaopin.com 

 

 

 

[jira] [Updated] (WEEX-89) View with linear gradient could not render its border radius correctly

[leozdgao (JIRA)]

 [ 
https://issues.apache.org/jira/browse/WEEX-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

leozdgao updated WEEX-89:
-
Summary: View with linear gradient could not render its border radius 
correctly  (was: View with linear gradient could not render border radius 
correctly)

> View with linear gradient could not render its border radius correctly
> --
>
> Key: WEEX-89
> URL: https://issues.apache.org/jira/browse/WEEX-89
> Project: Weex
>  Issue Type: Bug
>  Components: iOS
>Reporter: leozdgao
>Assignee: Adam Feng
>Priority: Blocker
> Attachments: correct-without-gradient.PNG, incorrect-with-gradient.PNG
>
>
> A view with linear gradient could not render its border radius correctly, 
> check the attachment please, the file 'incorrect-with-gradient' shows the 
> problem, and the file `correct-without-gradient` is the view without linear 
> gradient and it render its border-radius correctly.
> And my style is right here:
> ```
> backgroundImage: linear-gradient(to right, '#FF00A0', '#FF0041');
> border-top-left-radius: 8px;
> border-top-right-radius: 8px;
> ```



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (WEEX-89) View with linear gradient could not render border radius correctly

[leozdgao (JIRA)]

leozdgao created WEEX-89:


 Summary: View with linear gradient could not render border radius 
correctly
 Key: WEEX-89
 URL: https://issues.apache.org/jira/browse/WEEX-89
 Project: Weex
  Issue Type: Bug
  Components: iOS
Reporter: leozdgao
Assignee: Adam Feng
Priority: Blocker
 Attachments: correct-without-gradient.PNG, incorrect-with-gradient.PNG

A view with linear gradient could not render its border radius correctly, check 
the attachment please, the file 'incorrect-with-gradient' shows the problem, 
and the file `correct-without-gradient` is the view without linear gradient and 
it render its border-radius correctly.

And my style is right here:

```
backgroundImage: linear-gradient(to right, '#FF00A0', '#FF0041');
border-top-left-radius: 8px;
border-top-right-radius: 8px;
```



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (WEEX-88) BOOL arguments cannot be received correctly by component's method in 32-bit iOS devices

[Adam Feng (JIRA)]

[ 
https://issues.apache.org/jira/browse/WEEX-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216678#comment-16216678
 ] 

Adam Feng commented on WEEX-88:
---

It looks good to me,  please create a pull request, thanks.

> BOOL arguments cannot be received correctly by component's method in 32-bit 
> iOS devices
> ---
>
> Key: WEEX-88
> URL: https://issues.apache.org/jira/browse/WEEX-88
> Project: Weex
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: 0.15
> Environment: iPhone 4s (iOS 9.1), iPhone 5 simulator (iOS 10.3)
>Reporter: Shiwen XU
>Assignee: Adam Feng
>Priority: Blocker
>
> BOOL arguments cannot be received correctly by component's method in 32-bit 
> iOS devices. It appears that the received argument is always some integer 
> value other than boolean value.
> This problem might be introduced by the macro *WX_ARGUMENTS_SET*.
> {code:title=WXUtility.h|borderStyle=solid}
> #define WX_ARGUMENTS_SET(_invocation, _sig, idx, _obj, _ppFree) \
> do {\
> const char *encode = [_sig getArgumentTypeAtIndex:(idx) + 2];\
> switch(encode[0]){\
> WX_EPCHAR_CASE(_invocation, idx, _C_CHARPTR, _obj, char *, 
> UTF8String, _ppFree)\
> WX_ENUMBER_CASE(_invocation, idx, _C_INT, _obj, int, intValue, 
> _ppFree)\
> WX_ENUMBER_CASE(_invocation, idx, _C_SHT, _obj, short, shortValue, 
> _ppFree)\
> WX_ENUMBER_CASE(_invocation, idx, _C_LNG, _obj, long, longValue, 
> _ppFree)\
> WX_ENUMBER_CASE(_invocation, idx, _C_LNG_LNG, _obj, long long, 
> longLongValue, _ppFree)\
> WX_ENUMBER_CASE(_invocation, idx, _C_UCHR, _obj, unsigned char, 
> unsignedCharValue, _ppFree)\
> WX_ENUMBER_CASE(_invocation, idx, _C_UINT, _obj, unsigned int, 
> unsignedIntValue, _ppFree)\
> WX_ENUMBER_CASE(_invocation, idx, _C_USHT, _obj, unsigned short, 
> unsignedShortValue, _ppFree)\
> WX_ENUMBER_CASE(_invocation, idx, _C_ULNG, _obj, unsigned long, 
> unsignedLongValue, _ppFree)\
> WX_ENUMBER_CASE(_invocation, idx, _C_ULNG_LNG, _obj,unsigned long 
> long, unsignedLongLongValue, _ppFree)\
> WX_ENUMBER_CASE(_invocation, idx, _C_FLT, _obj, float, floatValue, 
> _ppFree)\
> WX_ENUMBER_CASE(_invocation, idx, _C_DBL, _obj, double, doubleValue, 
> _ppFree)\
> WX_ENUMBER_CASE(_invocation, idx, _C_BOOL, _obj, bool, boolValue, 
> _ppFree)\
> default: { [_invocation setArgument:&_obj atIndex:(idx) + 2]; 
> *(_ppFree + idx) = 0; break;}\
> }\
> }while(0)
> {code}
> The BOOL value in 32-bit iOS is a typedef of signed char so its *@encode* is 
> *_C_CHR* instead of *_C_BOOL*. We can find the typedef in objc.h.
> {code:title=objc.h|borderStyle=solid}
> #if defined(__OBJC_BOOL_IS_BOOL)
> // Honor __OBJC_BOOL_IS_BOOL when available.
> #   if __OBJC_BOOL_IS_BOOL
> #   define OBJC_BOOL_IS_BOOL 1
> #   else
> #   define OBJC_BOOL_IS_BOOL 0
> #   endif
> #else
> // __OBJC_BOOL_IS_BOOL not set.
> #   if TARGET_OS_OSX || (TARGET_OS_IOS && !__LP64__ && !__ARM_ARCH_7K)
> #  define OBJC_BOOL_IS_BOOL 0
> #   else
> #  define OBJC_BOOL_IS_BOOL 1
> #   endif
> #endif
> #if OBJC_BOOL_IS_BOOL
> typedef bool BOOL;
> #else
> #   define OBJC_BOOL_IS_CHAR 1
> typedef signed char BOOL; 
> // BOOL is explicitly signed so @encode(BOOL) == "c" rather than "C" 
> // even if -funsigned-char is used.
> #endif
> {code}
> But *WX_ARGUMENTS_SET* didn't consider the case of *_C_CHR*. In this case the 
> default condition is executed and the *NSNumber pointer* value will be casted 
> to a *BOOL* value so the received argument is always wrong.
> If I add this line of code and the received argument will become correct.
> {code}
> WX_ENUMBER_CASE(_invocation, idx, _C_UCHR, _obj, unsigned char, 
> unsignedCharValue, _ppFree)\
> /* added code */
> WX_ENUMBER_CASE(_invocation, idx, _C_CHR, _obj, char, charValue, _ppFree)\
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [DISCUSS] Roadmap proposal for community building

[许有红]

support GitHub issue

2017-10-15 20:57 GMT+08:00 danwu wu :

> Team, I created on jira regard the plan of weex-toolkit development , if
> there is any idea, welcome to discuss together！
>
> [1] https://issues.apache.org/jira/browse/WEEX-85
>

[jira] [Commented] (WEEX-17) Abstract a common `weex` variable for each JS framework

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WEEX-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216509#comment-16216509
 ] 

ASF GitHub Bot commented on WEEX-17:


Github user Hanks10100 commented on the issue:

https://github.com/apache/incubator-weex/pull/785
  
Got, this PR can be closed.


> Abstract a common `weex` variable for each JS framework
> ---
>
> Key: WEEX-17
> URL: https://issues.apache.org/jira/browse/WEEX-17
> Project: Weex
>  Issue Type: Improvement
>Reporter: Jinjiang Zhao
>Assignee: Hanks Zhang
>Priority: Minor
>  Labels: features
>
> I think before a Weex instance initialized by a certain JS framework, we can 
> abstract and prepare something which every JS framework will do the same and 
> put them into a common `weex` variable. Then this variable could be used 
> directly in a JS framework.
> It contains:
> 1. A CallbackManager instance: to convert callback into a unique callbackId 
> in this Weex page, just for passing the id to native as the callback itself.
> 2. A NativeModuleGetter instance: to require a native module in this Weex 
> page. Because it certainly need processes functions, so it depends on the 
> CallbackManager instance.
> 3. A Document instance: every Weex page must have and only have one Document 
> instance.
> 4. Config object of the Weex page. It should contains env info, framework 
> info and bundle info.
> 5. CSS Units calculator. It depends on config object.
> 6. All injects from JS Services.
> All of above could be passed into JS framework for init. And 
> NativeModuleGetter instance, Document instance, config object and CSS units 
> calculator could be exposed on `weex` variable as `{ requireModule(name), 
> document, config, unit }`. So the new API design of 
> `framework.createInstance` could be:
> function createInstance(id, code, info)
> and parameter info contains: { weex, callbacks, services }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (WEEX-17) Abstract a common `weex` variable for each JS framework

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/WEEX-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16216510#comment-16216510
 ] 

ASF GitHub Bot commented on WEEX-17:


Github user Hanks10100 closed the pull request at:

https://github.com/apache/incubator-weex/pull/785


> Abstract a common `weex` variable for each JS framework
> ---
>
> Key: WEEX-17
> URL: https://issues.apache.org/jira/browse/WEEX-17
> Project: Weex
>  Issue Type: Improvement
>Reporter: Jinjiang Zhao
>Assignee: Hanks Zhang
>Priority: Minor
>  Labels: features
>
> I think before a Weex instance initialized by a certain JS framework, we can 
> abstract and prepare something which every JS framework will do the same and 
> put them into a common `weex` variable. Then this variable could be used 
> directly in a JS framework.
> It contains:
> 1. A CallbackManager instance: to convert callback into a unique callbackId 
> in this Weex page, just for passing the id to native as the callback itself.
> 2. A NativeModuleGetter instance: to require a native module in this Weex 
> page. Because it certainly need processes functions, so it depends on the 
> CallbackManager instance.
> 3. A Document instance: every Weex page must have and only have one Document 
> instance.
> 4. Config object of the Weex page. It should contains env info, framework 
> info and bundle info.
> 5. CSS Units calculator. It depends on config object.
> 6. All injects from JS Services.
> All of above could be passed into JS framework for init. And 
> NativeModuleGetter instance, Document instance, config object and CSS units 
> calculator could be exposed on `weex` variable as `{ requireModule(name), 
> document, config, unit }`. So the new API design of 
> `framework.createInstance` could be:
> function createInstance(id, code, info)
> and parameter info contains: { weex, callbacks, services }



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)