from:"Jens Geyer"



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

Jens Geyer resolved THRIFT-5781.

Fix Version/s: 0.21.0
   Resolution: Fixed

> implement full deprecation support
> --
>
> Key: THRIFT-5781
> URL: https://issues.apache.org/jira/browse/THRIFT-5781
> Project: Thrift
>  Issue Type: Improvement
>  Components: netstd - Compiler
>    Reporter: Jens Geyer
>    Assignee: Jens Geyer
>Priority: Minor
> Fix For: 0.21.0
>
> Attachments: deprecated.thrift
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently netstd only checks service methods for deprecation markers. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (THRIFT-5781) implement full deprecation support



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

Jens Geyer updated THRIFT-5781:
---
Attachment: deprecated.thrift

> implement full deprecation support
> --
>
> Key: THRIFT-5781
> URL: https://issues.apache.org/jira/browse/THRIFT-5781
> Project: Thrift
>  Issue Type: Improvement
>  Components: netstd - Compiler
>    Reporter: Jens Geyer
>    Assignee: Jens Geyer
>Priority: Minor
> Attachments: deprecated.thrift
>
>
> Currently netstd only checks service methods for deprecation markers. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (THRIFT-5781) implement full deprecation support

Jens Geyer created THRIFT-5781:
--

 Summary: implement full deprecation support
 Key: THRIFT-5781
 URL: https://issues.apache.org/jira/browse/THRIFT-5781
 Project: Thrift
  Issue Type: Improvement
  Components: netstd - Compiler
Reporter: Jens Geyer
Assignee: Jens Geyer


Currently netstd only checks service methods for deprecation markers. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-640) Support deprecation



[ 
https://issues.apache.org/jira/browse/THRIFT-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840810#comment-17840810
 ] 

Jens Geyer commented on THRIFT-640:
---

[Example of how it works can be found in 
optional_required_default.thrift|https://github.com/apache/thrift/blob/master/lib/netstd/Tests/Thrift.PublicInterfaces.Compile.Tests/optional_required_default.thrift]

> Support deprecation
> ---
>
> Key: THRIFT-640
> URL: https://issues.apache.org/jira/browse/THRIFT-640
> Project: Thrift
>  Issue Type: New Feature
>  Components: Java - Compiler
>Reporter: Nathan Marz
>Assignee: Daniel Wolf
>Priority: Minor
> Fix For: 0.10.0
>
> Attachments: thrift-640-java-deprecation.patch
>
>
> Sometimes we do schema migrations and it would be cool to be able to have 
> deprecation functionality from Thrift. At the most basic level, we should be 
> able to annotate a field as deprecated and have the compiler generate 
> "@Deprecated" annotations in the Java code.
> Sometimes though, you may want creators of structs to be forced to use new 
> fields, but you still want to be able to read the old fields until you have 
> everything migrated over. In this case you could mark a field as 
> "strong-deprecated" and just not generate any setters for those fields (only 
> getters). This would force all users of the struct to migrate to new schema, 
> since the code won't compile otherwise.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (THRIFT-5780) Prevent certain warnings related to net8

2024-04-24 Thread Jens Geyer (Jira)



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

Jens Geyer resolved THRIFT-5780.

Fix Version/s: 0.21.0
   Resolution: Fixed

> Prevent certain warnings related to net8
> 
>
> Key: THRIFT-5780
> URL: https://issues.apache.org/jira/browse/THRIFT-5780
> Project: Thrift
>  Issue Type: Improvement
>  Components: netstd - Compiler
>    Reporter: Jens Geyer
>    Assignee: Jens Geyer
>Priority: Minor
> Fix For: 0.21.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> * IDE0301 Use collection expression for empty collections
> * CA1041: Provide ObsoleteAttribute message



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (THRIFT-5780) Prevent certain warnings related to net8

2024-04-24 Thread Jens Geyer (Jira)



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

Jens Geyer updated THRIFT-5780:
---
Summary: Prevent certain warnings related to net8  (was: Prevent certain 
warnings in related to net8)

> Prevent certain warnings related to net8
> 
>
> Key: THRIFT-5780
> URL: https://issues.apache.org/jira/browse/THRIFT-5780
> Project: Thrift
>  Issue Type: Improvement
>  Components: netstd - Compiler
>    Reporter: Jens Geyer
>    Assignee: Jens Geyer
>Priority: Minor
>
> * IDE0301 Use collection expression for empty collections
> * CA1041: Provide ObsoleteAttribute message



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (THRIFT-5780) Prevent certain warnings in related to net8

2024-04-24 Thread Jens Geyer (Jira)

Jens Geyer created THRIFT-5780:
--

 Summary: Prevent certain warnings in related to net8
 Key: THRIFT-5780
 URL: https://issues.apache.org/jira/browse/THRIFT-5780
 Project: Thrift
  Issue Type: Improvement
  Components: netstd - Compiler
Reporter: Jens Geyer
Assignee: Jens Geyer


* IDE0301 Use collection expression for empty collections
* CA1041: Provide ObsoleteAttribute message



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (THRIFT-5654) LNK4042 and LNK2019 in go_validator_generator.cc

2024-04-23 Thread Jens Geyer (Jira)



[ 
https://issues.apache.org/jira/browse/THRIFT-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840072#comment-17840072
 ] 

Jens Geyer edited comment on THRIFT-5654 at 4/23/24 11:54 AM:
--

If we don't have it we should resolve the problem? Are you sure? And how is 
that related to this ticket at all?

https://www.cvedetails.com/vulnerability-list/vendor_id-45/product_id-38295/Apache-Thrift.html


was (Author: jensg):
If we don't have it we should resolve the problem? Are you sure? And how is 
that related to this ticket at all?

> LNK4042 and LNK2019 in go_validator_generator.cc
> 
>
> Key: THRIFT-5654
> URL: https://issues.apache.org/jira/browse/THRIFT-5654
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
> Environment: Visual Studio 2022
>    Reporter: Jens Geyer
>Priority: Critical
>
> With VS2022  I get "warning LNK4042: object specified more than once; extras 
> ignored" in go_validator_generator.obj.
> Also I had to comment out this to get rid of some fatal LNK2019: unresolved 
> external symbol:
> //go_validator_generator(this).generate_struct_validator(f_types_, tstruct); 
> Extra info:
> https://stackoverflow.com/questions/3695174/visual-studio-2010s-strange-warning-lnk4042



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-5654) LNK4042 and LNK2019 in go_validator_generator.cc

2024-04-23 Thread Jens Geyer (Jira)



[ 
https://issues.apache.org/jira/browse/THRIFT-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840072#comment-17840072
 ] 

Jens Geyer commented on THRIFT-5654:


If we don't have it we should resolve the problem? Are you sure? And how is 
that related to this ticket at all?

> LNK4042 and LNK2019 in go_validator_generator.cc
> 
>
> Key: THRIFT-5654
> URL: https://issues.apache.org/jira/browse/THRIFT-5654
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
> Environment: Visual Studio 2022
>    Reporter: Jens Geyer
>Priority: Critical
>
> With VS2022  I get "warning LNK4042: object specified more than once; extras 
> ignored" in go_validator_generator.obj.
> Also I had to comment out this to get rid of some fatal LNK2019: unresolved 
> external symbol:
> //go_validator_generator(this).generate_struct_validator(f_types_, tstruct); 
> Extra info:
> https://stackoverflow.com/questions/3695174/visual-studio-2010s-strange-warning-lnk4042



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (THRIFT-5778) Thrift URIs: A machine readable way to describe client-side service bindings

2024-04-22 Thread Jens Geyer (Jira)



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

Jens Geyer updated THRIFT-5778:
---
Description: 
Describing the endpoint specifics for a Thrift API today is a purely 
text-adventure like exercise, which leaves the client end with the task to set 
up and stack together a proper protocol/transport stack. That sometimes even 
leads to headaches, e.g. if the server requires e.g. framed protocol which 
might not be obvious. The use of a generally accepted, machine-readable and 
extensible Thrift URI format to describe client bindings could streamline that 
process.
   
 Details (work in progress) at 
https://github.com/Jens-G/thrift/blob/thrift-uri/doc/specs/thrift-uri.md

  was:
Describing the endpoint specifics for a Thrift API today is a purely textual 
exercise, which leaves the client end with the task to set up and stack 
together a proper protocol/transport stack. That sometimes even leads to 
headaches, e.g. if the server requires e.g. framed protocol which might not be 
obvious. The use of a generally accepted, machine-readable and extensible 
Thrift URI format to describe client bindings could streamline that process.
   
 Details (work in progress) at 
https://github.com/Jens-G/thrift/blob/thrift-uri/doc/specs/thrift-uri.md


> Thrift URIs: A machine readable way to describe client-side service bindings
> 
>
> Key: THRIFT-5778
> URL: https://issues.apache.org/jira/browse/THRIFT-5778
> Project: Thrift
>  Issue Type: New Feature
>    Reporter: Jens Geyer
>Priority: Major
>
> Describing the endpoint specifics for a Thrift API today is a purely 
> text-adventure like exercise, which leaves the client end with the task to 
> set up and stack together a proper protocol/transport stack. That sometimes 
> even leads to headaches, e.g. if the server requires e.g. framed protocol 
> which might not be obvious. The use of a generally accepted, machine-readable 
> and extensible Thrift URI format to describe client bindings could streamline 
> that process.
>
>  Details (work in progress) at 
> https://github.com/Jens-G/thrift/blob/thrift-uri/doc/specs/thrift-uri.md



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (THRIFT-5778) Thrift URIs: A machine readable way to describe client-side service bindings

2024-04-22 Thread Jens Geyer (Jira)

Jens Geyer created THRIFT-5778:
--

 Summary: Thrift URIs: A machine readable way to describe 
client-side service bindings
 Key: THRIFT-5778
 URL: https://issues.apache.org/jira/browse/THRIFT-5778
 Project: Thrift
  Issue Type: New Feature
Reporter: Jens Geyer


Describing the endpoint specifics for a Thrift API today is a purely textual 
exercise, which leaves the client end with the task to set up and stack 
together a proper protocol/transport stack. That sometimes even leads to 
headaches, e.g. if the server requires e.g. framed protocol which might not be 
obvious. The use of a generally accepted, machine-readable and extensible 
Thrift URI format to describe client bindings could streamline that process.
   
 Details (work in progress) at 
https://github.com/Jens-G/thrift/blob/thrift-uri/doc/specs/thrift-uri.md



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-5776) Cpp cross test fail

2024-04-22 Thread Jens Geyer (Jira)



[ 
https://issues.apache.org/jira/browse/THRIFT-5776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839588#comment-17839588
 ] 

Jens Geyer commented on THRIFT-5776:


Could it be related to THRIFT-5772 ?

> Cpp cross test fail
> ---
>
> Key: THRIFT-5776
> URL: https://issues.apache.org/jira/browse/THRIFT-5776
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Reporter: Volodymyr Panivko
>Priority: Major
>
> When running cross test in docker I'm getting an error
> {code:java}
> ibs/ThriftTest_extras.o
> Benchmark.cpp: In function 'int main()':
> Benchmark.cpp:69:7: error: 'class thrift::test::debug::OneOfEach' has no 
> member named 'rfc4122_uuid'
>    69 |   ooe.rfc4122_uuid = "{5e2ab188-1726-4e75-a04f-1ed9a6a89c4c}";
>       |       ^~~~
> make[5]: *** [Makefile:1408: Benchmark.o] Error 1
>  {code}
> if i comment 69 line in Benchmark.cpp this error doe not appear but i'm 
> getting a new one THRIFT-5775



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (THRIFT-5766) Replace std::endl with "\n"

2024-04-15 Thread Jens Geyer (Jira)



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

Jens Geyer resolved THRIFT-5766.

Fix Version/s: 0.21.0
   Resolution: Fixed

> Replace std::endl with "\n"
> ---
>
> Key: THRIFT-5766
> URL: https://issues.apache.org/jira/browse/THRIFT-5766
> Project: Thrift
>  Issue Type: Improvement
>  Components: Compiler (General)
>Affects Versions: 0.19.0
>Reporter: Carel
>Assignee: Carel
>Priority: Minor
> Fix For: 0.21.0
>
>  Time Spent: 4h
>  Remaining Estimate: 0h
>
> Remove the usage of {{std::endl}} to force new lines for {{std::ostream}}
> Rationale
>  * Using `std::endl` for linebreaks is bad practice since {{std::endl}} also 
> forces a stream flush.
>  * A past Ticket THRIFT-1815 identified the flush component as a problem and 
> the behavior of {{std::endl}} was replaced with a custom constant that only 
> did the new line to minimize code changes.
>  * This enforces bad practice and changes expected behaviour
>  * The [C++ Core Guidelines 
> SL.io.50|https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#slio50-avoid-endl]
>  also suggest that {{std::endl}} should be avoided
> I propose (by PR) to remove the usage of {{endl}} and instead use {{\n}} 
> directly to avoid building on the bad practice.
> See: [https://github.com/apache/thrift/pull/2943]
>  * Replace the usage of {{endl}} with "\n" in all genertors
>  * Replace the usage in most test files and examples
>  * Keep the usage in {{std::cerr}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (THRIFT-5772) Add UUID support for C++

2024-04-07 Thread Jens Geyer (Jira)



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

Jens Geyer updated THRIFT-5772:
---
Component/s: C++ - Compiler

> Add UUID support for C++
> 
>
> Key: THRIFT-5772
> URL: https://issues.apache.org/jira/browse/THRIFT-5772
> Project: Thrift
>  Issue Type: New Feature
>  Components: C++ - Compiler
>Reporter: Carel
>Assignee: Carel
>Priority: Minor
> Fix For: 0.21.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Starting the discussion to add UUID support for C++.
> I have started with an implementation (See PR linked soon)
> Open points for discussion: 
> # Is there perhaps a need to add a wrapper class for UUID?
> ## I started off with {{std::string}} for ease-of-use
> ## 'ease-of-use' has the drawback of ease of miss-use... 
> ## Something lightweight as a strong wrapper to wrap a `{{uint8_t data[16];}}`
> ### A wrapper gives us the ability to add utility functions, like 
> `to_string()` and `from_string()`
> ### Can use {{boost::uuids::uuid}} in the implementation, hidden from users 
> (see current implementation)
> ## I will see if I can't implement something while this PR is looked at.
> # Can someone help with some cross tests
> ## With the absence of working dockers I am really struggling to get other 
> languages compiled.
> ## I don't have enough experience with other languages to effectively do this
> ## I will probably be able to add Java tests if there is something to build 
> on (pointers needed)
> # How important is the JSON side? 
> ## I did add the support but I see only go has some support for it. 
> # (edit) How important is the HOST vs Network order on the UUID?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (THRIFT-5772) Add UUID support for C++

2024-04-07 Thread Jens Geyer (Jira)



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

Jens Geyer resolved THRIFT-5772.

Fix Version/s: 0.21.0
 Assignee: Carel
   Resolution: Fixed

> Add UUID support for C++
> 
>
> Key: THRIFT-5772
> URL: https://issues.apache.org/jira/browse/THRIFT-5772
> Project: Thrift
>  Issue Type: New Feature
>Reporter: Carel
>Assignee: Carel
>Priority: Minor
> Fix For: 0.21.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Starting the discussion to add UUID support for C++.
> I have started with an implementation (See PR linked soon)
> Open points for discussion: 
> # Is there perhaps a need to add a wrapper class for UUID?
> ## I started off with {{std::string}} for ease-of-use
> ## 'ease-of-use' has the drawback of ease of miss-use... 
> ## Something lightweight as a strong wrapper to wrap a `{{uint8_t data[16];}}`
> ### A wrapper gives us the ability to add utility functions, like 
> `to_string()` and `from_string()`
> ### Can use {{boost::uuids::uuid}} in the implementation, hidden from users 
> (see current implementation)
> ## I will see if I can't implement something while this PR is looked at.
> # Can someone help with some cross tests
> ## With the absence of working dockers I am really struggling to get other 
> languages compiled.
> ## I don't have enough experience with other languages to effectively do this
> ## I will probably be able to add Java tests if there is something to build 
> on (pointers needed)
> # How important is the JSON side? 
> ## I did add the support but I see only go has some support for it. 
> # (edit) How important is the HOST vs Network order on the UUID?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (THRIFT-5772) Add UUID support for C++

2024-04-04 Thread Jens Geyer (Jira)



[ 
https://issues.apache.org/jira/browse/THRIFT-5772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834070#comment-17834070
 ] 

Jens Geyer edited comment on THRIFT-5772 at 4/4/24 11:40 PM:
-

The following is solely about {*}binary wire format representation{*}. What you 
do internally, in your own memory, is a whole other story - typically whatever 
fits best.

A well-defined byte order is important to be able to exchange uuid bytes across 
platforms. Problem here is that there are in fact several implementations from 
different vendors doing inconsistent stuff (see links below). And there is 
RFC4122 that suggests network order but not everybody follows this.

That's why the docs linked from THRIFT-5587 state explicitly that {*}Thrift 
uses "network" order{*}, which is also consistent with our general integer 
serialisation scheme. Furthermore, there are also [test 
cases|https://github.com/apache/thrift/blob/master/lib/delphi/src/Thrift.Utils.pas#L380]
 intended [to test 
|https://github.com/apache/thrift/blob/master/lib/netstd/Thrift/Protocol/Utilities/TGuidExtensions.cs#L50]
 exactly this. 

Some helpful and/or amusing links (depends on how you look at it):
 - [https://www.ietf.org/rfc/rfc4122.txt]
 - 
[https://stackoverflow.com/questions/10850075/guid-uuid-compatibility-issue-between-net-and-linux]
 - [https://lists.gnu.org/archive/html/bug-parted/2002-01/msg00099.html]


was (Author: jensg):
A well-defined byte order is important to be able to exchange uuid bytes across 
platforms. Problem here is that there are in fact several implementations from 
different vendors doing inconsistent stuff (see links below). And there is 
RFC4122 that suggests network order but not everybody follows this.

That's why the docs linked from THRIFT-5587 state explicitly that {*}Thrift 
uses "network" order{*}, which is also consistent with our general integer 
serialisation scheme. Furthermore, there are also [test 
cases|https://github.com/apache/thrift/blob/master/lib/delphi/src/Thrift.Utils.pas#L380]
 intended [to test 
|https://github.com/apache/thrift/blob/master/lib/netstd/Thrift/Protocol/Utilities/TGuidExtensions.cs#L50]
 exactly this. 

Some helpful and/or amusing links (depends on how you look at it):
 - [https://www.ietf.org/rfc/rfc4122.txt]
 - 
[https://stackoverflow.com/questions/10850075/guid-uuid-compatibility-issue-between-net-and-linux]
 - [https://lists.gnu.org/archive/html/bug-parted/2002-01/msg00099.html]

> Add UUID support for C++
> 
>
> Key: THRIFT-5772
> URL: https://issues.apache.org/jira/browse/THRIFT-5772
> Project: Thrift
>  Issue Type: New Feature
>Reporter: Carel
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Starting the discussion to add UUID support for C++.
> I have started with an implementation (See PR linked soon)
> Open points for discussion: 
> # Is there perhaps a need to add a wrapper class for UUID?
> ## I started off with {{std::string}} for ease-of-use
> ## 'ease-of-use' has the drawback of ease of miss-use... 
> ## Something lightweight as a strong wrapper to wrap a `{{uint8_t data[16];}}`
> ### A wrapper gives us the ability to add utility functions, like 
> `to_string()` and `from_string()`
> ### Can use {{boost::uuids::uuid}} in the implementation, hidden from users 
> (see current implementation)
> ## I will see if I can't implement something while this PR is looked at.
> # Can someone help with some cross tests
> ## With the absence of working dockers I am really struggling to get other 
> languages compiled.
> ## I don't have enough experience with other languages to effectively do this
> ## I will probably be able to add Java tests if there is something to build 
> on (pointers needed)
> # How important is the JSON side? 
> ## I did add the support but I see only go has some support for it. 
> # (edit) How important is the HOST vs Network order on the UUID?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (THRIFT-5772) Add UUID support for C++

2024-04-04 Thread Jens Geyer (Jira)



[ 
https://issues.apache.org/jira/browse/THRIFT-5772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834070#comment-17834070
 ] 

Jens Geyer edited comment on THRIFT-5772 at 4/4/24 8:14 PM:


A well-defined byte order is important to be able to exchange uuid bytes across 
platforms. Problem here is that there are in fact several implementations from 
different vendors doing inconsistent stuff (see links below). And there is 
RFC4122 that suggests network order but not everybody follows this.

That's why the docs linked from THRIFT-5587 state explicitly that {*}Thrift 
uses "network" order{*}, which is also consistent with our general integer 
serialisation scheme. Furthermore, there are also [test 
cases|https://github.com/apache/thrift/blob/master/lib/delphi/src/Thrift.Utils.pas#L380]
 intended [to test 
|https://github.com/apache/thrift/blob/master/lib/netstd/Thrift/Protocol/Utilities/TGuidExtensions.cs#L50]
 exactly this. 

Some helpful and/or amusing links (depends on how you look at it):
 - [https://www.ietf.org/rfc/rfc4122.txt]
 - 
[https://stackoverflow.com/questions/10850075/guid-uuid-compatibility-issue-between-net-and-linux]
 - [https://lists.gnu.org/archive/html/bug-parted/2002-01/msg00099.html]


was (Author: jensg):
A well-defined byte order is important to be able to exchange uuid bytes across 
platforms. Problem here is that there are in fact several implementations from 
different vendors doing inconsistent stuff (see links below). And there is 
RFC4122 that suggests network order but not everybody follows this.

That's why the docs linked from THRIFT-5587 state explicitly that {*}Thrift 
uses "network" order{*}, which is also consistent with our general integer 
serialisation scheme. Furthermore, there are also test cases intended to test 
exactly this. 

Some helpful and/or amusing links (depends on how you look at it):
 - [https://www.ietf.org/rfc/rfc4122.txt]
 - 
[https://stackoverflow.com/questions/10850075/guid-uuid-compatibility-issue-between-net-and-linux]
 - [https://lists.gnu.org/archive/html/bug-parted/2002-01/msg00099.html]

> Add UUID support for C++
> 
>
> Key: THRIFT-5772
> URL: https://issues.apache.org/jira/browse/THRIFT-5772
> Project: Thrift
>  Issue Type: New Feature
>Reporter: Carel
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Starting the discussion to add UUID support for C++.
> I have started with an implementation (See PR linked soon)
> Open points for discussion: 
> # Is there perhaps a need to add a wrapper class for UUID?
> ## I started off with {{std::string}} for ease-of-use
> ## 'ease-of-use' has the drawback of ease of miss-use... 
> ## Something lightweight as a strong wrapper to wrap a `{{uint8_t data[16];}}`
> ### A wrapper gives us the ability to add utility functions, like 
> `to_string()` and `from_string()`
> ### Can use {{boost::uuids::uuid}} in the implementation, hidden from users 
> (see current implementation)
> ## I will see if I can't implement something while this PR is looked at.
> # Can someone help with some cross tests
> ## With the absence of working dockers I am really struggling to get other 
> languages compiled.
> ## I don't have enough experience with other languages to effectively do this
> ## I will probably be able to add Java tests if there is something to build 
> on (pointers needed)
> # How important is the JSON side? 
> ## I did add the support but I see only go has some support for it. 
> # (edit) How important is the HOST vs Network order on the UUID?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-5772) Add UUID support for C++

2024-04-04 Thread Jens Geyer (Jira)



[ 
https://issues.apache.org/jira/browse/THRIFT-5772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834070#comment-17834070
 ] 

Jens Geyer commented on THRIFT-5772:


A well-defined byte order is important to be able to exchange uuid bytes across 
platforms. Problem here is that there are in fact several implementations from 
different vendors doing inconsistent stuff (see links below). And there is 
RFC4122 that suggests network order but not everybody follows this.

That's why the docs linked from THRIFT-5587 state explicitly that {*}Thrift 
uses "network" order{*}, which is also consistent with our general integer 
serialisation scheme. Furthermore, there are also test cases intended to test 
exactly this. 

Some helpful and/or amusing links (depends on how you look at it):
 - [https://www.ietf.org/rfc/rfc4122.txt]
 - 
[https://stackoverflow.com/questions/10850075/guid-uuid-compatibility-issue-between-net-and-linux]
 - [https://lists.gnu.org/archive/html/bug-parted/2002-01/msg00099.html]

> Add UUID support for C++
> 
>
> Key: THRIFT-5772
> URL: https://issues.apache.org/jira/browse/THRIFT-5772
> Project: Thrift
>  Issue Type: New Feature
>Reporter: Carel
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Starting the discussion to add UUID support for C++.
> I have started with an implementation (See PR linked soon)
> Open points for discussion: 
> # Is there perhaps a need to add a wrapper class for UUID?
> ## I started off with {{std::string}} for ease-of-use
> ## 'ease-of-use' has the drawback of ease of miss-use... 
> ## Something lightweight as a strong wrapper to wrap a `{{uint8_t data[16];}}`
> ### A wrapper gives us the ability to add utility functions, like 
> `to_string()` and `from_string()`
> ### Can use {{boost::uuids::uuid}} in the implementation, hidden from users 
> (see current implementation)
> ## I will see if I can't implement something while this PR is looked at.
> # Can someone help with some cross tests
> ## With the absence of working dockers I am really struggling to get other 
> languages compiled.
> ## I don't have enough experience with other languages to effectively do this
> ## I will probably be able to add Java tests if there is something to build 
> on (pointers needed)
> # How important is the JSON side? 
> ## I did add the support but I see only go has some support for it. 
> # (edit) How important is the HOST vs Network order on the UUID?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (THRIFT-5755) Docker image build fail



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

Jens Geyer updated THRIFT-5755:
---
Component/s: Build Process
 (was: Compiler (General))

> Docker image build fail
> ---
>
> Key: THRIFT-5755
> URL: https://issues.apache.org/jira/browse/THRIFT-5755
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
> Environment: Ubuntu 22.04
>Reporter: Volodymyr Panivko
>Assignee: Thomas Bruggink
>Priority: Major
> Fix For: 0.21.0
>
>  Time Spent: 5h 20m
>  Remaining Estimate: 0h
>
> When I'm trying to build an docker image and run command
> {code:java}
> docker build -t thrift build/docker/ubuntu-bionic{code}
> I get such error
>  
> {code:java}
>  
>  => ERROR [13/35] RUN apt-get install -y --no-install-recommends       `# 
> dotnet core dependencies`       dotnet-sdk-8.0       dotnet-runtime-8.0       
> aspnetcore-runtime-8.0       dotnet-apphost-pack-8.0           1.3s
> --
>  > [13/35] RUN apt-get install -y --no-install-recommends       `# dotnet 
> core dependencies`       dotnet-sdk-8.0       dotnet-runtime-8.0       
> aspnetcore-runtime-8.0       dotnet-apphost-pack-8.0:
> 0.350 Reading package lists...
> 1.113 Building dependency tree...
> 1.216 Reading state information...
> 1.311 E: Unable to locate package dotnet-sdk-8.0
> 1.311 E: Couldn't find any package by glob 'dotnet-sdk-8.0'
> 1.311 E: Couldn't find any package by regex 'dotnet-sdk-8.0'
> 1.311 E: Unable to locate package dotnet-runtime-8.0
> 1.311 E: Couldn't find any package by glob 'dotnet-runtime-8.0'
> 1.311 E: Couldn't find any package by regex 'dotnet-runtime-8.0'
> 1.311 E: Unable to locate package aspnetcore-runtime-8.0
> 1.311 E: Couldn't find any package by glob 'aspnetcore-runtime-8.0'
> 1.311 E: Couldn't find any package by regex 'aspnetcore-runtime-8.0'
> 1.311 E: Unable to locate package dotnet-apphost-pack-8.0
> 1.311 E: Couldn't find any package by glob 'dotnet-apphost-pack-8.0'
> 1.311 E: Couldn't find any package by regex 'dotnet-apphost-pack-8.0'
> --
> Dockerfile:134
> 
>  133 |     
>  134 | >>> RUN apt-get install -y --no-install-recommends \
>  135 | >>>       `# dotnet core dependencies` \
>  136 | >>>       dotnet-sdk-8.0 \
>  137 | >>>       dotnet-runtime-8.0 \
>  138 | >>>       aspnetcore-runtime-8.0 \
>  139 | >>>       dotnet-apphost-pack-8.0
>  140 |     
> 
> ERROR: failed to solve: process "/bin/sh -c apt-get install -y 
> --no-install-recommends       `# dotnet core dependencies`       
> dotnet-sdk-8.0       dotnet-runtime-8.0       aspnetcore-runtime-8.0       
> dotnet-apphost-pack-8.0" did not complete successfully: exit code: 100
> {code}
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (THRIFT-5755) Docker image build fail



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

Jens Geyer resolved THRIFT-5755.

Fix Version/s: 0.21.0
 Assignee: Thomas Bruggink
   Resolution: Fixed

> Docker image build fail
> ---
>
> Key: THRIFT-5755
> URL: https://issues.apache.org/jira/browse/THRIFT-5755
> Project: Thrift
>  Issue Type: Bug
> Environment: Ubuntu 22.04
>Reporter: Volodymyr Panivko
>Assignee: Thomas Bruggink
>Priority: Major
> Fix For: 0.21.0
>
>  Time Spent: 5h 20m
>  Remaining Estimate: 0h
>
> When I'm trying to build an docker image and run command
> {code:java}
> docker build -t thrift build/docker/ubuntu-bionic{code}
> I get such error
>  
> {code:java}
>  
>  => ERROR [13/35] RUN apt-get install -y --no-install-recommends       `# 
> dotnet core dependencies`       dotnet-sdk-8.0       dotnet-runtime-8.0       
> aspnetcore-runtime-8.0       dotnet-apphost-pack-8.0           1.3s
> --
>  > [13/35] RUN apt-get install -y --no-install-recommends       `# dotnet 
> core dependencies`       dotnet-sdk-8.0       dotnet-runtime-8.0       
> aspnetcore-runtime-8.0       dotnet-apphost-pack-8.0:
> 0.350 Reading package lists...
> 1.113 Building dependency tree...
> 1.216 Reading state information...
> 1.311 E: Unable to locate package dotnet-sdk-8.0
> 1.311 E: Couldn't find any package by glob 'dotnet-sdk-8.0'
> 1.311 E: Couldn't find any package by regex 'dotnet-sdk-8.0'
> 1.311 E: Unable to locate package dotnet-runtime-8.0
> 1.311 E: Couldn't find any package by glob 'dotnet-runtime-8.0'
> 1.311 E: Couldn't find any package by regex 'dotnet-runtime-8.0'
> 1.311 E: Unable to locate package aspnetcore-runtime-8.0
> 1.311 E: Couldn't find any package by glob 'aspnetcore-runtime-8.0'
> 1.311 E: Couldn't find any package by regex 'aspnetcore-runtime-8.0'
> 1.311 E: Unable to locate package dotnet-apphost-pack-8.0
> 1.311 E: Couldn't find any package by glob 'dotnet-apphost-pack-8.0'
> 1.311 E: Couldn't find any package by regex 'dotnet-apphost-pack-8.0'
> --
> Dockerfile:134
> 
>  133 |     
>  134 | >>> RUN apt-get install -y --no-install-recommends \
>  135 | >>>       `# dotnet core dependencies` \
>  136 | >>>       dotnet-sdk-8.0 \
>  137 | >>>       dotnet-runtime-8.0 \
>  138 | >>>       aspnetcore-runtime-8.0 \
>  139 | >>>       dotnet-apphost-pack-8.0
>  140 |     
> 
> ERROR: failed to solve: process "/bin/sh -c apt-get install -y 
> --no-install-recommends       `# dotnet core dependencies`       
> dotnet-sdk-8.0       dotnet-runtime-8.0       aspnetcore-runtime-8.0       
> dotnet-apphost-pack-8.0" did not complete successfully: exit code: 100
> {code}
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (THRIFT-5755) Docker image build fail



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

Jens Geyer updated THRIFT-5755:
---
Component/s: Compiler (General)

> Docker image build fail
> ---
>
> Key: THRIFT-5755
> URL: https://issues.apache.org/jira/browse/THRIFT-5755
> Project: Thrift
>  Issue Type: Bug
>  Components: Compiler (General)
> Environment: Ubuntu 22.04
>Reporter: Volodymyr Panivko
>Assignee: Thomas Bruggink
>Priority: Major
> Fix For: 0.21.0
>
>  Time Spent: 5h 20m
>  Remaining Estimate: 0h
>
> When I'm trying to build an docker image and run command
> {code:java}
> docker build -t thrift build/docker/ubuntu-bionic{code}
> I get such error
>  
> {code:java}
>  
>  => ERROR [13/35] RUN apt-get install -y --no-install-recommends       `# 
> dotnet core dependencies`       dotnet-sdk-8.0       dotnet-runtime-8.0       
> aspnetcore-runtime-8.0       dotnet-apphost-pack-8.0           1.3s
> --
>  > [13/35] RUN apt-get install -y --no-install-recommends       `# dotnet 
> core dependencies`       dotnet-sdk-8.0       dotnet-runtime-8.0       
> aspnetcore-runtime-8.0       dotnet-apphost-pack-8.0:
> 0.350 Reading package lists...
> 1.113 Building dependency tree...
> 1.216 Reading state information...
> 1.311 E: Unable to locate package dotnet-sdk-8.0
> 1.311 E: Couldn't find any package by glob 'dotnet-sdk-8.0'
> 1.311 E: Couldn't find any package by regex 'dotnet-sdk-8.0'
> 1.311 E: Unable to locate package dotnet-runtime-8.0
> 1.311 E: Couldn't find any package by glob 'dotnet-runtime-8.0'
> 1.311 E: Couldn't find any package by regex 'dotnet-runtime-8.0'
> 1.311 E: Unable to locate package aspnetcore-runtime-8.0
> 1.311 E: Couldn't find any package by glob 'aspnetcore-runtime-8.0'
> 1.311 E: Couldn't find any package by regex 'aspnetcore-runtime-8.0'
> 1.311 E: Unable to locate package dotnet-apphost-pack-8.0
> 1.311 E: Couldn't find any package by glob 'dotnet-apphost-pack-8.0'
> 1.311 E: Couldn't find any package by regex 'dotnet-apphost-pack-8.0'
> --
> Dockerfile:134
> 
>  133 |     
>  134 | >>> RUN apt-get install -y --no-install-recommends \
>  135 | >>>       `# dotnet core dependencies` \
>  136 | >>>       dotnet-sdk-8.0 \
>  137 | >>>       dotnet-runtime-8.0 \
>  138 | >>>       aspnetcore-runtime-8.0 \
>  139 | >>>       dotnet-apphost-pack-8.0
>  140 |     
> 
> ERROR: failed to solve: process "/bin/sh -c apt-get install -y 
> --no-install-recommends       `# dotnet core dependencies`       
> dotnet-sdk-8.0       dotnet-runtime-8.0       aspnetcore-runtime-8.0       
> dotnet-apphost-pack-8.0" did not complete successfully: exit code: 100
> {code}
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (THRIFT-5750) Remove "ansistr_binary_" option



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

Jens Geyer resolved THRIFT-5750.

Fix Version/s: 0.21.0
   Resolution: Fixed

> Remove "ansistr_binary_" option
> ---
>
> Key: THRIFT-5750
> URL: https://issues.apache.org/jira/browse/THRIFT-5750
> Project: Thrift
>  Issue Type: Improvement
>  Components: Delphi - Compiler
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Minor
> Fix For: 0.21.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> That option was introduced earlier for some rather exotic use case which a) 
> is not really relevant anymore and b) should not be part of a general library 
> anymore.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Regarding Haskell

2024-03-31 Thread Jens Geyer


Hi tjakway,

we indeed had Haskell bindings. Since Haskell community decided to do 
their own implementation and nobody really cared about maintaining our 
implementation anymore the code was removed a while ago.


https://issues.apache.org/jira/browse/THRIFT-5347

Have fun,

JensG

Packages 0.20.0

2024-03-23 Thread Jens Geyer


Hi all,

following packages and package managers have been published/updated

- netstd nuget
- haxelib
- java maven (needs some time to update)
- npm
- php packagist.org
- rubygems

Have fun,
JensG





OpenPGP_0x76BD340FC4B75865.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[jira] [Updated] (THRIFT-5757) Unit tests for php lib

2024-03-23 Thread Jens Geyer (Jira)



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

Jens Geyer updated THRIFT-5757:
---
Fix Version/s: (was: 0.21.0)

> Unit tests for php lib
> --
>
> Key: THRIFT-5757
> URL: https://issues.apache.org/jira/browse/THRIFT-5757
> Project: Thrift
>  Issue Type: New Feature
>  Components: PHP - Library
>Reporter: Volodymyr Panivko
>Assignee: Volodymyr Panivko
>Priority: Major
> Attachments: image-2024-02-24-10-41-37-836.png
>
>  Time Spent: 12h 20m
>  Remaining Estimate: 0h
>
> After running PHP unit tests for each pull request THRIFT-5756
> Next step is writing test for php lib.
> It will be several pull request for this task.  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Reopened] (THRIFT-5757) Unit tests for php lib

2024-03-23 Thread Jens Geyer (Jira)



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

Jens Geyer reopened THRIFT-5757:


> Unit tests for php lib
> --
>
> Key: THRIFT-5757
> URL: https://issues.apache.org/jira/browse/THRIFT-5757
> Project: Thrift
>  Issue Type: New Feature
>  Components: PHP - Library
>Reporter: Volodymyr Panivko
>Assignee: Volodymyr Panivko
>Priority: Major
> Fix For: 0.21.0
>
> Attachments: image-2024-02-24-10-41-37-836.png
>
>  Time Spent: 12h 20m
>  Remaining Estimate: 0h
>
> After running PHP unit tests for each pull request THRIFT-5756
> Next step is writing test for php lib.
> It will be several pull request for this task.  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[RESULT][VOTE] Apache Thrift 0.20.0-rc1 release candidate

2024-03-22 Thread Jens Geyer


Hi all,

Vote ended with four +1 votes. There were no 0 or -1 votes.

Summary:
+1: Jens Geyer, Yuxuan Wang, Duru Can Celasun, Randy Abernethy

The vote for the Apache Thrift 0.20.0 release candidate 1 is successful.
Thank you to all who helped test and verify.

Voting Thread:
https://lists.apache.org/thread/lrrfv9x0yb44bq9b49v357f5j504h747

Have fun,
JensG


Am 12.03.2024 um 23:13 schrieb Jens Geyer:

All,

I propose that we accept the following release candidate as the 
official Apache Thrift 0.20.0 release:


https://dist.apache.org/repos/dist/dev/thrift/0.20.0-rc1/thrift-0.20.0.tar.gz 



The release candidate was created from the release/0.20.0 branch and 
can be cloned using:


git clone -b release/0.20.0 https://github.com/apache/thrift.git

The release candidates GPG signature can be found at:
https://dist.apache.org/repos/dist/dev/thrift/0.20.0-rc1/thrift-0.20.0.tar.gz.asc 



The release candidates checksums are:
md5: aadebde599e1f5235acd3c730721b873
sha1: 08330d85fa037440d5b0873aa18edd654194483c
sha256: b5d8311a779470e1502c027f428a1db542f5c051c8e1280ccd2163fa935ff2d6

A prebuilt statically-linked Windows compiler is available at:
https://dist.apache.org/repos/dist/dev/thrift/0.20.0-rc1/thrift-0.20.0.exe 



Prebuilt statically-linked Windows compiler GPG signature:
https://dist.apache.org/repos/dist/dev/thrift/0.20.0-rc1/thrift-0.20.0.exe.asc 



Prebuilt statically-linked Windows compiler checksums are:

md5: e867efb609da1f89a77a078c79d435b9
sha1: 1268712650a525a70125e96ddeb47035b1dfdbb7
sha256: 7e554be788b6f1fddb05d2be2a3cd2dc853075218c937adb9e9b834959c9c060

The CHANGES list for this release is available at:
https://github.com/apache/thrift/blob/0.20.0/CHANGES.md

Please download, verify sig/sum, install and test the libraries and 
languages of your choice.



I start this voting thread with my own +1 vote.


This vote will close in 145 hours on 2024-02-19 00:00 UTC
https://www.timeanddate.com/countdown/generic?iso=20240319T=1440

[ ] +1 Release this as Apache Thrift 0.20.0
[ ] +0
[ ] -1 Do not release this as Apache Thrift 0.20.0 because...

Have fun,
JensG





OpenPGP_0x76BD340FC4B75865.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[jira] [Resolved] (THRIFT-5769) Large messages crash Node.js client when using TFramedTransport

2024-03-18 Thread Jens Geyer (Jira)



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

Jens Geyer resolved THRIFT-5769.

Fix Version/s: 0.21.0
 Assignee: Tuomo Jokimies
   Resolution: Fixed

> Large messages crash Node.js client when using TFramedTransport
> ---
>
> Key: THRIFT-5769
> URL: https://issues.apache.org/jira/browse/THRIFT-5769
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Affects Versions: 0.19.0
>Reporter: Tuomo Jokimies
>Assignee: Tuomo Jokimies
>Priority: Major
> Fix For: 0.21.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Large messages cause Thrift client to crash when using TFramedTransport.
> Crash is caused by array overflow of residual variable in receiver function.
>  
> *Stack trace for Node.js v21.7.1*
> (pinpoints the cause as it is using new version of V8)
> {code:java}
> /thrift/lib/nodejs/lib/thrift/framed_transport.js:43
>   residual.push(data[i])
>^
> RangeError: Invalid array length
> at Array.push ()
> at /thrift/lib/nodejs/lib/thrift/framed_transport.js:43:16
> {code}
>  
> *Stack trace for Node.js LTS v20.11.1*
> {code:java}
> #
> # Fatal error in , line 0
> # Fatal JavaScript invalid size error 169220804 (see crbug.com/1201626)
> #
> #
> #
> #FailureMessage Object: 0x16f48a0f8
> - Native stack trace -
> 1: 0x100aad340 node::NodePlatform::GetStackTracePrinter()::$_3::__invoke() 
> [/.nvm/versions/node/v20.11.1/bin/node]
> 2: 0x101b309ac V8_Fatal(char const*, ) 
> [/.nvm/versions/node/v20.11.1/bin/node]
> 3: 0x100d71334 
> v8::internal::FactoryBase::NewFixedArrayWithFiller(v8::internal::Handle,
>  int, v8::internal::Handle, 
> v8::internal::AllocationType) 
> [/.nvm/versions/node/v20.11.1/bin/node]
> 4: 0x100f0cf68 v8::internal::(anonymous 
> namespace)::ElementsAccessorBase namespace)::FastPackedSmiElementsAccessor, v8::internal::(anonymous 
> namespace)::ElementsKindTraits<(v8::internal::ElementsKind)0>>::GrowCapacity(v8::internal::Handle,
>  unsigned int) [/.nvm/versions/node/v20.11.1/bin/node]
> 5: 0x101158600 v8::internal::Runtime_GrowArrayElements(int, unsigned long*, 
> v8::internal::Isolate*) [/.nvm/versions/node/v20.11.1/bin/node]
> 6: 0x1014c4c44 Builtins_CEntry_Return1_ArgvOnStack_NoBuiltinExit 
> [/.nvm/versions/node/v20.11.1/bin/node]
> 7: 0x1064cfe9c
> 8: 0x1064aac88
> 9: 0x10143c3e4 Builtins_InterpreterEntryTrampoline 
> [/.nvm/versions/node/v20.11.1/bin/node]
> 10: 0x1064aac88
> 11: 0x10143c3e4 Builtins_InterpreterEntryTrampoline 
> [/.nvm/versions/node/v20.11.1/bin/node]
> 12: 0x10143c3e4 Builtins_InterpreterEntryTrampoline 
> [/.nvm/versions/node/v20.11.1/bin/node]
> 13: 0x10143a50c Builtins_JSEntryTrampoline 
> [/.nvm/versions/node/v20.11.1/bin/node]
> 14: 0x10143a1f4 Builtins_JSEntry 
> [/.nvm/versions/node/v20.11.1/bin/node]
> 15: 0x100d104f8 v8::internal::(anonymous 
> namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous 
> namespace)::InvokeParams const&) 
> [/.nvm/versions/node/v20.11.1/bin/node]
> 16: 0x100d0f944 v8::internal::Execution::Call(v8::internal::Isolate*, 
> v8::internal::Handle, 
> v8::internal::Handle, int, 
> v8::internal::Handle*) 
> [/.nvm/versions/node/v20.11.1/bin/node]
> 17: 0x100bea214 v8::Function::Call(v8::Local, 
> v8::Local, int, v8::Local*) 
> [/.nvm/versions/node/v20.11.1/bin/node]
> 18: 0x100978fd8 node::InternalMakeCallback(node::Environment*, 
> v8::Local, v8::Local, v8::Local, int, 
> v8::Local*, node::async_context) 
> [/.nvm/versions/node/v20.11.1/bin/node]
> 19: 0x100979304 node::MakeCallback(v8::Isolate*, v8::Local, 
> v8::Local, int, v8::Local*, node::async_context) 
> [/.nvm/versions/node/v20.11.1/bin/node]
> 20: 0x1009ee554 node::Environment::CheckImmediate(uv_check_s*) 
> [/.nvm/versions/node/v20.11.1/bin/node]
> 21: 0x1014209e0 uv__run_check 
> [/.nvm/versions/node/v20.11.1/bin/node]
> 22: 0x10141a700 uv_run [/.nvm/versions/node/v20.11.1/bin/node]
> 23: 0x100979754 node::SpinEventLoopInternal(node::Environment*) 
> [/.nvm/versions/node/v20.11.1/bin/node]
> 24: 0x100a89c6c node::NodeMainInstance::Run(node::ExitCode*, 
> node::Environment*) [/.nvm/versions/node/v20.11.1/bin/node]
> 25: 0x100a89a08 node::NodeMainInstance::Run() 
> [/.nvm/versions/node/v20.11.1/bin/node]
> 26: 0x100a13718 node::Start(int, char**) 
> [/.nvm/versions/node/v20.11.1/bin/node]
> 27: 0x1a61dff28 start [/usr/lib/dyld]{code}
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (THRIFT-5682) UB in generated C++ code, stops compiling with C++20

2024-03-13 Thread Jens Geyer (Jira)



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

Jens Geyer resolved THRIFT-5682.

Fix Version/s: 0.21.0
 Assignee: Lukas Barth
   Resolution: Fixed

Thanks!

> UB in generated C++ code, stops compiling with C++20
> 
>
> Key: THRIFT-5682
> URL: https://issues.apache.org/jira/browse/THRIFT-5682
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Compiler
>Affects Versions: 0.17.0
>Reporter: Lukas Barth
>Assignee: Lukas Barth
>Priority: Major
>  Labels: pull-request-available
> Fix For: 0.21.0
>
>  Time Spent: 4h 10m
>  Remaining Estimate: 0h
>
> The C++ compiler of Thrift 0.17.0 produces C++ code with undefined behavior, 
> which stops compiling on Clang 15 in C++20 mode.
> For a generated class, both the default constructor and {{operator==}} 
> implementations reference certain member functions of the class' members. As 
> an example, the default constructor references (i.e., "uses") the default 
> constructors of its members.
> If a class contains a {{{}std::vector{}}}, and {{Foo}} has only been 
> _forward_ declared (which happens often in Thrift-generated code), this 
> creates undefined behavior: The {{std::vector}} specification states that as 
> long as {{Foo}} is an incomplete type, it is fine to reference 
> {{{}std::vector{}}}, but not any members (such as its default 
> constructor).
> Thus, we must defer our default constructor's implementation (which 
> references the default constructor of std::vector) to a point where Foo is a 
> complete type. That is the case in the .cpp file.
> The same holds for operator==.Example
> Take this very simple Thrift file:
> {{struct StructA {}}
> {{  1:required list myBs}}
> {{}}}
> {{struct StructB}}
> {
> {{  1:required string someString}}
> {{}}}
> If I compile this using {{thrift --gen cpp:no_skeleton -o out ./file.thrift}} 
> I get a header file that contains the following:
> {{class StructA;}}
> {{class StructB;}}
> {{class StructA : …}}
> {{public:}}
> {{  …}}
> {{{}  StructA() noexcept {{
> {{  …}}
> {{  std::vector myBs;}}
> {{  …}}
> {{};}}
> {{…}}
> {{class StructB : …}}
> { … };
>  
> In this case, the default constructor for {{StructA}} references the default 
> constructor of {{std::vector}} while {{StructB}} is still an 
> incomplete type. *This is undefined behavior.* It did apparently compile with 
> all big compilers until recently, but with C++20, Clang 15 stops accepting 
> this kind of construct, as you can see here at CompilerExplorer: 
> [https://godbolt.org/z/xcc4av6cb]
> {{ }}
> h2. Proposed Solution
> I propose to move the definitions of the default constructor and 
> {{operator==}} from the {{foobar_types.h}} into the {{foobar_types.cpp}} 
> file. That way, when the definition is seen (and therefore the methods of 
> {{std::vector}} referenced), Foo already is a complete type and 
> everything works out.
> The only alternative Solution (and which only works if Thrift does not allow 
> circular dependencies - does it?) that I can see would be to compute a DAG of 
> dependencies between the structures and then output them in topological 
> order. That would not be a minor change.
> I guess that the reason for the definitions being in the header file is that 
> this allows better inlining of these two methods. Nowadays, most 
> compilers/linkers perform link-time optimization, which allows for inlining 
> to happen at link time, so my feeling is that moving the definitions into 
> their own translation unit inside the CPP file should not cause significant 
> performance loss.
>  
> I have created a Pull Request for my proposed solution here: 
> [https://github.com/apache/thrift/pull/2755]
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (THRIFT-5766) Replace std::endl with "\n"

2024-03-13 Thread Jens Geyer (Jira)



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

Jens Geyer reassigned THRIFT-5766:
--

Assignee: Carel

> Replace std::endl with "\n"
> ---
>
> Key: THRIFT-5766
> URL: https://issues.apache.org/jira/browse/THRIFT-5766
> Project: Thrift
>  Issue Type: Improvement
>  Components: Compiler (General)
>Affects Versions: 0.19.0
>Reporter: Carel
>Assignee: Carel
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Remove the usage of {{std::endl}} to force new lines for {{std::ostream}}
> Rationale
>  * Using `std::endl` for linebreaks is bad practice since {{std::endl}} also 
> forces a stream flush.
>  * A past Ticket THRIFT-1815 identified the flush component as a problem and 
> the behavior of {{std::endl}} was replaced with a custom constant that only 
> did the new line to minimize code changes.
>  * This enforces bad practice and changes expected behaviour
>  * The [C++ Core Guidelines 
> SL.io.50|https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#slio50-avoid-endl]
>  also suggest that {{std::endl}} should be avoided
> I propose (by PR) to remove the usage of {{endl}} and instead use {{\n}} 
> directly to avoid building on the bad practice.
> See: [https://github.com/apache/thrift/pull/2943]
>  * Replace the usage of {{endl}} with "\n" in all genertors
>  * Replace the usage in most test files and examples
>  * Keep the usage in {{std::cerr}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (THRIFT-5766) Replace std::endl with "\n"

2024-03-13 Thread Jens Geyer (Jira)



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

Jens Geyer updated THRIFT-5766:
---
Description: 
Remove the usage of {{std::endl}} to force new lines for {{std::ostream}}

Rationale
 * Using `std::endl` for linebreaks is bad practice since {{std::endl}} also 
forces a stream flush.
 * A past Ticket THRIFT-1815 identified the flush component as a problem and 
the behavior of {{std::endl}} was replaced with a custom constant that only did 
the new line to minimize code changes.
 * This enforces bad practice and changes expected behaviour
 * The [C++ Core Guidelines 
SL.io.50|https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#slio50-avoid-endl]
 also suggest that {{std::endl}} should be avoided

I propose (by PR) to remove the usage of {{endl}} and instead use {{\n}} 
directly to avoid building on the bad practice.

See: [https://github.com/apache/thrift/pull/2943]
 * Replace the usage of {{endl}} with "\n" in all genertors
 * Replace the usage in most test files and examples
 * Keep the usage in {{std::cerr}}

  was:
Remove the usage of {{std::endl}} to force new lines for {{std::ostream}}
 
Rationale
 * Using `std::endl` for linebreaks is bad practice since {{std::endl}} also 
forces a stream flush.
 * A past Ticket THRIFT-1815 identified the flush component as a problem and 
instead of a proper fix the behavior of {{std::endl}} was replaced with a 
custom constant that only did the new line.
 * This enforces bad practice and changes expected behaviour
 * The [C++ Core Guidelines 
SL.io.50|https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#slio50-avoid-endl]
 also suggest that {{std::endl}} should be avoided
 

I propose (by PR) to remove the usage of {{endl}} and instead use {{\n}} 
directly to avoid building on the bad practice. 

See: https://github.com/apache/thrift/pull/2943
* Replace the usage of {{endl}} with "\n" in all genertors
* Replace the usage in most test files and examples
* Keep the usage in {{std::cerr}}


> Replace std::endl with "\n"
> ---
>
> Key: THRIFT-5766
> URL: https://issues.apache.org/jira/browse/THRIFT-5766
> Project: Thrift
>  Issue Type: Improvement
>  Components: Compiler (General)
>Affects Versions: 0.19.0
>Reporter: Carel
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Remove the usage of {{std::endl}} to force new lines for {{std::ostream}}
> Rationale
>  * Using `std::endl` for linebreaks is bad practice since {{std::endl}} also 
> forces a stream flush.
>  * A past Ticket THRIFT-1815 identified the flush component as a problem and 
> the behavior of {{std::endl}} was replaced with a custom constant that only 
> did the new line to minimize code changes.
>  * This enforces bad practice and changes expected behaviour
>  * The [C++ Core Guidelines 
> SL.io.50|https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#slio50-avoid-endl]
>  also suggest that {{std::endl}} should be avoided
> I propose (by PR) to remove the usage of {{endl}} and instead use {{\n}} 
> directly to avoid building on the bad practice.
> See: [https://github.com/apache/thrift/pull/2943]
>  * Replace the usage of {{endl}} with "\n" in all genertors
>  * Replace the usage in most test files and examples
>  * Keep the usage in {{std::cerr}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[VOTE] Apache Thrift 0.20.0-rc1 release candidate

2024-03-12 Thread Jens Geyer


All,

I propose that we accept the following release candidate as the official 
Apache Thrift 0.20.0 release:


https://dist.apache.org/repos/dist/dev/thrift/0.20.0-rc1/thrift-0.20.0.tar.gz

The release candidate was created from the release/0.20.0 branch and can 
be cloned using:


git clone -b release/0.20.0 https://github.com/apache/thrift.git

The release candidates GPG signature can be found at:
https://dist.apache.org/repos/dist/dev/thrift/0.20.0-rc1/thrift-0.20.0.tar.gz.asc

The release candidates checksums are:
md5: aadebde599e1f5235acd3c730721b873
sha1: 08330d85fa037440d5b0873aa18edd654194483c
sha256: b5d8311a779470e1502c027f428a1db542f5c051c8e1280ccd2163fa935ff2d6

A prebuilt statically-linked Windows compiler is available at:
https://dist.apache.org/repos/dist/dev/thrift/0.20.0-rc1/thrift-0.20.0.exe

Prebuilt statically-linked Windows compiler GPG signature:
https://dist.apache.org/repos/dist/dev/thrift/0.20.0-rc1/thrift-0.20.0.exe.asc

Prebuilt statically-linked Windows compiler checksums are:

md5: e867efb609da1f89a77a078c79d435b9
sha1: 1268712650a525a70125e96ddeb47035b1dfdbb7
sha256: 7e554be788b6f1fddb05d2be2a3cd2dc853075218c937adb9e9b834959c9c060

The CHANGES list for this release is available at:
https://github.com/apache/thrift/blob/0.20.0/CHANGES.md

Please download, verify sig/sum, install and test the libraries and 
languages of your choice.



I start this voting thread with my own +1 vote.


This vote will close in 145 hours on 2024-02-19 00:00 UTC
https://www.timeanddate.com/countdown/generic?iso=20240319T=1440

[ ] +1 Release this as Apache Thrift 0.20.0
[ ] +0
[ ] -1 Do not release this as Apache Thrift 0.20.0 because...

Have fun,
JensG





OpenPGP_0x76BD340FC4B75865.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[jira] [Resolved] (THRIFT-5744) Proposal: Switch all go logging in the library to slog

2024-03-12 Thread Jens Geyer (Jira)



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

Jens Geyer resolved THRIFT-5744.

Fix Version/s: 0.20.0
   Resolution: Fixed

> Proposal: Switch all go logging in the library to slog
> --
>
> Key: THRIFT-5744
> URL: https://issues.apache.org/jira/browse/THRIFT-5744
> Project: Thrift
>  Issue Type: Task
>  Components: Go - Library
>Reporter: Yuxuan Wang
>Assignee: Yuxuan Wang
>Priority: Major
> Fix For: 0.20.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> In the go library, we used to use the stdlib [log|https://pkg.go.dev/log] 
> library to do logging. Then in THRIFT-4985 we added a simple wrapper 
> interface, Logger, to replace all the logging usage in the library code.
> This Proposal is that we switch all internal logging to stdlib 
> [slog|https://pkg.go.dev/log/slog] (after go 1.22 release so our minimal 
> supported go version is at least 1.21 and has slog in stdlib), and 
> deprecate/remove the Logger wrapper interface.
> In the current go library code, there are 2 places logging is used:
> # TDebugProtocol: with this proposal we should switch them to 
> slog.DebugContext
> # TSimpleServer: we log errors from processRequests, so with this proposel we 
> should switch them to slog.ErrorContext, and also add a SetBaseContext api to 
> TSimpleServer so a base context can be set to be used in that logging
> The original, stdlib log approach, didn't work out well because the API of it 
> is too limited (no log level, no context, no structured logging/kv pair 
> ability, etc.), resulting in a lot of third-party logging library 
> implementations cannot be adapted to the stdlib log api (even when some of 
> them, for example zap, provided a way to replace the default log logger to be 
> zap backend, because of the limitation of the api a lot of the features like 
> log level and kv pairs are still unusable with log api), resulting in mixed 
> logging in applications.
> The Logger wrapper interface resolved the mixed logging issue, but its API is 
> still very limited (it's a common denominator approach), so it still have 
> issues like lack of fine grain control of the logging, and performance (see 
> THRIFT-5539, because the lack of log level we cannot skip the Sprintf used by 
> TDebugProtocol when we don't need the logging, resulting in us forking out 
> TDuplicateToProtocol).
> The new slog stdlib is go team's answer to the fragmentation of logging 
> library issue in the go ecosystem, and it does have a really good chance to 
> really unite all the logging libraries once and for all:
> * The context in logging calls provides the ability to: 1) attach context kv 
> pairs automatically (trace id, etc.); 2) control minimal log level (you can 
> provide a ctx before calling thrift code that could do potential logging to 
> raise/lower minimal log level as needed); 3) or even do additional log 
> suppressing logic based on the context
> * Even if some developers still prefer zap/zerolog/etc. for their performance 
> (zap still claims to be faster than slog, for example), there are wrapper 
> libraries to set the default slog handler to a zap/zerolog/etc. 
> implementation so they still have uniformed logging, and the new API from 
> slog means that they can still preserve the majority of the features from 
> those third party logging libraries.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (THRIFT-5745) go: Implement slog.LogValuer for exceptions and/or structs

2024-03-12 Thread Jens Geyer (Jira)



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

Jens Geyer resolved THRIFT-5745.

Fix Version/s: 0.20.0
   Resolution: Fixed

> go: Implement slog.LogValuer for exceptions and/or structs
> --
>
> Key: THRIFT-5745
> URL: https://issues.apache.org/jira/browse/THRIFT-5745
> Project: Thrift
>  Issue Type: Task
>  Components: Go - Compiler
>Reporter: Yuxuan Wang
>Assignee: Yuxuan Wang
>Priority: Major
> Fix For: 0.20.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> To follow up on THRIFT-5744, implement 
> [slog.LogValuer|https://pkg.go.dev/log/slog#LogValuer] on compiler generated 
> exceptions, and maybe also structs.
> The current problem is that when logging an exception, the Stringer 
> implementation will be used, but that usually gives you quite unhelpful 
> string, especially when optional fields are used.
> For example we have [this exception 
> defined|https://github.com/reddit/baseplate.py/blob/8c446337dab6a1692900decf9cd01f3f4e39d764/baseplate/thrift/baseplate.thrift#L197]:
> {code:java}
> exception Error {
> 1: optional i32 code
> 2: optional string message
> 3: optional map details
> 4: optional bool retryable
> }
> {code}
> When you create an instance of it:
> {code:go}
> return {
>   Code: thrift.Int32Ptr(404),
>   Message: thrift.Pointer("no such id"),
> }
> {code}
> And then log that error, instead of getting something useful with the code 
> (404) and message ("no such id") in it, you get something like this instead 
> because this is how we implemented fmt.Stringer from the compiler:
> {code:go}
> Error({Code:0xc000426648 Message:0xc00041ca10 Details:map[] Retryable:})
> {code}
> The compiler generates implementation for json.Marshaler for all exceptions, 
> which will be much more helpful. The marshaled json for such error would be:
> {code:json}
> {"code":400,"message":"no such id"}
> {code}
> They are also much more expensive, so probably not suitable to replace the 
> current Stringer implementation, but when logging them, it's probably worth 
> it to implement slog.LogValuer so we can log something more useful, probably 
> like this:
> {code:go}
> func (p *Error) LogValue() slog.Value{
>   var sb strings.Builder
>   sb.WriteString("baseplate.Error")
>   bytes, err := json.Marshal(p)
>   if err != nil {
> // should not happen
> return slog.StringValue(fmt.Sprintf("baseplate.Error.LogValue: failed to 
> marshal json: %v", err))
>   }
>   sb.Write(bytes)
>   return slog.StringValue(sb.String())
> }
> {code}
> Which will make the error logged show as:
> {code:json}
> baseplate.Error{"code":400,"message":"no such id"}
> {code}
> Some open questions:
> # Is this also useful for structs?
> # Do we want to make this optional (e.g. only generate LogValue function when 
> a compiler flag is passed in)?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (THRIFT-5688) Publish python package to pypi for recent releases

2024-03-12 Thread Jens Geyer (Jira)



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

Jens Geyer resolved THRIFT-5688.

Fix Version/s: 0.20.0
   Resolution: Fixed

> Publish python package to pypi for recent releases
> --
>
> Key: THRIFT-5688
> URL: https://issues.apache.org/jira/browse/THRIFT-5688
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>Affects Versions: 0.17.0, 0.18.0, 0.18.1
>Reporter: Yuxuan Wang
>Assignee: Yuxuan Wang
>Priority: Major
> Fix For: 0.20.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Currently the latest version published to pypi is 0.16.0: 
> https://pypi.org/project/thrift/#history
> We probably should update the release runbook regarding this step, and also 
> publish 0.17.0, 0.18.0 and 0.18.1 to pypi.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Contribute to an issue - THRIFT-5688

2024-03-08 Thread Jens Geyer


Hi,

there is some undergoing work already, see pull requests at Github. I 
would recommend to chime in there and discuss your solution vis-á-vis 
what is WIP there.


Thanks!

Have fun,

JensG


Am 06.03.2024 um 23:06 schrieb Adheeth P Praveen:

Hello Jens,

I've been able to create a bash script that I'm willing to share that helps 
auto generate python package builds that we could push to PyPI!
It can be used across all the versions - present and past!

I believe what I've created is a simple, detailed and step by step script that 
anyone would be able to use to create the SRC package.
I'm also willing to help and guide with its usage.

Currently I cannot push to PyPI/Test PyPI - I'm assuming it's due to some sort 
of credentials/access rights issues but you possibly could.

My questions are as follows:
How do i go about submit a software packaging patch? Please guide me.
My basic understanding of PR is that I fork the Thrift project to my personal 
repo and submit the PR to the original project.
That works for code related changes but i am lost how to approach this for 
software packaging needs/issues.
Please help me.
Also, would this make/include me as a contributor to the project? Is that 
something i should manually do, or will it be done automatically


Regards,
bull500




From: Jens Geyer 
Sent: Saturday, January 13, 2024 4:40 PM
To: dev@thrift.apache.org 
Subject: Re: Contribute to an issue - THRIFT-5688

Hi,

yes I do have PyPi creds.

What would bve the optimum would be some sort of a step-by-step process
description that someone can follow, even with little to no clue about
Python and/or its packaging system.


We have a docuement which also has a small section abpout 3rd party
package managers at the very end. If its more than a few bullet points
consider putting it into some extra *.md and link to it from there.

https://github.com/apache/thrift/blob/master/doc/ReleaseManagement.md#third-party-package-managers


If you send a PR, the  I can test the process and we can work it out
together until we are all happy with it.


Have fun,

JensG






From: Adheeth P Praveen 
Sent: Sunday, December 17, 2023 4:57 PM
To: dev@thrift.apache.org 
Subject: Re: Contribute to an issue - THRIFT-5688

Hey Jens

Thank You for the reply and being positive!

I took a manual approaching to the packaging process initially.
I've used the source package available from 
http://archive.apache.org/dist/thrift/0.19.0/thrift-0.19.0.tar.gz and I've been 
able to generate a python package from it.
I've also done a local install on the built package and it worked without any 
issues.

For generating auto build there's a bit I need to learn and explore - mainly 
pipelines.

For uploading the package to the PyPi repo we'll need access to the repository 
and make use a utility called twine.
I believe you do have the credentials/access and you'll be able to do this 
process. If not, you'll have to add a maintainer.

How should i go about it from here?
Where should i share the built packages?
Do we need a GitHub issue on this? If Yes, any pointers on how to create one?

Regards,
bull500


From: Jens Geyer 
Sent: Thursday, November 30, 2023 7:28 PM
To: dev@thrift.apache.org 
Subject: Re: Contribute to an issue - THRIFT-5688

Hi Adheeth,

   > I'm not sure if this is the right place to ask this

Welcome! Yes, indeed it is.


but the JIRA and GitHub looked very specific to development purpose than 
discussions

Correct. General matters are to be discussed in these mailing lists.


   > I came across this issue and I wanted to contribute towards
addressing the problem.

As the ticket says, we currently have the funny situation that there is a  high 
demand for updated python packages but nobody that wants to do this or can 
spare the time. I myself do quite a number of packages myself but Thrift 
supports about 20+ target languages - most of which come with an associated 
library package. So any help on this is highly appreciated!

So where are we with that ticket and where do we want to go?

As shortly noted in the ticket, what we want is some step by step process that 
one can follow to publish the pypi package even though one never did that 
before nor has any intention to follow overly complex procedures (as these tend 
to break over time).

What we have already is an pull request with an updated pypi publishing 
procedere, but since I do not use Python myself I can't say much about the 
status of it.

https://github.com/apache/thrift/pull/2555

As a first milestone it would be perfect if we could publish the latest package 
in _some_ way (even manually) in order to satisfy the demand for it.

   > I'm new to packaging a project to pypi but i would like to help and
learn during the process.

Learning for sure is a by-product of working in the FOSS community.
Therefore, people around are usually keen to help on specific

[jira] [Resolved] (THRIFT-5765) Extra override for WriteBinary() to avoid unnecessary memory allocations when using COM types



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

Jens Geyer resolved THRIFT-5765.

Fix Version/s: 0.21.0
   Resolution: Fixed

> Extra override for WriteBinary() to avoid unnecessary memory allocations when 
> using COM types
> -
>
> Key: THRIFT-5765
> URL: https://issues.apache.org/jira/browse/THRIFT-5765
> Project: Thrift
>  Issue Type: Improvement
>  Components: Delphi - Library
>    Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Minor
> Fix For: 0.21.0
>
> Attachments: 
> 0001-THRIFT-5765-Extra-override-for-WriteBinary-to-avoid-.patch
>
>
> The IThriftBytes implementation allocates another TBytes array for the only 
> purpose to send the data down the tranport/protocol stack. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (THRIFT-5765) Extra override for WriteBinary() to avoid unnecessary memory allocations when using COM types



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

Jens Geyer updated THRIFT-5765:
---
Attachment: 0001-THRIFT-5765-Extra-override-for-WriteBinary-to-avoid-.patch

> Extra override for WriteBinary() to avoid unnecessary memory allocations when 
> using COM types
> -
>
> Key: THRIFT-5765
> URL: https://issues.apache.org/jira/browse/THRIFT-5765
> Project: Thrift
>  Issue Type: Improvement
>  Components: Delphi - Library
>    Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Minor
> Attachments: 
> 0001-THRIFT-5765-Extra-override-for-WriteBinary-to-avoid-.patch
>
>
> The IThriftBytes implementation allocates another TBytes array for the only 
> purpose to send the data down the tranport/protocol stack. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (THRIFT-5765) Extra override for WriteBinary() to avoid unnecessary memory allocations when using COM types



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

Jens Geyer updated THRIFT-5765:
---
Summary: Extra override for WriteBinary() to avoid unnecessary memory 
allocations when using COM types  (was: Extra override for WriteBinary() to 
avoid unnecessary memory allocations when using COM types.)

> Extra override for WriteBinary() to avoid unnecessary memory allocations when 
> using COM types
> -
>
> Key: THRIFT-5765
> URL: https://issues.apache.org/jira/browse/THRIFT-5765
> Project: Thrift
>  Issue Type: Improvement
>  Components: Delphi - Library
>    Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Minor
>
> The IThriftBytes implementation allocates another TBytes array for the only 
> purpose to send the data down the tranport/protocol stack. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (THRIFT-5765) Extra override for WriteBinary() to avoid unnecessary memory allocations when using COM types.



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

Jens Geyer updated THRIFT-5765:
---
Summary: Extra override for WriteBinary() to avoid unnecessary memory 
allocations when using COM types.  (was: Extra override for WriteBinary() to 
avoid unnecessary memory allocations when using COM types. )

> Extra override for WriteBinary() to avoid unnecessary memory allocations when 
> using COM types.
> --
>
> Key: THRIFT-5765
> URL: https://issues.apache.org/jira/browse/THRIFT-5765
> Project: Thrift
>  Issue Type: Improvement
>  Components: Delphi - Library
>    Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Minor
>
> The IThriftBytes implementation allocates another TBytes array for the only 
> purpose to send the data down the tranport/protocol stack. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (THRIFT-5765) Extra override for WriteBinary() to avoid unnecessary memory allocations when using COM types.



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

Jens Geyer reassigned THRIFT-5765:
--

Assignee: Jens Geyer

> Extra override for WriteBinary() to avoid unnecessary memory allocations when 
> using COM types. 
> ---
>
> Key: THRIFT-5765
> URL: https://issues.apache.org/jira/browse/THRIFT-5765
> Project: Thrift
>  Issue Type: Improvement
>    Reporter: Jens Geyer
>    Assignee: Jens Geyer
>Priority: Minor
>
> The IThriftBytes implementation allocates another TBytes array for the only 
> purpose to send the data down the tranport/protocol stack. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (THRIFT-5765) Extra override for WriteBinary() to avoid unnecessary memory allocations when using COM types.

Jens Geyer created THRIFT-5765:
--

 Summary: Extra override for WriteBinary() to avoid unnecessary 
memory allocations when using COM types. 
 Key: THRIFT-5765
 URL: https://issues.apache.org/jira/browse/THRIFT-5765
 Project: Thrift
  Issue Type: Improvement
Reporter: Jens Geyer


The IThriftBytes implementation allocates another TBytes array for the only 
purpose to send the data down the tranport/protocol stack. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (THRIFT-5765) Extra override for WriteBinary() to avoid unnecessary memory allocations when using COM types.



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

Jens Geyer updated THRIFT-5765:
---
Component/s: Delphi - Library

> Extra override for WriteBinary() to avoid unnecessary memory allocations when 
> using COM types. 
> ---
>
> Key: THRIFT-5765
> URL: https://issues.apache.org/jira/browse/THRIFT-5765
> Project: Thrift
>  Issue Type: Improvement
>  Components: Delphi - Library
>    Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Minor
>
> The IThriftBytes implementation allocates another TBytes array for the only 
> purpose to send the data down the tranport/protocol stack. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (THRIFT-5764) Extra CTOR for TThriftBytesImpl



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

Jens Geyer resolved THRIFT-5764.

Fix Version/s: 0.21.0
   Resolution: Fixed

> Extra CTOR for TThriftBytesImpl
> ---
>
> Key: THRIFT-5764
> URL: https://issues.apache.org/jira/browse/THRIFT-5764
> Project: Thrift
>  Issue Type: Improvement
>  Components: Delphi - Library
>    Reporter: Jens Geyer
>    Assignee: Jens Geyer
>Priority: Trivial
> Fix For: 0.21.0
>
> Attachments: 0001-THRIFT-5764-Extra-CTOR-for-TThriftBytesImpl.patch
>
>
> Currently TThriftBytesImpl only offers CTORs that accept TBytes.
> While this is a rather safe approach, in some use cases an extra "comfort" 
> CTOR that directly accepts pointer and size removes the need to write 
> potentially error prone code and/or the need for extra memory allocation.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (THRIFT-5764) Extra CTOR for TThriftBytesImpl



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

Jens Geyer updated THRIFT-5764:
---
Attachment: 0001-THRIFT-5764-Extra-CTOR-for-TThriftBytesImpl.patch

> Extra CTOR for TThriftBytesImpl
> ---
>
> Key: THRIFT-5764
> URL: https://issues.apache.org/jira/browse/THRIFT-5764
> Project: Thrift
>  Issue Type: Improvement
>  Components: Delphi - Library
>    Reporter: Jens Geyer
>    Assignee: Jens Geyer
>Priority: Trivial
> Attachments: 0001-THRIFT-5764-Extra-CTOR-for-TThriftBytesImpl.patch
>
>
> Currently TThriftBytesImpl only offers CTORs that accept TBytes.
> While this is a rather safe approach, in some use cases an extra "comfort" 
> CTOR that directly accepts pointer and size removes the need to write 
> potentially error prone code and/or the need for extra memory allocation.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (THRIFT-5764) Extra CTOR for TThriftBytesImpl

Jens Geyer created THRIFT-5764:
--

 Summary: Extra CTOR for TThriftBytesImpl
 Key: THRIFT-5764
 URL: https://issues.apache.org/jira/browse/THRIFT-5764
 Project: Thrift
  Issue Type: Improvement
  Components: Delphi - Library
Reporter: Jens Geyer
Assignee: Jens Geyer


Currently TThriftBytesImpl only offers CTORs that accept TBytes.

While this is a rather safe approach, in some use cases an extra "comfort" CTOR 
that directly accepts pointer and size removes the need to write potentially 
error prone code and/or the need for extra memory allocation.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (THRIFT-5762) Expose service result objects in Java

2024-03-05 Thread Jens Geyer (Jira)



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

Jens Geyer updated THRIFT-5762:
---
Component/s: Java - Compiler

> Expose service result objects in Java
> -
>
> Key: THRIFT-5762
> URL: https://issues.apache.org/jira/browse/THRIFT-5762
> Project: Thrift
>  Issue Type: New Feature
>  Components: Java - Compiler
>Reporter: Thomas Bruggink
>Assignee: Thomas Bruggink
>Priority: Major
> Fix For: 0.21.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Some libraries want to bypass the TServer class and handle the full
> service startup manually. For example when building a service that hosts
> multiple thrift services where the IFace type is unknown when handling a
> request.
> For example when you host multiple services on top of netty and through
> an HTTP path you want to route to the correct thrift service. In this
> situation you treat can treat an IFace as an Object and use the
> `getProcessMapView()` method to parse a byte array into a thrift message
> and pass let the `AsyncProcessFunction` handle the invocation.
> To return a correct thrift response it's necessary to write the
> `{service_name}_result` that contains the response args.
> While it is possible to get an incoming args object from the
> (Async)ProcessFunction its unfortunately not possible to get
> a result object without using reflection.
> This PR extends the (Async)ProcessFunction by adding a
> `getEmptyResultInstance` method that returns a new generic `A` (answer)
> that matches the `{service_name}_result` object.
> This allows thrift users to write the following processing code:
> {code:java}
>  void handleRequest(
> TProtocol in,
> TProtocol out,
> TBaseAsyncProcessor processor,
> I asyncIface
> ) throws TException {
> final Map, TBase, 
> TBase>> processMap = (Map) processor.getProcessMapView();
> final var msg = in.readMessageBegin();
> final var fn = processMap.get(msg.name);
> final var args = fn.getEmptyArgsInstance();
> args.read(in);
> in.readMessageEnd();
> if (fn.isOneway()) {
> return;
> }
> fn.start(asyncIface, args, new AsyncMethodCallback<>() {
> @Override
> public void onComplete(TBase o) {
> try {
> out.writeMessageBegin(new TMessage(fn.getMethodName(), 
> TMessageType.REPLY, msg.getSeqid()));
> final var response_result = fn.getEmptyResultInstance();
> final var success_field = 
> response_result.fieldForId(SUCCESS_ID);
> ((TBase) response_result).setFieldValue(success_field, o);
> response_result.write(out);
> out.writeMessageEnd();
> out.getTransport().flush();
> } catch (TException e) {
> throw new RuntimeException(e);
> }
> }
> @Override
> public void onError(Exception e) {
> try {
> out.writeMessageBegin(new TMessage(fn.getMethodName(), 
> TMessageType.EXCEPTION, msg.getSeqid()));
> ((TApplicationException) e).write(out);
> out.writeMessageEnd();
> out.getTransport().flush();
> } catch (TException ex) {
> throw new RuntimeException(ex);
> }
> }
> });
> }
> {code}
> The above example code doesn't need any reference to the original types
> and can dynamically create the correct objects to return a correct
> response.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (THRIFT-5762) Expose service result objects in Java

2024-03-05 Thread Jens Geyer (Jira)



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

Jens Geyer resolved THRIFT-5762.

Fix Version/s: 0.21.0
 Assignee: Thomas Bruggink
   Resolution: Fixed

> Expose service result objects in Java
> -
>
> Key: THRIFT-5762
> URL: https://issues.apache.org/jira/browse/THRIFT-5762
> Project: Thrift
>  Issue Type: New Feature
>Reporter: Thomas Bruggink
>Assignee: Thomas Bruggink
>Priority: Major
> Fix For: 0.21.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Some libraries want to bypass the TServer class and handle the full
> service startup manually. For example when building a service that hosts
> multiple thrift services where the IFace type is unknown when handling a
> request.
> For example when you host multiple services on top of netty and through
> an HTTP path you want to route to the correct thrift service. In this
> situation you treat can treat an IFace as an Object and use the
> `getProcessMapView()` method to parse a byte array into a thrift message
> and pass let the `AsyncProcessFunction` handle the invocation.
> To return a correct thrift response it's necessary to write the
> `{service_name}_result` that contains the response args.
> While it is possible to get an incoming args object from the
> (Async)ProcessFunction its unfortunately not possible to get
> a result object without using reflection.
> This PR extends the (Async)ProcessFunction by adding a
> `getEmptyResultInstance` method that returns a new generic `A` (answer)
> that matches the `{service_name}_result` object.
> This allows thrift users to write the following processing code:
> {code:java}
>  void handleRequest(
> TProtocol in,
> TProtocol out,
> TBaseAsyncProcessor processor,
> I asyncIface
> ) throws TException {
> final Map, TBase, 
> TBase>> processMap = (Map) processor.getProcessMapView();
> final var msg = in.readMessageBegin();
> final var fn = processMap.get(msg.name);
> final var args = fn.getEmptyArgsInstance();
> args.read(in);
> in.readMessageEnd();
> if (fn.isOneway()) {
> return;
> }
> fn.start(asyncIface, args, new AsyncMethodCallback<>() {
> @Override
> public void onComplete(TBase o) {
> try {
> out.writeMessageBegin(new TMessage(fn.getMethodName(), 
> TMessageType.REPLY, msg.getSeqid()));
> final var response_result = fn.getEmptyResultInstance();
> final var success_field = 
> response_result.fieldForId(SUCCESS_ID);
> ((TBase) response_result).setFieldValue(success_field, o);
> response_result.write(out);
> out.writeMessageEnd();
> out.getTransport().flush();
> } catch (TException e) {
> throw new RuntimeException(e);
> }
> }
> @Override
> public void onError(Exception e) {
> try {
> out.writeMessageBegin(new TMessage(fn.getMethodName(), 
> TMessageType.EXCEPTION, msg.getSeqid()));
> ((TApplicationException) e).write(out);
> out.writeMessageEnd();
> out.getTransport().flush();
> } catch (TException ex) {
> throw new RuntimeException(ex);
> }
> }
> });
> }
> {code}
> The above example code doesn't need any reference to the original types
> and can dynamically create the correct objects to return a correct
> response.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

What about 0.20.0?

2024-03-02 Thread Jens Geyer


@all,

I'm not quite sure about what the status is here. Any idea when are we 
considering ourselves ready? Would be nice to know before I start again 
with RC-1


Thanks,

JensG

[jira] [Resolved] (THRIFT-5757) Unit tests for php lib



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

Jens Geyer resolved THRIFT-5757.

Fix Version/s: 0.21.0
   Resolution: Fixed

> Unit tests for php lib
> --
>
> Key: THRIFT-5757
> URL: https://issues.apache.org/jira/browse/THRIFT-5757
> Project: Thrift
>  Issue Type: New Feature
>  Components: PHP - Library
>Reporter: Volodymyr Panivko
>Assignee: Volodymyr Panivko
>Priority: Major
> Fix For: 0.21.0
>
> Attachments: image-2024-02-24-10-41-37-836.png
>
>  Time Spent: 3h 20m
>  Remaining Estimate: 0h
>
> After running PHP unit tests for each pull request THRIFT-5756
> Next step is writing test for php lib.
> It will be several pull request for this task.  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (THRIFT-5761) Lib/json tests fail



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

Jens Geyer resolved THRIFT-5761.

Fix Version/s: 0.21.0
   Resolution: Fixed

> Lib/json tests fail
> ---
>
> Key: THRIFT-5761
> URL: https://issues.apache.org/jira/browse/THRIFT-5761
> Project: Thrift
>  Issue Type: Bug
>  Components: JSON - Library
>Reporter: Thomas Bruggink
>Assignee: Thomas Bruggink
>Priority: Minor
> Fix For: 0.21.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Running `ant validate-generated-json` fails with the following error:
> {code:java}
> validate-generated-json:
>  [java] --- BEGIN 
> /thrift/src/lib/json/test/build/gen-json/ThriftTest.json---
>  [java] validation: FAILURE
>  [java] [ {
>  [java]   "level" : "error",
>  [java]   "schema" : {
>  [java] "loadingURI" : "file:/thrift/src/lib/json/schema.json#",
>  [java] "pointer" : "/definitions/constant"
>  [java]   },
>  [java]   "instance" : {
>  [java] "pointer" : "/constants/0"
>  [java]   },
>  [java]   "domain" : "validation",
>  [java]   "keyword" : "allOf",
>  [java]   "message" : "instance failed to match all required schemas 
> (matched only 2 out of 3)",
>  [java]   "matched" : 2,
>  [java]   "nrSchemas" : 3,
>  [java]   "reports" : {
>  [java] "/definitions/constant/allOf/0" : [ ],
>  [java] "/definitions/constant/allOf/1" : [ {
>  [java]   "level" : "error",
>  [java]   "schema" : {
>  [java] "loadingURI" : "file:/thrift/src/lib/json/schema.json#",
>  [java] "pointer" : "/definitions/type-desc"
>  [java]   },
>  [java]   "instance" : {
>  [java] "pointer" : "/constants/0"
>  [java]   },
>  [java]   "domain" : "validation",
>  [java]   "keyword" : "allOf",
>  [java]   "message" : "instance failed to match all required schemas 
> (matched only 1 out of 2)",
>  [java]   "matched" : 1,
>  [java]   "nrSchemas" : 2,
>  [java]   "reports" : {
>  [java] "/definitions/type-desc/allOf/0" : [ ],
>  [java] "/definitions/type-desc/allOf/1" : [ {
>  [java]   "level" : "error",
>  [java]   "schema" : {
>  [java] "loadingURI" : 
> "file:/thrift/src/lib/json/schema.json#",
>  [java] "pointer" : "/definitions/type-desc/allOf/1"
>  [java]   },
>  [java]   "instance" : {
>  [java] "pointer" : "/constants/0"
>  [java]   },
>  [java]   "domain" : "validation",
>  [java]   "keyword" : "oneOf",
>  [java]   "message" : "instance failed to match exactly one 
> schema (matched 0 out of 4)",
>  [java]   "matched" : 0,
>  [java]   "nrSchemas" : 4,
>  [java]   "reports" : {
>  [java] "/definitions/type-desc/allOf/1/oneOf/0" : [ {
>  [java]   "level" : "error",
>  [java]   "schema" : {
>  [java] "loadingURI" : 
> "file:/thrift/src/lib/json/schema.json#",
>  [java] "pointer" : 
> "/definitions/base-type/properties/typeId"
>  [java]   },
>  [java]   "instance" : {
>  [java] "pointer" : "/constants/0/typeId"
>  [java]   },
>  [java]   "domain" : "validation",
>  [java]   "keyword" : "enum",
>  [java]   "message" : "instance value (\"enum\") not found in 
> enum (possible values: 
> [\"void\",\"string\",\"bool\",\"byte\",\"i8\",\"i16\",\"

[jira] [Updated] (THRIFT-5761) Lib/json tests fail



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

Jens Geyer updated THRIFT-5761:
---
Component/s: JSON - Library

> Lib/json tests fail
> ---
>
> Key: THRIFT-5761
> URL: https://issues.apache.org/jira/browse/THRIFT-5761
> Project: Thrift
>  Issue Type: Bug
>  Components: JSON - Library
>Reporter: Thomas Bruggink
>Assignee: Thomas Bruggink
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Running `ant validate-generated-json` fails with the following error:
> {code:java}
> validate-generated-json:
>  [java] --- BEGIN 
> /thrift/src/lib/json/test/build/gen-json/ThriftTest.json---
>  [java] validation: FAILURE
>  [java] [ {
>  [java]   "level" : "error",
>  [java]   "schema" : {
>  [java] "loadingURI" : "file:/thrift/src/lib/json/schema.json#",
>  [java] "pointer" : "/definitions/constant"
>  [java]   },
>  [java]   "instance" : {
>  [java] "pointer" : "/constants/0"
>  [java]   },
>  [java]   "domain" : "validation",
>  [java]   "keyword" : "allOf",
>  [java]   "message" : "instance failed to match all required schemas 
> (matched only 2 out of 3)",
>  [java]   "matched" : 2,
>  [java]   "nrSchemas" : 3,
>  [java]   "reports" : {
>  [java] "/definitions/constant/allOf/0" : [ ],
>  [java] "/definitions/constant/allOf/1" : [ {
>  [java]   "level" : "error",
>  [java]   "schema" : {
>  [java] "loadingURI" : "file:/thrift/src/lib/json/schema.json#",
>  [java] "pointer" : "/definitions/type-desc"
>  [java]   },
>  [java]   "instance" : {
>  [java] "pointer" : "/constants/0"
>  [java]   },
>  [java]   "domain" : "validation",
>  [java]   "keyword" : "allOf",
>  [java]   "message" : "instance failed to match all required schemas 
> (matched only 1 out of 2)",
>  [java]   "matched" : 1,
>  [java]   "nrSchemas" : 2,
>  [java]   "reports" : {
>  [java] "/definitions/type-desc/allOf/0" : [ ],
>  [java] "/definitions/type-desc/allOf/1" : [ {
>  [java]   "level" : "error",
>  [java]   "schema" : {
>  [java] "loadingURI" : 
> "file:/thrift/src/lib/json/schema.json#",
>  [java] "pointer" : "/definitions/type-desc/allOf/1"
>  [java]   },
>  [java]   "instance" : {
>  [java] "pointer" : "/constants/0"
>  [java]   },
>  [java]   "domain" : "validation",
>  [java]   "keyword" : "oneOf",
>  [java]   "message" : "instance failed to match exactly one 
> schema (matched 0 out of 4)",
>  [java]   "matched" : 0,
>  [java]   "nrSchemas" : 4,
>  [java]   "reports" : {
>  [java] "/definitions/type-desc/allOf/1/oneOf/0" : [ {
>  [java]   "level" : "error",
>  [java]   "schema" : {
>  [java] "loadingURI" : 
> "file:/thrift/src/lib/json/schema.json#",
>  [java] "pointer" : 
> "/definitions/base-type/properties/typeId"
>  [java]   },
>  [java]   "instance" : {
>  [java] "pointer" : "/constants/0/typeId"
>  [java]   },
>  [java]   "domain" : "validation",
>  [java]   "keyword" : "enum",
>  [java]   "message" : "instance value (\"enum\") not found in 
> enum (possible values: 
> [\"void\",\"string\",\"bool\",\"byte\",\"i8\",\"i16\",\"i32\",\"i64\",\"double\",\&

[jira] [Assigned] (THRIFT-5761) Lib/json tests fail



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

Jens Geyer reassigned THRIFT-5761:
--

Assignee: Thomas Bruggink

> Lib/json tests fail
> ---
>
> Key: THRIFT-5761
> URL: https://issues.apache.org/jira/browse/THRIFT-5761
> Project: Thrift
>  Issue Type: Bug
>Reporter: Thomas Bruggink
>Assignee: Thomas Bruggink
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Running `ant validate-generated-json` fails with the following error:
> {code:java}
> validate-generated-json:
>  [java] --- BEGIN 
> /thrift/src/lib/json/test/build/gen-json/ThriftTest.json---
>  [java] validation: FAILURE
>  [java] [ {
>  [java]   "level" : "error",
>  [java]   "schema" : {
>  [java] "loadingURI" : "file:/thrift/src/lib/json/schema.json#",
>  [java] "pointer" : "/definitions/constant"
>  [java]   },
>  [java]   "instance" : {
>  [java] "pointer" : "/constants/0"
>  [java]   },
>  [java]   "domain" : "validation",
>  [java]   "keyword" : "allOf",
>  [java]   "message" : "instance failed to match all required schemas 
> (matched only 2 out of 3)",
>  [java]   "matched" : 2,
>  [java]   "nrSchemas" : 3,
>  [java]   "reports" : {
>  [java] "/definitions/constant/allOf/0" : [ ],
>  [java] "/definitions/constant/allOf/1" : [ {
>  [java]   "level" : "error",
>  [java]   "schema" : {
>  [java] "loadingURI" : "file:/thrift/src/lib/json/schema.json#",
>  [java] "pointer" : "/definitions/type-desc"
>  [java]   },
>  [java]   "instance" : {
>  [java] "pointer" : "/constants/0"
>  [java]   },
>  [java]   "domain" : "validation",
>  [java]   "keyword" : "allOf",
>  [java]   "message" : "instance failed to match all required schemas 
> (matched only 1 out of 2)",
>  [java]   "matched" : 1,
>  [java]   "nrSchemas" : 2,
>  [java]   "reports" : {
>  [java] "/definitions/type-desc/allOf/0" : [ ],
>  [java] "/definitions/type-desc/allOf/1" : [ {
>  [java]   "level" : "error",
>  [java]   "schema" : {
>  [java] "loadingURI" : 
> "file:/thrift/src/lib/json/schema.json#",
>  [java] "pointer" : "/definitions/type-desc/allOf/1"
>  [java]   },
>  [java]   "instance" : {
>  [java] "pointer" : "/constants/0"
>  [java]   },
>  [java]   "domain" : "validation",
>  [java]   "keyword" : "oneOf",
>  [java]   "message" : "instance failed to match exactly one 
> schema (matched 0 out of 4)",
>  [java]   "matched" : 0,
>  [java]   "nrSchemas" : 4,
>  [java]   "reports" : {
>  [java] "/definitions/type-desc/allOf/1/oneOf/0" : [ {
>  [java]   "level" : "error",
>  [java]   "schema" : {
>  [java] "loadingURI" : 
> "file:/thrift/src/lib/json/schema.json#",
>  [java] "pointer" : 
> "/definitions/base-type/properties/typeId"
>  [java]   },
>  [java]   "instance" : {
>  [java] "pointer" : "/constants/0/typeId"
>  [java]   },
>  [java]   "domain" : "validation",
>  [java]   "keyword" : "enum",
>  [java]   "message" : "instance value (\"enum\") not found in 
> enum (possible values: 
> [\"void\",\"string\",\"bool\",\"byte\",\"i8\",\"i16\",\"i32\",\"i64\",\"double\",\"binary\",\"

[jira] [Resolved] (THRIFT-5758) PHP 8.2 Deprecate dynamic properties



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

Jens Geyer resolved THRIFT-5758.

Fix Version/s: 0.21.0
   Resolution: Fixed

> PHP 8.2 Deprecate dynamic properties
> 
>
> Key: THRIFT-5758
> URL: https://issues.apache.org/jira/browse/THRIFT-5758
> Project: Thrift
>  Issue Type: New Feature
>  Components: PHP - Library
>Reporter: Volodymyr Panivko
>Assignee: Volodymyr Panivko
>Priority: Major
> Fix For: 0.21.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> In php 8.2 dynamic properties will generate a deprecation
> [https://www.php.net/releases/8.2/en.php#deprecate_dynamic_properties]
>  
> In Tbase and TException dynamic properties is used.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (THRIFT-5760) Update minimal version of php



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

Jens Geyer resolved THRIFT-5760.

Fix Version/s: 0.21.0
   Resolution: Fixed

> Update minimal version of php
> -
>
> Key: THRIFT-5760
> URL: https://issues.apache.org/jira/browse/THRIFT-5760
> Project: Thrift
>  Issue Type: Improvement
>  Components: PHP - Library
>Reporter: Volodymyr Panivko
>Assignee: Volodymyr Panivko
>Priority: Major
>  Labels: breaking_change
> Fix For: 0.21.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Update minimal version of php to 7.1
> I know that currently 8.* is main version, but current code has to much 
> dependencies on version 5, so let's move step by step.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-5755) Docker image build fail



[ 
https://issues.apache.org/jira/browse/THRIFT-5755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820301#comment-17820301
 ] 

Jens Geyer commented on THRIFT-5755:


I'm not aware of anything in old being used. Why the heck do we have a folder 
named "old" at all?

{quote}what about the original problem, i cannot build container due to the 
error, who can help with it?{quote}
Have a look at the ReleaseMgmt doc I linked. there is a command line that also 
has a volume reference.  Did you try that?

{code}
$ docker run -v $(pwd):/thrift/src:rw -it thrift/thrift-build:ubuntu-bionic 
/bin/bash
root@8b4101188aa2:/thrift/src# ./bootstrap.sh && ./configure && make dist
{code}


> Docker image build fail
> ---
>
> Key: THRIFT-5755
> URL: https://issues.apache.org/jira/browse/THRIFT-5755
> Project: Thrift
>  Issue Type: Bug
> Environment: Ubuntu 22.04
>Reporter: Volodymyr Panivko
>Priority: Major
>
> When I'm trying to build an docker image and run command
> {code:java}
> docker build -t thrift build/docker/ubuntu-bionic{code}
> I get such error
>  
> {code:java}
>  
>  => ERROR [13/35] RUN apt-get install -y --no-install-recommends       `# 
> dotnet core dependencies`       dotnet-sdk-8.0       dotnet-runtime-8.0       
> aspnetcore-runtime-8.0       dotnet-apphost-pack-8.0           1.3s
> --
>  > [13/35] RUN apt-get install -y --no-install-recommends       `# dotnet 
> core dependencies`       dotnet-sdk-8.0       dotnet-runtime-8.0       
> aspnetcore-runtime-8.0       dotnet-apphost-pack-8.0:
> 0.350 Reading package lists...
> 1.113 Building dependency tree...
> 1.216 Reading state information...
> 1.311 E: Unable to locate package dotnet-sdk-8.0
> 1.311 E: Couldn't find any package by glob 'dotnet-sdk-8.0'
> 1.311 E: Couldn't find any package by regex 'dotnet-sdk-8.0'
> 1.311 E: Unable to locate package dotnet-runtime-8.0
> 1.311 E: Couldn't find any package by glob 'dotnet-runtime-8.0'
> 1.311 E: Couldn't find any package by regex 'dotnet-runtime-8.0'
> 1.311 E: Unable to locate package aspnetcore-runtime-8.0
> 1.311 E: Couldn't find any package by glob 'aspnetcore-runtime-8.0'
> 1.311 E: Couldn't find any package by regex 'aspnetcore-runtime-8.0'
> 1.311 E: Unable to locate package dotnet-apphost-pack-8.0
> 1.311 E: Couldn't find any package by glob 'dotnet-apphost-pack-8.0'
> 1.311 E: Couldn't find any package by regex 'dotnet-apphost-pack-8.0'
> --
> Dockerfile:134
> 
>  133 |     
>  134 | >>> RUN apt-get install -y --no-install-recommends \
>  135 | >>>       `# dotnet core dependencies` \
>  136 | >>>       dotnet-sdk-8.0 \
>  137 | >>>       dotnet-runtime-8.0 \
>  138 | >>>       aspnetcore-runtime-8.0 \
>  139 | >>>       dotnet-apphost-pack-8.0
>  140 |     
> 
> ERROR: failed to solve: process "/bin/sh -c apt-get install -y 
> --no-install-recommends       `# dotnet core dependencies`       
> dotnet-sdk-8.0       dotnet-runtime-8.0       aspnetcore-runtime-8.0       
> dotnet-apphost-pack-8.0" did not complete successfully: exit code: 100
> {code}
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (THRIFT-5757) Unit tests for php lib



[ 
https://issues.apache.org/jira/browse/THRIFT-5757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820300#comment-17820300
 ] 

Jens Geyer edited comment on THRIFT-5757 at 2/24/24 9:55 AM:
-

{quote}I'm subscribed, and already write a letter the list, but i does not 
appear in it.{quote}

 

Could you try to contact INFRA about this? 


was (Author: jensg):
??I'm subscribed, and already write a letter the list, but i does not appear in 
it.\{quote}??

 

Could you try to contact INFRA about this? 

> Unit tests for php lib
> --
>
> Key: THRIFT-5757
> URL: https://issues.apache.org/jira/browse/THRIFT-5757
> Project: Thrift
>  Issue Type: New Feature
>  Components: PHP - Library
>Reporter: Volodymyr Panivko
>Assignee: Volodymyr Panivko
>Priority: Major
> Attachments: image-2024-02-24-10-41-37-836.png
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> After running PHP unit tests for each pull request THRIFT-5756
> Next step is writing test for php lib.
> It will be several pull request for this task.  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (THRIFT-5757) Unit tests for php lib



[ 
https://issues.apache.org/jira/browse/THRIFT-5757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820300#comment-17820300
 ] 

Jens Geyer edited comment on THRIFT-5757 at 2/24/24 9:54 AM:
-

??I'm subscribed, and already write a letter the list, but i does not appear in 
it.\{quote}??

 

Could you try to contact INFRA about this? 


was (Author: jensg):
{quote}I'm subscribed, and already write a letter the list, but i does not 
appear in it.\{quote}

Could you try to contact INFRA about this? 

> Unit tests for php lib
> --
>
> Key: THRIFT-5757
> URL: https://issues.apache.org/jira/browse/THRIFT-5757
> Project: Thrift
>  Issue Type: New Feature
>  Components: PHP - Library
>Reporter: Volodymyr Panivko
>Assignee: Volodymyr Panivko
>Priority: Major
> Attachments: image-2024-02-24-10-41-37-836.png
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> After running PHP unit tests for each pull request THRIFT-5756
> Next step is writing test for php lib.
> It will be several pull request for this task.  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-5757) Unit tests for php lib



[ 
https://issues.apache.org/jira/browse/THRIFT-5757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820300#comment-17820300
 ] 

Jens Geyer commented on THRIFT-5757:


{quote}I'm subscribed, and already write a letter the list, but i does not 
appear in it.\{quote}

Could you try to contact INFRA about this? 

> Unit tests for php lib
> --
>
> Key: THRIFT-5757
> URL: https://issues.apache.org/jira/browse/THRIFT-5757
> Project: Thrift
>  Issue Type: New Feature
>  Components: PHP - Library
>Reporter: Volodymyr Panivko
>Assignee: Volodymyr Panivko
>Priority: Major
> Attachments: image-2024-02-24-10-41-37-836.png
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> After running PHP unit tests for each pull request THRIFT-5756
> Next step is writing test for php lib.
> It will be several pull request for this task.  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-5757) Unit tests for php lib



[ 
https://issues.apache.org/jira/browse/THRIFT-5757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820299#comment-17820299
 ] 

Jens Geyer commented on THRIFT-5757:


Whatever makes most sense,

> Unit tests for php lib
> --
>
> Key: THRIFT-5757
> URL: https://issues.apache.org/jira/browse/THRIFT-5757
> Project: Thrift
>  Issue Type: New Feature
>  Components: PHP - Library
>Reporter: Volodymyr Panivko
>Assignee: Volodymyr Panivko
>Priority: Major
> Attachments: image-2024-02-24-10-41-37-836.png
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> After running PHP unit tests for each pull request THRIFT-5756
> Next step is writing test for php lib.
> It will be several pull request for this task.  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (THRIFT-5757) Unit tests for php lib



[ 
https://issues.apache.org/jira/browse/THRIFT-5757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820296#comment-17820296
 ] 

Jens Geyer edited comment on THRIFT-5757 at 2/24/24 9:51 AM:
-

{quote}PHP Lib in Thrift project currently supports many PHP versions, which is 
EOL, it gives many troubles, because in the new PHP version many changes are 
provided and many old possibilities become deprecated.
{quote}
If it is EOL and makes problems why don't we drop support for it from current 
development branch?

EDIT: Just found this [https://www.php.net/supported-versions.php]
The 7 version is not even listed there ... however if it is still widely used 
and does not cause too many additional troubles to support, why not? I'm fine 
with it.

I just would recommend to check the efforts needed and if it gets too clumsy 
and troublesome to maintain any outdated version I personally would decide to 
cut it off and go with what is officially supported at the moment. 

Just to make an example: When net6 (LTS) [gets EOL in 
October|https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core] 
this year, net6 and net7 support will be the next thing I throw out.


was (Author: jensg):
{quote}
PHP Lib in Thrift project currently supports many PHP versions, which is EOL, 
it gives many troubles, because in the new PHP version many changes are 
provided and many old possibilities become deprecated. 
{quote}

If it is EOL and makes problems why don't we drop support for it from current 
development branch?

> Unit tests for php lib
> --
>
> Key: THRIFT-5757
> URL: https://issues.apache.org/jira/browse/THRIFT-5757
> Project: Thrift
>  Issue Type: New Feature
>  Components: PHP - Library
>Reporter: Volodymyr Panivko
>Assignee: Volodymyr Panivko
>Priority: Major
> Attachments: image-2024-02-24-10-41-37-836.png
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> After running PHP unit tests for each pull request THRIFT-5756
> Next step is writing test for php lib.
> It will be several pull request for this task.  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-5757) Unit tests for php lib



[ 
https://issues.apache.org/jira/browse/THRIFT-5757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820296#comment-17820296
 ] 

Jens Geyer commented on THRIFT-5757:


{quote}
PHP Lib in Thrift project currently supports many PHP versions, which is EOL, 
it gives many troubles, because in the new PHP version many changes are 
provided and many old possibilities become deprecated. 
{quote}

If it is EOL and makes problems why don't we drop support for it from current 
development branch?

> Unit tests for php lib
> --
>
> Key: THRIFT-5757
> URL: https://issues.apache.org/jira/browse/THRIFT-5757
> Project: Thrift
>  Issue Type: New Feature
>  Components: PHP - Library
>Reporter: Volodymyr Panivko
>Assignee: Volodymyr Panivko
>Priority: Major
> Attachments: image-2024-02-24-10-41-37-836.png
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> After running PHP unit tests for each pull request THRIFT-5756
> Next step is writing test for php lib.
> It will be several pull request for this task.  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (THRIFT-5757) Unit tests for php lib



[ 
https://issues.apache.org/jira/browse/THRIFT-5757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820295#comment-17820295
 ] 

Jens Geyer edited comment on THRIFT-5757 at 2/24/24 9:40 AM:
-

You have no rights to write to dev list? How can that happen? Its a public 
mailing list.

Maybe you need to subscribe first (I'm not 100% sure about that)
https://thrift.apache.org/mailing


was (Author: jensg):
You have no rights to write to dev list? How can that happen? Its a public 
mailing list.

> Unit tests for php lib
> --
>
> Key: THRIFT-5757
> URL: https://issues.apache.org/jira/browse/THRIFT-5757
> Project: Thrift
>  Issue Type: New Feature
>  Components: PHP - Library
>Reporter: Volodymyr Panivko
>Assignee: Volodymyr Panivko
>Priority: Major
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> After running PHP unit tests for each pull request THRIFT-5756
> Next step is writing test for php lib.
> It will be several pull request for this task.  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-5757) Unit tests for php lib



[ 
https://issues.apache.org/jira/browse/THRIFT-5757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820295#comment-17820295
 ] 

Jens Geyer commented on THRIFT-5757:


You have no rights to write to dev list? How can that happen? Its a public 
mailing list.

> Unit tests for php lib
> --
>
> Key: THRIFT-5757
> URL: https://issues.apache.org/jira/browse/THRIFT-5757
> Project: Thrift
>  Issue Type: New Feature
>  Components: PHP - Library
>Reporter: Volodymyr Panivko
>Assignee: Volodymyr Panivko
>Priority: Major
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> After running PHP unit tests for each pull request THRIFT-5756
> Next step is writing test for php lib.
> It will be several pull request for this task.  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (THRIFT-5756) Run php tests in github actions

2024-02-21 Thread Jens Geyer (Jira)



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

Jens Geyer resolved THRIFT-5756.

Fix Version/s: 0.21.0
   Resolution: Fixed

> Run php tests in github actions
> ---
>
> Key: THRIFT-5756
> URL: https://issues.apache.org/jira/browse/THRIFT-5756
> Project: Thrift
>  Issue Type: New Feature
>  Components: PHP - Library
>Reporter: Volodymyr Panivko
>Assignee: Volodymyr Panivko
>Priority: Major
> Fix For: 0.21.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Before updating minimum version of php to 7.4 or 8.0 we should start running 
> php tests on every pull request.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (THRIFT-5755) Docker image build fail

2024-02-19 Thread Jens Geyer (Jira)



[ 
https://issues.apache.org/jira/browse/THRIFT-5755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17818578#comment-17818578
 ] 

Jens Geyer edited comment on THRIFT-5755 at 2/19/24 9:23 PM:
-

{quote}The Dockerfiles under build/docker are no longer used and maintained, we 
probably should remove them from the repository.\{quote}

The images are used in the release process. Although they were actually built a 
while ago, removing them may cause more problems in the future.
 * [https://hub.docker.com/r/thrift/thrift-build/tags]
 * [https://github.com/apache/thrift/blob/master/doc/ReleaseManagement.md]

 


was (Author: jensg):
The images are used in the release process. Although they were actually built a 
while ago, removing them may cause more problems in the future.


 * [https://hub.docker.com/r/thrift/thrift-build/tags]
 * [https://github.com/apache/thrift/blob/master/doc/ReleaseManagement.md]

 

> Docker image build fail
> ---
>
> Key: THRIFT-5755
> URL: https://issues.apache.org/jira/browse/THRIFT-5755
> Project: Thrift
>  Issue Type: Bug
> Environment: Ubuntu 22.04
>Reporter: Volodymyr Panivko
>Priority: Major
>
> When I'm trying to build an docker image and run command
> {code:java}
> docker build -t thrift build/docker/ubuntu-bionic{code}
> I get such error
>  
> {code:java}
>  
>  => ERROR [13/35] RUN apt-get install -y --no-install-recommends       `# 
> dotnet core dependencies`       dotnet-sdk-8.0       dotnet-runtime-8.0       
> aspnetcore-runtime-8.0       dotnet-apphost-pack-8.0           1.3s
> --
>  > [13/35] RUN apt-get install -y --no-install-recommends       `# dotnet 
> core dependencies`       dotnet-sdk-8.0       dotnet-runtime-8.0       
> aspnetcore-runtime-8.0       dotnet-apphost-pack-8.0:
> 0.350 Reading package lists...
> 1.113 Building dependency tree...
> 1.216 Reading state information...
> 1.311 E: Unable to locate package dotnet-sdk-8.0
> 1.311 E: Couldn't find any package by glob 'dotnet-sdk-8.0'
> 1.311 E: Couldn't find any package by regex 'dotnet-sdk-8.0'
> 1.311 E: Unable to locate package dotnet-runtime-8.0
> 1.311 E: Couldn't find any package by glob 'dotnet-runtime-8.0'
> 1.311 E: Couldn't find any package by regex 'dotnet-runtime-8.0'
> 1.311 E: Unable to locate package aspnetcore-runtime-8.0
> 1.311 E: Couldn't find any package by glob 'aspnetcore-runtime-8.0'
> 1.311 E: Couldn't find any package by regex 'aspnetcore-runtime-8.0'
> 1.311 E: Unable to locate package dotnet-apphost-pack-8.0
> 1.311 E: Couldn't find any package by glob 'dotnet-apphost-pack-8.0'
> 1.311 E: Couldn't find any package by regex 'dotnet-apphost-pack-8.0'
> --
> Dockerfile:134
> 
>  133 |     
>  134 | >>> RUN apt-get install -y --no-install-recommends \
>  135 | >>>       `# dotnet core dependencies` \
>  136 | >>>       dotnet-sdk-8.0 \
>  137 | >>>       dotnet-runtime-8.0 \
>  138 | >>>       aspnetcore-runtime-8.0 \
>  139 | >>>       dotnet-apphost-pack-8.0
>  140 |     
> 
> ERROR: failed to solve: process "/bin/sh -c apt-get install -y 
> --no-install-recommends       `# dotnet core dependencies`       
> dotnet-sdk-8.0       dotnet-runtime-8.0       aspnetcore-runtime-8.0       
> dotnet-apphost-pack-8.0" did not complete successfully: exit code: 100
> {code}
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (THRIFT-5755) Docker image build fail

2024-02-19 Thread Jens Geyer (Jira)



[ 
https://issues.apache.org/jira/browse/THRIFT-5755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17818578#comment-17818578
 ] 

Jens Geyer edited comment on THRIFT-5755 at 2/19/24 9:23 PM:
-

{quote}The Dockerfiles under build/docker are no longer used and maintained, we 
probably should remove them from the repository.\{quote}
{quote}
 

The images are used in the release process. Although they were actually built a 
while ago, removing them may cause more problems in the future.
 * [https://hub.docker.com/r/thrift/thrift-build/tags]
 * [https://github.com/apache/thrift/blob/master/doc/ReleaseManagement.md]

 


was (Author: jensg):
{quote}The Dockerfiles under build/docker are no longer used and maintained, we 
probably should remove them from the repository.\{quote}

The images are used in the release process. Although they were actually built a 
while ago, removing them may cause more problems in the future.
 * [https://hub.docker.com/r/thrift/thrift-build/tags]
 * [https://github.com/apache/thrift/blob/master/doc/ReleaseManagement.md]

 

> Docker image build fail
> ---
>
> Key: THRIFT-5755
> URL: https://issues.apache.org/jira/browse/THRIFT-5755
> Project: Thrift
>  Issue Type: Bug
> Environment: Ubuntu 22.04
>Reporter: Volodymyr Panivko
>Priority: Major
>
> When I'm trying to build an docker image and run command
> {code:java}
> docker build -t thrift build/docker/ubuntu-bionic{code}
> I get such error
>  
> {code:java}
>  
>  => ERROR [13/35] RUN apt-get install -y --no-install-recommends       `# 
> dotnet core dependencies`       dotnet-sdk-8.0       dotnet-runtime-8.0       
> aspnetcore-runtime-8.0       dotnet-apphost-pack-8.0           1.3s
> --
>  > [13/35] RUN apt-get install -y --no-install-recommends       `# dotnet 
> core dependencies`       dotnet-sdk-8.0       dotnet-runtime-8.0       
> aspnetcore-runtime-8.0       dotnet-apphost-pack-8.0:
> 0.350 Reading package lists...
> 1.113 Building dependency tree...
> 1.216 Reading state information...
> 1.311 E: Unable to locate package dotnet-sdk-8.0
> 1.311 E: Couldn't find any package by glob 'dotnet-sdk-8.0'
> 1.311 E: Couldn't find any package by regex 'dotnet-sdk-8.0'
> 1.311 E: Unable to locate package dotnet-runtime-8.0
> 1.311 E: Couldn't find any package by glob 'dotnet-runtime-8.0'
> 1.311 E: Couldn't find any package by regex 'dotnet-runtime-8.0'
> 1.311 E: Unable to locate package aspnetcore-runtime-8.0
> 1.311 E: Couldn't find any package by glob 'aspnetcore-runtime-8.0'
> 1.311 E: Couldn't find any package by regex 'aspnetcore-runtime-8.0'
> 1.311 E: Unable to locate package dotnet-apphost-pack-8.0
> 1.311 E: Couldn't find any package by glob 'dotnet-apphost-pack-8.0'
> 1.311 E: Couldn't find any package by regex 'dotnet-apphost-pack-8.0'
> --
> Dockerfile:134
> 
>  133 |     
>  134 | >>> RUN apt-get install -y --no-install-recommends \
>  135 | >>>       `# dotnet core dependencies` \
>  136 | >>>       dotnet-sdk-8.0 \
>  137 | >>>       dotnet-runtime-8.0 \
>  138 | >>>       aspnetcore-runtime-8.0 \
>  139 | >>>       dotnet-apphost-pack-8.0
>  140 |     
> 
> ERROR: failed to solve: process "/bin/sh -c apt-get install -y 
> --no-install-recommends       `# dotnet core dependencies`       
> dotnet-sdk-8.0       dotnet-runtime-8.0       aspnetcore-runtime-8.0       
> dotnet-apphost-pack-8.0" did not complete successfully: exit code: 100
> {code}
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-5755) Docker image build fail

2024-02-19 Thread Jens Geyer (Jira)



[ 
https://issues.apache.org/jira/browse/THRIFT-5755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17818578#comment-17818578
 ] 

Jens Geyer commented on THRIFT-5755:


The images are used in the release process. Although they were actually built a 
while ago, removing them may cause more problems in the future.


 * [https://hub.docker.com/r/thrift/thrift-build/tags]
 * [https://github.com/apache/thrift/blob/master/doc/ReleaseManagement.md]

 

> Docker image build fail
> ---
>
> Key: THRIFT-5755
> URL: https://issues.apache.org/jira/browse/THRIFT-5755
> Project: Thrift
>  Issue Type: Bug
> Environment: Ubuntu 22.04
>Reporter: Volodymyr Panivko
>Priority: Major
>
> When I'm trying to build an docker image and run command
> {code:java}
> docker build -t thrift build/docker/ubuntu-bionic{code}
> I get such error
>  
> {code:java}
>  
>  => ERROR [13/35] RUN apt-get install -y --no-install-recommends       `# 
> dotnet core dependencies`       dotnet-sdk-8.0       dotnet-runtime-8.0       
> aspnetcore-runtime-8.0       dotnet-apphost-pack-8.0           1.3s
> --
>  > [13/35] RUN apt-get install -y --no-install-recommends       `# dotnet 
> core dependencies`       dotnet-sdk-8.0       dotnet-runtime-8.0       
> aspnetcore-runtime-8.0       dotnet-apphost-pack-8.0:
> 0.350 Reading package lists...
> 1.113 Building dependency tree...
> 1.216 Reading state information...
> 1.311 E: Unable to locate package dotnet-sdk-8.0
> 1.311 E: Couldn't find any package by glob 'dotnet-sdk-8.0'
> 1.311 E: Couldn't find any package by regex 'dotnet-sdk-8.0'
> 1.311 E: Unable to locate package dotnet-runtime-8.0
> 1.311 E: Couldn't find any package by glob 'dotnet-runtime-8.0'
> 1.311 E: Couldn't find any package by regex 'dotnet-runtime-8.0'
> 1.311 E: Unable to locate package aspnetcore-runtime-8.0
> 1.311 E: Couldn't find any package by glob 'aspnetcore-runtime-8.0'
> 1.311 E: Couldn't find any package by regex 'aspnetcore-runtime-8.0'
> 1.311 E: Unable to locate package dotnet-apphost-pack-8.0
> 1.311 E: Couldn't find any package by glob 'dotnet-apphost-pack-8.0'
> 1.311 E: Couldn't find any package by regex 'dotnet-apphost-pack-8.0'
> --
> Dockerfile:134
> 
>  133 |     
>  134 | >>> RUN apt-get install -y --no-install-recommends \
>  135 | >>>       `# dotnet core dependencies` \
>  136 | >>>       dotnet-sdk-8.0 \
>  137 | >>>       dotnet-runtime-8.0 \
>  138 | >>>       aspnetcore-runtime-8.0 \
>  139 | >>>       dotnet-apphost-pack-8.0
>  140 |     
> 
> ERROR: failed to solve: process "/bin/sh -c apt-get install -y 
> --no-install-recommends       `# dotnet core dependencies`       
> dotnet-sdk-8.0       dotnet-runtime-8.0       aspnetcore-runtime-8.0       
> dotnet-apphost-pack-8.0" did not complete successfully: exit code: 100
> {code}
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-5688) Publish python package to pypi for recent releases

2024-02-12 Thread Jens Geyer (Jira)



[ 
https://issues.apache.org/jira/browse/THRIFT-5688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816790#comment-17816790
 ] 

Jens Geyer commented on THRIFT-5688:


No need to argue with me, since I do not make the rules, I only point out they 
exist, in order to make everybody around aware of it.

Somewhere in that document there is also some details about what a release is 
and how to make test packages available (and what to avoid). 

I personally would agree with TestPyPi being perfect for any kind of unapproved 
builds.

> Publish python package to pypi for recent releases
> --
>
> Key: THRIFT-5688
> URL: https://issues.apache.org/jira/browse/THRIFT-5688
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>Affects Versions: 0.17.0, 0.18.0, 0.18.1
>Reporter: Yuxuan Wang
>Assignee: Yuxuan Wang
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Currently the latest version published to pypi is 0.16.0: 
> https://pypi.org/project/thrift/#history
> We probably should update the release runbook regarding this step, and also 
> publish 0.17.0, 0.18.0 and 0.18.1 to pypi.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[RESULT][VOTE] Apache Thrift 0.20.0-rc0 release candidate

2024-02-11 Thread Jens Geyer


Hi all,

We have one +1 and one -1 vote.

The vote for the Apache Thrift 0.20.0 release candidate 0 is NOT successful.

Thank you to all who helped test and verify.

Voting Thread:
https://lists.apache.org/thread/gt1xhdlqqh3r51q1olp6tksvks746oh5

Summary:
+1: Jens Geyer
-1: Yuxuan Wang

Have fun,
JensG



Am 04.02.2024 um 15:54 schrieb Jens Geyer:

All,

I propose that we accept the following release candidate as the official 
Apache Thrift 0.20.0 release:


https://dist.apache.org/repos/dist/dev/thrift/0.20.0-rc0/thrift-0.20.0.tar.gz

The release candidate was created from the release/0.20.0 branch and can 
be cloned using:


git clone -b release/0.20.0 https://github.com/apache/thrift.git

The release candidates GPG signature can be found at:
https://dist.apache.org/repos/dist/dev/thrift/0.20.0-rc0/thrift-0.20.0.tar.gz.asc

The release candidates checksums are:
md5: 4f18ac2105791269e6f877da0090248d
sha1: f5fcd41700680d7d6a755aba7a34a482ea21a455
sha256: fca0ae48a127659eaa5ee1c642c08d96dc4f6667a8514702c29f79bb4c8488f3



A prebuilt statically-linked Windows compiler is available at:
https://dist.apache.org/repos/dist/dev/thrift/0.20.0-rc0/thrift-0.20.0.exe

Prebuilt statically-linked Windows compiler GPG signature:
https://dist.apache.org/repos/dist/dev/thrift/0.20.0-rc0/thrift-0.20.0.exe.asc

Prebuilt statically-linked Windows compiler checksums are:
md5: 9e2dc5749602803ebbb9cb68f90ac8ef
sha1: 194bf921d0de78ffa5de47b18ddd00a9a8bffb03
sha256: 79ba296e83bc348ab09419d601f027e3219c2d61f32da97f26d3b684b69dd2fe


The CHANGES list for this release is available at:
https://github.com/apache/thrift/blob/0.20.0/CHANGES.md


Please download, verify sig/sum, install and test the libraries and 
languages of your choice.



I start this voting thread with my own +1 vote.


This vote will close in 129 hours on 2024-02-10 00:00 UTC
https://www.timeanddate.com/countdown/generic?iso=20240210T=1440

[ ] +1 Release this as Apache Thrift 0.20.0
[ ] +0
[ ] -1 Do not release this as Apache Thrift 0.20.0 because...

Have fun,
JensG




OpenPGP_0x76BD340FC4B75865.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[jira] [Comment Edited] (THRIFT-5688) Publish python package to pypi for recent releases

2024-02-11 Thread Jens Geyer (Jira)



[ 
https://issues.apache.org/jira/browse/THRIFT-5688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816396#comment-17816396
 ] 

Jens Geyer edited comment on THRIFT-5688 at 2/11/24 11:55 AM:
--

> thrift-test 0.21.0

To prevent conflicts I want to emphasize this

[https://www.apache.org/legal/release-policy.html#policy] 


was (Author: jensg):
> thrift-test 0.21.0

Top prevent conflicts I want to emphasize this

[https://www.apache.org/legal/release-policy.html#policy] 

> Publish python package to pypi for recent releases
> --
>
> Key: THRIFT-5688
> URL: https://issues.apache.org/jira/browse/THRIFT-5688
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>Affects Versions: 0.17.0, 0.18.0, 0.18.1
>Reporter: Yuxuan Wang
>Assignee: Yuxuan Wang
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Currently the latest version published to pypi is 0.16.0: 
> https://pypi.org/project/thrift/#history
> We probably should update the release runbook regarding this step, and also 
> publish 0.17.0, 0.18.0 and 0.18.1 to pypi.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-5688) Publish python package to pypi for recent releases

2024-02-11 Thread Jens Geyer (Jira)



[ 
https://issues.apache.org/jira/browse/THRIFT-5688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816396#comment-17816396
 ] 

Jens Geyer commented on THRIFT-5688:


> thrift-test 0.21.0

Top prevent conflicts I want to emphasize this

[https://www.apache.org/legal/release-policy.html#policy] 

> Publish python package to pypi for recent releases
> --
>
> Key: THRIFT-5688
> URL: https://issues.apache.org/jira/browse/THRIFT-5688
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>Affects Versions: 0.17.0, 0.18.0, 0.18.1
>Reporter: Yuxuan Wang
>Assignee: Yuxuan Wang
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Currently the latest version published to pypi is 0.16.0: 
> https://pypi.org/project/thrift/#history
> We probably should update the release runbook regarding this step, and also 
> publish 0.17.0, 0.18.0 and 0.18.1 to pypi.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: PyPi again

2024-02-11 Thread Jens Geyer


Hi,

Did that last week or so.

Have fun,

JensG



Am 06.02.2024 um 23:28 schrieb Yuxuan Wang:

Hi Jens, can you also add me to the test pypi project:
https://test.pypi.org/project/thrift/? My username is
https://test.pypi.org/user/fishy/

With how pypi works, I will need to test it on test pypi first before doing
it for the real pypi.

On Fri, Jan 19, 2024 at 2:21 PM Jens Geyer  wrote:


Hi,

  > The image is:

I see. Not sure if I can do this, since I have no access to project
settings. Maybe INFRA can.

Have fun,

JensG



Am 18.01.2024 um 23:58 schrieb Yuxuan Wang:

My pypi account is fishy:

https://protect.checkpoint.com/v2/___https://pypi.org/user/fishy/___.YzJ1OnJlZGRpdDpjOmc6MDg0MmRmZjE0YjI0MDBkNWY4YTk5ZDM2MjAzMDExY2E6NjpkZGNjOjM3OWQyYjk2NDgzZjk0MWVhZDdiMmMwMDY1MDA5ZTQzZDM5YWJiNDk4NjVjMWJjZThjY2FiMjE1YzA0ZWM4NmQ6cDpU

The image is:

https://protect.checkpoint.com/v2/___https://imgur.com/a/vkehdiF___.YzJ1OnJlZGRpdDpjOmc6MDg0MmRmZjE0YjI0MDBkNWY4YTk5ZDM2MjAzMDExY2E6NjpkMTcxOjJlNjRkOTc3NTQ1NDAzNTU5YmQ4MmQ4NzliYzU4YWQyOWFiMGRiNzc4ZTE0YTNjNWQ4YzlkOWFmZjRkNjczNWY6cDpU

On Thu, Jan 18, 2024 at 2:49 PM Jens Geyer

wrote:

Hi,


I can't see the picture and I don't have your pypi username. I tried the
email but that did not work.


Have fun,

jensG


Am 17.01.2024 um 02:11 schrieb Yuxuan Wang:

I just logged into my pypi account (I was there to register an
account, and it turns out I already have one, which I have no memory
of, and I do not have any projects published there), it seems that
they actually have an automated way to create the github actions for
you automatically:

https://protect.checkpoint.com/v2/___https://docs.pypi.org/trusted-publishers/___.YzJ1OnJlZGRpdDpjOmc6OGFlODQ5M2ZiYWZjYTc2OTg1MWFlOWVlN2Y1NGI3YzI6NjoxYjIzOjE1MTU3M2QyZTExNGEzOTE5NjIxYjUzYjgyNDBhNzMxODQzN2U1ZWNmMGQ1MzMzM2EwMTY3NGFlNzk1MDA0YTI6cDpU

But I would assume that might require that I have admin access to the
github repo (not sure yet, as I don't have any other project to test),
so if you are fine with that (e.g. add me to the PyPi maintainer list,
I try to use that approach, if it doesn't work, give me admin access
to the github repo), I'm fine :)

Also, there's a recent pytorch supply chain attach report
<

https://protect.checkpoint.com/v2/___https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/___.YzJ1OnJlZGRpdDpjOmc6OGFlODQ5M2ZiYWZjYTc2OTg1MWFlOWVlN2Y1NGI3YzI6NjphNDlkOjFkYmFiNzllNjc5NzIxNWQwMjFiZWFhY2JkZjYxNGQ3NTM2OTFlMmUzOTJkYWUyMjkxMTNlYTZmMzllYjNkMDU6cDpU

which will be relevant to us if we choose to use github actions to
auto publish to pypi, then we probably should follow their suggested
mitigation
<

https://protect.checkpoint.com/v2/___https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/%23mitigations___.YzJ1OnJlZGRpdDpjOmc6OGFlODQ5M2ZiYWZjYTc2OTg1MWFlOWVlN2Y1NGI3YzI6NjpjNDZkOjhlZjYzM2ZkOGEzNjMyNDk1OTk1OGE2MjBhZWIyNDUzMmU2Mzg4NjYzMDBkODJkNTUxYmViY2JkY2E2MDE1NjU6cDpU

,

which is to change to "Require approval for all outside collaborators":
image.png
(changing this setting on github also requires admin access, the
screenshot is taken from a repo I have admin access on)

On Sat, Jan 13, 2024 at 3:13 AM Jens Geyer

wrote:

  I can probably add you to the PyPi maintainer list. Would that

help?


  Am 12.01.2024 um 23:19 schrieb Yuxuan Wang:
  > IMHO there are two issues with the pypi publishing problem:
  technical and
  > non-technical.
  >
  > The non-technical issue is the credential/secret required to
  publish to
  >


https://protect.checkpoint.com/v2/___https://pypi.org/project/thrift/___.YzJ1OnJlZGRpdDpjOmc6MThmM2FhOGE3MzlkYjk0ZGEzNzQwM2ZmMDhlNzUwZjg6Njo2MTllOjY0ZTYwOWM0ZmJkYjhjNGU3NjZlYTVjY2YyMmZhNDEwZTZiOGU0ZTUyNjNlZTdmOWEzNTg0YzcxYzhkMGVjMzU6cDpU

.

  Any of the technical solution also
  > depends on that being available.
  >
  > Once we have it (in github actions secret store, for example),

then

  > technical solution is not the hard part. As I mentioned in the
  jira thread
  > Reddit already has a github action pipeline to publish to pypi
  on git tag
  > we can upstream to thrift project to be used (so whenever a
  maintainer
  > pushes a tag to github, github actions auto publishes to pypi).
  Or others
  > can contribute other solutions.
  >
  > On Sat, Jan 6, 2024 at 3:18 AM Jens Geyer

wrote:

  >
  >> @all,
  >>
  >> I just want to bring up that topic again. There is a rather
  frequent
  >> stream of (absolutely legitimate) questions regarding the PyPi
  packages
  >> not being published.
  >>
  >> So it seems fair to say that there is obviously a certain
  demand within
  >> the community, which is supe

[VOTE] Apache Thrift 0.20.0-rc0 release candidate

2024-02-04 Thread Jens Geyer


All,

I propose that we accept the following release candidate as the official 
Apache Thrift 0.20.0 release:


https://dist.apache.org/repos/dist/dev/thrift/0.20.0-rc0/thrift-0.20.0.tar.gz

The release candidate was created from the release/0.20.0 branch and can 
be cloned using:


git clone -b release/0.20.0 https://github.com/apache/thrift.git

The release candidates GPG signature can be found at:
https://dist.apache.org/repos/dist/dev/thrift/0.20.0-rc0/thrift-0.20.0.tar.gz.asc

The release candidates checksums are:
md5: 4f18ac2105791269e6f877da0090248d
sha1: f5fcd41700680d7d6a755aba7a34a482ea21a455
sha256: fca0ae48a127659eaa5ee1c642c08d96dc4f6667a8514702c29f79bb4c8488f3



A prebuilt statically-linked Windows compiler is available at:
https://dist.apache.org/repos/dist/dev/thrift/0.20.0-rc0/thrift-0.20.0.exe

Prebuilt statically-linked Windows compiler GPG signature:
https://dist.apache.org/repos/dist/dev/thrift/0.20.0-rc0/thrift-0.20.0.exe.asc

Prebuilt statically-linked Windows compiler checksums are:
md5: 9e2dc5749602803ebbb9cb68f90ac8ef
sha1: 194bf921d0de78ffa5de47b18ddd00a9a8bffb03
sha256: 79ba296e83bc348ab09419d601f027e3219c2d61f32da97f26d3b684b69dd2fe


The CHANGES list for this release is available at:
https://github.com/apache/thrift/blob/0.20.0/CHANGES.md


Please download, verify sig/sum, install and test the libraries and 
languages of your choice.



I start this voting thread with my own +1 vote.


This vote will close in 129 hours on 2024-02-10 00:00 UTC
https://www.timeanddate.com/countdown/generic?iso=20240210T=1440

[ ] +1 Release this as Apache Thrift 0.20.0
[ ] +0
[ ] -1 Do not release this as Apache Thrift 0.20.0 because...

Have fun,
JensG




OpenPGP_0x76BD340FC4B75865.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[jira] [Updated] (THRIFT-5736) Support Http2 for thrift lib java

2024-02-04 Thread Jens Geyer (Jira)



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

Jens Geyer updated THRIFT-5736:
---
Component/s: Java - Library

> Support Http2 for thrift lib java
> -
>
> Key: THRIFT-5736
> URL: https://issues.apache.org/jira/browse/THRIFT-5736
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Library
>Reporter: nicole Wang
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> add new Transport to support http2 for thrift lib java



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-5712) Add Dart 3 compatibility

2024-01-28 Thread Jens Geyer (Jira)



[ 
https://issues.apache.org/jira/browse/THRIFT-5712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17811673#comment-17811673
 ] 

Jens Geyer commented on THRIFT-5712:


{quote}

Add an __isset struct like in the cpp generator but it will only contain 
required fields.

{quote}

__isset is usually used for *optional* or *default* requiredness only. 

Required fields do not need an __isset, because they {*}must be set by 
definition{*}. 

 

> Add Dart 3 compatibility
> 
>
> Key: THRIFT-5712
> URL: https://issues.apache.org/jira/browse/THRIFT-5712
> Project: Thrift
>  Issue Type: Improvement
>  Components: Dart - Compiler
>Affects Versions: 0.18.1
>Reporter: Vlad Koronnov
>Priority: Major
>
> Dart project generated by thrift has constraints in pubspec.yaml
>  
> {code:java}
> name: dart_client
> version: 0.0.1
> description: Autogenerated by Thrift Compiler
> environment:
>   sdk: '>=2.12.0 <3.0.0' {code}
>  
>  
> And generated code uses uninitialized variables, which can't be used with 
> sound null safety, required by Dart 3.0



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-5750) deprecate "ansistr_binary_" option

2024-01-21 Thread Jens Geyer (Jira)



[ 
https://issues.apache.org/jira/browse/THRIFT-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809285#comment-17809285
 ] 

Jens Geyer commented on THRIFT-5750:


Deprecation notice via commit 
[7d4c7fa|https://github.com/apache/thrift/commit/7d4c7fa69b8a8fcb6d013141edeaae85182a28d7]

> deprecate "ansistr_binary_" option
> --
>
> Key: THRIFT-5750
> URL: https://issues.apache.org/jira/browse/THRIFT-5750
> Project: Thrift
>  Issue Type: Improvement
>  Components: Delphi - Compiler
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> That option was introduced earlier for some rather exotic use case which a) 
> is not really relevant anymore and b) should not be part of a general library 
> anymore.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (THRIFT-5750) Remove "ansistr_binary_" option

2024-01-21 Thread Jens Geyer (Jira)



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

Jens Geyer updated THRIFT-5750:
---
Summary: Remove "ansistr_binary_" option  (was: deprecate "ansistr_binary_" 
option)

> Remove "ansistr_binary_" option
> ---
>
> Key: THRIFT-5750
> URL: https://issues.apache.org/jira/browse/THRIFT-5750
> Project: Thrift
>  Issue Type: Improvement
>  Components: Delphi - Compiler
>        Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> That option was introduced earlier for some rather exotic use case which a) 
> is not really relevant anymore and b) should not be part of a general library 
> anymore.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: PyPi again

2024-01-19 Thread Jens Geyer


Hi,

> The image is:

I see. Not sure if I can do this, since I have no access to project 
settings. Maybe INFRA can.


Have fun,

JensG



Am 18.01.2024 um 23:58 schrieb Yuxuan Wang:

My pypi account is fishy:https://pypi.org/user/fishy/

The image is:https://imgur.com/a/vkehdiF

On Thu, Jan 18, 2024 at 2:49 PM Jens Geyer  wrote:


Hi,


I can't see the picture and I don't have your pypi username. I tried the
email but that did not work.


Have fun,

jensG


Am 17.01.2024 um 02:11 schrieb Yuxuan Wang:

I just logged into my pypi account (I was there to register an
account, and it turns out I already have one, which I have no memory
of, and I do not have any projects published there), it seems that
they actually have an automated way to create the github actions for
you automatically:

https://protect.checkpoint.com/v2/___https://docs.pypi.org/trusted-publishers/___.YzJ1OnJlZGRpdDpjOmc6OGFlODQ5M2ZiYWZjYTc2OTg1MWFlOWVlN2Y1NGI3YzI6NjoxYjIzOjE1MTU3M2QyZTExNGEzOTE5NjIxYjUzYjgyNDBhNzMxODQzN2U1ZWNmMGQ1MzMzM2EwMTY3NGFlNzk1MDA0YTI6cDpU

But I would assume that might require that I have admin access to the
github repo (not sure yet, as I don't have any other project to test),
so if you are fine with that (e.g. add me to the PyPi maintainer list,
I try to use that approach, if it doesn't work, give me admin access
to the github repo), I'm fine :)

Also, there's a recent pytorch supply chain attach report
<

https://protect.checkpoint.com/v2/___https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/___.YzJ1OnJlZGRpdDpjOmc6OGFlODQ5M2ZiYWZjYTc2OTg1MWFlOWVlN2Y1NGI3YzI6NjphNDlkOjFkYmFiNzllNjc5NzIxNWQwMjFiZWFhY2JkZjYxNGQ3NTM2OTFlMmUzOTJkYWUyMjkxMTNlYTZmMzllYjNkMDU6cDpU>


which will be relevant to us if we choose to use github actions to
auto publish to pypi, then we probably should follow their suggested
mitigation
<

https://protect.checkpoint.com/v2/___https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/%23mitigations___.YzJ1OnJlZGRpdDpjOmc6OGFlODQ5M2ZiYWZjYTc2OTg1MWFlOWVlN2Y1NGI3YzI6NjpjNDZkOjhlZjYzM2ZkOGEzNjMyNDk1OTk1OGE2MjBhZWIyNDUzMmU2Mzg4NjYzMDBkODJkNTUxYmViY2JkY2E2MDE1NjU6cDpU>,


which is to change to "Require approval for all outside collaborators":
image.png
(changing this setting on github also requires admin access, the
screenshot is taken from a repo I have admin access on)

On Sat, Jan 13, 2024 at 3:13 AM Jens Geyer

wrote:


 I can probably add you to the PyPi maintainer list. Would that help?


 Am 12.01.2024 um 23:19 schrieb Yuxuan Wang:
 > IMHO there are two issues with the pypi publishing problem:
 technical and
 > non-technical.
 >
 > The non-technical issue is the credential/secret required to
 publish to
 >


https://protect.checkpoint.com/v2/___https://pypi.org/project/thrift/___.YzJ1OnJlZGRpdDpjOmc6MThmM2FhOGE3MzlkYjk0ZGEzNzQwM2ZmMDhlNzUwZjg6Njo2MTllOjY0ZTYwOWM0ZmJkYjhjNGU3NjZlYTVjY2YyMmZhNDEwZTZiOGU0ZTUyNjNlZTdmOWEzNTg0YzcxYzhkMGVjMzU6cDpU
.

 Any of the technical solution also
 > depends on that being available.
 >
 > Once we have it (in github actions secret store, for example), then
 > technical solution is not the hard part. As I mentioned in the
 jira thread
 > Reddit already has a github action pipeline to publish to pypi
 on git tag
 > we can upstream to thrift project to be used (so whenever a
 maintainer
 > pushes a tag to github, github actions auto publishes to pypi).
 Or others
 > can contribute other solutions.
 >
 > On Sat, Jan 6, 2024 at 3:18 AM Jens Geyer

wrote:

 >
 >> @all,
 >>
 >> I just want to bring up that topic again. There is a rather
 frequent
 >> stream of (absolutely legitimate) questions regarding the PyPi
 packages
 >> not being published.
 >>
 >> So it seems fair to say that there is obviously a certain
 demand within
 >> the community, which is super great. Now on the other hand we
 have no
 >> noteworthy reactions from that very same community to help with
 that topic.
 >>
 >> Let me put it bluntly. This is not your mothers supermarked
 where stock
 >> refills almost like automagically overnight. This is open
 source. It
 >> works as long as there are at least some people spending parts
 of their
 >> valuable time supporting projects. It is about giving & taking.
 >>
 >> Thrift supports about 20+ target languages. So it is fair to
 say that
 >> supporting packages for all of them (where approprate) is quite
 a bit of
 >> work.
 >>
 >> Of course I can only speak for myself, but I personally
 maintain quite a
 >> n

[jira] [Resolved] (THRIFT-5753) PHP 8.1 deprecated warning about return type in jsonSerialize functions

2024-01-19 Thread Jens Geyer (Jira)



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

Jens Geyer resolved THRIFT-5753.

Fix Version/s: 0.20.0
 Assignee: Pavel Kvach
   Resolution: Fixed

> PHP 8.1 deprecated warning about return type in jsonSerialize functions
> ---
>
> Key: THRIFT-5753
> URL: https://issues.apache.org/jira/browse/THRIFT-5753
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Library
>Reporter: Pavel Kvach
>Assignee: Pavel Kvach
>Priority: Minor
> Fix For: 0.20.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> In PHP 8.1 a "mixed" return type was added to the 
> "JsonSerializable::jsonSerialize()" method.
> This triggers a deprecation warning for generated PHP classes:
> {code:java}
> Return type of TestClass::jsonSerialize() should either be compatible with 
> JsonSerializable::jsonSerialize(): mixed, or the #[\ReturnTypeWillChange] 
> attribute should be used to temporarily suppress the notice in ...{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: PyPi again

2024-01-18 Thread Jens Geyer


Hi,


I can't see the picture and I don't have your pypi username. I tried the 
email but that did not work.



Have fun,

jensG


Am 17.01.2024 um 02:11 schrieb Yuxuan Wang:
I just logged into my pypi account (I was there to register an 
account, and it turns out I already have one, which I have no memory 
of, and I do not have any projects published there), it seems that 
they actually have an automated way to create the github actions for 
you automatically: https://docs.pypi.org/trusted-publishers/


But I would assume that might require that I have admin access to the 
github repo (not sure yet, as I don't have any other project to test), 
so if you are fine with that (e.g. add me to the PyPi maintainer list, 
I try to use that approach, if it doesn't work, give me admin access 
to the github repo), I'm fine :)


Also, there's a recent pytorch supply chain attach report 
<https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/> 
which will be relevant to us if we choose to use github actions to 
auto publish to pypi, then we probably should follow their suggested 
mitigation 
<https://johnstawinski.com/2024/01/11/playing-with-fire-how-we-executed-a-critical-supply-chain-attack-on-pytorch/#mitigations>, 
which is to change to "Require approval for all outside collaborators":

image.png
(changing this setting on github also requires admin access, the 
screenshot is taken from a repo I have admin access on)


On Sat, Jan 13, 2024 at 3:13 AM Jens Geyer  wrote:


I can probably add you to the PyPi maintainer list. Would that help?


Am 12.01.2024 um 23:19 schrieb Yuxuan Wang:
> IMHO there are two issues with the pypi publishing problem:
technical and
> non-technical.
>
> The non-technical issue is the credential/secret required to
publish to
>

https://protect.checkpoint.com/v2/___https://pypi.org/project/thrift/___.YzJ1OnJlZGRpdDpjOmc6MThmM2FhOGE3MzlkYjk0ZGEzNzQwM2ZmMDhlNzUwZjg6Njo2MTllOjY0ZTYwOWM0ZmJkYjhjNGU3NjZlYTVjY2YyMmZhNDEwZTZiOGU0ZTUyNjNlZTdmOWEzNTg0YzcxYzhkMGVjMzU6cDpU.
Any of the technical solution also
> depends on that being available.
>
> Once we have it (in github actions secret store, for example), then
> technical solution is not the hard part. As I mentioned in the
jira thread
> Reddit already has a github action pipeline to publish to pypi
on git tag
> we can upstream to thrift project to be used (so whenever a
maintainer
> pushes a tag to github, github actions auto publishes to pypi).
Or others
> can contribute other solutions.
>
> On Sat, Jan 6, 2024 at 3:18 AM Jens Geyer  wrote:
>
>> @all,
>>
>> I just want to bring up that topic again. There is a rather
frequent
>> stream of (absolutely legitimate) questions regarding the PyPi
packages
>> not being published.
>>
>> So it seems fair to say that there is obviously a certain
demand within
>> the community, which is super great. Now on the other hand we
have no
>> noteworthy reactions from that very same community to help with
that topic.
>>
>> Let me put it bluntly. This is not your mothers supermarked
where stock
>> refills almost like automagically overnight. This is open
source. It
>> works as long as there are at least some people spending parts
of their
>> valuable time supporting projects. It is about giving & taking.
>>
>> Thrift supports about 20+ target languages. So it is fair to
say that
>> supporting packages for all of them (where approprate) is quite
a bit of
>> work.
>>
>> Of course I can only speak for myself, but I personally
maintain quite a
>> number of packages after each release. Thanks to the great work
of other
>> people (e.g. @JimKing) who spent their time on that topic
before me,
>> this became manageable by setting up and documenting a well-defined
>> process to follow which also does not eat too much additional
release time.
>>
>> If we can have such a process for PyPi that would be super awesome.
>> Right now this is not the case, unfortunately. This is where
you could
>> chime in.
>>
>> See also
>>

https://protect.checkpoint.com/v2/___https://github.com/apache/thrift/pull/2555___.YzJ1OnJlZGRpdDpjOmc6ZGEyMWNiMjExZDEwMWVjZmIzNGI3MWIzMGFmMmEyZTY6Njo0ZDRjOmIyMTFmOWI4ODI2ZTJmZTIxMTQ0NmNhMmQ4M2I5M2EzNDBhY2VhOTVlOGE2YzVjZDgyNWZlMGVmZmZhMThhOWU6cDpU
>>
>> Happy New Year everybody,
>> JensG
>>
>>
>>

[jira] [Resolved] (THRIFT-5754) Fix PHP 8.1 deprecates passing null to non-nullable internal function parameters

2024-01-18 Thread Jens Geyer (Jira)



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

Jens Geyer resolved THRIFT-5754.

Fix Version/s: 0.20.0
 Assignee: Pavel Kvach
   Resolution: Fixed

> Fix PHP 8.1 deprecates passing null to non-nullable internal function 
> parameters
> 
>
> Key: THRIFT-5754
> URL: https://issues.apache.org/jira/browse/THRIFT-5754
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Library
>Reporter: Pavel Kvach
>Assignee: Pavel Kvach
>Priority: Minor
> Fix For: 0.20.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> PHP 8.1 has deprecated passing null values to non-nullable internal function 
> parameters:
> [https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg]
> This can lead to deprecation warnings and potential errors in future versions.
> Example of a deprecation warning:
> {code:java}
> PHP Deprecated: strlen(): Passing null to parameter #1 ($string) of type 
> string is deprecated in Thrift/StringFunc/Core.php on line 38 {code}
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: PyPi again

2024-01-13 Thread Jens Geyer

I can probably add you to the PyPi maintainer list. Would that help?

Am 12.01.2024 um 23:19 schrieb Yuxuan Wang:

IMHO there are two issues with the pypi publishing problem: technical and
non-technical.

The non-technical issue is the credential/secret required to publish to
https://pypi.org/project/thrift/. Any of the technical solution also
depends on that being available.

Once we have it (in github actions secret store, for example), then
technical solution is not the hard part. As I mentioned in the jira thread
Reddit already has a github action pipeline to publish to pypi on git tag
we can upstream to thrift project to be used (so whenever a maintainer
pushes a tag to github, github actions auto publishes to pypi). Or others
can contribute other solutions.

On Sat, Jan 6, 2024 at 3:18 AM Jens Geyer wrote:

@all,

I just want to bring up that topic again. There is a rather frequent
stream of (absolutely legitimate) questions regarding the PyPi packages
not being published.

So it seems fair to say that there is obviously a certain demand within
the community, which is super great. Now on the other hand we have no
noteworthy reactions from that very same community to help with that topic.

Let me put it bluntly. This is not your mothers supermarked where stock
refills almost like automagically overnight. This is open source. It
works as long as there are at least some people spending parts of their
valuable time supporting projects. It is about giving & taking.

Thrift supports about 20+ target languages. So it is fair to say that
supporting packages for all of them (where approprate) is quite a bit of
work.

Of course I can only speak for myself, but I personally maintain quite a
number of packages after each release. Thanks to the great work of other
people (e.g. @JimKing) who spent their time on that topic before me,
this became manageable by setting up and documenting a well-defined
process to follow which also does not eat too much additional release time.

If we can have such a process for PyPi that would be super awesome.
Right now this is not the case, unfortunately. This is where you could
chime in.

See also
https://protect.checkpoint.com/v2/___https://github.com/apache/thrift/pull/2555___.YzJ1OnJlZGRpdDpjOmc6ZGEyMWNiMjExZDEwMWVjZmIzNGI3MWIzMGFmMmEyZTY6Njo0ZDRjOmIyMTFmOWI4ODI2ZTJmZTIxMTQ0NmNhMmQ4M2I5M2EzNDBhY2VhOTVlOGE2YzVjZDgyNWZlMGVmZmZhMThhOWU6cDpU

Happy New Year everybody,
JensG

Re: Contribute to an issue - THRIFT-5688

2024-01-13 Thread Jens Geyer


Hi,

yes I do have PyPi creds.

What would bve the optimum would be some sort of a step-by-step process 
description that someone can follow, even with little to no clue about 
Python and/or its packaging system.



We have a docuement which also has a small section abpout 3rd party 
package managers at the very end. If its more than a few bullet points 
consider putting it into some extra *.md and link to it from there.


https://github.com/apache/thrift/blob/master/doc/ReleaseManagement.md#third-party-package-managers


If you send a PR, the  I can test the process and we can work it out 
together until we are all happy with it.



Have fun,

JensG






From: Adheeth P Praveen 
Sent: Sunday, December 17, 2023 4:57 PM
To: dev@thrift.apache.org 
Subject: Re: Contribute to an issue - THRIFT-5688

Hey Jens

Thank You for the reply and being positive!

I took a manual approaching to the packaging process initially.
I've used the source package available from 
http://archive.apache.org/dist/thrift/0.19.0/thrift-0.19.0.tar.gz and I've been 
able to generate a python package from it.
I've also done a local install on the built package and it worked without any 
issues.

For generating auto build there's a bit I need to learn and explore - mainly 
pipelines.

For uploading the package to the PyPi repo we'll need access to the repository 
and make use a utility called twine.
I believe you do have the credentials/access and you'll be able to do this 
process. If not, you'll have to add a maintainer.

How should i go about it from here?
Where should i share the built packages?
Do we need a GitHub issue on this? If Yes, any pointers on how to create one?

Regards,
bull500


From: Jens Geyer 
Sent: Thursday, November 30, 2023 7:28 PM
To: dev@thrift.apache.org 
Subject: Re: Contribute to an issue - THRIFT-5688

Hi Adheeth,

  > I'm not sure if this is the right place to ask this

Welcome! Yes, indeed it is.


but the JIRA and GitHub looked very specific to development purpose than 
discussions

Correct. General matters are to be discussed in these mailing lists.


  > I came across this issue and I wanted to contribute towards
addressing the problem.

As the ticket says, we currently have the funny situation that there is a  high 
demand for updated python packages but nobody that wants to do this or can 
spare the time. I myself do quite a number of packages myself but Thrift 
supports about 20+ target languages - most of which come with an associated 
library package. So any help on this is highly appreciated!

So where are we with that ticket and where do we want to go?

As shortly noted in the ticket, what we want is some step by step process that 
one can follow to publish the pypi package even though one never did that 
before nor has any intention to follow overly complex procedures (as these tend 
to break over time).

What we have already is an pull request with an updated pypi publishing 
procedere, but since I do not use Python myself I can't say much about the 
status of it.

https://github.com/apache/thrift/pull/2555

As a first milestone it would be perfect if we could publish the latest package 
in _some_ way (even manually) in order to satisfy the demand for it.

  > I'm new to packaging a project to pypi but i would like to help and
learn during the process.

Learning for sure is a by-product of working in the FOSS community.
Therefore, people around are usually keen to help on specific questions,
especially if those are related to the Apache Thrift project.

What we cannot provide is countless hours of help to guide contributors
through the basics of a certain field. There are much better places for
this, and in this particular case I'm sure the Python community would be
of a much greater help.

Have fun,

JensG




Am 25.11.2023 um 18:34 schrieb Adheeth P Praveen:

Hello,

I came across this issue and I wanted to contribute towards addressing the 
problem.
https://issues.apache.org/jira/browse/THRIFT-5688
I'm not sure if this is the right place to ask this but the JIRA and GitHub 
looked very specific to development purpose than discussions

I'm new to packaging a project to pypi but i would like to help and learn 
during the process.
Are there any prerequisites I need to do/learn before addressing this issue?
I would like to have some support if I hit some technical snags if it comes to 
a point where I'm unable solve on my own.

Thanks for reading this!
bull500

[jira] [Commented] (THRIFT-5688) Publish python package to pypi for recent releases

2024-01-12 Thread Jens Geyer (Jira)



[ 
https://issues.apache.org/jira/browse/THRIFT-5688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806197#comment-17806197
 ] 

Jens Geyer commented on THRIFT-5688:


[https://lists.apache.org/thread/xcxlxpzjp81nk1rkf91fjhyxz33wkxlb]

 

> Publish python package to pypi for recent releases
> --
>
> Key: THRIFT-5688
> URL: https://issues.apache.org/jira/browse/THRIFT-5688
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>Affects Versions: 0.17.0, 0.18.0, 0.18.1
>Reporter: Yuxuan Wang
>Assignee: James E. King III
>Priority: Major
>
> Currently the latest version published to pypi is 0.16.0: 
> https://pypi.org/project/thrift/#history
> We probably should update the release runbook regarding this step, and also 
> publish 0.17.0, 0.18.0 and 0.18.1 to pypi.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-5753) PHP 8.1 deprecated warning about return type in jsonSerialize functions

2024-01-11 Thread Jens Geyer (Jira)



[ 
https://issues.apache.org/jira/browse/THRIFT-5753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805778#comment-17805778
 ] 

Jens Geyer commented on THRIFT-5753:


Maybe this helps. 
[https://stitcher.io/blog/php-version-stats-january-2023]

I personally have no opinion in this regard.

> PHP 8.1 deprecated warning about return type in jsonSerialize functions
> ---
>
> Key: THRIFT-5753
> URL: https://issues.apache.org/jira/browse/THRIFT-5753
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Library
>Reporter: Pavel Kvach
>Priority: Minor
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> In PHP 8.1 a "mixed" return type was added to the 
> "JsonSerializable::jsonSerialize()" method.
> This triggers a deprecation warning for generated PHP classes:
> {code:java}
> Return type of TestClass::jsonSerialize() should either be compatible with 
> JsonSerializable::jsonSerialize(): mixed, or the #[\ReturnTypeWillChange] 
> attribute should be used to temporarily suppress the notice in ...{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (THRIFT-5752) Add TTransportFactoryInterface

2024-01-09 Thread Jens Geyer (Jira)



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

Jens Geyer resolved THRIFT-5752.

Fix Version/s: 0.20.0
   Resolution: Fixed

> Add TTransportFactoryInterface
> --
>
> Key: THRIFT-5752
> URL: https://issues.apache.org/jira/browse/THRIFT-5752
> Project: Thrift
>  Issue Type: Improvement
>  Components: PHP - Library
>Affects Versions: 0.19.0
>Reporter: Volodymyr Panivko
>Assignee: Volodymyr Panivko
>Priority: Trivial
>  Labels: php
> Fix For: 0.20.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> I'm offer to add TTransportFactoryInterface for having a possibility to use 
> own implementation of TTransportFactory in TServer.
> I have a problem when I'm tried to make a TSimpleServer for client who used a 
> TFramedTransport. Current realization of TTransportFactory does not give me a 
> possibility to add a TFramedTransport as  a decorator for use TTransport



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (THRIFT-5752) Add TTransportFactoryInterface

2024-01-06 Thread Jens Geyer (Jira)



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

Jens Geyer updated THRIFT-5752:
---
Fix Version/s: (was: 0.20.0)

> Add TTransportFactoryInterface
> --
>
> Key: THRIFT-5752
> URL: https://issues.apache.org/jira/browse/THRIFT-5752
> Project: Thrift
>  Issue Type: Improvement
>  Components: PHP - Library
>Affects Versions: 0.19.0
>Reporter: Volodymyr Panivko
>Assignee: Volodymyr Panivko
>Priority: Trivial
>  Labels: php
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I'm offer to add TTransportFactoryInterface for having a possibility to use 
> own implementation of TTransportFactory in TServer.
> I have a problem when I'm tried to make a TSimpleServer for client who used a 
> TFramedTransport. Current realization of TTransportFactory does not give me a 
> possibility to add a TFramedTransport as  a decorator for use TTransport



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

February release?

2024-01-06 Thread Jens Geyer


@all,

I'm planning to prepare next release candidate around beginning of 
February, unless there are any objections, of course. Please respond 
early if there are any. The date is not set in concrete, there is 
flexibility, so if you want to finish something time-consuming before, 
just let me know.


Have fun,
JensG



OpenPGP_0x76BD340FC4B75865.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

PyPi again

2024-01-06 Thread Jens Geyer


@all,

I just want to bring up that topic again. There is a rather frequent 
stream of (absolutely legitimate) questions regarding the PyPi packages 
not being published.


So it seems fair to say that there is obviously a certain demand within 
the community, which is super great. Now on the other hand we have no 
noteworthy reactions from that very same community to help with that topic.


Let me put it bluntly. This is not your mothers supermarked where stock 
refills almost like automagically overnight. This is open source. It 
works as long as there are at least some people spending parts of their 
valuable time supporting projects. It is about giving & taking.


Thrift supports about 20+ target languages. So it is fair to say that 
supporting packages for all of them (where approprate) is quite a bit of 
work.


Of course I can only speak for myself, but I personally maintain quite a 
number of packages after each release. Thanks to the great work of other 
people (e.g. @JimKing) who spent their time on that topic before me, 
this became manageable by setting up and documenting a well-defined 
process to follow which also does not eat too much additional release time.


If we can have such a process for PyPi that would be super awesome. 
Right now this is not the case, unfortunately. This is where you could 
chime in.


See also https://github.com/apache/thrift/pull/2555

Happy New Year everybody,
JensG




OpenPGP_0x76BD340FC4B75865.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[jira] [Resolved] (THRIFT-5749) Option to enable RTTI info



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

Jens Geyer resolved THRIFT-5749.

Resolution: Fixed

> Option to enable RTTI info
> --
>
> Key: THRIFT-5749
> URL: https://issues.apache.org/jira/browse/THRIFT-5749
> Project: Thrift
>  Issue Type: Improvement
>  Components: Delphi - Compiler
>    Reporter: Jens Geyer
>    Assignee: Jens Geyer
>Priority: Major
> Fix For: 0.20.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> In some cases it would be helpful to have RTTI info available for generated 
> API interfaces.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (THRIFT-5749) Option to enable RTTI info



[ 
https://issues.apache.org/jira/browse/THRIFT-5749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798152#comment-17798152
 ] 

Jens Geyer edited comment on THRIFT-5749 at 12/18/23 11:49 AM:
---

Enabling RTTI comes with small, but necessary changes to the generated code.

*With RTTI enabled:*
 - the interfaces derive from {{IBaseWithTypeInfo}} which in turn derives from 
{{IBase}}.
 - binary translates to {{TThriftBytes}} instead of {{System.TBytes}} to 
prevent against {{E2134 "TBytes has no typinfo"}}.

{{TThriftBytes}} is assignment compatible to {{TBytes}} but it may require 
other code changes, e.g. when using {{Length()}}.

Implementing/querying {{IBaseWithTypeInfo}}  is not necessary/foreseen, its 
only purpose is to add typeinfo.

*Compatibilty note:*

There may cases where activating RTTI leads to uncompileable code, presenting 
{{E2134 "TMyEnum has no typinfo"}} where {{TMyEnum}} is an "irregular" enum 
like {{TNumberz}} from the test suite. This is a known limitation of the Delphi 
RTTI system [1] and *NOT* a bug in Thrift. At this time, you simply cannot use 
RTTI with such enums, unless Embarcadero finally does that stuff right.

[1] 
https://stackoverflow.com/questions/1420562/why-do-i-get-type-has-no-typeinfo-error-with-an-enum-type


was (Author: jensg):
Enabling RTTI comes with small, but necessary changes to the generated code.

*With RTTI enabled:*
 - the interfaces derive from {{IBaseWithTypeInfo}} which in turn derives from 
{{{}IBase{}}}.
 - binary translates to {{TThriftBytes}} instead of {{System.TBytes}} to 
prevent against {{{}E2134 "TBytes has no typinfo"{}}}.

{{TThriftBytes}} is assignment compatible to {{TBytes}} but it may require 
other code changes, e.g. when using {{{}Length(){}}}.

Implementing/querying {{IBaseWithTypeInfo}} is not necessary/foreseen, its only 
purpose is to add typeinfo.

*Compatibilty note:*

There may cases where activating RTTI leads to uncompileable code, presenting 
{{E2134 "TMyEnum has no typinfo"}} where {{TMyEnum}} is an "irregular" enum 
like {{TNumberz}} from the test suite. This is a [well-known limitation of the 
Delphi RTTI 
system|[http://example.com|https://stackoverflow.com/questions/1420562/why-do-i-get-type-has-no-typeinfo-error-with-an-enum-type]]
 and *NOT* a bug in Thrift. At this time, you simply cannot use RTTI with such 
enums, unless Embarcadero finally does that stuff right.

> Option to enable RTTI info
> --
>
> Key: THRIFT-5749
> URL: https://issues.apache.org/jira/browse/THRIFT-5749
> Project: Thrift
>  Issue Type: Improvement
>  Components: Delphi - Compiler
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Major
> Fix For: 0.20.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> In some cases it would be helpful to have RTTI info available for generated 
> API interfaces.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-5749) Option to enable RTTI info



[ 
https://issues.apache.org/jira/browse/THRIFT-5749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798152#comment-17798152
 ] 

Jens Geyer commented on THRIFT-5749:


Enabling RTTI comes with small, but necessary changes to the generated code.

*With RTTI enabled:*
 - the interfaces derive from {{IBaseWithTypeInfo}} which in turn derives from 
{{{}IBase{}}}.
 - binary translates to {{TThriftBytes}} instead of {{System.TBytes}} to 
prevent against {{{}E2134 "TBytes has no typinfo"{}}}.

{{TThriftBytes}} is assignment compatible to {{TBytes}} but it may require 
other code changes, e.g. when using {{{}Length(){}}}.

Implementing/querying {{IBaseWithTypeInfo}} is not necessary/foreseen, its only 
purpose is to add typeinfo.

*Compatibilty note:*

There may cases where activating RTTI leads to uncompileable code, presenting 
{{E2134 "TMyEnum has no typinfo"}} where {{TMyEnum}} is an "irregular" enum 
like {{TNumberz}} from the test suite. This is a [well-known limitation of the 
Delphi RTTI 
system|[http://example.com|https://stackoverflow.com/questions/1420562/why-do-i-get-type-has-no-typeinfo-error-with-an-enum-type]]
 and *NOT* a bug in Thrift. At this time, you simply cannot use RTTI with such 
enums, unless Embarcadero finally does that stuff right.

> Option to enable RTTI info
> --
>
> Key: THRIFT-5749
> URL: https://issues.apache.org/jira/browse/THRIFT-5749
> Project: Thrift
>  Issue Type: Improvement
>  Components: Delphi - Compiler
>        Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Major
> Fix For: 0.20.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> In some cases it would be helpful to have RTTI info available for generated 
> API interfaces.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (THRIFT-5750) deprecate "ansistr_binary_" option

Jens Geyer created THRIFT-5750:
--

 Summary: deprecate "ansistr_binary_" option
 Key: THRIFT-5750
 URL: https://issues.apache.org/jira/browse/THRIFT-5750
 Project: Thrift
  Issue Type: Improvement
  Components: Delphi - Compiler
Reporter: Jens Geyer
Assignee: Jens Geyer


That option was introduced earlier for some rather exotic use case which a) is 
not really relevant anymore and b) should not be part of a general library 
anymore.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (THRIFT-5750) deprecate "ansistr_binary_" option