CreateChatInviteLinkAsync

I found a bug to report, all created invite links are expired always
Steps to reproduce
Just try to use CreateChatInviteLinkAsync on group when bot is an admin, the link is created ok but always is expired, you can use just chatid with not datetime or use datime.now.adddays(50) for example and you will get expired link all time
Expected  behavior
Links should work
Actual behavior
Links are expired
NuGet Package Version: Latest 16,0,2

Could you give me a piece of code to reproduce the problem?

I weren't able to reproduce your problem.

I created another group and its working fine, I think that the issue is related to something in the other group, the link is not expired but telegram say that, sorry. I close the ticket and thanks for the fast responses :)


Improve "Overview" and "Index" pages of documentation

Observed State: When you first navigate to https://qiskit.org/documentation/ it only displays the Qiskit Table of Contents. This isn't ideal because it means the first impression of the landing page doesn't provide any descriptive information about Qiskit. This is the same for each of the individual packages, Terra, Aer, and Ignis.
Instead, descriptive information about the packages is on the Overview.rst pages. This means that the information which would be most useful to users (an introduction to the architecture and contents of the package) appears on a separate page from a useful, explicit list of the documentation table of contents.
To-be: Merge the overview.rst content into the index.rst files for Qiskit, Terra, Ignis, and Aer, to better match Aqua, which currently uses this structure for Index pages.
Actions: Consolidate the Overview and Index pages for to create a more user friendly introduction and navigation structure for:

[x] Qiskit
[x] Terra
[x] Aer
[x] Ignis

@lzdanski I'd just like to +1 this


Fix evaluation of arguments in s![]

This PR contains fixes and tests for two issues related to evaluation of arguments in the s![] macro. Before, the $r expression was used in two places: SliceNextDim::next_dim and s!(@convert ...), which caused it to be evaluated twice. In some cases, this also failed the borrow checker.
The fix is to evaluate $r only once, binding it to r, then determine out_dim using &r, and then convert r to SliceOrIndex. Rust's macro hygiene keeps the various r bindings from conflicting. The $s expression doesn't need to be bound to a variable because it's used only once.

Can we use match to bind and lift it out of the unsafe? I was actually thinking of the unsafe clean issue today. Thanks.

The diff is not pretty. I'll have to be back at my computer to look closer at this.

Can we use match to bind and lift it out of the unsafe?

Yeah, it would be good to move the variable bindings outside the unsafe block. I'm not exactly sure what you mean in this case by "use match", though.
I pushed a new version that moves the variable bindings out of the unsafe block. I just wrapped the expansion in { } to keep it as an expression. Is that what you're looking for?

match $r { r =>  expression  } keeps any temporaries in $r alive for the whole rest of the expression

That's true. match $r { r => expression } should be equivalent to { let r = $r; expression }, right? The second option what I pushed an hour ago. I can change it to match if you'd prefer.

It's not equivalent

Okay, I changed it to the match version. Out of curiosity, what is the difference between match $r { r => expression } and { let r = $r; expression } in this context?

Thanks!


Add support for variant properties

Please add some tests (see https://github.com/cginternals/libzeug/pull/129).
Then: :shipit:


Update documentation to fix typos & add missing info

In virtualtables.adoc:

Fixed incorrect USE statement examples (incorrect keyspace + typo)
Fixed order of results for DESCRIBE tables command to match the order in cqlsh
Updated the descriptions of metrics provided in each virtual table to add missing info / add more info
Fixed typos / punctuation / formatting

In cqlsh.adoc:

Fixed typos / punctuation / formatting

In faq/index.adoc

Fixed typos / punctuation

@lukechatfield thanks for the effort! btw could we spend a little bit more time on these virtual tables? There is also doc/modules/pages/new/virtualtables.adoc and I do not have a clue why it is there, should not that be just deleted? We might probably also add more virtual tables like system_views.system_logs (I think it is called like that).


Feat/Support Prefect API Pagination

Hey,
Thank you for this great project - it has great potential to help us monitor our OSS Prefect deployment.
This PR adds pagination support to the API based metrics classes. Before this PR, only the top 200 entries were returned for each of the endpoints. This PR makes sure all the items are fetched before returning.
In order to do so, I added a base PrefectApiMetric class that implements the _get_with_pagination method. Then, I made the other classes inherit from it (class PrefectFlowRuns(PrefectApiMetric) etc.) and updated the get_all_<items>_info methods use the new _get_with_pagination method, resulting in all the items being fetched.
I hope my contribution meets the guidelines - please review it and let me know about any changes requested.
Best regards,
Ohad

Thanks for the contribution @ohadch, we'll take a look at this as soon as possible. If you have any testing notes that show how you validated this works as expected, that'd help speed up the review process 👍🏼

This is released in https://github.com/PrefectHQ/prometheus-prefect-exporter/releases/tag/1.5.0.


nile init: Greenlet error using python3.10

I have python 3.10 installed with conda (conda create --name py310 python=3.10; conda activate py310)
After installing nile and running nile init, I get
  Running setup.py install for greenlet ... error
  error: subprocess-exited-with-error

  × Running setup.py install for greenlet did not run successfully.
  │ exit code: 1
  ╰─> [17 lines of output]
      running install
      running build
      running build_ext
      building 'greenlet' extension
      creating build
      creating build/temp.linux-x86_64-3.10
      gcc -pthread -B /home/samlaf/anaconda3/envs/py310/compiler_compat -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -fPIC -O2 -isystem /home/samlaf/anaconda3/envs/py310/include -fPIC -O2 -isystem /home/samlaf/anaconda3/envs/py310/include -fPIC -I/home/samlaf/devel/starkware/nile-test/env/include -I/home/samlaf/anaconda3/envs/py310/include/python3.10 -c greenlet.c -o build/temp.linux-x86_64-3.10/greenlet.o
      greenlet.c: In function ‘g_calltrace’:
      greenlet.c:566:10: error: ‘PyThreadState’ {aka ‘struct _ts’} has no member named ‘use_tracing’; did you mean ‘tracing’?
        566 |  tstate->use_tracing = 0;
            |          ^~~~~~~~~~~
            |          tracing
      greenlet.c:569:10: error: ‘PyThreadState’ {aka ‘struct _ts’} has no member named ‘use_tracing’; did you mean ‘tracing’?
        569 |  tstate->use_tracing = (tstate->tracing <= 0 &&
            |          ^~~~~~~~~~~
            |          tracing
      error: command '/usr/bin/gcc' failed with exit code 1
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: legacy-install-failure

× Encountered error while trying to install package.
╰─> greenlet

note: This is an issue with the package mentioned above, not pip.
hint: See above for output from the failure.
Traceback (most recent call last):
  File "/home/samlaf/devel/starkware/nile-test/env/bin/nile", line 8, in <module>
    sys.exit(cli())
  File "/home/samlaf/devel/starkware/nile-test/env/lib/python3.10/site-packages/click/core.py", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "/home/samlaf/devel/starkware/nile-test/env/lib/python3.10/site-packages/click/core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "/home/samlaf/devel/starkware/nile-test/env/lib/python3.10/site-packages/click/core.py", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/home/samlaf/devel/starkware/nile-test/env/lib/python3.10/site-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/samlaf/devel/starkware/nile-test/env/lib/python3.10/site-packages/click/core.py", line 760, in invoke
    return __callback(*args, **kwargs)
  File "/home/samlaf/devel/starkware/nile-test/env/lib/python3.10/site-packages/nile/cli.py", line 61, in init
    init_command()
  File "/home/samlaf/devel/starkware/nile-test/env/lib/python3.10/site-packages/nile/core/init.py", line 19, in init
    install()
  File "/home/samlaf/devel/starkware/nile-test/env/lib/python3.10/site-packages/nile/core/install.py", line 10, in install
    subprocess.check_call(
  File "/home/samlaf/anaconda3/envs/py310/lib/python3.10/subprocess.py", line 369, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/home/samlaf/devel/starkware/nile-test/env/bin/python3', '-m', 'pip', 'install', 'cairo-lang', 'starknet-devnet']' returned non-zero exit status 1.

Hey @samlaf, thanks for bringing this up! I believe this is a dependency issue with cairo-lang. I can recommend two approaches. Either:

pip install greenlet==1.1.2

you might need to also fix the Collections issue in your venv. Go to env/lib/python3.10/site-packages/frozendict/__init__.py and change the first import to import collections.abc as collections

Or switch to Python3.7 - 3.9 until dependencies are fixed

When I use python 3.9, I get a maximum recursion reached error:
> nile compile                                                                               (py310)
📁 Creating artifacts/abis to store compilation artifacts
🤖 Compiling all Cairo contracts in the contracts directory
🔨 Compiling contracts/contract.cairo
Traceback (most recent call last):
  File "/home/samlaf/devel/starkware/cairo_venv/bin/starknet-compile", line 10, in <module>
    sys.exit(main())
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/starkware/starknet/compiler/compile.py", line 189, in main
    preprocessed = cairo_compile_common(
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/starkware/cairo/lang/compiler/cairo_compile.py", line 134, in cairo_compile_common
    assembled_program.Schema().dump(assembled_program), out, indent=4, sort_keys=True
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/marshmallow_dataclass/lazy_class_attribute.py", line 33, in __get__
    setattr(cls, self.name, self.func())
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/marshmallow_dataclass/__init__.py", line 350, in class_schema
    return _internal_class_schema(clazz, base_schema, clazz_frame)
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/marshmallow_dataclass/__init__.py", line 393, in _internal_class_schema
    attributes.update(
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/marshmallow_dataclass/__init__.py", line 396, in <genexpr>
    field_for_schema(
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/marshmallow_dataclass/__init__.py", line 711, in field_for_schema
    nested_schema = getattr(typ, "Schema", None)
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/marshmallow_dataclass/lazy_class_attribute.py", line 33, in __get__
    setattr(cls, self.name, self.func())
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/marshmallow_dataclass/__init__.py", line 350, in class_schema
    return _internal_class_schema(clazz, base_schema, clazz_frame)
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/marshmallow_dataclass/__init__.py", line 393, in _internal_class_schema
    attributes.update(
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/marshmallow_dataclass/__init__.py", line 396, in <genexpr>
    field_for_schema(
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/marshmallow_dataclass/__init__.py", line 686, in field_for_schema
    generic_field = _field_for_generic_type(typ, base_schema, typ_frame, **metadata)
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/marshmallow_dataclass/__init__.py", line 559, in _field_for_generic_type
    return field_for_schema(
...
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/marshmallow_dataclass/__init__.py", line 396, in <genexpr>
    field_for_schema(
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/marshmallow_dataclass/__init__.py", line 686, in field_for_schema
    generic_field = _field_for_generic_type(typ, base_schema, typ_frame, **metadata)
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/marshmallow_dataclass/__init__.py", line 559, in _field_for_generic_type
    return field_for_schema(
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/marshmallow_dataclass/__init__.py", line 686, in field_for_schema
    generic_field = _field_for_generic_type(typ, base_schema, typ_frame, **metadata)
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/marshmallow_dataclass/__init__.py", line 528, in _field_for_generic_type
    children = tuple(
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/marshmallow_dataclass/__init__.py", line 529, in <genexpr>
    field_for_schema(arg, base_schema=base_schema, typ_frame=typ_frame)
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/marshmallow_dataclass/__init__.py", line 718, in field_for_schema
    or _internal_class_schema(typ, base_schema, typ_frame)
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/marshmallow_dataclass/__init__.py", line 393, in _internal_class_schema
    attributes.update(
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/marshmallow_dataclass/__init__.py", line 396, in <genexpr>
    field_for_schema(
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/marshmallow_dataclass/__init__.py", line 686, in field_for_schema
    generic_field = _field_for_generic_type(typ, base_schema, typ_frame, **metadata)
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/marshmallow_dataclass/__init__.py", line 559, in _field_for_generic_type
    return field_for_schema(
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/marshmallow_dataclass/__init__.py", line 686, in field_for_schema
    generic_field = _field_for_generic_type(typ, base_schema, typ_frame, **metadata)
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/marshmallow_dataclass/__init__.py", line 528, in _field_for_generic_type
    children = tuple(
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/marshmallow_dataclass/__init__.py", line 529, in <genexpr>
    field_for_schema(arg, base_schema=base_schema, typ_frame=typ_frame)
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/marshmallow_dataclass/__init__.py", line 718, in field_for_schema
    or _internal_class_schema(typ, base_schema, typ_frame)
  File "/home/samlaf/devel/starkware/cairo_venv/lib/python3.9/site-packages/marshmallow_dataclass/__init__.py", line 385, in _internal_class_schema
    for k, v in inspect.getmembers(clazz)
  File "/home/samlaf/anaconda3/envs/py39/lib/python3.9/inspect.py", line 335, in getmembers
    names = dir(object)
RecursionError: maximum recursion depth exceeded while calling a Python object
🛑 Failed to compile the following 1 contract:
   contracts/contract.cairo

I installed greenlet==1.1.2 and still have the same error.
I also can't find any frozendict directory, neither in lib nor lib64.

Ah marshmallow_dataclass had a new release the other day which is where the maximum recursion error is coming from 😅 we have to use their previous version for now. Try pip install marshmallow-dataclass==8.5.3 for Python3.9.

I also can't find any frozendict directory, neither in lib nor lib64.

Hmm I'll try and recreate this to figure out what's happening.

@samlaf any news?

The following worked for me using 3.10, thanks!

1. `pip install greenlet==1.1.2`

   * you might need to also fix [the Collections issue](https://github.com/starkware-libs/cairo-lang/issues/38) in your venv. Go to `env/lib/python3.10/site-packages/frozendict/__init__.py` and change the first import to `import collections.abc as collections`

Thanks @EVLRBT-01!
I was using nile for a hackathon, and haven't had time to get back to it since. I will try to this week though, just to confirm that its working now.

you can also use this as a workaround for testing https://github.com/OpenZeppelin/cairo-contracts/pull/299

I have python 3.10 and after running nile init, I get
 Running setup.py install for greenlet ... error
  error: subprocess-exited-with-error

  × Running setup.py install for greenlet did not run successfully.
  │ exit code: 1
  ╰─> [26 lines of output]
      running install
      /Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/setuptools/command/install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.
        warnings.warn(
      running build
      running build_ext
      building 'greenlet' extension
      creating build
      creating build/temp.macosx-10.9-universal2-cpython-310
      clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -arch arm64 -arch x86_64 -g -I/Library/Frameworks/Python.framework/Versions/3.10/include/python3.10 -c greenlet.c -o build/temp.macosx-10.9-universal2-cpython-310/greenlet.o
      In file included from greenlet.c:359:
      In file included from ./slp_platformselect.h:47:
      ./platform/switch_aarch64_gcc.h:62:51: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
                 __asm__ volatile ("mov %0, #0" : "=r" (err));
                                                        ^
      ./platform/switch_aarch64_gcc.h:62:35: note: use constraint modifier "w"
                 __asm__ volatile ("mov %0, #0" : "=r" (err));
                                        ^~
                                        %w0
      greenlet.c:566:10: error: no member named 'use_tracing' in 'struct _ts'
              tstate->use_tracing = 0;
              ~~~~~~  ^
      greenlet.c:569:10: error: no member named 'use_tracing' in 'struct _ts'
              tstate->use_tracing = (tstate->tracing <= 0 &&
              ~~~~~~  ^
      1 warning and 2 errors generated.
      error: command '/usr/bin/clang' failed with exit code 1
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: legacy-install-failure

× Encountered error while trying to install package.
╰─> greenlet

note: This is an issue with the package mentioned above, not pip.
hint: See above for output from the failure.

I have updated the greenlet and fix the collection issues too.

I have python 3.10 and after running nile init, I get
 Running setup.py install for greenlet ... error
  error: subprocess-exited-with-error

  × Running setup.py install for greenlet did not run successfully.
  │ exit code: 1
  ╰─> [26 lines of output]
      running install
      /Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/setuptools/command/install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.
        warnings.warn(
      running build
      running build_ext
      building 'greenlet' extension
      creating build
      creating build/temp.macosx-10.9-universal2-cpython-310
      clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -arch arm64 -arch x86_64 -g -I/Library/Frameworks/Python.framework/Versions/3.10/include/python3.10 -c greenlet.c -o build/temp.macosx-10.9-universal2-cpython-310/greenlet.o
      In file included from greenlet.c:359:
      In file included from ./slp_platformselect.h:47:
      ./platform/switch_aarch64_gcc.h:62:51: warning: value size does not match register size specified by the constraint and modifier [-Wasm-operand-widths]
                 __asm__ volatile ("mov %0, #0" : "=r" (err));
                                                        ^
      ./platform/switch_aarch64_gcc.h:62:35: note: use constraint modifier "w"
                 __asm__ volatile ("mov %0, #0" : "=r" (err));
                                        ^~
                                        %w0
      greenlet.c:566:10: error: no member named 'use_tracing' in 'struct _ts'
              tstate->use_tracing = 0;
              ~~~~~~  ^
      greenlet.c:569:10: error: no member named 'use_tracing' in 'struct _ts'
              tstate->use_tracing = (tstate->tracing <= 0 &&
              ~~~~~~  ^
      1 warning and 2 errors generated.
      error: command '/usr/bin/clang' failed with exit code 1
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: legacy-install-failure

× Encountered error while trying to install package.
╰─> greenlet

note: This is an issue with the package mentioned above, not pip.
hint: See above for output from the failure.

I have updated the greenlet and fix the collection issues too.

Same problems here.

+1 here

Python 3.10 is not supported, the cairo language doesn't support it either.


New peak-finding algorithm

The existing one works fine, but requires alternating peaks/troughs in the signal. This one might work more intuitively in the long run:
https://www.mathworks.com/matlabcentral/fileexchange/25500-peakfinder-x0-sel-thresh-extrema-includeendpoints-interpolate

https://github.com/JorenSix/TarsosDSP/blob/master/src/core/be/tarsos/dsp/beatroot/Peaks.java
This also includes Java functions for peak detection. Haven't got chance to look how they did it but it's an extra option


update readme to include new help wanted link

as per this conversation on community: https://community-daily.mattermost.com/core/pl/am7oh9s16fd358twp4j8sct7gr

closing as duplicate of https://github.com/mattermost/mattermost-webapp/pull/7603


Basic auth is not supposed to be case sensitive

I spent the day looking into this for sbt/sbt#4852
Our nexus server (and almost certainly everyone else's) responds with:
www-authenticate: BASIC realm="Sonatype Nexus Repository Manager"

The code w/o this change looks for:
Basic realm="..."
But HTTP headers are generally case-insensitive.
You can see that the Rust implementation is explicitly case insensitive here:
https://docs.rs/www-authenticate/0.3.0/src/www_authenticate/lib.rs.html#190
impl Header for WwwAuthenticate {
    fn header_name() -> &'static str {
        "WWW-Authenticate"
    }

    fn parse_header(raw: &Raw) -> Result<Self> {
...
                let (scheme, challenge) = match stream.challenge() {
...
                map.entry(UniCase(CowStr(Cow::Owned(scheme))))

You can see that mozilla occasionally uses basic realm=... as in:
https://dxr.mozilla.org/mozilla-central/source/browser/components/urlbar/tests/browser/authenticate.sjs#139
        response.setHeader("WWW-Authenticate", "basic realm=\"" + realm + "\"", true);

Here's the Gecko (necko) implementation which is clearly case-insensitive:
https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpChannelAuthProvider.cpp#1019

nsresult nsHttpChannelAuthProvider::GetAuthenticator(
    const char* challenge, nsCString& authType, nsIHttpAuthenticator** auth) {
...
  GetAuthType(challenge, authType);
...
  // normalize to lowercase
  ToLowerCase(authType);

fixes #1319

Better add a test for this tricky case

Nice catch, yeah. I had fixed that locally some time ago, but didn't take the time to push it :|

It should be possible to add tests for it in that file. Tweaking this header in new tests in particular.

I wrote the test this morning and then spent the last hours trying to figure out how to run it.
I couldn't really figure that out, so instead I just asked Travis to try.
The tests failed without this fix:
https://travis-ci.org/jsoref/coursier/jobs/581781588
And pass with this fix:
https://travis-ci.org/jsoref/coursier/builds/581809682#L4546
So while I really don't understand the build system enough to run it locally, I believe the test is reasonably close enough to ship.


os/exec: cmd.Start got a deadlock when set cmd.Stdin

What version of Go are you using (go version)?
$ go version
go version go1.15.11 linux/amd64
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE="off"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/ace/.cache/go-build"
GOENV="/home/ace/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE="gitlab.alibaba-inc.com"
GOMODCACHE="/home/ace/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/ace/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build205131986=/tmp/go-build -gno-record-gcc-switches"

What did you do?
There is a deadlock in cmd.Start, this is only happen when command set cmd.Stdin
the calling stack: cmd.Start -> cmd set stdin, add stdin io copy in a goroutine after os.StartProcess successfully -> begin os.StartProcess -> finally in forkExec() -> fail in readlen (donnot know why) -> deal with the fail, begin to call wait4, but child process has run successfully, child wait goroutine to copy io, it was hang, and wait4 never success

use the follow code to reproduce
parent
package main

import (
        "bufio"
        "bytes"
        "encoding/json"
        "fmt"
        "io"
        "os"
        "os/exec"
        "time"
)

func forwardLog(fd io.Reader) {
        reader := bufio.NewReader(fd)
        for {
                line, err := reader.ReadBytes('\n')
                if err == io.EOF {
                        fmt.Println("end of read child log")
                        return

                }

                if err != nil {
                        fmt.Printf("failed to read child log: %s\n", err)
                        return
                }

                fmt.Printf("child log: %s\n", line)

        }
}

func main() {
        r, w, err := os.Pipe()
        go forwardLog(r)
        data := "hello"
        raw, err := json.Marshal(data)
        if err != nil {
                panic(err)
        }

        cmd := exec.Command("/home/ace/go/src/test/cmd-start-hang/read")
        cmd.ExtraFiles = append(cmd.ExtraFiles, w)
        cmd.Stdin = bytes.NewReader(raw)

        if err := cmd.Start(); err != nil {
                panic(err)

        }

        fmt.Printf("proc %+v\n", cmd.Process)

        if err := cmd.Wait(); err != nil {
                panic(err)
        }

        time.Sleep(10 * time.Second)

}

child
package main

import (
	"fmt"
	"io"
	"io/ioutil"
	"os"
	"time"
)

func getData(r io.Reader) ([]byte, error) {
	raw, err := ioutil.ReadAll(r)
	return raw, err
}

func main() {
	log := os.NewFile(uintptr(3), "")

	fmt.Fprintf(log, "child run\n")
	raw, err := getData(os.Stdin)
	if err != nil {
		fmt.Fprintf(log, "%s", err)
	}

	fmt.Fprintf(log, "read: %s\n", raw)

	time.Sleep(10 * time.Second)
	os.Exit(0)
}

Since I donnot know why readline fail, so I modify source code, create a error after readlen, make it fails

What did you expect to see?
cmd.Start got a error return
What did you see instead?
Both parent and child process were hang forever

I can't reproduce this, this exits normally on my system

Hi, @seankhliao  do you modify golang source code in /usr/local/go/src/syscall/exec_unix.go like the picture. Child process build with the original source code, parent process build with the modified source code.
parent process hang on wait4

child process wait on reading pipe

CC @ianlancetaylor via https://dev.golang.org/owners

Please describe code as ordinary text or as links to the Go source code.  Please do not use images.  Images are hard to read.  Thanks.

I can't recreate this problem either.  I see this output:
proc &{Pid:1084700 handle:0 isdone:0 sigMu:{w:{state:0 sema:0} writerSem:0 readerSem:0 readerCount:0 readerWait:0}}
child log: child run

child log: read: "hello"

There is a ten second delay after the final "child log" output.

build child code with origin golang code

package main

import (
	"fmt"
	"io"
	"io/ioutil"
	"os"
	"time"
)

func getData(r io.Reader) ([]byte, error) {
	raw, err := ioutil.ReadAll(r)
	return raw, err
}

func main() {
	log := os.NewFile(uintptr(3), "")

	fmt.Fprintf(log, "child run\n")
	raw, err := getData(os.Stdin)
	if err != nil {
		fmt.Fprintf(log, "%s", err)
	}

	fmt.Fprintf(log, "read: %s\n", raw)

	time.Sleep(10 * time.Second)
	os.Exit(0)
}

modify source code in https://github.com/golang/go/blob/master/src/syscall/exec_unix.go#L219-L227, create a error after L227 , as

	// Read child error status from pipe.
	Close(p[1])
	for {
		n, err = readlen(p[0], (*byte)(unsafe.Pointer(&err1)), int(unsafe.Sizeof(err1)))
		if err != EINTR {
			break
		}
	}
	Close(p[0])
	err = EINVAL

and then build parent code with the changed source code
package main

import (
        "bufio"
        "bytes"
        "encoding/json"
        "fmt"
        "io"
        "os"
        "os/exec"
        "time"
)

func forwardLog(fd io.Reader) {
        reader := bufio.NewReader(fd)
        for {
                line, err := reader.ReadBytes('\n')
                if err == io.EOF {
                        fmt.Println("end of read child log")
                        return

                }

                if err != nil {
                        fmt.Printf("failed to read child log: %s\n", err)
                        return
                }

                fmt.Printf("child log: %s\n", line)

        }
}

func main() {
        r, w, err := os.Pipe()
        go forwardLog(r)
        data := "hello"
        raw, err := json.Marshal(data)
        if err != nil {
                panic(err)
        }

        cmd := exec.Command("/home/ace/go/src/test/cmd-start-hang/read")
        cmd.ExtraFiles = append(cmd.ExtraFiles, w)
        cmd.Stdin = bytes.NewReader(raw)

        if err := cmd.Start(); err != nil {
                panic(err)

        }

        fmt.Printf("proc %+v\n", cmd.Process)

        if err := cmd.Wait(); err != nil {
                panic(err)
        }

        time.Sleep(10 * time.Second)

}

Finally,  the calling stack: cmd.Start -> cmd set stdin, add stdin io copy in a goroutine after os.StartProcess successfully -> begin os.StartProcess -> finally in forkExec() -> fail in readlen (donnot know why) -> deal with the fail, begin to call wait4, but child process has run successfully, child wait goroutine to copy io, it was hang, and wait4 never success

Could  you please try these steps again, @ianlancetaylor @seankhliao , thanks

I don't understand.  Are you saying that this problem only happens if you change the standard library?  Doesn't that mean that there is a bug with the way that you are changing the standard library?  I haven't tried to fully understand what you are doing, but it sounds like you are changing the code so that the child runs but the parent thinks that it did not run.  Why do you expect that to work?

The fact that you get the same stack trace doesn't mean that you are seeing the same problem.  The parent and child cooperate to report status.  By using different code for the child and parent, you are reaching a case where the child succeeds but the parent think that is has failed.  The parent then waits for the child process to complete.  If the child process had in fact failed, that would be fine.  But in your case the child process has not failed, so the parent waits forever.
I don't know what the real problem is, but as far as I can tell your example is showing a different problem that happens to have the same stack trace.  We need to fix the real problem, not the problem that you are describing.

Yes, you are correct, I am not describe this problem clearly, I just found this maybe got a error after child process create successfully, as child need read stdin to finish, so both child and parent process hang.  But I can't found any other information, any idea for debug this, @ianlancetaylor  ?

It's hard to know what to suggest without seeing the real code.  Typically approaches would be for both the parent and the child to print out before and after they make an I/O call, so that you can see where the hang occurs.  Or sometimes it helps to run the program under strace -f to see that last communication that happens before the hang.

The big problem is unable to reproduce offline, online environment I can only see the hang case. from the stack, I think the most probable error is readline(https://github.com/golang/go/blob/master/src/syscall/exec_unix.go#L222), but dlv can not read the err value.

Why do you think that the problem is in readlen?
What is the real problem?  The stack traces above show that the parent process is hanging in Wait while the child process is hanging in Read.  That doesn't look like a problem in readlen.  It looks like a deadlock between the parent and the child, the kind of thing that would happen if the parent never closed the pipe being used to send data to the child.  I can't help but notice that in your sample code the parent never closes w, though I know that that is not your real code.

No new information


Support Promises and async/await

This PR adds support for Promise and async/await for unirest-nodejs.

new method then

invoking then returns a proper promise chain with the callback try/catch wrapped so that errors that occur inside the callback can get handled by the catch method of the promise chain.

new dependency Bluebird

This is needed to implement Promises in older versions of Node JS
An example of using async/await with unirest
let { body, status } = await unirest.get(url)
if (status === 200) {
  ...doStuff
}

An example of using Promises with unirest
unirest.get(url)
  .then(res => doStuff(res))
  .then(stuff => doMoreStuff(stuff))
  .catch(err => ohNo(err))

Can someone please take a look at this. If the owner of this repository no longer wants to maintain this, please request new maintainers so that other folks can keep things moving forward.

Cool!

@nijikokun Any chance you can get this merged - or reject and close it.

So it's not possible to do await with a unirest call yet? Really need this!

@charliemitchell I've downloaded and used your changes, as well as updating a few dependencies.(request to 2.88.0, others to ^ instead of ~)
At this point, since @nijikokun seems to be 'out of pocket', would you mind publishing this to npm? If not, I will do it. I'm actually using this for production level integration tests with Jest. Thanks!

This is still not possible?


feat: cleanup github releases / ci contents

Kind of a grab-bag:

rename tasks to match the conceptual model now that it's real

should-publish => host
announce-release/publish-release => announce

clean up comments, add another test
create an empty Release for a library-release, allowing everything to know it should be hosted/published/announced

in theory this means library-releases to axo hosting should Now Work, but, not yet tested

github Releases now get the pretty Release urls from axo hosting

when performing host --steps=release we will update the artifact download urls with the result

only the axodotdev url will be updated, if github hosting also is enabled it will still refer to the github release
but we prefer the axodotdev url in multi-host-drifting so that's mostly academic
we also will find-and-replace the artifact download url in all install_hints
we will also regenerate the github releases announcement body to include the new hints

in CI we now save the dist-manifest at the end of the host job (which includes --steps=release)

it is written back to scratch storage (but not persistent storage on Abyss, which is logically Frozen at that point)
it is saved to an output of the host step in the same way the dist-manifest of "plan" is

in CI we now have the github announcement read from host.val instead of plan.val to get the new release notes

PR includes prereleases 7, 8, and 9 for testing

cut pre7 on this branch, and used it to make this release:
https://github.com/Gankra/evil-workspace/releases/tag/v0.8.3

updated first comment to explain wtf i've done in here


Fixed std calculation in QuantCalibrationStatsCollector

Pointed out by @Pavelrst :)
Standard deviation calculation was calculated with an average over batches, where the last batch might be very small and hence less elements.
Corrected by calculating std in the second pass by definition (after mean was calculated) .

Please note that the issue with the weighting of the last batch is not exclusive to this class, similar issue arises in SummaryActivationStatsCollector (and its derivatives). So introducing this correction into master, without adding the nuance of the last batch equally across collectors is something to consider.
Another consideration is that these code additions quite inflates the code, reducing its readability, for a functionality that is already found in AverageValueMeter. While I have my reservations of torchnet's AverageValueMeter implementation (I humbly confess I don't understand the conditions on 'n'), I think a generator object that keeps track of mean/std/var is the way to go.

@barrh AverageValueMeter is actually implemented in the way I am aiming to correct, i.e. the implementation is very similar to what was before this PR:
https://github.com/NervanaSystems/distiller/blob/61dfc8284e946ccd166792ab4468f3c08765ce81/distiller/data_loggers/collector.py#L444-L452
vs
https://github.com/pytorch/tnt/blob/d0d7fc966482cfe0e93283697045f07610a6c5e3/torchnet/meter/averagevaluemeter.py#L26-L29
In fact - to make their version correct it should have been (according to Welford's weighted algorithm):
self.m_s += n*(value - self.mean_old) * (value - self.mean)

I added this simple second pass algorithm since the second pass for quant_stats was already there for the b parameter.
About SummaryActivationStatsCollector - AverageValueMeter is already in there.

@levzlotnik
The major benefit of AverageValueMeter over your approach is that it sits in a separate module, thus, easier to evaluate & validate, and later reuse in the repo - outside QuantCalibrationStatsCollector. It also has a minor benefit, its API requires only single call to write the new values.
Just to be 100% clear, I don't think one should use torchnet's AverageValueMeter to compute weighted average means, regardless, the concept of a separate component is superior for the reasons above.


Reset Session's state in case of activation failure

The problem
Current PowerAuthSDK implementations doesn't handle internal Session's state properly during the activation process. We're forcing developers to reset the SDK object state before the activation or in case of error. All this situations should be handled in the SDK internally and the SDK behavior should be more predictable.
Solution
It looks like that we have to just add reset the session at various error points during the activation, but that's not true. The problem is more complex as it looks like at first sight :)

Remove PowerAuthSDK.reset() method. The method has a confusing naming and very unclear implementation.
Add PowerAuthSDK.cancelPendingActivation() method with a similar functionality to removed reset(). Unlike the reset(), this new method will be allowed only during the activation process and should properly cancel possible network communication.
Make sure, that cancelling a pending asynchronous task returned from createActivation...will also notify SDK about that cancellation. It's expected that developer can use both ways (cancelling the task or cancelling the pending activation in general, via the SDK methodl)
Make sure, that an error during the activation process always leads to an empty session.

Commits 586ed67 & 5d3dc54 are addressing problem with inconsistent internal Session object state during the createActivation process. Now the session is always reseted when an error occurs.


Highlights the suggested move on the chess board

Requested from google store.

Closed with https://github.com/recoders/chessbot/commit/5cd87815dbedee006434a08c01d8539c8d5e11c7


Consensus: Proof of Work

This PR implements PoW consensus engine in Substrate. We currently have a PoW verifier, and a simple thread-based miner. Refer to https://github.com/sorpaas/substrate-pow-template for a working node template configured with PoW if you want to test this out.
We delegate most of the PoW consensus components to runtime, so that we can swap mining algorithm, difficulty adjustment algorithm entirely online, without any modification of the consensus engine.
We use header's seal digest to store the PoW seal, and use the auxiliary store to store the total difficulty. The runtime interface PowApi::verify would take a header pre-hash, together with a seal. It will check whether the difficulty requirement is satisfied. If so, it returns the difficulty. The consensus engine then adds the given difficulty as total difficulty in the auxiliary store, and use that for best block selection.
For mining, we currently just use a simple runtime function PowApi::mine. It takes a header pre-hash, and is expected to loop until it finds a seal that satisfies the current difficulty.
Works still to be done for this PR:

[ ] Better mining routine. Currently it's a naive loop. We should take best block notification and interrupt current mining if a new block comes up.
[ ] Integration with srml-authorship. So that we handle coinbase.
[ ] A srml-pow module so that using the engine can be easier.

Things that can be improved, but probably not in this PR:

RPC methods for getWork and submitWork.

You can use a pre-runtime digest for the coinbase. A runtime API to fill it out using the runtime's keystore API would work perfectly for that.

I'm pulling this out of draft. There may still be many documentations or testing to be added, but in general I think it's ready for review (and merge).
There's a new abstraction added PowAlgorithm. One can use PowRuntimeAlgorithm to delegate the algorithm to runtime, or define a standalone implementation out of runtime. Hopefully this addresses some of the concerns of possible light client integration. For PowRuntimeAlgorithm, I still think we should be able to create a light client implementation for it. I'll try to draft a design for that and create an issue, but that'll be out of scope of this PR.
PowApi interface is slightly changed, to decouple difficulty and verify. The reason for this is that I find it simplify (a little bit) when using srml-pow.

As an aside, we should make doing parachains with proof-of-stake block production relatively easy and discourage parachains from actually using proof-of-work.  It's fine for testing of course but maybe bad optics if we have real parachains doing this.

@sorpaas Do you have time to work with someone from the docs team to help write some information about this?
How to use it, how it works, etc...
Would be looking to you to answer questions for whomever writes the docs.

@shawntabrizi Yeah for sure!

@sorpaas I've taken the lead on consensus on the docs team. Could we set up a call this week? I'll do my homework first. I'm @joshyorndorff:matrix.parity.io on riot. Tuesday or Wednesday would be fine. I'm UTC-8.

This PR implements PoW consensus engine in Substrate. We currently have a PoW verifier, and a simple thread-based miner. The PoW algorithm and difficulty adjustment algorithm is generic over PowAlgorithm struct. The caller is expected to implement one of this that suits its need.
For mining, we currently just use a simple runtime function PowAlgorithm::mine. It takes a header pre-hash, and is expected to loop until it finds a seal that satisfies the current difficulty.
Things that can be improved, but probably not in this PR:

RPC methods for getWork and submitWork.

come on, How to implement this RPC?


Add support for local agent execution

Fixes #13
This commit adds a new execution mode called "--local". This mode does not use Docker for isolation, and instead executes the agent directly on the host machine.
In order to do this, the changes add support for checking for and installing all of the software that the agent depends on.
Additionally, it changes the syntax of certain commands to make them more cross-platform compatible.
It also removes the udp-punch program as the Wireguard persistent keep-alive setting replaces the need for it.
Tested

Verified the --local flag records and runs a test successfully.
Verified without the flag that the Docker approach still works.
Connected to a running agent and killed the connect script, verified it exits.
Verified the agent exits when monitor dies while running locally.
Verified Ctrl+C properly kills all sub-processes.
Verified if I remove a dependency, the check script reports it.
Verified that the installation script succeeds and removes extra files.

When I run the script multiple times, I get an error from wireguard:
agent: toggling wireguard interface
Unable to access interface utun4: Permission denied
Warning: `/private/tmp/wg0.conf' is world accessible
[+] Interface for wg0 is utun4
wg-quick: `wg0' already exists as `utun4'
agent: failure in connect=, or monitor=true
agent: cleaning up...
agent: exiting
Reflect Agent exited unexpectedly: 1

We can sync more on this tomorrow.


Bug/uar 1283 confirmation dialog logs name in logs

JIRA link
https://companieshouse.atlassian.net/browse/UAR-1282
Change description
Don't include the bo or mo name in page title as that is logged by analytics.
Don't include the bo or mo name in Error raised in case that is logged.
Work checklist

[x] Tests added where applicable
[ ] UI changes meet accessibility criteria

Merge instructions
We are committed to keeping commit history clean, consistent and linear.  A BREAKING CHANGE can be part of commits of any type,
types other than fix: and feat: are allowed, for example build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others,
footers other than BREAKING CHANGE: <description> may be provided.

The ticket number linked doesn't appear to be the correct ticket? Let's make sure that the UI change was agreed with Gurur as I had chats with Jeremy about this ticket and heard nothing concrete back.


Test coverage with Coveralls

Check the coverage and include more tests (including integration tests for the tools).

Done in 152cb871e6e5e8b8a3003eb1104fb57096b075de


Test Bug

Verify CircleCI Build Check

@S1Y333 Great effort but make sure CircleCI is initiated when a PR is sent even from a forked repo.

check in your CircleCI advanced settings...

Thanks Redeem for your advice, I will practice what you suggested, does this count as a verified contribution? Thanks again
Sylvia

Once it's accepted you can record it

Once it's accepted you can record it

@Redeem-Grimm-Satoshi Mine is not accepted at the moment, right? Can you please let me know what I should do now? Thanks so much, I am confused.

@Redeem-Grimm-Satoshi Hi Redeem, I turned on Build forked pull requests, so it's good now?


Exclude runs that are not using the pathogen-repo-build workflow

Originally noted in Slack when we first included the ncov-ingest workflows.
We currently filter workflows to those that use the pathogen-repo-build workflow
https://github.com/nextstrain/status/blob/841b188463517ea1c5546098c714948d99518c00/pathogen-workflows.sql#L88
However, if the workflow had older runs that did not use the pathogen-repo-build, they are still included.

To do this filtering correctly, we'd need at least one of:

The history of a workflow's content (e.g. in Steampipe, github_workflow.workflow_file_content over time)
The workflow content associated with a specific workflow run (e.g. in Steampipe, github_actions_repository_workflow_run.github_workflow_file_content)

I thought Steampipe might already provide 2, but unfortunately it doesn't (because the GitHub API doesn't).
It is possible to generate either of those by walking git history for each workflow (for 1) or fetching the workflow content for each run individually by commit id (for 2) but neither are very efficient or appealing when applied across the many repos × workflows × workflow runs.
Since this issue only affects us for ~30 days after transitioning from not using pathogen-repo-build to using it, I'm not sure it's worth spending any more time on. If it's burdensome to have the bogus runs for those 30 days, a simpler filtering method would be to hard code "run after X" timestamps for workflows where we make this transition.

Since this issue only affects us for ~30 days after transitioning from not using pathogen-repo-build to using it, I'm not sure it's worth spending any more time on. If it's burdensome to have the bogus runs for those 30 days, a simpler filtering method would be to hard code "run after X" timestamps for workflows where we make this transition.

Based on @tsibley's comment quoted above, I'm going to close this issue out as "not planned".
If folks thing that we should do this work, or want to use this issue as the basis of the "run after X" approach, please re-open.


Turnstile

Creating a turnstile with textures

finished the main turnstile with the texture. Need the ends of the turnstile to finish a turnstile set but thats for the next sprint


Parse ISO stage

IEEE P24748-4/FDIS-Dec2015
IEEE P29119-4/DIS2-Feb2014
IEEE/IEC P60076-57-129_FDIS, July2017
ISO/IEC/IEEE P29119-2/FDIS, June2021
ISO/IEC/IEEE P29119-3_FDIS, June2021
ISO/IEC/IEEE P29119-4-DISMay2013
ISO/IEC/IEEE P12207-CD2-1410, October 2014
ISO/IEC/IEEE P12207-CD3-1502
ISO/IEC/IEEE P12207-CD4-1602
ISO/IEC/IEEE P12207-DIS-1610
ISO/IEC/IEEE P12207-FDIS-1707, June 2017
ISO/IEC/IEEE P14764/CD2, June 2020
ISO/IEC/IEEE P14764/DIS, January 2021
ISO/IEC/IEEE P14764/FDIS, July 2021
ISO/IEC/IEEE P15026-1/DIS
ISO/IEC/IEEE P15026-2/D1-CD, February 2020
ISO/IEC/IEEE P15026-4/DIS, February 2020
ISO/IEC/IEEE P15026-4/DIS2, February 2021
ISO/IEC/IEEE P15026-4/DIS2, September 2020
ISO/IEC/IEEE P15288-DIS-1403
ISO/IEC/IEEE P15288-FDIS-1412
ISO/IEC/IEEE P15288/ CD, March 2021
ISO/IEC/IEEE P15288/CD2-2013-09 (Revision of ISO/IEC/IEEE 15288:2008)
ISO/IEC/IEEE P15289 FDIS, February 2019
ISO/IEC/IEEE P15289:2016, 3rd Ed FDIS/D2
ISO/IEC/IEEE P16085/ FDIS, August 2020
ISO/IEC/IEEE P16085/CD2, February 2019
ISO/IEC/IEEE P16085/CD3, August 2019
ISO/IEC/IEEE P16326_FDIS, April 2019
ISO/IEC/IEEE P21839_DIS, July 2018
ISO/IEC/IEEE P21840, DIS-2019
ISO/IEC/IEEE P21840/FDIS_D4, July 2019
ISO/IEC/IEEE P23026/CD, January 2022
ISO/IEC/IEEE P24641/DIS, September 2021
ISO/IEC/IEEE P24641_D2_CD, June 2020
ISO/IEC/IEEE P24641_D3_CD2,March 2021
ISO/IEC/IEEE P24748-3/D3_FDIS, April 2020 (E)
ISO/IEC/IEEE P24748-4-DIS-1404, April 2014
ISO/IEC/IEEE P24748-4/DIS2-January 2015
ISO/IEC/IEEE P24748-5-CD3, February 2015
ISO/IEC/IEEE P24748-5-FDIS, December 2016
ISO/IEC/IEEE P24748-6/CD2, September 2021
ISO/IEC/IEEE P24748-9/CD, August 2021
ISO/IEC/IEEE P24748-9/WD.2, January 2021
ISO/IEC/IEEE P26511.2_FDIS 2018
ISO/IEC/IEEE P26514/CD2, August 2020
ISO/IEC/IEEE P26514/FDIS, August 2021
ISO/IEC/IEEE P26515 FDIS, May 2018
ISO/IEC/IEEE P26531/DIS, January 2022
ISO/IEC/IEEE P29119-1-FDIS, April 2013
ISO/IEC/IEEE P29119-1-FDIS, March 2013
ISO/IEC/IEEE P29119-1/CD, June 2020
ISO/IEC/IEEE P29119-1/DIS, December 2020
ISO/IEC/IEEE P29119-1/DIS, September 2012
ISO/IEC/IEEE P29119-2-FDIS, April 2013
ISO/IEC/IEEE P29119-2/CD Second edition, August 2019
ISO/IEC/IEEE P29119-2/DIS Second edition, April 2020
ISO/IEC/IEEE P29119-2_FDIS, December 2020
ISO/IEC/IEEE P29119-3-FDIS, April 2013
ISO/IEC/IEEE P29119-3/CD Second edition, August 2019
ISO/IEC/IEEE P29148_FDIS, September 2018
ISO/IEC/IEEE P42010.WD4:2019(E)
ISO/IEC/IEEE P42020 FDIS March 2019
ISO/IEC/IEEE P90003_FDIS, August 2018
ISO/IEC/IEEE/ P12207-2/D3_FDIS, July 2020
ISO/IEC/IEEE/ P21841/FDIS, April 2019
ISO/IEC/IEEE/ P24748-3/DIS, August 2019
ISO/IEC/IEEE/FDIS P24748-2/D3, June 2018
ISO/IEC/IEEE/FDIS P42030, March 2019
ISO/IEC/IEEE/P16085_DIS, March 2020
ISO/IEC/IEEE P29119-3/DIS Second edition, April 2020
ISO/IEC/IEEE P29119-4-CD3, September 2012
ISO/IEC/IEEE P29119-4-FDIS April 2015
ISO/IEC/IEEE P29119-4/FDIS, August 2019
ISO/IEC/IEEE P29119-4_CD2, February 2012
ISO/IEC/IEEE P29119-5-CD1 April 2014
ISO/IEC/IEEE P29119-5-DIS2-1504
ISO/IEC/IEEE P29119-5-FDIS1, July 2016
IEC/IEEE P61850-9-3_FDIS, February 2016
IEC/IEEE P61850-9-3_FDIS, March 2016
IEC/IEEE P61886-1_FDIS_D3.1, November 2020
IEC/IEEE P61886-2/CD, October 2021
IEC/IEEE P62209-1528_FDIS, August 2019
IEC/IEEE P62271-37-013/FDIS, June 2021
IEC/IEEE P60780-323, CDV1 2014
IEC/IEEE P60980-344 CDV D1, June2019
IEC/IEEE P61850-9-3_CDV July 2015
IEC/IEEE P62582-2/CDV, March 2021
IEC/IEEE P62582-4/CDV, March 2021
IEC/IEEE P62582-6, FDIS May 2019
IEC/IEEE P63113 CD4, April 2019
IEC/IEEE P63113 CDV, May 2020
IEC/IEEE P63113/FDIS, December 2020
IEC/IEEE P63195-1_FDIS, October 2021
IEC/IEEE P63195-2 ED2, February 2020
IEC/IEEE P63195-2 ED3, February 2021
IEC/IEEE P63195-2_FDIS, October 2021
IEC/IEEE P63195/ED1, 2018
IEC/IEEE P63195_CDV/V3, February 2020
IEC/IEEE P63195_FDIS, January 2021
IEC/IEEE P63198-2775_CD5.0, January 2021
IEC/IEEE P80005-1 ED2, October 2018
IEC/IEEE P80005-1:2019/AMD1, CDV August 2021
IEC/IEEE P80005-1:2019/AMD1_CDV, January 2021
IEC/IEEE P82079-1/ED2, February 2018
IEC/IEEE 80005-1:2019/AMD1:2022
IEC IEEE 62271-37-013:2015/COR1:2017
IEEE Std C37.09-2018 Cor1-2021
IEEE Std C37.101 -2006 (Revision of IEEE Std C37.101-1993/Incorporates IEEE Std C37.101-2006/Cor1:2007) - Redline
IEEE Std P12207_CD1
IEEE Std P15288/CD1
ISO/IEC/IEEE CD P15289, November 2017
ISO/IEC/IEEE CD P26513/D1, August 2015
ISO/IEC/IEEE CD P26515/D1, March 2017
ISO/IEC/IEEE CD P26531, June 2013
ISO/IEC/IEEE CD P26531_D2.1, December 2013
ISO/IEC/IEEE CD.1 P21839, October 2017
ISO/IEC/IEEE CD3 P15026-4
ISO/IEC/IEEE DIS P15939, August 2015
ISO/IEC/IEEE DIS P24748-2/D1, August 2017
ISO/IEC/IEEE DIS P26513, March 2016
ISO/IEC/IEEE DIS P26531/D2.2, March 2014
ISO/IEC/IEEE DIS P29119-5, August 2014
ISO/IEC/IEEE DIS P29148, September 2017
ISO/IEC/IEEE DIS P42030/D1, December 2017
ISO/IEC/IEEE FDIS P15289_D3, 2017
ISO/IEC/IEEE FDIS P15289_D4, 2017
ISO/IEC/IEEE FDIS P24765 FDIS, October 2016
ISO/IEC/IEEE FDIS P24765:2016(E), January 2017
ISO/IEC/IEEE FDIS P26512_D1, October 2016
ISO/IEC/IEEE FDIS P26512_D3, January 2017
ISO/IEC/IEEE FDIS P42030/D2, August 2018
P82079-1_D4_FDIS
IEC/IEEE FDIS 60079-30-2, 2015
IEC/IEEE FDIS P60079-30-1, 2015
IEC/IEEE FDIS P60780-323, 2015
IEC/IEEE CD P62704-5 ED1, 2018
IEC/IEEE CDV P62704-2/D4, July 2016
IEC/IEEE CDV80005-3, 2016
IEEE P15939_FDIS, 2016
IEEE P16085/CD, February 2018
IEEE P29119-2/FDIS, March 2013
IEEE P29119-3/FDIS, March 2013
IEEE/IEC/ISO P80005-1/FDIS_March 2012
IEEE/ISO/IEC P15026-3/CD, December 2021
IEEE/ISO/IEC P29119-2-DIS, December 2011
IEEE/ISO/IEC P29119-3-DIS2, September 2012
IEEE/ISO/IEC P29119-3/DIS, December 2011
IEEE/ISO/IEC P29119-4/DIS, April 2020
IEEE/ISO/IEC P29119-4/FDIS, June 2021
IEEE/ISO/IEC P29119-4_FDIS, December 2020
IEEE/ISO/IEC P42010.CD1-V1.0, April 2020
ISO /IEC/IEEE P24774/DIS, July 2020
ISO/IEC DIS P24748-1/D1, August 2017
ISO/IEC DIS P26511.2, May 2017
ISO/IEC FDIS P15289, April 2014(E)
ISO/IEEE DIS P11073-10418 D13, January 2011
ISO/IEEE DIS P11073-10418/D15, June 2011
ISO/IEEE DIS P11073-10418_D8, July 2010
IEEE P21840/CD, February 2018
IEEE P21841/CD2, February 2018
IEEE P62582-3/FDIS, September 2012
IEEE P15026.2/FDIS, August 2010
IEEE P15026-4/CD2, February 2018
ISO /IEC/IEEE P24774/DIS, July 2020
IEEE/ISO/IEC FDIS P26515, May 2018
IEEE/IEC P62582 CD2 proposal, May 2017
IEEE/IEC P63195-2 ED4, March 2021
IEEE P24748-1/FDIS, May 2018
IEEE P24748-5-CD3-July 2015
IEEE-P15026-3-DIS-January 2015
IEC FDIS 62271-111/IEEE Std C37.60/D7, August 2017

@ronaldtse What to do with number after "CD"? We don't have CD with numbers in pubid-iso.

@mico in pubid-iso there are CD entries: https://github.com/metanorma/pubid-iso/issues/1#issuecomment-1057553289
CDV is an IEC stage, it is like the CD but is called “CE for Voting”. We might want to do pubid-iec before doing CDV.

@mico the full list of IEC stages are available here:
https://github.com/relaton/relaton-iec/blob/0edb34766cef55d0d006747814df65062b8125de/lib/relaton_iec/statuses.yml

@mico the full list of IEC stages are available here:
https://github.com/relaton/relaton-iec/blob/0edb34766cef55d0d006747814df65062b8125de/lib/relaton_iec/statuses.yml

@ronaldtse I don't see "CDV" stage here. But there are stages like "ACDV", "CCDV", "CDVM"...
For pubid-iec we use "CDV" only for working documents. Should we add "CDV" for normal identifiers?

@mico actually there are 2 types of stages in IEC:

Document stage: https://www.iec.ch/standards-development/stages
Project stage: https://www.iec.ch/standards-development/stage-codes

For the document stage, I think we only care about the first. We should also consider these differences in the pubid-iec gem.


Adds function to Jump to Next / Prev errors

Fixes #82
Exposes functions
flake8#Flake8NextError() and flake8#Flake8PrevError()
that can be called to move the cursor to the next / prev error in the current file and also Show the error message under the cursor
This pull request depends on #81 for showing the error message of the current line.

@nvie Could you take a look at this?

Thanks for your contribution @skvrahul - it's on my list of things todo, and I will hopefully get to it soon. Thanks for your patience!

This would be a most welcomed addition to my workflow -- especially if it could populate the "movement list" (e.g. :cnext/:cprev or :lnext/:lprev ).

Thanks, @nvie! :champagne:


Entering the same 12 word seed phrase in connect 2 and into V2 wallet bring back different address

Is this because connect 2 is currently using the main-net derivation path and the stacks wallet V2 is using test-net? I was under the impression they would both be using the testnet?
Video of issue: http://somup.com/cYl0202doT in the video I will use seed phrase van praise reform tiger open rhythm buyer dizzy royal curve setup voice

@hstove @kyranjamie thoughts here?

@hstove @kyranjamie thoughts here?

wallet balance is also different

wallet balance is also different

This is because the wallet is using the derivation for identities, right?

This is because the wallet is using the derivation for identities, right?

This appears to be dependent on the derivation path updates that @hstove is making.

This appears to be dependent on the derivation path updates that @hstove is making.


Refactor defined type Splunk::Addon

Transitions the defined type Splunk::Addon to using the splunk*_input types instead of concat, supports installation from splunkbase provided archive, and valid for use on more than just forwarder nodes.

Thanks!


added checks for niter and nburnin in mcmc$run method

Adds checks in the mcmc$run method, for:
niter < 0
nburnin < 0
niter < nburnin
Any of these result in a helpful error message.

Testing passed, merging in


Save action returns an error if not interact with the dropdowns Currency and Company

When the Update Fund dialog is open and you click "Save" it returns an error saying the Currency must be selected (it happens also for Company) but the currency is selected.

Solved adding an empty option


Address bug issue #215 empty slides at end of carousel

#215
fix(vue): use currentPerPage to determine maxOffset, remove check on navigateTo watch preventing call of goToPage

Coverage increased (+0.7%) to 70.417% when pulling 1f7c0078daa3dabed7854ebe2336093c83f63371 on toddgroff:bug/215/empty_slides into ef6143150d865ba894f5f8c1808ea49e8c3556ce on SSENSE:master.

Hey @toddgroff, thanks a million for fixing this is been a huge issue! I'll test this morning, then merge and release if all is well :~)

Releasing now - just a heads up for transparency, I had to make some changes to the build files in order to resolve a conflict with the last patch. No files changed on your side, and I'm going to regen the build on release anyway :~)


Pin all dependencies with version 0.Y.Z

Per semver:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

https://semver.org/#spec-item-4

Accordingly, we should pin any dependencies with version 0.Y.Z, to prevent our packages failing if the dependency introduces breaking changes.

Runtime dependencies if we want to prioritize them:
from Mike

"dependencies": {
    "@types/tunnel": "^0.0.3",
    "process": "^0.11.10",
    "tunnel": "^0.0.6",
    "xml2js": "^0.4.19"
  },
event-hubs floats process as well


Add clear-all command

Feature Request

[x] Yes, I reviewed the contribution guidelines.

Describe your use case and the problem you are facing
There's currently no way of completely clearing the oembed cache. This is for example useful after one has added a oembed_dataparse filter to modify the HTML.
Describe the solution you'd like
I'd propose adding an cache clear-all command.
The quick and dirty version is to run DELETE FROM wp_posts WHERE post_type = 'oembed_cache' and DELETE FROM wp_postmeta WHERE meta_key LIKE '_oembed_%'.

@stefanfisk The use-case seems reasonable to me!
The feature itself might be better implemented by changing wp embed cache clear <post_id> to wp embed cache clear [<post_id>...] [--all].
With this change, the command should error if neither post IDs nor --all are provided.
Want to submit a pull request with Behat feature tests?


[SUPPORT] Optimized code ComparableVersion

Tips before filing an issue

Have you gone through our FAQs?

Join the mailing list to engage in conversations and get faster support at<EMAIL_ADDRESS>

If you have triaged this as a bug, then file an issue directly.

Describe the problem you faced
A clear and concise description of the problem.
To Reproduce
Steps to reproduce the behavior:

Optimized code ComparableVersion

Expected behavior
Optimized code ComparableVersion
Environment Description

Hudi version :

Spark version :

Hive version :

Hadoop version :

Storage (HDFS/S3/GCS..) :

Running on Docker? (yes/no) :

Additional context
Add any other context about the problem here.
Stacktrace
Add the stacktrace of the error.

@balloon72 Did you got a chance to provide more details here?


Feature/42

This has the naive implementation of a difficulty regulator.  Not really ready to call it finished as there's more merging between Lance's scaler and my regulator I have to do, such as subtract bucks as time progresses.   However, my regulator does the following:

If a patron gets too far to the right, they are destroyed, subtracting $50.
The game starts out w/ a 50% chance of a patron spawning every second.
If your bucks goes above 100, that chance is increased by 1% for every buck you have, to a minimum of 50%.
If your bucks go below 100, then it drops to 50% chance of spawn.
Max number of patrons on the screen is 10.  We could up this if we want.
Spawning all happens in one place, from the regulator.

TODO Items:

increase the speed of the patrons randomly.  They are a bit too uniform, and we probably want to increase the speed a bit in a subtle way, the more money the player has.  This would make anther way to scale difficulty.
Move more code from Lance's DifficultyScaler class into mine, so it's all in one place.  Starting my own class just helped me think through the process from scratch.
instead of checking every second to spawn, check more often.
maybe increase the max # of patrons to 20?

Give it a whirl and see if I'm on track.

Closing PR without pulling.  Work is still being done on feature/42.


The package does not support .NetFramework, version=4.5.

Hi
Just tried to install the package on a project targeting .Net 4.5 and got the below error. Is this expected? If so, is there an intention to support 4.5 in the future? Thanks.
Could not install package 'Microsoft.AspNetCore.Mvc.Versioning 2.0.0'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.5', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.

Are you looking the ASP.NET Web API or ASP.NET Core version of the package? The package id that you listed is for ASP.NET Core, which has never supported .NET 4.5. ASP.NET Core 1.0/1.1 target .NET 4.5.1 and .NET Standard 1.6. ASP.NET Core 2.0 targets .NET Standard 2.0, which maps to .NET 4.6.1 and above.
If you're looking for the ASP.NET Web API version of the package, you can find it here. That version does target .NET 4.5.
I hope that helps.

@commonsensesoftware, I am trying to add the nuget package Microsoft.AspNetCore.Mvc.Versioning for a .NET Core 2.0 project that targets .NET Framework 4.6.2.
It says it is incompatible: "Package Microsoft.AspNetCore.Mvc.Versioning 2.0.0 is not compatible with net462 (.NETFramework,Version=v4.6.2). Package Microsoft.AspNetCore.Mvc.Versioning 2.0.0 supports: netstandard2.0 (.NETStandard,Version=v2.0)"
Is there any way to use Microsoft.AspNetCore.Mvc.Versioning in this project without changing its target?

Please correct me if I'm wrong, but I think there is a mix-up of terminology and possibly tooling. Let me clarify.
The latest version of API versioning for ASP.NET Core targets .NET Standard 2.0. The dependency graph looks like: API Versioning 2.0 → ASP.NET Core 2.0 → .NET Standard 2.0
.NET Standard is not a target platform, but rather a contract for a set of APIs that are platform-neutral. This means that libraries that target .NET Standard 2.0 can run on both the .NET Framework and .NET Core. .NET Standard 2.0 is compatible with the .NET Framework 4.6.1 and later.

Note: The .NET Standard 2.0 tooling is available in Visual Studio 2017 15.3 and above. I'm not sure about Visual Studio 2015, if that applies to you.

It's not possible to target .NET Framework 4.6.2 (net462) for a .NET Core (netcoreapp2.0) application. It is, however, possible to create an ASP.NET Core 2.0 application that targets either  .NET Framework 4.6.2 or .NET Core 2.0.

Aside: Thanks marketing guys for overloading the term "Core"

I suppose the proof is in the pudding, so here's what a working project with ASP.NET Core 2.0 and API Versioning 2.0 that target the .NET Framework 4.6.2 should look like:
<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net462</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <Folder Include="wwwroot\" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore" Version="2.0.1" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="2.0.1" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc.Versioning" Version="2.0.0" />
  </ItemGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.1" />
  </ItemGroup>
</Project>

I'm happy to attach the full project here for you if it's useful, but these should be the only relevant tastey bits.

In fact I was mixing up both Core terms. Sorry about that.
I found out that my problem was not related with this package. It was a VS issue. It was something similar to this: https://stackoverflow.com/questions/45802909/updating-to-asp-net-core-2-0-packages-are-not-compatible-with-netcoreapp2-0
I updated VS from version 15.2.? to 15.4.4 and then the package could be installed.
Thanks for your time!

No problem. Yeah - this is because ASP.NET Core moved to .NET Standard 2.0. The tooling for it only became available in Visual Studio 15.3+.
I hit this issue myself and the error messages are ... well ... less than helpful. Some folks asked for preview versions as well. You can imagine how much fun that was. >_<
Glad you got things working.

Thanks @commonsensesoftware  and @joaocpribeiro. I think my issue is also about VS2013 vs VS2017. I will find some time to upgrade my tools and use VS2017. I bet the issue will go away as you guys also noted :)

This appears to be resolved. Let me know if you continue to run into issues. Thanks.


Support FP16 in Allreduce of all communicators

The current version of ChainerMN supports FP16 in Allreuce of PureNcclCommunicator only.
ChainerMN should support FP16 in Allreduce of all communicators

This issue was solved by https://github.com/chainer/chainer/issues/6330 https://github.com/chainer/chainer/pull/6448


Streaming disconnected

Describe the bug
Whenever I try to connect to the streaming API I get Error: disconnected. I also tried making a connection myself without this library and got the same message so maybe it is a general problem.
Steps To Reproduce
Identify the steps to reproduce the behavior:
Run the following code:
var tjs = require('teslajs');
var streamingOptions = {
    vehicle_id: vehicleId,
    authToken: authToken
};
tjs.startStreaming(streamingOptions, function (error, response, body) {
    if (error) {
      console.log(error);
      return;
    }
    // display the streaming results
    console.log(body);
    console.log("...Streaming ended.".cyan);
  });

Expected behavior
A connection to the streaming API should be made
Library version
4.9.5
Additional context

Tested with a Model 3 LR on 2<IP_ADDRESS>
Tested while charging at home
Also tried to stop charging and to turn on climate while connecting to change streaming values

Update
I managed to get one data:updated message using my own code byresending the subscribe_oauth message. Perhaps it would make sense to add this logic into teslajs? My sample code is here:
  const options = {
    "vehicleId": "123456789",
    "authToken": "1234567891011121314"
}
  const streamingColumns = ['elevation', 'est_heading', 'est_lat', 'est_lng', 'est_range', 'heading', 'odometer', 'power', 'range', 'shift_state', 'speed', 'soc']
  const streamingUrl = `wss://streaming.vn.teslamotors.com/streaming/`
  const ws = new WebSocket(streamingUrl, {
    perMessageDeflate: false
  })
  ws.on('message', function (data) {
    const d = JSON.parse(data)
    console.log(d)
    if (d.msg_type === 'control:hello') {
      ws.send(JSON.stringify({
        msg_type: 'data:subscribe_oauth',
        token: options.authToken,
        value: streamingColumns.join(','),
        tag: options.vehicleId.toString()
      }));
    }
    if (d.msg_type === 'data:error') {
      ws.send(JSON.stringify({
        msg_type: 'data:subscribe_oauth',
        token: options.authToken,
        value: streamingColumns.join(','),
        tag: options.vehicleId.toString()
      }));
    }
  })

Did you try the streaming sample?

Hi @mseminatore
I tried the streaming sample and get the same error:
Vehicle MYVIN - Model 3 ( 'Steve' ) is: ONLINE

Note: Inactive vehicle streaming responses can take up to several minutes.

Streaming starting...
Columns: timestamp,elevation,est_heading,est_lat,est_lng,est_range,heading,odometer,power,range,shift_state,speed,soc
Error: disconnected
Websocket disconnected

Found out some more information today by looking around: https://forum.abetterrouteplanner.com/topic/2250-abrp-losing-connection-to-battery-status/page/2/?tab=comments#comment-6961
I was also using Teslamate which also uses the streaming API. I guess it appears that if you are using another service like this it can cause the error in this issue. I tried stopping Teslamate and trying my code again and it worked.

When I run the sample I get back one response and then it disconnects. This is typical of a parked car that his sleeping or hibernating (as mine is).
Vehicle - Model S ( 'Electra' ) is: ONLINE
Note: Inactive vehicle streaming responses can take up to several minutes.
Streaming starting...
Columns: timestamp,elevation,est_heading,est_lat,est_lng,est_range,heading,odometer,power,range,shift_state,speed,soc
{
msg_type: 'data:update',
tag: '2010246753',
value:
}
...Streaming ended.
Error: disconnected

So this issue has gone away now. The only thing that changed was that I got an update from 2<IP_ADDRESS> to 2020.48.26


Release v0.3.0

With this PR we start the release workflow for version 0.3.0. Changes introduced with this release are listed in the CHANGELOG.md. Furthermore, this PR adds the automated release workflow to the GitHub actions.
Additional remarks

We dropped the -alpha suffix on the version with this release.
The order of authors is changed according to their contribution and dedication to the project.
This release is the first one from the new home of minterpy: github.com/minterpy-project/minterpy.git

TODOs

[x] add pypi publishing workflow

Hi @szabo137,
Thank you very much for this! Everything looks good.
To confirm:

once this PR is merged to main, we're making another step to tag the release so it triggers the push to PyPI, or?
If that so, I suppose we should later prepare a release notes?
This PR is directly from  a modified dev to main, so once merged the main will be ahead dev, should we later then merge main back to dev so everything will be nicely synchronized (I mean the changes are mainly GitHub workflows) before we move forward with dev again later?

once this PR is merged to main, we're making another step to tag the release so it triggers the push to PyPI, or?

Yes, this is how it should work. If not, we can do the pypi registration by hand based on the tag and come back to fix the workflow for publishing later.

If that so, I suppose we should later prepare a release notes?

This is correct, but we can always update release notes on gh-releases later. For later releases, the respective part of the publishing workflow will generate the release notes from the gh-PRs which went into the release.

This PR is directly from  a modified dev to main, so once merged the main will be ahead dev, should we later then merge main back to dev so everything will be nicely synchronized (I mean the changes are mainly GitHub workflows) before we move forward with dev again later?

Indeed, the release branch is merges back into dev later. This brings dev and main in sync again, as long as we don't squash the commits before merging.


Thumbnail selection partial showing in /edit

E.g.: http://lib-plum1.princeton.edu/concern/scanned_resources/prn301141f/edit

Do we want to remove this?

Yeah, the file manager handles this now.


[atom-reason] merlin integration broken

It seems that merlin integration with atom/nuclide has stopped working with 814c110d4bda4219de5a4a4625cd7d44860aab0c (after applying the fix from #741). I don't have the error message in front of me at the moment, but IIRC, it said something about invalid arguments to merlin. Maybe the merlin interface has changed?
I think it's unrelated but I've been having a number of other issues with the merlin integration even before this latest commit. Sometimes type on hover will just stop working and if I open the Chrome console it says something about assertion errors in printtyp.ml. It doesn't seem to happen until after I start using a lot of modules so maybe it has something to do with a problem printing qualified items. Wondering if anyone else has encountered this.

We are now using Merlin from master instead of a separate branch - see also: https://github.com/facebook/reason/pull/740. My fix PR is intended to align Travis with this change.

I am also pinning merlin from master now but still seeing the problems with nuclide. I tried installing nuclide from master but didn't see any change in the behavior. Does nuclide itself need to be updated to work with master?

@freebroccolo Will look into it, but did you also pin merlin-extend from master?

I just tried repinning Reason master, with merlin master, and merlin-extend master, and Atom works well for me (version 1.11 beta). Let me know if you still see issues. I'll try to make a sticky post in the gitter channel.

merlin with latest master works for me too.

@vramana You had to pin merlin-extend master too right?

@jordwalke Yes. I followed the updated Contributors guide.

@jordwalke yeah, I unpinned/uninstalled reason, merlin_extend, and merlin and repinned them all to master respectively. I also tried removing all the atom reason packages (3 of them) and nuclide and deleting the atom compile cache and reinstalling. At one point I tried using nuclide from master too.
It's possible that somehow my configuration got in a bad state but the last configuration I was able to get to work without merlin errors in the console was:

release nuclide
release atom reason packages
merlin#reason-0.0.1
merlin-extend#reason-0.0.1
reason#499c11d

I will try again in a little while and see if I can get it working. It was definitely saying something about merlin throwing an "invalid arguments" but I couldn't tell much beyond that.

Linux right?

I was using Mac OS actually (10.11.6). Most stuff installed via homebrew and then I was using an ocaml 4.02.3 switch via opam (from homebrew).
I'll try to give it another go tonight though and see if I run into problems again. Thanks for looking into it though. If nobody else is seeing it was probably just some fluke on my end.

@freebroccolo No worries. This kind of fluke is a bad user experience that we want to avoid.

We hope that the new sandbox model will make all of these weird conflicts an impossibility.

Okay, I just tested again and it is working for me now with reason pinned to master so I'll go ahead and close this.


add macvlan support

Hi Michael,
I added Macvlan support to be able to connect your cEOS instances to an CVP instance outside of the Docker host. Please check and be kind to my code - I'm an SE and no programmer 😅

Thanks man, looks interesting. I'm a bit busy atm, will have a closer look over the weekend.
What's you usecase? Why do you need to connect this to outside box? Because you can run CVP in a container on the same host..

My usecase is double; I already had a CVP instance running on another
machine, and in addition to that I was not able to run the CVP container
due to my working environment was already within a LXC container (later on
I discovered this also breaks cEOS' forwarding plane, but that's a separate
issue).
My main thought was that this would make deploying testbeds more flexible.
Op do 3 mei 2018 om 14:32 schreef networkop<EMAIL_ADDRESS>
Thanks man, looks interesting. I'm a bit busy atm, will have a closer look
over the weekend.
What's you usecase? Why do you need to connect this to outside box?
Because you can run CVP in a container on the same host..
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/networkop/arista-ceos-topo/pull/3#issuecomment-386279803,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAwLekpDByumIDQ-crDWKK29kfGWxBl-ks5tuvj3gaJpZM4Tw0mG
.

I was thinking about using macvlan but in a slightly different way. Since each element in links is a representation of a physical link, i was thinking about adding some metadata to the elements of the list and build a network with a different driver. Something like this:
links:

driver: macvlan
endpoints: ["Device-1:Interface1", "Device-2:Interface1"]
driver: bridge
endpoints: ["Device-1:Interface2", "Device-2:Interface2"]
Which, I think is similar to what you've done. Anyhow, i'll play with the idea over the weekend.

BTW, Why do you need to connect CVP over the macvlan bridge? wouldn't it work just using the normal routed IP?

That's exactly what I was thinking. Be able to add direct veth as one of the drivers for folks who like LACP.
Do you want to have a shot at it?
I was thinking to split the topology build from main into its own function, and also provide yaml file versioning, similar to docker-compose, so that we can make non-backwards compatible changes without breaking things for everyone.
This way in topology build function I can basically have something like this
if yaml_version == 1:
build_topo_v1(*args)
elif yaml_version == 2:
build_topo_v2(*args)
else:
LOG.error("wrong version")

Sounds good. I've got some time today to start works on it. Will push to my
git repo; working or broken as I won't have a lot of time this weekend.
Will let you know.
Op vr 4 mei 2018 om 11:35 schreef networkop<EMAIL_ADDRESS>
That's exactly what I was thinking. Be able to add direct veth as one of
the drivers for folks who like LACP.
Do you want to have a shot at it?
I was thinking to split the topology build from main into its own
function, and also provide yaml file versioning, similar to docker-compose,
so that we can make non-backwards compatible changes without breaking
things for everyone.
This way in topology build function I can basically have something like
this
if yaml_version == 1:
build_topo_v1(*args)
elif yaml_version == 2:
build_topo_v2(*args)
else:
LOG.error("wrong version")
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/networkop/arista-ceos-topo/pull/3#issuecomment-386550709,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAwLenJakhppu9V9l3fTJl-jT_KWGi3iks5tvCDggaJpZM4Tw0mG
.

See https://github.com/jorisc90/arista-ceos-topo
Current state is broken; had it working before... can't find what I'm doing
wrong so quickly.
({'Device-A': <main.CEOS object at 0x7f353b149b00>, 'Device-B':
<main.CEOS object at 0x7f353b149b70>}, [<main.Link object at
0x7f353b149e48>])
Traceback (most recent call last):
File "./bin/ceos-topo", line 465, in
main()
File "./bin/ceos-topo", line 430, in main
for idx,name in enumerate(sorted(devices.keys())):
AttributeError: 'tuple' object has no attribute 'keys'
I put in the config versioning and parsing, both macvlan and bridge logic
are in. Veth pairs not started yet.
Cheers,
Op vr 4 mei 2018 om 11:42 schreef Joris Claassen<EMAIL_ADDRESS>
Sounds good. I've got some time today to start works on it. Will push to
my git repo; working or broken as I won't have a lot of time this weekend.
Will let you know.
Op vr 4 mei 2018 om 11:35 schreef networkop<EMAIL_ADDRESS>
That's exactly what I was thinking. Be able to add direct veth as one of
the drivers for folks who like LACP.
Do you want to have a shot at it?
I was thinking to split the topology build from main into its own
function, and also provide yaml file versioning, similar to docker-compose,
so that we can make non-backwards compatible changes without breaking
things for everyone.
This way in topology build function I can basically have something like
this
if yaml_version == 1:
build_topo_v1(*args)
elif yaml_version == 2:
build_topo_v2(*args)
else:
LOG.error("wrong version")
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/networkop/arista-ceos-topo/pull/3#issuecomment-386550709,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAwLenJakhppu9V9l3fTJl-jT_KWGi3iks5tvCDggaJpZM4Tw0mG
.

no worries, will check it out over the weekend. have a good one yourself!

i think i got it working in my dev branch based on what you've done with some modifications. check it out, see if it works for you.

I've already done veth as well. I couldn't think of a "API" way of doing this so I done it with shell commands.
You can test it and see if it works for you. I've tried with a couple of cEOS interconnected B2B and it worked. (at least i could ping over an LACP port-channel).
If you know of a better way of doing this, that wouldn't involve bunch of shell commands - let me know. I'd be interested to throw them out and replace with a cleaner code.

I also thought of this as the "easy" way. If I read correctly, support was
added to pyroute2: https://github.com/svinota/pyroute2/issues/84
Could be of help to clean the code.
Op ma 7 mei 2018 om 13:25 schreef networkop<EMAIL_ADDRESS>
I've already done veth as well. I couldn't think of a "API" way of doing
this so I done it with shell commands.
You can test it and see if it works for you. I've tried with a couple of
cEOS interconnected B2B and it worked. (at least i could ping over an LACP
port-channel).
If you know of a better way of doing this, that wouldn't involve bunch of
shell commands - let me know. I'd be interested to throw them out and
replace with a cleaner code.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/networkop/arista-ceos-topo/pull/3#issuecomment-387035876,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAwLenRoW172YNqPrDp8TDJk9vc7eLa7ks5twC8ngaJpZM4Tw0mG
.

wow, this is super cool. I've never seen that library before. It's definitely worth re-writing what we can with this.

everything's been merged into master in https://github.com/networkop/arista-ceos-topo/pull/4


Upstream source tests

Add a set of checks against a source checkout of universal_robot repo in kinetic.
See #266.

A couple of jobs demonstrating the intended effect:

https://travis-ci.org/miguelprada/ur_modern_driver/builds/501429852
https://travis-ci.org/miguelprada/ur_modern_driver/builds/501431277

Thanks. This is indeed what I had in mind.
Remaining issue is: the regular tests are going to fail (as #266 describes), so GH will block merging by anyone except admins (at least with the current repository settings).
I'm not against giving people admin rights, but it also means that merges will look like they were "forced" by an admin overriding CI results.

Not sure there's much alternative, other than allowing the other tests to fail, and only requiring the "new ones". Not ideal, but shouldn't be discarded.
Is this handled differently in the buildfarm jobs? Not familiar enough with how that works. Can e.g. universal_robot be bloomed so that ur_modern_driver jobs can be tested against the release candidate in the shadow-fixed repo?

Is this handled differently in the buildfarm jobs? Not familiar enough with how that works. Can e.g. universal_robot be bloomed so that ur_modern_driver jobs can be tested against the release candidate in the shadow-fixed repo?

Releases of ur_modern_driver would fail in the exact same way: packages are only built against released versions of other packages.

So are configurations such as this one always require two syncs in order to add a feature that requires changes in both repositories? I must say I'm surprised there's no workaround for that.

No, the buildfarm builds against shadow-fixed.

Ok. Getting sidetracked here, though.
About the original matter. What would you like to do?

So, should we merge this as is? What do you think, @gavanderhoorn? Would you like anything else to be discussed/added to this PR?

The only way I see -- or at least without custom Travis scripts -- this work without having to merge PRs that fail CI would be to add all "standard" build tests to the "allowed to fail" part of the matrix, and to make the builds that use upstream of universal_robot required to pass.
I'm open to suggestions for other approaches, but I'm not sure there are any: if a PR depends on a feature not yet merged into universal_robot (and has seen a release) it will fail the CI builds that use binary packages.

The only way I see this work without having to merge PRs that fail CI -- or at least without custom Travis scripts -- would be to add all "standard" build tests to the "allowed to fail" part of the matrix, and to make the builds that use upstream of universal_robot required to pass.

Mee too. I'll let you either merge this as it is, or close it and assume we either "force merge" some PRs or wait for required features of universal_robot to be released.

@miguelprada: I decided to squash-merge this, as the your commit was essentially a "trial".
Thanks for the PR and let's keep an eye on whether this actually works satisfactorily.


Composition and generics

This errors:
R.compose(R.fromPairs)([['1','A'], ['2','B'], ['3','C']])

[ts] Argument of type '[string, string][]' is not assignable to parameter of type 'KeyValuePair<number, any>[]'.
  Type '[string, string]' is not assignable to type 'KeyValuePair<number, any>'.
    Types of property '0' are incompatible.
      Type 'string' is not assignable to type 'number'.

Though this works as it should (without compose and with numbered index)
R.fromPairs([['1','A'], ['2','B'], ['3','C']])

R.compose(R.fromPairs)([[1,'A'], [2,'B'], [3,'C']])

Thank you for posting this.
From what I can see, this issue relates to interaction between composition and functions with generics. The more recent thread #92 appeared to be about the same problem. I currently intend to track this issue in #78, about currying rather than composition but otherwise seemingly the same issue. I've integrated your example into the test suite, so we won't forget.
I agree inference failing here is a significant issue, and I hope we can find a solution.

Minimum reproduction: R.pipe(R.identity) kills generics, degenerating to {} => {}.

Comes down to https://github.com/Microsoft/TypeScript/pull/16072#issuecomment-310996281. May get viable after https://github.com/Microsoft/TypeScript/issues/6606.


Add sentry

What is this PR trying to achieve?
Adding sentry so we can start catching client errors RUM like.
What does it look like?

For interface components

[x] Browser testing - Have you checked the component in our supported browsers

In regards to the rather brutal execution - see #415 as a TODO.


Doubt about Multiple Graphs

When I run dgmc on batch multi-graphs, the S_L get the wrong size and values. But I look the test_dgmc and believe that the model support it. So I want to know that wether it can run the batch data on multi-graph

You mean a graph with multiple (typed) edges? Sure, that should be no problem. Since DGMC only considers node correspondences in S_L, I am wondering what you mean with "it gets the wrong size". Maybe you can show me a minimal example to reproduce?

You paper mentioned that Vs<=Vt, so I try the case Gs have 2 nodes and Gt have 5 nodes and it works. But I try the case there are different graphs of Vs<=Vt, the result of S_L make me confused.
For example,
v1s = torch.randn(2, 32)
e1s = torch.tensor([[0, 1], [1, 1]])
data1s = Data(x=v1s, edge_index=e1s)
v1t=torch.randn(4, 32)
e1t=torch.tensor([[0, 1, 1, 2, 2, 3], [1, 0, 2, 1, 3, 2]])
data1t = Data(x=v1t, edge_index=e1t)
v2s = torch.randn(3, 32)
e2s = torch.tensor([[0, 1,2], [1, 2,0]])
data2s = Data(x=v2s, edge_index=e2s)
v2t = torch.randn(5, 32)
e2t = torch.tensor([[0, 1, 1, 3, 2, 3], [1, 0, 2, 4, 3, 2]])
data2t = Data(x=v2t, edge_index=e2t)
v3s = torch.randn(2, 32)
e3s = torch.tensor([[1,0], [0,1]])
data3s = Data(x=v3s, edge_index=e3s)
v3t = torch.randn(3, 32)
e3t = torch.tensor([[0, 1, 1, 2], [1, 2, 1, 2]])
data3t = Data(x=v3t, edge_index=e3t)
batchs = Batch.from_data_list([data1s, data2s,data3s])
batcht = Batch.from_data_list([data1t, data2t,data3t])
psi_1 = GIN(32, 16, num_layers=2)
psi_2 = GIN(8, 8, num_layers=2)
model = DGMC(psi_1, psi_2, num_steps=2,k=10)
_, S_L = model(batchs.x,batchs.edge_index,None,batchs.batch,batcht.x,batcht.edge_index,None,batcht.batch)
print(S_L.size())

cmd: torch.Size([7, 5])

That looks correct to me. Note that S_L isn't handles as a [batch_size, max_num_nodes_s, max_num_nodes_t] matrix, but instead unifies batch_size and num_nodes_s in the first dimension to save memory. So we have 2+3+2=7 in the first dimension and max(4, 5, 3)=5 in the second dimension.

I get it. So dealing with the batch graphs with vs<=vt, the code is practical when the num nodes of target graphs are same. Thanks


Should columns also respect from?

Usually many files would have merged cells as header in the top.
So when I specific columns as true, it actually shouldn't read from the first line.
So I think it's should also respect the from configuration.
When we specific both of them, I would expect it's getting the columns name start at from.
Someone else meet similar situation.
#144
Thanks for your great work.

Closing due to lack of activity.


(DOCSP-16607) Backfills Atlas CLI content for several clusters commands

Proposed changes
Backfills content for several Atlas CLI clusters commands
Jira tickets:
https://jira.mongodb.org/browse/DOCSP-16607
https://jira.mongodb.org/browse/DOCSP-16610
https://jira.mongodb.org/browse/DOCSP-16611
https://jira.mongodb.org/browse/DOCSP-16612
https://jira.mongodb.org/browse/DOCSP-16614
https://jira.mongodb.org/browse/DOCSP-16616
Checklist

[x] I have signed the MongoDB CLA
[ ] I have added tests that prove my fix is effective or that my feature works
[x] I have added any necessary documentation in document requirements section listed in CONTRIBUTING.md (if appropriate)
[ ] I have addressed the @mongodb/docs-cloud-team comments (if appropriate)
[ ] I have updated test/README.md (if an e2e test has been added)
[ ] I have run make fmt and formatted my code

yes, failures are not related. Thanks!