| #!/bin/sh | |
| # | |
| # Copyright (c) 2016 Babak Farrokhi. All rights reserved. | |
| # | |
| # Redistribution and use in source and binary forms, with or without | |
| # modification, are permitted provided that the following conditions | |
| # are met: | |
| # | |
| # 1. Redistributions of source code must retain the above copyright |
| #![allow(non_camel_case_types)] | |
| use std::mem; | |
| // The Situation | |
| struct ffi_Object; | |
| type ffi_Callback = unsafe extern fn(*mut ffi_Object) -> u32; | |
| extern fn ffi_push_callback(_: *mut ffi_Object, _: ffi_Callback) {} | |
| // Dummy wrapper | |
| struct Object { |
Hello guys,
Continuing from this guide to building ffmpeg and libav with NVENC and VAAPI enabled, this snippet will cover advanced options that you can use with ffmpeg and libav on both NVENC and VAAPI hardware-based encoders.
For ffmpeg:
I recently had several days of extremely frustrating experiences with service workers. Here are a few things I've since learned which would have made my life much easier but which isn't particularly obvious from most of the blog posts and videos I've seen.
I'll add to this list over time – suggested additions welcome in the comments or via twitter.com/rich_harris.
Chrome 51 has some pretty wild behaviour related to console.log in service workers. Canary doesn't, and it has a load of really good service worker related stuff in devtools.
| chip "nct6793-isa-0290" | |
| label in0 "CPUVCORE" | |
| compute in0 @*2, @/2 | |
| label in1 "VIN0" | |
| label in2 "AVCC" | |
| label in3 "3VCC" | |
| label in4 "VIN1" | |
| label in5 "VIN2" | |
| label in6 "VIN3" | |
| label in7 "3VSB" |
| test: ipv6-parse-test | |
| ./ipv6-parse-test | |
| ipv6-parse-test: | |
| $(CC) -o ipv6-parse-test ipv6-parse-test.cpp | |
| clean: | |
| rm -f ipv6-parse-test | |
| .PHONY: clean |
With the release of hoogle5, we can now hoogle all local packages.
This let us implement stack hoogle, which is on the master
branch of stack, but is not yet on a stack release. We'd like you to
try it out before we do!
To upgrade to the latest stack from git, use:
| // This is free and unencumbered software released into the public domain. | |
| // | |
| // Anyone is free to copy, modify, publish, use, compile, sell, or | |
| // distribute this software, either in source code form or as a compiled | |
| // binary, for any purpose, commercial or non-commercial, and by any | |
| // means. | |
| // | |
| // In jurisdictions that recognize copyright laws, the author or authors | |
| // of this software dedicate any and all copyright interest in the | |
| // software to the public domain. We make this dedication for the benefit |
ℹ️ Please note this research is from 2016 when Opera has first added their browser "VPN", even before the "Chinese deal" was closed. They have since introduced some real VPN apps but this below is not about them.
🕵️ Some folks also like to use this article to show a proof that the Opera browser is a spyware or that Opera sells all your data to 3rd parties or something like that. This article here doesn't say anything like that.
When setting up (that's immediately when user enables it in settings) Opera VPN sends few API requests to https://api.surfeasy.com to obtain credentials and proxy IPs, see below, also see The Oprah Proxy.
The browser then talks to a proxy de0.opera-proxy.net (when VPN location is set to Germany), it's IP address can only be resolved from within Opera when VPN is on, it's 185.108.219.42 (or similar, see below). It's an HTTP/S proxy which requires auth.
An expression beginning with a left arrow (<-) inside a do block statement is desugared to a monadic binding. This is syntactically a superset of existing Haskell, including extensions. It admits a clean notation that subsumes existing patterns and comes with few downsides.
do
f (<- x) (<- y)
-- ===