I'm creating a new Elixir library that require to be executed with different versions of the language.
This library uses the Erlang :crypto.hmac function but this function was replaced on version 22 of Erlang OTP by :crypto.mac (with same functionality).
I'm using the following private macro to execute the newer or older functions:
defmacrop hmac(key, data) do
if System.otp_release() >= "22" do
quote do: :crypto.mac(:hmac, :sha256, unquote(key), unquote(data))
else
quote do: :crypto.hmac(:sha256, unquote(key), unquote(data))
end
end
And using it in the following way:
hmac(key, data)
Two questions:
Is this a correct way of execute code based in the OTP release version?
Any better obvious way to address this problem?
Thanks.
Is this a correct way of execute code based in the OTP release version?
You should not check OTP version, but the application (in this case crypto) version. As the OTP version can be different from the application version.
Any better obvious way to address this problem?
Yes, check if given function is exported instead of checking what is the version of the OTP/application.
There are 2 ways to do so, in runtime:
def hmac(key, data) do
if Code.ensure_loaded?(:crypto) and function_exported?(:crypto, :mac, 4) do
:crypto.mac(:mac, :sha256, key, data)
else
:crypto.hmac(:sha256, key, data)
end
end
Or during compile time:
if Code.ensure_loaded?(:crypto) and function_exported?(:crypto, :mac, 4) do
def hmac(key, data), do: :crypto.mac(:mac, :sha256, key, data)
else
def hmac(key, data), do: :crypto.hmac(:sha256, key, data)
end
Macros are compile-time creatures. After compilation there is no trail of macro; instead, the AST it injected takes place in the release.
That said if you want it to be a compile-time, meaning you’ll need many environments to compile, and each release to be working on the same platform as it was compiled only, this is the correct approach.
If you want to assemble a release once and make it working on different target platforms, you’d better use Kernel.apply/3 as
def hmac(key, data) do
if String.to_integer(System.otp_release) >= 22,
do: apply(:crypto, :mac, [:hmac, :sha256, key, data]),
else: apply(:crypto, :hmac, [:sha256, key, data])
end
Sidenote: even if you want it to be compile-time, it’d be cleaner to declare different functions, rather than a macro.
if String.to_integer(System.otp_release) >= 22 do
def hmac(key, data),
do: :crypto.mac(:hmac, :sha256, key, data)
else
def hmac(key, data),
do: :crypto.hmac(:sha256, key, data)
end
This will be evaluated in the compile-time and the respective function will take place in the resulting BEAM code.
Related
We use APIs, baninst1.PP_DEDUCTION.p_update and baninst1.PP_DEDUCTION.p_create, to maintain our payroll tables of benefit/deduction data. Numerous packages utilize the APIs. We would like to create a package containing the API call that all the existing packages can use and remove the code that is repeated in each package. I tried EXECUTE IMMEDIATE for the purpose of having a dynamic API name. However, I have not been able to get the syntax correct. I’m hoping you will help me.
create or replace PACKAGE BODY "ORBIT"."MM_BENEFITS_COMMON" AS
PROCEDURE PAY_P_EMPLOYEE_BENEFIT_ACTION(pi_benefit_action IN VARCHAR2,
pi_pidm IN pdrbded.pdrbded_pidm%TYPE,
pi_status IN pdrdedn.pdrdedn_status%TYPE,
pi_bdca_code IN pdrbded.pdrbded_bdca_code%TYPE,
pi_effective_date IN pdrdedn.pdrdedn_effective_date%TYPE DEFAULT NULL, pi_user_id IN pdrdedn.pdrdedn_user_id%TYPE DEFAULT NULL, pi_data_origin IN pdrdedn.pdrdedn_data_origin%TYPE DEFAULT NULL,
po_base_rowid_out OUT gb_common.internal_record_id_type,
po_detail_rowid_out OUT gb_common.internal_record_id_type,
pi_amount1 IN pdrdedn.pdrdedn_amount1%TYPE DEFAULT NULL,
pi_opt_code1 IN pdrdedn.pdrdedn_opt_code1%TYPE DEFAULT NULL) IS
BEGIN
--Call the API for p_create or p_update.
baninst1.PP_DEDUCTION.pi_benefit_action(p_pidm => pi_pidm,
p_status => pi_status,
p_bdca_code => pi_bdca_code,
p_effective_date => CASE
WHEN pi_benefit_action 'p_create' THEN
TRUNC(pi_begin_date)
ELSE
TRUNC(pi_effective_date)
END,
p_user_id => pi_user_id,
p_data_origin => pi_data_origin,
p_base_rowid_out => po_base_rowid_out,
p_detail_rowid_out => po_detail_rowid_out, p_amount1 => pi_amount1,
p_opt_code1 => CASE
WHEN LENGTH(pi_opt_code1) = 1 THEN
'0' || pi_opt_code1
ELSE pi_opt_code1
END);
END PAY_P_EMPLOYEE_BENEFIT_ACTION;
END MM_BENEFITS_COMMON;
create or replace PACKAGE BODY "ORBIT"."MM_BENEFIT_TEST" AS
PROCEDURE PAY_P_MM_BENEFIT_TEST IS
lv_base_rowid_out gb_common.internal_record_id_type;
lv_detail_rowid_out gb_common.internal_record_id_type;
BEGIN
--Pass data to the common benefits package for the api call
MM_BENEFITS_COMMON.PAY_P_EMPLOYEE_BENEFIT_ACTION('p_update', 9999999, 'A', 'VI1', '01-JAN-2022', 'MM_Test', 'MM_TEST', lv_base_rowid_out, lv_detail_rowid_out, 25.82, NULL);
END PAY_P_MM_BENEFIT_TEST;
END MM_BENEFIT_TEST;
I'm not sure what's bothering you, actually. You did post some code, but - I don't know what it represents.
Let's see what you said:
"We use APIs, baninst1.PP_DEDUCTION.p_update and baninst1.PP_DEDUCTION.p_create, to maintain our payroll tables of benefit/deduction data."
OK
"Numerous packages utilize the APIs."
it means that there are many packages and they call those p_update and p_create procedures; that's also OK
"We would like to create a package containing the API call that all the existing packages can use and remove the code that is repeated in each package."
that would be a new package; you'd cut that piece of code from all of your packages and paste it into a new one.
OK, makes sense. Instead of all that code (in every package), you'd put call to newly created procedures (that reside in a newly created package)
"I tried EXECUTE IMMEDIATE for the purpose of having a dynamic API name. However, I have not been able to get the syntax correct."
why dynamic SQL? There's nothing dynamic here. Instead of dozens of lines of code you currently have (that do something), you'd put one line - the one that calls that newly created procedure (and pass parameters)
From my point of view, there's nothing unusual in what you want to do and I can't imagine what problems you could have in doing it; it's pretty much straightforward.
I'm working on implementing a feature like Strict Java Deps for rules_scala.
I'd really like to have the ability to configure in runtime if this uses warn or error.
I seem to recall skylark rules can't create and access command-line flags but I don't recall if they can access existing ones?
Main difference is that existing ones are already parsed so maybe they are also passed in some ctx.
The flag you want (strict_java_deps) isn't available through Skylark at the moment. There's no reason we can't add it, though, filed #3295 to track.
For other flags, the context can access the configuration fragments, which can access some of the parsed command line flags. I think what you'd want is ctx.fragments, then use the fragments to get the java fragments, and then get the default_javac_flags from that:
# rules.bzl
def _impl(ctx):
print("flags: %s" % ctx.fragments.java.default_javac_flags)
...
frag = rule(
implementation = _impl,
fragments = ["java"], # Declare that this rule uses java fragments
)
Then:
$ bazel build --javacopt="-g:source,lines" :x
WARNING: /home/kchodorow/test/a/tester.bzl:2:3: flags: ["-g:source,lines"].
I am using NodeMCU 0.9.6 with an Adafruit HUZZAH ESP8266.
The following code, which defines the callback function within the http.get statement, works:
http.get("http://192.168.2.38/ICmd.py?i=esp8266001", nil, function(code, data)
if (code < 0) then
print("***ICmd HTTP request failed")
else
print("***ICmd callback: ", code, data)
end
end)
The following code moves the callback function definition from within the http.get statement to be a standalone function:
function chkICmdResp(code, data)
if (code < 0) then
print("***ICmd HTTP request failed")
else
print("***ICmd callback: ", code, data)
end
end
http.get("http://192.168.2.38/ICmd.py?i=esp8266001", nil, chkICmdResp(code, data) )
The second format does not work, it generates the error:
stdin:2: attempt to compare nil with number
stack traceback:
stdin:2: in function 'chkICmdResponse'
stdin:1: in main chunk
Am I doing something incorrectly (NodeMCU noobie)? Or is this a design feature or a bug?
It would be nice to be able to have a single callback function that can be referenced from multiple http.get calls.
Note: I have also tried this with the net.socket:on("receive",...) module and got the same error result when trying to use a function that is defined outside of the calling statement.
There's a fundamental mismatch between what you're trying to do and what your firmware offers. Do NOT use those old 0.9.x NodeMCU binaries. They're based on old Espressif SDKs, they're no longer maintained and they're full of bugs.
The HTTP client module has only been around for a few months. It's currently only available in the NodeMCU dev branch i.e. not even in current master. Recipe for success:
build a firmware from the dev branch that includes the HTTP module (off by default): http://nodemcu.readthedocs.org/en/dev/en/build/
flash the binary to your chip: http://nodemcu.readthedocs.org/en/dev/en/flash/
use the HTTP module as documented: http://nodemcu.readthedocs.org/en/dev/en/modules/http/#httpget
If you decide to stick with the net module rather than using HTTP there's a small example in the docs: http://nodemcu.readthedocs.org/en/dev/en/modules/net/#netsocketsend
In my Informix 4GL program, I have an input field where the user can insert a URL and the feed is later being sent over to the web via a script.
How can I validate the URL at the time of input, to ensure that it's a live link? Can I make a call and see if I get back any errors?
I4GL checking the URL
There is no built-in function to do that (URLs didn't exist when I4GL was invented, amongst other things).
If you can devise a C method to do that, you can arrange to call that method through the C interface. You'll write the method in native C, and then write an I4GL-callable C interface function using the normal rules. When you build the program with I4GL c-code, you'll link the extra C functions too. If you build the program with I4GL-RDS (p-code), you'll need to build a custom runner with the extra function(s) exposed. All of this is standard technique for I4GL.
In general terms, the C interface code you'll need will look vaguely like this:
#include <fglsys.h>
// Standard interface for I4GL-callable C functions
extern int i4gl_validate_url(int nargs);
// Using obsolescent interface functions
int i4gl_validate_url(int nargs)
{
if (nargs != 1)
fgl_fatal(__FILE__, __LINE__, -1318);
char url[4096];
popstring(url, sizeof(url));
int r = validate_url(url); // Your C function
retint(r);
return 1;
}
You can and should check the manuals but that code, using the 'old style' function names, should compile correctly. The code can be called in I4GL like this:
DEFINE url CHAR(256)
DEFINE rc INTEGER
LET url = "http://www.google.com/"
LET rc = i4gl_validate_url(url)
IF rc != 0 THEN
ERROR "Invalid URL"
ELSE
MESSAGE "URL is OK"
END IF
Or along those general lines. Exactly what values you return depends on your decisions about how to return a status from validate_url(). If need so be, you can return multiple values from the interface function (e.g. error number and text of error message). Etc. This is about the simplest possible design for calling some C code to validate a URL from within an I4GL program.
Modern C interface functions
The function names in the interface library were all changed in the mid-00's, though the old names still exist as macros. The old names were:
popstring(char *buffer, int buflen)
retint(int retval)
fgl_fatal(const char *file, int line, int errnum)
You can find the revised documentation at IBM Informix 4GL v7.50.xC3: Publication library in PDF in the 4GL Reference Manual, and you need Appendix C "Using C with IBM Informix 4GL".
The new names start ibm_lib4gl_:
ibm_libi4gl_popMInt()
ibm_libi4gl_popString()
As to the error reporting function, there is one — it exists — but I don't have access to documentation for it any more. It'll be in the fglsys.h header. It takes an error number as one argument; there's the file name and a line number as the other arguments. And it will, presumably, be ibm_lib4gl_… and there'll be probably be Fatal or perhaps fatal (or maybe Err or err) in the rest of the name.
I4GL running a script that checks the URL
Wouldn't it be easier to write a shell script to get the status code? That might work if I can return the status code or any existing results back to the program into a variable? Can I do that?
Quite possibly. If you want the contents of the URL as a string, though, you'll might end up wanting to call C. It is certainly worth thinking about whether calling a shell script from within I4GL is doable. If so, it will be a lot simpler (RUN "script", IIRC, where the literal string would probably be replaced by a built-up string containing the command and the URL). I believe there are file I/O functions in I4GL now, too, so if you can get the script to write a file (trivial), you can read the data from the file without needing custom C. For a long time, you needed custom C to do that.
I just need to validate the URL before storing it into the database. I was thinking about:
#!/bin/bash
read -p "URL to check: " url
if curl --output /dev/null --silent --head --fail "$url"; then
printf '%s\n' "$url exist"
else
printf '%s\n' "$url does not exist"
fi
but I just need the output instead of /dev/null to be into a variable. I believe the only option is to dump the output into a temp file and read from there.
Instead of having I4GL run the code to validate the URL, have I4GL run a script to validate the URL. Use the exit status of the script and dump the output of curl into /dev/null.
FUNCTION check_url(url)
DEFINE url VARCHAR(255)
DEFINE command_line VARCHAR(255)
DEFINE exit_status INTEGER
LET command_line = "check_url ", url
RUN command_line RETURNING exit_status
RETURN exit_status
END FUNCTION {check_url}
Your calling code can analyze exit_status to see whether it worked. A value of 0 indicates success; non-zero indicates a problem of some sort, which can be deemed 'URL does not work'.
Make sure the check_url script (a) exits with status zero on success and non-zero on any sort of failure, and (b) doesn't write anything to standard output (or standard error) by default. The writing to standard error or output will screw up screen layouts, etc, and you do not want that. (You can obviously have options to the script that enable standard output, or you can invoke the script with options to suppress standard output and standard error, or redirect the outputs to /dev/null; however, when used by the I4GL program, it should be silent.)
Your 'script' (check_url) could be as simple as:
#!/bin/bash
exec curl --output /dev/null --silent --head --fail "${1:-http://www.example.com/"
This passes the first argument to curl, or the non-existent example.com URL if no argument is given, and replaces itself with curl, which generates a zero/non-zero exit status as required. You might add 2>/dev/null to the end of the command line to ensure that error messages are not seen. (Note that it will be hell debugging this if anything goes wrong; make sure you've got provision for debugging.)
The exec is a minor optimization; you could omit it with almost no difference in result. (I could devise a scheme that would probably spot the difference; it involves signalling the curl process, though — kill -9 9999 or similar, where the 9999 is the PID of the curl process — and isn't of practical significance.)
Given that the script is just one line of code that invokes another program, it would be possible to embed all that in the I4GL program. However, having an external shell script (or Perl script, or …) has merits of flexibility; you can edit it to log attempts, for example, without changing the I4GL code at all. One more file to distribute, but better flexibility — keep a separate script, even though it could all be embedded in the I4GL.
As Jonathan said "URLs didn't exist when I4GL was invented, amongst other things". What you will find is that the products that have grown to superceed Informix-4gl such as FourJs Genero will cater for new technologies and other things invented after I4GL.
Using FourJs Genero, the code below will do what you are after using the Informix 4gl syntax you are familiar with
IMPORT com
MAIN
-- Should succeed and display 1
DISPLAY validate_url("http://www.google.com")
DISPLAY validate_url("http://www.4js.com/online_documentation/fjs-fgl-manual-html/index.html#c_fgl_nf.html") -- link to some of the features added to I4GL by Genero
-- Should fail and display 0
DISPLAY validate_url("http://www.google.com/testing")
DISPLAY validate_url("http://www.google2.com")
END MAIN
FUNCTION validate_url(url)
DEFINE url STRING
DEFINE req com.HttpRequest
DEFINE resp com.HttpResponse
-- Returns TRUE if http request to a URL returns 200
TRY
LET req = com.HttpRequest.create(url)
CALL req.doRequest()
LET resp = req.getResponse()
IF resp.getStatusCode() = 200 THEN
RETURN TRUE
END IF
-- May want to handle other HTTP status codes
CATCH
-- May want to capture case if not connected to internet etc
END TRY
RETURN FALSE
END FUNCTION
In the recent Erlang R14, inets' file httpd.hrl has been moved from:
src/httpd.hrl
to:
src/http_server/httpd.hrl
The Erlang Web framework includes the file in several places using the following directive:
-include_lib("inets/src/httpd.hrl").
Since I'd love the Erlang Web to compile with both versions of Erlang (R13 and R14), what I'd need ideally is:
-ifdef(OLD_ERTS_VERSION).
-include_lib("inets/src/httpd.hrl").
-else.
-include_lib("inets/src/http_server/httpd.hrl").
-endif.
Even if it possible to retrieve the ERTS version via:
erlang:system_info(version).
That's indeed not possible at pre-processing time.
How to deal with these situations? Is the parse transform the only way to go? Are there better alternatives?
Not sure if you'll like this hackish trick, but you could use a parse transform.
Let's first define a basic parse transform module:
-module(erts_v).
-export([parse_transform/2]).
parse_transform(AST, _Opts) ->
io:format("~p~n", [AST]).
Compile it, then you can include both headers in the module you want this to work for. This should give the following:
-module(test).
-compile({parse_transform, erts_v}).
-include_lib("inets/src/httpd.hrl").
-include_lib("inets/src/http_server/httpd.hrl").
-export([fake_fun/1]).
fake_fun(A) -> A.
If you're on R14B and compile it, you should have the abstract format of the module looking like this:
[{attribute,1,file,{"./test.erl",1}},
{attribute,1,module,test},
{error,{3,epp,{include,lib,"inets/src/httpd.hrl"}}},
{attribute,1,file,
{"/usr/local/lib/erlang/lib/inets-5.5/src/http_server/httpd.hrl",1}},
{attribute,1,file,
{"/usr/local/lib/erlang/lib/kernel-2.14.1/include/file.hrl",1}},
{attribute,24,record,
{file_info,
[{record_field,25,{atom,25,size}},
{record_field,26,{atom,26,type}},
...
What this tells us is that we can use both headers, and the valid one will automatically be included while the other will error out. All we need to do is remove the {error,...} tuple and get a working compilation. To do this, fix the parse_transform module so it looks like this:
-module(erts_v).
-export([parse_transform/2]).
parse_transform(AST, _Opts) ->
walk_ast(AST).
walk_ast([{error,{_,epp,{include,lib,"inets/src/httpd.hrl"}}}|AST]) ->
AST;
walk_ast([{error,{_,epp,{include,lib,"inets/src/http_server/httpd.hrl"}}}|AST]) ->
AST;
walk_ast([H|T]) ->
[H|walk_ast(T)].
This will then remove the error include, only if it's on the precise module you wanted. Other messy includes should fail as usual.
I haven't tested this on all versions, so if the behaviour changed between them, this won't work. On the other hand, if it stayed the same, this parse_transform will be version independent, at the cost of needing to order the compiling order of your modules, which is simple enough with Emakefiles and rebar.
If you are using makefiles, you can do something like
ERTS_VER=$(shell erl +V 2>&1 | egrep -o '[0-9]+.[0-9]+.[0-9]+')
than match the string and define macro in erlc arguments or in Emakefile.
There is no other way, AFAIK.