[GitHub] thrift pull request #1320: THRIFT-4270: Generate Erlang mapping functions fo...
GitHub user dhull opened a pull request: https://github.com/apache/thrift/pull/1320 THRIFT-4270: Generate Erlang mapping functions for const maps and lists The Erlang generator now creates a new constants module containing two functions for each const map and list. The first function takes a single argument, the key for a const map or the index for a const list, and returns the corresponding value for that key or index; it throws an exception if the key does not exist or the index is out of range. The second function is similar to the first but takes a default second element, and returns this default instead of throwing an exception if the key does not exist or the index is out of range. For example, if example.thrift contains the following Thrift definitions: ```thrift const mapALPHABET = { "a" : "apple", "b" : "banana" } const list NUMBER = [ "one", "two", "three" ] ``` then these calls will succeed: ```erlang "apple" = example_constants:alphabet("a"), "three" = example_constants:number(3), ``` You can merge this pull request into a Git repository by running: $ git pull https://github.com/dhull/thrift thrift-4270-erlang-mapping-functions Alternatively you can review and apply these changes as the patch at: https://github.com/apache/thrift/pull/1320.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1320 commit 3ec8e6a542c1f59908deabafd7ce94f459dfa038 Author: David Hull Date: 2017-07-28T21:13:23Z Remove unused t_erl_generator::export_types_function function. commit 3d1ec6131268a803c701f02480ac758c4cbcb5f2 Author: David Hull Date: 2017-07-28T18:52:21Z THRIFT-4270: Generate Erlang mapping functions for const maps and lists. The Erlang generator now creates a new constants module containing two functions for each const map and list. The first function takes a single argument, the key for a const map or the index for a const list, and returns the corresponding value for that key or index; it throws an exception if the key does not exist or the index is out of range. The second function is similar to the first but takes a default second element, and returns this default instead of throwing an exception if the key does not exist or the index is out of range. For example, if example.thrift contains the following Thrift definitions: const map ALPHABET = { "a" : "apple", "b" : "banana" } const list NUMBER = [ "one", "two", "three" ] these calls will succeed: "apple" = example_constants:alphabet("a"), "three" = example_constants:number(3), --- 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] [Created] (THRIFT-4270) Generate Erlang mapping functions for const maps and lists
David Hull created THRIFT-4270: -- Summary: Generate Erlang mapping functions for const maps and lists Key: THRIFT-4270 URL: https://issues.apache.org/jira/browse/THRIFT-4270 Project: Thrift Issue Type: Improvement Components: Erlang - Compiler Affects Versions: 0.10.0 Reporter: David Hull Priority: Minor The Thrift Erlang compiler generates macros for consts. This is great for scalar types and structs. However the macro that is generated for a map is something like {code:none} -define(CONSTANTS_DEMO_GEN_MAP, dict:from_list([{35532,233},{43523,853}])). {code} This is not as useful as the other macros, because any use of this macro will generate the dict at run time. (It is possible to work around this issue by using the ct_expand parse transform.) It would be better to generate a function directly to do the transform. The function for the previous example would be {code:none} gen_map(35532) -> 233; gen_map(43523) -> 853. {code} Similarly, the macro that is generated for a list is something like: {code:none} -define(CONSTANTS_DEMO_GEN_LIST, [235235,23598352,3253523]). {code} This representation is fine if you want to iterate over the elements of the list, but is not efficient if you need to look an element because lists in Erlang are implemented as singly-linked lists. For lookups, it would be better to generate a tuple and then use {{element(N, Tuple)}} to extract the nth element. The thrift generator could generate a function to do the lookup: {code:none} gen_list(N) -> element(N, {235235,23598352,3253523}). {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] thrift issue #1311: Fix for constant assignments to optional fields in Go.
Github user davinchia commented on the issue: https://github.com/apache/thrift/pull/1311 @Jens-G Github must have hidden my comments. My latest commit combined the functions and removed the toString function as per your suggestions. Not sure why one of the integration tests are failing. Logs show `/usr/include/php5/Zend/zend_hash.h:266:2:` is the cause, which is not something I modified. --- 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-4269) Don't append '.' to Erlang namespace if it ends in '_'.
[ https://issues.apache.org/jira/browse/THRIFT-4269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16105435#comment-16105435 ] ASF GitHub Bot commented on THRIFT-4269: GitHub user dhull opened a pull request: https://github.com/apache/thrift/pull/1319 THRIFT-4269: Don't append '.' to Erlang namespace if it ends in '_'. THRIFT-3834 added support for namespaces to the Erlang code generator. However, that support uses a `.` between the namespace name and the type name. This is inconvenient because, although `.` is a valid character in an Erlang atom, atoms that contain `.` must be quoted. This means that a struct named MyStruct in the namespace NS will generate a record named `'NS.MyStruct'`. The rules for naming atoms in Erlang are: > Atoms begin with a lower-case letter, and may contain alphanumeric characters, underscores (_) or at-signs (@). Alternatively atoms can be specified by enclosing them in single quotes ('), necessary when they start with an uppercase character or contain characters other than underscores and at-signs. This pull request changes the Erlang code generator so that if an Erlang namespace ends in a `_` then no `.` is added between the namespace and the struct name when creating the record. This preserves the current behavior unless the namespace ends is a `_`, but allow users to override the normal behavior by adding an explicit `_` to the end of their namespace declarations. You can merge this pull request into a Git repository by running: $ git pull https://github.com/dhull/thrift thrift-4269-erlang-namespace-dot-optional Alternatively you can review and apply these changes as the patch at: https://github.com/apache/thrift/pull/1319.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1319 commit 453f45725e3fd474ff08c0633d8902bf1a8358f4 Author: David HullDate: 2017-07-28T00:09:42Z THRIFT-4269: Add Erlang namespace test using ConstantsDemo.thrift. commit 50fade0cf7cd9b922d5d87c76d21afc9ce62ee15 Author: David Hull Date: 2017-07-27T23:26:55Z THRIFT-4269: Don't append '.' to Erlang namespace if it ends in '_'. THRIFT-3834 added support for namespaces to the Erlang code generator. However, that support uses a '.' between the namespace name and the type name. This is inconvenient because, although '.' is a valid character in an Erlang atom, atoms that contain '.' must be quoted. This means that a struct named MyStruct in the namespace NS will generate a record named 'NS.MyStruct'. The rules for naming atoms in Erlang are: Atoms begin with a lower-case letter, and may contain alphanumeric characters, underscores (_) or at-signs (@). Alternatively atoms can be specified by enclosing them in single quotes ('), necessary when they start with an uppercase character or contain characters other than underscores and at-signs. This commit changes the Erlang code generator so that if an Erlang namespace ends in a '_' then no '.' is added between the namespace and the struct name when creating the record. This preserves the current behavior unless the namespace ends is a '_', but allow users to override the normal behavior by adding an explicit '_' to the end of their namespace declarations. > Don't append '.' to Erlang namespace if it ends in '_'. > --- > > Key: THRIFT-4269 > URL: https://issues.apache.org/jira/browse/THRIFT-4269 > Project: Thrift > Issue Type: Improvement > Components: Erlang - Compiler >Affects Versions: 0.10.0 >Reporter: David Hull >Priority: Minor > > THRIFT-3834 added support for namespaces to the Erlang code generator. > However, that support uses a {{.}} between the namespace name and the type > name. This is inconvenient because, although {{.}} is a valid character in an > Erlang atom, atoms that contain {{.}} must be quoted. This means that a > struct named {{MyStruct}} in the namespace {{NS}} will cause a record named > {{'NS.MyStruct'}} to be generated. Here are the rules for naming atoms in > Erlang: > bq. Atoms begin with a lower-case letter, and may contain alphanumeric > characters, underscores (_) or at-signs (@). Alternatively atoms can be > specified by enclosing them in single quotes ('), necessary when they start > with an uppercase character or contain characters other than underscores and > at-signs. > I propose that if an Erlang namespace ends in a {{\_}} that no {{.}} be added > between the namespace and the struct name when creating the record. This will > preserve the current behavior unless
[GitHub] thrift pull request #1319: THRIFT-4269: Don't append '.' to Erlang namespace...
GitHub user dhull opened a pull request: https://github.com/apache/thrift/pull/1319 THRIFT-4269: Don't append '.' to Erlang namespace if it ends in '_'. THRIFT-3834 added support for namespaces to the Erlang code generator. However, that support uses a `.` between the namespace name and the type name. This is inconvenient because, although `.` is a valid character in an Erlang atom, atoms that contain `.` must be quoted. This means that a struct named MyStruct in the namespace NS will generate a record named `'NS.MyStruct'`. The rules for naming atoms in Erlang are: > Atoms begin with a lower-case letter, and may contain alphanumeric characters, underscores (_) or at-signs (@). Alternatively atoms can be specified by enclosing them in single quotes ('), necessary when they start with an uppercase character or contain characters other than underscores and at-signs. This pull request changes the Erlang code generator so that if an Erlang namespace ends in a `_` then no `.` is added between the namespace and the struct name when creating the record. This preserves the current behavior unless the namespace ends is a `_`, but allow users to override the normal behavior by adding an explicit `_` to the end of their namespace declarations. You can merge this pull request into a Git repository by running: $ git pull https://github.com/dhull/thrift thrift-4269-erlang-namespace-dot-optional Alternatively you can review and apply these changes as the patch at: https://github.com/apache/thrift/pull/1319.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1319 commit 453f45725e3fd474ff08c0633d8902bf1a8358f4 Author: David HullDate: 2017-07-28T00:09:42Z THRIFT-4269: Add Erlang namespace test using ConstantsDemo.thrift. commit 50fade0cf7cd9b922d5d87c76d21afc9ce62ee15 Author: David Hull Date: 2017-07-27T23:26:55Z THRIFT-4269: Don't append '.' to Erlang namespace if it ends in '_'. THRIFT-3834 added support for namespaces to the Erlang code generator. However, that support uses a '.' between the namespace name and the type name. This is inconvenient because, although '.' is a valid character in an Erlang atom, atoms that contain '.' must be quoted. This means that a struct named MyStruct in the namespace NS will generate a record named 'NS.MyStruct'. The rules for naming atoms in Erlang are: Atoms begin with a lower-case letter, and may contain alphanumeric characters, underscores (_) or at-signs (@). Alternatively atoms can be specified by enclosing them in single quotes ('), necessary when they start with an uppercase character or contain characters other than underscores and at-signs. This commit changes the Erlang code generator so that if an Erlang namespace ends in a '_' then no '.' is added between the namespace and the struct name when creating the record. This preserves the current behavior unless the namespace ends is a '_', but allow users to override the normal behavior by adding an explicit '_' to the end of their namespace declarations. --- 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] [Updated] (THRIFT-4269) Don't append '.' to Erlang namespace if it ends in '_'.
[ https://issues.apache.org/jira/browse/THRIFT-4269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Hull updated THRIFT-4269: --- Description: THRIFT-3834 added support for namespaces to the Erlang code generator. However, that support uses a {{.}} between the namespace name and the type name. This is inconvenient because, although {{.}} is a valid character in an Erlang atom, atoms that contain {{.}} must be quoted. This means that a struct named {{MyStruct}} in the namespace {{NS}} will cause a record named {{'NS.MyStruct'}} to be generated. Here are the rules for naming atoms in Erlang: bq. Atoms begin with a lower-case letter, and may contain alphanumeric characters, underscores (_) or at-signs (@). Alternatively atoms can be specified by enclosing them in single quotes ('), necessary when they start with an uppercase character or contain characters other than underscores and at-signs. I propose that if an Erlang namespace ends in a {{\_}} that no {{.}} be added between the namespace and the struct name when creating the record. This will preserve the current behavior unless the namespace ends is a {{\_}}, but allow users to override the normal behavior by adding an explicit {{\_}} to the end of their namespace declarations. was: THRIFT-3834 added support for namespaces to the Erlang code generator. However, that support uses a {{.}} between the namespace name and the type name. This is inconvenient because, although {{.}} is a valid character in an Erlang atom, atoms that contain {{.}} must be quoted. This means that a struct named {{MyStruct}} in the namespace {{NS}} will cause a record named {{'NS.MyStruct'}} to be generated. Here are the rules for naming atoms in Erlang: bq. Atoms begin with a lower-case letter, and may contain alphanumeric characters, underscores (_) or at-signs (@). Alternatively atoms can be specified by enclosing them in single quotes ('), necessary when they start with an uppercase character or contain characters other than underscores and at-signs. I propose that if an Erlang namespace ends in a {{_}} that no {{.}} be added between the namespace and the struct name when creating the record. This will preserve the current behavior unless the namespace ends is a {{_}}, but allow users to override the normal behavior by adding an explicit {{_}} to the end of their namespace declarations. > Don't append '.' to Erlang namespace if it ends in '_'. > --- > > Key: THRIFT-4269 > URL: https://issues.apache.org/jira/browse/THRIFT-4269 > Project: Thrift > Issue Type: Improvement > Components: Erlang - Compiler >Affects Versions: 0.10.0 >Reporter: David Hull >Priority: Minor > > THRIFT-3834 added support for namespaces to the Erlang code generator. > However, that support uses a {{.}} between the namespace name and the type > name. This is inconvenient because, although {{.}} is a valid character in an > Erlang atom, atoms that contain {{.}} must be quoted. This means that a > struct named {{MyStruct}} in the namespace {{NS}} will cause a record named > {{'NS.MyStruct'}} to be generated. Here are the rules for naming atoms in > Erlang: > bq. Atoms begin with a lower-case letter, and may contain alphanumeric > characters, underscores (_) or at-signs (@). Alternatively atoms can be > specified by enclosing them in single quotes ('), necessary when they start > with an uppercase character or contain characters other than underscores and > at-signs. > I propose that if an Erlang namespace ends in a {{\_}} that no {{.}} be added > between the namespace and the struct name when creating the record. This will > preserve the current behavior unless the namespace ends is a {{\_}}, but > allow users to override the normal behavior by adding an explicit {{\_}} to > the end of their namespace declarations. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (THRIFT-4269) Don't append '.' to Erlang namespace if it ends in '_'.
David Hull created THRIFT-4269: -- Summary: Don't append '.' to Erlang namespace if it ends in '_'. Key: THRIFT-4269 URL: https://issues.apache.org/jira/browse/THRIFT-4269 Project: Thrift Issue Type: Improvement Components: Erlang - Compiler Affects Versions: 0.10.0 Reporter: David Hull Priority: Minor THRIFT-3834 added support for namespaces to the Erlang code generator. However, that support uses a {{.}} between the namespace name and the type name. This is inconvenient because, although {{.}} is a valid character in an Erlang atom, atoms that contain {{.}} must be quoted. This means that a struct named {{MyStruct}} in the namespace {{NS}} will cause a record named {{'NS.MyStruct'}} to be generated. Here are the rules for naming atoms in Erlang: bq. Atoms begin with a lower-case letter, and may contain alphanumeric characters, underscores (_) or at-signs (@). Alternatively atoms can be specified by enclosing them in single quotes ('), necessary when they start with an uppercase character or contain characters other than underscores and at-signs. I propose that if an Erlang namespace ends in a {{_}} that no {{.}} be added between the namespace and the struct name when creating the record. This will preserve the current behavior unless the namespace ends is a {{_}}, but allow users to override the normal behavior by adding an explicit {{_}} to the end of their namespace declarations. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (THRIFT-3593) Enable server-side to issue requests to clients on the same connection (push notifications)
[ https://issues.apache.org/jira/browse/THRIFT-3593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16105052#comment-16105052 ] James E. King, III commented on THRIFT-3593: At some point this year I would like to implement the behavior in THRIFT-66 (C#) in C++ to allow "clients" to register handlers. Each side of the connection will be a client and a server, and it will be backwards compatible. I may also move the socket transport behavior into boost::asio at that point because you really need a reactor model in order to make that work efficiently. Each side will be able to have multiple outstanding requests against the other, using the already-existing request ID field. > Enable server-side to issue requests to clients on the same connection (push > notifications) > --- > > Key: THRIFT-3593 > URL: https://issues.apache.org/jira/browse/THRIFT-3593 > Project: Thrift > Issue Type: Wish > Components: .NETCore - Compiler, .NETCore - Library, AS3 - Compiler, > AS3 - Library, C glib - Compiler, C glib - Library, C# - Compiler, C# - > Library, C++ - Compiler, C++ - Library, Cocoa - Compiler, Cocoa - Library, > Compiler (General), D - Compiler, D - Library, Dart - Compiler, Dart - > Library, Delphi - Compiler, Delphi - Library, Documentation, Erlang - > Compiler, Erlang - Library, Go - Compiler, Go - Library, Haskell - Compiler, > Haskell - Library, Haxe - Compiler, Haxe - Library, Java - Compiler, Java - > Library, JavaME - Compiler, JavaME - Library, JavaScript - Compiler, > JavaScript - Library, Lua - Compiler, Lua - Library, Node.js - Compiler, > Node.js - Library, OCaml - Compiler, OCaml - Library, Perl - Compiler, Perl - > Library, PHP - Compiler, PHP - Library, Python - Compiler, Python - Library, > Ruby - Compiler, Ruby - Library, Rust - Compiler, Rust - Library, Smalltalk - > Compiler, Smalltalk - Library, Swift - Compiler, Swift - Library, Test Suite, > Tutorial, Wish List >Reporter: Sebastian Zenker >Priority: Critical > Labels: push > > In our applications, we have very often the use case, that we actively want > to inform all connected Thrift clients about state changes on the server > side. Let me use a stupid example to explain what I whish. Let's assume we > have service which represents a fan controller. This service allows to > configure a target temperature and can be requested for the actual > temperature and actual RPM. > {code} > service FanController > { > void setTargetTemperature(int t); > int getTargetTemperature(); > int getActualTemperature(); > int getActualRPM(); > } > {code} > Our client application allows the user to set the target temperature and > display the actual temperature and RPM. > To implement such an application, we currently have two options when using > the Thrift framework: > 1.) Every client requests the actual temperature and RPM once per second. > With other words: every client implements polling. > 2.) We split service FanController into two different Thrift services. One > which allows to configure the fan controller and a second one which is used > by the server to notify all its clients about state changes. The first one is > implemented by the "real" server and the second one is implemented by all > clients and consists of some oneway methods only. So from a Thrift point of > view, both sides are server & client. E.g. > {code} > service FanController > { > void setTargetTemperature(int t); > int getTargetTemperature(); > void RegisterEvents(string hostname, int port); //use to tell the server, > that it should establish a connection to hostname+port which implements > FanControllerEvents > void UnregisterEvents(string hostname, int port); > } > service FanControllerEvents > { > oneway void targetTemperatureChanged(int t); > oneway void actualTemperatureChanged(int t); > oneway void actualRPMChanged(int rpm); > } > {code} > Both approaches have massive drawbacks. I think it is not worth the effort to > explain why solution #1 (polling) sucks. But also solution #2 doesn't work > well, because: > * It requires every client to register its FanControllerEvents service at > the server side by using FanController::RegisterEvents(). This doesn't work, > in case the client resides behind a NAT-router, because so the "real" server > cannot establish a TCP connection to the client. > * It always requires at least two TCP connections which makes firewall > configurations more complex. > * The "real" server needs to maintain a list with all connected clients in > the application logic. In case the actual RPM or temperature changes, the > server needs to iterate over the list of all connected clients and call the > corresponding function.