ENH: enable specifying custom conda channels + create env via environment.yml

This PR adds the basic functionality to specify a list of custom conda channels using a new key in the JSON config file; the associated feature request issue is #405
This actually looks fairly clean to me (and works for me), but there are probably some things that the core devs will know that I haven't thought of
I suspect the way the channels are added may need slight modification -- installing packages is done in a single call to conda for performance reasons, and we may wish to do the same for adding channels (I currently loop over the input channels as you can see)
need for tests? -- make sure this works when adding a single vs. multiple custom channels? mock the call to those channels? how much of a pain would this be to do? Maybe there's something simpler that can be done test-wise.

Coverage remained the same at 86.553% when pulling 8902fb1925b85b4c7d93cf4de6a4a03ed33f8a55 on MDAnalysis:conda_channels_upstream into 2320b0f89e67be4989446dbe161883671bdb202b on spacetelescope:master.

AppVeyor succeeded; all travis tests pass except for Python 3.3, which I don't understand.

need for tests? -- make sure this works when adding a single vs. multiple custom channels? mock the call to those channels? how much of a pain would this be to do? Maybe there's something simpler that can be done test-wise.

You can check the created ~/.condarc yaml file. As long channels are added you are fine. This also saves you from writing a mock.

I suspect the way the channels are added may need slight modification -- installing packages is done in a single call to conda for performance reasons, and we may wish to do the same for adding channels (I currently loop over the input channels as you can see)

You can also directly modify ~/.condarc but the calls to add a channel are usually fast and I do not expect that  people want to add 100 different channels.
Otherwise I like this addition since conda-forge packages a lot of dependencies for projects that are not available on the default channel.

@tylerjereddy this will always keep the default channel. I never removed that one myself but for others it might be useful to allow removing it and only use custom channels

@kain88-de The latest commit includes a draft unit test for verifying the addition of channels via probing the output of conda info -- which I think just probes the ~/.condarc data anyway.
One major drawback of this approach is that it touches the actual ~/.condarc on a users' machine if they run the unit test suite. Can we avoid this?
I think I also overestimated the sophistication of what is going on--although my unit test creates two separate environments for two versions of Python, all that really seems to happen is that global conda settings on a given machine are modified by asv and then used for those environments.
I think I was originally envisioning more isolation for the environments, but if my interpretation is correct, I'm not even sure we need to create the environments for this unit test (though it may not hurt) -- it seems the main thing is just to check that the machine conda settings have been adjusted appropriately.

Coverage increased (+0.07%) to 86.626% when pulling 81e85ec8395c0adf2a79788b4336d86770657a53 on MDAnalysis:conda_channels_upstream into 2320b0f89e67be4989446dbe161883671bdb202b on spacetelescope:master.

One major drawback of this approach is that it touches the actual ~/.condarc on a users' machine if they run the unit test suite. Can we avoid this?

You can be specifying which  channel a package should be installed from. Then you can call conda install -c custom_channel package. But that requires to change the way conda packages are installed and how to specify a package.

The config setting looks OK on a quick look. Add the empty list value in
https://github.com/spacetelescope/asv/blob/master/asv/config.py#L21 and
remove the try-except check.
Changing ~/.condarc cannot be done, so some other approach should be
used to inform conda to what to use.

Conda has a feature to share environments . What would prohibit us from using that feature directly? It allows to specify the channels I'm using as well as the packages with optional version tracking.  Installation can still be done in a single step here.
Here is the environment file for my own mdanalysis environment.
name: mda
channels:
- kain88-de
- bioconda
- conda-forge
- defaults
dependencies:
- biopython=1.70=np112py36_0
- joblib=0.9.3=py36_0
- typing=<IP_ADDRESS>=py36_0
- alabaster=0.7.10=py36_0
- apipkg=1.4=py36_0
- asn1crypto=0.22.0=py36_0
- babel=2.3.4=py36_0
- blas=1.1=openblas
- ca-certificates=2<IP_ADDRESS>=0
- certifi=2<IP_ADDRESS>=py36_0
- cffi=1.10.0=py36_0
- chardet=3.0.2=py36_1
- coverage=4.4.1=py36_0
- cryptography=1.9=py36_0
- curl=7.54.1=0
- cycler=0.10.0=py36_0
- cython=0.26=py36_0
- dbus=1.10.10=3
- decorator=4.1.2=py36_0
- docutils=0.13.1=py36_0
- execnet=1.4.1=py36_0
- expat=2.2.1=0
- fontconfig=2.12.1=4
- freetype=2.7=1
- gettext=0.19.7=1
- glib=2.51.4=0
- griddataformats=0.3.3=py36_0
- gst-plugins-base=1.8.0=0
- gstreamer=1.8.0=2
- hdf4=4.2.12=0
- hdf5=1.8.18=0
- hypothesis=3.11.6=py36_0
- icu=58.1=1
- idna=2.5=py36_0
- imagesize=0.7.1=py36_0
- ipython=6.1.0=py36_0
- ipython_genutils=0.2.0=py36_0
- jedi=0.10.2=py36_0
- jinja2=2.9.5=py36_0
- jpeg=9b=0
- krb5=1.14.2=0
- libffi=3.2.1=3
- libiconv=1.14=4
- libnetcdf=<IP_ADDRESS>=5
- libpng=1.6.28=0
- libssh2=1.8.0=1
- libtiff=4.0.6=7
- libxcb=1.12=1
- libxml2=2.9.4=4
- markupsafe=1.0=py36_0
- matplotlib=2.0.2=py36_1
- mmtf-python=1.0.7=py36_0
- msgpack-python=0.4.8=py36_0
- ncurses=5.9=10
- netcdf4=1.2.9=np112py36_0
- networkx=1.11=py36_0
- nose=1.3.7=py36_2
- numpy=1.12.1=py36_blas_openblas_200
- olefile=0.44=py36_0
- openblas=0.2.19=2
- openssl=1.0.2l=0
- pandas=0.20.3=py36_1
- patsy=0.4.1=py36_0
- pcre=8.39=0
- pexpect=4.2.1=py36_0
- pickleshare=0.7.3=py36_0
- pillow=4.2.1=py36_0
- pip=9.0.1=py36_0
- prompt_toolkit=1.0.15=py36_0
- ptyprocess=0.5.2=py36_0
- py=1.4.34=py36_0
- pycparser=2.18=py36_0
- pygments=2.2.0=py36_0
- pyopenssl=16.2.0=py36_0
- pyparsing=2.2.0=py36_0
- pyqt=5.6.0=py36_4
- pysocks=1.6.7=py36_0
- pytest=3.2.0=py36_0
- pytest-cov=2.5.1=py36_0
- pytest-xdist=1.18.2=py36_0
- python=3.6.2=0
- python-dateutil=2.6.1=py36_0
- pytz=2017.2=py36_0
- qt=5.6.2=3
- readline=6.2=0
- reportlab=3.4.0=py36_0
- requests=2.18.3=py36_0
- scikit-learn=0.18.2=np112py36_blas_openblas_200
- scipy=0.19.1=py36_blas_openblas_201
- seaborn=0.8.0=py36_0
- setuptools=36.2.2=py36_0
- simplegeneric=0.8.1=py36_0
- sip=4.18=py36_1
- six=1.10.0=py36_1
- snowballstemmer=1.2.1=py36_0
- sphinx=1.6.3=py36_0
- sphinxcontrib-websupport=1.0.1=py36_0
- sqlite=3.13.0=1
- statsmodels=0.8.0=np112py36_0
- tk=8.5.19=2
- tornado=4.5.1=py36_0
- traitlets=4.3.2=py36_0
- urllib3=1.21.1=py36_1
- wcwidth=0.1.7=py36_0
- wheel=0.29.0=py36_0
- xorg-libxau=1.0.8=3
- xorg-libxdmcp=1.1.2=3
- xz=5.2.2=0
- zlib=1.2.11=0
- libgfortran=3.0.0=1
- llvmlite=0.19.0=py36_0
- numba=0.34.0=np112py36_0
- pip:
  - ipython-genutils==0.2.0
  - prompt-toolkit==1.0.15
prefix: /home/max/anaconda3/envs/mda

It looks like sharing environments requires access to an environment.yml file and the docs even suggest emailing that file to another person that wants to use the same environment, which doesn't seem like a suitable automated / general approach for environment generation in asv.
If conda install -c channel_1 channel_2 channel_3 package  were possible, that might be a clean approach, since you could just use the custom channels in the specified priority order without modifying condarc.
However, it seems that you can only specify a single channel this way (i.e., the one you want to use for the specified package), so the -c flag approach (as I think @kain88-de suggests) would appear to require specification of a more complex dependency matrix that associates every required package with its cognate channel; the asv JSON file may get pretty gruesome with a dictionary-style association like this.

It looks like sharing environments requires access to an environment.yml file and the docs even suggest emailing that file to another person that wants to use the same environment, which doesn't seem like a suitable automated / general approach for environment generation in asv.

It should be possible to place this into the asv config file. I would also expect I can generate such a file from the current asv config files. Also with your suggested additions to specify a channel.

You should be able generate a temporary environment.yml that is used in
the environment creation.

Ok, so I think I understand the proposed route forward -- programmatically generate environment.yml from the asv config, including channels in the specified priority order.
A user could specify nodefaults as a channel to exclude the default channel without us having to add another JSON flag for that functionality, as documented for the .yml conda file.

The suggested solution might break existing workflows for people who implicitly depend on the conda channels they define in their own .condarc. Personally I like using a environment file better because it leads to better reproducible  environments. So this change should be mentioned more explicit in the release notes.

Coverage increased (+0.07%) to 86.626% when pulling 934c79404eaeeb38da077864233ce357b708a361 on MDAnalysis:conda_channels_upstream into 2320b0f89e67be4989446dbe161883671bdb202b on spacetelescope:master.

I started hacking away at the usage of an environment.yml file in the latest commit. I only get about three test failures locally, but there is definitely still a little more design / thought needed I think.
A common thing I see is this: "CondaValueError: Value error: prefix already exists: /Users/treddy/miniconda2/envs/conda-py2.7-colorama0.3.6-six"
And indeed, conda env list does get polluted with the new environments that are created during the tests. I think there's a flag to force the creation if the env already exists, but probably not the way to go.
Should we try to clean up the environment names after the tests /benchmarks run? I'm slightly concerned about the fragility of this approach--i.e., that the cleanup may not happen if an end-user has a test failure before it can happen & indeed the simple fact of modifying a users' conda env list is perhaps problematic in general (is there a nice trick to avoid this completely?).
Perhaps specifying the full path to the environment prefix for conda env create & using a temp dir of some sort could prevent polluting i.e. the local env list?

It's looks like it's creating the envs to the wrong place, they should go
to self._path. Conda create had a -p option. Can that be used with
environment.html?
29.8.2017 1.47 "Tyler Reddy"<EMAIL_ADDRESS>kirjoitti:
I started hacking away at the usage of an environment.yml file in the
latest commit. I only get about three test failures locally, but there is
definitely still a little more design / thought needed I think.
A common thing I see is this: "CondaValueError: Value error: prefix already
exists: /Users/treddy/miniconda2/envs/conda-py2.7-colorama0.3.6-six"
And indeed, conda env list does get polluted with the new environments that
are created during the tests. I think there's a flag to force the creation
if the env already exists, but probably not the way to go.
Should we try to clean up the environment names after the tests /benchmarks
run? I'm slightly concerned about the fragility of this approach--i.e.,
that the cleanup may not happen if an end-user has a test failure before it
can happen & indeed the simple fact of modifying a users' conda env list is
perhaps problematic in general (is there a nice trick to avoid this
completely?).
Perhaps specifying the full path to the environment prefix for conda env
create & using a temp dir of some sort could prevent polluting i.e. the
local env list?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/spacetelescope/asv/pull/539#issuecomment-325504635,
or mute
the thread
https://github.com/notifications/unsubscribe-auth/AACI5jqeO7T-8lEN33eUL4ncGiQ2oToAks5sc0OHgaJpZM4OtERc
.

Looks like it can. I'm down to two (local) test failures now: test_conda_pip_install & test_continuous. Hopefully I can take a closer look at those two issues soon.
conda env list no longer gets polluted by running the test suite now

I was able to resolve one test failure related to an open conda bug where pip needs to be specified as a dependency within environment.yml. Actually, the latter conda bug is labelled as an easy fix, but might be a bit much at this stage to go even farther upstream fixing issues.
Anyway, that's good, we're a tiny bit closer. I note that the total number of failures in the test suite does differ a bit for the same commit hash on different operating systems sometimes, at least for this PR branch.

I've patched all 7 test failures on a linux machine with the latest changes -- let's see how the continuous integration works out now.

Coverage decreased (-0.1%) to 86.41% when pulling ab27cb9424d9569201a4f6cccce34181a7e3fc50 on MDAnalysis:conda_channels_upstream into 2320b0f89e67be4989446dbe161883671bdb202b on spacetelescope:master.

Coverage decreased (-0.3%) to 86.265% when pulling d1ccaf672a9564307251c50ff0335db186d0da4c on MDAnalysis:conda_channels_upstream into 2320b0f89e67be4989446dbe161883671bdb202b on spacetelescope:master.

Both Travis and AppVeyor builds are passing. At this stage, I think at the very least we need:

cleanup of affected function names and comments / docs -- in a few places I've repurposed a function without changing its name to reflect this, and some comments probably need adjustment as well
the original unit test I added is probably out of date now -- an appropriate / updated version should be written and then the test can be reactivated
we might want to think about one or two more test cases; indeed, there is currently a modest drop in test coverage

Still, I think the basic functionality is here now.

Although the tests pass, as I try to write a specific test for channel addition, I'm noticing that environment.yml does not show up in self._path when I check on my machine after local tests. I can see asv-env-info.json there & the code to write the two files looks relatively similar to me, but there must be something tricky about writing files to the environment.
Furthermore, the environment creation command must be working for the tests to pass, and I can open the environment.yml file from within plugins/conda.py after creating it to print the contents, but not from within the test suite or when manually cd'ing to the directory in /tmp.

I've updated the new tests to reflect the desired / enforced behavior. I note that environment.yml is actually obliterated from the env by the --force flag I used in conda env create to avoid certain test error scenarios where a conda env already existed. This is mostly a side-effect of the behavior that allows the unit tests to all pass & removing the yml file from the env is not necessarily something I was aiming to do. We could possibly take measures to restore it after if this is considered important (it may be useful residual info to have in the env folder).
One of the new unit tests verifies that the order of channels that is specified for environment.yml is respected when installing packages. I note that actually parsing which channels are added by asv to the env was rather tricky. conda info doesn't seem applicable (indeed I think we actually want to avoid modifying this data just as we want to avoid touching condarc), and I actually ended up parsing the json data from conda list within the env to find the source channels used to install those packages. That's the best approach I've found so far.
Let's see what the CI says now.

Coverage increased (+0.4%) to 86.949% when pulling 47cfa6d938e15e088d74d6c1ca30d63888172307 on MDAnalysis:conda_channels_upstream into 2320b0f89e67be4989446dbe161883671bdb202b on spacetelescope:master.

Coverage increased (+0.3%) to 86.81% when pulling dd0fea0bd2cfb6d205a33ab4024aeab7259c3b72 on MDAnalysis:conda_channels_upstream into 2320b0f89e67be4989446dbe161883671bdb202b on spacetelescope:master.

Note that the method names need to be changed ---
_install_requirements does not actually install requirements, and
_add_channels does not add channels. I'd include the _add_channels
in the body of _setup without a separate method. What
_install_requirements does sounds more like _get_requirements.
mkdir_p should not be needed, the path is guaranteed to already exist
when _setup is called. If it's really needed, it should go in util.py
You can also write some of the file generation stuff simpler, e.g.,
+            env_file.write('dependencies:\n'
+                           '   - python={0}\n'
+                           '   - wheel\n'
+                           '   - pip\n'.format(self._python))

Note how strings can be split to multiple lines and that parenthesis is
not needed before .format.
Instead of using create --force wouldn't it be better to create the
environment.yml as a temporary file? Like so:
with tempfile.NamedTemporaryFile() as env_file:
     env_file.write(...)
     ...
     env_file.flush()
     util.check_output([conda, 'env', 'create', '-f', env_file.name] + ...)

Ok, I think I've addressed most of the comments. I suspect there will still be an issue with the AppVeyor test--not exactly sure what the problem there is yet, but perhaps something quite simple involving windows paths.

Coverage increased (+0.2%) to 86.748% when pulling 9aa7123aac94352bfce0e14d2bced2d2281b3731 on MDAnalysis:conda_channels_upstream into 2320b0f89e67be4989446dbe161883671bdb202b on spacetelescope:master.

Coverage increased (+0.2%) to 86.753% when pulling e0d9977ee916280b84e11dcb854c1235dab0f8ee on MDAnalysis:conda_channels_upstream into 2320b0f89e67be4989446dbe161883671bdb202b on spacetelescope:master.

Travis stuff mostly looks ok -- one strange failure for Python 3.5 only -- is that real?
I adopted the proposed NamedTemporaryFile  solution, but I don't understand how you are planning to overcome the platform-specific limitation here -- conda env create won't be able to access the file name for opening a second time on Windows as the std lib docs indicate

There's an open bug report in for CPython for this portability issue; looks like it is targeted for Python 3.7 maybe. Basically, you can open the tempfile a second time in the context manager on unix but not on Windows.
@pv my suggestion is that we use NamedTemporaryFile(mode='w', delete=False) so that the tempfile is not actually deleted after the context manager control flow exits, and then we move the conda env create call outside of the context manager. This is far less Pythonic, and kind of defeats the purpose of using a tempfile, but it does circumvent the issue, and eventually we can use the more Pythonic approach when this gets patched in CPython and platform portability is restored.

We may also have to switch back to using --force with conda as well, because we won't be able to leverage the cleanup of the tempfile if we use delete=False.

I've pushed the attempted windows compatibility changes despite the issues discussed above -- let's see what happens with the CI now.

Coverage increased (+0.2%) to 86.753% when pulling c465ea64df83d5cb8ef132e8cb00651cf56bd07a on MDAnalysis:conda_channels_upstream into 2320b0f89e67be4989446dbe161883671bdb202b on spacetelescope:master.

So, less issues now:

All Windows builds have only two failures, both for the same unit test because of conda list -p env._path --json failing on that platform for whatever reason (file path handling needs to be done more carefully in that unit test maybe?)
only the Python 2.6 Travis test suite has a single failure; all others pass -- looks like an issue with pip wheel in Python 2.6

Coverage increased (+0.5%) to 87.041% when pulling 351f64fbe90ba6db16e1a3feca33d9785363cda6 on MDAnalysis:conda_channels_upstream into 2320b0f89e67be4989446dbe161883671bdb202b on spacetelescope:master.

util.check_output([conda, 'list']) is sufficient to trigger the missing file failure on Windows. Now testing to see what path for conda is being used on Windows, but whatever the path, it is already clear that os.path.normpath() is not sufficient to make it work on that platform.

Coverage increased (+0.2%) to 86.763% when pulling d6d52b255c1adbcc30e3903acf29829ce6f75242 on MDAnalysis:conda_channels_upstream into 2320b0f89e67be4989446dbe161883671bdb202b on spacetelescope:master.

Coverage increased (+0.2%) to 86.767% when pulling 5b7e1a6b6da0ab063899dbd5d02d8fdde2b39f4a on MDAnalysis:conda_channels_upstream into 2320b0f89e67be4989446dbe161883671bdb202b on spacetelescope:master.

Coverage increased (+0.2%) to 86.782% when pulling 46ddd9c102be7bd51dfbfaa31471e08413119558 on MDAnalysis:conda_channels_upstream into 2320b0f89e67be4989446dbe161883671bdb202b on spacetelescope:master.

So, env._path exists as expected on the Windows / AppVeyor builds, but the bin subdirectory does not. I'm not sure if a symlink to the conda executable is being created within (another subdir of) env._path on Windows, but I'm pretty sure that the unix builds do create a symlink to conda executable somewhere (I remember seeing it when debugging).
There is a conda-meta entry in env._path on windows. I can take a peek in there.
My current suspicion is that env.find_executable() may need to be modified to point to the proper Windows executable for conda, because what it gives me now doesn't exist. There is a comment in the latter function referencing a standard conda layout, which is perhaps now no longer the case with my modifications, but it could also be something more confusing.

Coverage increased (+0.5%) to 87.02% when pulling 3e39556a896971923c8ae1ef513e8eaf3d19141f on MDAnalysis:conda_channels_upstream into 2320b0f89e67be4989446dbe161883671bdb202b on spacetelescope:master.

My debug work indeed indicates that there's a conda file (probably a symlink type thing) in the Scripts dir on Windows / AppVeyor when building an env. asv assumes that the executable for conda on windows will have an exe extension in the env and reside in either the env root or the Scripts subdirectory, based on the code in find_executable. Since this is not the case in the current AppVeyor builds, asv falls back to assuming that we have a unix configuration with a bin path instead, but it is in fact a Windows build that appears to have a conda executable without an exe extension.
So, I'll aim to try to patch find_executable to handle this scenario. I'm not clear on whether this is genuinely related to anything I've changed rather than simply the current tests don't probe this issue, but I think the logical fix is becoming clearer now.

Maybe related: https://github.com/spacetelescope/asv/pull/525

Maybe the minimal thing would be to add a paths=None argument that
takes a list of paths [with default value
os.environ['PATH'].split(os.pathsep)] to util.which so that the thing is
done only in a single place.

So you're suggesting it would be more appropriate to use util.which than find_executable in my unit test to probe for conda, and to modify util.which for increased flexibility if needed? find_executable doesn't seem to directly interact with util.which, so I'm guessing that changing the latter won't affect the current test.

find_executable should be implemented using util.which(executable,
paths=[...]), so that the logic of appending exe, bat, etc. on Windows
is not duplicated in many places.

Coverage increased (+0.3%) to 86.877% when pulling 36540bbb27234c25d4b29fa1e79b72305ea9139d on MDAnalysis:conda_channels_upstream into 2320b0f89e67be4989446dbe161883671bdb202b on spacetelescope:master.

Coverage increased (+0.3%) to 86.897% when pulling cb02a12759377a5b55756f51e4803fb59300c866 on MDAnalysis:conda_channels_upstream into 2320b0f89e67be4989446dbe161883671bdb202b on spacetelescope:master.

Coverage increased (+0.5%) to 87.041% when pulling cb02a12759377a5b55756f51e4803fb59300c866 on MDAnalysis:conda_channels_upstream into 2320b0f89e67be4989446dbe161883671bdb202b on spacetelescope:master.

Coverage increased (+0.5%) to 87.046% when pulling 959093874f7576c1632f4e557b5a6b6e02089519 on MDAnalysis:conda_channels_upstream into 2320b0f89e67be4989446dbe161883671bdb202b on spacetelescope:master.

Coverage increased (+0.4%) to 86.906% when pulling d20e472d3320206d6d977c7c7100e8b73b7c36a4 on MDAnalysis:conda_channels_upstream into 2320b0f89e67be4989446dbe161883671bdb202b on spacetelescope:master.

Coverage increased (+0.3%) to 86.875% when pulling 84b0d1783ea145677026f1619a1db4c41095f59c on MDAnalysis:conda_channels_upstream into 2320b0f89e67be4989446dbe161883671bdb202b on spacetelescope:master.

Note that it may be faster to grab a windows VM and debug locally, than triaging it via appveyor:
https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/
https://developer.microsoft.com/en-us/windows/downloads/virtual-machines

I noticed that on a Windows machine test_matrix_environments() can be forced to use the python.exe within self._path with some minor changes. However, even with this adjustment, the libraries installed match the system rather than the environment if probed using the above python.exe. Further evidence that the system (or root / other conda) python is effectively being used by this test include variabilities in the library causing the version check failure when comparing AppVeyor test builds with builds on my Windows 10 machine / powershell.
That said, there is evidence that the original conda env create was done correctly because I can manually go into the pertinent tmp path on Windows and probe the expected library versions using conda list -p (self._path).
What does this mean? Should there be a separate python.exe in the Scripts subfolder on windows? I'm only seeing one in the env self._path, and while the version of Python that is used does match the matrix, the version of the conda-installed libraries does not reflect the dependency matrix of the env (and probing the paths of these python libraries also doesn't match the env).
I think I'm slightly confused by the raw python -c calls in this unit test. I'm assuming we don't need to actually 'activate env' via conda  (there is no such call in the source anywhere) on the basis that the Python executable that is found is the one that would normally be 'activated' in any case, but I must be missing a little something here. This unit test is also rather prone to accidental passing since the system install of python could just happen to have dependency version matches to the env.

Coverage increased (+0.2%) to 86.736% when pulling 61feb6b7182a9952362b8941fbb1787c22f142c9 on MDAnalysis:conda_channels_upstream into 2320b0f89e67be4989446dbe161883671bdb202b on spacetelescope:master.

all the tests are passing on all platforms except for a single fail on Python 2.6 -- that failure I don't really understand, but it is an unsupported version of Python anyway
there are maybe one or two debug-related lines of code that should be removed, but the rest should be looking pretty solid now
we could maybe add the unit tests from the issue @pv linked above and ensure that we handle those file types as well, although that could also be considered a separate issue which is only partly addressed here to obtain the desired functionality, which was really only supposed to be custom conda channel support

Coverage increased (+0.5%) to 87.019% when pulling fab148e641634c9e800541180a327fea81fb9746 on MDAnalysis:conda_channels_upstream into 2320b0f89e67be4989446dbe161883671bdb202b on spacetelescope:master.

ok, fixed those myself now that I'm at it.

Coverage increased (+0.5%) to 87.009% when pulling 7017be285d656afc71ab00c80beeaee4a325b743 on MDAnalysis:conda_channels_upstream into 2320b0f89e67be4989446dbe161883671bdb202b on spacetelescope:master.

Coverage decreased (-0.1%) to 86.867% when pulling a510b9b68963ff32246f516714887151c2e9186f on MDAnalysis:conda_channels_upstream into 1108957f59a0773d59ea5a4fc4ca381b2d47cff0 on spacetelescope:master.

Still needs:

adding documentation to docs/source/asv.conf.json.rst
adding the option to asv/template/asv.conf.json

Thanks for taking care of those! I pushed first draft documentation changes for the files you requested.

Coverage decreased (-0.1%) to 86.892% when pulling ae4434f3bbc375700bb298e252bb9d32b947a640 on MDAnalysis:conda_channels_upstream into 1108957f59a0773d59ea5a4fc4ca381b2d47cff0 on spacetelescope:master.

Coverage increased (+0.2%) to 87.034% when pulling 85f68a4dc53466c3a130c1ca6da99c2fffa646d8 on MDAnalysis:conda_channels_upstream into 68ff232cb49c5ade3b74665351df6501735ffff2 on spacetelescope:master.

Rebased and squashed, will still have to test on windows (separately, since appveyor doesn't seem to be on a cooperative mood)

Coverage increased (+0.01%) to 86.892% when pulling ec826e2b0a528cff0bed7b7be3b4065c6c924c82 on MDAnalysis:conda_channels_upstream into 68ff232cb49c5ade3b74665351df6501735ffff2 on spacetelescope:master.

Coverage increased (+0.01%) to 87.034% when pulling bc728557b2e3abc51a7255f7a43348af5f19f85a on MDAnalysis:conda_channels_upstream into 2e34f67e384e80f8ab5af7fb41f8fa0cfefc0a02 on spacetelescope:master.

The AppVeyor tests all pass now too. I note that on my Windows 10 machine I still get the 1 unit test failure I describe above involving test_matrix_environments.
I think my basic conclusion was that the conda env site package libs weren't always being used by the python executable in the env created by this test even though conda list -p self._path listed the correct dependency versions for the env.
Maybe it is ok since AppVeyor isn't reproducing this. For completeness, pytest traceback:
================================== FAILURES ===================================
__________________________ test_matrix_environments ___________________________

tmpdir = local('c:\\users\\treddy\\appdata\\local\\temp\\pytest-of-treddy\\pytest-45\\test_matrix_environments0')

    @pytest.mark.skipif(not ((HAS_PYTHON_27 and HAS_PYTHON_34) or HAS_CONDA),
                        reason="Requires Python 2.7 and 3.4")
    def test_matrix_environments(tmpdir):
        conf = config.Config()

        conf.env_dir = six.text_type(tmpdir.join("env"))

        conf.pythons = ["2.7", "3.4"]
        conf.matrix = {
            "six": ["1.10", None],
            "colorama": ["0.3.6", "0.3.7"]
        }
        environments = list(environment.get_environments(conf, None))

        assert len(environments) == 2 * 2 * 2

        # Only test the first two environments, since this is so time
        # consuming
        for env in environments[:2]:
            env.create()

            output = env.run(
                ['-c', 'import six, sys; sys.stdout.write(six.__version__)'],
                valid_return_codes=None)
            if 'six' in env._requirements:
>               assert output.startswith(six.text_type(env._requirements['six']))
E               AssertionError: assert False
E                +  where False = <built-in method startswith of unicode object at 0x000000000419F060>('1.10')
E                +    where <built-in method startswith of unicode object at 0x000000000419F060> = '1.11.0'.startswith
E                +    and   '1.10' = <type 'unicode'>('1.10')
E                +      where <type 'unicode'> = six.text_type

If I manually check:
PS C:\users\treddy\appdata\local\temp\pytest-of-treddy\pytest-45\test_matrix_environments0\env\d26ca092d5e1c69bb963927c9c813a5e> .\python.exe
Python 2.7.13 |Continuum Analytics, Inc.| (default, May 11 2017, 13:17:26) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
Anaconda is brought to you by Continuum Analytics.
Please check out: http://continuum.io/thanks and https://anaconda.org
>>> import six
>>> six.__path__
[]
>>> import colorama
>>> colorama.__path__
['C:\\users\\treddy\\appdata\\local\\temp\\pytest-of-treddy\\pytest-45\\test_matrix_environments0\\env\\d26ca092d5e1c69bb963927c9c813a5e\\lib\\site-packages\\colorama']
>>> six.__version__
'1.11.0'
>>> colorama.__version__
'0.3.6'
>>> help(six)

Help on package six:

NAME
    six - Utilities for writing code that runs on Python 2 and 3

FILE
    c:\users\treddy\appdata\roaming\python\python27\site-packages\six-1.11.0-py2.7.egg\six.py

Looks like the env version of colorama is used, but not the case for six. The env packages are as expected though (including the version of six the unit test is looking for but doesn't find):
PS C:\users\treddy\appdata\local\temp\pytest-of-treddy\pytest-45\test_matrix_environments0\env\d26ca092d5e1c69bb963927c9c813a5e> conda list -p .
# packages in environment at C:\users\treddy\appdata\local\temp\pytest-of-treddy\pytest-45\test_matrix_environments0\env\d26ca092d5e1c69bb963927c9c813a5e:
#
certifi                   2016.2.28                py27_0
colorama                  0.3.6                    py27_0
pip                       9.0.1                    py27_1
python                    2.7.13                        1
setuptools                36.4.0                   py27_1
six                       1.10.0                   py27_0
vs2008_runtime            9.00.30729.5054               0
wheel                     0.29.0                   py27_0
wincertstore              0.2                      py27_0

Is Windows 10 newer than what is used in the current AppVeyor matrix? I suspect the actual issue is my usage of powershell instead of CMD --  I'm using a solution desribed in an open conda issue for environment handling in this currently problematic scenario (powershell + Windows 10 + conda). So, perhaps we can consider that a conda issue or not critical.
In short, it seems that official conda versions don't support environment activation / control in powershell + Windows 10 at the moment, but there are some work-arounds described above. I'm not sure if that is really the source of the issue (I suppose if I test on CMD instead of powershell and everything passes that would be enlightening).

The six on your machine looks like it comes from a --user installed
package.

This actually looks like a conda bug (would maybe be useful to report to
them):
$ conda create -n foo python=3.6
...
$ source activate foo
$ python
Python 3.6.2 |Continuum Analytics, Inc.| (default, Jul 20 2017, 13:51:32)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
 >>> import sys
 >>> sys.path
['', '/home/pauli/.local/lib/conda/envs/foo/lib/python36.zip',
'/home/pauli/.local/lib/conda/envs/foo/lib/python3.6',
'/home/pauli/.local/lib/conda/envs/foo/lib/python3.6/lib-dynload',
'/home/pauli/.local/lib/python3.6/site-packages',
'/home/pauli/.local/lib/conda/envs/foo/lib/python3.6/site-packages']
#
# Note that /home/pauli/.local/lib/python3.6/site-packages
# appears in sys.path. This seems to only occur on Python 3.6.
#

Ok, I've opened the issue on the conda github (cross-ref'd above) after confirming on my machine that this doesn't happen with Python 2.7 or 3.5, so does indeed appear to be 3.6 only as you suggest. I offered to help them patch it if they want to guide me.
I didn't observe any other issues running the full asv testsuite on Win 10 / powershell.

Thanks, merged!

Note that I can reproduce the issue on Python 2.7 if I install with --local packages before creating an env there as well. Anyway, I'll carry on that discussion with the conda team I guess.

Ok, I've closed the conda issue -- note that the usage of export PYTHONNOUSERSITE=True solves our problem and the default behavior of Python is to include the site packages in the manner we have both observed (see discussion in the conda issue & links therein).
There are probably other ways to exclude the site packages as well so that conda behaves more like virtualenv, which is probably what we want in asv. Without such a setting / suppression of local site packages, there is some risk that running the conda components of the asv testsuite locally will produce different results than in containerized CI tests where there are no local site packages that may pollute the path.
Is this sufficiently worrying to open another issue for asv so that we have robust site package suppression with conda (i.e., matching isolation of the envs for conda and virtualenv)?

It does not seem that other conda channels than default  are taken into account with the version at the tip of master at the moment.

The tests show otherwise.

That is, it may be then a difference between the environment at hand,
and what the tests use.

The tests appear to be setting the conda_channels from the Python API (and not getting it from the conf.json file).

Opened #657 to track this specific issue.

That should not matter. Indeed, it works correctly also in practice for
me when e.g. setting "conda_channels": ["conda-forge"] in the config
file.
Perhaps you have old environments left over --- it doesn't change the
conda_channels automatically?


Linter Issues for Renamed Class Definitions

Describe the bug
User-defined classes aren't properly linted, causing confusion at best and errors at worst.
To Reproduce

Make a new file testClass.m.
use the classdef snippet, make a new class testClass.
Rename the file to TestClass.m -- the linter doesn't recognize any issues.
Rename the classdef and constructor function to TestClass -- though this is correct and runs as expected, the linter gets angry.

Expected behavior
At step 3, the linter should get angry.
At step 4, the linter should calm down.
Screenshots
The Linter needs to get angry here

and calm here

Useful Information

OS Version: Windows 11
VS Code Version: 1.87.2

Hi @Gusmano-2-OSU , thanks for raising this!
I am having trouble reproducing this behavior on my end. Could you send some additional info to help us determine what is happening?

What MATLAB version are you using?
When you see this behavior when you are connected to MATLAB through the MATLAB extension for VS Code, or when MATLAB is disconnected? If MATLAB is not connected, linting will only update when the file is saved.

r2024a
Matlab is connected via the official MATLAB extension for VS Code.

Could you share a video of this occurring? This may assist with reproducing the issue on our end.

Created file testClass.m (no error, correct)
Wrote classdef named testClass (no error, correct)
Renamed file to TestClass.m (no error, bug)
Renamed classdef to TestClass (error, bug)
Renamed classdef back to testClass (no error, bug)

https://github.com/mathworks/MATLAB-extension-for-vscode/assets/8674612/33b51cf2-0a8d-463e-81d7-faf14fbfab61

Thanks again for sharing these steps! I was able to reproduce this behavior.
It appears that, after the file is renamed, the onDidChangeContent handler is still being provided a TextDocument for which the URI has the old file name.


Regent tests for privileges on fields of regions.

Tests illustrating bugs in privilege handling.

One of the test cases is for https://github.com/StanfordLegion/legion/issues/436

These tests are manually added by a7d75528 with minor modifications.


add analytics hub module

Checklist

I applicable, I acknowledge that I have:

[x] Read the contributing guide
[x] Ran terraform fmt on all modified files
[x] Regenerated the relevant README.md files using tools/tfdoc.py
[x] Made sure all relevant tests pass

Thanks for your review @ludoo. I've raised a separate PR for README in https://github.com/GoogleCloudPlatform/cloud-foundation-fabric/pull/2094


Underflow error

Underflow error. This is happening when using alignments with high values for --outFilterMultimapScoreRange (15 in this case). Probably what is happening is that including more suboptimal alignments results in very very small numbers (probabilities?) and causes underflow. Fix by switching to longdouble in these operations.
Traceback (most recent call last):
  File "/fsx/projects/alignment-tests-for-stellarscope/.snakemake/conda/87c2c9149ad9b04b9e2b40474ecea3d1/bin/stellarscope", line 8, in <module>
    sys.exit(stellarscope())
  File "/fsx/projects/alignment-tests-for-stellarscope/.snakemake/conda/87c2c9149ad9b04b9e2b40474ecea3d1/lib/python3.10/site-packages/stellarscope/__main__.py", line 141, in stellarscope
    args.func(args)
  File "/fsx/projects/alignment-tests-for-stellarscope/.snakemake/conda/87c2c9149ad9b04b9e2b40474ecea3d1/lib/python3.10/site-packages/stellarscope/stellarscope_assign.py", line 332, in run
    st_model = model.fit_pooling_model(st_obj, opts)
  File "/fsx/projects/alignment-tests-for-stellarscope/.snakemake/conda/87c2c9149ad9b04b9e2b40474ecea3d1/lib/python3.10/site-packages/stellarscope/utils/model.py", line 1146, in fit_pooling_model
    st_model = fit_pseudobulk(_scoremat)
  File "/fsx/projects/alignment-tests-for-stellarscope/.snakemake/conda/87c2c9149ad9b04b9e2b40474ecea3d1/lib/python3.10/site-packages/stellarscope/utils/model.py", line 1048, in fit_pseudobulk
    st_model.em(use_likelihood=opts.use_likelihood)
  File "/fsx/projects/alignment-tests-for-stellarscope/.snakemake/conda/87c2c9149ad9b04b9e2b40474ecea3d1/lib/python3.10/site-packages/stellarscope/utils/model.py", line 773, in em
    _z = self.estep(self.pi, self.theta)
  File "/fsx/projects/alignment-tests-for-stellarscope/.snakemake/conda/87c2c9149ad9b04b9e2b40474ecea3d1/lib/python3.10/site-packages/stellarscope/utils/model.py", line 712, in estep
    return _n.norm(1)
  File "/fsx/projects/alignment-tests-for-stellarscope/.snakemake/conda/87c2c9149ad9b04b9e2b40474ecea3d1/lib/python3.10/site-packages/stellarscope/utils/sparse_plus.py", line 51, in norm
    return self._norm(axis)
  File "/fsx/projects/alignment-tests-for-stellarscope/.snakemake/conda/87c2c9149ad9b04b9e2b40474ecea3d1/lib/python3.10/site-packages/stellarscope/utils/sparse_plus.py", line 59, in _norm
    return self.multiply(_recip0(self.sum(1)))
  File "/fsx/projects/alignment-tests-for-stellarscope/.snakemake/conda/87c2c9149ad9b04b9e2b40474ecea3d1/lib/python3.10/site-packages/stellarscope/utils/sparse_plus.py", line 203, in multiply
    return type(self)(super().multiply(other))
  File "/fsx/projects/alignment-tests-for-stellarscope/.snakemake/conda/87c2c9149ad9b04b9e2b40474ecea3d1/lib/python3.10/site-packages/scipy/sparse/_compressed.py", line 470, in multiply
    data = np.multiply(ret.data, other[ret.row].ravel())
FloatingPointError: underflow encountered in multiply

Resolved by 17c8933 and 148e9b2


Check results in ALS as per downstream/upstream instead of per log

[x] If this pull request closes/resolves/fixes an existing issue, replace the issue number. Closes #.
[x] Update the CHANGES log.

Currently the mesh analyzer plugins are invoked on every piece of log, and the plugin chain is terminated as soon as any metrics data is extracted from an previous plugin, this is fine if the upstream/downstream from the log both have or have no metadata, then both side can be analyzed in mx plugin or k8s IP mapping plugin, but if one side has metadata and the other side needs k8s IP mapping plugin, the latter will be skipped as the mx plugin already has part of the metrics, this patch will determine the upstream/downstream metrics are extracted or not, and fallback to the next plugin to extract the missing metrics.

The CI seems broken. Please fix them.


Add Automated Documentation Generation

Replicate the changes that were made in this PR:
https://github.com/dsccommunity/ComputerManagementDsc/pull/318

I going to begin working on this so that we can move these resources to HQRM.


Bot only loads one plugin automatically running under Ubuntu Server

Running Ubuntu Server 18.04 LTS under Python 3.8.2 the bot only loads the "Roles" plugin automatically. Expected behavior (As shown under Windows 10) is that all plugins should load.
Manually running the plugins load command successfully loads the plugins with no issues.
I'm assuming the issue has to do with the stdlib os.etc calls.

Since ee918b7 a second plugin is loading. Wonder what weirdness is going on here.

Appears to be fixed with Ubuntu 20.04? Leaving the issue open as 18.04 is still LTS.

Working correctly as of 30ba46c


Missing coastline in trajectory plot

I have found that for many floats Python code is not displying coastline contours of continents in trajectory plot.
Left plot -Python verion; Right plot- Matlab version

WMO: 3900560; 3901531; 3901985; 4901464; 6901121
Reference data: CTD_for_DMQC_2019V01
WMO boxes: wmo_boxes_ctd.mat
Cal series:
breaks = [] max_breaks = 4 # 0 for linear trend, -1 for offset calseries = np.ones((1, no_profiles)).flatten() # example for splitting time series at profile 33 # calseries = np.concatenate((np.ones((1, 33)), 2 * np.ones(1,no_profiles - 33))) calib_profile_no = profile_no use_percent_gt = 0.5 use_theta_lt = 0 use_theta_gt = 0 use_pres_lt = 0 use_pres_gt = 0

The issue has been solved by wrapping the longitudes of profile and climatology data from 0-360 to -180-180 to correspond to bathymetry data. I keep the geopandas package instead cartopy and harmonica.


refactor(config): reduce size by 53%

Summary
Part of #1263.
This PR reduces by 53% (from 8440 bytes to 3976 bytes) the memory usage of biome.json.
Most of the memory usage comes from the RuleConfiguration type (40 bytes) that is present for every rule. RuleConfiguration is an enum with two variants, thus it takes the size of its biggest variant: RuleWithOptions. Most of the rules have no options, so this is just a waste of memory. This PR replace RuleWithOptions with Box<RuleWithOptions>. This allows reducing RuleConfiguration from 40 bytes to 16 bytes. It is not an ideal fix because Box incurs a heap allocation. However, this only happen when configuring a rule with options (we only have a few one at the moment).
Alternatively, we could add lifetime annotations on every config struct/enums and use a reference instead of a Box.
Another solution could be of exposing the option type of every rule (most of them the type is the unit type ()) and using it in a generic RuleConfiguration type:
pub enum RuleConfiguration<T> {
    Plain(RulePlainConfiguration),
    WithOptions(T),
}

Note: I had to remove Bpaf for rules' configuration because it doesn't support Box.
Test Plan
CI and local test with the CLI.

Why was the serde macro removed? Isn't it necessary anymore?

Why was the serde macro removed? Isn't it necessary anymore?

The serde macro?

Why was the serde macro removed? Isn't it necessary anymore?

Fixed. Sorry about that.


Create a full website with Home, Calculator and Quote pages

Project name: Math magicians - full website
Project description: In this project, a full website for the Math magicians app will be created, consisting of several pages and using the components already created.
Project requirements:
In previous projects, you created the core functionality of the app: a Calculator component. Now you should develop a full website with several pages.

Create a website consisting of 3 pages: Home, Calculator, and Quote.
The general layout should match the given wireframes.
Add your own styles to improve the look and feel.

Use React basic styling (inline styles, importing CSS, and pre-processed CSS files).

For every page, you should create a <Route>.
Make sure that navigation links for all 3 routes are displayed on each page.
Use React Router to make the routes work.

Project requirements link: https://github.com/microverseinc/curriculum-react-redux/blob/main/math-magicians/project_full_website_v2.md

Hi @mikethreels ,
Thank you so much for the review.
Best Regards,
K. Inoulen Shanongba


Create [HACKTOBERFEST 2024] - CSS Grid Quiz #56194

Best 20 Questions for the topic Css grid quiz to get good understanding of the topic
Checklist:

[ ] I have read and followed the contribution guidelines.
[ ] I have read and followed the how to open a pull request guide.
[ ] My pull request targets the main branch of freeCodeCamp.
[ ] I have tested these changes either locally on my machine, or GitPod.

Closes #XXXXX

Kindly remove spam from this file i can delete it if you say so cuz i ddint have any idea what you wanted it was my first time so i was clueless


ISPN-8249 EvictionFunctionalTest.testSimpleExpirationMaxIdle random failure

Fix OffHeapDataContainer.compute() and optimize some other methods
Trigger expired entries processing manually
Drop EvictionFunctionalTest.testMultiThreaded which does not test anything

https://issues.jboss.org/browse/ISPN-8249

@wburns added the null check in evict

Integrated into master, thanks @rvansa !


Unable to run LittleWeeb Client under Ubuntu 18.04

When running with sudo mono LittleWeeb.exe, this appears:
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
I have stacktrace in the debug output too.
Have you considered building a Flatpak or AppImage file for the program? That is a self contained, working program file that contains all necessary software.

First, you are trying to run the mono version of specific windows build version that only runs on windows through the .Net framework (thus not mono) due to using WinForms i.c.m. CefSharp (which is windows only).
You could use LittleWeebServer and run that, which is the console version where  you need to run the interface through a browser of choice on the same machine.
That said, the server is not really.... well how should I put it: In working condition.
Luckily, I dont like to have a separate server version for linux or any other platform, so I went ahead and started messing with ElectronNet (the Net wrapper for electron). This was after that I reworked the whole code base to support C# .Net Core 2.1 which means its cross platform by default and does not require mono.
In the end, I got it working yesterday (little teaser ;) ):

But I am certainly not a linux expert, and there are quite some issues to be fixed to put this version online, although I have a deadline for within two days.
Until then, good luck!

Hi, version 0.4.0 has been released for most platforms: https://littleweeb.github.io/ or https://github.com/littleweeb/Desktop, should fix the issues you were having entirely ;)


Cannot execute cell with error code FODC0002

When executing a cell, the following error is displayed:
XError:Cannot read file c:\Users\Jes%C3%BAs Gonz%C3%A1lez\.vscode\extensions\deltaxml.xpath-notebook-0.0.6\resources\xslt-sef\xpath-eval-to-json.sef.json - ENOENT: no such file or directory, open 'c:\Users\Jes%C3%BAs Gonz%C3%A1lez\.vscode\extensions\deltaxml.xpath-notebook-0.0.6\resources\xslt-sef\xpath-eval-to-json.sef.json'; code:FODC0002
The referenced file is actually there. Probably the problem is related to the username directory having a space character and/or unicode characters.

Thanks for reporting this bug. I'll update this issue as soon as I've reproduced this locally and learnt more.

I've just uploaded a PR (#9) that fixes the issue with a workaround.
The root cause is a bit obscure, because the dumped script was generated properly in the temp dir, and it executed just fine when running nodejs REPL outside vscode, but when run from the extension SaxonJS for some reason just did not handle properly multi-byte characters. This workaround avoids generating the path with multi-byte characters, and therefore circumvents the root cause.

Sorry, I'd coded the fix before seeing your PR.
Your PR converted the path to a URI to resolve the issue. My fix builds a URI in the first place starting with the extension URI rather than the extension path. Both approaches seem to achieve the same result.
I've published the fix (Release 0.0.7) but please let me know if you still encounter problems.

Your fix is working fine, thanks!


Dexter only called once

Expected behaviour
Dexter to ask again for permissions if they are turned off in the app settings after having accepted them
Actual behaviour
When accepting permissions and afterwards turning them off in the settings; I'm expecting Dexter to be called in the onResume method in my BaseActivity. Since there is already a running instance it is called only once.
Steps to reproduce
Accept permissions, go to settings, go back to the app and see that the permissions are not requested in the onResume
@Override
    protected void onResume() {
        super.onResume();

        if (!Dexter.isRequestOngoing()) {
            Dexter.checkPermissions(new MultiplePermissionsListener() {
                @Override public void onPermissionsChecked(MultiplePermissionsReport report) {/* ... */}
                @Override public void onPermissionRationaleShouldBeShown(List<PermissionRequest> permissions, PermissionToken token) {/* ... */}
            }, android.Manifest.permission.READ_EXTERNAL_STORAGE, android.Manifest.permission.WRITE_EXTERNAL_STORAGE, android.Manifest.permission.ACCESS_FINE_LOCATION, android.Manifest.permission.CAMERA);
        }
     }

Version of the library
com.karumi:dexter:2.2.2

Hi @Isabellle
I'm wondering if you are actually implementing the onPermissionRationaleShouldBeShown callback. When the user denies a permission, either through the dialog or the settings, the Android framework gives the app the opportunity to show a rationale to explain your user why do you need that permission.
In the case of Dexter, this callback is called with a token parameter. Once the app has informed the user, the app must use the token to continue the permission request process. If you don't want to show anything at all, you still need to call token.continuePermissionRequest() in order to notify Dexter that you are ready to effectively request the permission(s).
This is explained in the Dexter documentation. If the problem still persists let us know and we'll see if there is something we can do.
Sorry for the delay and thanks for giving us your feedback!

Hi @Isabellle I'd like to know if @Serchinastico's comment was helpful. Can we close this issue or the problem is related with the library implementation?

I switched to an homemade solution. Thanks for your assistance.

I ran into this issue today.  The setup documentation is not very clear and it seems that the helpful "builders" should make this work easier.  Instead you have to setup a "helpful" builder listener and then also setup a listener to take care of this other case, which, imo, doesn't seem to be as helpful as it could be.

What is solution ?


Fix typo 'anlyticsAction'

https://github.com/icssc/AntAlmanac/blob/a720bd636af9da1ada95235c86af2e3f8832cdde/src/components/SectionTable/CourseInfoButton.js#L15
In CourseInfoButton, there was a typo. 'anlyticsAction' is missing an 'a'.
- anlyticsAction
+ analyticsAction

TODO:

Fix the typo in CourseInfoButton.js
Fix the typo everywhere that CourseInfoButton was used
Add analyticsAction and analyticsCategory to CourseInfoButton.propTypes (at the bottom of CourseInfoButton)

I'll take this one!

I'll take this!


Remove rgbShader from my custom note?

Describe your problem here.
Hey all, made a noteskin in 0.6.3, all worked fine, but it seems rgbShader messes with it. I tried this code from ShadowMario:
function onCountdownStarted()
for i = 0, getProperty('unspawnNotes.length') - 1 do
setPropertyFromGroup('unspawnNotes', i, 'rgbShader.enabled', false)
end
end
but, that disabled all notehues. is there a way to disable it just for my custom note?
Thanks!
Are you modding a build from source or with Lua?
Lua
What is your build target?
Windows x64
Did you edit anything in this build? If so, mention or summarize your changes.
None

You're forgetting to check for the note type:
if getPropertyFromGroup('unspawnNotes', i, 'noteType') == 'attackNote' then
			setPropertyFromGroup('unspawnNotes', i, 'rgbShader.enabled', false)
end

An example with My Streets's attack note:
attackNote.lua

Worked like a charm! Thanks so much!


Reply URL will not update in the Jira Addon

I am trying to run Jira in an app proxy and use the SAML App. I followed the advice given in https://github.com/MicrosoftDocs/azure-docs/issues/5192. I made the changes in the Azure app, however when I resolve the Metadata URL in Jira, the Reply URL is not updating. Is there any way to clear the values in the Jira Addon? I tried a reinstall and it did not work.
When I try to Login with Azure AD in Jira I get "Invalid response. Invalid certificate recieved in response. Please contact your Azure AD admin."
Thanks

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: d38cad90-6574-38c2-3262-059a9f975064
Version Independent ID: dd08d5c5-65a4-c2cc-8b51-7a35268dde68
Content: Tutorial: Azure Active Directory integration with JIRA SAML SSO by Microsoft
Content Source: articles/active-directory/saas-apps/jiramicrosoft-tutorial.md
Service: active-directory
GitHub Login: @jeevansd
Microsoft Alias: jeedes

@mwabbe12 Thanks for your feedback! We will investigate and update as appropriate.

@mwabbe12 This is not a supported scenario today. Your JIRA server should have HTTPS enabled otherwise the plugin will not able to populate the values with HTTPS. But we are trying to provide an update to this plugin so that we will allow you to update some of these URLs manually and that way you can get this working.
The work is already in progress and should be our by next month.

@jeevansd Jira is HTTPS enabled, I agree it would be nice to modify those URLs manually, however the URLs do not match between the Azure app and the Jira Add-on. Pressing Resolve is not fetching my changes in the Azure app.

Can you please write your issue details to our alias and then we can help you up<EMAIL_ADDRESS>

@mwabbe12 We have fixed this issue in our new plugin. Also we have updated the article to show how to configure your server in this scenario. So please try again.

#please-close


Improve pvlib.spa speed

[x] I am familiar with the contributing guidelines
[x] Adds description and name entries in the appropriate "what's new" file in docs/sphinx/source/whatsnew for all changes. Includes link to the GitHub Issue with :issue:`num` or this Pull Request with :pull:`num`. Includes contributor name and/or GitHub username (link with :ghuser:`user`).
[x] Pull request is nearly complete and ready for detailed review.
[x] Maintainer: Appropriate GitHub Labels (including remote-data) and Milestone are assigned to the Pull Request and linked Issue.

Some functions in pvlib.spa are doing quite a lot of unnecessary computation:

For the table-based computations, our code combines arrays of different lengths into a single 2d array, thus padding the shorter arrays with zero, and creating a bunch of unnecessary busy work to process those dummy entries.
The longitude_nutation and obliquity_nutation functions perform the same expensive calculation
To much lesser effect, there are several instances of a single function containing multiple calls to np.radians(x).

This PR prevents those unnecessary computations and reduces overall calculation time by 40-50% for both numpy and numba.  The table below compares runtimes in seconds:

n
numpy, PR
numpy, main
numba, PR
numba, main

10
0.002
0.004
0
0

100
0.003
0.004
0
0.001

1000
0.006
0.011
0.001
0.002

10000
0.041
0.069
0.009
0.017

100000
0.4
0.657
0.083
0.161

1000000
4.654
8.492
0.864
1.633

Regarding the table-length issue, it might be better to  do away  with the combined HELIO_LONG_TABLE et al. entirely and just keep the arrays as separate module-level variables.

Ready for review.  The drop in reported coverage should be ignored; it's in the part of pvlib.spa that is run in numba-mode only, and coverage tracking doesn't work with numba functions.


Add a Time dimension format rule to cube checker

Is your feature request related to a problem? Please describe.
A "[GraphQL] Cannot turn null for non-nullable field TemporalDimension.timeFormat" error turned out to be a source of confusion several times; we should add a new rule to cube checker to be able to guide creators of cubes into the right direction to fix the problem.
Describe the solution you'd like
A new role (row) should be added to /_cube_checker page.
Describe alternatives you've considered
We also can add info on this requirement to the RDF to Visualize docs.
Usecases and impact
It will be clear how to fix the above problem for our users.

How to test

Go to /_cube-checker
Paste https://environment.ld.admin.ch/foen/ubd0104prod/5 and click "Check".
See that there is a check related to time formats at the bottom.


Resource usage stats from Ehcache server entity (close #1551 and close #1530)

Close #1551 and close #1530.
This PR will build when the tc-platform release 5.0.9.beta will be available
Important notes for Ehcache / M&M people:

TimeSource

We need in management to get the server time in a uniform way both from ehcache server entity and within the monitoring service. Currently, we are calling: System.currentTimeMillis() because there is no time service in voltron.
See StatisticCollectorManagementProvider in this PR.
I started a discussion for that: Terracotta-OSS/terracotta-apis#167

Scheduling tasks

There is no way to schedule a task in voltron yet, so I needed to start a scheduled executor service (the thread is set to daemon) used only by management to compute stats.
See Management in this PR
I started an issue for that: Terracotta-OSS/terracotta-apis#158

Statistics configuration

We have currently no way to pass the stats config object to use server-side. One idea is that it could be an optional XML config in ehcache xml, sent when the entity is configured with the server config. For the moment, the stat config is then fixed and cannot be changed.
See Management and StatisticConfiguration in this PR
I started an issue for that: #1567

Management calls to server entities

We have no way yet to issue a management call to the server entity to configure which stat to collect depending on what we need. So for the moment, all stats are collected.
See Management in this PR
I started an issue for that: Terracotta-OSS/terracotta-apis#168

test this please

several "hacks" are in place in this PR to make server side stats collection possible.
Those hacks are well documented and tracked in different issues.
LGTM
PS : please try and bring OffHeapResource stats in a next PR

Yes, I'll add an observer for OffHeapResource.remaining(). Just need to see first if it is ok to make offheap lib depends on stats, or if it is preferable to duplicate he observers per server entity.


Implementing MemoryStore

Hey,
I'm trying to write a custom MemoryStore that works with a sqlx postgres database to store sessions for axum-login.
I've got the following SQL, which has space for all the non-serde-skipped parts of Session:
CREATE TABLE auth_sessions (
    id TEXT PRIMARY KEY NOT NULL,
    expiry TIMESTAMP
);

CREATE TABLE auth_session_data (
    k TEXT NOT NULL,
    v TEXT NOT NULL,

    session_id TEXT NOT NULL,
    CONSTRAINT fk_session_id
        FOREIGN KEY (session_id)
        REFERENCES auth_sessions(id)
        ON DELETE CASCADE
)

Unfortunately, I can't work out a way to get the session contents to/from SQL, as I can't seem to find a constructor for making a Session, or getting all of the data - I can get values from keys but if I don't know what keys are being used (and would rather not have to hardcode a list from axum-login), and I can make a new cookie and add data but I can't do things like set the ID.

Apologies, I should've taken this to async-session.

Is there a reason you aren’t using the provided sqlx stores?

Correct me if I'm wrong @maxcountryman, but looking at the docs.rs pages (for sqlxstore and the concrete postgresstore), it only looks like implement UserStore and not SessionStore?

You can just that in conjunction with axum-session which also supports sqlx. Check out the examples.

Ah OK, so I should just be using the serde fields and a deserialiser/representation like JSON. Thanks!


Download button too small to notice when trying to download jobs

First of all, people that have used PATRIC before will be looking for it on the right hand side.  Secondly, I KNOW where it is, and I still have to look for it!  Can't we make it bigger and more obvious?

Neal has fixed the styling so it is on the right like it is supposed to be.  Will be up on beta soon.


Migrate to API v2

https://www.digitalocean.com/company/blog/api-v2-enters-public-beta/

Yes, this is important as they will be retiring v1.

I'm sort of surprised things have worked as long as they have.
Ok, so EOL for API v1 is Monday, November 9, 2015. Good to know.

Looks like there's a popular Python library now, Pontoon should probably just wrap that.

Agreed. also, EOL less than a week away (and can no longer request creds for API v1)

Yeah, it's looming. I'll carve out some time for it this week, it'll be a photo finish.

Pontoon 0.2.1 is pushed to PyPI (0.2.0 is scrubbed for breaking configure). Changelog here.
Need to update docs, etc, but open an issue if you upgrade to 0.2.1 and notice any problems.

Excellent, nice work!


Structural clean-up

Just did some structural adjustments for my own sake while playing with the code, and figured I'd submit them back in case you find them useful:

Removed using namespace in header file to avoid accidental namespace pollution
Minimized header includes
Refactored globals into function parameters
Separated example code into separate file
Moved image files to separate dir to clean up the include dir

This is awesome. Could you write a helper function in the savgol.cpp file that shows how the frame size, polynomial order and range on inputs can be set from the command line? So that by calling ./savgol  --help or ./savgol -h from the command line, the user is shown how the parameters   <x_1> <x_n>, are set.
I added a Contribution.md file to the master to aid future developers. You may add this to your local branch before your next push. Thanks!
Weldone!

I don't have the time to make other changes at the moment, but this pull request should be independent anyway. I think this is ready for merge.

No worries, @catskul.


optimize helm crds

What type of PR is this?

What this PR does / why we need it:
Fix the problem of missing crd during installation.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

@calvin0327 @RuliXu PTAL

/cc @calvin0327 @RuliXu

/lgtm

/lgtm


Emphasize git dependency version locking behavior.

Added a section in src/doc/src/reference/specifying-dependencies.md clarifying Cargo's version locking behavior when adding git dependencies:
Once a `git` dependency has been added, Cargo will lock that dependency to the
latest commit at the time. New commits will not be pulled down automatically
once the lock is in place. However, they can be pulled down manually with
`cargo update`.

Resolves #8555

r? @alexcrichton
(rust_highfive has picked a reviewer for you, use r? to override)

Um... that's interesting

Thanks for the PR!
The build failure was due to some independent changes, now fixed via #8558.
@bors r+

:pushpin: Commit 13e789e01f56be3d0e7f61dfc28c40940b258c92 has been approved by ehuss

:hourglass: Testing commit 13e789e01f56be3d0e7f61dfc28c40940b258c92 with merge 21a1e1544b6ca41921ed53b228f1241665a4dcd6...

Should this PR get closed or merged?

It'll get merged soon.  We use a bot called bors which runs all tests before merging to master.  The command I entered above told it to put in the queue of things to test.  It should get merged in about 15-20 minutes, and then the bot will handle closing things.

Gotcha, that's pretty cool! Thanks!

:sunny: Test successful - checks-actions
Approved by: ehuss
Pushing 21a1e1544b6ca41921ed53b228f1241665a4dcd6 to master...


nixos/znapzend: fix when no previous zetup

When the znapzend module was enabled for the first time with pure =
true; then the list of previous entries is empty, but xargs still tried
to execute a znapzendzetup delete command with no arguments, which made
it fail
Motivation for this change
This was reported by ottidmes on IRC, who was trying to use the module and got an error.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
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 nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Was confirmed to work by ottidmes and me

Ping @dermetfan @otwieracz @orivej

Sorry, I am no longer able to maintain here - at this moment I have no working NixOS/ZFS setup.

Pinging @7c6f434c @Mic92 @gebner @matthewbauer, this is a trivial change without which the znapzend module doesn't work for new users, would like to have it merged. Should be applied to 18.03 as well.

OK, I cannot test it but it makes a lot of sense.

Picked

Thanks!


updating catalyst versions while keeping namespace data

It is recommended here to uninstall and then install rather than updating in order to avoid side effects of dependencies. But uninstalling looses namespace data which cause problems when running live or paper modes.
Amy suggestion how to properly update catalyst versions without losing namespace data?

Hi @kooomix ,

But uninstalling looses namespace data

Please elaborate on how you perform the uninstall procedure.
Thanks,
Lena

$ source activate catalyst
$ pip uninstall enigma-catalyst
$ pip install enigma-catalyst

Are you referring to the ~/.catalyst/data directory?

yes, assuming this is the only place an algorithm namespace data is being
logged.
On Thu, 13 Sep 2018 at 12:52 Lena<EMAIL_ADDRESS>wrote:

Are you referring to the ~/.catalyst/data directory?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/enigmampc/catalyst/issues/464#issuecomment-420950631,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AZmz--mQnVcIlX8joqxZPzuCxItbenCbks5uairygaJpZM4WmpxO
.

The live algorithms data is being saved under ~/.catalyst/data/live_algos/<algo_namespace> which is not being deleted after uninstalling catalyst.
Please describe the issue you are having when upgrading to a newer release.
Thanks,
Lena

@kooomix are you still experience this issue?
If so, please provide more information.
Thanks


fix - multielasticdump - special chars in index name

Allows multielasticdump to be used on an Elasticsearch instance containing indexes with special chars.
example of index name crashing multielasticdump: %index

Thanks!


When creating a new MeshInstance snapping doesn't work before re-clicking . . .

Godot version:
Godot 3.3 . .
OS/device including version:
Windows . .
Issue description:
When I make a MeshInstance node, with snapping on, when it immediately enters the scene, ' snapping ' is off, ie. it doesn't move in snap ' increments ' . . I have to click something else and, click it again, then it works . .
See here . .

Snapping was on, ie. icon was 'active', yet by default snapping isn't on, when creating a new object . . This is a bit frustrating, since it happens a lot of times, and sort of, wastes the users time . . I'm not sure why this is happening, though . . Maybe it's a bug, maybe it's normal . .
Steps to reproduce:
Enable snapping, make a 'new' objects, and move it, before clicking anything else . . Then, snapping doesn't work, but it works, after de-selecting . . Not sure it's a bug, can't say . . .
Minimal reproduction project:
Well, think the video above explains it, not really sure it's a bug, either . . Thx . . .

Ok, first video was bad, hope this is clearer . . :OO

<3 . . .


Updated whatsnew-en-US

Background
Looking through all documentation for spelling, grammar, and punctuation errors.
Changes
Fixed minor spelling, grammar, and punctuation errors.
Test plan
There is no need to test this fix.

Maybe merge all your PRs into one, and update CHANGELOG.md


[ Ubuntu 16.04 LTS ] $HOME seems to not be set when using vim.

When using vim and exiting with :q, vim spits out an error message:
E138: Can't write viminfo file $HOME/.viminfo!
While in vim, if I run :!echo $HOME, the path to my home directory is not printed. Instead, nothing is shown. If I run :echo $PATH, the correct paths are listed.
EDIT: Outside of vim, echo $HOME shows the correct path to my home directory.
I don't have this problem in the GNOME Terminal.
UPDATES:

When starting vim from terminus, .vimrc isn't being read. .vimrc IS read when starting vim from GNOME Terminal.
Starting vim from terminus as root and typing in :!echo $HOME prints out /root as expected.
The variable ~ is correctly set in vim.

Terminus is a really cool Terminal app.

Please retry with Alpha 22

The problem is still there:

If $HOME is not defined, then vim will not load my vim configuration file (.vimrc). This is probably a major issue that will keep people who use vim away.
If I run vim with verbose output, vim -V, on both GNOME Terminal and Terminus, it looks like this:


[Snyk] Security upgrade node-fetch from 2.6.1 to 2.6.7

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to fix one or more vulnerable packages in the `npm` dependencies of this project.

Changes included in this PR

Changes to the following files to upgrade the vulnerable dependencies to a fixed version:

packages/pwa/package.json
packages/pwa/package-lock.json

Vulnerabilities that will be fixed
With an upgrade:

Severity
Priority Score (*)
Issue
Breaking Change
Exploit Maturity

539/1000  Why? Has a fix available, CVSS 6.5
Information Exposure SNYK-JS-NODEFETCH-2342118
No
No Known Exploit

(*) Note that the real score may have changed since the PR was raised.

Commit messages

Package name: node-fetch
    The new version differs by 7 commits.

1ef4b56 backport of #1449 (#1453)
8fe5c4e 2.x: Specify encoding as an optional peer dependency in package.json (#1310)
f56b0c6 fix(URL): prefer built in URL version when available and fallback to whatwg (#1352)
b5417ae fix: import whatwg-url in a way compatible with ESM Node (#1303)
18193c5 fix v2.6.3 that did not sending query params (#1301)
ace7536 fix: properly encode url with unicode characters (#1291)
152214c Fix(package.json): Corrected main file path in package.json (#1274)

See the full diff

Check the changes in this PR to ensure they won't cause issues with your project.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
🛠 Adjust project settings
📚 Read more about Snyk's upgrade and patch logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Learn about vulnerability in an interactive lesson of Snyk Learn.

Closine this PR as this package upgrade is inside the PWA template. No new project is using this version of pwa anymore.

Ignored on Snyk to avoid the bot re-open the PR


[doc] "Hardware Development Stages" vs "Development Stages"

In our documentation at https://docs.opentitan.org/doc/project/development_stages/ we talk about "hardware development stages" and "development stages" somewhat randomly. The development stages focus primarily on a single IP block, but cover RTL, verification, and DIFs (which are the "software" part).
It would be nice to clarify the scope of the development stages document by using consistent naming.
I can't see a clearly better naming, here's my thinking:

Use "Hardware Development Stages" to clearly indicate that we only consider everything hardware-related topics, but not software other than DIFs.
Use "Development Stages" to avoid the potential confusion about DIFs being software, but still within scope for the development stages.

I guess one main question would be how strongly we need/want to separate the lifecycle scheme from software other than DIFs. What's your thinking there @gkelly @lenary?
@sjgitty @asb @sriyerg

Agree, we should not typically refer to them as Hardware Development Stages; I think we even changed the file to reflect that a while back and just didn't update the content underneath. Feel free to suggest a PR, or I will as soon as my machine is resurrected / replaced.

Fine with 'Development Changes' since we are not just building HW but also SW drivers that goes with it.
IMO DIFs are more tightly coupled with HW since we use it in pre-Si verification (which gates tapeout / final chip signoff), whereas the rest of the SW stack can continue to develop beyond tapeout.

I've been pretty careful to try to use "Development Stages" when talking about them from the software side, but I was wary of updating all the Silicon documentation.
Other software will not be using this S1/S2/S3 development stage model, I don't believe, but I don't think @gkelly and I have had a chance to discuss that in any great detail.

Closed as obsolete. We have settled down on using "Development Stages" to refer to hw and software development stages.