Golang is bad at floating point numbers

What version of Go are you using (go version)?

$ go version
go version go1.14.7 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=""
GOARCH="amd64"
GOBIN="/home/vj0r/GOLANG/bin"
GOCACHE="/home/vj0r/.cache/go-build"
GOENV="/home/vj0r/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/vj0r/GOLANG"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go-1.14"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.14/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-build355855424=/tmp/go-build -gno-record-gcc-switches"

What did you do?
Provide code that calculates the average of the floating point numbers read from a file
If the file with numbers of size 50M the count is performed flawlessly. And the values are the same from other programming languages.
If the file is 245M in size, then the golang does not count correctly. Most likely, there is an accumulation of errors.
File from go

package main

import (
	"bufio"
	"fmt"
	"log"
	"os"
	"strconv"
	"strings"
)

func main() {

	file, err := os.Open("./file")
	panicm(err)
	read := bufio.NewScanner(file)
	var sum float32 = 0
	var i int = 0
	for read.Scan() {

		res := strings.TrimSpace(read.Text())
		r1, err := strconv.ParseFloat(res, 32)
		panicm(err)
		sum += float32(r1)
		i++
	}

	err = file.Close()
	panicm(err)

	fmt.Printf("%F\n", sum/float32(i))
}

func panicm(err error) {
	if err != nil {
		log.Panic(err)
	}
}

file with numbers like:

$ cat file
56.2
89.5
71.8
56.2
......

$ du -sh file
245M	file

go build loadfile.go
$ ./loadfile
101.770912

$ perl -e 'open(fd,"file"); $sum=0; $i=0; while(){$sum+=$_; $i++} print $sum/$i'
150.811212282527

$awk 'BEGIN {sum=0; count=0} {sum+=$1; count++} END{print sum/count}' file
150.811

$ cat loadfile.py
#!/usr/bin/python3
f = open("./file")
sum=0
i=0
for ch in f.readlines():
    sum+=float(ch)
    i+=1
print(sum/i)

$ ./loadfile.py
150.8112122825271

What did you expect to see?
150.811212
What did you see instead?
101.770912

should be used float64

should be used


GetConnectionbyPublic does not work

If not exists, it should return ǹil`but i get an Connection from another token.
https://github.com/NoProvider2Push/dbus/blob/832eb6eff90fd67585d5d4d87a86a9e56cbda7d0/storage/storage.go#L64-L67

test to validate: a4e0dd7ea24bc13c13c91c348a6460d792fb03bc
fix is in 126ddf5bc7163d5b2ac269f1775d8cd6931e6281
part of PR #17


Improve panic handling

What do you think about improving the panic handling? I was thinking of a custom handler or passing an error to all results in case of a panic? Or do you believe one should do this in the batchFunc itself?

We currently catch panics that happen in the batch function and pass the error to all results. The relative code can be found here: https://github.com/nicksrandall/dataloader/blob/v5/dataloader.go#L419-L441
What are you proposing we do on top of that?

Ah missed that part below it, then there is something up in my tests (using gomock), the test hangs when a gomock panic occurs. I'll investigate and report back if there were any issues related to this library.
&Result{Error: fmt.Errorf("Panic received in batch function: %v", panicErr)}
An improvement to the library might be to be able to configure a 'panic handler', i.e., a func(panicErr interface{}) Result. But this is of course a minor improvement.

Consumers of this library may implement their own panic handler inside the batch function if they wish to. As such, I'm not convinced that we need such a feature baked into the library.


RegistrationsController#edit does not respect Accept type

RegistrationsController#edit renders a view without respect to the Accept type. Unless I'm missing something, it should be:
def edit
  respond_with resource
end

With this change, it will serve JSON when requested, which is useful in the case of using Devise in an API, for example.
If correct, I'm happy to make a PR.

Looks like this change is ok, but I don't know if I missing something 🤔
@rafaelfranca @feliperenan WDYT?

I think is ok too.
PS: We already use respond_with resource in the new action.
https://github.com/plataformatec/devise/blob/451ba5362b84ff18a31ea1b3251137128a6b1beb/app/controllers/devise/registrations_controller.rb#L10

edit actions usually doesn't make sense in API requests. It is a navigational action, to render a form to edit the user.
In APIs you should be accessing the show action to get the user response and making the request to the update action.
That said I think the registration controller should either keep its actual behavior or respond with a 406 when asked for anything that is not a HTML.

Makes sense, the current behavior stays the same and I'm going to close this issue.
Thanks!


Can't set collateral with ledger nano X

My ledger works fine for transactions but Nami doesn't see it when trying to set collateral.
Any ideas?

See #359 and #351.
Seems to be not possible at the moment. Wouldn't make much sense, anyway, 'cause smart contracts are not possible with Ledger at the moment.


Geoevent adapters missing

Missing adapters causing issues with "inputs"
AFM_UDP_In
Status: Error - Stopping Stream 'AFM_UDP_In' because the Adapter is not available.
buoy-regexText-in
Status: Error - Stopping Stream 'buoy-regexText-in' because the Adapter is not available.
metar-regexText-in
Status: Error - Stopping Stream 'metar-regexText-in' because the Adapter is not available.
twitter-in
Status: Error - Stopping Stream 'twitter-in' because the Adapter is not available.,Stopping Stream 'twitter-in' because the Transport is not available.
SeismicEventsIn
Status: Error - Address already in use : Bind
symbolid-tcp-text-in
Status: Error - Address already in use : Bind

@pHill5136  - I am facing similar adapters missing issue on Azure event hub connectors. Any clue to debug/fix?


Fix bug #894, resolve #773.

#773 -> Change $cordovaCamera to provider, now you can configure options for camera plugin easily and friendly, using new setters methods. I will update the documentation.
#894 -> Really had error when we tried to execute demo app using cordova serve or ionic serve. Was fixed.

This is great; can you base this PR off of dev-next?  That's the dev branch we use to ensure everything is good before going into master.


[Feature] CldVideoPlayer autoplay should respect browser standard prop of autoplay without captilization

Feature Request
Is your feature request related to a problem? Please describe.
The browser standard video tag uses autoplay without capitalization. The CldVideoPlayer should have the same.
Describe the solution you'd like
autoplay="always" should result in autoplayMode="always" on the playerOptions object.
further, we should support the autoplay prop being passed as a boolean, so:
<CldVideoPlayer autoplay
<CldVideoPlayer autoplay={true}

This however shoudl act as if it were the standard autoplay attribute, which would add autoplay: true to the playerOptions object.
For backwards compatability, autoPlay should still be supported, but pass its value to autoplay
To sum up:

<CldVideoPlayer autoplay => playerOptions.autoplay = true
<CldVideoPlayer autoplay={true} => playerOptions.autoplay = true
<CldVideoPlayer autoplay={false} => playerOptions.autoplay = false
<CldVideoPlayer autoplay="always" => playerOptions.autoplayMode = 'always'
<CldVideoPlayer autoplay="never" => playerOptions.autoplayMode = 'never'
<CldVideoPlayer autoPlay="always" => playerOptions.autoplayMode = 'always'

Booleans get passed to autoplay and strings get passed to autoplayMode

Hello @colbyfayock , I would like to work on this issue

all yours @codingis4noobs2
wanted to give a heads up that tomororw is the last day for Hacktoberfest contributions
if you open a PR with a majority of the work done, with only edits and tweaks being needed but merged later, it will still count!

hey @codingis4noobs2 were you still planning on working on this?

Hi @colbyfayock , currently my final exams are going on, so I rarely get some time
If I don't make a pr within 2-3 days you may assign it to diff. person 🙂

Sounds good. Good luck on the exams!

Hi @colbyfayock, i would like to pick this up if its still open

all yours @DevYemi


small packages of adjustments for backend test services and new dockers for GVC client

This PR address need for dockers of catalyst-backend /  snapshot service / snapshot service wormhole.
An example was provided in docker-compose file. Small fixes like accept configuration path from ENV or more verbose error reporting were done

Please hold on with review. I found one issue in the code i need to fix before handing it to review


Extreme Tux Racer

IRC request there https://ghost.ced117.net/etracer_libera_migration.txt

Copy'n'paste of contents of your link:
--- Day changed lun. juin 07 2021
03:04 --> sevu<EMAIL_ADDRESS>has joined #etracer
03:06 <-- shiki<EMAIL_ADDRESS>has quit (Ping timeout: 248 seconds)
14:30 --- ChanServ has changed the topic to: moved to libera
14:31  ced117: o/
14:31 --- ChanServ has changed the topic to: etracer - moved to libera
--- Day changed mar. juin 08 2021

Netsplit links:
https://netsplit.de/channels/details.php?room=%23etracer&net=Libera.Chat
Doesn't exist on on freenode anymore.


Make it production and development ready

This thing need to be able to be used as a production and development server, thus keeping the build process in development equivalent to the build process in production (which should be close to none). Allow an option for minifying.

I've been thinking through this, and I think the best option is to transpile into a distribution directory that the user specifies in zwitterion.json. They can then use relatively paths in their script tags, and the development and production environments will be exactly the same. This will also allow for repositories to work seamlessly as dependencies, because each will have its own distribution directory that is referenced relatively.

It works!


update packages

:white_check_mark: Build TheIdServer 3.0.1-fix-dependencies1-0036 completed (commit https://github.com/Aguafrommars/TheIdServer/commit/e8aa128608 by @)


Support for deployment of  WorkflowActivity class which inherits from Custom Base class

Support for deployment of  WorkflowActivity class which inherits from Custom class which inherits from CodeActivity. (e.g support for deployment of workflows inheriting from WorkflowActivityBase class)
This code supports Workflow Activities which inherit from CodeActivity or any Custom Class such as WorkflowActivityBase which inherits from CodeActivity

@scottdurow sorry to chase... could I ask when this will be merged and released?

I’m on it this week!

@scottdurow - thanks a lot

Included in https://www.nuget.org/packages/spkl/1.0.206-beta


[feature] add support for [YYYY] as ISO8601 format

related to issue https://github.com/moment/moment/issues/3918

DOCUMENTATION needs to be updated (let me know if I can help with it):
Document that library supports YYYY-MM and YYYY as a recognized ISO8601 strings

@marwahaha , could you help me with the build please?  I see that node 5 and 7 failed, but there is no error message. Thank you!

update to latest develop branch and build is fine now (not sure what was the issue)

Great, thank you!
Could you make a PR against the docs too?
https://github.com/moment/momentjs.com/

Shouldn't this also support [+-]\d{6} format for consistency?

@ashsearle do you mean ±YYYYY (5 digits)? https://en.wikipedia.org/wiki/ISO_8601
Not sure if we need it. I found its description a bit confusing and not compulsory (prior agreement between the sender and the receiver).
To represent years before 0000 or after 9999, the standard also permits the expansion of the year representation but only by prior agreement between the sender and the receiver. An expanded year representation [±YYYYY] must have an agreed-upon number of extra year digits beyond the four-digit minimum, and it must be prefixed with a + or − sign[20] instead of the more common AD/BC (or CE/BCE) notation
Let me know if you are still keen to support [±YYYYY]. I yes, I can update my PR. Thanks.

@marwahaha thanks, I created a new PR against the docs https://github.com/moment/momentjs.com/pull/498
Shall we merge current source code PR first?

@medinarkhov I meant consistent with the the basicIsoRegex and extendedIsoRegex in the 2 lines above your new yearIsoRegex change: https://github.com/moment/moment/pull/4470/files#diff-e3f27469204308066d413adbf4fe72dfR13

@ashsearle thank you for clarification!
var yearIsoRegex = /^\s*([+-]\d{6}|\d{4})$/;
"2018" - match
but
"-201803" - match
"+201803" - match
"-201803" and "+201803" matching is not expected behavior for yearIsoRegex , though it doesn't brake the code in general.
Would you like me to use var yearIsoRegex = /^\s*([+-]\d{6}|\d{4})$/; anyway?

I think matching +123456 and -123456 is exactly what you want - it's consistent behaviour with the ECMAScript spec for extended years:
new Date(+201803, 0, 1).toISOString(); // "+201803-01-01T00:00:00.000Z"
new Date(-201803, 0, 1).toISOString(); // "-201803-01-01T00:00:00.000Z"

@ashsearle I've modified regex as per your review. Thank you!
Regarding CLA. I committed the change from different machine, so I'm not sure why CLA got confused.  I can't sign CLA twice now. Hopefully it's not a problem.

Fixed CLA warning by modifying author's email in the last commit.
All checks green now =)

@marwahaha @ashsearle Sorry for bothering you but I'm new here =)
As I understand: PR checks passed, documentation updated, peer review done...could you advise what's next? Is my PR ready to be merged? Is it awaiting someone's review or particular date? Thank you.

Thanks for the ping. I'll get to it when I have time :)

@medinarkhov - one last thing - could you add @ashsearle 's test cases to the tests? That way, we have the results of this discussion documented in our tests.

@marwahaha @ashsearle I reverted my change to support extended years [+/-YYYYYY]. I think it needs more discussion and work. Do you mind if we move it out of the scope for this PR?
The scope for this PR is to support [YYYY] as ISO8601 format.

@medinarkhov I'm a little torn about this.
#3918 says (with emphasis added):

We should either fully support minimal representations less than a full date, or not support them at all, and we should document this either way.

@medinarkhov I hate asking for more when you've been kind enough to contribute your time for free.  Is there something I can do to help you overcome whatever difficulty you had with implementing or adding tests for +/- 6-digit years?
Perhaps you just need a couple more lines in the isoDates array?
Maybe:
['YYYYYY-MM', /[+-]\d{6}-\d\d/],
['YYYYYY', /[+-]\d{6}/],

@ashsearle I'm a bit confused here. In the original issue #3918 Matt pointed out that YYYYMM is actually a shorthand for YYYY-MM, which is not 6 digit years, but year + month, without separator. So I have no idea why 6 digit years are being discussed in this fix, when there is no such thing mentioned in the issue.
I can't recall one instance in which a computer spitted out 5-6 digit year and that was correct ... like who is talking about the year 10 000 and beyond... Maybe negative 6 digit years make more sense, but AD... no way.
I'll merge this as is, and then add support for YYYYMM myself, to fix the issue in it's entirety.

@ichernev The aim is to parse a year on its own, according to ISO8601.
From ISO8601 on Wikipedia

To represent years before 0000 or after 9999, the standard also permits the expansion of the year representation but only by prior agreement between the sender and the receiver. An expanded year representation [±YYYYY] must have an agreed-upon number of extra year digits beyond the four-digit minimum, and it must be prefixed with a + or − sign.

JavaScript natively implements expanded years using a 6-digit representation, so I thought it'd make sense to build that in by default as a 'prior agreement'.

In the simplified ECMAScript format such an expanded year representation shall have 2 extra year digits and is always prefixed with a + or – sign.

The leading +/- prefix should avoid 6-digit years being confused with YYYYMM.
Also, you'll probably find its supported by your browser / node:
new Date('-000123').toISOString(); // '-000123-01-01T00:00:00.000Z'
new Date('+123456').toISOString(); // '+123456-01-01T00:00:00.000Z'


Include a py.typed marker file to show that pyglet is typed

Is your feature request related to a problem? Please describe.
It would be nice if pyglet could contain the py.typed marker file, so that when I import pyglet I dont get type errors and for example mypy can type check my usage of pyglet
Describe the solution you'd like
Include a py.typed marker file (just an empty file in pyglet folder)
Additional context
https://typing.readthedocs.io/en/latest/spec/distributing.html#packaging-typed-libraries

Hi,
typing for pyglet is mostly done, but is still a work in progress. I wasn't aware this was still necessary, but we can add it if it will help some use cases.

So now when I have some code that import pyglet I need to do
import pyglet #type: ignore

or else if I typecheck with mypy I get this error:
error: Skipping analyzing "pyglet": module is installed, but missing library stubs or py.typed marker  [import-untyped]

If Pyglet is ready for this Im not sure (I checked those things I used and they had types), but imho its still good to let the user have the option. It will still be possible to ignore the type if something is missing.

What is your IDE & code inspection setup?
The goal is to get pyglet typed at a useful level, that works for the majority of type checking tools. As you know typing in Python itself is still a work in progress, and sometimes different tools have different ideas on things. The pyproject.toml has a general list of things that are currently ignored, and also tool specific overrides. It should give a bit of a hint on what the current status is.

I use two typecheckers, pyright in VSCode (which is part of the pylance), and Mypy from command line. Pyright seems to not care about py.typed, while mypy requires it to do anything.
I think the top comment here describes the issue quite well: https://github.com/python/typing/discussions/1429
Basically unless something is super-broken or the types are somewhere else, its better to have the file than not.

Some additional comments:

If I run Mypy or Pyright on Pyglet itself there are many type errors.
For my (limited) usage, if I add a py.typed file manually to Pyglet my code typechecks fine.

Added for next point release (v2.0.18).
Please note that running mypy directly against the entire pyglet code base is not currently supported, but this should help projects that are importing pyglet.

@viblo you may have better luck with pyright (pylance if you're using VS Code):

The pyglet.math module uses NamedTuple for speed reasons
The mypy project does not support NamedTuple:

@pushfoo I am actually already using pyright, as I wrote earlier. Its just that I also use mypy. I maintain another library, Pymunk, and I think its good, if possible, to have types working for more than just one checker for libraries. Now, for the same reason I also fully understand that its lots of work to add types retroactively and that it might not even be possible to make perfect types for mypy, especially not without adjusting the API. I filed bug reports to both pyright and mypy when I added types to Pymunk. But in this isssue I only hoped for the py.typed marker file :)
For the pyglet.math thing I think you linked the wrong thread or maybe I misunderstand? The issue is not that mypy does not support NamedTuples, it does. There are some limitations to the support which is described in your linked issue, but I dont think they apply to Pyglet, when I look for NamedTuple it looks to be only simple cases?
However, pyglet.math does use tuple as baseclass. And for cases when you inherit tuples there's a limitation when you restrict the arguments allowed as pyglet does. See https://github.com/python/typeshed/issues/228 which is what mypy finds when running it against pyglet.math.

I think we have similar ideas about typing, in general.
I believe what pushfoo was saying is that, while pyglet is not exclusively supporting pyrite, mypy is still a bit too "noisy" to recommend. (Correct me if I'm wrong here).
The math module in particular is doing some non-standard things in the name of performance, so we can't "fix" it for mypy.
I'm personally in favor of a more "wait and see" approach to typing, because things are still changing in the Python world.
We have at least implemented type hints for all user facing APIs so far, so inspection should be hopefully more useful to end users. We're working towards improving things with every release.


Allow for very long log lines

Signed-off-by: Alex Ellis (OpenFaaS Ltd<EMAIL_ADDRESS>Description

Allow for very long log lines
Motivation and Context
With this environment-variable (log_buffer_size), very large
logs can be scanned and printed out to stdio.
This was reported by RateHub (an OpenFaaS Pro) user, but has
also been worked on several times in the past.
cc @LucasRoesler @everesio @ghostbody
Fixes #105 #100
Closes #99 #107
How Has This Been Tested?

Tested with a 5MB JSON file and a Node.js process that
printed the value to console.log/console.error.
It worked as expected. After reducing the value to the
default, an error was returned.
'use strict'
const fs = require("fs")

module.exports = async (event, context) => {

  let v=  fs.readFileSync("./function/5mb.json", "utf8")

  console.error(v)

  return context
    .status(200)
    .succeed(v)
}

http_upstream_url="http://<IP_ADDRESS>:3000" mode=http exec_timeout=30s log_buffer_size=31457280 write_timeout=30s fprocess="node index.js" read_timeout=30s write_debug=true ../../of-watchdog

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] I've read the CONTRIBUTION guide
[x] I have signed-off my commits with git commit -s
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

In an older PR #107 the code changed to s, err := reader.ReadString('\n'), but it's not explained why that change was made.
This PR appears to resolve the issue and retain compatibility with the existing behaviour.

Resolved your requests @LucasRoesler. If you can think of a simpler and easier to read test than that in #107 then perhaps we could add it at a later time.

cc @chrisrichard @voziv from RateHub


test(client): unskip 2 tests using the isolated postgresql / mysql uris

I think it could be worth porting this to the functional tests (+ all dbs are isolated by default there).

@millsp I think someone from Client Team could finish that then

I am OK merging this for now, because everyone is fully booked atm

👍🏼 I'll check later, maybe the easy option would be to disable them for the no-docker runs


Feature/160 option all

If #140 gets merged before this one, a small edit is required in the translation file

If #140 gets merged before this one, a small edit is required in the translation file

Same in reverse if this is before #140 .


About Question with depth

Reference to your readme,  while the command CUDA_VISIBLE_DEVICES=0  python train_mvs_nerf_pl.py     --with_depth  --imgScale_test 1.0 \     --expname mvs-nerf-is-all-your-need \     --num_epochs 6 --N_samples 128 --use_viewdirs --batch_size 1024 \     --dataset_name dtu \     --datadir path/to/dtu/data \     --N_vis 6 cannot work.
Error information :
log['val_psnr'] = mse2psnr(torch.mean(img_err_abs[:,mask] ** 2))
IndexError: The shape of the mask [1, 1] at index 0 does not match the shape of the indexed tensor [3, 512, 640] at index1

It may be caused by the resolution issue, please download the Depth_raw from the original MVSNet repo or just remove the "--with_depth" command

It may be caused by the resolution issue, please download the Depth_raw from the original MVSNet repo or just remove the "--with_depth" command

where is Depth_raw from the original MVSNet repo?


run sinsp-example with kmod error

Describe the bug
[root@localhost examples]# ./sinsp-example -k -j
-- Try to open: 'kmod' engine.
terminate called after throwing an instance of 'scap_open_exception'
  what():  error opening device /dev/scap0. Make sure you have root credentials and that the scap module is loaded: No such file or directory
Aborted (core dumped)

How to reproduce it

Expected behaviour

Screenshots

Environment

Falco version:

System info:

Cloud provider or hardware configuration:
OS:
Rocky Linux release 9.0 (Blue Onyx)

Kernel:
Linux localhost.localdomain 5.14.0-70.26.1.el9_0.x86_64 #1 SMP PREEMPT Tue Sep 20 17:53:31 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Installation method:
refer Build

Additional context

I try search like linux scap module, linux /dev/scap but there is no useful info.
can someone help me.

Hi! Thanks for taking the time to report this issue!
Did you build kmod? ie: make driver? Did you insmod the driver (ie: insmod driver/scap.ko)?

Also, we should really add the logic to auto-start the kmod in sinsp-example when it is not present, just like Falco does.

my fault, I found the scap.ko under driver directory，after insmod scap.ko i could run successfully.


Expand language.lua data to include Roblox v505 changes.

This change adds the following changes to language.lua:
debug.loadmodule
coroutine.close
TextChatMessageProperties.new
Will keep this as a draft until release notes come out.

I really appreciate you doing this <3

It is ready for merging now.


[MM-29393] Migrate changeCSS() to CSS variable in utils/utils.jsx, ln 519 (#15832)

Summary
Migrate changeCSS() to CSS variable in utils/utils.jsx, ln 519
Ticket Link
Fixes https://github.com/mattermost/mattermost-server/issues/15832
JIRA ticket: https://mattermost.atlassian.net/browse/MM-29393

Hello @KuSh,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.

QA review will be done on the final PR that merges all changes to this campaign branch into master.

Thanks! Can you double check that the theme switch works in the new sidebar as well? Right now its only updated for the legacy sidebar.

This is totally normal .sidebar--left class is only used by legacy sidebar so removed line in utils was only targeting legacy sidebar (and so is the migrated css rule)

PR will be QA'd in batch when campaign branch is merged to master


readthedocs link 404s

Describe the bug
The provided link to nbcelltests.readthedocs.io leads to a 404 page.
To Reproduce
Steps to reproduce the behavior:

Click on nbcelltests.readthedocs.io on the repository's About section

Expected behavior
A. Get some further documentation with the provided link.
B. The link not existing in the first place.

Related PRs:

https://github.com/jpmorganchase/nbcelltests/pull/23 (2019, June)
https://github.com/jpmorganchase/nbcelltests/pull/47 (2019, October)
https://github.com/jpmorganchase/nbcelltests/pull/253 (2022, April)

yep that's correct


Added mustudent.ac.tz domain

Added mustudent.ac.tz domain

@evancejaye Please provide us with a proof, which shows that the school recognizes the domain you are submitting as an official email domain for the students.
You can provide us with any of the following:

A copy of instruction (a hard-copy or electronic one) given to you by the school that tells you to use an email address in this email domain
An URL of a page at the official school website that says that students use this email domain
A reference to a recognized journal where an article was published by someone from the school, with explicit affiliation to the school, and e-mail address from the email domain
A WHOIS data that link the email domain to the school somehow
A copy of official letter from the school representative saying that the school provides e-mail addresses in this domain to the students
Anything else that can prove this fact in similar way, i.e. can be verified independently.

Links:
http://repository.costech.or.tz/handle/123456789/1897 (Mzumbe University
Legal Materials Repository - Hosted at Commision of Science and Technology
Tanzania)
https://whois.tznic.or.tz/whois/domain/mustudent.ac.tz/ (Whois Domain
Lookup)
https://econpapers.repec.org/article/sprjoiaen/v_3a9_3ay_3a2020_3ai_3a1_3ad_3a10.1186_5fs13731-020-00123-7.htm
(Paper published by EconPaper by Muzmbe University Students)
https://ijip.in/articles/analysis-of-subjective-well-being-by-influence-of-marketing-factors-and-pyrethrum-farmers-characteristics-in-makete-tanzania/
(Another paper)
Kind regards.
On Fri, Aug 13, 2021 at 1:31 PM Philip Torchinsky @.***>
wrote:

@evancejaye https://github.com/evancejaye Please provide us with a
proof, which shows that the school recognizes the domain you are submitting
as an official email domain for the students.
You can provide us with any of the following:

A copy of instruction (a hard-copy or electronic one) given to you
by the school that tells you to use an email address in this email domain
An URL of a page at the official school website that says that
students use this email domain
A reference to a recognized journal where an article was published
by someone from the school, with explicit affiliation to the school, and
e-mail address from the email domain
A WHOIS data that link the email domain to the school somehow
A copy of official letter from the school representative saying
that the school provides e-mail addresses in this domain to the students
Anything else that can prove this fact in similar way, i.e. can be
verified independently.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/JetBrains/swot/pull/12220#issuecomment-898361205, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AL3ZKOMHAQ43R5I7MPFB34LT4TYB3ANCNFSM5CANJK3A
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email
.

--
Evance Jay E
C.E.O - Jay E Media
📞: +255712730419
*📞: *+255756166367
🌎: evancejaye.com http://evancejaye.com

@evancejaye Pull request merged. Thank you!


BUG: Refactor: move to file: if imports are from file where was refactor done, remove them (imports for itself)

Refactor: move to file:
if imports are from file where was refactor done, remove them (imports for itself)

Please share steps to reproduce the issue along with example code

Thanks for creating this issue! We figured it's missing some basic information or in some other way doesn't follow our issue reporting guidelines. Please take the time to review these and update the issue.
Happy Coding!

STR:

there are 2 files: a.ts and b.ts:

// a.ts

import {BaseTest} from 'b.ts';

export type Test = BaseTest;

// b.ts

export type BaseTest = string;

With tool "Refactor: move to a file" move type Test from file a.ts to b.ts. During this process imports from a.ts are moved to b.ts too. So after refactoring file b.ts becomes:

// b.ts

import {BaseTest} from 'b.ts';           // here is problem, import was moved and now refers to itself, this need to delete in such cases

export type BaseTest = string;
export type Test = BaseTest;


Bug: Pasting text immediately after an inline element (e.g. link) causes the text and its following siblings to be moved into the inline element

Lexical version: 0.9.1
Steps To Reproduce

Go to Lexical Playground
Select some text, e.g. the word "playground"
Copy it to the clipboard
Position the cursor after the "Lexical website" link
Press Paste

The current behavior
The pasted word ("playground") and all the following text on that line end up being link-ified
https://user-images.githubusercontent.com/1232595/230831265-67ba23ab-c2fd-4767-ac23-93b56c5f762b.mp4
The expected behavior
The pasted word should not be link-ified and, at very least, the following text should not be link-ified either.
Note that this behavior reproduces with a non-collapsed selection too, provided the selection starts/ends at the end of an inline element (since for a non-collapsed selection we'll end up dropping the selection contents through a call to removeText()).
Analysis
A bit of debugging points to the code here:
https://github.com/facebook/lexical/blob/933ec6ada2b2f25db807cb125de75952ea0f7fd3/packages/lexical/src/LexicalSelection.ts#L1409-L1412
Specifically, if the selection is at the start of a text run (anchor offset is zero) then we choose the previous sibling as the target and append the pasted text and its siblings into the previous sibling.
I'm not sure what the reasoning is for this logic but it produces surprising results for this particular case.

I've put together some test cases for this (all failing ones are marked with a comment) here: https://github.com/shirakaba/lexical/tree/insertnodes-after-inline-element
I'll try to come up with a fix to serve as a strawman.

I've pushed a strawman fix to that branch now. Just need to sort out the CLA to open a PR.

Adding some extra context emerging from @zurfyx's discussion in #4346:

Additionally, prior to this [strawman] fix, it also seems like the text after is getting merged into the previous target element. It sems like the root cause is deeper than this.
Can we check why this is the case?

This seems to be due to this line here, where the siblings (the nodes to the right of the anchor node at the time of insertion) are handled:
https://github.com/facebook/lexical/blob/933ec6ada2b2f25db807cb125de75952ea0f7fd3/packages/lexical/src/LexicalSelection.ts#L1675
The intention (according to the code comment at the declaration of nextSiblings) is to "append them after the last node we're inserting", and in this case they're indeed being appended after the inserted node (which is unfortunately in the wrong place, inside the inline element).
I think in this case we want to insert the siblings after the target (the inline element), so maybe we want to get onto this conditional branch instead:
https://github.com/facebook/lexical/blob/933ec6ada2b2f25db807cb125de75952ea0f7fd3/packages/lexical/src/LexicalSelection.ts#L1696
Probably we could do that by augmenting the conditional check that we do here:
https://github.com/facebook/lexical/blob/933ec6ada2b2f25db807cb125de75952ea0f7fd3/packages/lexical/src/LexicalSelection.ts#L1666
... in the same way that we end up doing here (where this discussion began):
https://github.com/facebook/lexical/blob/933ec6ada2b2f25db807cb125de75952ea0f7fd3/packages/lexical/src/LexicalSelection.ts#L1409-L1412
In other words, if in the first place we change the check from just $isElementNode(target) to $isElementNode(target) && !target.isInline(), then we should make that same change in the second place, too.

Of note: I was curious why insertText works while insertNodes doesn't, and it occurred to me that it might be beneficial if the two were refactored to share the same code (after an initial conversion step), if possible. I was trying to compare the two, but unfortunately they share little similarity at present.

@zurfyx Do you want to re-open this? I think #4346 only added tests.

I am facing a similar issue with the code below. linkCopy, textNode and newLink all show the correct text selection but the link wraps the rest of the inline text no matter what.
const linkNode = $createLinkNode(sanitizeUrl(linkUrl));
const textNode = $createTextNode(linkCopy);
const newLink = linkNode.append(textNode);
$insertNodes([newLink]);

https://github.com/facebook/lexical/assets/18293479/d89bd162-333f-428e-b031-44e854e15f0b


Timeseries instant label instead of period

Describe the solution you'd like
Ability to label a specific timestamp instant instead of marking a period of time.
A clear and concise description of any alternative solutions or features you've considered.
Alternatively have used the available features and labelled a very short period starting at the timestamp of interest. In post processing, for the specific label, we discarded the labelling period information and used only the “start time” as the timestamp of interest
Add any other context or screenshots about the feature request here.
An example of our effort to mark timestamp instant.

I'm noticing an "instant" field in the output values, but can't figure out how to configure labeling a instant rather than a period.

Just select a label and double click on time series.

Wohoo!! Will give that a try :) Thanks!


[Carbon X] DatePicker color tokens applied with g90 and g100 themes have inaccessible color contrast

Detailed description
A number of colors/tokens being applied to the DatePicker are not accessible when the g100 or g90 themes from @carbon/themes are used.
Here are some example screenshots...
g100 theme
Simple date picker

Range with min and max

g90 theme
Range

The underline for the fields should be $ui-04 which is Gray 60 #6F6F6F in the Gray 100 theme
All the icons should be using the token $icon-01
The day ranges are just hard coded and will have to be over ridden. It seems excessive to make a token just for that. Could be convinced otherwise though. Could maybe be like a $highlight token or something, could maybe be used elsewhere

What the Duo file says the dark date picker should look like:

highlight is Blue 90 #021677

I'm waiting for https://github.com/IBM/carbon-components/pull/1795 to be merged (as I need the new $highlight token from @carbon/themes) before I can proceed with proposing a fix for this 👍

@jendowns just a heads up, will pull out the updates into a two parts, I think. Hoping to have it done this morning if folks have a chance to leave feedback 👍

Sounds good -- thank you!

@aagonzales Quick question -- That "selected" color (the start/end selected date in a range) and the text + "dot" color for the current date look like blue60 in these dark themes. The token used throughout looks like $interactive-01, which unfortunately is always blue60 for all themes -- https://carbon-elements.netlify.com/themes/examples/preview/
Am I correct in see that the blue for select/today should be blue40 (or even blue50) instead? Do you think $interactive-01 needs to be modified... or a new token needs to be created?

@jendowns we're one step a head of you this time. We just added in a new $interactive-04 that will those lighter blues in the dark themes but still keeping Blue 60 in the dark themes for the primary buttons with $interactive-01 https://github.com/IBM/carbon-elements/issues/366

I think this has been resolved with the addition of the $highlight color token.


fix(versions): update Activiti/activiti-cloud-full-chart-security versions into master

UpdateBot pushed helm dependency: activiti-cloud-full-example to: 7.1.72

UpdateBot commands:
updatebot push-version --kind helm activiti-cloud-full-example 7.1.72


Immersive experience link broken

Immersive experience link broken

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

ID: 6adff4a9-1f94-e638-b62f-0ad205a7af54
Version Independent ID: a04cd7b3-2d98-b08a-8a61-0ef20459130e
Content: Design Guidelines Reference - Teams
Content Source: msteams-platform/resources/design/overview.md
Product: msteams
GitHub Login: @o365devx
Microsoft Alias: o365devx

@matt-dp Thanks for reporting. This is fixed now.


Provide more server operations.

Provide more middleware server operations for reload/suspend/resume.
The backend provides all code to later also supply timeout parameters if needed. This is not part of this PR.
This was first done in #8210 but as this was not progressing due to no progress of the ui part of supplying the timeout. So I have separated the two aspects. This PR is for the part without timeout.
The PR has already been discussed in #8210 and the spec on https://travis-ci.org/pilhuhn/manageiq/builds/140617551 has passed. It builds on the work of #7304 and enhances+generifies it more.

I have opened https://github.com/ManageIQ/manageiq/issues/9462 for the addition of the timeout UI.
@miq-bot add_label providers/hawkular
@abonas

The hawkular-ruby-gem has been bumped to version 2.1, which fixes some issues with running operations. It does not touch metrics at all.

I don't get why the miq-bot rubocop is reporting things so much differently than local ones :-/

@pilhuhn how do you run it locally? perhaps it takes another configuration?

What's the difference between shutdown and stop operations?

@abonas Stop = System.exti() , Shutdown = wait until connections have drained or timeout hits and then exit. As timeout is currently 0 (we don't have the UI to pass a different value), both are basically the same. I can pass in a number < 0 to "wait forever" or >0 to "wait x seconds" as default.
There is also 'Restart', which means  server should shutdown and restart.
One can probably remove one of Stop/Shutdown. Or even Restart once we have the UI ready to pass the parameters timeout and should_restart

@abonas Stop = System.exti() , Shutdown = wait until connections have drained or timeout hits and then exit. As timeout is currently 0 (we don't have the UI to pass a different value), both are basically the same. I can pass in a number < 0 to "wait forever" or >0 to "wait x seconds" as default.
There is also 'Restart', which means server should shutdown and restart.
One can probably remove one of Stop/Shutdown. Or even Restart once we have the UI ready to pass the parameters timeout and should_restart

Thanks, now it's much more clear but I don't think that the user has a big chance of understanding the difference based on the names. Perhaps the Shutdown should be called "graceful shutdown" to ease differentiating them?

Test failure seems to come from recent rest-api-work and not from my work.

The hawkular-ruby-gem has been bumped to version 2.1, which fixes some issues with running operations. It does not touch metrics at all.

cc @simon3z

@abonas Ok with you?

@abonas Ok with you?

I didn't see that stop/shutdown naming issue was addressed. perhaps I missed it?
https://github.com/ManageIQ/manageiq/pull/9465#issuecomment-229035182

https://github.com/ManageIQ/manageiq/pull/9465/commits/7f4b0d5df404cfb79774d7dec433bac6ea52507c#diff-e6f07e5cdde7794bbc9e7cac60727879R46

7f4b0d5#diff-e6f07e5cdde7794bbc9e7cac60727879R46

this leads to non existing url :confused:

The hawkular-ruby-gem has been bumped to version 2.1, which fixes some issues with running operations. It does not touch metrics at all.

cc @simon3z

Thanks @abonas LGTM, @yaacov can you review?

The hawkular-ruby-gem has been bumped to version 2.1, which fixes some issues with running operations. It does not touch metrics at all.

LGTM

@miq-bot assign @chessbyte

@epwinchell can you provide a resume icon?  (see resume.png file in this PR)

@blomquisg I will in a separate PR

On 1 Jul 2016, at 15:44, Greg Blomquist wrote:

@epwinchell can you provide a resume icon?  (see resume.png file in
this PR)
My understanding is that he will do that asynchronously - hence the
placeholder,
so that by looking into the assets/images/* folders he can see that
there is work
to do.

@blomquisg I will in a separate PR

Thanks @epwinchell!


 Just open the ,,inspect,, and set the div class blure to 0px ;-;

Uhh... although I haven't tried the method you're suggesting, there are other uses for it. This being a direct API exploit you can integrate it in a bigger automated system which can allow you to swipe right on all the profiles which have already liked you. Also note that it says photos and not photo therefore you get more than the first picture in the preview.
Hope this make you see other uses, it's a small script anyway for showing the vulnerability found by a friend.
Thanks for the feedback though!


recognition with wake worse than "hold to record"

I dont know if this is a bug or just some kind of usage error but i have tried both pocketsphyx and prorcupine as wake word providers. Both work and have good recognition rates but the recognition after the wake word is very bad compared to the recognition when clicking "hold to record".
When using hold to record i feel like the recognition rate is somewhere around 98%, with the wake word and a lot of trial and error for the right pronunciation and timing between waking and speaking its somwhere around 20-30%. I have been trying play music and stop music as commands.
I am using v2.4.19 with the docker install and a ReSpeaker 2-Mic board as a microphone (but i dont thing thats the cause since the manual record works great).
The settings are all default (except of course that the wake word detection was turned on). I have trained multiple times, restarted, and cleared the training chache and retrained.
Any ideas why this difference could occur ?
here the settings from the advanced tab (should be only the non default ones if i understand correctly)
{
    "language": "en",
    "name": "en",
    "locale": "en_US",
    "speech_to_text": {
        "system": "pocketsphinx",
        "dictionary_casing": "lower",
        "kaldi": {
            "base_dictionary": "kaldi/base_dictionary.txt",
            "base_language_model": "kaldi/base_language_model.txt",
            "base_language_model_fst": "kaldi/base_language_model.fst",
            "compatible": true,
            "custom_words": "kaldi_custom_words.txt",
            "dictionary": "kaldi/dictionary.txt",
            "graph": "graph",
            "language_model": "kaldi/language_model.txt",
            "model_dir": "kaldi/model",
            "unknown_words": "kaldi/unknown_words.txt",
            "mix_fst": "kaldi/mixed.fst",
            "g2p_model": "kaldi/g2p.fst",
            "phoneme_examples": "kaldi/phoneme_examples.txt",
            "phoneme_map": "kaldi/espeak_phonemes.txt"
        }
    },
    "intent": {
        "flair": {
            "embeddings": [
                "news-forward-0.4.1.pt",
                "news-backward-0.4.1.pt"
            ]
        }
    },
    "text_to_speech": {
        "wavenet": {
            "language_code": "en-US"
        },
        "marytts": {
            "locale": "en-US"
        }
    },
    "download": {
        "conditions": {
            "speech_to_text.system": {
                "pocketsphinx": {
                    "acoustic_model": "cmusphinx-en-us-5.2.tar.gz:cmusphinx-en-us-5.2",
                    "base_dictionary.txt": "en-g2p.tar.gz:base_dictionary.txt",
                    "g2p.fst": "en-g2p.tar.gz:g2p.fst"
                },
                "kaldi": {
                    "kaldi": "en_kaldi-zamia.tar.gz:kaldi"
                }
            },
            "speech_to_text.kaldi.open_transcription": {
                "True": {
                    "kaldi/model/base_graph": "en_kaldi-zamia-base_graph.tar.gz:base_graph"
                }
            },
            "speech_to_text.pocketsphinx.mix_weight": {
                ">0": {
                    "base_language_model.txt": "en-70k-0.2-pruned.lm.gz:en-70k-0.2-pruned.lm"
                }
            },
            "intent.system": {
                "flair": {
                    "flair/cache/embeddings/news-forward-0.4.1.pt": "news-forward-0.4.1.pt",
                    "flair/cache/embeddings/news-backward-0.4.1.pt": "news-backward-0.4.1.pt"
                }
            }
        },
        "files": {
            "cmusphinx-en-us-5.2.tar.gz": {
                "url": "https://github.com/synesthesiam/rhasspy-profiles/releases/download/v1.0-en/cmusphinx-en-us-5.2.tar.gz"
            },
            "en-70k-0.2-pruned.lm.gz": {
                "url": "https://github.com/synesthesiam/rhasspy-profiles/releases/download/v1.0-en/en-70k-0.2-pruned.lm.gz"
            },
            "en-g2p.tar.gz": {
                "url": "https://github.com/synesthesiam/rhasspy-profiles/releases/download/v1.0-en/en-g2p.tar.gz"
            },
            "news-forward-0.4.1.pt": {
                "url": "https://github.com/synesthesiam/rhasspy-profiles/releases/download/v1.0-en/news-forward-0.4.1.pt",
                "cache": false
            },
            "news-backward-0.4.1.pt": {
                "url": "https://github.com/synesthesiam/rhasspy-profiles/releases/download/v1.0-en/news-backward-0.4.1.pt",
                "cache": false
            },
            "en_kaldi-zamia.tar.gz": {
                "url": "https://github.com/synesthesiam/rhasspy-profiles/releases/download/v1.0-en/en_kaldi-zamia.tar.gz"
            },
            "en_kaldi-zamia-base_graph.tar.gz": {
                "url": "https://github.com/synesthesiam/rhasspy-profiles/releases/download/v1.0-en/en_kaldi-zamia-base_graph.tar.gz"
            }
        }
    }
}

There should be almost no difference unless the feedback sounds are bleeding over into the recorded voice command. If you record a command and click the play back button in the web UI, do you hear the beeps?

so until now i did not have an output device configured. I attatched a headset for testing.
When recording, stopping recording or playing the voice command no sounds play. When saying the wake word it does make two sounds, one when starting recording and one when ending (at least that what i think since the icon on the top left changes as well between the beeps).
Still the detection is basically useless when using the wake word and almost perfect when triggering the recording manually.

Started playing today and had the same problem. When listening to the last command in the web UI after the wake word (thanks for the hint @synesthesiam), I realized that the first split second of the command was cut off and the first word could not be recognized. Seems like webrtcvad needed some tuning ... adding this to the profile fixed it for me:
    "command": {
        "webrtcvad": {
            "speech_buffers": 0,
            "throwaway_buffers": 3
        }

(Although something was weird about the speech_buffers setting: somewhere around 2-3 the behaviour jumped from "cutting the first command word" to "keep all the silence between wake word and first command word")

Ok that is definitely a huge improvement to how it was before! It feels like everything is a little slower now but that might be something else.

I can confirm that https://github.com/synesthesiam/rhasspy/issues/199#issuecomment-614336096 is an improvement:
Before when I would say: What time is it? it would only recognize time is it. Now it the whole sentence.

Should I make a PR to change the defaults?

I don't see this problem anymore with rhasspy 2.5 from here: https://github.com/rhasspy/rhasspy


Merge sx1302 and RockPi fixes

Why

Fix sx1302 and RockPi
How

Bump diag and packet forwarder
References

#264
#271
Closes: NebraLtd/hm-diag#237
Relates-to: NebraLtd/hm-pyhelper#68
Relates-to: NebraLtd/hm-pktfwd#74
Relates-to: NebraLtd/hm-pktfwd#72
Closes: NebraLtd/hm-pktfwd#70

@NebraLtd/tech-support can you test these changes to see if we can push to production?

@shawaj Yes, I can do that


Update prettier cops

Lots of linting changes in this as I updated ruby-prettier
The biggest impact is that prettier now enables the rubocop line layout cops. (Which helps it avoid getting into a few battles, which triggered by attempt to update)
In turn thought this pretty much force my hand in putting the line length todos inline.

So I fixed up your suggestions, and also searched for similar patterns I could fix up. So this includes:

Consolidation of any enable->disable pairings
Consolidate cops onto a single line where appropriate.

There were also a few cases where you suggested moving a todo line, where I did the todo instead. Biggest one of these is in:
https://github.com/sanger/sequencescape/pull/3309/commits/1ba77ed1739856fab2b106468ea5b01b8aec6b30
I go into the changes a bit in the commit message there, as it looks like a more significant change than it actually is.

Just wanted to check whether you spotted this comment and whether what I said is valid or not? https://github.com/sanger/sequencescape/pull/3309#discussion_r700362780

Just wanted to check whether you spotted this comment and whether what I said is valid or not? #3309 (comment)

😱  No, I missed that one. Looks like a horrible bug in the rubocop safe auto-corrects. Well spotted.
(Looks like I missed a load of comments that GH hid beneath the fold)


Chore to remove legacy file structure to align with protected routes

Once #265 is merged, outstanding FE PRs using the legacy file structure remain will need to be integrated into protected routes as required and legacy folders deleted.

@shon-button I removed a couple of redundant files when I was resolving rebase conflicts as part of my PR; Given this, do you think this ticket is still required?


How to start the NGINX Proxy automatically after reboot

Operating System: CentOS 7
After a reboot the server, the NGINX Proxy Manager don't start automatically. Maybe with systemctl start nginx?????

Hi,
Do you launch the application in docker?
Add a directive restart: always or restart: on-failure to your docker-compose.yml
https://docs.docker.com/config/containers/start-containers-automatically/

Hi,
Do you launch the application in docker?
Add a directive restart: always or restart: on-failure to your docker-compose.yml
https://docs.docker.com/config/containers/start-containers-automatically/

restart: always works fine.

restart: always works fine.


[Forecasting] Graph expects dataset pre-sorted

Data tab has new option "Graph" for forecasting task. My dataset has items in somewhat random order so the graph does not look useful.
Does the forecasting require user to pre-sort the dataset or does it do sorting itself for the training?
Time series column in Unix timestamp. . I could not find information from https://docs.microsoft.com/en-us/dotnet/machine-learning/tutorials/time-series-demand-forecasting  if Unix timestamps are supported. If Unix timestamps are used, then what does "horizon" mean in the training and evaluation tabs? If I predict 10 steps to future, does it mean 10 seconds (per unix timestamp) or 10 steps of what is the average interval in the training data (such as 5 minutes per step)?

@LittleLittleCloud Can you comment on the above questions?

The graph in data page will show dataset as is, while during training, if you choose TimeStamp as time column, it will sort out your dataset (from earlier to later) based on your time column.
The horizon is the number of values to look overhead, this value will be used to set the horizon in ForecastBySsa. So it doesn't related with time column even if you set it up.


Cannot install on fresh MacOS 11.1

Bug report
Please note we will close your issue without comment if you delete, do not read or do not fill out the issue checklist below and provide ALL the requested information. If you repeatedly fail to use the issue template, we will block you from ever submitting issues to Homebrew again.

[ x ] ran brew update and can still reproduce the problem? - N/A
[ x ] ran brew doctor, fixed all issues and can still reproduce the problem? - N/A
[ x ] ran brew config and brew doctor and included their output with your issue? - N/A

What happened (include command output)
Tried to install onto a fresh 11.1 Intel
matt@matts-MBP Homebrew % uname -a
Darwin matts-MBP.inside 20.2.0 Darwin Kernel Version 20.2.0: Wed Dec  2 20:39:59 PST 2020; root:xnu-7195.60.75~1/RELEASE_X86_64 x86_64

Process fails part way through.
It can't run brew to continue.
/usr/local/bin/brew symlink is present, but it's broken; pointing to a non-existant bin directory in /usr/local/Homebrew
It's like the git checkout wasn't complete?
Git checkout looks correctly setup?

Command output

matt@matts-MBP ~ % /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
Password:
==> This script will install:
/usr/local/bin/brew
/usr/local/share/doc/homebrew
/usr/local/share/man/man1/brew.1
/usr/local/share/zsh/site-functions/_brew
/usr/local/etc/bash_completion.d/brew
/usr/local/Homebrew
Press RETURN to continue or any other key to abort
==> /usr/bin/sudo /usr/sbin/chown matt:admin /usr/local/Homebrew
==> Downloading and installing Homebrew...
HEAD is now at 95c6e92d9b4 Merge pull request #10278 from zkokaja/add-cask-json-values
/bin/bash: line 138: /usr/local/bin/brew: No such file or directory
Failed during: /usr/local/bin/brew update --force --quiet
matt@matts-MBP ~ % ls -l /usr/local/bin/brew
lrwxr-xr-x  1 matt  admin  28 25 Jan 12:18 /usr/local/bin/brew -> /usr/local/Homebrew/bin/brew
matt@matts-MBP ~ % ls -l /usr/local/Homebrew
total 0
drwxr-xr-x  3 matt  admin  96 25 Jan 11:54 Library
matt@matts-MBP Homebrew % git remote -v
origin	https://github.com/Homebrew/brew (fetch)
origin	https://github.com/Homebrew/brew (push)
matt@matts-MBP Homebrew % git pull
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.
git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:
git branch --set-upstream-to=origin/<branch> master

What you expected to happen
Installation should work
Step-by-step reproduction instructions (by running brew commands)
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
Output of brew config and brew doctor commands
N/A

This doesn't look like a bug with brew. There are many related discussions on Homebrew's discussions page.
For example:
https://github.com/Homebrew/discussions/discussions/590
https://github.com/Homebrew/discussions/discussions/140
https://github.com/Homebrew/discussions/discussions/600
https://github.com/Homebrew/discussions/discussions/595
Please check there first, and see if any of those discussions will help you. If they do not, perhaps you can post in one of them for help.

This doesn't look like a bug with brew. There are many related discussions on Homebrew's discussions page.
For example:
https://github.com/Homebrew/discussions/discussions/590
https://github.com/Homebrew/discussions/discussions/140
https://github.com/Homebrew/discussions/discussions/600
https://github.com/Homebrew/discussions/discussions/595
Please check there first, and see if any of those discussions will help you. If they do not, perhaps you can post in one of them for help.

Ok good to know; I don't what GitHub's SEO game is but google didn't find any of those.
None of them is my problem, but I'll post there.

Ok good to know; I don't what GitHub's SEO game is but google didn't find any of those.
None of them is my problem, but I'll post there.


Add Jenkins converters

Description
https://github.com/faros-ai/airbyte-connectors/issues/94
Type of change

[ ] Bug fix
[x] New feature
[ ] Breaking change

Please add tests.

@Roma-Kyrnis can you please address the comments so we can merge this?


Documentation typo

Hello,
I noticed on http://alex-d.github.io/Trumbowyg/documentation.html#svg-icons that the following line has a typo:
$.trumbowyg.svgPath = false:

It should be:
$.trumbowyg.svgPath = false;

(semicolon to end line)
I don't see a repo for the docs so I assume you'll have to make this fix yourself.
Thanks for a great plugin!

Doc is on a branch: https://github.com/Alex-D/Trumbowyg/tree/gh-pages
Thanks for report :)


Add support for i2c on embedded-hal v1

Implement embedded-hal v1.0.0-rc.1 I2C traits.
Tested on ESP32.

Thanks for the PR!  I fixed the nightly failures, can you rebase onto main or allow me write access to this PR to do it?

done. One check still fails. Is eh1 support missing in the mock?

Is eh1 support missing in the mock?

It was just returning a different error type for EH1 since they added the ErrorKind enum.


[Help]: Where to set environment variables without using docker?

Is there an existing issue for this?

[X] I have searched the existing issues

Version
v0.6.4
In which part of the application does the error occur?
Unknown/both
Current Behavior
If I don't use docker and run modmail directly by downloading tar, where should I configure environment variables such as MODMAIL_VIEWER_MONGODB_URI
Expected Behavior
No response
Steps To Reproduce
No response
Environment
- OS: Ubuntu 20.04
- Java: 17.0.7

Relevant log output
Exception in thread "main" java.lang.ExceptionInInitializerError
        at com.github.khakers.modmailviewer.Main.main(Main.java:72)
Caused by: java.lang.IllegalArgumentException: No mongodb URI provided. provide one with the option "MODMAIL_VIEWER_MONGODB_URI"
        at org.apache.logging.log4j.core.util.Assert.requireNonEmpty(Assert.java:96)
        at com.github.khakers.modmailviewer.Config.<clinit>(Config.java:26)
        ... 1 more

This is a bit of a broad Linux question since it heavily depends on how you're running the application.
If you're using systemd, for instance, you could set them in your unit file

这是来自QQVIP邮箱的自动回复邮件。


Is there a method to migrate data with manage.py?

I searched unsuccessfully for a method to migrate the events... data from PostgreSQL to ClickHouse (on Self Hosted instance).
I think SKIP_ASYNC_MIGRATIONS_SETUP=0 python manage.py migrate_clickhouse only creates the data model but does not migrate the data.
Question: is there any other method than posthog-plugin-migrator3000 to migrate the data?
I think a direct migration from PostgreSQL to ClickHouse must be faster than going through the Rest API (although I know it is not suitable for migrating data to or from a cloud instance).
If there is no other migration method, how about adding this information in the README? And add the rational?

Hey there! The way we migrate data is tightly coupled to how the plugins work. We don't offer another way of migrating and are not planning on offering one. Will have a look at your other issues today.


Localize date/time

Use local date/time format.
I.e, for french date should be  09/11/2021 09:17 instead of 2021-11-09 09:17

Implemented in version 3.2.17.


Revert "Enable minion liveness probe"

Reverts apache/pinot#8593
Minion /health port is 6500, and not 9514

@Jackie-Jiang The minion admin port isn't 9514 hence https://github.com/apache/pinot/pull/8593 must be reverted.
The right way to enable minion health check would be https://github.com/apache/pinot/pull/8651/files.


The pinpoint module is shut down.

When running pinpoint 2.4.0 version web,collector with java -jar, the process is automatically killed.
(When Pinpoint 2.3.3 module is executed, it does not end and runs normally)
Can you confirm this?
And, to use pinpoint 2.4.0 version, I downloaded it from the hbase site and upgraded it to 2.4.12.
Is there any hbase module provided by Pinpoint other than that method?

https://github.com/pinpoint-apm/pinpoint#compatibility
Try the hbase 2.0 module

check please
When running pinpoint 2.4.0 version web,collector with java -jar, the process is automatically killed.
(When Pinpoint 2.3.3 module is executed, it does not end and runs normally)

It seems that there is no data inflow in the area marked in red on the capture screen, but data inflow is seen in the area marked in green.
Please guide us on what to do in order to check the data in the part marked in red.

@emeroad meroad
Please respond to the inquiries.


Update README.rst

Little typo fix. it's => its

hello, same as this PR #220
Please also change *.po files for every language

Fixed it also in *.po files.


re-enabled TestDdaSearchMsFraggerBadFasta

re-enabled TestDdaSearchMsFraggerBadFasta as I think I fixed the reliability problems
discovered that GetSystemResourceString leaks heap memory even when all resources are disposed correctly; I wasn't able to fix that so I just set the test to have its leak ignored for now; maybe a better solution would be to run GetSystemString in a separate process

Discussing this with Brendan gave me one more idea to try: caching the result of GetString. When even that didn't stop the leak, I just commented out the usage of GetSystemResourceString() in the test (so the test is short circuited without checking the error message). It still leaked, so (/facepalm) it was never GetSystemResourceString() that was the problem. Something about short circuiting this test is causing a memory leak but my dotMemory-fu is not up to the task to quickly track it down and I've spent enough time on this. Knowing it's not GetSystemResourceString() is actually comforting because it means other tests can use it without them starting to leak as well.
I can come back to it later, but @brendanx67 do you want me to leave the test disabled, or go ahead with this workaround to mute the memory leak for this test?

Should I expect to see this test leaking in some way now? Or is it completely fixed? If so, did you remove the code to silence its leak testing? I am not seeing the leak with the current branch.

I can get it to leak reliably when run in an infinite loop in pass1:
TestRunner test=TestDdaSearchMsFraggerBadFasta pass1=on pass2=off loop=0 language=en
But it eventually stabilizes after a couple dozen runs and stops leaking. This is with the GetSystemResourceString() call commented out so that can't be the cause. The leak seems to go away entirely if I use language=all - it looks like you were testing that way? Can you try with just language=en?

Ignore the bit about languages. I see it's always running all languages during pass1. So I'm only getting leaks detected intermittently in the first couple dozen runs, and it always eventually stabilizes to "no leaks".
Here's one run:
Run with some leaks

# Pass 1: Run tests multiple times to detect memory leaks.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 3.51/17.41/71.5 MB, 68/497 handles, 3 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.33/17.48/72.0 MB, 69/498 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.34/17.53/72.6 MB, 69/498 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.43/17.60/72.3 MB, 72/500 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/17.66/72.5 MB, 75/508 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/17.68/72.6 MB, 75/508 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/17.71/72.6 MB, 75/508 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/17.74/72.7 MB, 75/508 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/17.78/72.7 MB, 75/503 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/17.81/72.8 MB, 75/503 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/17.83/72.8 MB, 75/498 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/17.85/72.8 MB, 75/498 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/17.80/72.8 MB, 75/500 handles, 2 sec.
# TestDdaSearchMsFraggerBadFasta deltas (13): managed = 0.3 KB, heap = 17.5 KB, memory = 23.4 KB, user-gdi = 0, total = -1.4
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/17.84/72.9 MB, 75/500 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/17.87/72.9 MB, 75/500 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/17.91/73.0 MB, 75/500 handles, 1 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/17.96/73.0 MB, 75/500 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/17.99/73.0 MB, 75/500 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/18.03/73.0 MB, 75/500 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/18.06/73.1 MB, 75/500 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/18.10/73.1 MB, 75/500 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/18.13/73.2 MB, 75/500 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/18.15/73.2 MB, 75/500 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/18.19/73.2 MB, 75/500 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/18.22/73.3 MB, 75/500 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/18.26/73.3 MB, 75/500 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/18.25/73.3 MB, 75/499 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/18.28/73.3 MB, 75/499 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/18.32/73.4 MB, 75/499 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/18.34/73.3 MB, 75/497 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/18.38/73.4 MB, 75/497 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/18.43/73.4 MB, 75/497 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/18.46/73.4 MB, 75/497 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/18.50/73.5 MB, 75/497 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/18.53/73.5 MB, 75/497 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/18.57/73.5 MB, 75/497 handles, 2 sec.
[15:58]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/18.60/73.5 MB, 75/497 handles, 2 sec.
!!!  TestDdaSearchMsFraggerBadFasta LEAKED 23945.1 Heap bytes
# TestDdaSearchMsFraggerBadFasta deltas (25): managed = -0.1 KB, heap = 23.4 KB, memory = 21.1 KB, user-gdi = 0, total = -0.3
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/19.37/74.6 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/19.40/74.5 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/19.43/74.6 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/19.47/74.6 MB, 75/497 handles, 2 sec.
[15:59]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/19.50/74.7 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/19.47/74.7 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/19.53/74.7 MB, 75/497 handles, 1 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/19.56/74.7 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/19.60/74.8 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/19.66/74.9 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/19.69/74.9 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/19.72/74.9 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/19.77/75.0 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/19.80/75.1 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/19.84/75.1 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/19.87/75.1 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/19.90/75.2 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/19.92/75.3 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/19.95/75.3 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/19.91/75.3 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/19.95/75.3 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/20.01/75.3 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/20.05/75.4 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/20.05/75.4 MB, 75/497 handles, 2 sec.
!!! TestDdaSearchMsFraggerBadFasta LEAKED 20987.4 Heap bytes
# TestDdaSearchMsFraggerBadFasta deltas (25): managed = -0.1 KB, heap = 20.5 KB, memory = 20 KB, user-gdi = 0, total = 0
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/20.05/75.4 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/20.05/75.3 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/20.04/75.4 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/20.04/75.4 MB, 75/497 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/20.02/75.3 MB, 75/495 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/20.06/75.3 MB, 75/495 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/20.06/75.4 MB, 75/495 handles, 2 sec.
[16:00]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/20.07/75.5 MB, 75/495 handles, 2 sec.
# TestDdaSearchMsFraggerBadFasta deltas (8): managed = 0 KB, heap = 3 KB, memory = 8.6 KB, user-gdi = 0, total = -0.3
[16:01]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/20.04/75.5 MB, 75/495 handles, 2 sec.
[16:01]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/20.03/75.5 MB, 75/495 handles, 2 sec.
[16:01]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/20.04/75.5 MB, 75/495 handles, 2 sec.
[16:01]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.51/20.05/75.6 MB, 75/495 handles, 2 sec.
[16:01]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.51/20.05/75.6 MB, 75/495 handles, 2 sec.
[16:01]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.51/20.09/75.5 MB, 75/495 handles, 2 sec.
[16:01]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.51/20.09/75.5 MB, 75/495 handles, 2 sec.
[16:01]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.51/20.09/75.5 MB, 75/495 handles, 2 sec.
# TestDdaSearchMsFraggerBadFasta deltas (8): managed = 0 KB, heap = 7.4 KB, memory = 4.6 KB, user-gdi = 0, total = 0

Run without leaks

# Pass 1: Run tests multiple times to detect memory leaks.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 3.51/17.41/71.2 MB, 69/497 handles, 3 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.31/17.52/71.8 MB, 70/498 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.33/17.57/71.7 MB, 70/498 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.40/17.63/72.0 MB, 73/500 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.48/17.70/72.2 MB, 76/508 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/17.74/72.3 MB, 76/508 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/17.78/72.3 MB, 76/508 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/17.81/72.3 MB, 76/508 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.49/17.83/72.4 MB, 76/503 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.49/17.86/72.4 MB, 76/503 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/17.86/72.4 MB, 76/498 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/17.89/72.5 MB, 76/498 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/17.84/72.5 MB, 76/500 handles, 2 sec.
# TestDdaSearchMsFraggerBadFasta deltas (13): managed = 0.3 KB, heap = 15.4 KB, memory = 32 KB, user-gdi = 0, total = -1.4
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/17.88/72.6 MB, 76/500 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/17.93/72.6 MB, 76/500 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/17.98/72.6 MB, 76/500 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.49/18.01/72.6 MB, 76/500 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.49/18.04/72.7 MB, 76/500 handles, 2 sec.
[15:54]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.08/72.8 MB, 76/500 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.09/72.8 MB, 75/500 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.10/72.8 MB, 75/500 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.49/18.10/72.8 MB, 75/500 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.49/18.09/72.8 MB, 75/500 handles, 2 sec.
# TestDdaSearchMsFraggerBadFasta deltas (10): managed = 0 KB, heap = 17.1 KB, memory = 27.4 KB, user-gdi = -0.1, total = 0
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.09/72.8 MB, 75/500 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.04/72.7 MB, 75/499 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.06/72.7 MB, 75/499 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.49/18.07/72.7 MB, 75/499 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.49/18.07/72.7 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.08/72.6 MB, 75/497 handles, 2 sec.
# TestDdaSearchMsFraggerBadFasta deltas (8): managed = 0 KB, heap = -1.8 KB, memory = -25.1 KB, user-gdi = 0, total = -0.4
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.08/72.6 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.49/18.08/72.6 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.49/18.08/72.6 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.10/72.6 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.05/72.7 MB, 75/497 handles, 2 sec.
# TestDdaSearchMsFraggerBadFasta deltas (8): managed = 0 KB, heap = -4.5 KB, memory = 4.6 KB, user-gdi = 0, total = 0
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.09/72.7 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.49/18.10/72.7 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.49/18.10/72.7 MB, 75/497 handles, 2 sec.
[15:55]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.10/72.7 MB, 75/497 handles, 1 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.10/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.10/72.7 MB, 75/497 handles, 1 sec.
# TestDdaSearchMsFraggerBadFasta deltas (8): managed = 0 KB, heap = 3.7 KB, memory = 1.1 KB, user-gdi = 0, total = 0
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.11/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.10/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.10/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.49/18.10/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.49/18.11/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.06/72.7 MB, 75/499 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.06/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.07/72.7 MB, 75/497 handles, 1 sec.
# TestDdaSearchMsFraggerBadFasta deltas (8): managed = 0 KB, heap = -6.3 KB, memory = -5.1 KB, user-gdi = 0, total = 0
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 1 sec.
# TestDdaSearchMsFraggerBadFasta deltas (8): managed = 0 KB, heap = 1.2 KB, memory = -1.1 KB, user-gdi = 0, total = 0
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.08/72.7 MB, 75/497 handles, 1 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.09/72.7 MB, 75/497 handles, 1 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.10/72.8 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.49/18.05/72.8 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.49/18.06/72.7 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.07/72.8 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.08/72.8 MB, 75/497 handles, 2 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.08/72.8 MB, 75/497 handles, 1 sec.
# TestDdaSearchMsFraggerBadFasta deltas (8): managed = 0 KB, heap = 0 KB, memory = 4.6 KB, user-gdi = 0, total = 0
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.09/72.8 MB, 75/497 handles, 1 sec.
[15:56]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.10/72.8 MB, 75/497 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.10/72.8 MB, 75/497 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (ja)   0 failures, 4.49/18.10/72.8 MB, 75/497 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (zh)   0 failures, 4.49/18.09/72.8 MB, 75/497 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (en)   0 failures, 4.49/18.09/72.8 MB, 75/497 handles, 2 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (fr)   0 failures, 4.49/18.09/72.8 MB, 75/497 handles, 1 sec.
[15:57]   1.0   TestDdaSearchMsFraggerBadFasta                 (tr)   0 failures, 4.49/18.09/72.8 MB, 75/497 handles, 1 sec.

Annoying!


Command "docker_installer" is not defined.

root@Client9:/var/azuracast# ./docker.sh install
Checking installation requirements for AzuraCast...
[PASS] Operating System: Linux
[PASS] Architecture: x86_64
[PASS] Command Present: curl
[PASS] Command Present: awk
[PASS] User Permissions
[PASS] Installation Directory
[PASS] All requirements met!
Docker is already installed! Continuing...
Docker Compose is already installed. Continuing...
Prefer stable release versions of AzuraCast? [y/N] y
Pulling installer ... done
Creating azuracast_installer_installer_run ... done

  Command "docker_installer" is not defined.

ERROR: 1
Pulling mariadb  ... done
Pulling redis    ... done
Pulling stations ... done
Pulling web      ... done
Creating network "azuracast_backend" with driver "bridge"
Creating network "azuracast_frontend" with driver "bridge"
Creating volume "azuracast_db_data" with default driver
Creating volume "azuracast_letsencrypt" with default driver
Creating volume "azuracast_letsencrypt_acme" with default driver
Creating volume "azuracast_shoutcast2_install" with default driver
Creating volume "azuracast_geolite_install" with default driver
Creating volume "azuracast_sftpgo_data" with default driver
Creating volume "azuracast_station_data" with default driver
Creating volume "azuracast_www_vendor" with default driver
Creating volume "azuracast_www_uploads" with default driver
Creating volume "azuracast_tmp_data" with default driver
Creating volume "azuracast_redis_data" with default driver
Creating volume "azuracast_backups" with default driver
Creating azuracast_stations ... done
Creating azuracast_mariadb  ... done
Creating azuracast_redis    ... done
Creating azuracast_web_run  ...
ERROR: Aborting.
^Cazuracast_redis is up-to-date
azuracast_mariadb is up-to-date
azuracast_stations is up-to-date
Creating azuracast_web ... done

I am trying to install AzuraCast via on Ubuntu 20.04 but I keep getting this error. I have tried to reinstall docker but it doesn't work. I even used a slightly older version but that didn't work.

I'm assuming you're following their instructions from https://docs.azuracast.com/en/getting-started/installation/docker
I'd suggest to report this issue with them if those instructions do not work; this looks to be unrelated to Docker's documentation, but could be a bug in their installation script.
Let me close this ticket, but feel free to continue the conversation


Functionally complete back panel design for v0.4

Description
Rehash/continuation of old PR #1297.
This constitutes a tentative design of the back panel assembly for v0.4, sufficiently complete for initial prototype integration. The act of integration and other testing may yet determine this design to be in some way deficient, so we avoid the pretense that this design is "final". To limit the scope of this update, we are also omitting any drawing, BOM or documentation updates at this point.
The implementation addresses the following:

closes #1040
updates #961
closes #1280
closes #1281
updates #646
closes #1061

Updates #1248 (umbrella ticket for the above)
Some details on what and why:

Needed models have been imported or created or cobbled-together for:

battery drawer
RJ45 pigtail port
RJ45 pigtail elbow connector
USB pigtail port
USB elbow

New or completely redesigned parts satisfying core requirements outlined in tickets:

Back panel acrylic plate
Power input sub-panel in 1/8" acrylic
Data port sub-panel in 1/8" acrylic

Knock-on modifications:

Added elbow connectors to electronics sub-assembly, to asses clashes with other nearby components
Main equipment acrylic has pass-through holes for main power and data harnesses going to the back-panel
Back-panel acrylic unlinked as no longer adaptive to the internals assembly, requiring geometry relinking for various enclosure components. Fundamentally geometry has not changed, but files had to be updated.
Various third-party components (such as fasteners) have been replaced, some obsolete hardware has been deleted.

Design has been iteratively tested and and confirmed to fit well with existing components.
Self-review checklist:

[x] Self-review: looked through the Files changed tab, browsed repository in branch
[ ] Documentation updated - reflects changes in code, electrical or mechanical design
[ ] Documentation and graphics follow the documentation style guide
[ ] New content is linked, easily discoverable, does not require too many clicks
[ ] Follows other relevant parts of contributor wiki
[x] PR has a descriptive name
[x] Tagged relevant reviewers

CAD / mechanical only:

[x] Follows our mechanical engineering standards
[x] Everything is metric and ISO where possible
[x] All features and constraints are named
[x] Imported parts are well-named, with source URL and iProperties
[ ] Screenshots and/or assembly photos updated

Great work.
I've got a few issues and some design questions.
When opening it gives can't find NPT file error. It is probably because of my local files. But should check whether there exists a dependency.
I've got back panel geometric errors.

About M4 heat set screws
Hole size should be ~5.28mm. 5.94 value is for tapered part. There is some info here. Because we can't cut a tapered hole wwe should decide whether we use maximum or minimum diameter for hole.

When using these heat set screws did you encountered loosenes? If not, 5.94mm diameter is OK.

Technical drawings should be updated.
When the design is finalized technical drawings should be updated. Giving hole locations and diameters resulted in messy drawing. We might give all info on drawing instead of a table. Should open an issue about this or we can add as a next step.

@gokcemay finally getting to this.

Geometric errors - I am not able to get these errors. I am now running a fresh Inventor install (most recent) with a freshly cloned repository. I also suggest that you answer "No" when Inventor asks you to update the models. Agreeing to it may have a bunch of knock-on effects of changed files all over the place. Trying to keep change sets minimal for each PR.
Heat insert diameter - generally it has not been a problem. maybe they are a little wide, but also we have some resin-printed parts with inserts, and for them anything narrower would be a problem, because resin does not melt. We may need 2 separate constants depending on embedding material. Maybe let's create a ticket to optimize this at a later point?
As the PR description above says, " To limit the scope of this update, we are also omitting any drawing, BOM or documentation updates at this point." Feel free to create a ticket for this to be taken care of later.
Regarding splash proofing, we have #1065 and (marginally) #960 . Feel free to create an additional (umbrella) ticket to capture general splash proofing?

I'll get a fresh repo than I'll try to reproduce the error. If I can reproduce without updating I'll post a ticket.
We might need a ticket.
OK, missed that. Sorry.
I've made a new issue #1323 There might be additional parts to be splash proofed and I'll add them to this list.


[DOC] Wrong filename and minor grammar fix

What does this PR do?
Fixes documentation for Oracle integration.
Motivation
I ran into these when trying to get the Oracle integration working.
Review checklist
Have not notified the docs team or created an issue on the documentation repo since it costs me more time to add those additional steps rather than submit this PR. Not understanding this additional hurdle to be honest.

No worries, this LGTM. This checklist item is more for when we make code changes that need to have a corresponding change in the docs.
Thanks a lot for finding and fixing this 🙇


Dynamically Loading Assemblies

Is it possible for ASP.NET 5 running under dnxcore50 to load assembly files at runtime; supporting a plug-in type system.  I have tried obtaining the IAssemblyLoadContext using Microsoft.Runtime.Loader.LoadContextAccessor.Instance.Default without success; I'm trying to achieve this via a TagHelper similar to <plugin-module path="~/plugins" file="module01", sha=".."></plugin-module>
am I barking up the wrong tree? is this even possible? any advice/help/pointers would be great.

Recommend using the IAssemblyLoadContext in DI. Best to add a parameter of this type to your tag helper's constructor.
Please let us know if this does not work a bit better. Would also appreciate additional details on the failure if problems continue.

@HornerGrahame Here's an example of a console application https://github.com/aspnet/Entropy/tree/dev/samples/Runtime.CustomLoader


Many merged cells causes slowdown

If you have a lot of merged cells, it gets slower and slower with each added row. A document with around 1.7k rows is taking around 10minutes.
This issue already existed in the original repository at https://github.com/natergj/excel4node/issues/321
Not sure what can be done here, the check makes sense, but with huge datasets it gets unbearable slow, maybe add a flag to optionaly skip this check.

Duplicate of #33


BUG: Fix bug with CSP rank

Closes #9094
WIP because I haven't thoroughly tested or anything. But at least modifying the example things work out of the box. The "trick" is to use _smart_eigh to figure out the correct subspace, do the eigh(a, b) in that subspace, and project back the same way we do with covariances. (Now you shouldn't even have to supply rank because it'll compute it from the cov for you if you don't!)
This really only works with a single channel type at the moment -- to properly support multiple channel types people should pass an info I think. So the TODO list is roughly:

[x] Make tests more thorough
[x] Make sure everything is green
[x] Add a test using MEG+EEG to make sure it works
[x] Add info support to make multiple channel types support robust
[x] Add an example using MEG+EEG

@drammock realized we should get this in to 1.7 as well. Ready for review/merge from my end!

Argh https://physionet.org/ is down but example renders okay locally

main
PR

Related https://github.com/MIT-LCP/physionet/issues/154

LGTM, just one question: does this also resolve the issue with channel types? I remember someone reported that computing the rank on EEG-only data suddenly created a rank for MEG channels, but unfortunately I cannot find that issue (or forum question).

LGTM, just one question: does this also resolve the issue with channel types? I remember someone reported that computing the rank on EEG-only data suddenly created a rank for MEG channels, but unfortunately I cannot find that issue (or forum question).

I think this refers to my problem, though it created a rank for MAG instead of MEG. It's discussed here https://github.com/mne-tools/mne-python/issues/9094#issuecomment-1954187464
A MWE is here: https://colab.research.google.com/drive/1LBq8Sg-30Cnlj9sYLPtEcsPIyBtsvxF8?usp=sharing#scrollTo=_hS__cmSGVIU
The logger still indicates MAG channels which don't exist, but it's not causing any real problems anymore.
Setting small MAG eigenvalues to zero (without PCA)

Okay pushed a commit to fix that "mag" business as well, the logging in the changed example (if you enable it) looks like:
Computing rank from data with rank=None
    Using tolerance 7e-05 (2.2e-16 eps * 64 dim * 4.9e+09  max singular value)
    Estimated rank (data): 63
    data: rank 63 computed from 64 data channels with 0 projectors
    Setting small data eigenvalues to zero (without PCA)
Reducing data rank from 64 -> 63
Estimating class=0 covariance using EMPIRICAL
Done.
Estimating class=1 covariance using EMPIRICAL
Done.

Thanks @larsoner!

Seems like this PR introduces a bug, reported here: https://mne.discourse.group/t/the-api-reference-of-csp-needs-updata/9018/2