[GitHub] thrift pull request #1320: THRIFT-4270: Generate Erlang mapping functions fo...

2017-07-28 Thread dhull
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 map ALPHABET = { "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

2017-07-28 Thread David Hull (JIRA)
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.

2017-07-28 Thread davinchia
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 '_'.

2017-07-28 Thread ASF GitHub Bot (JIRA)

[ 
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 Hull 
Date:   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...

2017-07-28 Thread dhull
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 Hull 
Date:   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 '_'.

2017-07-28 Thread David Hull (JIRA)

 [ 
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 '_'.

2017-07-28 Thread David Hull (JIRA)
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)

2017-07-28 Thread James E. King, III (JIRA)

[ 
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.