[jira] [Commented] (THRIFT-4679) Duplicate declaration of InputBufferUnderrunError in lib/nodejs/lib/thrift/json_protocol.js
[
https://issues.apache.org/jira/browse/THRIFT-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16713291#comment-16713291
]
ASF GitHub Bot commented on THRIFT-4679:
jeking3 closed pull request #1642: THRIFT-4679: Remove unused variable
declaration
URL: https://github.com/apache/thrift/pull/1642
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/lib/nodejs/lib/thrift/json_protocol.js
b/lib/nodejs/lib/thrift/json_protocol.js
index d960be9d0c..727a3b2ffb 100644
--- a/lib/nodejs/lib/thrift/json_protocol.js
+++ b/lib/nodejs/lib/thrift/json_protocol.js
@@ -18,7 +18,6 @@
*/
var Int64 = require('node-int64');
-var InputBufferUnderrunError = require('./transport').InputBufferUnderrunError;
var Thrift = require('./thrift');
var Type = Thrift.Type;
var util = require("util");
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Duplicate declaration of InputBufferUnderrunError in
> lib/nodejs/lib/thrift/json_protocol.js
> ---
>
> Key: THRIFT-4679
> URL: https://issues.apache.org/jira/browse/THRIFT-4679
> Project: Thrift
> Issue Type: Bug
> Components: JavaScript - Library
>Affects Versions: 0.11.0
>Reporter: Griffin Michl
>Priority: Minor
> Labels: easyfix
> Original Estimate: 10m
> Remaining Estimate: 10m
>
> InputBufferUnderrunError is unnecessarily declared twice in
> `lib/nodejs/lib/thrift/json_protocol.js`. This causes certain compilers to
> break when they attempt to compile code that uses the node thrift library. We
> should remove the first declaration, as it does not do anything.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (THRIFT-4679) Duplicate declaration of InputBufferUnderrunError in lib/nodejs/lib/thrift/json_protocol.js
[ https://issues.apache.org/jira/browse/THRIFT-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III resolved THRIFT-4679. --- Resolution: Fixed Assignee: James E. King III Fix Version/s: 1.0 Committed - thanks! > Duplicate declaration of InputBufferUnderrunError in > lib/nodejs/lib/thrift/json_protocol.js > --- > > Key: THRIFT-4679 > URL: https://issues.apache.org/jira/browse/THRIFT-4679 > Project: Thrift > Issue Type: Bug > Components: JavaScript - Library >Affects Versions: 0.11.0 >Reporter: Griffin Michl >Assignee: James E. King III >Priority: Minor > Labels: easyfix > Fix For: 1.0 > > Original Estimate: 10m > Remaining Estimate: 10m > > InputBufferUnderrunError is unnecessarily declared twice in > `lib/nodejs/lib/thrift/json_protocol.js`. This causes certain compilers to > break when they attempt to compile code that uses the node thrift library. We > should remove the first declaration, as it does not do anything. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (THRIFT-4679) Duplicate declaration of InputBufferUnderrunError in lib/nodejs/lib/thrift/json_protocol.js
[ https://issues.apache.org/jira/browse/THRIFT-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16713192#comment-16713192 ] ASF GitHub Bot commented on THRIFT-4679: griffinmichl opened a new pull request #1642: THRIFT-4679: Remove unused variable declaration URL: https://github.com/apache/thrift/pull/1642 Changes are backwards compatible (as this line never did anything) https://issues.apache.org/jira/browse/THRIFT-4679 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Duplicate declaration of InputBufferUnderrunError in > lib/nodejs/lib/thrift/json_protocol.js > --- > > Key: THRIFT-4679 > URL: https://issues.apache.org/jira/browse/THRIFT-4679 > Project: Thrift > Issue Type: Bug > Components: JavaScript - Library >Affects Versions: 0.11.0 >Reporter: Griffin Michl >Priority: Minor > Labels: easyfix > Original Estimate: 10m > Remaining Estimate: 10m > > InputBufferUnderrunError is unnecessarily declared twice in > `lib/nodejs/lib/thrift/json_protocol.js`. This causes certain compilers to > break when they attempt to compile code that uses the node thrift library. We > should remove the first declaration, as it does not do anything. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (THRIFT-4679) Duplicate declaration of InputBufferUnderrunError in lib/nodejs/lib/thrift/json_protocol.js
Griffin Michl created THRIFT-4679: - Summary: Duplicate declaration of InputBufferUnderrunError in lib/nodejs/lib/thrift/json_protocol.js Key: THRIFT-4679 URL: https://issues.apache.org/jira/browse/THRIFT-4679 Project: Thrift Issue Type: Bug Components: JavaScript - Library Affects Versions: 0.11.0 Reporter: Griffin Michl InputBufferUnderrunError is unnecessarily declared twice in `lib/nodejs/lib/thrift/json_protocol.js`. This causes certain compilers to break when they attempt to compile code that uses the node thrift library. We should remove the first declaration, as it does not do anything. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[NOTICE] Mandatory relocation of Apache git repositories on git-wip-us.apache.org
[IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS] Hello Apache projects, I am writing to you because you may have git repositories on the git-wip-us server, which is slated to be decommissioned in the coming months. All repositories will be moved to the new gitbox service which includes direct write access on github as well as the standard ASF commit access via gitbox.apache.org. ## Why this move? ## The move comes as a result of retiring the git-wip service, as the hardware it runs on is longing for retirement. In lieu of this, we have decided to consolidate the two services (git-wip and gitbox), to ease the management of our repository systems and future-proof the underlying hardware. The move is fully automated, and ideally, nothing will change in your workflow other than added features and access to GitHub. ## Timeframe for relocation ## Initially, we are asking that projects voluntarily request to move their repositories to gitbox, hence this email. The voluntary timeframe is between now and January 9th 2019, during which projects are free to either move over to gitbox or stay put on git-wip. After this phase, we will be requiring the remaining projects to move within one month, after which we will move the remaining projects over. To have your project moved in this initial phase, you will need: - Consensus in the project (documented via the mailing list) - File a JIRA ticket with INFRA to voluntarily move your project repos over to gitbox (as stated, this is highly automated and will take between a minute and an hour, depending on the size and number of your repositories) To sum up the preliminary timeline; - December 9th 2018 -> January 9th 2019: Voluntary (coordinated) relocation - January 9th -> February 6th: Mandated (coordinated) relocation - February 7th: All remaining repositories are mass migrated. This timeline may change to accommodate various scenarios. ## Using GitHub with ASF repositories ## When your project has moved, you are free to use either the ASF repository system (gitbox.apache.org) OR GitHub for your development and code pushes. To be able to use GitHub, please follow the primer at: https://reference.apache.org/committer/github We appreciate your understanding of this issue, and hope that your project can coordinate voluntarily moving your repositories in a timely manner. All settings, such as commit mail targets, issue linking, PR notification schemes etc will automatically be migrated to gitbox as well. With regards, Daniel on behalf of ASF Infra. PS:For inquiries, please reply to us...@infra.apache.org, not your project's dev list :-).
[jira] [Comment Edited] (THRIFT-4678) add noexcept cpp generator option
[ https://issues.apache.org/jira/browse/THRIFT-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16712801#comment-16712801 ] James E. King III edited comment on THRIFT-4678 at 12/7/18 12:44 PM: - In this effort here, `BOOST_NOEXCEPT_OR_NOTHROW` is a good option for exception declarations, however if we build any exception code into the link library, one would have to build a library for `C++03` and one for `C++11` in order for that to work. It starts getting a bit messy. I think it would be useful to first get the entire C++ library to work without boost if someone has `C++11` or later. Then we can drop support for `C++03`. Anyone who needs `C++03` support can use an older version (like 0.11.0 or 0.12.0, to be released soon, hopefully). THRIFT-4441 covers the effort to wean the project off boost. Perhaps this work can be done in cooperation with that work? The author of THRIFT-4441 seems to have disappeared or dropped their effort; they were pretty close to completing the work of getting to `C++11` without the need for boost. was (Author: jking3): In this effort here, `BOOST_NOEXCEPT_OR_NOTHROW` is a good option for exception declarations, however if we build any exception code into the link library, one would have to build a library for C++03 and one for C++11 in order for that to work. It starts getting a bit messy. I think it would be useful to first get the entire C++ library to work without boost if someone has C++11 or later. Then we can drop support for C++03. Anyone who needs C++03 support can use an older version (like 0.11.0 or 0.12.0, to be released soon, hopefully). THRIFT-4441 covers the effort to wean the project off boost. Perhaps this work can be done in cooperation with that work? The author of THRIFT-4441 seems to have disappeared or dropped their effort; they were pretty close to completing the work of getting to C++11 without the need for boost. > add noexcept cpp generator option > - > > Key: THRIFT-4678 > URL: https://issues.apache.org/jira/browse/THRIFT-4678 > Project: Thrift > Issue Type: Improvement > Components: C++ - Compiler, C++ - Library >Affects Versions: 0.11.0 >Reporter: yuanyuan chen >Priority: Minor > > The C++11 standard has deprecated the usage of throw() to express > exceptions,so to avoid warnings from the compiler,I think this option is > useful. > I have a pull request in github,this issue is created to track it. > Some questions remain: > 1.Should we change the runtime c++ library to use BOOST_NOEXCEPT_OR_NOTHROW? > 2.Should we add an control option to enable all c++11 options like > moveable_types .etc? > 3.Should we begin to support C+17 features? I think std::optional should be > used to implement optional keyword,but this is clearly an API breaking > change,so we need an c+17 control option. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (THRIFT-4678) add noexcept cpp generator option
[
https://issues.apache.org/jira/browse/THRIFT-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16712801#comment-16712801
]
James E. King III edited comment on THRIFT-4678 at 12/7/18 12:45 PM:
-
In this effort here, `BOOST_NOEXCEPT_OR_NOTHROW` is a good option for exception
declarations, however if we build any exception code into the link library, one
would have to build a library for {{C++03}} and one for {{C++11}} in order for
that to work. It starts getting a bit messy.
I think it would be useful to first get the entire C++ library to work without
boost if someone has {{C++11}} or later. Then we can drop support for
{{C++03}}. Anyone who needs {{C++03}} support can use an older version (like
0.11.0 or 0.12.0, to be released soon, hopefully). THRIFT-4441 covers the
effort to wean the project off boost. Perhaps this work can be done in
cooperation with that work? The author of THRIFT-4441 seems to have
disappeared or dropped their effort; they were pretty close to completing the
work of getting to {{C++11}} without the need for boost.
was (Author: jking3):
In this effort here, `BOOST_NOEXCEPT_OR_NOTHROW` is a good option for exception
declarations, however if we build any exception code into the link library, one
would have to build a library for `C++03` and one for `C++11` in order for that
to work. It starts getting a bit messy.
I think it would be useful to first get the entire C++ library to work without
boost if someone has `C++11` or later. Then we can drop support for `C++03`.
Anyone who needs `C++03` support can use an older version (like 0.11.0 or
0.12.0, to be released soon, hopefully). THRIFT-4441 covers the effort to wean
the project off boost. Perhaps this work can be done in cooperation with that
work? The author of THRIFT-4441 seems to have disappeared or dropped their
effort; they were pretty close to completing the work of getting to `C++11`
without the need for boost.
> add noexcept cpp generator option
> -
>
> Key: THRIFT-4678
> URL: https://issues.apache.org/jira/browse/THRIFT-4678
> Project: Thrift
> Issue Type: Improvement
> Components: C++ - Compiler, C++ - Library
>Affects Versions: 0.11.0
>Reporter: yuanyuan chen
>Priority: Minor
>
> The C++11 standard has deprecated the usage of throw() to express
> exceptions,so to avoid warnings from the compiler,I think this option is
> useful.
> I have a pull request in github,this issue is created to track it.
> Some questions remain:
> 1.Should we change the runtime c++ library to use BOOST_NOEXCEPT_OR_NOTHROW?
> 2.Should we add an control option to enable all c++11 options like
> moveable_types .etc?
> 3.Should we begin to support C+17 features? I think std::optional should be
> used to implement optional keyword,but this is clearly an API breaking
> change,so we need an c+17 control option.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4678) add noexcept cpp generator option
[ https://issues.apache.org/jira/browse/THRIFT-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16712801#comment-16712801 ] James E. King III commented on THRIFT-4678: --- In this effort here, `BOOST_NOEXCEPT_OR_NOTHROW` is a good option for exception declarations, however if we build any exception code into the link library, one would have to build a library for C++03 and one for C++11 in order for that to work. It starts getting a bit messy. I think it would be useful to first get the entire C++ library to work without boost if someone has C++11 or later. Then we can drop support for C++03. Anyone who needs C++03 support can use an older version (like 0.11.0 or 0.12.0, to be released soon, hopefully). THRIFT-4441 covers the effort to wean the project off boost. Perhaps this work can be done in cooperation with that work? The author of THRIFT-4441 seems to have disappeared or dropped their effort; they were pretty close to completing the work of getting to C++11 without the need for boost. > add noexcept cpp generator option > - > > Key: THRIFT-4678 > URL: https://issues.apache.org/jira/browse/THRIFT-4678 > Project: Thrift > Issue Type: Improvement > Components: C++ - Compiler, C++ - Library >Affects Versions: 0.11.0 >Reporter: yuanyuan chen >Priority: Minor > > The C++11 standard has deprecated the usage of throw() to express > exceptions,so to avoid warnings from the compiler,I think this option is > useful. > I have a pull request in github,this issue is created to track it. > Some questions remain: > 1.Should we change the runtime c++ library to use BOOST_NOEXCEPT_OR_NOTHROW? > 2.Should we add an control option to enable all c++11 options like > moveable_types .etc? > 3.Should we begin to support C+17 features? I think std::optional should be > used to implement optional keyword,but this is clearly an API breaking > change,so we need an c+17 control option. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (THRIFT-4678) add noexcept cpp generator option
[ https://issues.apache.org/jira/browse/THRIFT-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III updated THRIFT-4678: -- Affects Version/s: (was: 1.0) 0.11.0 > add noexcept cpp generator option > - > > Key: THRIFT-4678 > URL: https://issues.apache.org/jira/browse/THRIFT-4678 > Project: Thrift > Issue Type: Improvement > Components: C++ - Compiler, C++ - Library >Affects Versions: 0.11.0 >Reporter: yuanyuan chen >Priority: Minor > > The C++11 standard has deprecated the usage of throw() to express > exceptions,so to avoid warnings from the compiler,I think this option is > useful. > I have a pull request in github,this issue is created to track it. > Some questions remain: > 1.Should we change the runtime c++ library to use BOOST_NOEXCEPT_OR_NOTHROW? > 2.Should we add an control option to enable all c++11 options like > moveable_types .etc? > 3.Should we begin to support C+17 features? I think std::optional should be > used to implement optional keyword,but this is clearly an API breaking > change,so we need an c+17 control option. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (THRIFT-4678) add noexcept cpp generator option
[ https://issues.apache.org/jira/browse/THRIFT-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King III updated THRIFT-4678: -- Fix Version/s: (was: 1.0) > add noexcept cpp generator option > - > > Key: THRIFT-4678 > URL: https://issues.apache.org/jira/browse/THRIFT-4678 > Project: Thrift > Issue Type: Improvement > Components: C++ - Compiler, C++ - Library >Affects Versions: 0.11.0 >Reporter: yuanyuan chen >Priority: Minor > > The C++11 standard has deprecated the usage of throw() to express > exceptions,so to avoid warnings from the compiler,I think this option is > useful. > I have a pull request in github,this issue is created to track it. > Some questions remain: > 1.Should we change the runtime c++ library to use BOOST_NOEXCEPT_OR_NOTHROW? > 2.Should we add an control option to enable all c++11 options like > moveable_types .etc? > 3.Should we begin to support C+17 features? I think std::optional should be > used to implement optional keyword,but this is clearly an API breaking > change,so we need an c+17 control option. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
