Would a header file do? It’s quite common to have macros in header files. For example the ones for EUnit, for assertions, and for the logger.
4 Likes
The functions you’re looking for are in the inet_parse module that can easily be wrapped into a utility function
EG
is_ipv4(Ip) when is_list(Ip) ->
inet_parse:ipv4_address(Ip) =/= {error,einval};
is_ipv4(Ip) when is_tuple(Ip) ->
is_ipv4(inet_parse:ntoa(Ip));
is_ipv4(Ip) when is_binary(Ip) ->
is_ipv4(binary_to_list(Ip)).
Edit:
IIRC, when a module/function in OTP is “undocumented” it should be treated as private/unstable.
Maybe it’s time the IP parsing functions were documented/promoted
5 Likes
Yes, and they do have equivalents in inet 
inet:parse_address/1 and friends.
Anyway… the conversion and parsing needed to use those functions for this purpose is pretty expensive I think 
3 Likes
Oh yes, great idea - have possibilities to to set of custom guards if they are needed for project/lib/application 
3 Likes
Not what @meox wanted (guards), but better than having to re-implement IP checks in user code 
9 Likes
Maybe some well defined approaches for library dependency injection.
When I install third-party library, I do not want it to download another http client just because author had to do it. I want to provide some callback on application basic level.
It would be good to have it is a standard for community.
2 Likes
-
GUI: not always alpha/beta wx, but Tk or/and Qt
-
lz4 (with lzhc) along with gzip/zlib
-
not rebar3 but improved make/Emakefile build tool
1 Like
JSON-RPC
Ugly JSON must die.
BERT/BERT-RPC
Definitely no.
Interesting statements 
.
Ugly JSON must die. - Why? Alternatives?
Definitely no. - Why?
Guards? Yes, I agree that
is_ipv4(A) -> is_binary(A) andalso inet:parse_ipv4strict_address(binary_to_list(A)) =/= {error, einval}.
is too bulky (especially beacouse binary_to_list/1), but guard, really?
Ugly JSON must die.- Why?
Because it’s ugly and stupid
Alternatives?
term_to_binary/1,2
message pack
cbor
Definitely no.- Why?
Because it’s obsoleted and term_to_binary/1,2 faster and better.
Well the BERT is use in the background term_to_binary - of course this is related to the implementation but in any case it is used. About Because it’s ugly and stupid not sure that this is a good explanation . Any examples what is made you think so?
2 Likes
Because term_to_binary/1,2 cover all erlang type, cbor can cover all erlang types, MessagePack cover most of erlang types. And JSON is ugly and stupid (and yes, also according to js-developers).
BERTis use in the backgroundterm_to_binary
No, it don’t.
Interesting. But without js-developers you could not join and communicate in such a great forum as this one. I’m already silent about thousands of other useful resources.
No, it don’t. Hm… Yep it is used bert.erl/src/bert.erl at master · mojombo/bert.erl · GitHub and should be used, because BERT means Binary ERlang Term - so, without term_to_binary outside this will not works.
1 Like
But without
js-developersyou could not join and communicate in such a great forum as this one.
I meant “js-developers also think JSON is ugly and stupid” (AFAIK).
Oh… my bad. Misunderstanding. Sorry.
Yep it is used bert.erl/bert.erl at master · mojombo/bert.erl · GitHub
I can’t find maps and atoms there:)
Oh… my bad. Misunderstanding. Sorry.
Or my bad:) My English far from perfect, sorry:)
1 Like
You see I believe that this is a pet project which was experimental. But in this implementations is used some terms like lists, tuples, maps, you can find it in the logic in the encode_term/1 and decode_term/1. Perhaps the project is far from ideal, I saw more interesting implementations somewhere - but this may push us to implement something more impressive implementation.