[jira] [Commented] (THRIFT-4474) PHP generator use PSR-4 default
[
https://issues.apache.org/jira/browse/THRIFT-4474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16398149#comment-16398149
]
ASF GitHub Bot commented on THRIFT-4474:
Github user RobberPhex commented on the issue:
https://github.com/apache/thrift/pull/1479
@dcelasun squashed
> PHP generator use PSR-4 default
> ---
>
> Key: THRIFT-4474
> URL: https://issues.apache.org/jira/browse/THRIFT-4474
> Project: Thrift
> Issue Type: Improvement
> Components: PHP - Compiler
>Reporter: Robert Lu
>Assignee: Robert Lu
>Priority: Major
>
> Before, PHP generator generate php files like {{Types.php}}, {{Service.php}}.
> Those can only be load via
> [{{classmap}}|https://getcomposer.org/doc/04-schema.md#classmap] method. The
> latest PSR about autoload is [PSR-4|http://www.php-fig.org/psr/psr-4/].
> thrift compiler can generate PSR-4 code default, if want old-style code(which
> can only load via classmap), add {{classmap}} option.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] thrift issue #1479: THRIFT-4474: generate PHP code use PSR-4 style default
Github user RobberPhex commented on the issue: https://github.com/apache/thrift/pull/1479 @dcelasun squashed ---
[jira] [Commented] (THRIFT-4474) PHP generator use PSR-4 default
[
https://issues.apache.org/jira/browse/THRIFT-4474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16398145#comment-16398145
]
ASF GitHub Bot commented on THRIFT-4474:
Github user dcelasun commented on the issue:
https://github.com/apache/thrift/pull/1479
@RobberPhex can you squash your commits?
> PHP generator use PSR-4 default
> ---
>
> Key: THRIFT-4474
> URL: https://issues.apache.org/jira/browse/THRIFT-4474
> Project: Thrift
> Issue Type: Improvement
> Components: PHP - Compiler
>Reporter: Robert Lu
>Assignee: Robert Lu
>Priority: Major
>
> Before, PHP generator generate php files like {{Types.php}}, {{Service.php}}.
> Those can only be load via
> [{{classmap}}|https://getcomposer.org/doc/04-schema.md#classmap] method. The
> latest PSR about autoload is [PSR-4|http://www.php-fig.org/psr/psr-4/].
> thrift compiler can generate PSR-4 code default, if want old-style code(which
> can only load via classmap), add {{classmap}} option.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] thrift issue #1479: THRIFT-4474: generate PHP code use PSR-4 style default
Github user dcelasun commented on the issue: https://github.com/apache/thrift/pull/1479 @RobberPhex can you squash your commits? ---
[jira] [Commented] (THRIFT-4474) PHP generator use PSR-4 default
[
https://issues.apache.org/jira/browse/THRIFT-4474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16397994#comment-16397994
]
ASF GitHub Bot commented on THRIFT-4474:
Github user RobberPhex commented on a diff in the pull request:
https://github.com/apache/thrift/pull/1479#discussion_r174337789
--- Diff: lib/php/README.md ---
@@ -20,34 +19,46 @@ KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-Using Thrift with PHP
-=
+# Using Thrift with PHP
Thrift requires PHP 5. Thrift makes as few assumptions about your PHP
environment as possible while trying to make some more advanced PHP
features (i.e. APC cacheing using asbolute path URLs) as simple as
possible.
To use Thrift in your PHP codebase, take the following steps:
-#1) Copy all of thrift/lib/php/lib into your PHP codebase
-#2) Configure Symfony Autoloader (or whatever you usually use)
+1. Copy all of thrift/lib/php/lib into your PHP codebase
+2. Configure Symfony Autoloader (or whatever you usually use)
After that, you have to manually include the Thrift package
created by the compiler:
+```
require_once 'packages/Service/Service.php';
require_once 'packages/Service/Types.php';
+```
-Dependencies
-
+# Dependencies
PHP_INT_SIZE
- This built-in signals whether your architecture is 32 or 64 bit and is
- used by the TBinaryProtocol to properly use pack() and unpack() to
- serialize data.
+This built-in signals whether your architecture is 32 or 64 bit and is
+used by the TBinaryProtocol to properly use pack() and unpack() to
+serialize data.
apc_fetch(), apc_store()
- APC cache is used by the TSocketPool class. If you do not have APC
installed,
- Thrift will fill in null stub function definitions.
+APC cache is used by the TSocketPool class. If you do not have APC
installed,
+Thrift will fill in null stub function definitions.
+
+# Breaking Changes
+
+## 0.12.0
+
+1. For thrift compiler, `psr4` flag is opened default, generated code
match psr4 code struct.
+
+If you want old-style directory struct, use `classmap` option. (i.e.
`-gen php:classmap`)
+
+2. For ThriftClassloader, if use psr4 code struct, must use
`$thriftClassLoader->registerNamespace('namespace', '')` to register
autoload.
--- End diff --
Thank you! It's better phrasing.
---
Fixed by amend comment.
> PHP generator use PSR-4 default
> ---
>
> Key: THRIFT-4474
> URL: https://issues.apache.org/jira/browse/THRIFT-4474
> Project: Thrift
> Issue Type: Improvement
> Components: PHP - Compiler
>Reporter: Robert Lu
>Assignee: Robert Lu
>Priority: Major
>
> Before, PHP generator generate php files like {{Types.php}}, {{Service.php}}.
> Those can only be load via
> [{{classmap}}|https://getcomposer.org/doc/04-schema.md#classmap] method. The
> latest PSR about autoload is [PSR-4|http://www.php-fig.org/psr/psr-4/].
> thrift compiler can generate PSR-4 code default, if want old-style code(which
> can only load via classmap), add {{classmap}} option.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] thrift pull request #1479: THRIFT-4474: generate PHP code use PSR-4 style de...
Github user RobberPhex commented on a diff in the pull request:
https://github.com/apache/thrift/pull/1479#discussion_r174337789
--- Diff: lib/php/README.md ---
@@ -20,34 +19,46 @@ KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-Using Thrift with PHP
-=
+# Using Thrift with PHP
Thrift requires PHP 5. Thrift makes as few assumptions about your PHP
environment as possible while trying to make some more advanced PHP
features (i.e. APC cacheing using asbolute path URLs) as simple as
possible.
To use Thrift in your PHP codebase, take the following steps:
-#1) Copy all of thrift/lib/php/lib into your PHP codebase
-#2) Configure Symfony Autoloader (or whatever you usually use)
+1. Copy all of thrift/lib/php/lib into your PHP codebase
+2. Configure Symfony Autoloader (or whatever you usually use)
After that, you have to manually include the Thrift package
created by the compiler:
+```
require_once 'packages/Service/Service.php';
require_once 'packages/Service/Types.php';
+```
-Dependencies
-
+# Dependencies
PHP_INT_SIZE
- This built-in signals whether your architecture is 32 or 64 bit and is
- used by the TBinaryProtocol to properly use pack() and unpack() to
- serialize data.
+This built-in signals whether your architecture is 32 or 64 bit and is
+used by the TBinaryProtocol to properly use pack() and unpack() to
+serialize data.
apc_fetch(), apc_store()
- APC cache is used by the TSocketPool class. If you do not have APC
installed,
- Thrift will fill in null stub function definitions.
+APC cache is used by the TSocketPool class. If you do not have APC
installed,
+Thrift will fill in null stub function definitions.
+
+# Breaking Changes
+
+## 0.12.0
+
+1. For thrift compiler, `psr4` flag is opened default, generated code
match psr4 code struct.
+
+If you want old-style directory struct, use `classmap` option. (i.e.
`-gen php:classmap`)
+
+2. For ThriftClassloader, if use psr4 code struct, must use
`$thriftClassLoader->registerNamespace('namespace', '')` to register
autoload.
--- End diff --
Thank you! It's better phrasing.
---
Fixed by amend comment.
---
[jira] [Commented] (THRIFT-4382) Replace the use of Perl Indirect Object Syntax calls to new()
[ https://issues.apache.org/jira/browse/THRIFT-4382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16397877#comment-16397877 ] ASF GitHub Bot commented on THRIFT-4382: Github user djzort commented on the issue: https://github.com/apache/thrift/pull/1261 it's still on my TODO list, but is very low. I will get to it sooner or later. > Replace the use of Perl Indirect Object Syntax calls to new() > -- > > Key: THRIFT-4382 > URL: https://issues.apache.org/jira/browse/THRIFT-4382 > Project: Thrift > Issue Type: Improvement > Components: Perl - Compiler >Reporter: Dean Hamstead >Priority: Minor > > Using Indirect Object Syntax to instantiate objects is not recommended as per > https://perldoc.perl.org/perlobj.html#Invoking-Class-Methods -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] thrift issue #1261: THRIFT-4382: Replace the use of Indirect Object Syntax c...
Github user djzort commented on the issue: https://github.com/apache/thrift/pull/1261 it's still on my TODO list, but is very low. I will get to it sooner or later. ---
[jira] [Commented] (THRIFT-4513) thrift generated java code is not stable for constants
[
https://issues.apache.org/jira/browse/THRIFT-4513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16397815#comment-16397815
]
ASF GitHub Bot commented on THRIFT-4513:
Github user romanoid commented on the issue:
https://github.com/apache/thrift/pull/1505
Fix is in, the only failure left is this one, I'm not sure if it is
instability of tests or real problem:
https://travis-ci.org/apache/thrift/jobs/353050154
> thrift generated java code is not stable for constants
> --
>
> Key: THRIFT-4513
> URL: https://issues.apache.org/jira/browse/THRIFT-4513
> Project: Thrift
> Issue Type: Improvement
> Components: Java - Compiler
>Reporter: Roman Soroka
>Priority: Major
>
> In certain cases, output generated with java compiler is unstable, this
> prevents correct incremental generation, artifact caching, etc.
> This is especially crucible if the goal is reproducible builds: same results
> for the same source inputs.
> Here's example:
> Let's say we have thrift definition:
> const map CONSTANT_MAP =
> { 'key1' : \\{"enum1" : Enum1.ENUM1_VALUE1, "enum2" : Enum2.ENUM2_VALUE}
> ,
> 'key2' : \{"enum1" : Enum1.ENUM1_VALUE2, "enum2" : Enum2.ENUM2_VALUE},
> 'key3' : \{"enum1" : Enum1.ENUM1_VALUE3, "enum2" : Enum2.ENUM2_VALUE},
>
> }
> Compiler generates code like:
> public static final java.util.Map CONSTANT_MAP =
> new java.util.HashMap();
> static {
> Enum1Enum2 tmp199 = new Enum1Enum2();
> tmp199.setEnum1(com.java.package.Enum1.ENUM1_VALUE2);
> tmp199.setEnum2(com.java.package.Enum2.ENUM2_VALUE);
> CONSTANT_MAP.put("key2", tmp199);
> Enum1Enum2 tmp200 = new Enum1Enum2();
> tmp200.setEnum1(com.java.package.Enum1.ENUM1_VALUE1);
> tmp200.setEnum2(com.java.package.Enum2.ENUM2_VALUE);
> CONSTANT_MAP.put("key1", tmp200);
> Enum1Enum2 tmp201 = new Enum1Enum2();
> tmp201.setEnum1(com.java.package.Enum1.ENUM1_VALUE3);
> tmp201.setEnum2(com.java.package.Enum2.ENUM2_VALUE);
> CONSTANT_MAP.put("key3", tmp201);
> Possible reorderings:
> 1. Values are added in different order from run to run.
> 2. Set methods in value construction may be called in different order.
> Note: this results in equivalent java maps, so there is no runtime issues.
> Proposed remedy:
> When building construction of Constants from JSON, java code generator
> should use by-key ordering.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] thrift issue #1505: THRIFT-4513: Fixing java thrift compiler to generate con...
Github user romanoid commented on the issue: https://github.com/apache/thrift/pull/1505 Fix is in, the only failure left is this one, I'm not sure if it is instability of tests or real problem: https://travis-ci.org/apache/thrift/jobs/353050154 ---
[GitHub] thrift issue #1474: Recognize fbthrift TApplicationException codes
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1474 @jfarrell can you please give a final say on this? ---
[jira] [Commented] (THRIFT-4513) thrift generated java code is not stable for constants
[
https://issues.apache.org/jira/browse/THRIFT-4513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16397404#comment-16397404
]
ASF GitHub Bot commented on THRIFT-4513:
Github user romanoid commented on the issue:
https://github.com/apache/thrift/pull/1505
@jeking3 done, thanks, let's see if it passes.
> thrift generated java code is not stable for constants
> --
>
> Key: THRIFT-4513
> URL: https://issues.apache.org/jira/browse/THRIFT-4513
> Project: Thrift
> Issue Type: Improvement
> Components: Java - Compiler
>Reporter: Roman Soroka
>Priority: Major
>
> In certain cases, output generated with java compiler is unstable, this
> prevents correct incremental generation, artifact caching, etc.
> This is especially crucible if the goal is reproducible builds: same results
> for the same source inputs.
> Here's example:
> Let's say we have thrift definition:
> const map CONSTANT_MAP =
> { 'key1' : \\{"enum1" : Enum1.ENUM1_VALUE1, "enum2" : Enum2.ENUM2_VALUE}
> ,
> 'key2' : \{"enum1" : Enum1.ENUM1_VALUE2, "enum2" : Enum2.ENUM2_VALUE},
> 'key3' : \{"enum1" : Enum1.ENUM1_VALUE3, "enum2" : Enum2.ENUM2_VALUE},
>
> }
> Compiler generates code like:
> public static final java.util.Map CONSTANT_MAP =
> new java.util.HashMap();
> static {
> Enum1Enum2 tmp199 = new Enum1Enum2();
> tmp199.setEnum1(com.java.package.Enum1.ENUM1_VALUE2);
> tmp199.setEnum2(com.java.package.Enum2.ENUM2_VALUE);
> CONSTANT_MAP.put("key2", tmp199);
> Enum1Enum2 tmp200 = new Enum1Enum2();
> tmp200.setEnum1(com.java.package.Enum1.ENUM1_VALUE1);
> tmp200.setEnum2(com.java.package.Enum2.ENUM2_VALUE);
> CONSTANT_MAP.put("key1", tmp200);
> Enum1Enum2 tmp201 = new Enum1Enum2();
> tmp201.setEnum1(com.java.package.Enum1.ENUM1_VALUE3);
> tmp201.setEnum2(com.java.package.Enum2.ENUM2_VALUE);
> CONSTANT_MAP.put("key3", tmp201);
> Possible reorderings:
> 1. Values are added in different order from run to run.
> 2. Set methods in value construction may be called in different order.
> Note: this results in equivalent java maps, so there is no runtime issues.
> Proposed remedy:
> When building construction of Constants from JSON, java code generator
> should use by-key ordering.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] thrift issue #1505: THRIFT-4513: Fixing java thrift compiler to generate con...
Github user romanoid commented on the issue: https://github.com/apache/thrift/pull/1505 @jeking3 done, thanks, let's see if it passes. ---
[jira] [Updated] (THRIFT-4461) Compiler directive should match Delphi XE4
[
https://issues.apache.org/jira/browse/THRIFT-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Shchyrov updated THRIFT-4461:
---
Description:
In module Thrift.Utils daclared two methods
{code:java}
class function CharUtils.IsHighSurrogate( const c : Char) : Boolean;
begin
{$IF CompilerVersion < 23.0}
result := Character.IsHighSurrogate( c);
{$ELSE}
result := c.IsHighSurrogate();
{$IFEND}
end;
class function CharUtils.IsLowSurrogate( const c : Char) : Boolean;
begin
{$IF CompilerVersion < 23.0}
result := Character.IsLowSurrogate( c);
{$ELSE}
result := c.IsLowSurrogate;
{$IFEND}
end;
{code}
But methods Char.IsHighSurrogate()/Char.IsLowSurrogate() **appeared in Delphi
XE4. For Delphi XE4 variable CompilerVersion equal 25.
In this way condition
{{{$IF CompilerVersion < 23.0}}}
may be changed to
{{{$IF CompilerVersion < *25.0*}}}
And access for unit *Character* may be determined through defiine symbol
*OLD_UNIT_NAMES*
was:
In module Thrift.Utils daclared two methods
{{class function CharUtils.IsHighSurrogate( const c : Char) : Boolean;}}
{{begin}}
{{ \{$IF CompilerVersion < 23.0}}}
{{ result := Character.IsHighSurrogate( c);}}
{{ \{$ELSE}}}
{{ result := c.IsHighSurrogate();}}
{{ \{$IFEND}}}
{{end;}}
{{class function CharUtils.IsLowSurrogate( const c : Char) : Boolean;}}
{{begin}}
{{ \{$IF CompilerVersion < 23.0}}}
{{ result := Character.IsLowSurrogate( c);}}
{{ \{$ELSE}}}
{{ result := c.IsLowSurrogate;}}
{{ \{$IFEND}}}
{{end;}}
But methods Char.IsHighSurrogate()/Char.IsLowSurrogate() **appeared in Delphi
XE4. For Delphi XE4 variable CompilerVersion equal 25.
In this way condition
{{{$IF CompilerVersion < 23.0}}}
may be changed to
{{{$IF CompilerVersion < *25.0*}}}
And access for unit *Character* may be determined through defiine symbol
*OLD_UNIT_NAMES*
> Compiler directive should match Delphi XE4
> --
>
> Key: THRIFT-4461
> URL: https://issues.apache.org/jira/browse/THRIFT-4461
> Project: Thrift
> Issue Type: Bug
> Components: Delphi - Library
>Affects Versions: 0.11.0
> Environment: Delphi XE3
>Reporter: Anton Shchyrov
>Assignee: Jens Geyer
>Priority: Minor
> Labels: delphi
> Fix For: 0.12.0
>
> Attachments: Thrift.Utils.diff
>
>
> In module Thrift.Utils daclared two methods
>
> {code:java}
> class function CharUtils.IsHighSurrogate( const c : Char) : Boolean;
> begin
> {$IF CompilerVersion < 23.0}
> result := Character.IsHighSurrogate( c);
> {$ELSE}
> result := c.IsHighSurrogate();
> {$IFEND}
> end;
> class function CharUtils.IsLowSurrogate( const c : Char) : Boolean;
> begin
> {$IF CompilerVersion < 23.0}
> result := Character.IsLowSurrogate( c);
> {$ELSE}
> result := c.IsLowSurrogate;
> {$IFEND}
> end;
> {code}
> But methods Char.IsHighSurrogate()/Char.IsLowSurrogate() **appeared in Delphi
> XE4. For Delphi XE4 variable CompilerVersion equal 25.
> In this way condition
> {{{$IF CompilerVersion < 23.0}}}
> may be changed to
> {{{$IF CompilerVersion < *25.0*}}}
> And access for unit *Character* may be determined through defiine symbol
> *OLD_UNIT_NAMES*
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (THRIFT-4462) First line in Console duplicated
[
https://issues.apache.org/jira/browse/THRIFT-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Shchyrov updated THRIFT-4462:
---
Description:
Method Console.Write/WriteLine in class TGUIConsole after called method *Write*
and clear log duplicates current message
{code:java}
ChangeConsole(TGUIConsole.Create(Memo1.Lines));
Console.Write('String'); // Set internal FLineBreak to False
Memo1.Lines.Clear;
Console.Write('Some String'); // Log have "Some StringSome String"
Reason in method
procedure TGUIConsole.InternalWrite(const S: string; bWriteLine: Boolean);
var
idx : Integer;
begin
if FLineBreak then
begin
FMemo.Add( S );
end else
begin
idx := FMemo.Count - 1;
if idx < 0 then
begin
FMemo.Add( S );
end;
FMemo[idx] := FMemo[idx] + S;
end;
FLineBreak := bWriteLine;
end;
{code}
If FMemo.Count = 0 then idx = -1 and string added to log. But next line
{code:java}
FMemo[idx] := FMemo[idx] + S;{code}
repeats the added string. should be
{code:java}
if idx < 0 then
begin
FMemo.Add( S );
end else
FMemo[idx] := FMemo[idx] + S;{code}
was:
Method Console.Write/WriteLine in class TGUIConsole after called method *Write*
and clear log duplicates current message
{{ChangeConsole(TGUIConsole.Create(Memo1.Lines));}}
{{Console.Write('String'); // Set internal FLineBreak to False}}
{{Memo1.Lines.Clear;}}
{{Console.Write('Some String'); // Log have "Some StringSome String"}}
Reason in method
{{procedure TGUIConsole.InternalWrite(const S: string; bWriteLine: Boolean);}}
{{var}}
{{ idx : Integer;}}
{{begin}}
{{ if FLineBreak then}}
{{ begin}}
{{ FMemo.Add( S );}}
{{ end else}}
{{ begin}}
{{ idx := FMemo.Count - 1;}}
{{ if idx < 0 then}}
{{ begin}}
{{ FMemo.Add( S );}}
{{ end;}}
{{ FMemo[idx] := FMemo[idx] + S;}}
{{ end;}}
{{ FLineBreak := bWriteLine;}}
{{end;}}
If FMemo.Count = 0 then idx = -1 and string added to log. But next line
{{FMemo[idx] := FMemo[idx] + S;}}
repeats the added string. should be
if idx < 0 then
begin
FMemo.Add( S );
end *else*
FMemo[idx] := FMemo[idx] + S;
> First line in Console duplicated
>
>
> Key: THRIFT-4462
> URL: https://issues.apache.org/jira/browse/THRIFT-4462
> Project: Thrift
> Issue Type: Bug
> Components: Delphi - Library
>Affects Versions: 0.11.0
>Reporter: Anton Shchyrov
>Assignee: Jens Geyer
>Priority: Minor
> Fix For: 0.12.0
>
> Attachments: Thrift.Console.patch
>
>
> Method Console.Write/WriteLine in class TGUIConsole after called method
> *Write* and clear log duplicates current message
>
> {code:java}
> ChangeConsole(TGUIConsole.Create(Memo1.Lines));
> Console.Write('String'); // Set internal FLineBreak to False
> Memo1.Lines.Clear;
> Console.Write('Some String'); // Log have "Some StringSome String"
> Reason in method
> procedure TGUIConsole.InternalWrite(const S: string; bWriteLine: Boolean);
> var
> idx : Integer;
> begin
> if FLineBreak then
> begin
> FMemo.Add( S );
> end else
> begin
> idx := FMemo.Count - 1;
> if idx < 0 then
> begin
> FMemo.Add( S );
> end;
> FMemo[idx] := FMemo[idx] + S;
> end;
> FLineBreak := bWriteLine;
> end;
> {code}
> If FMemo.Count = 0 then idx = -1 and string added to log. But next line
> {code:java}
> FMemo[idx] := FMemo[idx] + S;{code}
> repeats the added string. should be
> {code:java}
> if idx < 0 then
> begin
> FMemo.Add( S );
> end else
> FMemo[idx] := FMemo[idx] + S;{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (THRIFT-4467) Add methods WriteFmt/WriteLineFmt to TThriftConsole class
[
https://issues.apache.org/jira/browse/THRIFT-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Shchyrov updated THRIFT-4467:
---
Description:
For ease of use, add methods
{code:java}
procedure TThriftConsole.WriteFmt(const AFmt: string;
const AArgs: array of const);
begin
Write(Format(AFmt, AArgs));
end;
procedure TThriftConsole.WriteLineFmt(const AFmt: string;
const AArgs: array of const);
begin
WriteLine(Format(AFmt, AArgs));
end;
{code}
was:
For ease of use, add methods
{{procedure TThriftConsole.WriteFmt(const AFmt: string;}}
const AArgs: array of const);
{{begin}}
{{ Write(Format(AFmt, AArgs));}}
{{end;}}
{{procedure TThriftConsole.WriteLineFmt(const AFmt: string;}}
const AArgs: array of const);
{{begin}}
{{ WriteLine(Format(AFmt, AArgs));}}
{{end;}}
> Add methods WriteFmt/WriteLineFmt to TThriftConsole class
> -
>
> Key: THRIFT-4467
> URL: https://issues.apache.org/jira/browse/THRIFT-4467
> Project: Thrift
> Issue Type: Sub-task
> Components: Delphi - Library
>Affects Versions: 0.11.0
>Reporter: Anton Shchyrov
>Assignee: Jens Geyer
>Priority: Minor
> Labels: Console
> Fix For: 0.12.0
>
>
> For ease of use, add methods
>
> {code:java}
> procedure TThriftConsole.WriteFmt(const AFmt: string;
> const AArgs: array of const);
> begin
> Write(Format(AFmt, AArgs));
> end;
> procedure TThriftConsole.WriteLineFmt(const AFmt: string;
> const AArgs: array of const);
> begin
> WriteLine(Format(AFmt, AArgs));
> end;
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (THRIFT-4468) Make the class TGUIConsole thread-safe
[
https://issues.apache.org/jira/browse/THRIFT-4468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Shchyrov updated THRIFT-4468:
---
Description:
In Delphi all methods that refer to VCL should do it only from main thread. But
class TGUIConsole despite the name does not contain any synchronization methods.
My suggestion is to rename this class to TStringsConsole, make method
InternalWrite virtual and make new class TGUIConsole inherits from
TStringsConsole
{code:java}
TGUIConsole = class( TStringsConsole )
protected
procedure InternalWrite(const S: string; bWriteLine: Boolean); override;
end;
{ TGUIConsole }
procedure TGUIConsole.InternalWrite(const S: string; bWriteLine: Boolean);
begin
if TThread.CurrentThread.ThreadID <> MainThreadID then begin
TThread.Synchronize(nil, procedure
begin
inherited InternalWrite(S, bWriteLine);
end
);
end else
inherited InternalWrite(S, bWriteLine);
end;
{code}
was:
In Delphi all methods that refer to VCL should do it only from main thread. But
class TGUIConsole despite the name does not contain any synchronization methods.
My suggestion is to rename this class to TStringsConsole, make method
InternalWrite virtual and make new class TGUIConsole inherits from
TStringsConsole
{{ TGUIConsole = class( TStringsConsole )}}
{{ protected}}
{{ procedure InternalWrite(const S: string; bWriteLine: Boolean); override;}}
{{ end;}}
{{{ TGUIConsole }}}
{{procedure TGUIConsole.InternalWrite(const S: string; bWriteLine: Boolean);}}
{{begin}}
{{ if TThread.CurrentThread.ThreadID <> MainThreadID then begin}}
{{ TThread.Synchronize(nil, procedure}}
{{ begin}}
{{ inherited InternalWrite(S, bWriteLine);}}
{{ end}}
{{ );}}
{{ end else}}
{{ inherited InternalWrite(S, bWriteLine);}}
{{end;}}
> Make the class TGUIConsole thread-safe
> --
>
> Key: THRIFT-4468
> URL: https://issues.apache.org/jira/browse/THRIFT-4468
> Project: Thrift
> Issue Type: Sub-task
> Components: Delphi - Library
>Affects Versions: 0.11.0
>Reporter: Anton Shchyrov
>Assignee: Jens Geyer
>Priority: Major
> Fix For: 0.12.0
>
>
> In Delphi all methods that refer to VCL should do it only from main thread.
> But class TGUIConsole despite the name does not contain any synchronization
> methods.
> My suggestion is to rename this class to TStringsConsole, make method
> InternalWrite virtual and make new class TGUIConsole inherits from
> TStringsConsole
>
> {code:java}
> TGUIConsole = class( TStringsConsole )
> protected
> procedure InternalWrite(const S: string; bWriteLine: Boolean); override;
> end;
> { TGUIConsole }
> procedure TGUIConsole.InternalWrite(const S: string; bWriteLine: Boolean);
> begin
> if TThread.CurrentThread.ThreadID <> MainThreadID then begin
> TThread.Synchronize(nil, procedure
> begin
> inherited InternalWrite(S, bWriteLine);
> end
> );
> end else
> inherited InternalWrite(S, bWriteLine);
> end;
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (THRIFT-4481) TBinaryProtocol.writeMessageEnd isn't trowable exception
[
https://issues.apache.org/jira/browse/THRIFT-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Shchyrov updated THRIFT-4481:
---
Description:
In base class TProtocol method writeMessageEnd can throw exception TException
{code:java}
public abstract void writeStructEnd() throws TException;{code}
In this class this method is overridden by an empty implementation and already
can not throw exceptions
{code:java}
public void writeMessageEnd() {
}{code}
I want to extend the capabilities of the class TBinaryProtocol and override
this method. But I can not throw an exception from it or call a method that can
throw an exception
A similar remark on all methods of a class TBinaryProtocol with an empty body
was:
In base class TProtocol method writeMessageEnd can throw exception TException
{{public abstract void writeStructEnd() throws TException;}}
In this class this method is overridden by an empty implementation and already
can not throw exceptions
{{public void writeMessageEnd() {}}
{{}}}
I want to extend the capabilities of the class TBinaryProtocol and override
this method. But I can not throw an exception from it or call a method that can
throw an exception
A similar remark on all methods of a class TBinaryProtocol with an empty body
> TBinaryProtocol.writeMessageEnd isn't trowable exception
>
>
> Key: THRIFT-4481
> URL: https://issues.apache.org/jira/browse/THRIFT-4481
> Project: Thrift
> Issue Type: Bug
> Components: Java - Library
>Affects Versions: 0.11.0
>Reporter: Anton Shchyrov
>Priority: Major
>
> In base class TProtocol method writeMessageEnd can throw exception TException
> {code:java}
> public abstract void writeStructEnd() throws TException;{code}
> In this class this method is overridden by an empty implementation and
> already can not throw exceptions
> {code:java}
> public void writeMessageEnd() {
> }{code}
> I want to extend the capabilities of the class TBinaryProtocol and override
> this method. But I can not throw an exception from it or call a method that
> can throw an exception
> A similar remark on all methods of a class TBinaryProtocol with an empty body
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (THRIFT-4518) The exception text disappears
[
https://issues.apache.org/jira/browse/THRIFT-4518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Shchyrov updated THRIFT-4518:
---
Description:
When the server method throws an exception TException, only the string
"Internal error processing \{MethodName}"
and does not reach the original message. Problem in the module
ProcessFunction.java. Instead of a code
{code:java}
} catch (Exception ex) {
LOGGER.error("Internal error processing " + getMethodName(), ex);
if(!isOneway()){
result = new TApplicationException(TApplicationException.INTERNAL_ERROR,
"Internal error processing " + getMethodName());
msgType = TMessageType.EXCEPTION;
}
}
{code}
There should be a code of
{code:java}
} catch (Exception ex) {
LOGGER.error("Internal error processing " + getMethodName(), ex);
if(!isOneway()){
result = new TApplicationException(TApplicationException.INTERNAL_ERROR,
String.format("Internal error processing. Method: %s, message: %s",
getMethodName(), ex.getMessage())); msgType = TMessageType.EXCEPTION;
}
}
{code}
In the server written on Delphi such problem is not present and there the text
of an exception is transferred correctly
was:
When the server method throws an exception TException, only the string
"Internal error processing \{MethodName}"
and does not reach the original message. Problem in the module
ProcessFunction.java. Instead of a code
{code:java}
} catch (Exception ex) {
LOGGER.error("Internal error processing " + getMethodName(), ex);
if(!isOneway()){
result = new TApplicationException(TApplicationException.INTERNAL_ERROR,
"Internal error processing " + getMethodName()); msgType =
TMessageType.EXCEPTION;
}
}
{code}
There should be a code of
} catch (Exception ex) {
LOGGER.error("Internal error processing " + getMethodName(), ex);
if(!isOneway())
{ result = new TApplicationException(TApplicationException.INTERNAL_ERROR,
String.format("Internal error processing. Method: %s, message: %s",
getMethodName(), ex.getMessage())); msgType = TMessageType.EXCEPTION; }
}
In the server written on Delphi such problem is not present and there the text
of an exception is transferred correctly
> The exception text disappears
> -
>
> Key: THRIFT-4518
> URL: https://issues.apache.org/jira/browse/THRIFT-4518
> Project: Thrift
> Issue Type: Bug
> Components: Java - Library
>Affects Versions: 0.11.0
>Reporter: Anton Shchyrov
>Priority: Major
> Labels: exception, exception-handling, patch, server
> Attachments: ProcessFunction.java.patch
>
>
> When the server method throws an exception TException, only the string
> "Internal error processing \{MethodName}"
> and does not reach the original message. Problem in the module
> ProcessFunction.java. Instead of a code
> {code:java}
> } catch (Exception ex) {
> LOGGER.error("Internal error processing " + getMethodName(), ex);
> if(!isOneway()){
> result = new TApplicationException(TApplicationException.INTERNAL_ERROR,
> "Internal error processing " + getMethodName());
> msgType = TMessageType.EXCEPTION;
> }
> }
> {code}
> There should be a code of
>
> {code:java}
> } catch (Exception ex) {
> LOGGER.error("Internal error processing " + getMethodName(), ex);
> if(!isOneway()){
> result = new TApplicationException(TApplicationException.INTERNAL_ERROR,
> String.format("Internal error processing. Method: %s, message: %s",
> getMethodName(), ex.getMessage())); msgType = TMessageType.EXCEPTION;
> }
> }
> {code}
>
> In the server written on Delphi such problem is not present and there the
> text of an exception is transferred correctly
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (THRIFT-4518) The exception text disappears
[
https://issues.apache.org/jira/browse/THRIFT-4518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Shchyrov updated THRIFT-4518:
---
Description:
When the server method throws an exception TException, only the string
"Internal error processing \{MethodName}"
and does not reach the original message. Problem in the module
ProcessFunction.java. Instead of a code
{code:java}
} catch (Exception ex) {
LOGGER.error("Internal error processing " + getMethodName(), ex);
if(!isOneway()){
result = new TApplicationException(TApplicationException.INTERNAL_ERROR,
"Internal error processing " + getMethodName()); msgType =
TMessageType.EXCEPTION;
}
}
{code}
There should be a code of
} catch (Exception ex) {
LOGGER.error("Internal error processing " + getMethodName(), ex);
if(!isOneway())
{ result = new TApplicationException(TApplicationException.INTERNAL_ERROR,
String.format("Internal error processing. Method: %s, message: %s",
getMethodName(), ex.getMessage())); msgType = TMessageType.EXCEPTION; }
}
In the server written on Delphi such problem is not present and there the text
of an exception is transferred correctly
was:
When the server method throws an exception TException, only the string
"Internal error processing \{MethodName}"
and does not reach the original message. Problem in the module
ProcessFunction.java. Instead of a code
} catch (Exception ex) {
LOGGER.error("Internal error processing " + getMethodName(), ex);
if(!isOneway()) {
result = new TApplicationException(TApplicationException.INTERNAL_ERROR,
"Internal error processing " + getMethodName());
msgType = TMessageType.EXCEPTION;
}
}
There should be a code of
} catch (Exception ex) {
LOGGER.error("Internal error processing " + getMethodName(), ex);
if(!isOneway()) {
result = new TApplicationException(TApplicationException.INTERNAL_ERROR,
String.format("Internal error processing. Method: %s, message: %s",
getMethodName(), ex.getMessage()));
msgType = TMessageType.EXCEPTION;
}
}
In the server written on Delphi such problem is not present and there the text
of an exception is transferred correctly
> The exception text disappears
> -
>
> Key: THRIFT-4518
> URL: https://issues.apache.org/jira/browse/THRIFT-4518
> Project: Thrift
> Issue Type: Bug
> Components: Java - Library
>Affects Versions: 0.11.0
>Reporter: Anton Shchyrov
>Priority: Major
> Labels: exception, exception-handling, patch, server
> Attachments: ProcessFunction.java.patch
>
>
> When the server method throws an exception TException, only the string
> "Internal error processing \{MethodName}"
> and does not reach the original message. Problem in the module
> ProcessFunction.java. Instead of a code
>
> {code:java}
> } catch (Exception ex) {
> LOGGER.error("Internal error processing " + getMethodName(), ex);
> if(!isOneway()){
> result = new TApplicationException(TApplicationException.INTERNAL_ERROR,
> "Internal error processing " + getMethodName()); msgType =
> TMessageType.EXCEPTION;
> }
> }
> {code}
> There should be a code of
> } catch (Exception ex) {
> LOGGER.error("Internal error processing " + getMethodName(), ex);
> if(!isOneway())
> { result = new
> TApplicationException(TApplicationException.INTERNAL_ERROR,
> String.format("Internal error processing. Method: %s, message: %s",
> getMethodName(), ex.getMessage())); msgType = TMessageType.EXCEPTION; }
> }
> In the server written on Delphi such problem is not present and there the
> text of an exception is transferred correctly
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4429) Make TThreadPoolServer.executorService_ available in inherited classes and refactor methods to be able customization
[ https://issues.apache.org/jira/browse/THRIFT-4429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16397369#comment-16397369 ] ASF GitHub Bot commented on THRIFT-4429: Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1485 > Make TThreadPoolServer.executorService_ available in inherited classes and > refactor methods to be able customization > > > Key: THRIFT-4429 > URL: https://issues.apache.org/jira/browse/THRIFT-4429 > Project: Thrift > Issue Type: Improvement > Components: Java - Library >Affects Versions: 0.11.0 >Reporter: Dmitry Volodin >Assignee: James E. King, III >Priority: Minor > Fix For: 0.12.0 > > > In some cases (for example in Apache Camel component for Thrift) there is a > requirement, when it is necessary not only to transfer executorService from > the external system through the Args in TThreadPoolServer , but to organize > control them from outside. In this case, it's possible to create a class > which is inherited from TThreadPoolServer, but not possible to access invoker > in overloaded method. > Also a good approach to split main execution code to the several methods to > be able to invoke them separately in appropriate sequence. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (THRIFT-4429) Make TThreadPoolServer.executorService_ available in inherited classes and refactor methods to be able customization
[ https://issues.apache.org/jira/browse/THRIFT-4429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III resolved THRIFT-4429. Resolution: Fixed Fix Version/s: 0.12.0 Committed - thanks. > Make TThreadPoolServer.executorService_ available in inherited classes and > refactor methods to be able customization > > > Key: THRIFT-4429 > URL: https://issues.apache.org/jira/browse/THRIFT-4429 > Project: Thrift > Issue Type: Improvement > Components: Java - Library >Affects Versions: 0.11.0 >Reporter: Dmitry Volodin >Assignee: James E. King, III >Priority: Minor > Fix For: 0.12.0 > > > In some cases (for example in Apache Camel component for Thrift) there is a > requirement, when it is necessary not only to transfer executorService from > the external system through the Args in TThreadPoolServer , but to organize > control them from outside. In this case, it's possible to create a class > which is inherited from TThreadPoolServer, but not possible to access invoker > in overloaded method. > Also a good approach to split main execution code to the several methods to > be able to invoke them separately in appropriate sequence. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (THRIFT-4429) Make TThreadPoolServer.executorService_ available in inherited classes and refactor methods to be able customization
[ https://issues.apache.org/jira/browse/THRIFT-4429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III reassigned THRIFT-4429: -- Assignee: James E. King, III > Make TThreadPoolServer.executorService_ available in inherited classes and > refactor methods to be able customization > > > Key: THRIFT-4429 > URL: https://issues.apache.org/jira/browse/THRIFT-4429 > Project: Thrift > Issue Type: Improvement > Components: Java - Library >Affects Versions: 0.11.0 >Reporter: Dmitry Volodin >Assignee: James E. King, III >Priority: Minor > Fix For: 0.12.0 > > > In some cases (for example in Apache Camel component for Thrift) there is a > requirement, when it is necessary not only to transfer executorService from > the external system through the Args in TThreadPoolServer , but to organize > control them from outside. In this case, it's possible to create a class > which is inherited from TThreadPoolServer, but not possible to access invoker > in overloaded method. > Also a good approach to split main execution code to the several methods to > be able to invoke them separately in appropriate sequence. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] thrift pull request #1485: THRIFT-4429: Make TThreadPoolServer.executorServi...
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1485 ---
[jira] [Commented] (THRIFT-4429) Make TThreadPoolServer.executorService_ available in inherited classes and refactor methods to be able customization
[ https://issues.apache.org/jira/browse/THRIFT-4429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16397365#comment-16397365 ] ASF GitHub Bot commented on THRIFT-4429: Github user dmvolod commented on the issue: https://github.com/apache/thrift/pull/1485 Thanks a lot for review. > Make TThreadPoolServer.executorService_ available in inherited classes and > refactor methods to be able customization > > > Key: THRIFT-4429 > URL: https://issues.apache.org/jira/browse/THRIFT-4429 > Project: Thrift > Issue Type: Improvement > Components: Java - Library >Affects Versions: 0.11.0 >Reporter: Dmitry Volodin >Priority: Minor > > In some cases (for example in Apache Camel component for Thrift) there is a > requirement, when it is necessary not only to transfer executorService from > the external system through the Args in TThreadPoolServer , but to organize > control them from outside. In this case, it's possible to create a class > which is inherited from TThreadPoolServer, but not possible to access invoker > in overloaded method. > Also a good approach to split main execution code to the several methods to > be able to invoke them separately in appropriate sequence. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] thrift issue #1485: THRIFT-4429: Make TThreadPoolServer.executorService_ ava...
Github user dmvolod commented on the issue: https://github.com/apache/thrift/pull/1485 Thanks a lot for review. ---
[GitHub] thrift issue #1480: [nodejs] Fix issue with connection failures silently fai...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1480 @bananer apart from missing any testing, is this a reasonable enhancement? ---
[jira] [Created] (THRIFT-4518) The exception text disappears
Anton Shchyrov created THRIFT-4518:
--
Summary: The exception text disappears
Key: THRIFT-4518
URL: https://issues.apache.org/jira/browse/THRIFT-4518
Project: Thrift
Issue Type: Bug
Components: Java - Library
Affects Versions: 0.11.0
Reporter: Anton Shchyrov
Attachments: ProcessFunction.java.patch
When the server method throws an exception TException, only the string
"Internal error processing \{MethodName}"
and does not reach the original message. Problem in the module
ProcessFunction.java. Instead of a code
} catch (Exception ex) {
LOGGER.error("Internal error processing " + getMethodName(), ex);
if(!isOneway()) {
result = new TApplicationException(TApplicationException.INTERNAL_ERROR,
"Internal error processing " + getMethodName());
msgType = TMessageType.EXCEPTION;
}
}
There should be a code of
} catch (Exception ex) {
LOGGER.error("Internal error processing " + getMethodName(), ex);
if(!isOneway()) {
result = new TApplicationException(TApplicationException.INTERNAL_ERROR,
String.format("Internal error processing. Method: %s, message: %s",
getMethodName(), ex.getMessage()));
msgType = TMessageType.EXCEPTION;
}
}
In the server written on Delphi such problem is not present and there the text
of an exception is transferred correctly
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4187) Dart -> Rust Framed cross tests fail
[ https://issues.apache.org/jira/browse/THRIFT-4187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16397190#comment-16397190 ] ASF GitHub Bot commented on THRIFT-4187: Github user allengeorge commented on the issue: https://github.com/apache/thrift/pull/1269 Yup. Will do. I'm a gonna set myself a target to get it done by end of next week. I've been lax on this :/ > Dart -> Rust Framed cross tests fail > > > Key: THRIFT-4187 > URL: https://issues.apache.org/jira/browse/THRIFT-4187 > Project: Thrift > Issue Type: Bug > Components: Rust - Library >Reporter: Allen George >Assignee: Allen George >Priority: Minor > > For some reason the Dart (client) -> Rust (server) framed-transport cross > tests fail. Initial investigation shows that *somehow* the dart client think > the socket was closed, which means it doesn't read the message from the > underlying transport. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] thrift issue #1269: THRIFT-4187 Allow dart framed transport to read incomple...
Github user allengeorge commented on the issue: https://github.com/apache/thrift/pull/1269 Yup. Will do. I'm a gonna set myself a target to get it done by end of next week. I've been lax on this :/ ---
[GitHub] thrift issue #1058: Node.js: Set/unset client seqid for json_protocol and co...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1058 In general I want to make sure all clients send a seqid and all servers put that seqid in the result. Without this we won't be able to have clients that can have multiple outstanding requests in the future. ---
[GitHub] thrift issue #1058: Node.js: Set/unset client seqid for json_protocol and co...
Github user bananer commented on the issue: https://github.com/apache/thrift/pull/1058 @jeking3 To be honest, I don't know why this is useful/necessary. I think there is no need for a seqid because the connection between request and response is handled through callbacks automatically. ---
[GitHub] thrift pull request #1479: THRIFT-4474: generate PHP code use PSR-4 style de...
Github user dcelasun commented on a diff in the pull request: https://github.com/apache/thrift/pull/1479#discussion_r174183088 --- Diff: lib/php/README.md --- @@ -20,34 +19,46 @@ KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -Using Thrift with PHP -= +# Using Thrift with PHP Thrift requires PHP 5. Thrift makes as few assumptions about your PHP environment as possible while trying to make some more advanced PHP features (i.e. APC cacheing using asbolute path URLs) as simple as possible. To use Thrift in your PHP codebase, take the following steps: -#1) Copy all of thrift/lib/php/lib into your PHP codebase -#2) Configure Symfony Autoloader (or whatever you usually use) +1. Copy all of thrift/lib/php/lib into your PHP codebase +2. Configure Symfony Autoloader (or whatever you usually use) After that, you have to manually include the Thrift package created by the compiler: +``` require_once 'packages/Service/Service.php'; require_once 'packages/Service/Types.php'; +``` -Dependencies - +# Dependencies PHP_INT_SIZE - This built-in signals whether your architecture is 32 or 64 bit and is - used by the TBinaryProtocol to properly use pack() and unpack() to - serialize data. +This built-in signals whether your architecture is 32 or 64 bit and is +used by the TBinaryProtocol to properly use pack() and unpack() to +serialize data. apc_fetch(), apc_store() - APC cache is used by the TSocketPool class. If you do not have APC installed, - Thrift will fill in null stub function definitions. +APC cache is used by the TSocketPool class. If you do not have APC installed, +Thrift will fill in null stub function definitions. + +# Breaking Changes + +## 0.12.0 + +1. For thrift compiler, `psr4` flag is opened default, generated code match psr4 code struct. --- End diff -- Better phrasing: `PSR-4` (make this a link to https://www.php-fig.org/psr/psr-4/) loader is now the default. If you want to use class maps instead, use `-gen php:classmap`. ---
[jira] [Commented] (THRIFT-4474) PHP generator use PSR-4 default
[
https://issues.apache.org/jira/browse/THRIFT-4474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16397141#comment-16397141
]
ASF GitHub Bot commented on THRIFT-4474:
Github user dcelasun commented on a diff in the pull request:
https://github.com/apache/thrift/pull/1479#discussion_r174183088
--- Diff: lib/php/README.md ---
@@ -20,34 +19,46 @@ KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-Using Thrift with PHP
-=
+# Using Thrift with PHP
Thrift requires PHP 5. Thrift makes as few assumptions about your PHP
environment as possible while trying to make some more advanced PHP
features (i.e. APC cacheing using asbolute path URLs) as simple as
possible.
To use Thrift in your PHP codebase, take the following steps:
-#1) Copy all of thrift/lib/php/lib into your PHP codebase
-#2) Configure Symfony Autoloader (or whatever you usually use)
+1. Copy all of thrift/lib/php/lib into your PHP codebase
+2. Configure Symfony Autoloader (or whatever you usually use)
After that, you have to manually include the Thrift package
created by the compiler:
+```
require_once 'packages/Service/Service.php';
require_once 'packages/Service/Types.php';
+```
-Dependencies
-
+# Dependencies
PHP_INT_SIZE
- This built-in signals whether your architecture is 32 or 64 bit and is
- used by the TBinaryProtocol to properly use pack() and unpack() to
- serialize data.
+This built-in signals whether your architecture is 32 or 64 bit and is
+used by the TBinaryProtocol to properly use pack() and unpack() to
+serialize data.
apc_fetch(), apc_store()
- APC cache is used by the TSocketPool class. If you do not have APC
installed,
- Thrift will fill in null stub function definitions.
+APC cache is used by the TSocketPool class. If you do not have APC
installed,
+Thrift will fill in null stub function definitions.
+
+# Breaking Changes
+
+## 0.12.0
+
+1. For thrift compiler, `psr4` flag is opened default, generated code
match psr4 code struct.
--- End diff --
Better phrasing:
`PSR-4` (make this a link to https://www.php-fig.org/psr/psr-4/) loader is
now the default. If you want to use class maps instead, use `-gen php:classmap`.
> PHP generator use PSR-4 default
> ---
>
> Key: THRIFT-4474
> URL: https://issues.apache.org/jira/browse/THRIFT-4474
> Project: Thrift
> Issue Type: Improvement
> Components: PHP - Compiler
>Reporter: Robert Lu
>Assignee: Robert Lu
>Priority: Major
>
> Before, PHP generator generate php files like {{Types.php}}, {{Service.php}}.
> Those can only be load via
> [{{classmap}}|https://getcomposer.org/doc/04-schema.md#classmap] method. The
> latest PSR about autoload is [PSR-4|http://www.php-fig.org/psr/psr-4/].
> thrift compiler can generate PSR-4 code default, if want old-style code(which
> can only load via classmap), add {{classmap}} option.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] thrift pull request #1479: THRIFT-4474: generate PHP code use PSR-4 style de...
Github user dcelasun commented on a diff in the pull request:
https://github.com/apache/thrift/pull/1479#discussion_r174183533
--- Diff: lib/php/README.md ---
@@ -20,34 +19,46 @@ KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-Using Thrift with PHP
-=
+# Using Thrift with PHP
Thrift requires PHP 5. Thrift makes as few assumptions about your PHP
environment as possible while trying to make some more advanced PHP
features (i.e. APC cacheing using asbolute path URLs) as simple as
possible.
To use Thrift in your PHP codebase, take the following steps:
-#1) Copy all of thrift/lib/php/lib into your PHP codebase
-#2) Configure Symfony Autoloader (or whatever you usually use)
+1. Copy all of thrift/lib/php/lib into your PHP codebase
+2. Configure Symfony Autoloader (or whatever you usually use)
After that, you have to manually include the Thrift package
created by the compiler:
+```
require_once 'packages/Service/Service.php';
require_once 'packages/Service/Types.php';
+```
-Dependencies
-
+# Dependencies
PHP_INT_SIZE
- This built-in signals whether your architecture is 32 or 64 bit and is
- used by the TBinaryProtocol to properly use pack() and unpack() to
- serialize data.
+This built-in signals whether your architecture is 32 or 64 bit and is
+used by the TBinaryProtocol to properly use pack() and unpack() to
+serialize data.
apc_fetch(), apc_store()
- APC cache is used by the TSocketPool class. If you do not have APC
installed,
- Thrift will fill in null stub function definitions.
+APC cache is used by the TSocketPool class. If you do not have APC
installed,
+Thrift will fill in null stub function definitions.
+
+# Breaking Changes
+
+## 0.12.0
+
+1. For thrift compiler, `psr4` flag is opened default, generated code
match psr4 code struct.
+
+If you want old-style directory struct, use `classmap` option. (i.e.
`-gen php:classmap`)
+
+2. For ThriftClassloader, if use psr4 code struct, must use
`$thriftClassLoader->registerNamespace('namespace', '')` to register
autoload.
--- End diff --
Better phrasing:
If using PSR4, use `$thriftClassLoader->registerNamespace('namespace',
'')` instead of `$thriftClassLoader->registerDefinition('namespace',
'')`.
---
[jira] [Commented] (THRIFT-4474) PHP generator use PSR-4 default
[
https://issues.apache.org/jira/browse/THRIFT-4474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16397140#comment-16397140
]
ASF GitHub Bot commented on THRIFT-4474:
Github user dcelasun commented on a diff in the pull request:
https://github.com/apache/thrift/pull/1479#discussion_r174183533
--- Diff: lib/php/README.md ---
@@ -20,34 +19,46 @@ KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-Using Thrift with PHP
-=
+# Using Thrift with PHP
Thrift requires PHP 5. Thrift makes as few assumptions about your PHP
environment as possible while trying to make some more advanced PHP
features (i.e. APC cacheing using asbolute path URLs) as simple as
possible.
To use Thrift in your PHP codebase, take the following steps:
-#1) Copy all of thrift/lib/php/lib into your PHP codebase
-#2) Configure Symfony Autoloader (or whatever you usually use)
+1. Copy all of thrift/lib/php/lib into your PHP codebase
+2. Configure Symfony Autoloader (or whatever you usually use)
After that, you have to manually include the Thrift package
created by the compiler:
+```
require_once 'packages/Service/Service.php';
require_once 'packages/Service/Types.php';
+```
-Dependencies
-
+# Dependencies
PHP_INT_SIZE
- This built-in signals whether your architecture is 32 or 64 bit and is
- used by the TBinaryProtocol to properly use pack() and unpack() to
- serialize data.
+This built-in signals whether your architecture is 32 or 64 bit and is
+used by the TBinaryProtocol to properly use pack() and unpack() to
+serialize data.
apc_fetch(), apc_store()
- APC cache is used by the TSocketPool class. If you do not have APC
installed,
- Thrift will fill in null stub function definitions.
+APC cache is used by the TSocketPool class. If you do not have APC
installed,
+Thrift will fill in null stub function definitions.
+
+# Breaking Changes
+
+## 0.12.0
+
+1. For thrift compiler, `psr4` flag is opened default, generated code
match psr4 code struct.
+
+If you want old-style directory struct, use `classmap` option. (i.e.
`-gen php:classmap`)
+
+2. For ThriftClassloader, if use psr4 code struct, must use
`$thriftClassLoader->registerNamespace('namespace', '')` to register
autoload.
--- End diff --
Better phrasing:
If using PSR4, use `$thriftClassLoader->registerNamespace('namespace',
'')` instead of `$thriftClassLoader->registerDefinition('namespace',
'')`.
> PHP generator use PSR-4 default
> ---
>
> Key: THRIFT-4474
> URL: https://issues.apache.org/jira/browse/THRIFT-4474
> Project: Thrift
> Issue Type: Improvement
> Components: PHP - Compiler
>Reporter: Robert Lu
>Assignee: Robert Lu
>Priority: Major
>
> Before, PHP generator generate php files like {{Types.php}}, {{Service.php}}.
> Those can only be load via
> [{{classmap}}|https://getcomposer.org/doc/04-schema.md#classmap] method. The
> latest PSR about autoload is [PSR-4|http://www.php-fig.org/psr/psr-4/].
> thrift compiler can generate PSR-4 code default, if want old-style code(which
> can only load via classmap), add {{classmap}} option.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4474) PHP generator use PSR-4 default
[
https://issues.apache.org/jira/browse/THRIFT-4474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16397139#comment-16397139
]
ASF GitHub Bot commented on THRIFT-4474:
Github user dcelasun commented on the issue:
https://github.com/apache/thrift/pull/1479
Added some doc comments. The actual code looks fine to me.
> PHP generator use PSR-4 default
> ---
>
> Key: THRIFT-4474
> URL: https://issues.apache.org/jira/browse/THRIFT-4474
> Project: Thrift
> Issue Type: Improvement
> Components: PHP - Compiler
>Reporter: Robert Lu
>Assignee: Robert Lu
>Priority: Major
>
> Before, PHP generator generate php files like {{Types.php}}, {{Service.php}}.
> Those can only be load via
> [{{classmap}}|https://getcomposer.org/doc/04-schema.md#classmap] method. The
> latest PSR about autoload is [PSR-4|http://www.php-fig.org/psr/psr-4/].
> thrift compiler can generate PSR-4 code default, if want old-style code(which
> can only load via classmap), add {{classmap}} option.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] thrift issue #1479: THRIFT-4474: generate PHP code use PSR-4 style default
Github user dcelasun commented on the issue: https://github.com/apache/thrift/pull/1479 Added some doc comments. The actual code looks fine to me. ---
[jira] [Updated] (THRIFT-4509) js and nodejs libraries need to be refreshed with current libraries
[
https://issues.apache.org/jira/browse/THRIFT-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III updated THRIFT-4509:
---
Component/s: (was: Node.js - Library)
> js and nodejs libraries need to be refreshed with current libraries
> ---
>
> Key: THRIFT-4509
> URL: https://issues.apache.org/jira/browse/THRIFT-4509
> Project: Thrift
> Issue Type: Improvement
> Components: JavaScript - Library
>Affects Versions: 0.11.0
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Critical
> Labels: security
> Fix For: 0.12.0
>
>
> The npm libraries that our js and nodejs depend on are starting to go end of
> life.
> As it stands the build is just barely holding together, and as of 5 hours ago
> the "ws" package dropped support for node < 4.5.0; Ubuntu Xenial 16.04 LTS
> uses node v4.2.6.
> There are other issues:
> {noformat}
> Running "shell:InstallThriftNodeJSDep" (shell) task
> WARN engine hawk@6.0.2: wanted: {"node":">=4.5.0"} (current:
> {"node":"4.2.6","npm":"3.5.2"})
> npm WARN deprecated minimatch@0.3.0: Please update to minimatch 3.0.2 or
> higher to avoid a RegExp DoS issue
> npm WARN deprecated minimatch@0.2.14: Please update to minimatch 3.0.2 or
> higher to avoid a RegExp DoS issue
> npm WARN deprecated minimatch@0.4.0: Please update to minimatch 3.0.2 or
> higher to avoid a RegExp DoS issue
> npm WARN deprecated minimatch@2.0.10: Please update to minimatch 3.0.2 or
> higher to avoid a RegExp DoS issue
> npm WARN deprecated node-uuid@1.4.8: Use uuid module instead
> npm WARN deprecated tough-cookie@2.2.2: ReDoS vulnerability parsing
> Set-Cookie https://nodesecurity.io/advisories/130
> {noformat}
> Some of these are security issues.
> In addition the js module depends on
> https://www.npmjs.com/package/grunt-external-daemon which requires grunt
> 0.4.0, which is really old and may contribute to requiring older versions of
> things that are posting deprecations.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (THRIFT-4509) js and nodejs libraries need to be refreshed with current libraries
[
https://issues.apache.org/jira/browse/THRIFT-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III resolved THRIFT-4509.
Resolution: Fixed
Assignee: James E. King, III
Fix Version/s: 0.12.0
Changes committed that break these old dependencies, thank you!
> js and nodejs libraries need to be refreshed with current libraries
> ---
>
> Key: THRIFT-4509
> URL: https://issues.apache.org/jira/browse/THRIFT-4509
> Project: Thrift
> Issue Type: Improvement
> Components: JavaScript - Library
>Affects Versions: 0.11.0
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Critical
> Labels: security
> Fix For: 0.12.0
>
>
> The npm libraries that our js and nodejs depend on are starting to go end of
> life.
> As it stands the build is just barely holding together, and as of 5 hours ago
> the "ws" package dropped support for node < 4.5.0; Ubuntu Xenial 16.04 LTS
> uses node v4.2.6.
> There are other issues:
> {noformat}
> Running "shell:InstallThriftNodeJSDep" (shell) task
> WARN engine hawk@6.0.2: wanted: {"node":">=4.5.0"} (current:
> {"node":"4.2.6","npm":"3.5.2"})
> npm WARN deprecated minimatch@0.3.0: Please update to minimatch 3.0.2 or
> higher to avoid a RegExp DoS issue
> npm WARN deprecated minimatch@0.2.14: Please update to minimatch 3.0.2 or
> higher to avoid a RegExp DoS issue
> npm WARN deprecated minimatch@0.4.0: Please update to minimatch 3.0.2 or
> higher to avoid a RegExp DoS issue
> npm WARN deprecated minimatch@2.0.10: Please update to minimatch 3.0.2 or
> higher to avoid a RegExp DoS issue
> npm WARN deprecated node-uuid@1.4.8: Use uuid module instead
> npm WARN deprecated tough-cookie@2.2.2: ReDoS vulnerability parsing
> Set-Cookie https://nodesecurity.io/advisories/130
> {noformat}
> Some of these are security issues.
> In addition the js module depends on
> https://www.npmjs.com/package/grunt-external-daemon which requires grunt
> 0.4.0, which is really old and may contribute to requiring older versions of
> things that are posting deprecations.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4187) Dart -> Rust Framed cross tests fail
[ https://issues.apache.org/jira/browse/THRIFT-4187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16397134#comment-16397134 ] ASF GitHub Bot commented on THRIFT-4187: Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1269 This needs to be rebased and completed. > Dart -> Rust Framed cross tests fail > > > Key: THRIFT-4187 > URL: https://issues.apache.org/jira/browse/THRIFT-4187 > Project: Thrift > Issue Type: Bug > Components: Rust - Library >Reporter: Allen George >Assignee: Allen George >Priority: Minor > > For some reason the Dart (client) -> Rust (server) framed-transport cross > tests fail. Initial investigation shows that *somehow* the dart client think > the socket was closed, which means it doesn't read the message from the > underlying transport. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] thrift issue #1269: THRIFT-4187 Allow dart framed transport to read incomple...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1269 This needs to be rebased and completed. ---
[jira] [Commented] (THRIFT-4509) js and nodejs libraries need to be refreshed with current libraries
[
https://issues.apache.org/jira/browse/THRIFT-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16397132#comment-16397132
]
ASF GitHub Bot commented on THRIFT-4509:
Github user bananer commented on the issue:
https://github.com/apache/thrift/pull/1506
@jeking3 I think all the problems mentioned in THRIFT-4509 are resolved
now. With the package-lock being included now, there should also be less random
build failures. The node and js parts of thrift could still use some cleanup
and modernization, but I will leave that for a separate ticket.
> js and nodejs libraries need to be refreshed with current libraries
> ---
>
> Key: THRIFT-4509
> URL: https://issues.apache.org/jira/browse/THRIFT-4509
> Project: Thrift
> Issue Type: Improvement
> Components: JavaScript - Library, Node.js - Library
>Affects Versions: 0.11.0
>Reporter: James E. King, III
>Priority: Critical
> Labels: security
>
> The npm libraries that our js and nodejs depend on are starting to go end of
> life.
> As it stands the build is just barely holding together, and as of 5 hours ago
> the "ws" package dropped support for node < 4.5.0; Ubuntu Xenial 16.04 LTS
> uses node v4.2.6.
> There are other issues:
> {noformat}
> Running "shell:InstallThriftNodeJSDep" (shell) task
> WARN engine hawk@6.0.2: wanted: {"node":">=4.5.0"} (current:
> {"node":"4.2.6","npm":"3.5.2"})
> npm WARN deprecated minimatch@0.3.0: Please update to minimatch 3.0.2 or
> higher to avoid a RegExp DoS issue
> npm WARN deprecated minimatch@0.2.14: Please update to minimatch 3.0.2 or
> higher to avoid a RegExp DoS issue
> npm WARN deprecated minimatch@0.4.0: Please update to minimatch 3.0.2 or
> higher to avoid a RegExp DoS issue
> npm WARN deprecated minimatch@2.0.10: Please update to minimatch 3.0.2 or
> higher to avoid a RegExp DoS issue
> npm WARN deprecated node-uuid@1.4.8: Use uuid module instead
> npm WARN deprecated tough-cookie@2.2.2: ReDoS vulnerability parsing
> Set-Cookie https://nodesecurity.io/advisories/130
> {noformat}
> Some of these are security issues.
> In addition the js module depends on
> https://www.npmjs.com/package/grunt-external-daemon which requires grunt
> 0.4.0, which is really old and may contribute to requiring older versions of
> things that are posting deprecations.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] thrift issue #1506: THRIFT-4509: grunt update (rebased)
Github user bananer commented on the issue: https://github.com/apache/thrift/pull/1506 @jeking3 I think all the problems mentioned in THRIFT-4509 are resolved now. With the package-lock being included now, there should also be less random build failures. The node and js parts of thrift could still use some cleanup and modernization, but I will leave that for a separate ticket. ---
[GitHub] thrift issue #1141: support for timeout in node http connection
Github user bananer commented on the issue: https://github.com/apache/thrift/pull/1141 @jeking3 it looks like a simple change now that support for node 4 can be dropped. However, I'm not sure what the expected behaviour in case of a timeout should be. Just from looking at the code it does not seem like error handling is triggered by the call to `req.abort()`⦠---
[jira] [Commented] (THRIFT-3916) Errors thrown from JavaScript client is strings and not errors
[
https://issues.apache.org/jira/browse/THRIFT-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16397108#comment-16397108
]
ASF GitHub Bot commented on THRIFT-3916:
Github user bananer commented on the issue:
https://github.com/apache/thrift/pull/1075
@jeking3 This is a well-intended change but I think it is not implemented
correctly and will break error handling for users.
In some places in the compiler the input to `render_recv_throw` already is
a proper `Error` (the JS exception class), e.g.
https://github.com/apache/thrift/blob/2b09dfed9c6b858571e7d8829a2b4a4bcda18d6a/compiler/cpp/src/thrift/generate/t_js_generator.cc#L1648-L1652
This is not the case for other places:
https://github.com/apache/thrift/blob/2b09dfed9c6b858571e7d8829a2b4a4bcda18d6a/compiler/cpp/src/thrift/generate/t_js_generator.cc#L1673
The proper way of doing this would be to inspect all usages of
`render_recv_throw` to see if the argument needs to be wrapped in `new
Error(…)`. Still then, this could break error handling that relies on these
cases being strings.
> Errors thrown from JavaScript client is strings and not errors
> --
>
> Key: THRIFT-3916
> URL: https://issues.apache.org/jira/browse/THRIFT-3916
> Project: Thrift
> Issue Type: Bug
> Components: JavaScript - Compiler
>Reporter: Simen Bekkhus
>Priority: Minor
> Labels: javascript
>
> In JavaScript, you can {{throw}} any object, including strings, but to get
> stack traces one should throw {{Errors}}.
> The generated JS code throws the error string directly, instead of wrapping
> it in {{new Error}}.
> Node core _only_ rejects with/throws Errors, never strings, and Thrift should
> follow the same standard.
> https://nodejs.org/api/errors.html#errors_class_error
> {quote}
> All errors generated by Node.js, including all System and JavaScript errors,
> will either be instances of, or inherit from, the Error class.
> {quote}
> PR for the change [here|https://github.com/apache/thrift/pull/1075].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] thrift issue #1075: THRIFT-3916 Throw proper errors from JS, not strings
Github user bananer commented on the issue: https://github.com/apache/thrift/pull/1075 @jeking3 This is a well-intended change but I think it is not implemented correctly and will break error handling for users. In some places in the compiler the input to `render_recv_throw` already is a proper `Error` (the JS exception class), e.g. https://github.com/apache/thrift/blob/2b09dfed9c6b858571e7d8829a2b4a4bcda18d6a/compiler/cpp/src/thrift/generate/t_js_generator.cc#L1648-L1652 This is not the case for other places: https://github.com/apache/thrift/blob/2b09dfed9c6b858571e7d8829a2b4a4bcda18d6a/compiler/cpp/src/thrift/generate/t_js_generator.cc#L1673 The proper way of doing this would be to inspect all usages of `render_recv_throw` to see if the argument needs to be wrapped in `new Error(â¦)`. Still then, this could break error handling that relies on these cases being strings. ---
[jira] [Commented] (THRIFT-4476) Typecasting problem on list items
[
https://issues.apache.org/jira/browse/THRIFT-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16397065#comment-16397065
]
ASF GitHub Bot commented on THRIFT-4476:
Github user ozymaxx commented on the issue:
https://github.com/apache/thrift/pull/1496
I have just disabled my new tests on `MSVC2013` builders and kicked a
build. Let's see what happens.
If the tests also fail on the `CYGWIN` machine, I will also write out new
tests for the x86 machines. However, the issue is not about the architecture,
only some modifiers seem to be overlooked in the generators.
> Typecasting problem on list items
> -
>
> Key: THRIFT-4476
> URL: https://issues.apache.org/jira/browse/THRIFT-4476
> Project: Thrift
> Issue Type: Bug
> Components: Java - Compiler
>Affects Versions: 0.11.0
>Reporter: Ozan Can Altiok
>Priority: Major
>
> I was trying to add the following into a thrift interface file.
> {{const list timeCoefficients = [24, 60, 60, 1000, 1000, 1000]}}
> With the definition given above the {{.thrift}} file compiled properly.
> However, I noticed that in Python, the items in {{timeCoefficients}} are
> considered to be integer although the list has been defined to include items
> of {{double}} type. Then I modified the definition as given below to make
> sure all the items are of type {{double}}.
> {{const list timeCoefficients = [24.0, 60.0, 60.0, 1000.0, 1000.0,
> 1000.0]}}
> After the change, I ran into the following error during compilation.
> {{[ERROR] .../TimeCoefficients.java:[402,48] error: no suitable method found
> for add(int)}}
> {{[ERROR] method Collection.add(Double) is not applicable}}
> {{[ERROR] (argument mismatch; int cannot be converted to Double)}}
> {{[ERROR] method List.add(Double) is not applicable}}
> {{[ERROR] (argument mismatch; int cannot be converted to Double)}}
> Next, I changed the line as follows and the compilation became successful.
> {{const list timeCoefficients = [24.1, 60.1, 60.1, 1000.1, 1000.1,
> 1000.1]}}
> When I reviewed the generated Java source files, I discovered that
> {{const list timeCoefficients = [24, 60, 60, 1000, 1000, 1000]}}
> compiles to
> {{public static final java.util.List timeCoefficients = new
> java.util.ArrayList();}}
> {{static {}}
> {{ timeCoefficients.add((double)24);}}
> {{ timeCoefficients.add((double)60);}}
> {{ timeCoefficients.add((double)60);}}
> {{ timeCoefficients.add((double)1000);}}
> {{ timeCoefficients.add((double)1000);}}
> {{ timeCoefficients.add((double)1000);}}
> {{}}}
> whilst
> {{const list timeCoefficients = [24.0, 60.0, 60.0, 1000.0, 1000.0,
> 1000.0]}}
> compiles to
> {{public static final java.util.List timeCoefficients = new
> java.util.ArrayList();}}
> {{static {}}
> {{ timeCoefficients.add(24);}}
> {{ timeCoefficients.add(60);}}
> {{ timeCoefficients.add(60);}}
> {{ timeCoefficients.add(1000);}}
> {{ timeCoefficients.add(1000);}}
> {{ timeCoefficients.add(1000);}}
> {{}}}
> which leads to an error.
> When I modified this line as follows
> {{const list timeCoefficients = [24.1, 60.1, 60.1, 1000.1, 1000.1,
> 1000.1]}}
> this line compiled to
> {{public static final java.util.List timeCoefficients = new
> java.util.ArrayList();}}
> {{static {}}
> {{ timeCoefficients.add(24.1);}}
> {{ timeCoefficients.add(60.1);}}
> {{ timeCoefficients.add(60.1);}}
> {{ timeCoefficients.add(1000.1);}}
> {{ timeCoefficients.add(1000.1);}}
> {{ timeCoefficients.add(1000.1);}}
> {{}}}
> My guess is that, even if I put {{.0}} at the end of each numeric constant,
> on the Java side, Thrift compiler considers them to be {{double}} and does no
> typecasts. However, the {{.0}} s are getting lost somewhere and the items
> become integers in the generated Java code. Thus, when it comes to populating
> the array, Java cannot succeed. {{Double}} s cannot be unboxed to integer and
> Java thinks {{int}} and {{Double}} are not related.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] thrift issue #1496: THRIFT-4476: Typecasting problem on list items (+ low pr...
Github user ozymaxx commented on the issue: https://github.com/apache/thrift/pull/1496 I have just disabled my new tests on `MSVC2013` builders and kicked a build. Let's see what happens. If the tests also fail on the `CYGWIN` machine, I will also write out new tests for the x86 machines. However, the issue is not about the architecture, only some modifiers seem to be overlooked in the generators. ---
[jira] [Commented] (THRIFT-4476) Typecasting problem on list items
[
https://issues.apache.org/jira/browse/THRIFT-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16397049#comment-16397049
]
ASF GitHub Bot commented on THRIFT-4476:
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1496
I put the MSVC2013 job back in to make sure we had some backwards
compatibility... glad I did. I wonder if we have 32-bit issues with double in
general in thrift?
> Typecasting problem on list items
> -
>
> Key: THRIFT-4476
> URL: https://issues.apache.org/jira/browse/THRIFT-4476
> Project: Thrift
> Issue Type: Bug
> Components: Java - Compiler
>Affects Versions: 0.11.0
>Reporter: Ozan Can Altiok
>Priority: Major
>
> I was trying to add the following into a thrift interface file.
> {{const list timeCoefficients = [24, 60, 60, 1000, 1000, 1000]}}
> With the definition given above the {{.thrift}} file compiled properly.
> However, I noticed that in Python, the items in {{timeCoefficients}} are
> considered to be integer although the list has been defined to include items
> of {{double}} type. Then I modified the definition as given below to make
> sure all the items are of type {{double}}.
> {{const list timeCoefficients = [24.0, 60.0, 60.0, 1000.0, 1000.0,
> 1000.0]}}
> After the change, I ran into the following error during compilation.
> {{[ERROR] .../TimeCoefficients.java:[402,48] error: no suitable method found
> for add(int)}}
> {{[ERROR] method Collection.add(Double) is not applicable}}
> {{[ERROR] (argument mismatch; int cannot be converted to Double)}}
> {{[ERROR] method List.add(Double) is not applicable}}
> {{[ERROR] (argument mismatch; int cannot be converted to Double)}}
> Next, I changed the line as follows and the compilation became successful.
> {{const list timeCoefficients = [24.1, 60.1, 60.1, 1000.1, 1000.1,
> 1000.1]}}
> When I reviewed the generated Java source files, I discovered that
> {{const list timeCoefficients = [24, 60, 60, 1000, 1000, 1000]}}
> compiles to
> {{public static final java.util.List timeCoefficients = new
> java.util.ArrayList();}}
> {{static {}}
> {{ timeCoefficients.add((double)24);}}
> {{ timeCoefficients.add((double)60);}}
> {{ timeCoefficients.add((double)60);}}
> {{ timeCoefficients.add((double)1000);}}
> {{ timeCoefficients.add((double)1000);}}
> {{ timeCoefficients.add((double)1000);}}
> {{}}}
> whilst
> {{const list timeCoefficients = [24.0, 60.0, 60.0, 1000.0, 1000.0,
> 1000.0]}}
> compiles to
> {{public static final java.util.List timeCoefficients = new
> java.util.ArrayList();}}
> {{static {}}
> {{ timeCoefficients.add(24);}}
> {{ timeCoefficients.add(60);}}
> {{ timeCoefficients.add(60);}}
> {{ timeCoefficients.add(1000);}}
> {{ timeCoefficients.add(1000);}}
> {{ timeCoefficients.add(1000);}}
> {{}}}
> which leads to an error.
> When I modified this line as follows
> {{const list timeCoefficients = [24.1, 60.1, 60.1, 1000.1, 1000.1,
> 1000.1]}}
> this line compiled to
> {{public static final java.util.List timeCoefficients = new
> java.util.ArrayList();}}
> {{static {}}
> {{ timeCoefficients.add(24.1);}}
> {{ timeCoefficients.add(60.1);}}
> {{ timeCoefficients.add(60.1);}}
> {{ timeCoefficients.add(1000.1);}}
> {{ timeCoefficients.add(1000.1);}}
> {{ timeCoefficients.add(1000.1);}}
> {{}}}
> My guess is that, even if I put {{.0}} at the end of each numeric constant,
> on the Java side, Thrift compiler considers them to be {{double}} and does no
> typecasts. However, the {{.0}} s are getting lost somewhere and the items
> become integers in the generated Java code. Thus, when it comes to populating
> the array, Java cannot succeed. {{Double}} s cannot be unboxed to integer and
> Java thinks {{int}} and {{Double}} are not related.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] thrift issue #1496: THRIFT-4476: Typecasting problem on list items (+ low pr...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1496 I put the MSVC2013 job back in to make sure we had some backwards compatibility... glad I did. I wonder if we have 32-bit issues with double in general in thrift? ---
[jira] [Updated] (THRIFT-3458) Register thrift in D package registry
[ https://issues.apache.org/jira/browse/THRIFT-3458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III updated THRIFT-3458: --- Description: add dub.sdl or dub.json and register it at code.dlang.org #723 has this work. from THRIFT-4504: use dub to build the dlang bits and pull in the deimos dependencies properly instead of putting them into the dockerfile for the CI build. #1380 has most of this work. The effort in #723 and #1380 are highly related and should be combined. was:add dub.sdl or dub.json and register it at code.dlang.org > Register thrift in D package registry > - > > Key: THRIFT-3458 > URL: https://issues.apache.org/jira/browse/THRIFT-3458 > Project: Thrift > Issue Type: Improvement > Components: D - Compiler, D - Library >Reporter: Tolstokulakov Nikolay >Assignee: James E. King, III >Priority: Major > > add dub.sdl or dub.json and register it at code.dlang.org #723 has this work. > from THRIFT-4504: use dub to build the dlang bits and pull in the deimos > dependencies properly instead of putting them into the dockerfile for the CI > build. #1380 has most of this work. > The effort in #723 and #1380 are highly related and should be combined. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (THRIFT-3458) Register thrift in D package registry
[ https://issues.apache.org/jira/browse/THRIFT-3458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16397021#comment-16397021 ] ASF GitHub Bot commented on THRIFT-3458: Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1380 THRIFT-3458 is also related, and the approach in THRIFT-3458 would allow us to add the apache git repo to dub directly so we should move in that direction, but still try to use dub to build in lib/d, test/d, tutorial/d. I closed THRIFT-4504 as a duplicate of THRIFT-3458. If we can get this PR to the point where there is a dub file at the top level of the repository that builds lib/d, that will allow us to add the apache repo to the dub registry and have it build and publish a dub package. > Register thrift in D package registry > - > > Key: THRIFT-3458 > URL: https://issues.apache.org/jira/browse/THRIFT-3458 > Project: Thrift > Issue Type: Improvement > Components: D - Compiler, D - Library >Reporter: Tolstokulakov Nikolay >Assignee: James E. King, III >Priority: Major > > add dub.sdl or dub.json and register it at code.dlang.org -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] thrift issue #1380: Support x64 build mode on Windows with DMD v2.076.0.
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1380 THRIFT-3458 is also related, and the approach in THRIFT-3458 would allow us to add the apache git repo to dub directly so we should move in that direction, but still try to use dub to build in lib/d, test/d, tutorial/d. I closed THRIFT-4504 as a duplicate of THRIFT-3458. If we can get this PR to the point where there is a dub file at the top level of the repository that builds lib/d, that will allow us to add the apache repo to the dub registry and have it build and publish a dub package. ---
[jira] [Resolved] (THRIFT-4504) Use dlang native build and package manager (dub) for builds
[ https://issues.apache.org/jira/browse/THRIFT-4504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III resolved THRIFT-4504. Resolution: Duplicate Assignee: James E. King, III Resolving as a dupe of THRIFT-3458. > Use dlang native build and package manager (dub) for builds > --- > > Key: THRIFT-4504 > URL: https://issues.apache.org/jira/browse/THRIFT-4504 > Project: Thrift > Issue Type: Improvement > Components: D - Library >Affects Versions: 0.11.0 >Reporter: James E. King, III >Assignee: James E. King, III >Priority: Major > > Opened to cover functionality provided in pull request #1380. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (THRIFT-3458) Register thrift in D package registry
[ https://issues.apache.org/jira/browse/THRIFT-3458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III reassigned THRIFT-3458: -- Assignee: James E. King, III (was: Jake Farrell) > Register thrift in D package registry > - > > Key: THRIFT-3458 > URL: https://issues.apache.org/jira/browse/THRIFT-3458 > Project: Thrift > Issue Type: Improvement > Components: D - Compiler, D - Library >Reporter: Tolstokulakov Nikolay >Assignee: James E. King, III >Priority: Major > > add dub.sdl or dub.json and register it at code.dlang.org -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (THRIFT-4504) Use dlang native build and package manager (dub) for builds
[ https://issues.apache.org/jira/browse/THRIFT-4504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III closed THRIFT-4504. -- > Use dlang native build and package manager (dub) for builds > --- > > Key: THRIFT-4504 > URL: https://issues.apache.org/jira/browse/THRIFT-4504 > Project: Thrift > Issue Type: Improvement > Components: D - Library >Affects Versions: 0.11.0 >Reporter: James E. King, III >Assignee: James E. King, III >Priority: Major > > Opened to cover functionality provided in pull request #1380. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (THRIFT-4504) Use dlang native build and package manager (dub) for builds
[ https://issues.apache.org/jira/browse/THRIFT-4504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16397019#comment-16397019 ] James E. King, III commented on THRIFT-4504: I think the approach in [https://github.com/apache/thrift/pull/723] is better for the project because we can add the apache thrift repository to dub directly and it will package and build, having a top level dub project file. We also want to use dub to build lib/d, test/d, and tutorial/d however, which was done in [https://github.com/apache/thrift/pull/1380.] I worked with it a little bit, and we're past the linking issues we had before with deimos now. It's time to take a look at these and combine them somehow. > Use dlang native build and package manager (dub) for builds > --- > > Key: THRIFT-4504 > URL: https://issues.apache.org/jira/browse/THRIFT-4504 > Project: Thrift > Issue Type: Improvement > Components: D - Library >Affects Versions: 0.11.0 >Reporter: James E. King, III >Priority: Major > > Opened to cover functionality provided in pull request #1380. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (THRIFT-4431) Repetitive use of HTTPClientTransport causes "Errno::EMFILE: Failed to open TCP connection"
[ https://issues.apache.org/jira/browse/THRIFT-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16397013#comment-16397013 ] ASF GitHub Bot commented on THRIFT-4431: Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1447 @lompy will you be able to carry this forward? > Repetitive use of HTTPClientTransport causes "Errno::EMFILE: Failed to open > TCP connection" > --- > > Key: THRIFT-4431 > URL: https://issues.apache.org/jira/browse/THRIFT-4431 > Project: Thrift > Issue Type: Bug > Components: Ruby - Library >Affects Versions: 0.10.0, 0.11.0 >Reporter: Roman Charushin >Priority: Major > Fix For: 0.10.0, 0.11.0 > > > Repetitive calls to the clients initiated with the HTTPClientTransport causes > "Errno::EMFILE: Failed to open TCP connection" error due to too many open > files. And the reason is that each time client is called new http connection > is created at each flush and is never finished after, holding the file > descriptors to tcp connection files. > In order to solve this HTTP#finish should be called in ensure block of > HTTPClientTransport#flush. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] thrift issue #1447: THRIFT-4431 Ruby library: Finish http connection after f...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1447 @lompy will you be able to carry this forward? ---
[jira] [Commented] (THRIFT-4474) PHP generator use PSR-4 default
[
https://issues.apache.org/jira/browse/THRIFT-4474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16397011#comment-16397011
]
ASF GitHub Bot commented on THRIFT-4474:
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1479
Any other php folks out there want to comment or review on the breaking
change here? It looks like the strategy was to change the generator and
provide a flag to allow folks to generate older style code for backwards
compatibility.
> PHP generator use PSR-4 default
> ---
>
> Key: THRIFT-4474
> URL: https://issues.apache.org/jira/browse/THRIFT-4474
> Project: Thrift
> Issue Type: Improvement
> Components: PHP - Compiler
>Reporter: Robert Lu
>Assignee: Robert Lu
>Priority: Major
>
> Before, PHP generator generate php files like {{Types.php}}, {{Service.php}}.
> Those can only be load via
> [{{classmap}}|https://getcomposer.org/doc/04-schema.md#classmap] method. The
> latest PSR about autoload is [PSR-4|http://www.php-fig.org/psr/psr-4/].
> thrift compiler can generate PSR-4 code default, if want old-style code(which
> can only load via classmap), add {{classmap}} option.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] thrift issue #1479: THRIFT-4474: generate PHP code use PSR-4 style default
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1479 Any other php folks out there want to comment or review on the breaking change here? It looks like the strategy was to change the generator and provide a flag to allow folks to generate older style code for backwards compatibility. ---
[jira] [Commented] (THRIFT-4382) Replace the use of Perl Indirect Object Syntax calls to new()
[ https://issues.apache.org/jira/browse/THRIFT-4382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16397001#comment-16397001 ] ASF GitHub Bot commented on THRIFT-4382: Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1261 If you are able to finish this up and do the tutorial code, or if you are not able to complete this, please let me know. > Replace the use of Perl Indirect Object Syntax calls to new() > -- > > Key: THRIFT-4382 > URL: https://issues.apache.org/jira/browse/THRIFT-4382 > Project: Thrift > Issue Type: Improvement > Components: Perl - Compiler >Reporter: Dean Hamstead >Priority: Minor > > Using Indirect Object Syntax to instantiate objects is not recommended as per > https://perldoc.perl.org/perlobj.html#Invoking-Class-Methods -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] thrift issue #1261: THRIFT-4382: Replace the use of Indirect Object Syntax c...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1261 If you are able to finish this up and do the tutorial code, or if you are not able to complete this, please let me know. ---
[GitHub] thrift issue #1141: support for timeout in node http connection
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1141 @bananer this would be a good candidate to pick up and run with. ---
[jira] [Commented] (THRIFT-4509) js and nodejs libraries need to be refreshed with current libraries
[
https://issues.apache.org/jira/browse/THRIFT-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16396996#comment-16396996
]
ASF GitHub Bot commented on THRIFT-4509:
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1506
With this merged would you say that THRIFT-4509 is now fixed, or is there
more work to do?
> js and nodejs libraries need to be refreshed with current libraries
> ---
>
> Key: THRIFT-4509
> URL: https://issues.apache.org/jira/browse/THRIFT-4509
> Project: Thrift
> Issue Type: Improvement
> Components: JavaScript - Library, Node.js - Library
>Affects Versions: 0.11.0
>Reporter: James E. King, III
>Priority: Critical
> Labels: security
>
> The npm libraries that our js and nodejs depend on are starting to go end of
> life.
> As it stands the build is just barely holding together, and as of 5 hours ago
> the "ws" package dropped support for node < 4.5.0; Ubuntu Xenial 16.04 LTS
> uses node v4.2.6.
> There are other issues:
> {noformat}
> Running "shell:InstallThriftNodeJSDep" (shell) task
> WARN engine hawk@6.0.2: wanted: {"node":">=4.5.0"} (current:
> {"node":"4.2.6","npm":"3.5.2"})
> npm WARN deprecated minimatch@0.3.0: Please update to minimatch 3.0.2 or
> higher to avoid a RegExp DoS issue
> npm WARN deprecated minimatch@0.2.14: Please update to minimatch 3.0.2 or
> higher to avoid a RegExp DoS issue
> npm WARN deprecated minimatch@0.4.0: Please update to minimatch 3.0.2 or
> higher to avoid a RegExp DoS issue
> npm WARN deprecated minimatch@2.0.10: Please update to minimatch 3.0.2 or
> higher to avoid a RegExp DoS issue
> npm WARN deprecated node-uuid@1.4.8: Use uuid module instead
> npm WARN deprecated tough-cookie@2.2.2: ReDoS vulnerability parsing
> Set-Cookie https://nodesecurity.io/advisories/130
> {noformat}
> Some of these are security issues.
> In addition the js module depends on
> https://www.npmjs.com/package/grunt-external-daemon which requires grunt
> 0.4.0, which is really old and may contribute to requiring older versions of
> things that are posting deprecations.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-3916) Errors thrown from JavaScript client is strings and not errors
[
https://issues.apache.org/jira/browse/THRIFT-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16396995#comment-16396995
]
ASF GitHub Bot commented on THRIFT-3916:
Github user jeking3 commented on the issue:
https://github.com/apache/thrift/pull/1075
@bananer is this worth pulling forward if it passes a build? Is it a
breaking change?
> Errors thrown from JavaScript client is strings and not errors
> --
>
> Key: THRIFT-3916
> URL: https://issues.apache.org/jira/browse/THRIFT-3916
> Project: Thrift
> Issue Type: Bug
> Components: JavaScript - Compiler
>Reporter: Simen Bekkhus
>Priority: Minor
> Labels: javascript
>
> In JavaScript, you can {{throw}} any object, including strings, but to get
> stack traces one should throw {{Errors}}.
> The generated JS code throws the error string directly, instead of wrapping
> it in {{new Error}}.
> Node core _only_ rejects with/throws Errors, never strings, and Thrift should
> follow the same standard.
> https://nodejs.org/api/errors.html#errors_class_error
> {quote}
> All errors generated by Node.js, including all System and JavaScript errors,
> will either be instances of, or inherit from, the Error class.
> {quote}
> PR for the change [here|https://github.com/apache/thrift/pull/1075].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] thrift issue #1058: Node.js: Set/unset client seqid for json_protocol and co...
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1058 @bananer is this worth pulling forward if it passes a build? ---
[GitHub] thrift issue #1075: THRIFT-3916 Throw proper errors from JS, not strings
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1075 @bananer is this worth pulling forward if it passes a build? Is it a breaking change? ---
[GitHub] thrift issue #1506: THRIFT-4509: grunt update (rebased)
Github user jeking3 commented on the issue: https://github.com/apache/thrift/pull/1506 With this merged would you say that THRIFT-4509 is now fixed, or is there more work to do? ---
[jira] [Commented] (THRIFT-4509) js and nodejs libraries need to be refreshed with current libraries
[
https://issues.apache.org/jira/browse/THRIFT-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16396992#comment-16396992
]
ASF GitHub Bot commented on THRIFT-4509:
Github user asfgit closed the pull request at:
https://github.com/apache/thrift/pull/1506
> js and nodejs libraries need to be refreshed with current libraries
> ---
>
> Key: THRIFT-4509
> URL: https://issues.apache.org/jira/browse/THRIFT-4509
> Project: Thrift
> Issue Type: Improvement
> Components: JavaScript - Library, Node.js - Library
>Affects Versions: 0.11.0
>Reporter: James E. King, III
>Priority: Critical
> Labels: security
>
> The npm libraries that our js and nodejs depend on are starting to go end of
> life.
> As it stands the build is just barely holding together, and as of 5 hours ago
> the "ws" package dropped support for node < 4.5.0; Ubuntu Xenial 16.04 LTS
> uses node v4.2.6.
> There are other issues:
> {noformat}
> Running "shell:InstallThriftNodeJSDep" (shell) task
> WARN engine hawk@6.0.2: wanted: {"node":">=4.5.0"} (current:
> {"node":"4.2.6","npm":"3.5.2"})
> npm WARN deprecated minimatch@0.3.0: Please update to minimatch 3.0.2 or
> higher to avoid a RegExp DoS issue
> npm WARN deprecated minimatch@0.2.14: Please update to minimatch 3.0.2 or
> higher to avoid a RegExp DoS issue
> npm WARN deprecated minimatch@0.4.0: Please update to minimatch 3.0.2 or
> higher to avoid a RegExp DoS issue
> npm WARN deprecated minimatch@2.0.10: Please update to minimatch 3.0.2 or
> higher to avoid a RegExp DoS issue
> npm WARN deprecated node-uuid@1.4.8: Use uuid module instead
> npm WARN deprecated tough-cookie@2.2.2: ReDoS vulnerability parsing
> Set-Cookie https://nodesecurity.io/advisories/130
> {noformat}
> Some of these are security issues.
> In addition the js module depends on
> https://www.npmjs.com/package/grunt-external-daemon which requires grunt
> 0.4.0, which is really old and may contribute to requiring older versions of
> things that are posting deprecations.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] thrift pull request #1506: THRIFT-4509: grunt update (rebased)
Github user asfgit closed the pull request at: https://github.com/apache/thrift/pull/1506 ---
[jira] [Commented] (THRIFT-4476) Typecasting problem on list items
[
https://issues.apache.org/jira/browse/THRIFT-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16396631#comment-16396631
]
ASF GitHub Bot commented on THRIFT-4476:
Github user ozymaxx closed the pull request at:
https://github.com/apache/thrift/pull/1496
> Typecasting problem on list items
> -
>
> Key: THRIFT-4476
> URL: https://issues.apache.org/jira/browse/THRIFT-4476
> Project: Thrift
> Issue Type: Bug
> Components: Java - Compiler
>Affects Versions: 0.11.0
>Reporter: Ozan Can Altiok
>Priority: Major
>
> I was trying to add the following into a thrift interface file.
> {{const list timeCoefficients = [24, 60, 60, 1000, 1000, 1000]}}
> With the definition given above the {{.thrift}} file compiled properly.
> However, I noticed that in Python, the items in {{timeCoefficients}} are
> considered to be integer although the list has been defined to include items
> of {{double}} type. Then I modified the definition as given below to make
> sure all the items are of type {{double}}.
> {{const list timeCoefficients = [24.0, 60.0, 60.0, 1000.0, 1000.0,
> 1000.0]}}
> After the change, I ran into the following error during compilation.
> {{[ERROR] .../TimeCoefficients.java:[402,48] error: no suitable method found
> for add(int)}}
> {{[ERROR] method Collection.add(Double) is not applicable}}
> {{[ERROR] (argument mismatch; int cannot be converted to Double)}}
> {{[ERROR] method List.add(Double) is not applicable}}
> {{[ERROR] (argument mismatch; int cannot be converted to Double)}}
> Next, I changed the line as follows and the compilation became successful.
> {{const list timeCoefficients = [24.1, 60.1, 60.1, 1000.1, 1000.1,
> 1000.1]}}
> When I reviewed the generated Java source files, I discovered that
> {{const list timeCoefficients = [24, 60, 60, 1000, 1000, 1000]}}
> compiles to
> {{public static final java.util.List timeCoefficients = new
> java.util.ArrayList();}}
> {{static {}}
> {{ timeCoefficients.add((double)24);}}
> {{ timeCoefficients.add((double)60);}}
> {{ timeCoefficients.add((double)60);}}
> {{ timeCoefficients.add((double)1000);}}
> {{ timeCoefficients.add((double)1000);}}
> {{ timeCoefficients.add((double)1000);}}
> {{}}}
> whilst
> {{const list timeCoefficients = [24.0, 60.0, 60.0, 1000.0, 1000.0,
> 1000.0]}}
> compiles to
> {{public static final java.util.List timeCoefficients = new
> java.util.ArrayList();}}
> {{static {}}
> {{ timeCoefficients.add(24);}}
> {{ timeCoefficients.add(60);}}
> {{ timeCoefficients.add(60);}}
> {{ timeCoefficients.add(1000);}}
> {{ timeCoefficients.add(1000);}}
> {{ timeCoefficients.add(1000);}}
> {{}}}
> which leads to an error.
> When I modified this line as follows
> {{const list timeCoefficients = [24.1, 60.1, 60.1, 1000.1, 1000.1,
> 1000.1]}}
> this line compiled to
> {{public static final java.util.List timeCoefficients = new
> java.util.ArrayList();}}
> {{static {}}
> {{ timeCoefficients.add(24.1);}}
> {{ timeCoefficients.add(60.1);}}
> {{ timeCoefficients.add(60.1);}}
> {{ timeCoefficients.add(1000.1);}}
> {{ timeCoefficients.add(1000.1);}}
> {{ timeCoefficients.add(1000.1);}}
> {{}}}
> My guess is that, even if I put {{.0}} at the end of each numeric constant,
> on the Java side, Thrift compiler considers them to be {{double}} and does no
> typecasts. However, the {{.0}} s are getting lost somewhere and the items
> become integers in the generated Java code. Thus, when it comes to populating
> the array, Java cannot succeed. {{Double}} s cannot be unboxed to integer and
> Java thinks {{int}} and {{Double}} are not related.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] thrift pull request #1496: THRIFT-4476: Typecasting problem on list items (+...
Github user ozymaxx closed the pull request at: https://github.com/apache/thrift/pull/1496 ---
[GitHub] thrift issue #1496: THRIFT-4476: Typecasting problem on list items (+ low pr...
Github user ozymaxx commented on the issue: https://github.com/apache/thrift/pull/1496 The AppVeyor builder with the `MSVC2013` configuration generates large double constants differently as the old `MSVC2010` configuration used to do. So I will add a condition to not do the `TestRenderedDoubleConstants` test on that builder. I also suspect that this problem might be due to the architecture (x86). The result of the `CYGWIN x86` builder will give us some clue on this. ---
[jira] [Commented] (THRIFT-4476) Typecasting problem on list items
[
https://issues.apache.org/jira/browse/THRIFT-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16396630#comment-16396630
]
ASF GitHub Bot commented on THRIFT-4476:
Github user ozymaxx commented on the issue:
https://github.com/apache/thrift/pull/1496
The AppVeyor builder with the `MSVC2013` configuration generates large
double constants differently as the old `MSVC2010` configuration used to do. So
I will add a condition to not do the `TestRenderedDoubleConstants` test on that
builder. I also suspect that this problem might be due to the architecture
(x86). The result of the `CYGWIN x86` builder will give us some clue on this.
> Typecasting problem on list items
> -
>
> Key: THRIFT-4476
> URL: https://issues.apache.org/jira/browse/THRIFT-4476
> Project: Thrift
> Issue Type: Bug
> Components: Java - Compiler
>Affects Versions: 0.11.0
>Reporter: Ozan Can Altiok
>Priority: Major
>
> I was trying to add the following into a thrift interface file.
> {{const list timeCoefficients = [24, 60, 60, 1000, 1000, 1000]}}
> With the definition given above the {{.thrift}} file compiled properly.
> However, I noticed that in Python, the items in {{timeCoefficients}} are
> considered to be integer although the list has been defined to include items
> of {{double}} type. Then I modified the definition as given below to make
> sure all the items are of type {{double}}.
> {{const list timeCoefficients = [24.0, 60.0, 60.0, 1000.0, 1000.0,
> 1000.0]}}
> After the change, I ran into the following error during compilation.
> {{[ERROR] .../TimeCoefficients.java:[402,48] error: no suitable method found
> for add(int)}}
> {{[ERROR] method Collection.add(Double) is not applicable}}
> {{[ERROR] (argument mismatch; int cannot be converted to Double)}}
> {{[ERROR] method List.add(Double) is not applicable}}
> {{[ERROR] (argument mismatch; int cannot be converted to Double)}}
> Next, I changed the line as follows and the compilation became successful.
> {{const list timeCoefficients = [24.1, 60.1, 60.1, 1000.1, 1000.1,
> 1000.1]}}
> When I reviewed the generated Java source files, I discovered that
> {{const list timeCoefficients = [24, 60, 60, 1000, 1000, 1000]}}
> compiles to
> {{public static final java.util.List timeCoefficients = new
> java.util.ArrayList();}}
> {{static {}}
> {{ timeCoefficients.add((double)24);}}
> {{ timeCoefficients.add((double)60);}}
> {{ timeCoefficients.add((double)60);}}
> {{ timeCoefficients.add((double)1000);}}
> {{ timeCoefficients.add((double)1000);}}
> {{ timeCoefficients.add((double)1000);}}
> {{}}}
> whilst
> {{const list timeCoefficients = [24.0, 60.0, 60.0, 1000.0, 1000.0,
> 1000.0]}}
> compiles to
> {{public static final java.util.List timeCoefficients = new
> java.util.ArrayList();}}
> {{static {}}
> {{ timeCoefficients.add(24);}}
> {{ timeCoefficients.add(60);}}
> {{ timeCoefficients.add(60);}}
> {{ timeCoefficients.add(1000);}}
> {{ timeCoefficients.add(1000);}}
> {{ timeCoefficients.add(1000);}}
> {{}}}
> which leads to an error.
> When I modified this line as follows
> {{const list timeCoefficients = [24.1, 60.1, 60.1, 1000.1, 1000.1,
> 1000.1]}}
> this line compiled to
> {{public static final java.util.List timeCoefficients = new
> java.util.ArrayList();}}
> {{static {}}
> {{ timeCoefficients.add(24.1);}}
> {{ timeCoefficients.add(60.1);}}
> {{ timeCoefficients.add(60.1);}}
> {{ timeCoefficients.add(1000.1);}}
> {{ timeCoefficients.add(1000.1);}}
> {{ timeCoefficients.add(1000.1);}}
> {{}}}
> My guess is that, even if I put {{.0}} at the end of each numeric constant,
> on the Java side, Thrift compiler considers them to be {{double}} and does no
> typecasts. However, the {{.0}} s are getting lost somewhere and the items
> become integers in the generated Java code. Thus, when it comes to populating
> the array, Java cannot succeed. {{Double}} s cannot be unboxed to integer and
> Java thinks {{int}} and {{Double}} are not related.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
