WIP: revamping code generation

There are a number of issues that it makes sense to tackle all at once:

The potential for name collision as described in #826
Decent amount of code spent in the intro and outro of modules.
We add all modules to Elm such that they are public to the world.
Make it work with Closure Compiler better
We want to have nice support for node
The bad error messages when folks say something like Elm.fullscreen(Erm.Main) in JS
We rebuild a decent amount of stuff for each "instance" of Elm as described in #888

With @JoeyEremondi working on dead code elimination, it seems like a reasonable time to start addressing these things in one pass. The point of this issue is to describe the plan for this in a coherent way.
Format for Generated Elm Code
When elm-make spits out a hunk of JS, the general format I have in mind is like this:
var Elm = function() {
    var elm-lang$core$Basics$fst = ...
    var elm-lang$core$Basics$snd = ...
    var elm-lang$core$Basics$degrees = ...
    var evancz$elm-html$Html$div = ...
    var evancz$elm-html$Html$text = ...
    ...

    return {
        fullscreen: ...
        embed: ...
        ...
    };
}();

All top level declarations in the whole project are turned into fully qualified names. There are no more module boundaries in generated code. So when I want to refer to Html.div I refer to evancz$elm-html$Html$div in the generated JS. And when we do dead code elimination, it will just mean leaving out some subset of these definitions.
This will address points 1, 2, and 3 entirely (name collision, intro/outro, exposing too much). I suspect it will also go a very long way with point 4 about Closure Compiler. One of the big problems we had there was that if you expose an object and use one field from it, you gotta keep all the fields. This is no longer an issue with module exports, so I am hoping things will work a lot nicer. We could at least pass things through there to do variable renaming and get nicer names.
Initializing an Elm instance
Right now initializing Elm code has certain issues (points 5 and 6) that it'd be nice to improve. We can conditionally generate the headers needed to get things working with node, that's not too crazy. The big change here would be in how we initialize Elm widgets.
// generated JS from the Elm code

var app = Elm.fullscreen('Main');

Notice that we give a string version of the module name we want. This means if there is some misspelling, we can give an error like "Cannot find module Main, did you mean one of these? ..." and then point to some other resources on what might be going wrong.
We also only have a very small API coming off of the Elm object now.
Reducing overhead of many "instances"
In the vast majority of cases, it is safe to share values across every instance that is out there. This is true of all non-signal code. When it comes to Mouse.position we need to be more careful because it matters where you are embedded.
Right now I am purposely leaving the "native format" unspecified, but it would make sense to me to have certain kinds of native code. The categories might just need to be pure/impure and we need to duplicate the impure parts for each instance but nothing else. If things depend on impure things, they also need to get duplicated. It should not be too hard to have an impure thing infect its dependencies.
Plan
To get this chunk of stuff done, it makes sense to break it into chunks in this order:

[ ] Add package information to the AST.Module.Interface record. We need to know the user and package name for every module to make canonicalization truly canonical and solve #826. This should be a PR of its own.
[ ] Make some tweaks to the canonicalization code to make uses of top-level values point to the fully qualified version, so Canonical Local "x" becomes Canonical (Module "Here") "x" and we generate the correct code.
[ ] Modify elm-compiler and elm-make to spit out code in the new format described above, with no module boundaries. The existing core and native stuff will not work with this. That is fine, we will rebuild them.
[ ] See how this interacts with Closure Compiler. Are there any bad problems?
[ ] Plan out how native code needs to fit into this.
[ ] Get core using the new format
[ ] Start doing dead code elimination on the whole thing

Nitpick: You'll need to turn dashes into underscores, e.g. elm-lang into elm_lang.
Question: How does this handle unexported values in modules? Are they hidden somehow? Or is the hiding at name-resolution-time?

What happens if there are multiple modules running in a page and they are using different versions of some library? Not sure how this interacts with the discussion of multiple instances, or if version numbers need to be added to the fully-qualified identifiers of values.

I think that would be an error right now, since elm-make needs a consistent
set of dependencies? But it's definitely good to keep in mind.
On Tue, Aug 25, 2015 at 8:40 AM, Pete Vilter<EMAIL_ADDRESS>wrote:

What happens if there are multiple modules running in a page and they are
using different versions of some library? Not sure how this interacts with
the discussion of multiple instances, or if version numbers need to be
added to the fully-qualified identifiers of values.
—
Reply to this email directly or view it on GitHub
https://github.com/elm-lang/elm-compiler/issues/1024#issuecomment-134633898
.

@vilterp That is not a problem because there is a closure around the whole app. This only removes the closure between modules, not between Elm and the outside world.

@vilterp, @laszlopandy is correct that it's all in a closure, so they won't interfere with anything else in the page. @JoeyEremondi is also correct that it'd be impossible to build a single closure that had multiple versions of the same thing.
@mgold, since everything will have a canonical name, it actually does not matter if "unexported values" are available. We know from the checks in the compiler that the module boundaries are respected. Those boundaries do not need to be replicated in the generated code because no one can write a new function that refers to a "hidden" value.

I opened #1025 about what to do with hyphens. I am not sure how to do that yet.

It looks like this does nothing about #873 (and may make it worse!). If codegen is changing this much, it may be possible to fix that bug at the same time.

I opened https://github.com/elm-lang/elm-compiler/issues/1029 about JS module compatibility.

It doesn't solve #873, but I don't think it will make it worse. I've been
working on reference analysis for DeadCodeElimination, so extending that to
check for self-reference not across lambdas should be not to hard.
On Wed, Aug 26, 2015 at 9:33 AM, Richard Feldman<EMAIL_ADDRESS>wrote:

I opened #1029 https://github.com/elm-lang/elm-compiler/issues/1029
about JS module compatibility.
—
Reply to this email directly or view it on GitHub
https://github.com/elm-lang/elm-compiler/issues/1024#issuecomment-135096265
.

I believe @laszlopandy's suggestion of "specify main in elm-package.json" would be a better fix for "The bad error messages when folks say something like Elm.fullscreen(Erm.Main) in JS" because it eliminates that class of errors.
In that world you'd just call Elm.fullscreen() and it would work, because the notion of what main to run would have been already incorporated into the compiled output, and verified at compile time.

Richard, not if you have multiple mains. Which apparently circuit hub needs.
That's why I promised elm-package.json has a list of main modules.
On Wednesday, August 26, 2015, Richard Feldman<EMAIL_ADDRESS>wrote:

I believe @laszlopandy https://github.com/laszlopandy's suggestion of
"specify main in elm-package.json" would be a better fix for "The bad
error messages when folks say something like Elm.fullscreen(Erm.Main) in
JS" because it eliminates that class of errors.
In that world you'd just call Elm.fullscreen() and it would work, because
the notion of what main to run would have been already incorporated into
the compiled output, and verified at compile time.
—
Reply to this email directly or view it on GitHub
https://github.com/elm-lang/elm-compiler/issues/1024#issuecomment-135100190
.

I'm curious if multiple mains are a strict "must have" there, or just the easiest way to implement given current tools?

@rehno-lindeque, I know you were building multiple mains in one call to elm-make. Folks are discussing some changes to elm-package.json that might make this easier to specify. Everyone, please continue this discussion on https://github.com/elm-lang/elm-make/issues/49.
@rtfeldman and others, please try to self police the curation stuff described here when possible.

Argh, sorry about that. Should have made a separate issue.

No worries, it's not an immediately intuitive way to do things (took me 3 years to think of it) so I expect I'll be adding reminders like that for a while ;)

Done enough with 0.17. Makes sense to manage DCE as a separate thing as it is more complicated than "just doing it" as discussed with @justinmanley yesterday!


Update sandbox.rst

Use the same option in the virtualenv command as the mkvirtualenv command uses.
apt-get is nowadays shortened to apt.
Might be helpful to advise to run
sudo apt update && sudo apt upgrade
before.

I also needed to run
sudo apt install build-essential
sudo apt install npm
sudo apt install libpq-dev
sudo apt install postgresql-common
(running Ubuntu 18.04 via WSL on Windows10)


Modify OpenHistoricalTiles vectiles schema to ingest borders

Broken out from #35, possibly done by either Seth or Gregor after Seth does #45. Once 45 is done we can reconsider who has more context + availability.

See June 10 commits for this work https://github.com/OpenHistoricalMap/openmaptiles/commit/9799ecc7dfa9756faf36f33791161e6a1d5dca3c


ghc810x: remove obsolete overrides (2/x)

Motivation for this change
Remove obsolete overrides on the following haskellPackages:
feed: -doJailbreak
hashable: -doJailbreak
parallel: -doJailbreak
regex-base: -doJailbreak
regex-compat: -doJailbreak
Part of https://github.com/NixOS/nixpkgs/issues/86500
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build haskell.packages.ghc8101.feed
@GrahamcOfBorg build haskell.packages.ghc8101.hashable
@GrahamcOfBorg build haskell.packages.ghc8101.parallel
@GrahamcOfBorg build haskell.packages.ghc8101.regex-base
@GrahamcOfBorg build haskell.packages.ghc8101.regex-compat

Looks good, thanks!


Master Script

Currently we have three separate tools to produce the data logs:

The GitHub project download (Java)

The git log producer (python)

The git log parser (python)

We need a master script that will link the three together so users need only to run one script.

gitcproc.py fulfills this role and is described on the README.  It is open to parallelization, but we can open a new issue for that later.


Version "undefined" after install via PIP

After an install with pip install hydrachain on a fresh env on Linux hostname 3.13.0-32-generic #57-Ubuntu
(newer)heiko@TTVM148:~$ hydrachain
Usage: hydrachain [OPTIONS] COMMAND [ARGS]...

  Welcome to HydraChain/vundefined/linux2/py2.7.6

Expected: Version number reported
Experienced: 'undefined' was reported
(newer)heiko@TTVM148:~$ pip show hydrachain
---
Metadata-Version: 2.0
Name: hydrachain
Version: 0.3.0

Could not reproduce. Installing in clean venv results in HydraChain/v0.3.0/linux2/py2.7.10 for me.
Please report:
´´´
which hydrachain
python -c "import hydrachain; print hydrachain.file"
´´´
My assumption: your pypi/pip install is shadowed by a local installation..?

Can't reproduce it either.
The only way I can think of this could happen is if the code is run from a source tarball (not a git checkout) without running  pip install -e . first.

I'm observing the same problem after upgrading hydrachain:
(local) ~ % hydrachain
Usage: hydrachain [OPTIONS] COMMAND [ARGS]...

  Welcome to HydraChain/v0.1.17/linux2/py2.7.9

Options:
  --profile [morden|frontier]  Configuration profile.  [default: morden]
  -C, --Config TEXT            Alternative config file
  -c TEXT                      Single configuration parameters
			       (<param>=<value>)
  -d, --data-dir TEXT          data directory  [default:
			       /home/ralf/.config/pyethapp]
  -l, --log_config TEXT        log_config string: e.g. ":info,eth:debug
			       [default: :info]
  --log-json / --log-no-json   log as structured json output
  --log-file PATH              Log to file instead of stderr.
  -b, --bootstrap_node TEXT    single bootstrap_node as
			       enode://pubkey@host:port
  -m, --mining_pct INTEGER     pct cpu used for mining
  --unlock TEXT                Unlock an account (prompts for password)
  --password FILENAME          path to a password file
  --help                       Show this message and exit.

Commands:
  account      Manage accounts.
  blocktest    Start after importing blocks from a file.
  config       Show the config
  export       Export the blockchain to FILE.
  import       Import blocks from FILE.
  run          Start the client ( --dev to stop on error)
  rundummy     run in a zero config default configuration
  runlocal     run in a zero config default configuration
  runmultiple  run multiple nodes in a zero config default...
(local) ~ % pip install -U hydrachain
Collecting hydrachain
  Downloading hydrachain-0.3.0-py2.py3-none-any.whl (49kB)
    100% |████████████████████████████████| 51kB 126kB/s
Requirement already up-to-date: simpy in ./local/lib/python2.7/site-packages (from hydrachain)
Requirement already up-to-date: rlp>=0.4.3 in ./local/lib/python2.7/site-packages (from hydrachain)
Requirement already up-to-date: c-secp256k1==0.0.8 in ./local/lib/python2.7/site-packages (from hydrachain)
Requirement already up-to-date: serpent in ./local/lib/python2.7/site-packages (from hydrachain)
Requirement already up-to-date: pytest==2.8.2 in ./local/lib/python2.7/site-packages (from hydrachain)
Collecting pyethapp>=1.0.11 (from hydrachain)
  Downloading pyethapp-1.2.1-py2.py3-none-any.whl (331kB)
    100% |████████████████████████████████| 337kB 136kB/s
Requirement already up-to-date: bitcoin==1.1.39 in ./local/lib/python2.7/site-packages (from hydrachain)
Collecting cffi>=1.2.1 (from c-secp256k1==0.0.8->hydrachain)
  Downloading cffi-1.6.0.tar.gz (397kB)
    100% |████████████████████████████████| 399kB 134kB/s
Requirement already up-to-date: py>=1.4.29 in ./local/lib/python2.7/site-packages (from pytest==2.8.2->hydrachain)
Requirement already up-to-date: gipc==0.4.0 in ./local/lib/python2.7/site-packages (from pyethapp>=1.0.11->hydrachain)
Requirement already up-to-date: pbkdf2 in ./local/lib/python2.7/site-packages (from pyethapp>=1.0.11->hydrachain)
Requirement already up-to-date: wheel in ./local/lib/python2.7/site-packages (from pyethapp>=1.0.11->hydrachain)
Collecting ethereum>=1.2.0 (from pyethapp>=1.0.11->hydrachain)
  Downloading ethereum-1.3.0.tar.gz (112kB)
    100% |████████████████████████████████| 122kB 134kB/s
Collecting requests (from pyethapp>=1.0.11->hydrachain)
  Downloading requests-2.10.0-py2.py3-none-any.whl (506kB)
    100% |████████████████████████████████| 512kB 135kB/s
Collecting werkzeug (from pyethapp>=1.0.11->hydrachain)
  Downloading Werkzeug-0.11.9-py2.py3-none-any.whl (306kB)
    100% |████████████████████████████████| 307kB 991kB/s
Collecting ipython>=3.0.0 (from pyethapp>=1.0.11->hydrachain)
  Downloading ipython-4.2.0-py2-none-any.whl (736kB)
    100% |████████████████████████████████| 737kB 113kB/s
Requirement already up-to-date: CodernityDB in ./local/lib/python2.7/site-packages (from pyethapp>=1.0.11->hydrachain)
Requirement already up-to-date: statistics in ./local/lib/python2.7/site-packages (from pyethapp>=1.0.11->hydrachain)
Collecting gevent==1.1.0 (from pyethapp>=1.0.11->hydrachain)
  Downloading gevent-1.1.0-cp27-cp27mu-manylinux1_x86_64.whl (1.3MB)
    100% |████████████████████████████████| 1.3MB 715kB/s
Requirement already up-to-date: leveldb in ./local/lib/python2.7/site-packages (from pyethapp>=1.0.11->hydrachain)
Requirement already up-to-date: scrypt in ./local/lib/python2.7/site-packages (from pyethapp>=1.0.11->hydrachain)
Requirement already up-to-date: decorator in ./local/lib/python2.7/site-packages (from pyethapp>=1.0.11->hydrachain)
Collecting click (from pyethapp>=1.0.11->hydrachain)
  Downloading click-6.6.tar.gz (283kB)
    100% |████████████████████████████████| 286kB 136kB/s
Collecting lmdb (from pyethapp>=1.0.11->hydrachain)
  Downloading lmdb-0.89.tar.gz (149kB)
    100% |████████████████████████████████| 153kB 144kB/s
Collecting devp2p>=0.7.2 (from pyethapp>=1.0.11->hydrachain)
  Downloading devp2p-0.7.2-py2.py3-none-any.whl (83kB)
    100% |████████████████████████████████| 92kB 137kB/s
Requirement already up-to-date: pyyaml in ./local/lib/python2.7/site-packages (from pyethapp>=1.0.11->hydrachain)
Requirement already up-to-date: pexpect in ./local/lib/python2.7/site-packages (from pyethapp>=1.0.11->hydrachain)
Requirement already up-to-date: pycparser in ./local/lib/python2.7/site-packages (from cffi>=1.2.1->c-secp256k1==0.0.8->hydrachain)
Requirement already up-to-date: repoze.lru in ./local/lib/python2.7/site-packages (from ethereum>=1.2.0->pyethapp>=1.0.11->hydrachain)
Requirement already up-to-date: pysha3 in ./local/lib/python2.7/site-packages (from ethereum>=1.2.0->pyethapp>=1.0.11->hydrachain)
Requirement already up-to-date: pycryptodome>=3.3.1 in ./local/lib/python2.7/site-packages (from ethereum>=1.2.0->pyethapp>=1.0.11->hydrachain)
Collecting secp256k1 (from ethereum>=1.2.0->pyethapp>=1.0.11->hydrachain)
  Downloading secp256k1-0.12.1.tar.gz (144kB)
    100% |████████████████████████████████| 153kB 152kB/s
Requirement already up-to-date: pyethash in ./local/lib/python2.7/site-packages (from ethereum>=1.2.0->pyethapp>=1.0.11->hydrachain)
Collecting traitlets (from ipython>=3.0.0->pyethapp>=1.0.11->hydrachain)
  Downloading traitlets-4.2.1-py2.py3-none-any.whl (67kB)
    100% |████████████████████████████████| 71kB 132kB/s
Collecting pickleshare (from ipython>=3.0.0->pyethapp>=1.0.11->hydrachain)
  Downloading pickleshare-0.7.2-py2.py3-none-any.whl
Requirement already up-to-date: simplegeneric>0.8 in ./local/lib/python2.7/site-packages (from ipython>=3.0.0->pyethapp>=1.0.11->hydrachain)
Collecting backports.shutil-get-terminal-size (from ipython>=3.0.0->pyethapp>=1.0.11->hydrachain)
  Downloading backports.shutil_get_terminal_size-1.0.0-py2.py3-none-any.whl
Requirement already up-to-date: setuptools>=18.5 in ./local/lib/python2.7/site-packages (from ipython>=3.0.0->pyethapp>=1.0.11->hydrachain)
Requirement already up-to-date: docutils>=0.3 in ./local/lib/python2.7/site-packages (from statistics->pyethapp>=1.0.11->hydrachain)
Requirement already up-to-date: greenlet>=0.4.9 in ./local/lib/python2.7/site-packages (from gevent==1.1.0->pyethapp>=1.0.11->hydrachain)
Requirement already up-to-date: coverage in ./local/lib/python2.7/site-packages (from devp2p>=0.7.2->pyethapp>=1.0.11->hydrachain)
Requirement already up-to-date: ipaddress in ./local/lib/python2.7/site-packages (from devp2p>=0.7.2->pyethapp>=1.0.11->hydrachain)
Requirement already up-to-date: pyelliptic in ./local/lib/python2.7/site-packages (from devp2p>=0.7.2->pyethapp>=1.0.11->hydrachain)
Requirement already up-to-date: tinyrpc in ./local/lib/python2.7/site-packages (from devp2p>=0.7.2->pyethapp>=1.0.11->hydrachain)
Requirement already up-to-date: tox in ./local/lib/python2.7/site-packages (from devp2p>=0.7.2->pyethapp>=1.0.11->hydrachain)
Requirement already up-to-date: ptyprocess>=0.5 in ./local/lib/python2.7/site-packages (from pexpect->pyethapp>=1.0.11->hydrachain)
Requirement already up-to-date: ipython-genutils in ./local/lib/python2.7/site-packages (from traitlets->ipython>=3.0.0->pyethapp>=1.0.11->hydrachain)
Collecting pathlib2 (from pickleshare->ipython>=3.0.0->pyethapp>=1.0.11->hydrachain)
  Downloading pathlib2-2.1.0-py2.py3-none-any.whl
Collecting virtualenv>=1.11.2 (from tox->devp2p>=0.7.2->pyethapp>=1.0.11->hydrachain)
  Downloading virtualenv-15.0.1-py2.py3-none-any.whl (1.8MB)
    100% |████████████████████████████████| 1.8MB 104kB/s
Requirement already up-to-date: pluggy<0.4.0,>=0.3.0 in ./local/lib/python2.7/site-packages (from tox->devp2p>=0.7.2->pyethapp>=1.0.11->hydrachain)
Collecting six (from pathlib2->pickleshare->ipython>=3.0.0->pyethapp>=1.0.11->hydrachain)
  Downloading six-1.10.0-py2.py3-none-any.whl
Building wheels for collected packages: cffi, ethereum, click, lmdb, secp256k1
  Running setup.py bdist_wheel for cffi ... done
  Stored in directory: /home/ralf/.cache/pip/wheels/8f/00/29/553c1b1db38bbeec3fec428ae4e400cd8349ecd99fe86edea1
  Running setup.py bdist_wheel for ethereum ... done
  Stored in directory: /home/ralf/.cache/pip/wheels/3c/07/96/66241dea8da79ed9aeb8936e802a1322ca1547f231e3aae911
  Running setup.py bdist_wheel for click ... done
  Stored in directory: /home/ralf/.cache/pip/wheels/b0/6d/8c/cf5ca1146e48bc7914748bfb1dbf3a40a440b8b4f4f0d952dd
  Running setup.py bdist_wheel for lmdb ... done
  Stored in directory: /home/ralf/.cache/pip/wheels/1d/36/58/b211fed809590977150eabf644580f7bc23569d1d782275fd6
  Running setup.py bdist_wheel for secp256k1 ... done
  Stored in directory: /home/ralf/.cache/pip/wheels/f9/d4/2e/45de9a2b74244b2453aebcef57db807fba5f51f9f4ed63ce07
Successfully built cffi ethereum click lmdb secp256k1
Installing collected packages: cffi, secp256k1, ethereum, requests, werkzeug, traitlets, six, pathlib2, pickleshare, backports.shutil-get-terminal-size, ipython, gevent, click, lmdb, devp2p, pyethapp, hydrachain, virtualenv
  Found existing installation: cffi 1.5.0
    Uninstalling cffi-1.5.0:
      Successfully uninstalled cffi-1.5.0
  Found existing installation: ethereum 1.0.8
    Uninstalling ethereum-1.0.8:
      Successfully uninstalled ethereum-1.0.8
  Found existing installation: requests 2.9.1
    Uninstalling requests-2.9.1:
      Successfully uninstalled requests-2.9.1
  Found existing installation: Werkzeug 0.11.3
    Uninstalling Werkzeug-0.11.3:
      Successfully uninstalled Werkzeug-0.11.3
  Found existing installation: traitlets 4.1.0
    Uninstalling traitlets-4.1.0:
      Successfully uninstalled traitlets-4.1.0
  Found existing installation: pickleshare 0.6
    Uninstalling pickleshare-0.6:
      Successfully uninstalled pickleshare-0.6
  Found existing installation: ipython 4.1.1
    Uninstalling ipython-4.1.1:
      Successfully uninstalled ipython-4.1.1
  Found existing installation: gevent 1.1b3
    Uninstalling gevent-1.1b3:
      Successfully uninstalled gevent-1.1b3
  Found existing installation: click 6.2
    Uninstalling click-6.2:
      Successfully uninstalled click-6.2
  Found existing installation: devp2p 0.6.2
    Uninstalling devp2p-0.6.2:
      Successfully uninstalled devp2p-0.6.2
  Found existing installation: pyethapp 1.0.18
    Uninstalling pyethapp-1.0.18:
      Successfully uninstalled pyethapp-1.0.18
  Found existing installation: hydrachain 0.1.17
    Uninstalling hydrachain-0.1.17:
      Successfully uninstalled hydrachain-0.1.17
  Found existing installation: virtualenv 14.0.6
    Uninstalling virtualenv-14.0.6:
      Successfully uninstalled virtualenv-14.0.6
Successfully installed backports.shutil-get-terminal-size-1.0.0 cffi-1.6.0 click-6.6 devp2p-0.7.2 ethereum-1.3.0 gevent-1.1.0 hydrachain-0.1.17 ipython-4.2.0 lmdb-0.89 pathlib2-2.1.0 pickleshare-0.7.2 pyethapp-1.2.1 requests-2.10.0 secp256k1-0.12.1 six-1.10.0 traitlets-4.2.1 virtualenv-15.0.1 werkzeug-0.11.9
You are using pip version 8.1.1, however version 8.1.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
pip install -U hydrachain  29.04s user 2.19s system 30% cpu 1:42.57 total
(local) ~ % hydrachain
Usage: hydrachain [OPTIONS] COMMAND [ARGS]...

  Welcome to HydraChain/vundefined/linux2/py2.7.9

Options:
  --profile [livenet|testnet]  Configuration profile.  [default: morden]
  -C, --Config TEXT            Alternative config file
  -c TEXT                      Single configuration parameters
			       (<param>=<value>)
  -d, --data-dir TEXT          data directory  [default:
			       /home/ralf/.config/pyethapp]
  -l, --log_config TEXT        log_config string: e.g. ":info,eth:debug
			       [default: :info]
  --log-json / --log-no-json   log as structured json output
  --log-file PATH              Log to file instead of stderr.
  -b, --bootstrap_node TEXT    single bootstrap_node as
			       enode://pubkey@host:port
  -m, --mining_pct INTEGER     pct cpu used for mining
  --unlock TEXT                Unlock an account (prompts for password)
  --password FILENAME          path to a password file
  --help                       Show this message and exit.

Commands:
  account      Manage accounts.
  blocktest    Start after importing blocks from a file.
  config       Show the config
  export       Export the blockchain to FILE.
  import       Import blocks from FILE.
  run          Start the client ( --dev to stop on error)
  rundummy     run in a zero config default configuration
  runlocal     run in a zero config default configuration
  runmultiple  run multiple nodes in a zero config default...

@schmir: Stange. I just recreated your example in a clean virtualenv and don't get that problem.
Could you run the following code in the same virtualenv:
from pkg_resources import get_entry_info, get_distribution
from pprint import pprint
import hydrachain

print(hydrachain.__file__)
print(get_entry_info('hydrachain==0.3.0', 'console_scripts', 'hydrachain'))
pprint(get_distribution('hydrachain==0.3.0').__dict__)

/home/ralf/local/local/lib/python2.7/site-packages/hydrachain/__init__.pyc
hydrachain = hydrachain.app:app
{'_ep_map': {'console_scripts': {'hydrachain': EntryPoint.parse('hydrachain = hydrachain.app:app')}},
 '_key': 'hydrachain',
 '_provider': <pkg_resources.PathMetadata instance at 0x7fef1ddff560>,
 '_version': '0.3.0',
 'location': '/home/ralf/local/lib/python2.7/site-packages',
 'platform': None,
 'precedence': -1,
 'project_name': 'hydrachain',
 'py_version': None}

(Note the duplicate local/local in the first path)
I have a directory ~/local/local, which looks like:
% ls -la ~/local/local
total 0
drwxr-xr-x 2 ralf ralf  40 Feb 11 22:41 ./
drwxr-xr-x 7 ralf ralf 103 Feb 11 22:44 ../
lrwxrwxrwx 1 ralf ralf  20 Feb 11 22:41 bin -> /home/ralf/local/bin/
lrwxrwxrwx 1 ralf ralf  24 Feb 11 22:41 include -> /home/ralf/local/include/
lrwxrwxrwx 1 ralf ralf  20 Feb 11 22:41 lib -> /home/ralf/local/lib/

I'm pretty sure I didn't create that myself (I am not that drunk!).
The check in hydrachain/init.py needs to resolve symlinks.
I've previously used https://pypi.python.org/pypi/hgdistver (which is
now superseeded by setuptools_scm), so that might also be an option
(together with reading the version with pkg_resources like you do in
the above snippet).


GLSL Panorama causes crash on some systems

I'm reporting this for a friend who does not have a GItHub account, but they can't load this modpack at all. It crashes on startup, no mods added. However, I am able to launch the modpack without any issues. They have tried multiple launchers.
Attached is the crash log they got.
crash-2024-02-16_20.59.11-client.txt

Modpack no-longer includes GLSL Panorama


Make Tape Dynamic

The current implementation of the tape is 128x128. This should be configurable.

Completed with #7


fix insert_all_chunked chunk_size calculation

Overview
This PR introduces fixes the broken OMG.WatcherInfo.DB.Repo.insert_all_chunked/3 functionality described in the issue https://github.com/omisego/elixir-omg/issues/1355.
chunk_size was being calculated before the entry to be inserted in the database had all of its fields added causing chunk_size to be calculated incorrectly. To fix this, the calculation of chunk_size is done after the new inserted_at and updated_at fields are added.
Changes
A minor refactoring to the OMG.WatcherInfo.DB.Repo.insert_all_chunked/3 function was done. The code
chunk_size = @max_params_count |> div(entries |> hd |> fields_count)

has been extracted into a function of its own for testability and readability purposes:
def chunk_size(entry) do
  @max_params_count |> div(entry |> fields_count)
end

Note: chunk_size/1 should be a private function, but I think it is an important function to test. Suggestions welcome on how to make it a private function, yet be easily testable. 😬
Testing
2 tests were added

test that insert_all_chunked/3 chunking works when the postgres parameter maximum is exceeded
test that chunk_size/1 returns the expected chunk size

Coverage remained the same at ?% when pulling ee4aefdc23a5e31122aa38fe16229c6665afcbfe on jacob/1355-fix-insert-all-chunked into 1b5c2ec2467fc524e51572a5d460f9df0d2db53e on master.

I thought about this PR a bit more after a some sleep.
This PR intends to fix the regression caused by https://github.com/omisego/elixir-omg/pull/1322 and bring us back to the functional parity of OMG.WatcherInfo.DB.Repo.insert_all_chunked/3 before the new columns broke it. That is the single goal of this PR.
However even before the regression, there was and is still a bottleneck. If we receive transactions at a rate where we continuously need to be chunking, we will eventually run out of memory. This can be solved, but would take this PR to the next level, and far out of this PR's scope.
It's likely premature to fix this bottleneck at this early stage, but I was considering creating an issue for it so we remember this problem exists. In the code I'd add a comment linking to the issue.
Thoughts?

This can be solved, but would take this PR to the next level, and far out of this PR's scope.
It's likely premature to fix this bottleneck at this early stage, but I was considering creating an issue for it so we remember this problem exists. In the code I'd add a comment linking to the issue.

Sounds good. I would go for a separate PR.

Great work!
Just one general comment, I'd like to recommend commit message convention some of the team members follow.

yeah sorry. i don't get that doc really. 😄  on the other hand in my subsequent commits, i tried to follow it.


Terminal account page

added account page to terminal ui.
Fixes issues #374

Unable to view account details

Resolved.


Feature/merge doks theme

Task & test plan
Task  for the landing page bug that is fixed in this PR
Please take your time to review/test this one because is a bit complex.
Cohtml PR
UE4 PR
GameUIComponents PR

Do we need the empty layouts/partials/main/landing-page.html

Yes we need it because GameUIComponets/docs/layouts/partials/main does not have a landing-page.html and will fail to build if we don't add an empty one here in the theme


add upgrade and shard overlays to tracker

Add overlays to the tracker to show relevant shards/upgrades to the base skills, as small icons in the corner of the relevant skill.
Triple jump would be the most useful, as it has the largest effect on logic and progression.
Possible unique upgrade markers, by skill: (roughly by importance)
Double Jump

Triple Jump
Extra Double Jump

Grapple

Ultra Grapple

Sword

Deflector

Shuriken

Static Star

Grenade

Uncharged Bashgrenades
Multigrenade
Extra Grenade

Dash

Extra Air Dash

Bash

Ultra Bash

Hammer

Shock Smash

Spear

Exploding Spike

Blaze

Charge Blaze

Bow

Quickshot
Splinter
Arcing
Charge Shot

Other

Skill Velocity
Jumpgrades

Efficiency/Rapid/Melting markers could be added. Melting would probably be the most useful as it has a notable effect on traversal. Counters could also be added to relevant upgrades.
This folder contains pngs for all the shards/upgrades/bonus upgrades/upgrade modifiers, most of which are already in ori-rando/assets
trackericons.zip

I know this is a LOT. I do think that if any substantial portion of it is added to the tracker, an option for a more simplified version of the tracker would also be good. This is kinda a spitballed list of possibilities more than anything.

Melting stuff got on there in the meantime


Broken link to "Super Simple Discovery API" design doc

I've updated the broken links in the document with the right one from the design-proposal-archive repo.
reference: https://github.com/kubernetes/website/issues/33893#issuecomment-1135497781

Hey, I have opened PR #34155 to fix all those links, please take a look.

#34155


chore: refactor Status Menu to UI to support Vue3 compatibility layer transition

Refactor Status Menu to UI  to support Vue3 compatibility layer transition https://github.com/kytos-ng/ui/pull/54
This depends on PR 55, which is in progress, so to work on it, you need to branch from PR 197.
@HeriLFIU can you help out with this one too? After you're done with https://github.com/kytos-ng/ui/pull/54, if you can prioritize this one before telemetry_int UI it would be great. Just so we'd also have this one here ready when we start merging Vue3 compat PRs soon enough.

done here https://github.com/kytos-ng/ui/pull/55/files#diff-6718634ef485af669eab12360c643e7d9f150b8e96c773aa16acac83f6ad30fe


Running Demo with docker: cli not starting

Cant get the CLI to connect to the Docker ...
Am not a docker expert. Bet its a silly things i am not doing...
Following the readme ...
server up - all good:
make run-docker-server
cd /Users/apple/workspace/go/src/github.com/choria-io/go-backplane &&  docker-compose up --scale demo1=2 --scale demo2=2
Starting go-backplane_broker_1 ... done
Starting go-backplane_demo2_1  ... done
Starting go-backplane_demo2_2  ... done
Starting go-backplane_demo1_1  ... done
Starting go-backplane_demo1_2  ... done
Attaching to go-backplane_broker_1, go-backplane_demo2_1, go-backplane_demo2_2, go-backplane_demo1_1, go-backplane_demo1_2
broker_1  | [1] 2018/07/13 14:01:10.848940 [INF] Starting nats-server version 1.2.0
broker_1  | [1] 2018/07/13 14:01:10.848994 [INF] Git commit [6608e9a]
broker_1  | [1] 2018/07/13 14:01:10.849098 [INF] Starting http monitor on <IP_ADDRESS>:8222
broker_1  | [1] 2018/07/13 14:01:10.849141 [INF] Listening for client connections on <IP_ADDRESS>:4222
broker_1  | [1] 2018/07/13 14:01:10.849161 [INF] Server is ready
broker_1  | [1] 2018/07/13 14:01:10.849469 [INF] Listening for route connections on <IP_ADDRESS>:6222

cli up - not os good...

x-MacBook-Pro:choria apple$ make run-docker-cli
docker run -e BROKER=<IP_ADDRESS>:4222 backplane --insecure demo2 info
Unable to find image 'backplane:latest' locally
docker: Error response from daemon: pull access denied for backplane, repository does not exist ormay require 'docker login'.
See 'docker run --help'.
make: *** [run-docker-cli] Error 125

my bad, change to docker run -e BROKER=<IP_ADDRESS>:4222 choria/backplane --insecure demo2 info

bingo :) thanks @ripienaar


Add CLI unit test for keyboard interrupt

Add a unit test to cover the case where the user performs a keyboard interrupt from the CLI.

Thanks for the PR! What will this prevent/fix?
Can we show you some appreciation for the contribution?
Also, we're giving away some Hacktoberfest bonuses and goodies for this month.

@tzarebczan I noticed that the unit tests weren't achieving code coverage of this code in cli.py:
try:
    loop.run_until_complete(daemon.start())
    loop.run_forever()
except (GracefulExit, KeyboardInterrupt, asyncio.CancelledError):
    pass
finally:
    loop.run_until_complete(daemon.stop())

I added a unit test to cover the case of stopping the Daemon when a keyboard interrupt is issued. When running the unit test, I discovered an issue with shutting down the daemon runner where an exception would occur, because the on_shutdown signal needed to be frozen.

@cbaumler thanks for the PR, turns out the freeze() wasn't necessary because shutdown() isn't necessary either (actually according to docs only cleanup() should be called and i've confirmed that cleanup() eventually sends the shutdown signal).


Beta 8

gulp2webpack, new database changes, font-awesome 5, update bootstrap & listeners, new namespaces

Shouldn't the require.flarum/core version be set to 0.1.0-beta.8 in composer.json as well?


No plot viewer shown in vscode

httpgd package was installed, and r.plot.useHttpgd is set to true. However running a simple plot command, plot(rnorm(100)) as an example, only outputs a Rplots.pdf file. I was expecting a plot viewer panel in the vscode, like in Rstudio. Is this a bug or I missed something?
I have R4.2.2 installed and Radian, languageserver, vscDebugger all installed, along with R extension and R Debugger extension. Googling all day long, but no solution found on this. Thanks.

Do you use R: Create R terminal to start a new R session?
Would you like to post the value of ls.str(.vsc) and getOption("device") from your R terminal?

Thanks so much for responding! I got similar errors when running ls.str(.vsc) and getOption("device"). I'm new to vscode. Thanks.
`getOption : The term 'getOption' is not recognized as the name of a cmdlet, function, script file, or operable
program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1

getOption("device")

  + CategoryInfo          : ObjectNotFound: (getOption:String) [], CommandNotFoundException
  + FullyQualifiedErrorId : CommandNotFoundException`

This is probably a stupid question - how do you use R: Create R terminal to start a new R session? in vs code code, I simply typed R: Create R terminal in the terminal, and got error:

Then I tried to attach R session by clicking on the bottom "R: (not attached)", it also failed

@EngineeringScholar Have you checked the wiki?
https://github.com/REditorSupport/vscode-R/wiki/Interacting-with-R-terminals

I read the wiki. It seems the problem is that my vs code could not find R client:

I have R installed in C: for all user with the following paths set in windows:
, but Radian installed to Users AppData/Roaming/Python/Python311/Scripts/radian folder, which there was not a way I know of to change the installation path.
I wonder if this has to do with where

Update: I disabled radian in Json settings, and it worked!! not sure why radian is causing the problem though.


Update search link.

Coverage decreased (-45.3%) to 53.813% when pulling f8232bda5facab675fe1edec613cce36a70a84db on tomprince:fix-link into 3ffbac9096ad301953d4c8f3066de7363eb5050a on glyph:master.

Mea culpa.
This PR's builds failed because I introduced a dependency on a third-party private API back in May that recently changed.  #32 removes that dependency.

Coverage remained the same at 99.783% when pulling 75fa593d373d089a4af326ea4930bdae48de6d11 on tomprince:fix-link into 448dd1b388e63f5357a8d6ea7d373605e7ef1ae9 on glyph:master.

Thanks for catching this, @tomprince .  Will merge.


To Do List - Interactive list

In this PR, I did the following:

[ ]  Create a new branch.
[ ]  Refactor the CSS to display interactions.
[ ]  Add JavaScript files for new functionality.
[ ]  Implement a function that clears all tasks selected.
[ ] Manage JavaScript events.
[ ]  All changes to the To Do List are saved in local storage.

@BenMukebo
https://www.loom.com/share/42df4b0a2c374370896ea7cd68deb08a

@BenMukebo, ok I understand, thanks

@BenMukebo, I make a new video:
To Do List - Interactive list by LarryIVC - web pack - Watch Video

Sorry for the delay, but I fell asleep.


[tutorial] flaskr's pytest does not pass due to test_db.py#test_get_close_db fail.

tests/test_db.py#test_get_close_db does not pass.
Actual Behavior

Environment

Python version: 3.7.3
Flask version: 1.0.3
Werkzeug version: 0.15.4
pytest: 5.0.0

I have a fix for this in #3278

@asottile
Great.
Closed this issue.

I think this can be fixed by using the getrepr() method.
`def test_get_close_db(app):
with app.app_context():
db = get_db()
assert db is get_db()
with pytest.raises(sqlite3.ProgrammingError) as e:
    db.execute('SELECT 1')

assert 'closed' in str(e.getrepr())`

I think this can be fixed using the getrepr() method.
def test_get_close_db(app):
    with app.app_context():
        db = get_db()
        assert db is get_db()

    with pytest.raises(sqlite3.ProgrammingError) as e:
        db.execute('SELECT 1')

    assert 'closed' in str(e.getrepr())

here's how it was fixed in #3278: https://github.com/pallets/flask/pull/3278/files#diff-27ab2245a7b45831d4fa8f8b51241d80R191


setup latex

okay

LaTeX environment has updated. I also upload a verison of LaTeX template, plz check.

Latex environment setup update in EnvSetup repo and HDD template update in Spec repo


Update pid_cache.go

Related to https://github.com/AsynkronIT/protoactor-dotnet/pull/309

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Thanks!, looks good!


v1.6.3

[x] Support Test case level TDP inside for loop
[x] Add store, if and while actions for iteration count, data set name
[x] Executions are not happening when test cases imported from Cloud to OS
[x] The $|Runtime| is not working as expected when added inside an Addon NLP's but working fine for the rest of the Normal NLP's
[x] Elements are not getting imported from OS to OS
[x] Uploaded files are not getting stored in IOS when we perform Cloud to OS export and import
[x] Elements are not getting imported from Cloud to OS
[x] While exporting API test cases from Cloud to OS all the Headers and auth are blank.
[x] Not able to execute the Test Cases that are imported from Cloud

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: siva-testsigma:x: PratheepVYou have signed the CLA already but the status is still pending? Let us recheck it.


fix(theme-translation): complete Japanese theme default translation

Pre-flight checklist

[x] I have read the Contributing Guidelines on pull requests.
[ ] If this is a code change: I have written unit tests and/or added dogfooding pages to fully verify the new behavior.
[ ] If this is a new API or substantial change: the PR has an accompanying issue (closes #0000) and the maintainers have approved on my working plan.

Motivation
I'd like to complete the Japanese default translations before proceeding to the Crowdin works.

Test Plan

Test links

Deploy preview: https://deploy-preview-8075--docusaurus-2.netlify.app/
Related issues/PRs

LGTM thanks 👍


Ratelimit issues

Hi @ethomson
Thanks for the nice workflow. I have setup a small dashboard for the jhipster org on github. But we are running now in rate limiting issues (the schedule was at first every hour). Maybe it is related to the configuration as I would like to display more projects than currently on the generated dashboard and thats why running into rate limit.
Is there a way to pass an api user or so, such that the the workflow runs on the higher limit?
If it helps the configuration is here: https://github.com/hipster-labs/github-dashboard
Thanks for help or any hint in advance!

Neat!
Sorry to hear about the rate limit issues.  Right now your configuration is running with the github token that's generated for your workflow run.  My recollection is that this has the same API limits as a normal user - but I could be wrong.  You could try generating a PAT and using that as your token instead (https://github.com/hipster-labs/github-dashboard/blob/master/.github/workflows/dashboard.yml#L272).
But ultimately I think that this action just needs to be smarter about the way it collects data.  GitHub hands us back the rate limiting information (how many additional calls you can make, when your limit refreshes), we could take advantage of that to pause data collection until there's a refresh instead of failing miserably like we do now.

Thanks for the quick reply. Will try a personal access token.

Yeah - reading this page suggests that you'll only get 1000 API requests with the github token and you should get 5x more with a PAT.  Let me know if that's not enough and we should be able to think about how to pause to keep the rate limit in check.

:thinking: It seems not to work (which is strange when looking at the limits). My personal access token has public_repo scope. I scheduled the job for noon maybe something is wrong.

Still the same. Rate limit exceeded for my user, even with two projects less.


[OTA] ESP32 notify the OTA job with failure although it accepted the new firmware.

I'm trying to get the OTA functionality to work with ESP32 and I have a strange behavior.
ESP32 notify the OTA job with failure although it accepted the new firmware.
And this is the error msg I get:
https://forums.aws.amazon.com/ Job in self test but platform state is not! 40 1318 https://forums.aws.amazon.com/ https://forums.aws.amazon.com/ Msg: {"status":"FAILED","statusDetails":{"reason":"rejected: 0x26000000"}} 41 1332 https://forums.aws.amazon.com/ State: Ready Received: 1 Queued: 1 Processed: 0 Dropped: 0

Hi @ahmedwahdan,
Can you post the full logs from your OTA update?
Thanks.

Without the logs we were unable to reproduce this issue so I am going to have to close it.
If you manage to reproduce this and can provide the logs please feel free to post it here and we will re-open it.


S3upload

Added S3 Upload with ReadMe

Needs to hook up to the UI
Needs total progress callback handler
Needs to add UIProgressBar under the ChatViewController's topLayoutGuide to show the total progress
Needs to show BYXBanner Error when an upload fails

Please read the updated readme!


Custom context script

Hello, I create Opnnebula tempalte with INIT_SCRIPTS key in CONTEXT. But it doesn't work, when machine is inicialized byt this driver, because driver itself create own CONTEXT. Solution would be merging CONTEXT defined in VM Template with driver context. Respectivelly, just add to CONTEXT your START_SCRIPT_BASE64

After reviewing this, I believe this is more an enhancement than a bug. It was a design decision that those CONTEXT attributes were going to be substituted with a specific one provided by the docker-machine-opennebula plugin.
Changing this is possible, but not easy. I'm leaving this open in order to improve it in future releases, although I believe this is not something we will do in the short-term.

Hello, so probably easier will be adding another option to driver, where can user pass custom context keys/values.

Can you provide an example?

Something like --opennebula-files and --opennebula-init-scripts which define context keys FILES and INIT_SCRIPTS
We bypassed this issue by calling docker-machine ssh 'commnads from init script' and it works fine....
so it can wait for template context merging implementation

Thanks for explaining it. I prefer this solution that context merging, actually :+1:


Command edit control becomes unusable when it does not fit a command

I think the control should enlarge its height automatically (becoming N-lines control) in this case.

Well, your scrollbars are huge, but I understand that's not the main issue here. You can toggle soft line-wrap with Editor: Toggle Soft Wrap command from command palette (you can also bind it to a hotkey if you wish).
I agree that this should be enabled by default. Which it is in 0.1.4. Thanks for pointing that out.

Great, it works nicely now. Thanks!


Fix crash when setting custom cursor

Fixes #66605.
When setting an in invalid cursor image, a default system cursor is set. However, there was no check whether the cursor type is allowed. I added this check to only allow setting the system cursor if the cursor type is valid.

This looks like a fairly safe bugfix. But needs a double check from someone knowledgeable about X11. And then a rebase to fix conflicts
cc @bruvzg

Superseded by #73500.


chore: init rpeo

HTTP client package with conduit interface and HTTPS support
Issue: https://github.com/linuxdeepin/developer-center/issues/5731
Log: init repo

/approve


Mantl Questions

First, thanks to everyone who has helped me so far!!  I have two environments running mantl( one is bare metal and one is DO ).  Both are of course testing environments.  I have some questions, so if you have a moment and can answer just one, that would be greatly appreciated.  Feel free to post links to any previous answers or resources( i dont mind reading up, i just havent found the answer in my searches ).  Feel free to call me out as well :)

Where are all the variables(IE Traefik has one)?  Can i use the ones from the component itself during the deployment? Or are the available ones listed in a file somewhere?
How can i test traefik with an application ( ie what do i need to do when running the process/service to tell traefik to send traffic to the service?)
How do i get other instances of an application already being serviced by traefik to tell traefik to add them to the list of available hosts.
Most LBs have health checks to verify an application is functioning properly and redirect traffic to the next host if not, is there a special method of telling traefik this or do i just use the instructions from traefik?
Being that consul is everywhere in mantl, is there anything i need to do when building a docker container to ensure that consul sees the new service and lists it in the service directory? ( in mantl )
Is there anything else i should be including in docker builds to ensure they are monitored correctly, run correctly, get logged correctly(ie send logs), are made available to other services? ( in mantl )
can i add addons to the sample/mantl.yml file so they are deployed during deployment and therefore deployed each time i add an agent server?
Do i need to include all machines in the ansible hosts file each time i run a deployment when i am adding another agent server?
Are their any tags and/or commands that i should ensure are in applications at launch when dealing with mantl?  IE: Chronos has several, but marathon has one.
I noticed mantl isnt supporting auto-scaling by default right now, is there a way to test this using the auto-scale from github?
How do i change/update mantl admin password?  Is it possible to add another user( even if this is done via manual scripting ).

@distributorofpain

If you're talking about the different variables you can use to customize your installation, each component has a README.rst that says what they all do, which you can find in the "components" section of the docs
If you run your container via Marathon, Consul will automatically register it as a service. This is done with mesos-consul.
For logging, check out our ELK stack addon
Sure, you can just use an Ansible include:  to include them in your mantl.yml
Can you post a link of what you're referencing in this question?
We don't have a solution for this yet, AFAIK.

Thanks!  Not sure if your number list is supposed to correspond or the system mangled it?

Some of these seem to be lacking in detail or non-existent.  This leads me to question if there are actually any variables at all or if i need to look at the configuration files to see if there is something in them as an example.  For the variables that are stated, i am left wondering where to put those variables( i am assuming the mantl/sample.yml file at this point, which is what i believe i was told when i asked in the glitter chat ).
thats awesome...  i had read up on this piece earlier but didnt quite understand the under the hood setup.  What i am unsure of here is that i have a few services running, but they do not appear in the traefik web interface.  Although for kibana, it has a tag for traefik set to false.  So it seems if thats set to false, then they wont appear in traefik?  ( Hence why i dont see them? ).  Is this meant to answer 2-4 ?
Which answer was this applying to?
Was this meant to answer 8?
Which question?
which question?

@distributorofpain Yeah, it tried to automatically renumber them. I've updated accordingly.
One: For most of the variables, you want to set them as "role variables". You may want to read up on Ansible's variable hierarchy on the Ansible docs page about variables.

updated my responses above, i put them in a code block so it wouldnt change them, but i suppose that didnt work out for the links :(

I wasnt able to use include for the elk stack addon, there is already an include in the elk addon, so when you use the include line, it sees it as a second entry and gives an error stating it cant find the checks file ( the error shows that the directory is wrong, it goes up one folder in the main path )
so /mantl/mantl-master/playbooks/check-requirements.yml becomes /mantl/playbooks/check-requirements.yml instead and thus an error is thrown.
If i remove the include line, it starts no problem.  I just copied the anisble part of the elk.yml role setup into the sample file and ran it instead.

@distributorofpain Have you been able to find answers to these questions? Do you have any that are still outstanding that you'd like for me to answer?

Question 4:  How to setup health checks for apps.  Found their document:  https://mesosphere.github.io/marathon/docs/health-checks.html  Though i wish they would also show interface examples as the json isnt always one to one.  It also seems mantl is behind version wise as their is a forcepullimage checkbox now.
Question 8:  ?
Question 10:  seems there is another issue/PR working on autoscaling :smile:
Question 11:  I thought i saw people talking about the autoscale program somewhere...
Question 12(new):  Is there a way to put a mesos node in maintenance?  When i looked at the reboot script, all it does is set consul in maintenance mode.  Unfortunately, this still allows apps to spin up on nodes as mesos doesnt seem to care what consul is doing.  I tried to run the api call, but mesos wouldnt respond ( i think this is due to the way mantl is secured interface wise as i was getting a reply from nginx ).  Someone suggested stopping it via systemd?

@distributorofpain
Four: Yes, Marathon is the way to go. I'll make an issue about upgrading Marathon.
Eight: I don't think so, would you mind trying without including all servers and letting us know how it goes?
Eleven: We don't really have a way to do this right now.
Twelve: Yes, you should stop the systemd service.

Four: awesome thanks!
Eight: ack! sure....  right now i am playing in DO, so my vm workstation setup is shutdown.  I do have a followup though.  In DO, i am using terraform to deploy.  With terraform, i can simply increase the agent node number and run terraform apply.  Then run the mantl install again.  would there be a way to only target the new node with the script?  ( i have a feeling someone already told me this, but i cant find it in my notes ).
Eleven:  Seems its just an app that runs in marathon or a task in chronos, so we could probably implement it in mantl without issues.  Though reading the latest comments/issues, its not ready for primetime :frowning:
Twelve: Duely noted!

Eight: Ansible has the ability to limit which hosts are affected: http://docs.ansible.com/ansible/intro_patterns.html

ok, so it looks like i could --limit the installs to only new machines i add via terraform.  Thats excellent news.  Thanks


Link in Readme leads nowhere

On the somewhat last line of the README.md is a link that leads nowhere.
'The extension can also be found on the VS Code marketplace.'

This extension is outdated in favor of https://marketplace.visualstudio.com/items?itemName=rust-lang.rust


Copy all CatalogSource annotations to its Pod

Description of the change:
Plumbs a mechanism that copies all annotations from the
CatalogSource directly into the corresponding Pod's metadata.
Motivation for the change:
This is needed in order to facilitate adding annotations to the pods created by a
CatalogSource; in particular the workload partitioning annotations required for Single Node Openshift as outlined in https://github.com/openshift/enhancements/pull/703
Reviewer Checklist

[ ] Implementation matches the proposed design, or proposal is updated to match implementation
[ ] Sufficient unit test coverage
[ ] Sufficient end-to-end test coverage
[ ] Docs updated or added to /doc
[ ] Commit messages sensible and descriptive

/ok-to-test


First cut of CCS

Just started throwing something at the wall for CCS, basically using same structure and code as R1CS with minor tweaks, didn't get very far yet but pushing so we can keep working in the same PR
cc @arnaucube

Very basic but at least got something to work with now. Gonna merge this since it won't break anything and will make other work easier. Suggest we do follow up work either in this PR or directly in the hypernova branch.


Update coredns-custom.md

Update Rewrite DNS YAML format

@mutazn : Thanks for your contribution! The author(s) have been notified to review your proposed change.

doc has been updated


Dimension preferences

Since the very beginning of the project, there has been some tension as to what Dimension objects are for. There have been two major pressures:

Keeping dimension objects as lightweight as possible, used to describe key features about the data.
Using dimension objects to implement features and improve usability. For instance, we've wanted a way to set a default position for sliders and Dimension is the obvious place to put that. Other things related to usability are soft_range and the formatters.

This situation has made things difficult as Dimension is a core component of HoloViews that we want to keep as simple as possible on one hand while also wanting to support new features on the other. Things are further complicated by questions as to whether two dimension objects are 'equal' and therefore interchangeable.
After discussing this problem with @philippjfr and @jbednar, I think we've found a good compromise based on this insight: some of what Dimension contains is indeed core metadata about the data and the rest of the options are aimed at usability that are issues of  preference (which can be subjective).
The core metadata should be a small list of things that define the most important information about the dimension and the preferences can be a much larger, open-ended set of options aimed at usability. For this reason, we should group these two types of metadata separately.

Core metadata: name, unit, range (often constrained by the unit definition, e.g (0, 360) for angle in degrees and (0, None) for a temperature in Kelvin).
Preferences: soft_range (the typical useful range as determined by the domain or user preference), default_key and the various formatters.

Based on this, the proposal is that Dimension has only the core metadata as its own parameters as well as a preference parameter that holds an object containing all the preferences. This makes it clear as to what the most important information is regarding a dimension while allowing flexibility in terms of the various preferences.
We still need to discuss the exact form this preference object takes and we should think of finding a syntactically convenient way of defining them.

Sounds good!  Deciding what to do with existing preferences like soft_range is also  important, as a a balance between compatibility and clean semantics.

Here is one syntax for this I think might be quite nice:
K = hv.Dimension('Kelvin', range=(0,None)).prefs(soft_range=(200,300), default=220)

Would the prefs object accept any Parameterized, or only the one sample one that we define (with soft_range, default, etc. already enumerated as Parameters)?

Of course, we also need to be careful around the issue of compatibility. Here is what we could do:

Issue deprecation warnings when things like soft_range are passed in through the dimension constructor, suggesting the use of the pref method while making it easy to disable such warnings.
Eventually remove this parameters (probably between one major release and the next).

I suppose we would need a bit of compatibility for pickling once these parameters are moved over to the preferences.

@jbednar Good question!
Maybe we could offer a way of using a preferences object we can understand (with things we define such as soft_range etc) but support storing other parameters which are metadata that people want to store but that we won't act upon.

Thanks for the summary. Several things to note, first of I'm wondering about the other parameters, like type and value. The type isn't currently used very consistently but values are used to define DynamicMaps with concrete sampling.

Preferences: soft_range (the typical useful range as determined by the domain or user preference), default_key and the various formatters.

This does not match the current semantics of range and soft_range. range defines an absolute range to use while soft_range only defines soft limits which can be overridden by the data.

Maybe we could offer a way of using a preferences object we can understand (with things we define such as soft_range etc) but support storing other parameters corresponding to metadata that people may want to store on the dimension as preferences but that we won't then act upon.

Yes, storing other metadata on them makes sense, although perhaps calling it preferences isn't quite correct then.

This does not match the current semantics of range and soft_range. range defines an absolute range to use while soft_range only defines soft limits which can be overridden by the data.

Thanks for clarifying! The key thing is that you agree that range is absolute and soft_range isn't.
I suspect value might be core as you can have categorial dimensions that are only defined for a number of discrete values. I think type (to the extent we use it) is also core.

I'll have to clarify again, when I said range is absolute what I meant is that it overrides everything else, including the data or soft_range. What that means is that it cannot be used as a definition of the actual physical quantity (e.g. Dimension('Temperature', unit='K', range=(0, inf)) but is simply a convenient way for the user to specify which part of the dimension range they are interested in. In other words the range is just as much a choice as the other parameters since the user has to set it deliberately to control the axis ranges, color normalization, or which parts of the parameter space can be explored with a DynamicMap.
This means range is not an describing some intrinsic and absolute property of a physical quantity (i.e. what you call core metadata) but rather provides convenient metadata about how to display the Dimensionedobject and therefore falls into the list ofpreferences``. The only core metadata on our Dimensions is the name and the unit. Defining the actual range of values a physical quantity allows is something that's best left up to a units package which we could eventually integrate with HoloViews.

Thanks for the clarification. To update the bullet point lists above:

Core metadata: name, unit, type
Preferences: range, values, soft_range, default_key and the various formatters.

I agree we are very flexible with how range and values are used so this new suggestion makes sense. That said, isn't value overloaded to also specify the categories for categorical dimensions?

As part of 1.7 we will add the preferences to Dimension, and as part of 2.0 we will move existing parameters to the preferences.

After starting a PR and discussing this issue in detail with Philipp (again!) we came up with a different approach. This is a proposal we are both happy and it requires fewer changes while doing away with an explicit concept of dimension preferences:

Dimensions will now have clearly defined equality semantics i.e what dimensions are which makes me happy.
The way dimensions are used is largely unchanged and we can feel free to add parameters to Dimension as necessary, minimizing disruption.

Instead of introducing preferences, the idea is that dimension objects are almost entirely preferences which means almost everything in a dimension can be ignored when comparing them. The key new insight is that what defines a dimension can't be some optional argument, or in other words,  'core' metadata must be whatever is passed as the first (mandatory) positional argument.
Currently there are two things you can put into this mandatory position, a string (the name) or a tuple (the name and label):
a = hv.Dimension('a')
b = hv.Dimension(('b', 'description of the b dimension'))

This means the current rules for equality (defining the semantics) should be:

Two dimension objects are equal if and only if their names match AND their labels match.
A dimension matches a string for equality if either the name or label matches (this definition is slightly loose but it is used all over the code. Names and labels are expected to be very different lengths by definition so there should be little confusion in practice)

Matching on both name and label should always work between two dimension objects as the label will match the name by default (i.e if it isn't explicitly set via the tuple).
Units
We have long wondered whether units are part of the semantics of a dimension or not. I believe we have finally figured this out:

Currently our 'unit' parameter is just an optional string used to display the dimension (e.g on an axis). It is not a rich unit object supporting unit conversions so it should not be considered core metadata and should not be considered in equality.

In future, we can support unit objects that are passed as the first positional argument. This makes them part of the core and therefore part of the equality comparison. Unit equality will not be a trivial comparison of the declared unit either: two dimension with rich unit objects are equal if they are in the same space which means the units must be able to directly convert to each other.

For instance, a dimension expressed in Kelvin is equals to a dimension expressed in Celsius (given the name and labels are also equal) as both express temperature. A dimension expressed in meters isn't equal to one expressed in celsius as these are different types of unit. The conversion methods of the rich unit objects of the dimensions will be used to determine whether the conversions are valid.
Rules defining Dimension parameters
In short, the first argument to Dimension defines the core metadata used in equality, everything else are to be considered preference parameters.
Unpacking the implications of this rule:

All state on a dimension instance is expressed by its parameters.
Core metadata parameters are set through the first (and only) positional argument. This means hv.Dimension('b', label='description of the b dimension') will be disallowed (the tuple format must be used if you want to set the label parameter). Although this restriction could potentially be relaxed if it causes problems,  I would like to avoid making label an exception to this rule.
You have a choice in how rich you want the dimension semantics to be based on what you choose to pass in as the first argument (string, name-label tuple, potential future unit object).
The unit parameter is currently set as a kwarg but one day it should be changed to only allow None or a rich unit object which will be passed as the first argument. This unit object will require the name and optionally the label, allowing all core parameters to be specified.
Everything else is considered non-semantic metadata. This is information which isn't about your data but about how you choose to display your data with HoloViews for a given visualization.

I'll now be working on a PR (or two!) to implement the following:

[ ] The updated equality semantics
[ ] Renaming the first argument from name to something else that makes it clear that it can represent the name or the name and label or some other core data . I can't decide between spec and core right now.
[ ] Remove the deprecated 'initial' option from the values parameter.
[ ] Declaring label as a parameter
[ ] Disallowing label from being passed as a kwarg.
[ ] Fixing the __call__ method, making it work with (name, label) tuples

I realize this comment has grown quite long but it is worth laying things out clearly and explicitly so we can think through the consequences of this plan. This issue has generated a lot of discussion over a number of years and I think we can finally put it to rest!

Good summary and the to-do list looks correct to me, might just want to add:

[ ] Ensure that redim still works correctly after these changes

Looks good; glad to see this heading toward resolution.

In future, we can support unit objects that are passed as the first positional argument.

By adding units as a third item in a tuple?  Seems a bit clunky, but does seem like it forces the user to know that this is part of the definition of that dimension.
Seems like it ought to be possible for users to add units later, but I'm not certain what I mean by "later".  People definitely add units later in wallclock time (after an initial implementation), but maybe they can be considered to add them at the logical start, not logically after initial creation; not sure.

This means hv.Dimension('b', label='description of the b dimension') will be disallowed

I'm not sure I agree with that; hv.Dimension('b', label='description of the b dimension') is much more explicit about which is which than hv.Dimension(('b','description of the b dimension')).  I do see what you mean about the positional argument, but it does have a downside here (as the meaning of a tuples is highly non-obvious, if not a named tuple).

I can't decide between spec and core right now.

I vote for spec.

After further discussion with @jbednar I think we finally have something all three of us are happy with!

Although this restriction could potentially be relaxed if it causes problems, I would like to avoid making label an exception to this rule.

Supporting label as a kwarg turned out to be the main sticking point. As I still don't want to make special exceptions regarding what is core and what isn't, we need a new rule:
New rule

Core data is defined by the tuple format supported in the constructor. This is the same tuple format you can use to avoid having to build a dimension object yourself. For instance:

hv.Image(..., vdims=[('z', 'Z-score')])

Whatever parameters can be set in this type of tuple format must be core semantic information - by design, these tuples are designed to specify only the most important information to avoid building a dimension object explicitly.

You'll be able to go from a dimension object to its tuple format via a spec property. This will be the same name as the first argument to the Dimension constructor. The spec property will always return the most descriptive tuple possible.

Dimension equality will only be allowed to access the spec property and not any other parameters.

Advantages

This means future unit support would require 3-tuple support:

hv.Image(..., vdims=[('z', 'Z-score', unit('m')) ])

The advantage is that is that the unit object could be supplied by some 3-party unit library instead of requiring a special holoviews object that needs a name and optional label (parameters that aren't really about units).

label would once again be allowed as a keyword. This ambiguous case would warn and use the label as specified by the keyword:

Dimension(('z', 'Z-score'), label='Something else')

Consequences

Until unit support is implemented, conceptually dimension equality is straightforward tuple equality between the two dimension spec properties.

Unfortunately, it isn't quite true due to name sanitization. In the end we decided to keep the current sanitization support for 1.7 but drop it in 2.0. The recommendation after 2.0 will be to use attribute friendly names on your data source or simply apply redim to get attribute friendly names.

Using label will be encouraged as the way of assigning the descriptive, non-attribute friendly name. People ignoring this advice and who don't redim can still use the horrible kwarg trick in select if absolutely necessary.

Even once this is implemented, equality between dimensions won't be strict tuple equality once unit support as we will need to compare the unit types. Equality between dimensions and strings will still be supported (as described in the earlier comment) i.e matching either the name or the label.

The following spec formats are currently supported: 'z', ('z', 'Z-score'). With future unit support, something like the two additional two formats seem reasonable: ('z', unit('m')), ('z', 'Z-score', unit('m')). This is an exhaustive list of spec formats we can foresee right now.

I'm hoping that this is the final proposal that is satisfactory to @jlstevens, @philippjfr and @jbednar!

Sounds perfect; thanks for writing that up.

I think this issue has finally been addressed in the PR referenced above (merged).
Glad to finally close this issue!

Reopening, I strongly disagree with the decisions we made here. I'd prefer not to open this can of worms again but here we are, should at least discuss it for 2.0.


[eas-cli] add Monterey image

Checklist

[ ] I've added an entry to CHANGELOG.md if necessary. You can comment this pull request with /changelog-entry [breaking-change|new-feature|bug-fix|chore] [message] and CHANGELOG.md will be updated automatically.

Why
Add Monterey image

/changelog-entry chore Add macOS Monterey image


Please... What the f**king SS14's protocol working ?!?!?!??!

I trying to write some programs with Space Station 14's (Robust ToolBox's) protocol on python, but NOTHING NOT HELPING ME WITH THIS. (I trying like a month)
I readed the official Robust ToolBox Docs on the Robust.Shared/Network.... Nothing...
I trying this with ChatGPT 4... Nothing...
Please, help me with this...
I don't have the nerve to try anymore !!...

pro

Duplicate of https://github.com/space-wizards/RobustToolbox/issues/4657


Relocated components and implemented shadcn ui

Related Issue(s)

Fixes #180

Description

Relocated all the other components that are not based on shadcn ui from components\ui to components directory
Implemented shadcn ui components like Button, Label, Input, Dropdown in pages including qr-codes , links, NoPageFound etc

Checklist
Before submitting your pull request, ensure that you have completed the following tasks:

[X] Code follows the project's style and conventions.
[X] Code has been tested thoroughly, and all tests pass successfully.
[ ] Documentation has been updated to reflect any relevant changes.
[X] All new and modified code is adequately commented for clarity.
[X] Pull request title follows the specified format: [Feature/Enhancement/Bug Fix]: Brief description of the change.

@Swarnendu0123 @rahulpoonia29 Please review and merge this PR

@Swarnendu0123 @rahulpoonia29 Please review and merge this PR

@Asymtode712 Seems good, thanks for the contribution.


Implement a v1alpha2 of the WasmCloudHostConfig CRD

Our CRD has become a bit unwieldy and disorganized because of the various options we've added since the project started. We should create a v1alpha2 version and restructure everything so that it makes sense. It should include all of the available host configuration options in a dedicated section separate from k8s-related configuration.

@joonas thoughts here?


4 Slash Diacritics | horizontal ( U+0335, 0336) Diagonal 0337, 0338 )

I was adding these for the second time and consulted with the Brill typeface. I have some ideas about
a) checks we might make
I noticed that the width is zero but that the shape should be offset to the left so that it can overlap the next glyph that is typed. We could maybe check to see that the width is zero, side bearings are negative on the left and positive on the right.
b) what we might do differently with the name lists.
John Hudson has 3 versions of the slash diacritic: Regular for lower case, a Capital (.cap or .case) version and a .sc version for small caps. Maybe we should too. Another way to go would be to repurpose the comb or .case diacritics for small caps
c) more pre-made letters?
I also wondered if we want to go ahead and add the composed letters that are meant to take these diacritics. I am guessing not but looking at how these strokes combine even in the Brill face I do see that not formally composing them is inevitably less clear and uglier.

a) If you want to properly place those overlay diacritics on different glyphs, you can use anchors and you might have to change the advance width and offset the outline of the base glyph. However there is no guarantee that where you position it is what the user expects. These overlay diacritics could be centered on ascenders, descenders, center of bowls, left of bowls, right of bowls, etc.
b) Having different versions of these overlay diacritics makes sense, you may need different sizes beyond those 3 for characters or glyphs of different widths (i, n, o, w, m, etc., I, J, N, O, W, M, etc.) or for where they go (ascender, etc.).
c) Unicode doesn’t use those for composing characters and doing so should be done with care (o + overlay slash may look to close to ø thus allowing spoofing).
See Unicode 11.0.0 Section 2.12 Non-decomposition of Certain Diacritics
and Section 7.9 Overlaid Diacritics
That said, there is little use for these overlay characters on letters besides a few corner cases.
Unicode usually encodes pertinent cases as new characters, for example the recently added U+A7B8 LATIN CAPITAL LETTER U WITH STROKE and U+A7B9 LATIN SMALL LETTER U WITH STROKE which should be used instead of <U+0055, U+0337> (LATIN CAPITAL LETTER U, COMBINING SHORT SOLIDUS OVERLAY), etc.
It should also be noted that transcription systems and orthographies have different position of strokes on Unicode encoded characters. For example ƀ or đ may have their stroke through the bowls instead of the ascenders in some locales. Unicode usually encodes those cases as separate characters when variants have different semantics in a single transcription system, for example ᵽ vs. ꝑ. And of course there are mixed situations: Ꝁ ꝁ vs. Ꝃ ꝃ vs. Ꞣ ꞣ have different semantics in Latin but then Ꝁ may look like ₭ in some other locale.
So, unless you’re planning to make a font for specific corner cases where your users need to position strokes or slashes on specific parts of characters that don’t exist as encoded characters, don’t include U+0335..0338 in your font or don’t bother positioning them.

Let me paraphrase what I got from this and see if it sounds right to you: Do it properly e.g. make the composed letters with slashes; or leave it out. The result of ( U+0335, 0336) Diagonal 0337, 0338 ) is too unsatisfactory in all cases to bother with.
If that's right why leave it in the Brill typeface? Maybe so you can type y and a slash diacritic and have it resolve to the composed form?
Or are there some limited glyphs in which this is a useful if imperfect half measure?

Oh - and assuming these made it into a standard list instead of being regulated to IPA+minority latin scripts or something - do you end up helping any populations of size with that gesture or would you need another 20 (or 120) other glyphs as well?

Brill doesn’t seem like it’s bothering to position U+0334..0338 much.

Let me paraphrase what I got from this and see if it sounds right to you: Do it properly e.g. make the composed letters with slashes; or leave it out. The result of ( U+0335, 0336) Diagonal 0337, 0338 ) is too unsatisfactory in all cases to bother with.

I’m saying it’s nearly impossible to do it properly as users expectations will vary greatly and there are too many possible cases.
Unicode prefers to encode single characters like Ⱥ ⱥ ᵬ Ƀ ƀ Ȼ ȼ  Ꞓ ꞓ ᵭ Đ đ Ɖ ɖ Ð ð Ɇ ɇ ᵮ Ǥ ǥ Ꞡ ꞡ Ħ ħ Ɨ ɨ ᵻ Ɉ ɉ Ꝁ ꝁ Ꝃ ꝃ Ꝅ ꝅ Ꞣ ꞣ Ɫ ɫ Ł ł Ƚ ƚ Ꝉ ꝉ Ⱡ ⱡ ƛ ᵯ ᵰ Ꞥ ꞥ Ɵ ɵ Ꝋ ꝋ Ø ø ᵱ Ᵽ ᵽ Ꝑ ꝑ Ꝗ ꝗ Ꝙ ꝙ ᵲ Ɍ ɍ Ꞧ ꞧ ᵴ Ꞩ ꞩ ᵵ Ŧ ŧ Ⱦ ⱦ Ꝥ ꝥ Ꝧ ꝧ Ʉ ʉ Ꞹ ꞹ ᵿ Ɏ ɏ ᵶ Ƶ ƶ ʡ ʢ which are more manageable.
Unlike é <U+00E9> (eacute) which is canonically equivalent to é <U+0065, U+0301> (e + acutecomb), meaning they should look, have the same semantics and behave the same way, any of those separate characters are not canonically equivalent with other characters combined with U+0334..0338. So no one should expect fonts to consistently replace a̷ <U+0061, U+0337> or a̸ <U+0061, U+0338> by the glyph of ⱥ <U+2C65>, nor k̷ <U+006B, U+0337> or k̸ <U+006B, U+0338> by ꝃ <U+A743> or ꞣ <U+A7A3>.
You can do any of those substitutions if you want, but it’s not a standard compliance requirement.
If you want to extend language orthography, historic or phonetic transcription coverage then include those single encoded Unicode characters. Those will help more users.
If fontbakery needs to have a check for those overlay marks, it should just check that the are non-spacing and that they overlay.


NPM install fails with Node 4.0

make: Entering directory `/data/dev/zk/node_modules/zookeeper/build'
ACTION binding_gyp_libzk_target_build_zk_client_lib .
Downloading zookeeper-3.4.3 from http://apache.mirrors.tds.net/zookeeper/zookeeper-3.4.3/zookeeper-3.4.3.tar.gz
gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
Unable to build zookeeper library
make: *** [.]  System Linux 2.6.32-504.30.3.el6.x86_64
gyp ERR! command "/root/.nvm/versions/node/v4.0.0/bin/node" "/root/.nvm/versions/node/v4.0.0/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /data/dev/zk/node_modules/zookeeper
gyp ERR! node -v v4.0.0
gyp ERR! node-gyp -v v3.0.1
gyp ERR! not ok
npm ERR! Linux 2.6.32-504.30.3.el6.x86_64
npm ERR! argv "/root/.nvm/versions/node/v4.0.0/bin/node" "/root/.nvm/versions/node/v4.0.0/bin/npm" "install" "zookeeper"
npm ERR! node v4.0.0
npm ERR! npm  v2.14.2
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>install: node-gyp rebuild
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script 'node-gyp rebuild'.
npm ERR! This is most likely a problem with the zookeeper package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node-gyp rebuild
npm ERR! You can get their info via:
npm ERR!     npm owner ls zookeeper
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     /data/dev/zk/npm-debug.log

I confirmed that it fails to install even with my fixes for node 0.12 in #108 .  I'll fix 4.0 support after I get 0.12 support merged in.

@hussion I've created a branch that should work on node 4.x.  I've run the test suite against it without trouble.  I'll run that branch in our deployment for a couple of days and then merge it into the mainline and push a new version out.  If you want to test the support (I'd really appreciate it), you can reference the branch like this:
"zookeeper": "git://github.com/mdlavin/node-zookeeper#node-4.0-adoption-prepublish"


[SPARK-24397][PYSPARK] Added TaskContext.getLocalProperties in Python

What changes were proposed in this pull request?
Added.
How was this patch tested?
New test added.

@JoshRosen @gatorsmile

Test build #91179 has started for PR 21437 at commit 52610e3.

Test build #91179 has finished for PR 21437 at commit 52610e3.

This patch fails Python style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/91179/
Test FAILed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/3605/
Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/3606/
Test PASSed.

Test build #91233 has started for PR 21437 at commit b9d8dd3.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/3648/
Test PASSed.

Test build #91233 has finished for PR 21437 at commit b9d8dd3.

This patch fails PySpark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/91233/
Test FAILed.

cc @ueshin @HyukjinKwon @BryanCutler

Test build #91272 has started for PR 21437 at commit e197460.

Test build #91272 has finished for PR 21437 at commit e197460.

This patch fails Python style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/91272/
Test FAILed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/3681/
Test PASSed.

Test build #91274 has started for PR 21437 at commit 9d95c12.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/3683/
Test PASSed.

Test build #91277 has started for PR 21437 at commit 2ea9cbc.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/3686/
Test PASSed.

Seems fine and I'm okay with it

Test build #91277 has finished for PR 21437 at commit 2ea9cbc.

This patch fails PySpark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/91277/
Test FAILed.

Test build #91288 has started for PR 21437 at commit 6fef2f1.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/3694/
Test PASSed.

Test build #91288 has finished for PR 21437 at commit 6fef2f1.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/91288/
Test FAILed.

Test build #91292 has started for PR 21437 at commit 6fef2f1.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution/3698/
Test PASSed.

Test build #91292 has finished for PR 21437 at commit 6fef2f1.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/91292/
Test PASSed.

@HyukjinKwon @BryanCutler @JoshRosen @ueshin is this good to go?

Ping once again.

Thank you very much everyone. Merging to master.


Add OIDC support

Add OIDC support

This might end up being a breaking change, I'll see how I go.
I'll let you know @onedr0p when there's a build for you to test.

https://github.com/midarrlabs/midarr-server/pull/374
@onedr0p Sorry for the delay on this one. I've opened another PR with a different approach / library implementation (which
I've made better progress with). Hopefully you're still keen to test?


(WIP) [SDP-1147] Admin schema pt2

What
[TODO: Short statement about what is changing.]
Why
[TODO: Why this change is being made. Include any context required to understand the why.]
Known limitations
[TODO or N/A]
Checklist
PR Structure

[ ] This PR has a reasonably narrow scope (if not, break it down into smaller PRs).
[ ] This PR title and description are clear enough for anyone to review it.
[ ] This PR does not mix refactoring changes with feature changes (split into two PRs otherwise).

Thoroughness

[ ] This PR adds tests for the new functionality or fixes.
[ ] This PR contains the link to the Jira ticket it addresses.

Configs and Secrets

[ ] No new CONFIG variables are required -OR- the new required ones were added to the helmchart's values.yaml file.
[ ] No new CONFIG variables are required -OR- the new required ones were added to the deployments (pr-preview, dev, demo, prd).
[ ] No new SECRETS variables are required -OR- the new required ones were mentioned in the helmchart's values.yaml file.
[ ] No new SECRETS variables are required -OR- the new required ones were added to the deployments (pr-preview secrets, dev secrets, demo secrets, prd secrets).

Release

[ ] This is not a breaking change.
[ ] This is ready for production.. If your PR is not ready for production, please consider opening additional complementary PRs using this one as the base. Only merge this into develop or main after it's ready for production!

Deployment

[ ] Does the deployment work after merging?

stellar-disbursement-platform-backend-preview is available here:SDP:      https://sdp-backend-pr266.previews.kube001.services.stellar-ops.com/healthAP:       https://sdp-ap-pr266.previews.kube001.services.stellar-ops.com/healthFrontend: https://sdp-backend-dashboard-pr266.previews.kube001.services.stellar-ops.com

stellar-disbursement-platform-backend-preview is available here:SDP:      https://sdp-backend-pr266.previews.kube001.services.stellar-ops.com/healthAP:       https://sdp-ap-pr266.previews.kube001.services.stellar-ops.com/healthFrontend: https://sdp-backend-dashboard-pr266.previews.kube001.services.stellar-ops.com

stellar-disbursement-platform-backend-preview is available here:SDP:      https://sdp-backend-pr266.previews.kube001.services.stellar-ops.com/healthAP:       https://sdp-ap-pr266.previews.kube001.services.stellar-ops.com/healthFrontend: https://sdp-backend-dashboard-pr266.previews.kube001.services.stellar-ops.com

stellar-disbursement-platform-backend-preview is available here:SDP:      https://sdp-backend-pr266.previews.kube001.services.stellar-ops.com/healthAP:       https://sdp-ap-pr266.previews.kube001.services.stellar-ops.com/healthFrontend: https://sdp-backend-dashboard-pr266.previews.kube001.services.stellar-ops.com

stellar-disbursement-platform-backend-preview is available here:SDP:      https://sdp-backend-pr266.previews.kube001.services.stellar-ops.com/healthAP:       https://sdp-ap-pr266.previews.kube001.services.stellar-ops.com/healthFrontend: https://sdp-backend-dashboard-pr266.previews.kube001.services.stellar-ops.com


AMDGPU fails with -low_power 1

When running with vaapi in an amdgpu (at least rdna2), if the -low_power 1 flag is set then transcoding fails with No usable encoding entrypoint found for profile VAProfileH264Main. Removing that flag gets it working. This wasn't happening to me on my previous server with an intel GPU.
It might be good to document this somewhere (documenting how the config file works could be useful too!)
Thanks for building this useful tool :)

There's no config file. You should be configuring this from the Memories admin dashboard.

Ahh interesting- my external go-vod instance wasn't running with hardware acceleration despite being toggled on in the memories admin dashboard (with intel and amd) so I assumed that only applied to the local instance. My solution was to just patch the sources so hardware acceleration was forced on. Similarly I patched the sources to remove the low_power flag to get things working on amd.
I have no experience with nvidia either, but amd supports vaapi and in theory works exactly the same as intel provided the right system packages are installed, but I guess support for the low_power flag is one difference.

Stale


Rebaseline performance tests

@wolfs thanks for the help!

@bot-gradle test and merge please

I've triggered a build for you.


Access and Change Point Light Properties from Model Viewer Scene Graph

Is there any way to access the lights from ModelViewer Scene Graph and Hide/Unhide or Change Intensity of Lights as in the following ExampleGIF?
The GLB model with Point Light was used in the ExampleGIF.
THREE.Js was used to Load the glb model and changing light intensity to 0 and 3.
Is some thing similar possible with Model Viewer? Are the Lights exposed in the model viewer Scene Graph API as the materials?

No, we don't have this functionality yet.

I think this is beyond model-viewer's scope.


df: values in the "Inodes", "IUsed", and "IFree" columns are too low

The values reported in the Inodes, IUsed, and IFree columns are by a factor of 1024 lower than those reported by GNU df.
$ ./target/debug/coreutils df --output=source,itotal,iused,iavail
Filesystem             Inodes        IUsed        IFree
dev                       978            0          977
run                       980            0          979
/dev/sda8               28416          966        27449
tmpfs                     980            0          980
tmpfs                    1024            0         1023
/dev/sda2                   0            0            0
tmpfs                     196            0          195

$ df --output=source,itotal,iused,iavail
Filesystem       Inodes  IUsed    IFree
dev             1001714<PHONE_NUMBER>
run             1003691<PHONE_NUMBER>
/dev/sda8      29097984<PHONE_NUMBER>8409
tmpfs           1003691<PHONE_NUMBER>
tmpfs           1048576     43  1048533
/dev/sda2             0      0        0
tmpfs            200738     81   200657

Looks like you're right. I was wondering whether it has anything to do with the BLOCK_SIZE environment variables, but that doesn't seem to be the case. With GNU, the I* columns all seem to ignore those variable.