Re: [DISCUSS]: Source release artifact

[Roger Meier]

Hi all

the big question for me is how git archive will be used, does it just
solve (1) as mentioned by Jens? What about updating version tags within
source tree and creating a tarball of the tree for a release?
So users need to sh bootstrap.sh or just use CMake or any other specific
build system such as npm.

The other question is how CMake should accelerate the release procedure.
To you think we should have e.g. a package.json and package.json.in file
within the tree? One for preparing the release easily and the other for
people hacking directly on the git tree as most people do.

Quarterly releases would be very good so people can use latest tagged
release within their projects.

bets!
roger

Quoting Jens Geyer :


Hi,

(1) If git archive solves the problems I'm for it. If EXTRA_DIST is  
made obsolete by this step I'm even more for it.


(2) Time plan sounds feasible to me. A week more or less will not  
harm anyone, so let's just do it.


(3) Regular schedule sounds great! Not sure about monthly, though.  
My first reaction was, bimonthly or quarterly (= 3 months) is  
probably enough and would be a great leap forward. On the other  
hand, if we somehow could manage to get into a position where we are  
able to do a release basically on the proverbial spur of the moment,  
just by pushing a few buttons, then we can have whatever release  
schedule makes sense vis-à-vis features implemented and bugs fixed.  
We could even make it based on a milestone feature set, instead of a  
fixed schedule. Not sure how close we can get to that goal and how  
much effort it takes (and where it stops making sense), but that's  
what I imagine.


Have fun,
JensG


-Ursprüngliche Nachricht- From: Jake Farrell
Sent: Friday, October 2, 2015 7:24 PM
To: dev@thrift.apache.org
Subject: [DISCUSS]: Source release artifact

In an effort to make releases easier to cut I would like to propose that we
move to using git archive with a .gitignore to exclude any files that we
feel should not be apart of the release. This will help cut down on time
spent tracking missed files in the EXTRA_DIST section and having to compare
the release dist versus whats in the repository.

My thought is that we work towards the cmake switch as follows:

0.9.4: end October - Switch to git archive
0.9.5: end November - Unify build/test env (Jenkins/Travis/etc all using
Docker)
1.0: end December - Switch to cmake

And what is everyone preference moving forward for release cadence, would
like to get on a more regular schedule. monthly, quarterly?

Thoughts?

-Jake

Re: Major feature suggestion/observation

[Roger Meier]

Hi David

Quoting David Bennett :

I'm a compiler guy (amongst other scars). I was somewhat surprised  
when I opened up the Thrift compiler to discover that it uses  
industrial strength parsing (for a very slim language) and a  
hand-rolled, ad hoc source code generator (for a serious backend  
problem). I had expected the exact opposite.


After reading a few comments on this list I think a number of the  
shortcomings of Thrift result from this. The compiler may be  
'tweakable' but it sure ain't configurable. The precise content of  
the generated code (and how to alter it) is an ever present problem.


My suggestion is that the backend of the compiler should be entirely  
rewritten using modern code generation technology and a selection of  
'skeletons' provided as separate text files. Anyone who wanted to  
tweak the output for any of their special use cases could easily  
copy and modify an individual skeleton without having to venture  
into the dark recesses of the C++ compiler.

Did you had a look at the JIRA issues related to rewrite and changes on
the compiler?
Have you seen the python variant? This was another try to do it again.

I have seldom seen some successful rewrites, usually it takes too long
to bring them to the same level. Personally, I'm a fan of evolution.



With luck, the initial batch of skeletons could be extracted  
directly from the existing compiler. It's still a biggish job.


[Side digression: for some languages code generation is not really  
needed. The language has sufficient abstraction capability to  
implement the IDL directly. Since there are other languages that do  
not, we are stuck with code generation.]


The biggest choice is: which product to use for the code generation?  
I have a little familiarity with T4 and the ANTLR StringTemplate,  
and I've hand-rolled a couple of my own but there are heaps of  
others out there. Maybe it all comes down to what you're used to.  
I'm not sure I'm quite ready for the investment of time.

Feel free to rewrite the compiler and provide a test suite for review.
Improving the test suites across languages, improving CMake, fixing bugs
and many other topics to improve on Thrift has much higher priority than
rewriting something we already have.

best!
Roger

PS: dev list is a better place for such discussions.




Regards
David M Bennett FACS

[GitHub] thrift pull request: Thrift 2905 & - Modern Objective-C & Swift co...

[kdubb]

Github user kdubb commented on the pull request:

https://github.com/apache/thrift/pull/539#issuecomment-145765106
  
@creker No Idea. I pinged them on the list a month or so ago. The response 
was favorable but no movement yet.

I just finished the rough pass of proper Swift code generation. It builds 
on these changes because it reuses the Objective-C implementations of protocols 
and transports. Hopefully this stuff will be interesting enough to get things 
moving.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Swift Code Generator

[Kevin Wooten]

I’ve added Swift code generation support.  It lives in my (*cough* aging 
*cough*) pull request #539 

I literally have just finished the code and it’s had very little testing apart 
from ensuring it generates compilable code.  Anybody who would like to take 
part in shaping the way the code is generated should check it out and send me 
your feedback.

It requires Swift 2.0 from Xcode 7.

It builds on my previous changes to modernize and optimize the Objective-C 
library and generated code. It does so because the generated Swift code re-uses 
the modernized cocoa library code.  I’d like to see these shared for the 
foreseeable future since I see no advantage to duplicating this library code at 
this time; other than being able to say it’s “all swift” it wouldn’t provide 
any real advantages.

Enjoy.


* I jokingly referred to my PR as aging because it was never merged but it 
probably needs to wait now until the Swift generations is stabilized and 
tested.  Alternatively I could move the Swift code to a new PR and #539 could 
be merged.

[jira] [Commented] (THRIFT-3339) Support for database/sql

[Jens Geyer (JIRA)]

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

Jens Geyer commented on THRIFT-3339:


I look at it soon, it's already on my list.

> Support for database/sql
> 
>
> Key: THRIFT-3339
> URL: https://issues.apache.org/jira/browse/THRIFT-3339
> Project: Thrift
>  Issue Type: Improvement
>  Components: Go - Compiler
>Reporter: Adam Beberg
>Assignee: Adam Beberg
> Fix For: 0.9.4
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> For use by database/sql the generated code needs:
> 1. Generated enums need to implement sql.Scanner and driver.Valuer
> 2. Struct fields need db: annotations with the original field names.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (THRIFT-3365) IDL Union structs nil dereferencing in Go

[Jamil (JIRA)]

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

Jamil updated THRIFT-3365:
--
Labels: golang union  (was: )

> IDL Union structs nil dereferencing in Go
> -
>
> Key: THRIFT-3365
> URL: https://issues.apache.org/jira/browse/THRIFT-3365
> Project: Thrift
>  Issue Type: Bug
>  Components: Go - Compiler
>Affects Versions: 0.9.2
>Reporter: Jamil
>  Labels: golang, union
>
> Suppose I have a union 
> {code}
> union Select {
> 1: Aggregate selectAggregate,
> 2: SelectColumns selectColumns,
> }
> {code}
> the Go representation looks like
> {code}
> type Select struct {
>   SelectAggregate *Aggregate `thrift:"selectAggregate,1" 
> json:"selectAggregate"`
>   SelectColumns   *SelectColumns `thrift:"selectColumns,2" 
> json:"selectColumns"`
> }
> {code}
> now when I create 
> {code}
> Select = NewSelect()
> Select.SelectColumns = SelectColumns{
> ...
> }
> {code}
> I get a nil dereference pointer when the code tries to invoke 
> select.SelectAggregate.writeField1()
> however if I create a empty aggregate instantiation I get the error:
> Cannot read a TUnion with more than one set value!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] thrift pull request: THRIFT-2994: Fix TJsonProtocol for nodejs

[timse]

Github user timse commented on the pull request:

https://github.com/apache/thrift/pull/379#issuecomment-145812777
  
i did changes, i don't really know what to do with the failing, tests. Are 
they related to my changes?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (THRIFT-2994) Node.js TJSONProtocol cannot be used for object serialization.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on THRIFT-2994:


Github user timse commented on the pull request:

https://github.com/apache/thrift/pull/379#issuecomment-145812777
  
i did changes, i don't really know what to do with the failing, tests. Are 
they related to my changes?


> Node.js TJSONProtocol cannot be used for object serialization.
> --
>
> Key: THRIFT-2994
> URL: https://issues.apache.org/jira/browse/THRIFT-2994
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Reporter: Jan Brauer
>Assignee: Randy Abernethy
>
> Consider the following code using the Thrift example types.
> {code:title=serialize.js|borderStyle=solid}
> var thrift = require('thrift');
> var test_types = require('gen-nodejs/ThriftTest_types.js');
> var bonk = new test_types.Bonk({message: "message", type: 6})
> var t_out = new thrift.TBufferedTransport();
> var p_out = new thrift.TJSONProtocol(t_out);
> bonk.write(p_out);
> var out
> t_out.flush(function (b) { out = b;});
> console.log(out)
> {code}
> My expectation would be for {{out}} to contain the serialized {{Bonk}} struct.
> But due to 
> [TJSONProtocol|https://github.com/apache/thrift/blob/master/lib/nodejs/lib/thrift/protocol.js#L1287]
>  only writing to the underlying transport in {{writeMessageEnd}} the above 
> code does not work.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[RESULT][VOTE]: Release Apache Thrift 0.9.3

[Jake Farrell]

With 6 +1's (5 binding) and no negative votes the 0.9.3 release candidate
vote passes. Will start publishing the release artifacts shortly, thanks
everyone for taking the time to review the release candidate and for all
the patches and new features that went into making this release

-Jake


Binding Votes:
Jake Farrell
Jake Luciani
Jens Geyer
Randy Abernethy
Roger Meier

Non-Binding Votes:
Konrad Grochowski



On Thu, Oct 1, 2015 at 9:24 PM, Jake Farrell  wrote:

> All,
> I propose that we accept the following release candidate as the official
> Apache Thrift 0.9.3 release.
>
> http://people.apache.org/~jfarrell/thrift/0.9.3/thrift-0.9.3-rc0.tar.gz
>
>
> The release candidate was created from the 0.9.3 branch and can be
> cloned using:
>
> git clone -b 0.9.3 https://git-wip-us.apache.org/repos/asf/thrift.git
>
> The release candidates GPG signature can be found at:
> http://people.apache.org/~jfarrell/thrift/0.9.3/thrift-0.9.3-rc0.tar.gz.asc
>
> It has an MD5 sum of: 88d667a8ae870d5adeca8cb7d6795442
>
> The CHANGES list for this release is available at:
>
> https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=CHANGES;hb=0.9.3
>
> Packaged client libraries are available for testing at:
> http://people.apache.org/~jfarrell/thrift/0.9.3/lib/
>
> The deb package repo is available at:
> http://people.apache.org/~jfarrell/thrift/0.9.3/repo/ubuntu
>
> The windows compiler is available at:
>
> http://people.apache.org/~jfarrell/thrift/0.9.3/compiler/windows/thrift-0.9.3-rc0.exe
>
>
> Please download, verify sig/sum, install and test the libraries of your
> choice.
>
> This vote will close in 72 hours
>
> [ ] +1 Release this as Apache Thrift 0.9.3
> [ ] +0
> [ ] -1 Do not release this as Apache Thrift 0.9.3 because...
>
> I will get the voting started with my own +1
> -Jake
>

[jira] [Commented] (THRIFT-2994) Node.js TJSONProtocol cannot be used for object serialization.

[Randy Abernethy (JIRA)]

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

Randy Abernethy commented on THRIFT-2994:
-

Regarding the tests, it would be great to have all tests pass after every patch 
but as long as no additional tests fail after the patch we can commit it on the 
merits of the patch. There are failing node tests in the current master that 
are not associated with your patch.

I'm reviewing 379 
(https://patch-diff.githubusercontent.com/raw/apache/thrift/pull/379.patch). 
The first hunk of the patch I see:{code}
@@ -40,6 +40,8 @@ module.exports = TJSONProtocol;
  */
 function TJSONProtocol(trans) {
   this.trans = trans;
+  this.tstack = [];
+  this.tpos = [];
 };{code}

Conflicts with the master which contains: {code}
function TJSONProtocol(trans) {
  this.tstack = [];
  this.tpos = [];
  this.trans = trans;
}; {code}

Am I not grabbing the right patch?

> Node.js TJSONProtocol cannot be used for object serialization.
> --
>
> Key: THRIFT-2994
> URL: https://issues.apache.org/jira/browse/THRIFT-2994
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Reporter: Jan Brauer
>Assignee: Randy Abernethy
>
> Consider the following code using the Thrift example types.
> {code:title=serialize.js|borderStyle=solid}
> var thrift = require('thrift');
> var test_types = require('gen-nodejs/ThriftTest_types.js');
> var bonk = new test_types.Bonk({message: "message", type: 6})
> var t_out = new thrift.TBufferedTransport();
> var p_out = new thrift.TJSONProtocol(t_out);
> bonk.write(p_out);
> var out
> t_out.flush(function (b) { out = b;});
> console.log(out)
> {code}
> My expectation would be for {{out}} to contain the serialized {{Bonk}} struct.
> But due to 
> [TJSONProtocol|https://github.com/apache/thrift/blob/master/lib/nodejs/lib/thrift/protocol.js#L1287]
>  only writing to the underlying transport in {{writeMessageEnd}} the above 
> code does not work.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (THRIFT-2805) 0.9.3 release candidate

[Jake Farrell (JIRA)]

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

Jake Farrell closed THRIFT-2805.

Resolution: Fixed

> 0.9.3 release candidate
> ---
>
> Key: THRIFT-2805
> URL: https://issues.apache.org/jira/browse/THRIFT-2805
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 0.9.3
>Reporter: Jake Farrell
>Assignee: Jake Farrell
> Fix For: 0.9.3
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)