Okay, checked [source code](https://github.com/python/cpython/blob/master/Lib/webbrowser.py) and `autoraise` is only supported on the Netscape family, the Galeon family, and Opera. (And I can make it work with any macOS GUI browser that is set to system default; don't really bother to send a patch.) Not very helpful.
By the way, another related feature is opening pages in the background (i.e., do not activate the browser window). If pages are opened in the background, you can just `1 <enter> 2 <enter> 3 <enter>`... then switch to the browser when you're ready to browse. However, I tested `webbrowser.open(url, autoraise=False)` and the results were very disappointing. On macOS it's using an AppleScript-based approach so I don't expect it to work (and it doesn't); I can easily workaround that with `open(1)`. On Ubuntu with Unity, `autoraise` also doesn't work, and I can't even find a workaround, as `xdg-open` and friends don't seem to have the capability of keeping the opened application in the background. Guess it's a dead end.
ohcount 3.0.0-g331
==================
- [x] Have you followed the [guidelines for contributing](https://github.com/Homebrew/homebrew-core/blob/master/CONTRIBUTING.md)?
- [x] Have you checked that there aren't other open [pull requests](https://github.com/Homebrew/homebrew-core/pulls) for the same formula update/change?
- [x] Have you built your formula locally with `brew install --build-from-source <formula>`, where `<formula>` is the name of the formula you're submitting?
- [x] Does your build pass `brew audit --strict <formula>` (after doing `brew install <formula>`)?
-----
This is an attempt to make ohcount more useful in the modern world.
The 3.0.0 release is just too old (from 2009) and doesn't recognize CoffeeScript, Go and Rust, among other languages. See https://github.com/blackducksoftware/ohcount/issues/45 (where I ask for a release) for details. I realized this after failing to count a project in Go a week ago, and have been using HEAD since then, but having to install HEAD to meet a basic expectation (being able to count Go) of a modern programmer is really bad user experience.
Judging from the fact that the last commit was made in 2014, and most PRs are left to rot without a reply, I don't expect any meaningful official response on blackducksoftware/ohcount#45, which has been sitting there for a week too. I'm taking the matter into my own hands here, but I'm not the first — openSUSE has been packaging `master~6` (see their [`ohcount-3.0.0.g312` package](https://build.opensuse.org/package/show/openSUSE:13.1/ohcount)) since 13.1 released in 2013, and slightly earlier revisions in earlier releases.
Bytecode has been replaced by wordcode in CPython 3.6, among other things; see [CPython bytecode changes](https://docs.python.org/3.6/whatsnew/3.6.html#cpython-bytecode-changes) in *What's New In Python 3.6*. For instance, `js2py.base.Empty.__code__.co_code` used to be `b'\x74\x00\x00\x64\x00\x00\x83\x01\x00\x53'`; now it's `b'\x74\x00\x64\x00\x83\x01\x53\x00'`.
I'm not familiar with bytecode/wordcode myself, but I skimmed [`wordcode.md`](https://github.com/abarnert/cpython/blob/wpy/Python/wordcode.md) and put together this quick patch for the bytecode reader, `js2py.utils.injector.instructions`:
```diff
diff --git a/js2py/utils/injector.py b/js2py/utils/injector.py
index 3ced868..2c724f7 100644
--- a/js2py/utils/injector.py
+++ b/js2py/utils/injector.py
@@ -2,6 +2,7 @@ __all__ = ['fix_js_args']
import types
import opcode
+import sys
import six
if six.PY3:
@@ -129,23 +130,38 @@ def append_arguments(code_obj, new_locals):
def instructions(code):
- if six.PY2:
- code = map(ord, code)
- i, L = 0, len(code)
- extended_arg = 0
- while i < L:
- op = code[i]
- i+= 1
- if op < opcode.HAVE_ARGUMENT:
- yield [op, None]
- continue
- oparg = code[i] + (code[i+1] << 8) + extended_arg
+ if sys.version_info < (3, 6):
+ if six.PY2:
+ code = map(ord, code)
+ i, L = 0, len(code)
extended_arg = 0
- i += 2
- if op == opcode.EXTENDED_ARG:
- extended_arg = oparg << 16
- continue
- yield [op, oparg]
+ while i < L:
+ op = code[i]
+ i+= 1
+ if op < opcode.HAVE_ARGUMENT:
+ yield [op, None]
+ continue
+ oparg = code[i] + (code[i+1] << 8) + extended_arg
+ extended_arg = 0
+ i += 2
+ if op == opcode.EXTENDED_ARG:
+ extended_arg = oparg << 16
+ continue
+ yield [op, oparg]
+ else:
+ i, L = 0, len(code)
+ extended_arg = 0
+ while i < L:
+ op = code[i]
+ oparg = code[i+1] + extended_arg
+ extended_arg = 0
+ i += 2
+ if op < opcode.HAVE_ARGUMENT:
+ yield [op, None]
+ elif op == opcode.EXTENDED_ARG:
+ extended_arg = oparg << 8
+ else:
+ yield [op, oparg]
def write_instruction(inst):
op, oparg = inst
```
I'm not sure if the endianness of the CPU architecture needs to be taken into account, but this reader should be correct for little-endian architectures like x86 and x64.
I tested this patch, unfortunately it only seems to work for basic cases, like the first few lines in the README example:
```py
# Adding Python built-in sum to the JS context:
>>> context = js2py.EvalJs({'python_sum': sum})
>>> js_code = '''
var a = 10
function f(x) {return x*x}
'''
>>> context.execute(js_code)
# Get value of variable a:
>>> context.a
10
# context.f behaves just like js function so you can supply more than 1 argument. '9'*'9' in javascript is 81.
>>> context.f('9', 0)
81
```
but fails with `SystemError: unknown opcode` in most cases. Apparently more (and probably more involved) work is needed.
Hint at new location of migrated formulae
=========================================
- [x] Have you followed the guidelines in our [Contributing](https://github.com/Homebrew/brew/blob/master/CONTRIBUTING.md) document?
- [x] Have you checked to ensure there aren't other open [Pull Requests](https://github.com/Homebrew/brew/pulls) for the same change?
- [x] Have you added an explanation of what your changes do and why you'd like us to include them?
- [x] Have you written new tests for your changes? [Here's an example](https://github.com/Homebrew/homebrew/pull/49031).
- [x] Have you successfully run `brew tests` with your changes locally?
-----
This is a partial implementation of https://github.com/Homebrew/brew-evolution/pull/15. Please read [the proposal](https://github.com/zmwangx/brew-evolution/blob/hint-at-new-location-of-migrated-formulae/015-hint-at-new-location-of-migrated-formulae.md), which was basically agreed upon. (Note that #1371 was also a step towards the goal.)
With this change:
```
$ brew info aeskeyfind
Error: No available formula with the name "aeskeyfind"
==> Searching for migrated formulae...
A deprecated formula named "aeskeyfind" has been migrated from homebrew/core to homebrew/boneyard.
A formula named "aeskeyfind" has been migrated from zmwangx/old to zmwangx/new.
```
(`zmwangx/old` has a placeholder `tap_migrations.json` with `{"aeskeyfind": "zmwangx/new"}`.)
```
$ brew install aeskeyfind
Error: No available formula with the name "aeskeyfind"
==> Searching for migrated formulae...
A deprecated formula named "aeskeyfind" has been migrated from homebrew/core to homebrew/boneyard.
A formula named "aeskeyfind" has been migrated from zmwangx/old to zmwangx/new.
```
```
$ brew info r
Error: No available formula with the name "r"
==> Searching for migrated formulae...
A formula named "r" has been migrated from caskroom/cask to homebrew/science.
```
```
$ brew install r
Error: No available formula with the name "r"
==> Searching for migrated formulae...
A formula named "r" has been migrated from caskroom/cask to homebrew/science.
```
```
$ brew info aeskeyfin
Error: No available formula with the name "aeskeyfin"
==> Searching for migrated formulae...
```
```
$ brew install aeskeyfin
Error: No available formula with the name "aeskeyfin"
==> Searching for migrated formulae...
==> Searching for similarly named formulae...
Error: No similarly named formulae found.
==> Searching taps...
Error: No formulae found in taps.
```