[jira] [Commented] (THRIFT-4405) Proper use of sequence IDs in all clients and servers
[ https://issues.apache.org/jira/browse/THRIFT-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754603#comment-16754603 ] Randy Abernethy commented on THRIFT-4405: - I would reword #3 and 4 a bit but otherwise sounds great. #3 A server must return the exact seqid received in a request with the response to that request. #4 A server should make no assumptions about the value or semantics of the seqid. > Proper use of sequence IDs in all clients and servers > - > > Key: THRIFT-4405 > URL: https://issues.apache.org/jira/browse/THRIFT-4405 > Project: Thrift > Issue Type: Improvement > Components: Test Suite >Affects Versions: 0.10.0 > Environment: docker ubuntu-xenial >Reporter: James E. King III >Assignee: James E. King III >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Create a feature test that verifies sequence numbers are used properly. > Write a server that verifies clients are generating unique sequence IDs. > Write a client that makes sure servers return the same sequence ID that was > given. > To do this, I enhanced the C++ TProcessorEventHandler class to include a > preReadSeq, which is like preRead but carries the sequence ID. > In the C++ TestServer, I check to see if the sequence numbers are unique and > do not repeat; if any of them do, the cpp test fails. > The following languages properly send sequence IDs (for the binary protocol): > * dart > * go > * nodejs > * java > * rs > The rest of the languages do not. Now, one could argue that unless a > language has a concurrent-safe client and server, sequence IDs are > unnecessary. While that is true, all languages should respect that the > protocol has a sequence ID and there could be future implementations that > will require all clients are well-behaved, which is why I am putting this > test in. > Languages fixed up so unique sequence IDs are sent by the client, and > verified by the tests: > * cpp (was only sending unique sequence IDs for Concurrent clients, now it > does for the regular one too) > * csharp (seqid_ was not bring incremented with each use) > * lua (seqid_ was not bring incremented with each use) > * perl (seqid_ was not bring incremented with each use) > * ruby (seqid_ was not bring incremented with each use and a unit test was > updated to no longer be pending) > Languages left to do: > * c_glib > * erlang > * haskell > * php > * python > * python3 > * any non-cross tested languages -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (THRIFT-2426) clarify IP rights and contributions from fbthrift
[ https://issues.apache.org/jira/browse/THRIFT-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754572#comment-16754572 ] Randy Abernethy commented on THRIFT-2426: - Hey Mario, Yes, would be surprised to get the FB nod to handing over the whole fbthrift repo, though it would be great. In the past the FB folks providing the code bits have built the pull requests. --Randy > clarify IP rights and contributions from fbthrift > -- > > Key: THRIFT-2426 > URL: https://issues.apache.org/jira/browse/THRIFT-2426 > Project: Thrift > Issue Type: Story > Components: Documentation >Reporter: Roger Meier >Assignee: James E. King III >Priority: Critical > > We need to ensure that we have the IP rights to anything we commit from > fbthrift and its traceable back on our dev list initiated from someone at > facebook. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: C# changes and a question
We'll also need to update the NuGet package to property support netstd. See top level ApacheThrift.nuspec - updated in 0.12.0. - Jim On Mon, Jan 28, 2019 at 5:54 PM Jens Geyer wrote: > > To make it clear: I'm talking about netstd only! > > As the plan is to drop C# and netcore after 0.13.0 in favour of netstd, > there's no point in it to change these. > > Thanks again, > JensG > > > -Ursprüngliche Nachricht- > From: Jens Geyer > Sent: Monday, January 28, 2019 11:43 PM > To: Thrift-Dev > Subject: C# changes and a question > > @all C# and netcore developers around, > > the new “netstd” library has been merged to master! > > I tried my best to consolidate the existing libraries into one single > target > that suits both ends of the continuum, including a README that gives hints > to master the migration process from C# or netcore. Yet there may still > be > things to improve, so don’t hesitate to report any problems that you run > into while migrating to netstd or while using it. > > And last not least, here’s a question for you: > > QUESTION --- > Are you using the “nullable” flag and/or could you agree on removing that > piece nevertheless? > > [+1] REMOVE NULLABLE: I am either not using it, or could live with > “nullable” being removed > [-1] KEEP NULLABLE: I am using it and absolutely need it. > > As a bonus question, in the latter case I would (optionally) be interested > in the exact reason, why you think it is not an option to remove > “nullable”. > -- > > Background of this question is, that “nullable” produces a great deal of > pain maintaining it but provides less added value than initially assumed > when we introduced it (at least that’s my personal view to the matter). So > the idea is to remove the “nullable” option entirely from netstd to make > maintenance of the generator code less painful. > > For those wondering: As of today, the “nullable” option is still in the > code, but inactive, so you currently can’t use it with netstd but requires > only a few lines of code to re-enable it. > > > Thank you, and have fun > JensG > >
Re: C# changes and a question
To make it clear: I'm talking about netstd only! As the plan is to drop C# and netcore after 0.13.0 in favour of netstd, there's no point in it to change these. Thanks again, JensG -Ursprüngliche Nachricht- From: Jens Geyer Sent: Monday, January 28, 2019 11:43 PM To: Thrift-Dev Subject: C# changes and a question @all C# and netcore developers around, the new “netstd” library has been merged to master! I tried my best to consolidate the existing libraries into one single target that suits both ends of the continuum, including a README that gives hints to master the migration process from C# or netcore. Yet there may still be things to improve, so don’t hesitate to report any problems that you run into while migrating to netstd or while using it. And last not least, here’s a question for you: QUESTION --- Are you using the “nullable” flag and/or could you agree on removing that piece nevertheless? [+1] REMOVE NULLABLE: I am either not using it, or could live with “nullable” being removed [-1] KEEP NULLABLE: I am using it and absolutely need it. As a bonus question, in the latter case I would (optionally) be interested in the exact reason, why you think it is not an option to remove “nullable”. -- Background of this question is, that “nullable” produces a great deal of pain maintaining it but provides less added value than initially assumed when we introduced it (at least that’s my personal view to the matter). So the idea is to remove the “nullable” option entirely from netstd to make maintenance of the generator code less painful. For those wondering: As of today, the “nullable” option is still in the code, but inactive, so you currently can’t use it with netstd but requires only a few lines of code to re-enable it. Thank you, and have fun JensG
C# changes and a question
@all C# and netcore developers around, the new “netstd” library has been merged to master! I tried my best to consolidate the existing libraries into one single target that suits both ends of the continuum, including a README that gives hints to master the migration process from C# or netcore. Yet there may still be things to improve, so don’t hesitate to report any problems that you run into while migrating to netstd or while using it. And last not least, here’s a question for you: QUESTION --- Are you using the “nullable” flag and/or could you agree on removing that piece nevertheless? [+1] REMOVE NULLABLE: I am either not using it, or could live with “nullable” being removed [-1] KEEP NULLABLE: I am using it and absolutely need it. As a bonus question, in the latter case I would (optionally) be interested in the exact reason, why you think it is not an option to remove “nullable”. -- Background of this question is, that “nullable” produces a great deal of pain maintaining it but provides less added value than initially assumed when we introduced it (at least that’s my personal view to the matter). So the idea is to remove the “nullable” option entirely from netstd to make maintenance of the generator code less painful. For those wondering: As of today, the “nullable” option is still in the code, but inactive, so you currently can’t use it with netstd but requires only a few lines of code to re-enable it. Thank you, and have fun JensG
[jira] [Updated] (THRIFT-4723) Consolidate C# and netcore into new netstd language target (and finally deprecate both C# and netcore bindings)
[ https://issues.apache.org/jira/browse/THRIFT-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer updated THRIFT-4723: --- Summary: Consolidate C# and netcore into new netstd language target (and finally deprecate both C# and netcore bindings) (was: Consolidate C# and netcore into new netstd language target and finally deprecate both C# and netcore bindings) > Consolidate C# and netcore into new netstd language target (and finally > deprecate both C# and netcore bindings) > --- > > Key: THRIFT-4723 > URL: https://issues.apache.org/jira/browse/THRIFT-4723 > Project: Thrift > Issue Type: Umbrella > Components: C# - Compiler, C# - Library, netcore - Compiler, netcore > - Library > Environment: .NET and Mono >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Major > Labels: Umbrella > Time Spent: 40m > Remaining Estimate: 0h > > There are too many differences to get C# effectively merged into netcore. > Because also the name is/would be misleading, the proposal is to have a new > *netstd* target which users can migrate to at will, not by force. The end > goal is of course to deprecate and remove both the existing C# as well as the > existing netcore bindings and only maintain netstd bindings. > *Purpose of this umbrella ticket is only to host all sub-tasks.* -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (THRIFT-4723) Consolidate C# and netcore into new netstd language target (and finally deprecate both C# and netcore bindings)
[ https://issues.apache.org/jira/browse/THRIFT-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer resolved THRIFT-4723. Resolution: Fixed Fix Version/s: 0.13.0 Committed > Consolidate C# and netcore into new netstd language target (and finally > deprecate both C# and netcore bindings) > --- > > Key: THRIFT-4723 > URL: https://issues.apache.org/jira/browse/THRIFT-4723 > Project: Thrift > Issue Type: Umbrella > Components: C# - Compiler, C# - Library, netcore - Compiler, netcore > - Library > Environment: .NET and Mono >Reporter: Jens Geyer >Assignee: Jens Geyer >Priority: Major > Labels: Umbrella > Fix For: 0.13.0 > > Time Spent: 40m > Remaining Estimate: 0h > > There are too many differences to get C# effectively merged into netcore. > Because also the name is/would be misleading, the proposal is to have a new > *netstd* target which users can migrate to at will, not by force. The end > goal is of course to deprecate and remove both the existing C# as well as the > existing netcore bindings and only maintain netstd bindings. > *Purpose of this umbrella ticket is only to host all sub-tasks.* -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (THRIFT-4405) Proper use of sequence IDs in all clients and servers
[
https://issues.apache.org/jira/browse/THRIFT-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754394#comment-16754394
]
Jens Geyer commented on THRIFT-4405:
The
[{color:#0066cc}Whitepaper{color}|https://thrift.apache.org/static/files/thrift-20070401.pdf]
explicitly lists the seqID at request, response AND processing stages. But
other than mentioning them in pseudo code, the whitepaper makes no assumptions
and applies no further requirements on them. Sounds like a good idea to fix
some lose ends.
> Proper use of sequence IDs in all clients and servers
> -
>
> Key: THRIFT-4405
> URL: https://issues.apache.org/jira/browse/THRIFT-4405
> Project: Thrift
> Issue Type: Improvement
> Components: Test Suite
>Affects Versions: 0.10.0
> Environment: docker ubuntu-xenial
>Reporter: James E. King III
>Assignee: James E. King III
>Priority: Major
>
> Create a feature test that verifies sequence numbers are used properly.
> Write a server that verifies clients are generating unique sequence IDs.
> Write a client that makes sure servers return the same sequence ID that was
> given.
> To do this, I enhanced the C++ TProcessorEventHandler class to include a
> preReadSeq, which is like preRead but carries the sequence ID.
> In the C++ TestServer, I check to see if the sequence numbers are unique and
> do not repeat; if any of them do, the cpp test fails.
> The following languages properly send sequence IDs (for the binary protocol):
> * dart
> * go
> * nodejs
> * java
> * rs
> The rest of the languages do not. Now, one could argue that unless a
> language has a concurrent-safe client and server, sequence IDs are
> unnecessary. While that is true, all languages should respect that the
> protocol has a sequence ID and there could be future implementations that
> will require all clients are well-behaved, which is why I am putting this
> test in.
> Languages fixed up so unique sequence IDs are sent by the client, and
> verified by the tests:
> * cpp (was only sending unique sequence IDs for Concurrent clients, now it
> does for the regular one too)
> * csharp (seqid_ was not bring incremented with each use)
> * lua (seqid_ was not bring incremented with each use)
> * perl (seqid_ was not bring incremented with each use)
> * ruby (seqid_ was not bring incremented with each use and a unit test was
> updated to no longer be pending)
> Languages left to do:
> * c_glib
> * erlang
> * haskell
> * php
> * python
> * python3
> * any non-cross tested languages
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4758) We gitignore and do not check in config lock files in many languages - isn't that bad?
[ https://issues.apache.org/jira/browse/THRIFT-4758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754105#comment-16754105 ] Mark Erickson commented on THRIFT-4758: --- Also, in Dart, the guidance is to NOT check in pubspec.lock files for libraries (like thrift), only check it in for applications. See [https://www.dartlang.org/guides/libraries/private-files#the-rules] > We gitignore and do not check in config lock files in many languages - isn't > that bad? > -- > > Key: THRIFT-4758 > URL: https://issues.apache.org/jira/browse/THRIFT-4758 > Project: Thrift > Issue Type: Bug > Components: Build Process, D - Library, Dart - Library, PHP - > Library, Ruby - Library, Rust - Compiler >Affects Versions: 0.12.0 >Reporter: James E. King III >Priority: Major > > In npm we check in the package-lock.json file because that ensures your > builds are stable over time. The cost you pay is that occasionally you need > to rev the file manually. The benefit is a changed package won't bork your > build. > I have identified in the following languages we are ignoring and not checking > in the package lock files: > d (dub) > dart > php (top level composer.jock) > ruby > rust -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (THRIFT-4743) Remove the compiler plug-in mode
[ https://issues.apache.org/jira/browse/THRIFT-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754048#comment-16754048 ] James E. King III commented on THRIFT-4743: --- Apologies, but this was voted on the dev mailing list about a month ago and approved. The plug-in support changes the build workflow depending on whether it is enabled or not. It added a layer of complexity that was considered unwarranted, at least from the perspective of package management. Downstream package managers and the thrift project only release statically linked thrift compilers. This means anyone who wanted to use plug-in mode (such as yourselves) must already fork and rebuild the project with different settings. Given you are already rebuilding, it should not be difficult then to add your compiler as a fairly standard patch. We can certainly discuss reverting this if there are more consumers, but given the lack of response on the mailing list it was assumed nobody is using it. This is a complex software project supporting 28 languages and having two build systems. Every compile-time branch is an added layer of complexity. We decided for example not to support both C++03 and C++11 at the same time because then downstream packagers would be required to produce two libthrift packages for C++, and things would get messy for them. The level of involvement from the community has not been that high, and we do not have committers covering every language. We need to move to a single build system (cmake) and simplify things as much as possible in order to have a more sustainable project. Given folks had to fork the project and build it already just to get plug-in support, it made sense (at least to me) to also have them just add their compiler code in their fork. I don't see how this is any more difficult than having to fork and build WITH_PLUGIN and also maintain a plug-in separately and copy things together to get a solution? > Remove the compiler plug-in mode > > > Key: THRIFT-4743 > URL: https://issues.apache.org/jira/browse/THRIFT-4743 > Project: Thrift > Issue Type: Improvement > Components: Compiler (General) >Affects Versions: 0.13.0 >Reporter: James E. King III >Assignee: James E. King III >Priority: Major > Labels: Breaking-Change > Time Spent: 20m > Remaining Estimate: 0h > > Vote passed on the development mailing list to remove the dynamic compiler > plug-in mechanism. It has been disabled in the majority of all CI builds, > and the mode is already disabled by default in the build systems. This will > simplify the project and remove some compile-time and packaging-time branches. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (THRIFT-4760) Install pkgconfig when using cmake
[ https://issues.apache.org/jira/browse/THRIFT-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III updated THRIFT-4760: -- Affects Version/s: 0.12.0 > Install pkgconfig when using cmake > -- > > Key: THRIFT-4760 > URL: https://issues.apache.org/jira/browse/THRIFT-4760 > Project: Thrift > Issue Type: Improvement > Components: Build Process >Affects Versions: 0.12.0 >Reporter: Aaron Cohen >Assignee: James E. King III >Priority: Major > Labels: cmake > Fix For: 0.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The pkgconfig files are currently only installed when using autotools. > It's not too hard to install them using cmake, and it's nice for 3rd party > projects which don't themselves use cmake. > Pull request to follow shortly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (THRIFT-4760) Install pkgconfig when using cmake
[ https://issues.apache.org/jira/browse/THRIFT-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III resolved THRIFT-4760. --- Resolution: Fixed Assignee: James E. King III Fix Version/s: 0.13.0 > Install pkgconfig when using cmake > -- > > Key: THRIFT-4760 > URL: https://issues.apache.org/jira/browse/THRIFT-4760 > Project: Thrift > Issue Type: Improvement > Components: Build Process >Reporter: Aaron Cohen >Assignee: James E. King III >Priority: Major > Labels: cmake > Fix For: 0.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The pkgconfig files are currently only installed when using autotools. > It's not too hard to install them using cmake, and it's nice for 3rd party > projects which don't themselves use cmake. > Pull request to follow shortly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [jira] [Commented] (THRIFT-4758) We gitignore and do not check in config lock files in many languages - isn't that bad?
I wonder then if the current use of package.lock for Javascript is valid
and correct, as it seems the guidance from other languages for making
libraries is to avoid checking in the lock file.
On Mon, Jan 28, 2019 at 8:23 AM Allen George (JIRA) wrote:
>
> [
> https://issues.apache.org/jira/browse/THRIFT-4758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753990#comment-16753990
> ]
>
> Allen George commented on THRIFT-4758:
> --
>
> [~jking3] Sorry for the delay in responding to this.
>
> Actually I followed the guidance in the Rust community regarding
> {{Cargo.lock}}: "If you’re building a library that other packages will
> depend on, put {{Cargo.lock}} in your {{.gitignore}}. " Source:
> https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html
>
> > We gitignore and do not check in config lock files in many languages -
> isn't that bad?
> >
> --
> >
> > Key: THRIFT-4758
> > URL: https://issues.apache.org/jira/browse/THRIFT-4758
> > Project: Thrift
> > Issue Type: Bug
> > Components: Build Process, D - Library, Dart - Library, PHP -
> Library, Ruby - Library, Rust - Compiler
> >Affects Versions: 0.12.0
> >Reporter: James E. King III
> >Priority: Major
> >
> > In npm we check in the package-lock.json file because that ensures your
> builds are stable over time. The cost you pay is that occasionally you
> need to rev the file manually. The benefit is a changed package won't bork
> your build.
> > I have identified in the following languages we are ignoring and not
> checking in the package lock files:
> > d (dub)
> > dart
> > php (top level composer.jock)
> > ruby
> > rust
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)
>
[jira] [Commented] (THRIFT-4405) Proper use of sequence IDs in all clients and servers
[
https://issues.apache.org/jira/browse/THRIFT-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754021#comment-16754021
]
James E. King III commented on THRIFT-4405:
---
It turns out the languages / combinations above do not need sequence IDs for
proper operation. [~codesf] and [~jensg] I think we should refine the
requirements here as follows, let me know if you agree or we should discuss
more:
# A client *{{MUST}}* send a sequence ID with each request (this is part of the
protocol header, although I am not sure about text-based ones).
# A client *{{MAY}}* make each sequence ID unique, if it requires sequencing
for proper operation. This is typical for clients that allow for multiple
outstanding requests. Clients that do not require sequencing are
*{{RECOMMENDED}}* to send zero for a sequence.
# A server *{{MUST}}* provide the same sequence ID with any response related to
that request.
# A server *{{MUST NOT}}* assume all sequence IDs will be unique.
Thoughts?
> Proper use of sequence IDs in all clients and servers
> -
>
> Key: THRIFT-4405
> URL: https://issues.apache.org/jira/browse/THRIFT-4405
> Project: Thrift
> Issue Type: Improvement
> Components: Test Suite
>Affects Versions: 0.10.0
> Environment: docker ubuntu-xenial
>Reporter: James E. King III
>Assignee: James E. King III
>Priority: Major
>
> Create a feature test that verifies sequence numbers are used properly.
> Write a server that verifies clients are generating unique sequence IDs.
> Write a client that makes sure servers return the same sequence ID that was
> given.
> To do this, I enhanced the C++ TProcessorEventHandler class to include a
> preReadSeq, which is like preRead but carries the sequence ID.
> In the C++ TestServer, I check to see if the sequence numbers are unique and
> do not repeat; if any of them do, the cpp test fails.
> The following languages properly send sequence IDs (for the binary protocol):
> * dart
> * go
> * nodejs
> * java
> * rs
> The rest of the languages do not. Now, one could argue that unless a
> language has a concurrent-safe client and server, sequence IDs are
> unnecessary. While that is true, all languages should respect that the
> protocol has a sequence ID and there could be future implementations that
> will require all clients are well-behaved, which is why I am putting this
> test in.
> Languages fixed up so unique sequence IDs are sent by the client, and
> verified by the tests:
> * cpp (was only sending unique sequence IDs for Concurrent clients, now it
> does for the regular one too)
> * csharp (seqid_ was not bring incremented with each use)
> * lua (seqid_ was not bring incremented with each use)
> * perl (seqid_ was not bring incremented with each use)
> * ruby (seqid_ was not bring incremented with each use and a unit test was
> updated to no longer be pending)
> Languages left to do:
> * c_glib
> * erlang
> * haskell
> * php
> * python
> * python3
> * any non-cross tested languages
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4758) We gitignore and do not check in config lock files in many languages - isn't that bad?
[
https://issues.apache.org/jira/browse/THRIFT-4758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753990#comment-16753990
]
Allen George commented on THRIFT-4758:
--
[~jking3] Sorry for the delay in responding to this.
Actually I followed the guidance in the Rust community regarding
{{Cargo.lock}}: "If you’re building a library that other packages will depend
on, put {{Cargo.lock}} in your {{.gitignore}}. " Source:
https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html
> We gitignore and do not check in config lock files in many languages - isn't
> that bad?
> --
>
> Key: THRIFT-4758
> URL: https://issues.apache.org/jira/browse/THRIFT-4758
> Project: Thrift
> Issue Type: Bug
> Components: Build Process, D - Library, Dart - Library, PHP -
> Library, Ruby - Library, Rust - Compiler
>Affects Versions: 0.12.0
>Reporter: James E. King III
>Priority: Major
>
> In npm we check in the package-lock.json file because that ensures your
> builds are stable over time. The cost you pay is that occasionally you need
> to rev the file manually. The benefit is a changed package won't bork your
> build.
> I have identified in the following languages we are ignoring and not checking
> in the package lock files:
> d (dub)
> dart
> php (top level composer.jock)
> ruby
> rust
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4758) We gitignore and do not check in config lock files in many languages - isn't that bad?
[ https://issues.apache.org/jira/browse/THRIFT-4758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753995#comment-16753995 ] Allen George commented on THRIFT-4758: -- The rationale (AFAICT) is that as the library author you specify the minimum/maximum dependencies your library can use, and then when the application is built Cargo will figure out how to solve all the constraints across all libraries it uses. At that point you check in your lock file for reproducible builds. If I specify a lock file here I'll end up limiting the usable dependencies downstream. > We gitignore and do not check in config lock files in many languages - isn't > that bad? > -- > > Key: THRIFT-4758 > URL: https://issues.apache.org/jira/browse/THRIFT-4758 > Project: Thrift > Issue Type: Bug > Components: Build Process, D - Library, Dart - Library, PHP - > Library, Ruby - Library, Rust - Compiler >Affects Versions: 0.12.0 >Reporter: James E. King III >Priority: Major > > In npm we check in the package-lock.json file because that ensures your > builds are stable over time. The cost you pay is that occasionally you need > to rev the file manually. The benefit is a changed package won't bork your > build. > I have identified in the following languages we are ignoring and not checking > in the package lock files: > d (dub) > dart > php (top level composer.jock) > ruby > rust -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (THRIFT-4763) HTML compiler produces invalid HTML document
Sebastian Zenker created THRIFT-4763:
Summary: HTML compiler produces invalid HTML document
Key: THRIFT-4763
URL: https://issues.apache.org/jira/browse/THRIFT-4763
Project: Thrift
Issue Type: Bug
Components: HTML - Compiler
Reporter: Sebastian Zenker
Steps to reproduce:
# Create an simpl thrift file like the following:
service MyService {}
# generate the HTML documentation for it via thrift -gen html MyService.thrift
The HTML compiler generates the following invalid stream:
{{http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>}}
{{http://www.w3.org/1999/xhtml;>}}
{{}}
{{}}
{{}}
{{Thrift module: test}}
{{}}
{{Thrift module: test}}
{{ModuleServicesData
typesConstants}}
{{}}
{{testMyService}}
{{}}
{{}}
{{}}
{{}}
{{{color:#FF}**{color}}}
{{}}
{{Services}}
{{Service: MyService}}
{{}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (THRIFT-4743) Remove the compiler plug-in mode
[ https://issues.apache.org/jira/browse/THRIFT-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753895#comment-16753895 ] Sebastian Zenker edited comment on THRIFT-4743 at 1/28/19 10:53 AM: _>>> James E. King III: This will simplify the project and remove some compile-time and packaging-time branches._ What are the concert problems with plugin support? Maybe those can be fixed? was (Author: sebastian.zenker): _This will simplify the project and remove some compile-time and packaging-time branches._ What are the concert problems with plugin support? Maybe those can be fixed? > Remove the compiler plug-in mode > > > Key: THRIFT-4743 > URL: https://issues.apache.org/jira/browse/THRIFT-4743 > Project: Thrift > Issue Type: Improvement > Components: Compiler (General) >Affects Versions: 0.13.0 >Reporter: James E. King III >Assignee: James E. King III >Priority: Major > Labels: Breaking-Change > Time Spent: 20m > Remaining Estimate: 0h > > Vote passed on the development mailing list to remove the dynamic compiler > plug-in mechanism. It has been disabled in the majority of all CI builds, > and the mode is already disabled by default in the build systems. This will > simplify the project and remove some compile-time and packaging-time branches. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (THRIFT-4743) Remove the compiler plug-in mode
[ https://issues.apache.org/jira/browse/THRIFT-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753893#comment-16753893 ] Sebastian Zenker commented on THRIFT-4743: -- I just saw right now, that this feature has been removed from master :( Unfortunately, our own software depends on this. Please revert it! > Remove the compiler plug-in mode > > > Key: THRIFT-4743 > URL: https://issues.apache.org/jira/browse/THRIFT-4743 > Project: Thrift > Issue Type: Improvement > Components: Compiler (General) >Affects Versions: 0.13.0 >Reporter: James E. King III >Assignee: James E. King III >Priority: Major > Labels: Breaking-Change > Time Spent: 20m > Remaining Estimate: 0h > > Vote passed on the development mailing list to remove the dynamic compiler > plug-in mechanism. It has been disabled in the majority of all CI builds, > and the mode is already disabled by default in the build systems. This will > simplify the project and remove some compile-time and packaging-time branches. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (THRIFT-4743) Remove the compiler plug-in mode
[ https://issues.apache.org/jira/browse/THRIFT-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753895#comment-16753895 ] Sebastian Zenker commented on THRIFT-4743: -- _This will simplify the project and remove some compile-time and packaging-time branches._ What are the concert problems with plugin support? Maybe those can be fixed? > Remove the compiler plug-in mode > > > Key: THRIFT-4743 > URL: https://issues.apache.org/jira/browse/THRIFT-4743 > Project: Thrift > Issue Type: Improvement > Components: Compiler (General) >Affects Versions: 0.13.0 >Reporter: James E. King III >Assignee: James E. King III >Priority: Major > Labels: Breaking-Change > Time Spent: 20m > Remaining Estimate: 0h > > Vote passed on the development mailing list to remove the dynamic compiler > plug-in mechanism. It has been disabled in the majority of all CI builds, > and the mode is already disabled by default in the build systems. This will > simplify the project and remove some compile-time and packaging-time branches. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (THRIFT-4762) C++: Applied some C++11 refactorings to the runtime library and compiler
Sebastian Zenker created THRIFT-4762: Summary: C++: Applied some C++11 refactorings to the runtime library and compiler Key: THRIFT-4762 URL: https://issues.apache.org/jira/browse/THRIFT-4762 Project: Thrift Issue Type: Improvement Components: C++ - Compiler, C++ - Library, Tutorial Reporter: Sebastian Zenker I basically used clang-tidy to apply the following C++11 refactorings (which make very much sense to me) * make use of override keyword whenever a virtual function is overwritten * make use of auto keyword for iterators * make use of auto keyword when every a redundancy can be avoided, e.g. uint32_t len = static_cast(str.length()); auto len = static_cast(str.length()); * replaced NULL with nullptr * make use of explicitly-defaulted function definition Additionally, I applied some more const-correctness to some functions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (THRIFT-3560) C++ TTransport::isOpen() and TTransport::getOrigin() should be const member functions
[ https://issues.apache.org/jira/browse/THRIFT-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian Zenker closed THRIFT-3560. Resolution: Won't Fix I will create a new merge request, which applies some more C++11 refactorings > C++ TTransport::isOpen() and TTransport::getOrigin() should be const member > functions > - > > Key: THRIFT-3560 > URL: https://issues.apache.org/jira/browse/THRIFT-3560 > Project: Thrift > Issue Type: Improvement > Components: C++ - Library >Affects Versions: 0.9.3, 0.10.0 >Reporter: Sebastian Zenker >Priority: Minor > Labels: easyfix > Time Spent: 10m > Remaining Estimate: 0h > > ... as they should not alter the state of TTransport. Also peek() should be > const in my opinion, but this requires some more refactoring. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
