Lua-openssl - all openssl submodules are nil - lua

I'm trying to follow the instructions from the readme file here: https://github.com/zhaozg/lua-openssl
This is a basic program I'm running:
openssl = require 'openssl'
inspect = require 'inspect'
print(inspect(openssl.cipher))
Only 'nil' gets printed to the terminal.
If I try to inspect the "openssl" object, I get the following output:
{
NO_IDEA = true,
NO_MD2 = true,
NO_MDC2 = true,
NO_RC5 = true,
NO_SCTP = true,
SHLIB_VERSION_HISTORY = "",
SHLIB_VERSION_NUMBER = "1.1",
SSLEAY_BUILT_ON = 2,
SSLEAY_CFLAGS = 1,
SSLEAY_DIR = 4,
SSLEAY_PLATFORM = 3,
SSLEAY_VERSION = 0,
SSLEAY_VERSION_NUMBER = 269484159,
VERSION_NUMBER = 269484159,
VERSION_TEXT = "OpenSSL 1.1.0g 2 Nov 2017",
version = <function 1>
}
Any ideas? What am I doing wrong?

The version that comes with your system may not have yet the cipher module, or may be another binding for openssl.
Check the modules that your version has in the folder where lua openssl is located, in my system is in /usr/local/share/lua/5.1/openssl/, there is also a file outside the folder /usr/local/share/lua/5.1/openssl.lua and the shared object in /usr/local/lib/lua/5.1/_openssl.so but in yours it may vary.
Backup those files to another place just to make sure. Remove them and install the latest version with luarocks.
luarocks install openssl
Luarocks will probably install the new shared object in /usr/local/lib/lua/5.1/. If the name of the module installed has the version in the name like openssl_0_7_7_0-openssl.so rename it to openssl.so.

Related

How Set Neovim startup directory to Desktop in windows?

I'm using Astro vim distro with neovide. every time I launch neovide / neovim-qt it launches in the directory it's installed on!
OS: windows 10
[Astrovim starting location][1]
[using windows shortcut properties to set start in location][2]
[1]: https://i.stack.imgur.com/ZvXfp.png
[2]: https://i.stack.imgur.com/IEl4N.png
is there a way to set startup location in options.lua ?
Try following code in your configuration file, it make use of vim\neovim autocommands feature:
local os = require("os")
local path_to_desktop = os.getenv("USERPROFILE") .. "\\Desktop"
local vim_enter_group = vim.api.nvim_create_augroup("vim_enter_group", { clear = true })
vim.api.nvim_create_autocmd(
{"VimEnter"},
{ pattern = "*", command = "cd " .. path_to_desktop, group = vim_enter_group }
)
nvim_create_autocmd and nvim_create_group are described in neovim docs. Use :h nvim_create_autocmdto find out more.

Bazel: java_library character encoding via javacopts not working?

I have an external source repository that apparently stores some source files using ISO-8859-1 character encoding. I am having trouble getting javac to change from default UTF-8 to ISO-8859-1 when invoked through Bazel.
I'm fetching the external repository via Bazel and can determine the charset of the fetched files:
> cd bazel-PROJECT/external/third-party/src
> file -i LibraryCode.java
LibraryCode.java: text/x-c; charset=iso-8859-1
Building the external sources via Bazel's java_library, or attempting to compile external repository source files via javac directly from the command line fails with (expected):
error: unmappable character for encoding UTF8
Attempting to use javac's -encoding argument solves the compilation issue when used from the command line against the external repository files fetched by Bazel:
> javac -encoding iso-8859-1 LibraryCode.java
However, I've been unable to successfully pass the -encoding option to javac via Bazel.
I've tried so far:
setting the javacopts in java_library rule
setting --javacopt from Bazel's command line
declaring java_toolchain rule with encoding ISO-8859-1 and using it with --java_toolchain from Bazel's command line.
None of these attempts got around the charset mismatch and compiler error.
1) repository_rule build_file: thirdparty.BUILD
java_library(
name = "thirdparty",
srcs = glob(["src/**/*.java"]),
javacopts = ["-encoding iso-8859-1"],
visibility = ["//visibility:public"]
)
2) Bazel command line:
> bazel build --javacopt="-encoding iso-8859-1" target
3) Defining Java toolchain target with encoding setting:
java_toolchain(
name = "toolchain",
bootclasspath = ["#bazel_tools//tools/jdk:bootclasspath"],
encoding = "iso-8859-1",
extclasspath = ["#bazel_tools//tools/jdk:extdir"],
forcibly_disable_header_compilation = 0,
genclass = ["#bazel_tools//tools/jdk:GenClass_deploy.jar"],
header_compiler = ["#bazel_tools//tools/jdk:turbine_deploy.jar"],
ijar = ["#bazel_tools//tools/jdk:ijar"],
javabuilder = ["#bazel_tools//tools/jdk:JavaBuilder_deploy.jar"],
javac = ["#bazel_tools//third_party/java/jdk/langtools:javac_jar"],
javac_supports_workers = 1,
jvm_opts = [
"-XX:+TieredCompilation",
"-XX:TieredStopAtLevel=1",
],
misc = [
"-XDskipDuplicateBridges=true",
],
singlejar = ["#bazel_tools//tools/jdk:SingleJar_deploy.jar"],
source_version = "8",
target_version = "8",
visibility = ["//visibility:public"]
)
All end up with error: unmappable character for encoding UTF8.
What is the mistake I am making in setting the javac encoding via Bazel?
I can try to work around the issue by converting the external repository source files via iconv but I'd prefer solving it via javac's encoding setting as intended.
Follow Up
The java_toolchain encoding not getting recognized appears to be a bug. I've a preliminary fix for this on my local copy of Bazel -- java_toolchain approach to changing charset (option #3 above) appears to work.
Tracking this issue and a proposed fix in: #2926
Unfortunately there is no good way to do that from the command line / target based. You have to write a java_toolchain and point to it. Deriving the one from bazel that would result in:
java_toolchain(
name = "toolchain",
bootclasspath = ["#bazel_tools//tools/jdk:bootclasspath"],
encoding = "iso-8859-1",
extclasspath = ["#bazel_tools//tools/jdk:extclasspath"],
forcibly_disable_header_compilation = 0,
genclass = ["#bazel_tools//tools/jdk:genclass"],
header_compiler = ["#bazel_tools//tools/jdk:turbine"],
ijar = ["#bazel_tools//tools/jdk:ijar"],
javabuilder = ["#bazel_tools//tools/jdk:javabuilder"],
javac = ["#bazel_tools//third_party/java/jdk/langtools:javac_jar"],
javac_supports_workers = 1,
jvm_opts = [
"-XX:+TieredCompilation",
"-XX:TieredStopAtLevel=1",
],
misc = [
"-XDskipDuplicateBridges=true",
],
singlejar = ["#bazel_tools//tools/jdk:SingleJar_deploy.jar"],
source_version = "8",
target_version = "8",
)
(you might want to change the singlejar target to the C++ binary for performance reason: #bazel_tools//tools/jdk:singlejar IIRC)
Then you can point to that toolchain with --java_toolchain=//my:toolchain (see the java_toolchain flag)

How to rebuild uwsgi with xml = True

I have installed uwsgi in my server. But when I can't use command uwsgi -x django_socket.xml.
It said
uwsgi: invalid option -- 'x'
getopt_long() error
Someone told me that i should rebuild it cause i build uwsgi without xml support. Then i check the uwsgi docs.
Then i downloads the Django-2.0.4.tar.gz again, cause i remove it after i installed it last time.
And i rebuild it with command:
python uwsgiconfig.py --build
And i saw a report
pcre = True
kernel = Linux
malloc = libc
execinfo = False
ifaddrs = True
ssl = True
zlib = True
locking = pthread_mutex
plugin_dir = .
timer = none
yaml = embedded
json = False
filemonitor = inotify
routing = True
debug = False
capabilities = False
xml = False
event = epoll
but it seems does't work, the xml still false. What should i do?
install libxml2 or expat development headers and re-run make. The build system will automatically detect their availability

HHVM+Hacklang: errors/warnings output into browser

Is there any way to tell HHVM to output Hacklang warnings and errors into the browser? Something like PHP does with enabled display_errors, display_startup_errors and error_reporting set to E_ALL
HHVM version:
$ php -v
HipHop VM 3.1.0-dev+2014.04.09 (rel)
Compiler: heads/master-0-g4fc811c64c23a3686f66a2bea80ba47f3eaf9f3d
Repo schema: 79197c935790c0b9c9cb13566c3e727ace368117
I've tried the following config:
$ cat /etc/hhvm/php.ini
; php options
display_startup_errors = On
error_reporting = E_ALL
display_errors = On
; hhvm specific
hhvm.log.level = Warning
hhvm.log.always_log_unhandled_exceptions = true
hhvm.log.runtime_error_reporting_level = 8191
hhvm.mysql.typed_results = false
And :
$ cat /etc/hhvm/server.ini
; php options
pid = /var/run/hhvm/pid
; hhvm specific
hhvm.server.port = 9000
hhvm.server.type = fastcgi
hhvm.server.default_document = index.php
hhvm.log.level = Warning
hhvm.log.always_log_unhandled_exceptions = true
hhvm.log.runtime_error_reporting_level = 8191
hhvm.log.use_log_file = true
hhvm.log.file = /var/log/hhvm/error.log
hhvm.repo.central.path = /var/run/hhvm/hhvm.hhbc
hhvm.mysql.typed_results = false
hhvm.debug.full_backtrace = true
hhvm.debug.server_stack_trace = true
hhvm.debug.server_error_message = true
hhvm.debug.translate_source = true
tl;dr: You can't.
The thing to keep in mind here is that the typechecker does a static analysis of your code while the PHP errors you talk about show up at runtime. If this was C++, you could compare the Hack typechecker errors with the errors during the compile step - so Hack tells you things that are wrong before the code even runs.
The trick is to use either the vim or emacs plugins which warn you of errors as you save the file, or use hh_client from the terminal, or build a plugin for your favorite IDE (feel free to send pull requests!). hh_client --json gives an easy to parse output if you want to build a plugin for Sublime Text, or Eclipse or whatever you want.
Note that some errors are runtime errors, while some aren't. Function args as well as return types should throw exceptions at runtime for the latest HHVM build for example. The problem there is that you only see those errors when you hit a certain code-path. The beauty of Hack is that it errors for all the problems in your code, even if it's a code-path you may not test at runtime.

RVM error: "Unknown ruby interpreter version" when trying to verify an .rvmrc file [closed]

This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 9 years ago.
I'm trying to set up my first .rvmrc file for one of my projects. I created a .rvmrc file in the root of the project folder with the following contents:
rvm 1.9.2p180#projectr3
Now when I list gemsets I'm asked to verify the file:
$ rvm gemset list
gemsets for ruby-1.9.2-p180 (found in /Users/meltemi/.rvm/gems/ruby-1.9.2-p180)
global
=> projectr3
rails3
...
===============================================================
= NOTICE: =
===============================================================
= RVM has encountered a new or modified .rvmrc file in the =
= current working directory. Resource files may execute =
= arbitrary instructions, so RVM will not use an .rvmrc file =
= that has not been explicitly marked as 'trusted.' =
= =
= Examine the contents of this file carefully to be sure the =
= contents are good before trusting it! =
= =
= You will now be given a chance to read the .rvmrc file =
= before deciding whether or not its contents are safe. After =
= reading the file, you will be prompted 'yes or no' to set =
= the trust level for this particular version of the file. =
= =
= Note: You will be re-prompted each time the .rvmrc file =
= changes, and may change the trust setting manually at any =
= time. =
= =
= Press 'q' to exit the reader when finished reading the file =
===============================================================
(press enter to review the .rvmrc file)
rvm 1.9.2p180#projectr3
Examining /Users/meltemi/rails/myproject/.rvmrc complete.
================================================================
= Trusting an .rvmrc file means that whenever you cd into this =
= directory, RVM will run this .rvmrc script in your shell. =
= =
= If the contents of the file change, you will be re-prompted =
= to review the file and adjust its trust settings. You may =
= also change the trust settings manually at any time with =
= the 'rvm rvmrc' command. =
= =
= Now that you have examined the contents of the file, do you =
= wish to trust this particular .rvmrc? =
================================================================
(yes or no) > yes
ERROR: Unknown ruby interpreter version: '1.9.2p180'
bigmac:myproject meltemi$
What does this ERROR: Unknown ruby interpreter version: '1.9.2p180' mean?
FWIW - These are my rubies:
$ rvm list
rvm rubies
ruby-1.9.2-p0 [ x86_64 ]
ruby-1.9.2-p136 [ x86_64 ]
=> ruby-1.9.2-p180 [ x86_64 ]
ruby-1.9.2-rc2 [ x86_64 ]
Looks like a typo in your .rvmrc file. Perhaps it should read:
environment_id="rvm 1.9.2-p180#projectr3"
I think you are missing the dash before the p180.
ian.

Resources