HHVM+Hacklang: errors/warnings output into browser - hhvm

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.

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.

How to build a NixOps deployment on hydra

Deploying my NixOps machines takes alot of time, as packages need to build. I want to do the building regularly on my trusted private Hydra instance.
My current approach involves this release.nix file, but it doesn't work out so well.
{ nixpkgs ? <nixpkgs>, onlySystem ? true, extraModules ? [] }:
let
nixos = import "${nixpkgs}/nixos";
buildEnv = conf: (nixos {
configuration = conf;
});
buildTarget = m: let build = buildEnv (buildConf m); in
if onlySystem then build.system else build.vm;
buildConf = module: { ... }:
{
imports = [ module ] ++ extraModules;
};
in
{
machine1 = buildTarget ./machine1/configuration.nix;
machine2 = buildTarget ./machine2/configuration.nix
machine3 = buildTarget ./machine3/configuration.nix
machine4 = buildTarget ./machine4/configuration.nix
}
I don't really understand this code, as I copied it from here.
This builds fine if I run nix-build release.nix locally, but on hydra I never get a full build. Sometimes builds don't dequeue (they just don't get build), sometimes they fail with various error messages. As nothing of the hydra problems are reproducible (beside the fact, that I never get a full build), I wonder what the best practice for building a NixOps deployment is.
Please note, that I have unfree packages in my deployment. The option nixpkgs.config.allowUnfree = true; is set on the hydra server.
This is not a question about my hydra failures, but about what would be a good way to build a NixOps deployment with Hydra CI.
As far as I know, there is no way to make this super easy. Your code looks ok, but my method is a slightly different. I only build the toplevel attribute and I construct the NixOS configuration differently.
I build NixOS 'installations' from inside Nix using something like:
let
modules = [ ./configuration.nix ];
nixosSystem = import (pkgs.path + "/nixos/lib/eval-config.nix") {
inherit (pkgs) system;
inherit modules;
};
in
nixosSystem.config.system.build.toplevel

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

uWSGI as a standalone http server with lua

I'm trying to set up uWSGI to run as a standalone server running a simple LUA script(right now, as a POC, using the hello world from http://uwsgi-docs.readthedocs.org/en/latest/Lua.html).
Here's my uwsgi.ini file:
[uwsgi]
master = true
workers = 1
threads = 8
listen = 4096
max-request = 512
pidfile = /uwsgi/logs/uwsgi.pid
procname-master = uWSGI master
auto-procname = true
lua = /uwsgi/hello.lua
socket-timeout = 30
socket = /uwsgi/uwsgi_1.sock
http = 127.0.0.1:80
http-to = /uwsgi/uwsgi_1.sock
When sending a web request, an empty response is received, and uWSGI process outputs:
-- unavailable modifier requested: 0 --
I've read this usually means a plugin is missing, however, LUA plugin is installed, and when doing the same but through NGINX everything works fine, which means there's no problem loading LUA.
Any help please?
Thanks.
Somebody told me I had to add http-modifier1 = 6 and now it works.
Still don't understand what does '6' mean, but whatever.

Resources