aboutsummaryrefslogtreecommitdiffstats
path: root/lib/diameter/src/compiler/diameter_forms.hrl
AgeCommit message (Collapse)Author
2015-06-18Change license text to APLv2Bruce Yinhe
2015-04-30diameter: Use module erl_annoHans Bolinder
2014-03-25Use fun encoding to erl_parse:abstract/2Anders Svensson
This is an encoding that didn't exist at the time of the previous commit, but which was added in commit 83b6daef. Use it to restrict stringification to lists containing printable ascii.
2014-03-21Adapt dictionary compilation to new default encodingAnders Svensson
The problem is that the change in default encoding to utf8 in 17.0, in commit 00e42967, changes the behaviour of erl_parse:abstract/1, which is used by the dictionary compiler to turn terms into abstract code. In particular, it transforms the orddict representation of a parsed dictionary to contruct the return value of a dictionary module's dict/0 function. This orddict contains various lists, one of which is a list of tuples of the form {Name, Code, [VendorId], [Avp]} where Name is an ASCII string and VendorId is a non-negative integer. Using erl_parse:abstract/2 instead allows a string encoding to be specified but regardless of what encoding is used, the result of transforming our tuple might not be what we really want, which is for Name to always be represented as a string form and [VendorId] to always be represented as a cons form: the [VendorId] will always end up as a string form if the integers are small enough. The only way around this is to transform the tuple bit by bit, but modifying the code to do this is quite a lot of work, for not much gain: it would be nice to produce more readable output but nothing stops working without it. This commit restores the pre-17.0 conversion by explicilty specifying latin1 as the string encoding to erl_parse:abstract/2. The utf8 encoding broke the compilation of some dictionares since unicode strings aren't expected when writing the generated code to file. Note that the latin1 encoding does reasonably well in practice, although it mangles the Ericsson Vendor Id list [193] into a "LATIN CAPITAL LETTER A WITH ACUTE". The utf8 encoding does worse, mangling the 3GPP Vendor Id 10415 into "DESERET CAPITAL LETTER CHEE". An ascii encoding would do better than latin1 but doesn't yet exist. (Encoding isn't really what the option is. It's a string predicate: if the predicate is true then represent as a string form, otherwise a cons form.)
2013-02-22Update copyright yearsBjörn-Egil Dahlberg
2013-02-08Add exprecs '#get-'/1 for transforming records into listsAnders Svensson
The generated '#get-'/1 has one clause for each exported record r, whose definition is equivalent to the following. '#get-'(#r{} = Rec) -> [r | lists:zip(record_info(r, fields), tl(tuple_to_list(Rec)))]; The record name at the head of the list is the same format that diameter accepts for outgoing message.
2011-12-02diameter_spec_util -> diameter_dict_util and adapt to parserAnders Svensson
Errors are now detected after the parse with format_error/1 providing understandable error messages, pointing to the offending line number(s) in the dictionary source.
2011-05-20Update copyright yearsBjörn-Egil Dahlberg
2011-05-18Initial commit of the diameter application.Anders Svensson
The application provides an implementation of the Diameter protocol as defined in RFC 3588.