Debian test failure in test_get_uns_neighbors_deprecated

Hello,
We were trying packaging anndata 0.7.4 for debian-med and ran into some test failures
(There's a minor issue where the Debian test process builds the package in a separate directory and runs tests there, and some of the small test data files aren't copied over so the tests fail. I added some setup(package_data) globs and fixed that, I can file a separate issue if you're interested)
The issue I'm more stumped on is this one: We're testing with python3.8 & 3.9 and get this exception with both versions of python. By any chance do you have any suggestions what might be wrong?
anndata/tests/test_deprecations.py::test_get_uns_neighbors_deprecated FAILED                                                                                [ 36%]

adata = AnnData object with n_obs × n_vars = 2 × 3
    obs: 'anno1'
    var: 'anno2'
    uns: 'neighbors'
    layers: 'x2'
    obsp: 'connectivities'

    def test_get_uns_neighbors_deprecated(adata):
        n = adata.shape[0]
        mtx = sparse.random(n, n, density=0.3, format="csr")
        adata.obsp["connectivities"] = mtx
        adata.uns["neighbors"] = {}

        with pytest.warns(FutureWarning):
            from_uns = adata.uns["neighbors"]["connectivities"]

        assert_equal(from_uns, mtx)

        with pytest.warns(None) as rec:
            v = adata[: n // 2]
>           assert not rec
E           assert not WarningsChecker(record=True)

anndata/tests/test_deprecations.py:113: AssertionError

Might help to show what the warnings are:
p vars(rec.list[0])
{'message': FutureWarning('is_categorical is deprecated and will be removed in a future version.  Use is_categorical_dtype instead'),
 'category': <class 'FutureWarning'>,
 'filename': '/build/python-anndata-exfcES/python-anndata-0.7.4+ds/.pybuild/cpython3_3.9_anndata/build/anndata/_core/anndata.py',
 'lineno': 1094,
'file': None,
'line': None,
'source': None,
'_category_name': 'FutureWarning'}
(Pdb) p vars(rec.list[1])
{'message': FutureWarning('is_categorical is deprecated and will be removed in a future version.  Use is_categorical_dtype instead'),
'category': <class 'FutureWarning'>,
'filename': '/build/python-anndata-exfcES/python-anndata-0.7.4+ds/.pybuild/cpython3_3.9_anndata/build/anndata/_core/anndata.py',
'lineno': 1094,
'file': None,
'line': None,
'source': None,
'_category_name': 'FutureWarning'}

After reading the warnings, Debian is shipping pandas 1.1.3, and in that is_categorical is deprecated in favor of is_categorical_dtype, using this patch resolves the test failure, though I don't know if you'd rather accept the warnings to work with older versions of pandas.
Also as an aside it looks like there's more from pandas.api.types import is_categorical statements than is needed.
--- anndata/_core/anndata.py	2020-11-05 12:23:54.976471806 -0800
+++ /run/schroot/mount/unstable-amd64-sbuild-6f63c09f-36e0-4302-9409-6689c5b05354/build/python-anndata-exfcES/python-anndata-0.7.4+ds/anndata/_core/anndata.py	2020-11-05 15:28:33.517496264 -0800
@@ -19,5 +19,5 @@
 from numpy import ma
 import pandas as pd
-from pandas.api.types import is_string_dtype, is_categorical
+from pandas.api.types import is_string_dtype, is_categorical_dtype
 from scipy import sparse
 from scipy.sparse import issparse
@@ -1089,8 +1089,8 @@

     def _remove_unused_categories(self, df_full, df_sub, uns):
-        from pandas.api.types import is_categorical
+        from pandas.api.types import is_categorical_dtype

         for k in df_full:
-            if not is_categorical(df_full[k]):
+            if not is_categorical_dtype(df_full[k]):
                 continue
             all_categories = df_full[k].cat.categories
@@ -1190,5 +1190,5 @@
                 key
                 for key in df.columns
-                if is_string_dtype(df[key]) and not is_categorical(df[key])
+                if is_string_dtype(df[key]) and not is_categorical_dtype(df[key])
             ]
             for key in string_cols:

I believe we've already done this on master, but haven't made a release yet. I think we'll be making a bugfix release soon which will include this.

Just made that release, are your builds working now?

@ivirshup Hello! The build works on 64bit systems, but the tests fail on 32-bit systems.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982098
=================================== FAILURES ===================================
___________________ test_set_dataframe[<lambda>-False-int32] ___________________

homogenous = False, df = <function <lambda> at 0xf1d74148>
dtype = <class 'numpy.int32'>

    @pytest.mark.parametrize(
        "df,homogenous,dtype",
        [
            (lambda: gen_typed_df_t2_size(*X.shape), True, np.object_),
            (lambda: pd.DataFrame(X ** 2), False, np.int_),
        ],
    )
    def test_set_dataframe(homogenous, df, dtype):
        adata = AnnData(X)
        if homogenous:
            with pytest.warns(UserWarning, match=r"Layer 'df'.*dtype object"):
                adata.layers["df"] = df()
        else:
            with pytest.warns(None) as warnings:
                adata.layers["df"] = df()
                assert not len(warnings)
        assert isinstance(adata.layers["df"], np.ndarray)
>       assert np.issubdtype(adata.layers["df"].dtype, dtype)
E       AssertionError: assert False
E        +  where False = <function issubdtype at 0xf60991d8>(dtype('int32'), <class 'numpy.int32'>)
E        +    where <function issubdtype at 0xf60991d8> = np.issubdtype
E        +    and   dtype('int32') = array([[ 1,  4,  9],\n       [16, 25, 36],\n       [49, 64, 81]], dtype=int32).dtype

/usr/lib/python3/dist-packages/anndata/tests/test_layers.py:62: AssertionError

Perhaps this has been fixed and you can suggest a commit or PR that we can apply as a patch? Or a new release?
Thanks,

Not sure that's a bug on our end. That assertion looks like it should be fine, regardless of platform.
To me, it looks like there is a bug in whatever version of numpy that system is using?

This is just weird and supports the idea that it's something in numpy.
I ran this  python3 -m pytest --pdb --pyargs anndata
and in the generated pdb session in a i386 chroot found this sequence in anndata/tests/test_layers.py:62 quite weird.
Module variables from test_layers.py:10
X = np.array([[1, 2, 3], [4, 5, 6], [7, 8, 9]])
L = np.array([[10, 11, 12], [13, 14, 15], [16, 17, 18]])

(Pdb) p X.dtype, (X ** 2).dtype
(dtype('int32'), dtype('int32'))
(Pdb) p np.issubdtype(X.dtype, np.int_)
True
(Pdb) p np.issubdtype((X ** 2).dtype, np.int_)
False
(Pdb) p X.dtype is L.dtype
True
(Pdb) p X.dtype is (X ** 2).dtype
False

Yep this reproduces the issue and only depends on numpy.
It runs correctly on 64-bit intel and fails on 32-bit intel.
import numpy as np

X = np.array([[1, 2, 3], [4, 5, 6], [7, 8, 9]])

assert np.issubdtype(X.dtype, np.integer)
assert np.issubdtype(X.dtype, np.int_)
assert np.issubdtype((X**2).dtype, np.integer)
assert np.issubdtype((X**2).dtype, np.int_)

on a i386 system:
Traceback (most recent call last):
  File "/tmp/repro.py", line 8, in <module>
    assert np.issubdtype((X**2).dtype, np.int_)
AssertionError


Add: Pinwheel

Channel Name
Pinwheel
Alternative Names (optional)
No response
Network (optional)
No response
Owners (optional)
Warner Communications
Country
US
Subdivision (optional)
No response
City (optional)
No response
Broadcast Area
c/US
Languages
eng
Categories (optional)
No response
NSFW
FALSE
Launched (optional)
1977-12-01
Closed (optional)
1979-04-01
Replaced By (optional)
NickelodeonEast.us
Website (optional)
No response
Logo
https://upload.wikimedia.org/wikipedia/commons/thumb/4/47/Pinwheel_television_logo.svg/554px-Pinwheel_television_logo.svg.png
Notes
QUBE Channel https://en.m.wikipedia.org/wiki/QUBE, later turned into nickelodeon

Please update your request:

the size of the logo should not exceed 512x512px

https://github.com/iptv-org/database/blob/master/CONTRIBUTING.md#channels

Cannot do anything

Reopening request because i fixed the logo.


add welcome workflow

add welcome and issue for contributors
close; #439

Rebased, and merged.
Thanks for your contribution !


Adding AzureApplicationGatewayRewrite creates unwanted extra rule

Describe the bug
When you add an AzureApplicationGatewayRewrite to the latest helm chart 1.6.0, it automatically adds an unwanted section breaking the rule
To Reproduce
Steps to reproduce the behavior:
using ingress-azure helm chart 1.6.0
Add the following:
apiVersion: appgw.ingress.azure.io/v1beta1
kind: AzureApplicationGatewayRewrite
metadata:
  name: x-forwarded-headers
  namespace: istio-system
spec:
  rewriteRules:
    - name: x-forwarded-headers
      ruleSequence: 100
      actions:
        requestHeaderConfigurations:
          - actionType: set
            headerName: X-Forwarded-For
            headerValue: "{var_add_x_forwarded_for_proxy}"

on the ingress, add the rewrite header
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: "istio-ingressgateway-development"
  namespace: "istio-system"
  annotations:
    kubernetes.io/ingress.class: azure/application-gateway
    appgw.ingress.kubernetes.io/rewrite-rule-set-custom-resource: x-forwarded-headers

Expected result:
New rewrite rule is created that looks like this:

Current result:
We get some unexpected extra rule breaking the rule:

@mariusandersen I wonder if this is a UI related issue. Can you view Application Gateway's "JSON view" in portal and check if you see an empty rewrite rule present in the Config.

I don't think that is the issue
{
    "name": "bp-istio-system-istio-ingressgateway-development-80-8080-istio-ingressgateway-development",
    ...
    "properties": {
        "provisioningState": "Succeeded",
        ...
        "requestRoutingRules": [
            {
                "id": "/subscriptions/<guid>/resourceGroups/my-rg/providers/Microsoft.Network/applicationGateways/my-agw/requestRoutingRules/rr-<guid>"
            }
        ]
    },
    "type": "Microsoft.Network/applicationGateways/backendHttpSettingsCollection"
},

Also while the unexpected part is there, the routing does not work giving 404. Only after I manually remove that unexpected part I showed in first post, does the agw work as expected.

Ok, I think I found the issue.
https://github.com/Azure/application-gateway-kubernetes-ingress/blob/master/pkg/appgw/rewrites.go#L174
Here, a url rewrite is constructed even when properties are empty and causes the 404 that you see.
This will require a fix and will come in a release that we are planning for next month. Sorry for the inconvenience.
As a work around, there is rewrite-rule-set annotation can be used to directly reference a rule set added on application gateway.
https://github.com/Azure/application-gateway-kubernetes-ingress/blob/master/docs/annotations.md#rewrite-rule-set

Thank you for the workaround, that works for now.


Fixed hosts should have only one physical location

The physical location of a physical host is specified via a 'locatedIn' relationship from the host to a Space.
Spaces are assumed to be non-overlapping. If one space encloses another (e.g., a cabinet inside a room), the inside of the cabinet is considered to be a separate space from the rest of the room. The 'locatedIn' relationship from a host somewhere in the room specifies whether the host is inside the cabinet, or inside the rest of the room.
What this means is that if a host has locatedIn relationships to multiple spaces, it means the host must be mobile and so could be in either space.
Some types of hosts are considered to be fixed, e.g., physical servers, some workstations, routers, etc. It would be a modelling error if those types of hosts had more than one location, but no such modelling error has yet been added to the domain model.

Modelling error added in branch 151.


AMBARI-24025 Display Mpack Info on Service Summary Page

How was this patch tested?
Tested manually

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/2584/
Test FAILed.
Test FAILured.

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/2585/
Test FAILed.
Test FAILured.


Feature Request: Option to Hide Internal Members and Methods in Autocomplete

When typing an object name followed by a period, the autocomplete currently lists all available members and methods. It would be really helpful to have an option to hide internal members and methods (those prefixed with an underscore) from this list during autocomplete, as the full list can sometimes be overwhelming for the user.
For cases where the "self" object is being accessed within a class, it would be ideal for all members to still be displayed by default.

Thanks for the issue. This is a duplicate of https://github.com/microsoft/pylance-release/discussions/3797. Please up-vote that enhancement discussion.


How to prevent downloading partner/other/featured YT channels?

Checklist

[x] I'm asking a question
[x] I've looked through the README and FAQ for similar questions
[x] I've searched the bugtracker for similar questions including closed ones

Question

I'm downloading a channel a regularly (it's set to run every day to catch new uploads). It worked fine for months. Now it's downloading all the partner/other/featured channel's videos too, which I don't need. These: https://www.youtube.com/c/athleanx/channels
It logs them in the archive in the folder of the main channel, so I can just wait then delete them, but still...
My .bat file:
cd /D "%~dp0"
youtube-dl https://www.youtube.com/c/athleanx ^
--config-location config.txt ^
--download-archive ATHLEAN-X/archive.txt
PAUSE

My config file:
--format ("bestvideo[width>=1920]"/bestvideo)+bestaudio/best
--download-archive archive.txt
--output %(uploader)s/%(uploader)s.%(upload_date)s.%(title)s.%(id)s.%(ext)s
--restrict-filenames
--merge-output-format mkv
--ignore-errors
--verbose
--write-sub
--sub-lang es,en

My youtube-dl is also set to auto-update itself, and since this started happening today, it must be something in the new version or a change on YT itself.

Use https://www.youtube.com/c/athleanx/videos . This is a change made in the youtube extractor recently


Add support for ActivityBot's ADC and DAC

From this thread, the adcACpropab object doesn't work with PropWare's build system

adcDCpropab provides an in-cog solution which may work for some people. Even still, PropWare needs to be 100% compatible with the Simple library, and that includes adcACpropab

Fix applied by modifying the Learn folder. No build system changes required.


Eemancini comm docs

Category

[X] Content fix
[X] New article

Contents of the Pull Request

Removed repetitive bullet from staff & training article.
Submitting new article for How to elevate staff and training

Guidance

Please add to the Microsoft 365 Maturity Model TOC

Docs Build status updates of commit cf1a107:
:warning: Validation status: warnings

File
Status
Preview URL
Details

Community/microsoft-maturity-model-how-to-staff-and-training.md
:warning:Warning
View
Details

Community/microsoft365-maturity-model--staff-and-training.md
:white_check_mark:Succeeded
View

Community/microsoft-maturity-model-how-to-staff-and-training.md

Line 2, Column 1: [Warning-ms-prod-or-service-missing] One of the following attributes is required: 'ms.prod', 'ms.service'. Use ms.prod for on-premise products, or ms.service for cloud services.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Thanks, @eemancini!


Improve inheritance hierarchy of ChatOptions/FunctionCallingOptions

Convert ChatOptions.Builder to have Builder<B extends Builder<B, C>, C extends ChatOptions>

This will allow the subclasses which extend this builder to provide their implementation of ChatOptions i.e, in our case FunctionCallingOptions
Update the default builder implementations with this change
Update FunctionCallingOptions and its default builder impelementation to enforce this hiearchical change

I've reimplemented the options builders to get rid of the generics.  There were still hard to resolve warnings in the IDE and I kept going in circles.  It shouldn't be so complicated but that approach seems to lead to unwanted java generic warning/side effects.
Now the approach is very simple and easy to understand.
merged new impl in 0765b2ca88f110a9849ab869f1b3166e362af1cc


Update markerclusterer - moved to GitHub from SVN.

There was an issue with the markers on the Events map. I think it has to do with the fact that Google moved the repo from SVN to GitHub. I have updated the file + added the 5 markers (m1-m5). The images were added in folder static/img/* - I find it weird there was no other markers before, so if you spot a mistake, please flag it and don't accept the PR. Thanks!

Coverage remained the same at 85.114% when pulling 39abc0bbb28dd9f0dd559e39570b469b1eb7d2e5 on oana-sipos:master into c881805f57b16b989940f0ea143fa533eeecb1f5 on codeeu:master.

Hey @oana-sipos,
It's great that you spotted the issue and provided a fix!
You're probably right that the images stopped working since this URL is no longer available: http://google-maps-utility-library-v3.googlecode.com/svn/trunk/markerclusterer/images/m2.png I think we shouldn't have used that in the first place.
After a quick glance over the diff I think it looks fine and your solution to include the images in our repo is a lot better than to reference them from an external server.
I can't do much more, however, since I've stepped down from the webdev team at Code Week. I will give you write access to the repositories and you'll be able to merge this PR yourself should you decide so. I can also provide you with access to the production server so you or someone esle can deploy the fix.

@mitio Just saw this and invited @oana-sipos to be a member of the org.

@kerstin Yeah, I also added her in the "Members" team (people with write and admin access).
If you're interested into restructuring the teams, please go ahead as you see fit. 🚢

Coverage remained the same at 85.114% when pulling c38a367c363b28fbad6e808ea6b062d643e2e0b8 on oana-sipos:master into c881805f57b16b989940f0ea143fa533eeecb1f5 on codeeu:master.

@mitio Could you please deploy? Thanks 🍨

@oana-sipos I deployed it using the ./deploy-latest-coding-events script I wrote (as mentioned in the instructions).
Now no markers show on the map, however.
I will leave it deployed so you can track what might have caused it. I did a very quick investigation but I see no apparent problems aside from the fact that the markersclusterer.js is loaded from this URL in production: http://events.codeweek.eu/static/CACHE/js/4ed9097d9207.js which means the images would be searched for in http://events.codeweek.eu/static/CACHE/img/m... which is not correct. Maybe an absolute path needs to be used for them, e.g. /static/img/m. I think, however, that the problem is somewhere else since no marker images are attempted to be loaded and no markers appear to be drawn at all.

P.S. Here is the deploy log and the short deployment script.

Something is clearly weird in here. As far as I understand markerclusterer.js is loaded in production from http://events.codeweek.eu/static/CACHE/js/8121d734f1ac.js which doesn't fully make sense. I am trying to run everything locally and also deploy to heroku to see how it works in a prod env. An evening + night of traveling is awaiting for me, so it might take until tomorrow to fix it fully (am afraid will not have a connection anytime soon). If you think it's better, please revert the deploy to the previous commit. Thanks, keep in touch!
p.s. About deploying: guess you would need a private ssh key from me to be able to connect to root?

Things are different on the public site due to the fact that there's some concatenation and caching going on only on production. You might need to check out the actual configuration on the production server.
However, the file itself is being loaded, so that doesn't seem to be the problem. The issue is possibly somewhere else.
Let's leave this version up for now. No need to revert back to another broken version.
For deploying, I will need your public key, not the private one. The private key must stay only in your possession. You can check out this article or this one on the topic on generating the private-public key pair. When you've generated one, just email me the contents of your public key (most likely contained in ~/.ssh/id_rsa.pub).

I meant public of course :P E-mail sent to you with it. Just ping me when you add it. Thanks!


Add discussion of theoretical basis

In the Definition, we should cite and briefly summarize both Syntax and Semantics of Abstract Binding Trees and Type Refinements for the Working Class.

I think the category-theoretic parts of Syntax and Semantics of Abstract Binding Trees and Type Refinements for the Working Class are giving me the most trouble, at the moment. For example, in Syntax and Semantics of Abstract Binding Trees, I am lost beyond the fact that it is possible to interpret contexts into a category with objects as contexts and e.g. renaming of symbol as morphisms (or, e.g. substitutions in the case of variable contexts, if I understand correctly). This is mostly me though, and I think I need to get up to speed if I also want to e.g. understand the semantics of the cubical type theory paper, on a related note, as well.
Anyways, I suppose my question is: should/will the Definition of Red JonPRL be uncategorized completely?
Also, maybe illustrating and extending your examples in Syntax and Semantics of Abstract Binding Trees, i.e. the lambda calculus and assignable references calculus examples, in code, would be useful in the definition?

An additional thought:
What is an example of properties I could prove about programs in Red JonPRL that I couldn't elsewhere? For example, in theory, would I be able to prove that e.g. selection sort and merge sort formulated in ALGOL 60 (having both expressions and commands) are extensionally equal in Red JonPRL? What would the prospects of doing this in Red JonPRL, as opposed to elsewhere?

I really like these paragraphs, by the way, as a starting point:

Hi Mark,
I will respond in more detail later, but to address the category theory question--- the reason for the categorical treatment in both cases is that the machinery is very elaborate and categorical language allows us to "factor out" a lot of complexity. In the ABTs paper, you can safely ignore all the scary sheaf stuff---there is a technical reason why we need it, but it is not really the essence of what is going on here. For your purposes, the sheaf stuff (which exists to ensure that strengthening holds for symbols) as well as the entire section on the categorical semantics can probably be ignored.
However, if you look at the Refinements paper, it is already mostly "uncategorified" (for instance, in the rules, rather than working internally to the topos, we work externally and quantify over renamings etc.); we chose to do this because we didn't want to give the impression that there was something essentially categorical about our meaning explanation. In other places in the paper, though (such as the explanation of types as computation-respecting refinements), it was more convenient to use categorical language.
It would be a good idea for us to add some more detailed example of a language to the ABT paper, such as an appendix developing Harper's Modernized Algol.
Best,
Jon

On Feb 7, 2016, at 6:31 AM, Mark Farrell<EMAIL_ADDRESS>wrote:
I think the category-theoretic parts of Syntax and Semantics of Abstract Binding Trees and Type Refinements for the Working Class are giving me the most trouble, at the moment. For example, in Syntax and Semantics of Abstract Binding Trees, I am lost beyond the fact that it is possible to interpret contexts into a category with objects as contexts and e.g. renaming of symbol as morphisms (or, e.g. substitutions in the case of variable contexts, if I understand correctly). This is mostly me though, and I think I need to get up to speed if I also want to e.g. understand the semantics of the cubical type theory paper, on a related note, as well.
Anyways, I suppose my question is: should/will the Definition of Red JonPRL be uncategorized completely?
Also, maybe illustrating and extending your examples in Syntax and Semantics of Abstract Binding Trees, i.e. the lambda calculus and assignable references calculus examples, in code, would be useful in the definition?
—
Reply to this email directly or view it on GitHub.

I will respond in more detail later, but to address the category theory question--- the reason for the categorical treatment in both cases is that the machinery is very elaborate and categorical language allows us to "factor out" a lot of complexity. In the ABTs paper, you can safely ignore all the scary sheaf stuff---there is a technical reason why we need it, but it is not really the essence of what is going on here. For your purposes, the sheaf stuff (which exists to ensure that strengthening holds for symbols) as well as the entire section on the categorical semantics can probably be ignored.
However, if you look at the Refinements paper, it is already mostly "uncategorified" (for instance, in the rules, rather than working internally to the topos, we work externally and quantify over renamings etc.); we chose to do this because we didn't want to give the impression that there was something essentially categorical about our meaning explanation. In other places in the paper, though (such as the explanation of types as computation-respecting refinements), it was more convenient to use categorical language.
It would be a good idea for us to add some more detailed example of a language to the ABT paper, such as an appendix developing Harper's Modernized Algol.
Best,
Jon

Red JonPRL's syntactic framework makes it plausible that we could define the syntax of the states of an ALGOL machine as then impose an operational semantics on them—and then we could use our refiner to reason about the computation of ALGOL procedures. There are not currently any plans to do this, but it would be an interesting project!

What is an example of properties I could prove about programs in Red JonPRL that I couldn't elsewhere?

So, in comparison to Coq, you can prove theorems about computational and extensional equivalence of programs, and then use these theorems to justify rewriting some other goal. In Coq, you can prove extensional equivalence of programs, but it's not that useful because you can't do anything with the proof afterward; and you can't prove computational equivalence because there's no way to talk about computation in Coq.
What you can do in Coq is formalize the operational semantics of a programming language and then formalize a type system, and define computational equivalence and show that your little type system respects it, etc. In Coq, when you do this, you're doing metamathematics; JonPRL and Nuprl are a lot stronger in this area, because rather than the user defining a little closed language and then defining computation for it, you're actually observing the computation of JonPRL's programming language itself, and all of JonPRL's type theory is arranged such that it respects this notion of computation.
Here's an example of something you can prove in Nuprl, that you can't prove in Coq:

Every stream processor is "merely" continuous. (Where by "merely", I mean that we can calculate its modulus of continuity, but we cannot do so continuously.) Furthermore, you can also prove Brouwer's Fan Theorem, from which you can show that all functions on the reals are uniformly continuous.

We're intending to make it possible to prove these things as well in Red JonPRL. It relies on two things that Coq probably can't have (except perhaps through some kind of forcing layer, like what Sozeau was working on):

Exceptions with fresh exception names (which will be very elegant thanks to the ABT framework).
The Bar Principle—an intuitionistic principle that states that a proof like forall (X : stream(Nat)), exists n : Nat, P(X[n]) can always be analyzed into a wellordered tree. We can add this consistently because it is possible to give evidence for membership that it separate from the object under consideration.

Using exceptions you can prove that everything in sight is continuous. Using the Bar Principle, you can prove its special case called the Fan Theorem (the Fan Theorem is basically the Bar Theorem when restricted to streams of 0,1-bits instead of streams of natural numbers); using the Fan Theorem, we can prove that every continuous real function is uniformly continuous.

@markfarrell The other thing we intend to do, longer term, is add mutable references to JonPRL. It's not yet totally clear how to integrate higher order state with CTT, but it seems like it will be possible. I'm excited about this, because you'll be able to use JonPRL to prove behavioral specifications of imperative programs! (if and when we add this).
What we might do for now is start with first order mutable references (such as references that can only hold integers or something); it seems like it should be pretty clear how to get that working much sooner than we have a treatment of general references.
Conceivably, mutable state could also be added to Coq using forcing, but it's a long way off.


Betterment of github actions

Why:  Some github actions like going back and switching tabs sometimes shows some glitch which need to be checked.
Closes [issue link]

What's being changed (if available, include any code snippets, screenshots, or gifs):

Check off the following:

[ ] I have reviewed my changes in staging (look for the "Automatically generated comment" and click the links in the "Preview" column to view your latest changes).
[x] For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

[ ] This pull request impacts the contribution experience

[ ] I have added the 'writer impact' label
[ ] I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

I’m want to access @slenguyen


Update Julia wrapper

[x] update docs
[x] rename OpenSpiel_jll -> OpenSpiel

Hi @findmyway , this looks great. We have not had time to take a look yet -- does it mean we could avoid the download/install of the custom Julia install as we had setup now?
Also there seems to be a conflict; we had updated build_and_run_tests.sh last week. I guess it should be an easy merge, though. Can you take a look?

I just merged the latest master branch.

does it mean we could avoid the download/install of the custom Julia version as we have setup now?

We still need to download and install a Julia binary with v1.3 or above. But we do not need to install a specific CxxWrap.jl like I said here anymore 😉 .
Most changes in this PR are to update the dependency of CxxWrap.jl to v0.10. Another extra modification is that an extra BUILD_WITH_PYTHON=ON flag is added. This is handy when people only want to build the Julia wrapper(without python related dependencies). So now the whole story is:

If a user is using Julia v1.3 on Linux, he/she only needs a usable version for experiments. Then just install this package with ]add OpenSpiel in the Julia REPL. The package manager will download a precompiled version I registered here.
If a user wants to use it on Mac or needs the latest features. He/she needs to build the libspieljl locally by with the install.sh and build_and_test.sh scripts.

Hi @findmyway , hmm.. the julia tests are failing when I import it:
WARNING: both OpenSpiel and Base export "step"; uses of it in module Main must be qualified
can play tic_tac_toe: Error During Test at /usr/local/google/home/lanctot/tmp/open_spiel/open_spiel/julia/test/bots.jl:8
  Got exception outside of a @test
  UndefVarError: step not defined
  Stacktrace:
   [1] evaluate_bots(::CxxWrap.StdLib.UniquePtrAllocated{State}, ::Array{MCTSBotAllocated,1}, ::Int64) at /usr/local/google/home/lanctot/tmp/open_spiel/open_spiel/julia/test/runtests.jl:31
   [2] top-level scope at /usr/local/google/home/lanctot/tmp/open_spiel/open_spiel/julia/test/bots.jl:14
   [3] top-level scope at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Test/src/Test.jl:1107
   [4] top-level scope at /usr/local/google/home/lanctot/tmp/open_spiel/open_spiel/julia/test/bots.jl:9
   [5] top-level scope at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Test/src/Test.jl:1107
   [6] top-level scope at /usr/local/google/home/lanctot/tmp/open_spiel/open_spiel/julia/test/bots.jl:4
   [7] top-level scope at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Test/src/Test.jl:1107
   [8] top-level scope at /usr/local/google/home/lanctot/tmp/open_spiel/open_spiel/julia/test/bots.jl:3
   [9] include at ./boot.jl:328 [inlined]
   [10] include_relative(::Module, ::String) at ./loading.jl:1105
   [11] include(::Module, ::String) at ./Base.jl:31
   [12] include(::String) at ./client.jl:424
   [13] top-level scope at /usr/local/google/home/lanctot/tmp/open_spiel/open_spiel/julia/test/runtests.jl:40
   [14] top-level scope at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Test/src/Test.jl:1107
   [15] top-level scope at /usr/local/google/home/lanctot/tmp/open_spiel/open_spiel/julia/test/runtests.jl:38
   [16] include at ./boot.jl:328 [inlined]
   [17] include_relative(::Module, ::String) at ./loading.jl:1105
   [18] include(::Module, ::String) at ./Base.jl:31
   [19] include(::String) at ./client.jl:424
   [20] top-level scope at none:6
   [21] eval(::Module, ::Any) at ./boot.jl:330
   [22] exec_options(::Base.JLOptions) at ./client.jl:263
   [23] _start() at ./client.jl:460

can play single player: Error During Test at /usr/local/google/home/lanctot/tmp/open_spiel/open_spiel/julia/test/bots.jl:18
  Got exception outside of a @test
  UndefVarError: step not defined
  Stacktrace:
   [1] evaluate_bots(::CxxWrap.StdLib.UniquePtrAllocated{State}, ::Array{MCTSBotAllocated,1}, ::Int64) at /usr/local/google/home/lanctot/tmp/open_spiel/open_spiel/julia/test/runtests.jl:31
   [2] top-level scope at /usr/local/google/home/lanctot/tmp/open_spiel/open_spiel/julia/test/bots.jl:23
   [3] top-level scope at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Test/src/Test.jl:1107
   [4] top-level scope at /usr/local/google/home/lanctot/tmp/open_spiel/open_spiel/julia/test/bots.jl:19
   [5] top-level scope at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Test/src/Test.jl:1107
   [6] top-level scope at /usr/local/google/home/lanctot/tmp/open_spiel/open_spiel/julia/test/bots.jl:4
   [7] top-level scope at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Test/src/Test.jl:1107
   [8] top-level scope at /usr/local/google/home/lanctot/tmp/open_spiel/open_spiel/julia/test/bots.jl:3
   [9] include at ./boot.jl:328 [inlined]
   [10] include_relative(::Module, ::String) at ./loading.jl:1105
   [11] include(::Module, ::String) at ./Base.jl:31
   [12] include(::String) at ./client.jl:424
   [13] top-level scope at /usr/local/google/home/lanctot/tmp/open_spiel/open_spiel/julia/test/runtests.jl:40
   [14] top-level scope at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Test/src/Test.jl:1107
   [15] top-level scope at /usr/local/google/home/lanctot/tmp/open_spiel/open_spiel/julia/test/runtests.jl:38
   [16] include at ./boot.jl:328 [inlined]
   [17] include_relative(::Module, ::String) at ./loading.jl:1105
   [18] include(::Module, ::String) at ./Base.jl:31
   [19] include(::String) at ./client.jl:424
   [20] top-level scope at none:6
   [21] eval(::Module, ::Any) at ./boot.jl:330
   [22] exec_options(::Base.JLOptions) at ./client.jl:263
   [23] _start() at ./client.jl:460

play three player stochastic games: Error During Test at /usr/local/google/home/lanctot/tmp/open_spiel/open_spiel/julia/test/bots.jl:27
  Got exception outside of a @test
  UndefVarError: step not defined
  Stacktrace:
   [1] evaluate_bots(::CxxWrap.StdLib.UniquePtrAllocated{State}, ::Array{MCTSBotAllocated,1}, ::Int64) at /usr/local/google/home/lanctot/tmp/open_spiel/open_spiel/julia/test/runtests.jl:31
   [2] top-level scope at /usr/local/google/home/lanctot/tmp/open_spiel/open_spiel/julia/test/bots.jl:34
   [3] top-level scope at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Test/src/Test.jl:1107
   [4] top-level scope at /usr/local/google/home/lanctot/tmp/open_spiel/open_spiel/julia/test/bots.jl:28
   [5] top-level scope at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Test/src/Test.jl:1107
   [6] top-level scope at /usr/local/google/home/lanctot/tmp/open_spiel/open_spiel/julia/test/bots.jl:4
   [7] top-level scope at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Test/src/Test.jl:1107
   [8] top-level scope at /usr/local/google/home/lanctot/tmp/open_spiel/open_spiel/julia/test/bots.jl:3
   [9] include at ./boot.jl:328 [inlined]
   [10] include_relative(::Module, ::String) at ./loading.jl:1105
   [11] include(::Module, ::String) at ./Base.jl:31
   [12] include(::String) at ./client.jl:424
   [13] top-level scope at /usr/local/google/home/lanctot/tmp/open_spiel/open_spiel/julia/test/runtests.jl:40
   [14] top-level scope at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Test/src/Test.jl:1107
   [15] top-level scope at /usr/local/google/home/lanctot/tmp/open_spiel/open_spiel/julia/test/runtests.jl:38
   [16] include at ./boot.jl:328 [inlined]
   [17] include_relative(::Module, ::String) at ./loading.jl:1105
   [18] include(::Module, ::String) at ./Base.jl:31
   [19] include(::String) at ./client.jl:424
   [20] top-level scope at none:6
   [21] eval(::Module, ::Any) at ./boot.jl:330
   [22] exec_options(::Base.JLOptions) at ./client.jl:263
   [23] _start() at ./client.jl:460

Test Summary:                            |  Pass  Error  Total
OpenSpiel.jl                             | 25872      3  25875
  Games                                  |    27            27
  games simulation                       | 25803         25803
  bots                                   |    19      3     22
    MCTSBot                              |    19      3     22
      can play tic_tac_toe               |            1      1
      can play single player             |            1      1
      play three player stochastic games |            1      1
      solve draw                         |     9             9
      solve loss                         |     6             6
      solve win                          |     4             4
  cfr                                    |     8             8
  Trajectory                             |    15            15
ERROR: LoadError: Some tests did not pass: 25872 passed, 0 failed, 3 errored, 0 broken.
in expression starting at /usr/local/google/home/lanctot/tmp/open_spiel/open_spiel/julia/test/runtests.jl:37
ERROR: Package OpenSpiel errored during testing
Stacktrace:
 [1] pkgerror(::String, ::Vararg{String,N} where N) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Pkg/src/Types.jl:113
 [2] #test#131(::Bool, ::Nothing, ::Cmd, ::Cmd, ::typeof(Pkg.Operations.test), ::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Pkg/src/Operations.jl:1372
 [3] #test at ./none:0 [inlined]
 [4] #test#62(::Bool, ::Nothing, ::Cmd, ::Cmd, ::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}, ::typeof(Pkg.API.test), ::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Pkg/src/API.jl:253
 [5] test(::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Pkg/src/API.jl:239
 [6] #test#58 at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Pkg/src/API.jl:233 [inlined]
 [7] test() at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Pkg/src/API.jl:230
 [8] top-level scope at none:1

99% tests passed, 1 tests failed out of 84

Total Test time (real) =  84.58 sec

The following tests FAILED:
	 84 - julia_test (Failed)
Errors while running CTest
At least one test failed.
If this is the first time you have run these tests, try:
pip3 install -r requirements.txt
Note that outside a virtualenv, you will need to install the system
wide matplotlib: sudo apt-get install python-matplotlib
Exiting virtualenv
lanctot@lanctot:open_spiel$

Any ideas?

Another edit, I missed this, which seems quite relevant!
WARNING: both OpenSpiel and Base export "step"; uses of it in module Main must be qualified

I guess we just have to tag on OpenSpiel:: , I'll try it

Prepending step with OpenSpiel. fixed it. I'm learning some Julia, cool!

Ok, now the julia test seems to be failing on my Mac:
[100%] Building CXX object julia/CMakeFiles/spieljl.dir/wrapper/spieljl.cc.o

[100%] Linking CXX shared library libspieljl.dylib
[100%] Built target spieljl
Test project /Users/lanctot/open_spiel/build
    Start 146: julia_test
1/1 Test #146: julia_test .......................***Failed   22.73 sec
   Testing OpenSpiel
 Resolving package versions...
 Installed StatsBase ────── v0.33.0
 Installed DataStructures ─ v0.17.12
C++ exception while wrapping module OpenSpiel: Attempt to use unmapped type NSt3__16vectorIdNS_9allocatorIdEEEE in parameter list
ERROR: LoadError: Attempt to use unmapped type NSt3__16vectorIdNS_9allocatorIdEEEE in parameter list
Stacktrace:
 [1] register_julia_module at /Users/lanctot/.julia/packages/CxxWrap/LfTHV/src/CxxWrap.jl:406 [inlined]
 [2] readmodule(::String, ::Symbol, ::Module, ::Nothing) at /Users/lanctot/.julia/packages/CxxWrap/LfTHV/src/CxxWrap.jl:701
 [3] wrapmodule(::String, ::Symbol, ::Module, ::Nothing) at /Users/lanctot/.julia/packages/CxxWrap/LfTHV/src/CxxWrap.jl:705
 [4] top-level scope at /Users/lanctot/open_spiel/open_spiel/julia/src/OpenSpiel.jl:8
 [5] include at ./boot.jl:328 [inlined]
 [6] include_relative(::Module, ::String) at ./loading.jl:1105
 [7] include(::Module, ::String) at ./Base.jl:31
 [8] top-level scope at none:2
 [9] eval at ./boot.jl:330 [inlined]
 [10] eval(::Expr) at ./client.jl:425
 [11] top-level scope at ./none:3
in expression starting at /Users/lanctot/open_spiel/open_spiel/julia/src/OpenSpiel.jl:8
ERROR: LoadError: Failed to precompile OpenSpiel [7e5d8dc8-489f-4be6-9273-f4c3010e6ec1] to /Users/lanctot/.julia/compiled/v1.3/OpenSpiel/pEQx0_8bSIK.ji.
Stacktrace:
 [1] error(::String) at ./error.jl:33
 [2] compilecache(::Base.PkgId, ::String) at ./loading.jl:1283
 [3] _require(::Base.PkgId) at ./loading.jl:1024
 [4] require(::Base.PkgId) at ./loading.jl:922
 [5] require(::Module, ::Symbol) at ./loading.jl:917
 [6] include at ./boot.jl:328 [inlined]
 [7] include_relative(::Module, ::String) at ./loading.jl:1105
 [8] include(::Module, ::String) at ./Base.jl:31
 [9] include(::String) at ./client.jl:424
 [10] top-level scope at none:6
in expression starting at /Users/lanctot/open_spiel/open_spiel/julia/test/runtests.jl:1
ERROR: Package OpenSpiel errored during testing
Stacktrace:
 [1] pkgerror(::String, ::Vararg{String,N} where N) at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.3/Pkg/src/Types.jl:113
 [2] #test#131(::Bool, ::Nothing, ::Cmd, ::Cmd, ::typeof(Pkg.Operations.test), ::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}) at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.3/Pkg/src/Operations.jl:1372
 [3] #test at ./none:0 [inlined]
 [4] #test#62(::Bool, ::Nothing, ::Cmd, ::Cmd, ::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}, ::typeof(Pkg.API.test), ::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}) at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.3/Pkg/src/API.jl:253
 [5] test(::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}) at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.3/Pkg/src/API.jl:239
 [6] #test#58 at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.3/Pkg/src/API.jl:233 [inlined]
 [7] test() at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.3/Pkg/src/API.jl:230
 [8] top-level scope at none:1

0% tests passed, 1 tests failed out of 1

Total Test time (real) =  22.87 sec

The following tests FAILED:
	146 - julia_test (Failed)
Errors while running CTest

Ah, I can reproduce the error now.
It might be that I didn't test again after merging the latest master branch.
Will fix them soon.

Great thanks, the Linux tests pass now so it' only the one error on MacOS.

Hi @findmyway , I soled the first problem (conflict in step) in a different way, by prepending OpenSpiel. before step but I noticed you put back the imports in the header. Is there a preference between these?
Any idea on the MacOS problem..? Have you been able to reproduce it?

Is there a preference between these?

Yeah, I think import in the header would be better to avoid breaking things unexpectedly when using step, it also applies for first and last.
Unfortunately, I can't access my Mac environment recently. So it's not easy for me to debug the error with Mac. The error is quite strange to me. I didn't introduce any relevant change spieljl.cc file. And from the test result on Travis: https://travis-ci.org/github/findmyway/open_spiel/jobs/676503286 it seems to work fine. Could you check it again?

Ok will change the step thing as you have.
The 146 tests is likely because I am only building a subset of the tests (I added the ability to test only specific tests) but I agree its odd to only be missing one.
I also upgraded my XCode and upgraded my Mac early this week which could explain it.
Will try it again as soon as I can.

Actually the 146 tests are because I didn't build with some of the optional deps (ACPC etc.)
I just tried again completely fresh and still get the same error. If it helps, it's coming from here: https://github.com/JuliaInterop/libcxxwrap-julia/blob/73149f8f1445d83dcb6ee2995e18b8f98f0c94e9/include/jlcxx/module.hpp#L343 . I wish it would give us a line number in spieljl.cc because I have no way of knowing where to look.
Since the tests are passing on Travis, it has to be my recent upgrades; but that is unsettling, because I'm sure others will hit this. I'm happy to merge it anyway but we should anticipate a bug report and/or maybe ask the CxxWrap devs.

Thanks for trying it again!
C++ exception while wrapping module OpenSpiel: Attempt to use unmapped type NSt3__16vectorIdNS_9allocatorIdEEEE in parameter list
ERROR: LoadError: Attempt to use unmapped type NSt3__16vectorIdNS_9allocatorIdEEEE in parameter list

From my limited experience, it usually means some type is not wrapped with jlcxx::stl::apply_stl. (Sorry that I can't figure out the specific line without a workable environment.)

Since the tests are passing on Travis, it has to be my recent upgrades (also didn't find anything on Google, likely because it's too new); but that is unsettling, because others will likely encounter this. I'm happy to merge it anyway but we should anticipate a bug report and/or maybe ask the CxxWrap devs.

Gently ping @barche to let him aware of this potential issue 😀 .

From my limited experience, it usually means some type is not wrapped with jlcxx::stl::apply_stl. (Sorry that I can't figure out the specific line without a workable environment.)

Yeah that's exactly what I was thinking too. I was trying to think if we've added anything recently (i.e. this week) that would cause this, and it doesn't seem so. So it must be some interaction between CxxWrap and the new XCode that maybe wasn't an issue before.

Gently ping @barche to let him aware of this potential issue 😀 .

Will do, thanks a lot for the help.

I think the problem is that it is picking up a stale version of CxxWrap somehow, when compiling. After pulling in the code from this PR and running build_and_run_tests.sh, I found it was linked to the wrong lib:
ldd build/julia/libspieljl.so
libcxxwrap_julia.so.0 => /home/user/.julia/packages/CxxWrap/lDNAy/deps/usr/lib/libcxxwrap_julia.so.0

Deleting /home/user/.julia/packages/CxxWrap/lDNAy and build/julia and then building again fixed it for me.
Off-topic: I just happened to do these tests on our DGX station for reasons of convenience. Now that I have a working OpenSpiel installation, is there any cool stuff I can run to demo the power of our GPUs?

Thanks @barche. Unfortunately, it didn't seem to fix my problem (which btw only appears on MacOS -- on linux it all works fine). I got rid of $HOME/.julia and $HOME/.local/bin/julia* and all of build to be sure, and re-ran the installer so it would re-install all the packages, and get the same problem when building.

Off-topic: I just happened to do these tests on our DGX station for reasons of convenience. Now that I have a working OpenSpiel installation, is there any cool stuff I can run to demo the power of our GPUs?

Ah! If you mean via the Julia API then I am not sure what is supported. Maybe Jun can say more.
There are several of the python algorithms that use Tensorflow ( but default to cpu ). I will check with the team to see if there is a better one for benchmarking and showing off hardware!

OK, it took me a while to realize, but the problem is a recent incompatibility between the precompiled  libcxxwrap libraries and the latest Apple Clang, see https://github.com/JuliaInterop/CxxWrap.jl/issues/230
To fix this, compile libcxxwrap from source and set the Overrides.toml, as explained here: https://github.com/JuliaInterop/libcxxwrap-julia#building-libcxxwrap-julia
Unfortunately, I only realised this after building and testing the whole thing on my poor Macbook Air, it took 940 s for the tests, vs. 162 s on the DGX station ;)

Ok, I've updated github now with these changes; I had imported the code prior to the last few commits which I added msyelf, so I'm closing the issue.
As for the outstanding issue with CxxWrap on MacOS with XCode 11.4: thanks @barche for all the time you've spent helping us understand this. Unfortunately, I have to move to other things now. I think it's ok to leave as is for now, though since I expect it would affect a very small portion of users for a short time, since I expect this will be eventually fixed once the prebuilt binaries in CxxWrap are updated. The other option would be to build libcxxwrap within the install of Julia, but that seems like a heavy change on our side for something that should correct itself soon. What do you think, @findmyway ?
What I'm missing, though, is that there is no open issue on either CxxWrap or libcxxwrap documenting this as an outstanding "bug". Do the devs on their side know about it and is there a plan to fix it? @barche: are you one of the devs of these projects; could you comment on that? The issue you linked is closed so I'm not sure if my assumptions above are correct.

I think it's ok to leave as is for now, though, since I expect it would affect a very small portion of users for a short time, because this will be fixed once the prebuilt binaries in CxxWrap are updated.

Agree 👍

because this will be fixed once the prebuilt binaries in CxxWrap are updated

Unfortunately this is not possible: binaries for use with the "official" Julia releases are compiled using BinaryBuilder, which uses cross-compilation, so I expect this incompatibility with Xcode 11.4 to remain for a long time. To solve this for Julia end-users, OpenSpiel should be made available using BinaryBuilder as well, by submitting a build script to Yggdrasil: https://github.com/JuliaPackaging/Yggdrasil

Thanks for @barche 's advice. In fact, I've already added one there, but I encounter some errors when trying to build with x86_64-apple-darwin14. I'll revisit the problem sometime later.

@findmyway, how about for now we just mention this problem in the Julia README.md (Under a 'known problems' section), just so people are aware?


Remove mavenLocal() from default repos for pluginManagement.

Also just redirect to Repositories.DEFAULT_PLUGINS.

Build failed


Formatting & formatting guidelines

autopep8?

@alvinz-matician I'm unfamiliar with autopep8. Would this be something that would be locally run before pushing code, or automated through github actions?

It's a Python auto-formatter for PEP8 standards, I just wanted to put it on your radar. I was thinking that it could be nice to add as a PR check in GitHub actions.

from a quick search, it looks like flake8 wraps a few things including pyflakes (statically checks for logical errors) and pycodestyle (formerly pep8).
autopep8 does automatic formatting according to pep8.
would be cool to have both but if we have to pick one to start with maybe flake8? action: https://github.com/py-actions/flake8

Thanks for adding this. Should we fix the flake8 errors before merging this?

I'm rewriting the natural scenes and patches stuff in #30 so IMO it's fine for now. At least until we have a writeup I don't think we'll have too much external traffic.

Yep. Realized that after I looked at #30. Thanks!

Can these requests be resolved so we can merge this branch?


Ignore deleted outputs in default workflows

This is a simple change but adding tests for this is really hard in a test environment so decided to explain the reasons behind the change in the code so it can be used during this and future reviews.

Coverage increased (+0.008%) to 92.9% when pulling 7d41a34be7b4460f6b2203a8d4d606433877d189 on antgonza:ignore-deleted-outputs-in-default-workflows into 7aa8a18f5aef634162c43b192d6ac3cfa83d4e76 on qiita-spots:dev.


Don't display dotted underline on abbr[title] tags to browsers that don't support hover

Prerequisites

[X] I have searched for duplicate or closed feature requests
[X] I have read the contributing guidelines

Proposal
Currently the Abbreviation styles show the dotted underline on all browsers, even mobile devices where it isn't possible to hover over them to show the title.
I'd like to propose that the styles for abbr and .initialism be limited to only browsers/devices which support the hover:hover media query (namely iOS/iPadOS) by updating reboot.scss. I think it'd look something like this:
@media (hover: none) {
  abbr[title] {
    -webkit-text-decoration: none;
    text-decoration: none;
  }
}

@media (hover: hover) {
  abbr[title] {
    text-decoration: underline dotted;
    cursor: help;
    text-decoration-skip-ink: none;
  }
}

I've tested this on desktop Chrome 102, Edge 102 and it works exactly as expected there  - the text is not underlined on iPadOS 15, iOS 15 and Android 7 (Chrome 102) where it isn't possible to see the title - even with a pointing device (mouse) connected.
CodePen:
https://codepen.io/coliff/pen/rNJbEoM
I used this to make a simplified page test:
https://tests.christianoliff.com/title-style-hover/
Motivation and context
Currently the Abbreviation styles show the dotted underline on mobile devices which don't support hover and it can be frustrating for users to see the dotted underlines on abbr text but have no way to interact with it. It'd be better if the text just appeared as normal text.

My two cents: using @media (hover: hover) to reset those styles would decrease potential side effects.
Apart from that, why not? I'm almost sure we shop such progressive enhancement here and there.

UPDATE: I did some further testing and got it working correctly on Android too! 👍
(basically we want to set text-decoration: none on  @media (hover: none)
I've updated my original post to reflect the changes.

Removing the text decoration when @media (hover: none) seems a good idea to avoid having frustrated users. Maybe we could enhance their experience by displaying the full title as well with something like (supposing that doesn't cause any issues with internationalization):
@media (hover: none) {
  abbr[title]:after
  {
   content: " (" attr(title) ")";
  }
}

heya @julien-deramond - that's an interesting idea and I think that would be useful in some circumstances, but I think it could also cause problems in some cases too. On small phone screens for example it could be annoying to see longer abbreviations expanded after every instance and it could potentially break formatting.
I made a Stackblitz demo taking a paragraph from the Bootstrap dropdowns docs to test:
https://stackblitz.com/edit/js-4tafmg?file=index.html,style.css
So on iPhone screen it looks a bit cluttered :-\

Yes you're right, let's not do it by default. If we still find it useful maybe we could mention this trick only in the documentation as an option or we could create a specific class (utility) for the users to use it only when it's needed.

quickfire: don't use @media (hover: ...). use @media (any-hover: ...)
https://css-tricks.com/interaction-media-features-and-their-potential-for-incorrect-assumptions/

Yes!
I'm also facing similar issue but now its gone You can check here


Update Set-M365DataAtRestEncryptionPolicyAssignment.md

Docs Build status updates of commit a85dc70:
:clock10: Pending: waiting for processors (7 builds ahead of you)
:warning: Docs Build is busy, currently there are 7 builds ahead of this one, for more information you can view the Build queue graph on the Docs Portal.

Docs Build status updates of commit a85dc70:
:clock10: Pending: waiting for processors (7 builds ahead of you)
:warning: Docs Build is busy, currently there are 7 builds ahead of this one, for more information you can view the Build queue graph on the Docs Portal.

Docs Build status updates of commit a85dc70:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/Set-M365DataAtRestEncryptionPolicyAssignment.md
:white_check_mark:Succeeded
View (exchange-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit a85dc70:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/Set-M365DataAtRestEncryptionPolicyAssignment.md
:white_check_mark:Succeeded
View (exchange-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


There is no way to specify a required algorithm for Given Keys

When parsing keys from JWKS, the "alg" parameter is loaded and enforced by the KeyFunc:  an error will be returned if the token header's algorithm does not match the key's specified algorithm (if any).   This is good!
But when constructing a keyfunc from GivenKeys, there is no way to specify which algorithm the keys are intended for.   Not enforcing the algorithm could (in theory) allow an attacker to specify the kid of a key intended for algorithm A but actually specify algorithm B.  If both A and B expected the same runtime type for their key, golang-jwt might validate the token using algorithm B despite the key only being intended for algorithm A.
Note: I don't think any practical exploit is possible using the default signing algorithms (given that golang-jwt blocks the "none" algorithm by default), but in theory it is best practice to ensure that the algorithm used matches what the key is intended for.
I think this could be solved easily by adding an algorithm field to GivenKey, plus a constructor that populates it.  This can just be copied to the parsedJWK.algorithm field and it wouldn't break backwards compatibility.
If this makes sense I can submit a PR for it.

Thank you for opening this issue, @sean-rn.
It is my understanding that alg related attacks happen when the alg is used as a component for key selection. keyfunc only selects keys based on their IDs, kid. Even though the kid parameter is optional for both JWS and JWT, it is required for this package to function.

If both A and B expected the same runtime type for their key, golang-jwt might validate the token using algorithm B despite the key only being intended for algorithm A.

For example, an attacker forging a token with a self-created RSA key when the key used for signature verification is RSA PSS. Both of these use *rsa.PublicKey type when returning from the jwt.Keyfunc, and golang-jwt seems to pass on the algorithm verification check to their package users. Presumably the algorithm method selection happens inside golang-jwt, but it's been a while. I imagine it comes straight from the JWT header. In this case the package user of golang-jwt is keyfunc. It looks like that since keyfunc doesn't allow an alg to be specified for given keys. As a consequence, the algorithm verification check cannot take place on this line. However, I believe there are not any known attacks for these types of alg mismatches. Again, I think the known vulnerabilities are when the alg is used key selection not algorithm selection. I would imagine if such an attack does exist, there would need to be some specialized cryptography work needed to forge a self-created RSA key that could pass as a specific key under a different algorithm's signature verification algorithm.
Here's an article that mentions alg related attacks:
https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/
But known attacks don't matter much, it's best to follow the RFCs. According to various RFCs alg specification by users and verification is required in all cases. Looks like keyfunc doesn't do that with given keys.
Here's a clear example RFC 8725 Section 3.1:

Libraries MUST enable the caller to specify a supported set of algorithms and MUST NOT use any other algorithms when performing cryptographic operations. The library MUST ensure that the "alg" or "enc" header specifies the same algorithm that is used for the cryptographic operation. Moreover, each key MUST be used with exactly one algorithm, and this MUST be checked when the cryptographic operation is performed.

I'd like to implement the change you've suggested, @sean-rn. If you have a PR that is welcome.

I should have also mentioned that alg related attack described in the "RSA or HMAC?" section of the linked blog post. This type of attack is not possible with golang-jwt due to how keys are specific Go types. I guess coming from a mindset where this is possible blurs the line between key selection and algorithm selection.
I also didn't mention how this could impact something like HS256 vs HS512 with given keys, but finding a collision isn't something I think is feasible at this time.

I agree there are no known attacks that could exploit this.  I was just thinking it would be best practice.

I wish the issue wasn't closed automatically when the PR is merged. I don't consider it closed until there is a tagged release.
You are 100% right, it's important to follow the RFC to the letter. Thank you for opening this issue and your PR @sean-rn!

Please see the new release, v1.6.0.

A note on Go's type system:
In that article I linked earlier there is a section about confusing symmetric keys vs asymmetric keys.
Since golang-jwt needs to perform a type assertion on keys in order to use them in signature verification, it isn't possible to pass a key with the wrong type into a signature verification function. For example, you can't pass an *rsa.PublicKey into an HMAC signature verification function because the function is expecting []byte.
On Tuesday, when I had time to look into this, I recalled that ed25519.PublicKey is actually a type alias for []byte. HMAC keys are required to be of type []byte. EdDSA is public key cryptography and HMAC is private key cryptography.
If both EdDSA and HMAC of keys were in *keyfunc.JWKS at the same type and the Go type system allowed a type alias to be type asserted into its aliased type I would have registered a CVE.
On Tuesday, I wrote a quick Proof Of Concept (POC) to see if an attacker could abuse this.

Click to expand POC:

package main

import (
	"crypto/ed25519"
	"crypto/rand"
	"log"

	"github.com/golang-jwt/jwt/v4"

	"github.com/MicahParks/keyfunc"
)

const (
	eddsaKID = "myEdDSAKeyID"
	hmacKID  = "myHMACKeyID"
)

func main() {
	// Create an EdDSA key.
	public, _, err := ed25519.GenerateKey(rand.Reader)
	if err != nil {
		log.Fatalf("Failed to generate key pair: %v", err)
	}

	// Create a JWKS without specifying signing algorithms for keys.
	jwks := keyfunc.NewGiven(map[string]keyfunc.GivenKey{
		eddsaKID: keyfunc.NewGivenEdDSA(public),
		hmacKID:  keyfunc.NewGivenHMAC([]byte("irrelevant HMAC secret")),
	})

	// Attacker forges JWT with HMAC signature and EdDSA key ID.
	token := jwt.NewWithClaims(jwt.SigningMethodHS256, jwt.MapClaims{
		"attackerForged": true,
	})
	token.Header["kid"] = eddsaKID
	attackerForged, err := token.SignedString(public)
	if err != nil {
		log.Fatalf("Failed to sign attacker forged JWT: %v", err)
	}

	// Parse the attacker forged JWT.
	//
	// This should fail due to the Go type system preventing a key typed as ed25519.PublicKey from being used to sign a
	// token with a HMAC signature. This is despite ed25519.PublicKey being a type alias for []byte, which is the type
	// expected for HMAC signatures.
	token, err = jwt.Parse(attackerForged, jwks.Keyfunc)
	if err != nil {
		log.Fatalf("Failed to parse attacker forged JWT: %v", err)
	}

	// Confirm the validity of the token.
	//
	// This should never execute.
	if token.Valid {
		log.Println("Attacker forged JWT was valid!")
	} else {
		log.Println("Attacker forged JWT was invalid, but the code should have never reached this point.")
	}
}

More concise POC:

package main

type myType bool

func main() {
	var i myType
	println("Can a type alias be type asserted to the aliased type?")
	if isBool(i) {
		println("Yes.")
	} else {
		println("No.")
	}
}

func isBool(i interface{}) bool {
	_, ok := i.(bool)
	return ok
}

Recapping what is in the above POCs, the Go type system does not allow a type alias to type assert into its aliased typed. This means a ed25519.PublicKey cannot be type asserted into an []byte, so the code is not vulnerable, which is great. Thank you Go type system.


Support contexts for api requests

It'd be great if the API methods took in a golang context object so that I could easily put timeouts on requests.

Great suggestion! This repo is largely in maintenance mode, but I could likely review a PR if you wanted to put one together


[new site request] srrdb.com

it would be really straight forward and simple since srrdb has an imdb search option (for example https://www.srrdb.com/browse/imdb:tt0800320/1)

That site is added to https://github.com/Purfview/IMDb-Scout-Mod


Changelog for 0.23.3

Make sure these boxes are checked before submitting your issue - thank you!

[*] I have checked the superset logs for python stacktraces and included it here as text if any
[*] I have reproduced the issue with at least the latest released version of superset
[*] I have checked the issue tracker for the same issue and I haven't found one similar

Superset version
0.23.3
Expected results
I've expected changelog for the new version
Actual results
There is no changelog for version 0.23.3
Steps to reproduce
Watch CHANGELOG.md in master branch

FYI 0.23.x releases are tagged from 0.23 branch


Weather icon not loading for certain weather conditions

Weather icon is not showing up on city info screen in few cases.
What to do?
In case, we don't have the vector drawable for given weather condition, show the weather icon URL we are receiving in the response

Taking this up.


Add Parker to Contributors list

@parkerdyer, I'm quite elated about your PR. I wanna evolve this project to addresses various problems faced by first-time contributors. I'd love to learn about your journey in open source community, the problems, pain points you had etc.
Could you explain how you felt when you went through the tutorial, made a PR and learned that I merged it?


Test case refactoring: improve test case generality

As part of a research project at the University of Waterloo, we are exploring automatic test refactoring tools and submitting vetted proposed refactorings upstream. These refactorings make it easier to add additional related test methods, should help with the maintainability of the tests, and reduce repeated code. In this pull request, we have four refactoring cases involving 14 test methods. We've checked all cases and ensured that all the test runs pass successfully.
If it helps, we can also propose a test case that uses these 14 refactored test methods. We explained each of the four refactoring cases below.

BootiqueExceptionsHandlerIT.java
There is a standard procedure to verify the expected behavior of an erring command outcome that includes checking if the exit code is one, checking the existence of exceptions, and checking the outcome's message. We create the "assertErrorOutcome(CommandOutcome out, String outMessage)" parametrized method, which allows you to add similar test cases with different arguments out and outMessage.

InPlacePropertiesMergerTest.java
This refactoring is a bit more specific. "testApply_ObjectArray()" and "testApply_ObjectArray_PastEnd()" test methods only differ in the string of array content, expected array, and the key string (for Collections.singletonMap). We create the "testApply_ObjectArrayTemplate(ArrayList expectedArray, String key, String value, String arrayContent, String arrayName)", which allows you to add similar test cases with different arguments. We also replace the multiple assertEquals for every member of the list with one assertEquals for the actual list and expected list.

PathSegmentTest.java
To check the possibility of creating a valid path segment for a given JsonNode and path, we follow a standard procedure. By creating the "assertCanCreateValidPathSegment(JsonNode t, String path, int expectedValue)" parametrized method, we're encapsulating that procedure, which allows you to add similar test cases.

ResourceFactoryTest.java
Both "testGetUrls_ClasspathUrl()" and "testGetUrls_File()" test methods get URLs from a resource factory, check the number of URLs, and check the ending of the first URL. We create the "testGetUrlsTemplate(String location, int numOfUrls, String firstUrlEnding)" parametrized method, which allows you to add similar test cases with different arguments location, numOfUrls, and firstUrlEnding.

Overall good suggestions, but the auto-generated code requires its own manual cleanup, even worsening test redability in some cases. Have to decline the PR


python3Packages.sagemaker: 2.34.0 -> 2.35.0

Motivation for this change
Update
Things done

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

[ ] NixOS
[ ] macOS
[X] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[X] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[X] 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)
[X] Ensured that relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 119545 at 4a30b500 run on aarch64-linux 1

2 packages built successfully:

python38Packages.sagemaker
python39Packages.sagemaker


Use the terragrunt download dir for generating the temporary workspace for dependency optimization

Partially resolves https://github.com/gruntwork-io/terragrunt/issues/1344
This works for tfenv under the default settings because the terragrunt-cache will be in the same directory as the terragrunt config, and thus will be in the right spot in the folder tree of tfenv terraform versions.
Note that this will NOT work if the download dir is configured to somewhere outside of the tree, but currently that flow breaks tfenv even under normal usage (because we don't copy hidden files and folders, so .terraform-version does not get copied over).

As I also reported in #1344:

It seems to be working perfectly.
I've tested with:

the system-wide terraform version for tfenv unset
the system-wide terraform version for tfenv set to a version that's incompatible with the current version of terragrunt (0.12.26)

Before each test I made sure to remove all .terragrunt-cache folders with:
find . -type d -name ".terragrunt-cache" -prune -exec rm -rf {} \;

Both tests were successful.
I then re-run both tests without removing the .terragrunt-cache folders, just in case, to test both cases.
Both tests were successful again.
The temporary directories, containing only the backend.tf file, get created (one each) in the .terragrunt-cache folder of each dependency for which terragrunt runs terraform output -json and it almost immediately gets removed, leaving behind an empty .terragrunt-cache folder.

LGTM

Thanks for review! Will merge and release now.


Fix Map Feature Info for ArcGIS map services when reprojection is needed

Very small fix to correctly set the spatial reference id in the 'Identify' query parameters.
Also use the default 'top' mode instead of all visible layers.

@aruniverse Do we still plan to make 4.2.x builds ?If so, I think this fix should be included.

Yes we are still doing 4.2 patches
@mergifyio backport release/4.2.x

@Mergifyio backport release/4.2.x


Parallel Bible NT OT  (Content update)

In parallel bible reading when we choose languages which don’t have OT contents on Right side it shows “ The book you were reading is not available in Haryanvi “ that’s correct . but after that even the user choose NT book in right side it shows the same message like “ The book you were reading is not available in Haryanvi “ .. same happened for all languages which don’t have OT contents.

attaching screenshots for reference


Field not validated with "value" pre-defined

What
When the field's value prop is pre-defined, it doesn't get validated.
Expected behavior
I fieldProps.value is set, should call Form.validateField({ fieldProps }); to trigger respective context properties updates for the field.

Implemented: https://github.com/kettanaito/react-conform/pull/14. Closing.


Arnold mesh light support

This adds support for Arnold's mesh_light in the Arnold renderer backend, and adds a new ArnoldMeshLight node which simplifies the task of setting one up in Gaffer. It also contains some refactoring of the light representation in Gaffer, continuing on from the work @danieldresser did to change the light representation to attributes rather than an object.

From skimming the code, this all looks good.  Is this major enough that I should pick it up tomorrow and actually do the work of hooking it up at IE before we conclude that it is good to merge, or are you comfortable merging it already?

I've just pushed a rebase to deal with the merge conflict.
I'm pretty confident that this will give you what you need for an IEMeshLight so I wouldn't worry about that, but given the LightVisualiser and Light->Shader refactoring, I think it'd be good to do a dev build and get the existing IERendering stuff working and tested with it before merging.

Closing this in favour of @danieldresser's update in #1777.


When will beta be released?

I've noticed a common thread in the Discord when talking about page-objects in that there are two distinct answered depending if someone is using the beta or not. This is often followed up with a comment about this repo being in beta for a very long time.
Some teams are uncomfortable using beta versions in their production apps.
What are the blockers to getting this over the hump and into a new version? The community has been testing it for quite some time—I'm sure; considering the first beta was released February 23, 2018 (9 months ago).

@sukima I think we need a thumbs up from people using the beta and saying it's ok to release it. The other bulk of work was updating the documentation to reflect how to use this version instead of the old one.
Maybe @ro0gr is the person with more info about current state of the beta and if we're ready to release it.
My 2¢ is: Let's release it, if we're afraid of regressions, let's release it as a new major version so people can opt-in into updating.

Also, I've been really away from the project for the last year and a half (and away from Ember) so I don't think I have enough insight of what's happening in Ember world lately that could block this version from being released.
I would love to transfer the project to people that is more involved with Ember and the development of this addon. @ro0gr, @sukima?

@san650 @sukima @ro0gr I'm upgrading an app to 3.x and beta seems to be working well with the new testing layout.
I can help with that is pending with the docs (not sure what's the state on that)

First of all, sorry guys for letting release to hang for so long!

The community has been testing it for quite some time

Yes. I believe there are no known issues with the current beta from the implementation standpoint. And we could probably have it released already. However I feel like promoting a new release without documentation being updated is not a right thing to do.
Initially I've thought that documentation can stay unchanged. I was wrong.
I believe that with the new test helpers support in the guides we have to recommend usage of async/await exclusively. My first naive attempts to re-write examples to just use the new syntax have shown me that most of examples just loses their sense because of simplification/unification of ember testing APIs. This led me to a conclusion that some parts of documentation has to be completelly re-written. Unfortunatelly updating docs took me much longer than I've expected.

let's release it as a new major version so people can opt-in into updating.

I think we can safely release it as a minor release cause there are no expected breakages in API.

this repo being in beta for a very long time.

ok, in the end I totally get the pain about the current state of things. Let's release it by Monday despite the state of the docs. I'll do my best to improve the docs as much as I can until then. Any help is much appreciated.

I can help with that is pending with the docs (not sure what's the state on that)

There is a Quickstart page PR https://github.com/san650/ember-cli-page-object/pull/431 which I think is pretty close to what we need. Currently I'm working on a components page update. Also some of the  work(migrate to async/await and dedicated moduleFor page) is not shared in any PR yet. Going to share it soon.

Let's release it by Monday

🎉 👏 💯

I'll do my best to improve the docs as much as I can until then. Any help is much appreciated.

@ro0gr I can try to help on this on Saturday (I'll try to free some time to help with this problem). Do you have a list of what's most important to rewrite?

@san650 I've just summarized the most critical(in my opinion) parts in a separate issue https://github.com/san650/ember-cli-page-object/issues/436. I think the components page is the last difficult part of the puzle. I have some progress locally, but I'm not satisfied with what I have yet..

it's finally released! Thank you all 🖐


onchange fire by itself (ts-node related)

I use onchange in npm script to watch file changes to re-run tests.
I notice for some reason onchange has detect changes out of nowhere and keep rerunning the tests
I look at the files and notice .git/FETCH_HEAD is updating continuously. I believe it is done by VSCode.
However, my onchange call does not listen to the .git folder (of course).
My call is onchange -w -i \"src/**/*.ts\ -- npm run test-spec
I tried to exclude the folder onchange -w -i \"src/**/*.ts\" -e \"**/.DS_Store\" -e \".git/*\" -- npm run test-spec but it still keep running by itself. So FETCH_HEAD may not be the cause.
You can see / try the call here: https://github.com/typings/core/tree/add-jspm
Don't know if it would be reproducible.

I look into it further and somehow it seems like it is actually ts-node related. If I don't run the tests, onchange doesn't fire again.
To complete the story:
// package.json
{
  "scripts": {
    "test-spec": "ts-node node_modules/blue-tape/bin/blue-tape.js \"src/**/*.spec.ts\" | tap-diff",
    "watch": "onchange -w -i \"src/**/*.ts\" -- npm run test-spec"
    // ...
  }
}

If I run onchange -w -i \"src/**/*.ts\" -- echo "running", it does not fire again.
If I run onchange -w -i \"src/**/*.ts\" -- ts-node node_modules/blue-tape/bin/blue-tape.js \"src/**/*.spec.ts\", it does.

Is there a way to combine the test running and -- echo '{{event}} to {{changed}}' to show what has happened?
By the way, I don't know how the {{event}} to {{changed}} works.

{{event}} and {{changed}} are templates that get replaced anywhere in the command after the --. You could try something like /bin/sh -c "echo '{{event}} to {{changed}}' && my-command" to combine two commands. You'll have to make sure you escape the double quotes properly, if you put that in your package.json file.

Thank! That's really helpful.
I discovered the issue is within the project test cases themselves.

Great, glad you worked it out. 😸


Fix mobile menu modals not opening for the second time

Fixes

Fixes #1308 by @stacimc
Description

This PR sets the useHideOutside to false for mobile modals. This fixes the bug, but it doesn't fix the underlying problem. That, hopefully, will be fixed in PR that Typescriptifies the dialog composables: https://github.com/WordPress/openverse-frontend/pull/1279
Testing Instructions

Open the app on mobile width, and try clicking Filter/ Page menu buttons in the header several times. The menus should open and close successfully. On main search-staging.openverse.engineering/search, you can only open them once.
Checklist

[x] My pull request has a descriptive title (not a vague title like Update index.md).
[x] My pull request targets the default branch of the repository (main) or a parent feature branch.
[x] My commit messages follow best practices.
[x] My code follows the established code style of the repository.
[x] I added or updated tests for the changes I made (if applicable).
[ ] I added or updated documentation (if applicable).
[x] I tried running the project locally and verified that there are no visible errors.

Developer Certificate of Origin

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

LGTM, but could we just add the prop as false to the base modal implementation so that it is fixed across all modals, not just the mobile ones? For example, the modal in storybook still has the problem.


How to adapt for different image size

Thank you for your excellent work.
I want to match two different images. One is taken from camera, other one is taken from somewhere else. So images have different size. I modified the code, but I take an error below;

Is there any suggestion?

Thank you for your excellent work.
I want to match two different images. One is taken from camera, other one is taken from somewhere else. So images have different size. I modified the code, but I take an error below;

Is there any suggestion?

hi, i got the same error, how do you solve the problem? thanks~


Found low severity vulnerability

by performing an npm audit we have :
                      === npm audit security report ===

                                 Manual Review
             Some vulnerabilities require your attention to resolve

          Visit https://go.npm.me/audit-guide for additional guidance

  Low             Regular Expression Denial of Service

  Package         debug

  Patched in      >= 2.6.9 < 3.0.0 || >= 3.1.0

  Dependency of   proxy [dev]

  Path            proxy > debug

  More info       https://npmjs.com/advisories/534

found 1 low severity vulnerability in 4804 scanned packages
  1 vulnerability requires manual review. See the full report for details.

Rem : Not being an Node JS expert, I don't know if this is important or not.

Thanks for the report @LeMoussel. It's only a development dependency so it's fine. No one will do a DoS attack on your localhost


Implemented Batch Minting Eligible User v2

please make it backward compatible and add v2 endpoint beside the old version

Done


Sidebar occasionally "stuck" when sticky navigation disabled

Problem
When "sticky navigation" is set to false, the sidebar occasionally will become "stuck" and refuse to scroll.  This can reliably be induced by scrolling all the way to the top or bottom of the main page; once you hit either end, the sidebar locks and will not scroll.  Usually it unfreezes itself within a few seconds, but the timing appears inconsistent.
It is always possible to force it to unfreeze by expanding and collapsing an element in the sidebar.
Reproducible Project
An example of a project in which this is currently occurring can be found here:
https://github.com/Daltz333/frc-docs
https://frc-docs.readthedocs.io/en/latest/
Environment Info

Python Version: 3.6
Sphinx Version: 1.8.5
RTD Theme Version: 0.4.3
Web Browser: Chrome

@Oblarg I can't reproduce this. Can you provide a gif or video of the behavior?
What OS are you using?
What do you mean with "the sidebar locks and will not scroll"? Do you mean it does not scroll when you scroll the main content, or that it does not scroll when you try to scroll the sidebar itself?

I mean the latter.  I'm using Windows 10.

I have also noticed this, I could get it to happen pretty often when I:

Scrolled the sidebar
Scrolled the main content
Tried to scroll the sidebar again, couldn't until reload

@GammaGames what OS and browser do you use?
Is there any output in the console when this happens?

elementary OS 5.0 (Built on Ubuntu 18.04.2 LTS) and Google Chrome 74.0.3729.131
I was able to reproduce the issue. If you scroll the content down a little bit before trying to scroll the sidebar, it won't scroll until the content gets to the top. There's no errors in the console.

A few other things I've noticed that may help in debugging this:
The sidebar seems to get into one of two states.  Either:

The sidebar is stuck whenever the main content is not all the way at the top or bottom, or

The sidebar is stuck whenever the main content is all the way at the top or bottom.

There does not appear to be much rhyme or reason to which of the two states it ends up in.  In either case, there is a couple second delay between scrolling the main content out of the problematic position, and the sidebar unsticking.  In either case, as well, the sidebar can be reliably unstuck by interacting with any elements in it (either collapsing or un-collapsing them), however it will usually rapidly get stuck again.

Also can't reproduce with Chromium or Firefox on Ubuntu (VM).
Any additional URLs (godot engine seems to have found a workaround with sticky nav) or OS/browser combinations would be appreciated

Ah, I noticed something similar with #835, mostly on Firefox, I'm not sure if I noticed on Chromium. Scrolling sometimes would pause on the flyout menu scrollable content. This could potentially be affected by the scrolling JS that we use, though I thought that JS only targeted the main nav bar scrollable content.


Release new versions of everything to Hackage

This addresses #802.

[ ] https://hackage.haskell.org/package/ihaskell-<IP_ADDRESS>/candidate
[ ] https://hackage.haskell.org/package/ipython-kernel-<IP_ADDRESS>/candidate
[ ] https://hackage.haskell.org/package/ghc-parser-<IP_ADDRESS>/candidate

I purposely haven't included an ihaskell-static-canvas release because static-canvas doesn't have the right bounds for GHC 8.2 yet. I might do this separately.


Add documentation to our API

All of the API functionality we offer should be documented using proper Kdoc. This will help users of this library by displaying information about any functionality they might want to use directly in their IDE.

I've already documented some functionality in our method classes as I touched individual files, but would like to finish the job for 2.0.0, at least regarding anything in the method directory. This is a non-breaking change, mostly copy&paste from already available documentation, so could go in at any time.

Sure! Makes perfectly sense. Thanks for bringing it up.

Once the KDoc is in place, we should aim for enabling the following rules in detekt:
/config/detekt/detekt.yml
OutdatedDocumentation:
    active: true
    matchTypeParameters: true
    matchDeclarationsOrder: true
    allowParamOnConstructorProperties: false
UndocumentedPublicClass:
    active: true
    excludes: ['**/test/**', '**/androidTest/**', '**/commonTest/**', '**/jvmTest/**', '**/jsTest/**', '**/iosTest/**']
    searchInNestedClass: true
    searchInInnerClass: true
    searchInInnerInterface: true
    searchInProtectedClass: false
UndocumentedPublicFunction:
    active: true
    excludes: ['**/test/**', '**/androidTest/**', '**/commonTest/**', '**/jvmTest/**', '**/jsTest/**', '**/iosTest/**']
    searchProtectedFunction: false
UndocumentedPublicProperty:
    active: true
    excludes: ['**/test/**', '**/androidTest/**', '**/commonTest/**', '**/jvmTest/**', '**/jsTest/**', '**/iosTest/**']
    searchProtectedProperty: false

With all methods now being documented, and work on all entities already marked with a 2.1.0 milestone, I moved the rest of this to 2.1.0 as well.

Enabled detekt rules OutdatedDocumentation and UndocumentedPublicClass with this PR: https://github.com/andregasser/bigbone/pull/139

@bocops I think we can close this issue for the moment. Any objections?

No objections, I think the documentation is in a good shape overall right now. :)


Automate publish on NuGet

Setup a GitHub Action to automate the publishing of the package.
The pipeline should run every push on main branch.

Closed in PR #10


please make a release with libgit2 1.6.1

libgit2 1.6.1 has been released, which (among other fixes) contains a fix for NetBSD which particularly affects git2-rs when no system libgit2 is used (where currently the build is broken due to a conflict with system headers).
Can you please make a new release using libgit2 1.6.1 so this fix be used in other projects? Thank you.

Yes, please. This would save us a lot of issues.

there is a draft PR already: https://github.com/rust-lang/git2-rs/pull/935

Good, let's wait for it.
Right now can't update, e.g. onefetch

Since #935 is merged, perhaps close this issue?

Indeed, thanks!


update got package to fix vulnerability

Solved on https://github.com/pangeacyber/pangea-javascript/pull/211


Replace gomock with a mocked CGroupManager implementation

What this PR does
Before this PR:

The project relied on the external library github.com/golang/mock/gomock for creating mocks in unit tests. This approach introduced a dependency on a repository that is no longer maintained, raising concerns about future support and compatibility.

After this PR:

Introduces "fake" implementations of interfaces previously mocked with gomock, starting with the CGroupManager interface. This is achieved by replacing the MockCGroupManager with a simplified "fake" struct that records calls to its methods, facilitating straightforward verification in unit tests without external dependencies.

Fixes #10355
Why we need it and why it was done in this way
The shift towards using "fake" implementations over external mocking libraries is motivated by the need for long-term maintainability and reducing external dependencies, especially those not actively maintained. Implementing our own "fake" structures provides greater control over test environments and simplifies the testing process.
The following tradeoffs were made:

Direct control over mock behavior and structure at the expense of potentially reimplementing some functionality provided by gomock.

The following alternatives were considered:

Seeking an actively maintained alternative to gomock was considered but ultimately rejected in favor of more integrated and simplified testing mechanisms.

Links to places where the discussion took place:

Discussion on replacing gomock with "fake" implementations: GitHub Issue #10355

Special notes for your reviewer

Checklist

[ ] Design: Not required as the change focuses on internal testing strategies rather than architectural modifications.
[ ] PR: Description communicates the motivation and impact of the switch to "fake" implementations.
[ ] Code: Adheres to best practices for writing understandable code and keeps modifications straightforward.
[ ] Refactor: The introduction of "fake" implementations aims to simplify and clarify the testing approach.
[ ] Upgrade: Not applicable.
[ ] Testing: Includes updates to unit tests to utilize the new "fake" implementations effectively.
[ ] Documentation: Not required as these changes do not affect user-facing features or API.
[ ] Community: Considered notifying about this testing strategy change but deemed not necessary for an internal change.

Release note

Hi @ivylu888! Thanks for your contribution! :)
Please note that the file you changed, and any other file that begins with generated_, must not be edited directly. Instead it is being auto-generated by make generate.


Keep test name separate

Codecov Report
Patch coverage has no change and project coverage change: -0.14 :warning:

Comparison is base (3fe5660) 3.86% compared to head (a753855) 3.73%.

:exclamation: Current head a753855 differs from pull request most recent head 7ea3678. Consider uploading reports for the commit 7ea3678 to get more accurate results

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@            Coverage Diff            @@
##           master     #12      +/-   ##
=========================================
- Coverage    3.86%   3.73%   -0.14%
=========================================
  Files           5       5
  Lines         362     375      +13
=========================================
  Hits           14      14
- Misses        347     360      +13
  Partials        1       1

Flag
Coverage Δ

unittests
3.73% <0.00%> (-0.14%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

main.go
0.00% <0.00%> (ø)

processor.go
0.00% <0.00%> (ø)

race.go
32.55% <0.00%> (ø)

report.go
0.00% <0.00%> (ø)

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


StaticLib Revisions

Docs Build status updates of commit e214960:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

microsoft-edge/webview2/howto/static.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 3b03fe5:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

microsoft-edge/webview2/howto/static.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 93cc90e:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

microsoft-edge/webview2/howto/static.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

#sign-off