Move from copilot.vim to copilot.lua

This should possibly make config easier to integrate with the existing cmp plugin by using copilot-cmp

I can open a PR for this if you're interested in testing this out. I did so on my laptop a couple of weeks ago, and the experience was better IMHO.

I can open a PR for this if you're interested in testing this out. I did so on my laptop a couple of weeks ago, and the experience was better IMHO.

that would be wonderful <3

Disclaimer:

In Windows there are two big problems:

copilot.vim: it crashes as soon as two or more buffers are open and insert mode is entered in one of them.
copilot.lua: no autocomplete suggestion is given, even it copilot LSP allegedly started.

@pidgeon777  You should take that up with the plugin owners. And disable them in your config

In Windows there are two big problems:

copilot.vim: it crashes as soon as two or more buffers are open and insert mode is entered in one of them.
copilot.lua: no autocomplete suggestion is given, even it copilot LSP allegedly started.

yeah sadly i don't use windows at all ( macbook + linux workstation) so I've not tested it on windows, but i would suggest doing what Uzaaft said ( disabling them temporarily and reporting the bug to the plugin owners)

I just updated my Neovim to this version (I was using a previous v0.7.0 nighly version):
https://github.com/neovim/neovim/releases/tag/v0.7.0
copilot.lua is not working still, but copilot.vim at least now doesn't make Neovim crash anymore, fortunately.
Great plugin, though.

I just updated my Neovim to this version (I was using a previous v0.7.0 nighly version):
https://github.com/neovim/neovim/releases/tag/v0.7.0
copilot.lua is not working still, but copilot.vim at least now doesn't make Neovim crash anymore, fortunately.
Great plugin, though.

yeah i'm only using copilot.vim as well, and yes it is a wonderful plugin


refactor: tidy up and simplify tui

Codecov Report

Merging #42 (ee0cf5e) into main (a4eff71) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #42   +/-   ##
=======================================
  Coverage   50.17%   50.17%
=======================================
  Files           6        6
  Lines         289      289
=======================================
  Hits          145      145
  Misses        136      136
  Partials        8        8

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a4eff71...ee0cf5e. Read the comment docs.


Call to undeclared function 'DDLogInfo'; ISO C99 and later do not support implicit function declarations

Describe the bug
compile time error messages
To Reproduce
Steps to reproduce the behavior:
call any of the DDLog* methods
Expected behavior
no warnings or errors
Screenshots

Environment info

Info
Value

Platform Name
N/A

Platform Version
N/A

CocoaLumberjack Version
e.g. 3.8.0

Integration Method
cocoapods

Xcode Version
Xcode 14.3.1

Repro rate
all the time (100%) but after a while of background processing it dissappears until app rebuild

Additional context
It shows "errors" but the app runs fine. If I open the file where the "error" is, the error disappears after a few seconds

This could either be a missing import (DDLogMacros.h) or an Xcode quirk.
Given the build works, it's obviously a spurious error. Not sure we can do much here.


Domain index out of range with geopmread

geopmread -d reports more domain indices than are valid for reading.  For example, the output from geopmread -d is:
board                   1
package                 2
core                    48
cpu                     96
board_memory            2
package_memory          0
board_nic               0
package_nic             0
board_accelerator       0
package_accelerator     0

Trying to read cpu 80 gives the following error:
> geopmread FREQUENCY cpu 80
Error: cannot read signal: <geopm> Invalid argument: MSRIOGroup::push_signal(): domain_idx out of range: at geopm/src/MSRIOGroup.cpp:216

> geopmread FREQUENCY core 40
Error: cannot read signal: <geopm> Invalid argument: PlatformTopo::domain_idx() cpu index (cpu_idx) out of range: at geopm/src/PlatformTopo.cpp:225

The output of lscpu matches the domains reported by geopmread:
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                96
On-line CPU(s) list:   0-95
Thread(s) per core:    2
Core(s) per socket:    24
Socket(s):             2
NUMA node(s):          2
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 85
Model name:            Intel(R) Xeon(R) Platinum 8160 CPU @ 2.10GHz
Stepping:              4
CPU MHz:               1000.000
CPU max MHz:           2101.0000
CPU min MHz:           1000.0000
BogoMIPS:              4190.12
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              1024K
L3 cache:              33792K
NUMA node0 CPU(s):     0-23,48-71
NUMA node1 CPU(s):     24-47,72-95

Cannot reproduce


[broker] Bug Fix: topic policy is not properly init if namespace is loaded first.

Motivation
Currently, the onUpdate(TopicPolicies policies) callback is fired in two situations:

Namespace bundle first binds the broker.
Topic policy value updates.

Consider the following case, for one topic "topic-A" of namespace bundle "bundle-B". B is already loaded in current broker,  but "topic-A" is not loaded yet. (It happens when bundle-B is loaded by admin lookup operations.)
After a long while, "topic-A" is loaded by maybe some producer. In current loading procedure, only the listeners will be registered to TopicPoliciesService. So the onUpdate method of "topic-A" has no change of getting called.
More detailed steps to reproduce this bug, you can refer to the new test case  testTopicPolicyInitialValueWithNamespaceAlreadyLoaded.
Modifications
Add an async read topic policy and update procedure in PersistentTopic#initialize.
Verifying this change

[ ] Make sure that the change passes the CI checks.

This change added tests and can be verified as follows:

testTopicPolicyInitialValueWithNamespaceAlreadyLoaded

Does this pull request potentially affect one of the following parts:
If yes was chosen, please highlight the changes

Dependencies (does it add or upgrade a dependency): (no)
The public API: (no)
The schema: (no)
The default values of configurations: (no)
The wire protocol: (no)
The rest endpoints: (no)
The admin cli options: (no)
Anything that affects deployment: (no)

Documentation
Check the box below and label this PR (if you have committer privilege).
Need to update docs?

[x] no-need-doc

Bug fix.

/pulsarbot run-failure-checks

@codelipenghui @315157973  Please help take a look.

/pulsarbot run-failure-checks


Implementation for Gelu Operation

This code essentially adds support for onnx.gelu using the approximate attribute value.
When approximate = none the following output is expected:
y = 0.5 * x * (1 + erf(x/sqrt(2)))
Whenapproximate = tanh the following output is expected:
y = 0.5 * x * (1 + Tanh(sqrt(2/pi) * (x + 0.044715 * x^3)))
What this PR covers:

Added code to elementwise to ensure the calculations are done correctly for the output
Added code for SIMD of onnx.gelu
I also added a verifier to onnx.gelu to make sure that only the string value of tanh or none are accepted values for approximate
I created two lit tests
I added the eight backend tests associated with gelu from onnx 1.15.0 but only 4/8 tests pass. I am not too familiar with what the expanded variation of this tests means so will comment out until I better understand how to debug.
Updated documentation and did some small housekeeping

Jenkins Linux ppc64le Build #12825 [push] Implementation for Gelu ... started at 20:27

Jenkins Linux s390x Build #13828 [push] Implementation for Gelu ... started at 20:20

Jenkins Linux amd64 Build #13801 [push] Implementation for Gelu ... started at 19:20

Jenkins Linux s390x Build #13828 [push] Implementation for Gelu ... passed after 1 hr 2 min

Jenkins Linux amd64 Build #13801 [push] Implementation for Gelu ... passed after 1 hr 8 min

Jenkins Linux ppc64le Build #12825 [push] Implementation for Gelu ... passed after 1 hr 38 min


Unzip should move .properties files to .config

Info

Which version of Pi are you using: ZeroW
Which github revision of software: develop
Which board version: FULLSPEC
Which computer is the RaSCSI connected to: VAXstation/Alphaserver

Describe the issue
The unzip feature is great and I intend to use it to store software ISOs and extract only as required. Also to store various installed operating systems for testing. Some ISO files (like mine) and hard disk images have .properties files to set sector sizes or vendor/product strings. These should be processed if found in the zip file.
If a .properties file is detected inside the zip file, then:

It should not be listed in the expanded zip details (or maybe put an asterisk after the image name to flag it)
If an image is selected to unzip, the corresponding .properties file should be moved to the .config directory so that it is associated with the image.

This would allow image files to be restored correctly along with their properties.
I notice that the delete function automatically deletes the associated .properties file, so this part is already taken care of.

@Pacjunk This should address this use case https://github.com/akuker/RASCSI/pull/432
What it does, is that when you choose to unzip a properties file individually, as well as as part of Unzip All, the resulting file will be moved to ~/.conf/rascsi/
Seems to be working as expected in my testing.

@Pacjunk Improvements as discussed in Discord https://github.com/akuker/RASCSI/pull/447


Document update conflict

Hi, I need some help.
Thanks

Hi there,
This is not a CouchDB bug. GitHub is for actual CouchDB bugs only. I believe your problem is invalid JavaScript in one of your views causing the external couchjs process to fail.
If you are looking for general support with using CouchDB, please try one of these other options:

The user mailing list. Signup instructions are here
The Slack/IRC chat room. Joining instructions are here


path.public not being used when publishing assets from a package

Laravel Version: 5.5.23
PHP Version: 7.0.22
Database Driver & Version: MySQL v5.7.19

Description:
Hello,
It seems that the path.public doesn't get loaded correctly when you vendor:publich from a service provider from a package.
Am I overlooking something here or is this a bug?
Thanks.
Steps To Reproduce:
I have installed a fresh copy of Laravel, and installed the Voyager package. I added the following code to change the public path of Laravel to the AppServiceProvider.php register method.
$this->app->bind('path.public', function () { return base_path('public_html'); });
I created a console command and a route where I dd(public_path()) and they both returned the public_html. I also did this in the VendorPublishCommand class and it also returned the public_html path.
When I dd(public_path()) in the following class: VoyagerServiceProvider it reverts back to public.

The reason you are not seeing it is because Laravel isn't able to properly locate the public_html directory. That's why it is reverting back to public folder.
Try this, it may work though:
$this->app->bind('path.public', function () {
    return base_path().DIRECTORY_SEPARATOR.'public_html';
});

I copied the exact code you posted, but it is still being placed in a newly created public folder.

It depends on the order of providers registration, please ask on the forums, this repo is for bug reporting only. You can use https://laracasts.com/discuss or https://laravel.io/forum which are forums with a very large community of developers helping each other.


Fix OCSP stapling with dual cert

This PR fixes two issues.

The OCSP cache is not set for the first ocsp.update_period (defaults to 60 seconds).

The OCSP information for only one of the certificates associated with the SSL_CTX is stapled (it appeared to be the first certificate listed in the comma separated list in ssl_multicert.config.  I was testing this with alternating calls to the following

openssl s_client --connect localhost:443 -cipher 'ECDHE-ECDSA-AES256-SHA' -tls1_2 -status
openssl s_client --connect localhost:443 -cipher 'ECDHE-RSA-AES256-SHA' -tls1_2 -status

In the current code, both requests would return the following OCSP repsponse:
OCSP response:
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: 5168FF90AF0207753CCCD9656462A212B859723B
    Produced At: Jan  7 09:19:56 2019 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: CF26F518FAC97E8F8CB342E01C2F6A109E8E5F0A
      Issuer Key Hash: 5168FF90AF0207753CCCD9656462A212B859723B
      Serial Number: 029FD28F5532A4F9158D26390D478AA2
    Cert Status: good
    This Update: Jan  7 09:19:56 2019 GMT
    Next Update: Jan 14 08:34:56 2019 GMT

    Signature Algorithm: sha256WithRSAEncryption
         01:ce:a8:85:c0:25:b2:40:0c:91:ea:8e:c5:1d:cf:37:65:2f:
         79:86:fb:34:91:d1:fc:ba:6c:dd:59:8e:34:07:5f:87:1a:c7:
         f1:dc:32:0d:36:2e:13:11:95:17:66:bd:eb:7d:eb:7b:3d:51:
         07:aa:30:d5:64:08:65:0d:11:0c:79:f5:db:b9:9b:1b:2c:2c:
         47:69:ca:6d:29:3e:e4:e6:69:9c:25:d3:ef:5c:1e:75:78:fb:
         14:eb:54:d1:1d:68:8b:1c:b5:12:42:5e:47:c4:94:43:ef:81:
         51:ff:3a:27:58:99:b4:f4:bd:0c:51:44:5d:ff:e6:ce:e6:68:
         56:b2:8d:13:07:03:84:98:92:a7:71:33:c3:17:2b:e2:89:ac:
         d4:52:fc:b0:6f:51:b5:e7:b7:d3:fc:b8:f8:0a:84:ad:da:86:
         47:d1:83:80:78:42:f0:95:63:81:8b:28:92:34:e3:7a:bc:74:
         09:c4:ca:dd:05:66:1b:10:b8:a2:a9:13:ad:4b:3a:4b:87:a7:
         b5:f5:0a:f4:ba:ea:42:9b:f8:c8:14:03:92:4c:d6:9c:a8:fd:
         91:1f:89:d3:2a:76:92:ac:9c:22:fe:bb:d4:8e:c7:6c:67:03:
         cf:24:e4:39:1a:42:02:65:0c:54:f5:15:2a:48:c5:84:31:1f:
         5b:d9:26:d8
======================================

Where serial # 029FD28F5532A4F9158D26390D478AA2 corresponds to my EC certificate which would have been used in the negotiation of the first request but not the second request.
With this code change, the request that negotiates a RSA authentication returns reference to serial number in the RSA certificate.

@randall Did I successfully address your concerns?

Cherry picked to 8.1.0

Cherry-picked to 8.1.x


Have anyone run it on windows 7?

When i run make on win7,I got an error as following:
godep go build -o bin/go-mysql-elasticsearch ./cmd/go-mysql-elasticsearch
process_begin: CreateProcess(NULL, godep go build -o bin/go-mysql-elasticsearch
./cmd/go-mysql-elasticsearch, ...) failed.
make (e=2): 系统找不到指定的文件。
make: *** [build-elasticsearch] 错误 2
What's wrong here?

Hi @leelyliu
I have no windows platform, so I don't know how to fix it. Sorry.

Hi @siddontang
Thanks your reply anyway. I run it successfully on Win7 at last.
Coz no experience of the GO language, I spent too much time compiling the source on windows.
I downloaded a "make.exe" from internet, but the compile failed. Show me above error. I have to continue to find answer on internet. Maybe there are some problems of the "make.exe". So I got a "make.exe" by MinGW. And complied your program by the "make.exe". It worked!!!
But when I run go-mysql-elasticsearch in command line on windows. The system told me the program can't be recognized. So I changed "godep go build -o bin/go-mysql-elasticsearch" to "godep go build -o bin/go-mysql-elasticsearch.exe" in MikeFile from your src. And then compiled them again. The exe worked!!!
It's great!!

Cool


[FLINK-14903][table] Relax structured types constraints

What is the purpose of the change
In order to allow type extraction of structured types that are not registered in a catalog, we need to relax the structured type concept to "inline or anonymous structured types" that are not identified by an object identifier in a catalog but the fully qualified implementation class.
This PR also fixes issues with UnresolvedIdentifier
Brief change log

Use UnresolvedIdentifier everywhere
Fix equals of UnresolvedIdentifier
Make ObjectIdentifier optional for anonymous structured types

Verifying this change
This change is already covered by existing tests.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): yes
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? yes
If yes, how is the feature documented? JavaDocs

Thanks for the feedback @dawidwys. Merging...


Search request urls should urlencode plus signs

Search request urls must urlencode plus signs (perhaps minus signs as well?) in order to work.

Fixed the issue and reworked the urlencoding a bit.


Review AWS STRA with CP Team

Describe the issue
Review of the AWS SOAR with CP team member(s)
Which Sprint Priority is this issue related to?
sprint13
Additional context
Add any other context, attachments or screenshots
Definition of done

Meet with CP team members
Review document for edits/update
Confirm no other changes needed from CP team.

met with CP product owner on 23rd
Reviewing and incorporating updates.

Met with JS & GL
Reviewed and signed off by GL.
Moved for sign off


Replaced u8 by unsigned char & added the option "-nm" in the README

When compiling the c code, u8 is not typedef yet. Replacing it by "unsigned char" solve this problem

Could you expain why you have a "u8 undefined" problem? This has been used for years and in hundreds of projects and no-one has had this problem. In fact, you can get any of this projects from CPCRetroDev website, for instance, and they compile without any problem.
u8 is a type defined in cpctelera.h header file. If you are not using CPCtelera, you could create your own header file with the typedef and use "--includes" flag to make img2cpc generate a "#include "your_headerfile.h"" directive at the top of generated file.

I don't use cpctelera and didn't know the –includes flag.
You could close the request then ;) Sorry for that.
(But you could add the -nm flag in the readme ;p)


Model diverges if FP16 is enabled

I am training a ViT Transformer using deepspeed with FP16 enabled. The loss decreases at the beginning, however it starts to increase once it reaches loss around 14. Below is an example (x-axis: iteration, y-axis: loss value):

@gongbudaizhe, thanks for reporting this problem. Can you please share more details, such as script and dataset, to help repro?

Did you solve this problem, I also got the same problem @gongbudaizhe

No, I have tried gradient clipping and smaller learning rate but the results are no good. More in-depth investigation is needed.
For now, I am using FairScale from facebook research which supports ZeRO with AMP and doesn't have the divergence problem. However, the training speed and memory consumption is inferior to DeepSpeed.

@gongbudaizhe or @Bournet, are you able to share details to help us repro the problem? Thanks.

@gongbudaizhe, just wanted to check if you could share a small repro to help us fix this issue? Thanks.

Closing for lack of response. Please reopen as appropriate.


Handle situatuation when user try to register with existing username

When user try to register with existing username the following error is returned from /users/register controller: link to pastebin.com

in addition to this task. i propose remove  return new ResponseEntity(HttpStatus.IM_USED); and
return new ResponseEntity(HttpStatus.CREATED); and handle this with an exception handler

@romach use pastebin.com for large code, please

blocked with #155 @AndriyBaibak @alex-anakin pls fix

@AndriyBaibak time spent: 3h

@AndriyBaibak time spent: 20m

@AndriyBaibak time spent: 30m

@AndriyBaibak time spent 10m


pycurl.URL doesn't accept unicode, so use str().

Good point!
Have you tried this with python 3?

No, I haven't, I've been testing the client on RHEL-7.1.

I think that the string should be properly encoded. Let's merge this and figure out possible issues in future.


Updated api, web & azure image versions

[x] I've added a new note in the charts/wharf-helm/CHANGELOG.md file, according to docs:
https://iver-wharf.github.io/#/development/changelogs/writing-changelogs
(but without version dates nor WIP versions)

Summary

Upped chart version to v2.0.0.

Updated docs in README.md about helm-docs as there was a bug in v1.6.0 that I don't have time to deal with right now. Sticking to v1.5.0 for now, as the GitHub Actions is already locked into using v1.5.0.

BREAKING: Changed image version of providers.azuredevops from v1.2.0 to v2.0.1.

Changed image version of web from v1.3.3 to v1.4.0.

Changed image version of api from v4.1.1 to v4.2.0.

Motivation
Did a major version bump on the chart as the azuredevops update has breaking changes.

@Alexamakans PR comment says azuredevops v1.2.0 to v2.0.0 but it was updated to v2.0.1.
Assuming it's supposed to say v2.0.1 in the PR comment as well, but you never know.

Yea, force-pushed the change to this PR but forgot to update the PR description.

@fredx30 No updates in github/gitlab providers?

Nope. No new releases. As these azuredevops changes are kind of prio I neglected the other providers for now. The wharf-web got into the mix just because it was about to be released anyways.


added first few lines of strings.md

I have added some documentation for strings.
Needs more work to become complete.

I have continued work and added some more content since the last pull request...


401 Unauthorized at Site Creation step

Script appears to hit a 401 when creating the Site Collection (v3 SPO), is already logged on in SharePoint Online Management Shell and tested logging in to the Admin Site through PnP.

Changed default auth mode to just use the SharePoint PnP Cmdlets to work around this while investigating. SharePoint Online Management Shell will not be required for now.

Revised this slightly. SharePoint Online Management Shell is required, but we aren't explicitly calling it anymore, PnP calls it implicitly when we try to use it's Auth and that seems to work around this.

This Issue posted for PnP is relevant here and why this broke originally:
https://github.com/pnp/PnP-PowerShell/issues/2538


Storybook does not work with RN0.59.+

Describe the bug
Unable to load findSymlinksPaths: Cannot find module 'react-native/local-cli/util/findSymlinksPaths'
error: unknown option `--projectRoots'
To Reproduce
Steps to reproduce the behavior:

Upgrade to latest react-native version
run storybook start -p 7007 | react-native start --projectRoot storybook

Additional context
I think the problem is because the path is wrong, now the cli is from @react-community/cli

Which version of storybook?

I've solved this adding react-dom as devDep
and then adding this to metro.config.js:
const path = require('path');

module.exports = {
  projectRoot: path.resolve(__dirname, '.'),

  watchFolders: [
    path.resolve(__dirname, 'node_modules'),
  ],

  resolver: {
    // https://github.com/facebook/metro/issues/1#issuecomment-453450709
    extraNodeModules: new Proxy({}, {
      get: (target, name) => path.join(process.cwd(), `node_modules/${name}`),
    }),
  },

  transformer: {
    getTransformOptions: async () => ({
      transform: {
        experimentalImportSupport: false,
        inlineRequires: false,
      },
    }),
  },
};

@shilman 3.4.12 latest on npm

Oh wow. Any reason you're not upgrading to 4.x or 5.1-alpha.x (other than that upgrading can be a pain in the neck)?

@shilman actually i have tried to use version 4.1.16 which is using "airbnb-js-shims" which is using "promise.prototype.finally" . and then i have another error "finally is undefined".

@benoitdion @Gongreg have you seen this airbnb-js-shims issue?
@MaxToyberman Perhaps @jgcmarins workaround will work for you on 3.4? If not, I suggest trying to upgrade to 5.1-alpha. All active development is going on there, so you're much more likely to get help if you're running latest. We just don't have the resources to go back and support RN59 in old versions of storybook unless it's community-contributed.

@shilman  the same problem on 5.1-alpha, my dependecies:

"@storybook/addon-actions": "5.0.6",
    "@storybook/addon-knobs": "5.0.6",
    "@storybook/addon-ondevice-knobs": "4.1.16",
    "@storybook/addon-ondevice-notes": "4.1.16",
    "@storybook/addons": "5.0.6",
    "@storybook/react-native": "5.1.0-alpha.24",

@MaxToyberman I don't think this will solve the problem, but in general keep all your @storybook/* to the same version (in this case 5.1.0-alpha.24). Also did you follow the 5.1 migration instructions: https://github.com/storybooks/storybook/blob/next/MIGRATION.md#react-native-server

@shilman I have created a new empty project and added storybook with : npx -p @storybook/cli sb init --type react_native
then i write  :
    fetch("https://google.com")
      .then(res => {})
      .catch(e => {
        console.log("finally");
      })
      .finally(() => {
        console.log("finally");
      });

i get this error :

The solution for me was to modify package.json to :
    "@storybook/addon-actions": "4.0.11",
    "@storybook/addon-knobs": "4.0.11",
    "@storybook/addon-links": "4.0.11",
    "@storybook/addon-ondevice-knobs": "4.1.16",
    "@storybook/addon-ondevice-notes": "4.0.11",
    "@storybook/addons": "4.0.11",
    "@storybook/react-native": "4.0.11",

@MaxToyberman are you still seeing the issue with the latest 5.1 RC?


[WIP] updated visualisation methods and unit handling; alpha update

EDIT: This PR updates methods for visualisation of Dipole

[ ] time series smoothing (add Savitzky-Golay for smoothing and better docstrings)
[ ] power spectrum estimation and plotting
[ ] handling of units in plots (alternative to a scale-operation)
[ ] update alpha-example to demonstrate
[ ] implement test for savgol and copy methods

I was unable to push these directly to #249 before merging, so here as a follow-up. Note that I removed the print(params)-line, since there's a lot in there that doesn't get applied (incl. 'common feeds').
@ntolley if you agree, merge at will!
To follow up on a discussion in #249 (@jasmainak @rythorpe): I think this example might benefit from smoothing the waveforms? I tried with smooth(1000), which looks quite illustrative for both cases:

We could leave it for 0.2 release, though. There's a lot we need to figure out regarding visualisation.

Thanks @cjayb, I'll go ahead and merge once the CI's go green.
I actually really like the smoothing for illustrative purposes. Might require a quick statement in the docstring like "MEG/EEG signals undergo low-pass filtering when passing through the skull. We can apply a smoothing to the simulated current dipole to better reflect experimentally recorded signals."

Thanks @cjayb, I'll go ahead and merge once the CI's go green.
I actually really like the smoothing for illustrative purposes. Might require a quick statement in the docstring like "MEG/EEG signals undergo low-pass filtering when passing through the skull. We can apply a smoothing to the simulated current dipole to better reflect experimentally recorded signals."

MEG/EEG signals undergo low-pass filtering when passing through the skull.

yikes, Matti will disown me if he sees this sentence in hnn-core :)

MEG/EEG signals undergo low-pass filtering when passing through the skull.

yikes, Matti will disown me if he sees this sentence in hnn-core :)

I also saw this sentence in the example:

The dpl[trial_idx].scale() call relates to the amount of cortical tissue necessary to observe the electric current dipole outside the head with M/EEG.

but no call to "scale". Remove the sentence?

I also saw this sentence in the example:

The dpl[trial_idx].scale() call relates to the amount of cortical tissue necessary to observe the electric current dipole outside the head with M/EEG.

but no call to "scale". Remove the sentence?

I tried with smooth(1000), which looks quite illustrative for both cases

I wonder if the smooth function should take input in seconds instead of samples

I tried with smooth(1000), which looks quite illustrative for both cases

I wonder if the smooth function should take input in seconds instead of samples

yikes, Matti will disown me if he sees this sentence in hnn-core :) I believe the low-pass hypothesis has never been proven experimentally ... but I am happy to be proven wrong

Ah good to know, quick reading suggests that it may reflect how synchronous high frequency activity occurs with smaller volumes of cortical tissue.
Point stills stands, if we want to include smoothing do you have a suggested explanation that won't offend too many people? Perhaps just "Several factors contribute to the appearance of low-pass filtered signal when recording neural signals outside the head. We can apply a smoothing to the simulated current dipole to better reflect experimentally recorded signals."

yikes, Matti will disown me if he sees this sentence in hnn-core :) I believe the low-pass hypothesis has never been proven experimentally ... but I am happy to be proven wrong

Ah good to know, quick reading suggests that it may reflect how synchronous high frequency activity occurs with smaller volumes of cortical tissue.
Point stills stands, if we want to include smoothing do you have a suggested explanation that won't offend too many people? Perhaps just "Several factors contribute to the appearance of low-pass filtered signal when recording neural signals outside the head. We can apply a smoothing to the simulated current dipole to better reflect experimentally recorded signals."

So -- low-pass filtering the data will create a corner frequency whereas I have mostly seen the spectrum decay (what's usually called a 1/f but that's a bit of a misnomer too). I am also not exactly sure what the smoothing with Hamming window does. It low-pass filters but what's the corner frequency? Okay I have said enough ... floor is yours @cjayb to pitch opinions :)

So -- low-pass filtering the data will create a corner frequency whereas I have mostly seen the spectrum decay (what's usually called a 1/f but that's a bit of a misnomer too). I am also not exactly sure what the smoothing with Hamming window does. It low-pass filters but what's the corner frequency? Okay I have said enough ... floor is yours @cjayb to pitch opinions :)

Codecov Report

Merging #264 (56bd90c) into master (acef0cd) will increase coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #264      +/-   ##
==========================================
+ Coverage   52.93%   52.94%   +0.01%
==========================================
  Files          23       23
  Lines        2747     2748       +1
==========================================
+ Hits         1454     1455       +1
  Misses       1293     1293

Impacted Files
Coverage Δ

hnn_core/__init__.py
100.00% <0.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update acef0cd...56bd90c. Read the comment docs.

Codecov Report

Merging #264 (56bd90c) into master (acef0cd) will increase coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #264      +/-   ##
==========================================
+ Coverage   52.93%   52.94%   +0.01%
==========================================
  Files          23       23
  Lines        2747     2748       +1
==========================================
+ Hits         1454     1455       +1
  Misses       1293     1293

Impacted Files
Coverage Δ

hnn_core/__init__.py
100.00% <0.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update acef0cd...56bd90c. Read the comment docs.

I think Matti and @jasmainak are vindicated: http://dx.doi.org/10.1523/ENEURO.0291-16.2016 :)
Any real evoked or even rhythmic response is riding on top of that 1/f-like sea of, you know, that ninety-something% of "brain activity" we rarely focus on. So in essence we have hundreds of thousands of 'other' HNN networks active, creating a stochastic smoothing. Furthermore, one of our 200 pyramidal neuron-strong networks is probably only on the order of a percent of the total number of microcolumns creating the macroscopic signals we measure. And each of these is also doing other computations, involving other dynamics that interact and interfere.
I see smoothing here as a way to 'simulate' the combined effects of 1) non-zero background and 2) hundreds or thousands of more n_trials. I don't think we can 'justify it' with reference to any biophysical properties of neurons or tissue. The former surely generate HH-dynamics at a very high rate, and the latter is essentially a linear conductor with a flat impedance spectrum.
I'll take a look at the smoothing code (agree it's currently a little ad hoc), and see if I can write some prose about the background (without drowning the example in too many details). @ntolley had a delightfully 'Swiss' proposal above, maybe best to dodge the issue like that :)

I think Matti and @jasmainak are vindicated: http://dx.doi.org/10.1523/ENEURO.0291-16.2016 :)
Any real evoked or even rhythmic response is riding on top of that 1/f-like sea of, you know, that ninety-something% of "brain activity" we rarely focus on. So in essence we have hundreds of thousands of 'other' HNN networks active, creating a stochastic smoothing. Furthermore, one of our 200 pyramidal neuron-strong networks is probably only on the order of a percent of the total number of microcolumns creating the macroscopic signals we measure. And each of these is also doing other computations, involving other dynamics that interact and interfere.
I see smoothing here as a way to 'simulate' the combined effects of 1) non-zero background and 2) hundreds or thousands of more n_trials. I don't think we can 'justify it' with reference to any biophysical properties of neurons or tissue. The former surely generate HH-dynamics at a very high rate, and the latter is essentially a linear conductor with a flat impedance spectrum.
I'll take a look at the smoothing code (agree it's currently a little ad hoc), and see if I can write some prose about the background (without drowning the example in too many details). @ntolley had a delightfully 'Swiss' proposal above, maybe best to dodge the issue like that :)

yes, agree with @cjayb 's explanation. Another point I can't resist making is that intracranial EEG signals look pretty smooth as well ... at least what I've seen so far from recent explorations. So the destructive/constructive interference between multiple HH networks seems to make more sense to me. I'm okay with either @ntolley 's swiss explanation or a more detailed explanation that is less wrong than the first explanation we had :)

yes, agree with @cjayb 's explanation. Another point I can't resist making is that intracranial EEG signals look pretty smooth as well ... at least what I've seen so far from recent explorations. So the destructive/constructive interference between multiple HH networks seems to make more sense to me. I'm okay with either @ntolley 's swiss explanation or a more detailed explanation that is less wrong than the first explanation we had :)

Wellwell, let's see how this goes down... ;) I lifted this from mne. Savitzky-Golay works nicely on short datasets like evoked responses and our simulations. It's not 'exact', the docstring reflects this.
Other changes:

Dipole.copy() and some return self's: allows doing dpl.copy().savgol_filter(30)
revamped the PSD plotting function: the use of spectrogram suddenly weirded me out! And I decided against Welch because our trials are usually too short.
added units from Dipole.units to plot_dipole and plot_periodogram

Things to discuss

[ ] savgol_filter or just smooth?
[ ] periodogram OK, or should it be Welch with a winlen-parameter?
[ ] rather than reading from Dipole.units, might be better to have an explicit units-argument? Dipole.scale doesn't update the units, so we can easily end up in a mismatch. But we don't currently expose the scale-method, so I guess we can defer the decision for later?

Wellwell, let's see how this goes down... ;) I lifted this from mne. Savitzky-Golay works nicely on short datasets like evoked responses and our simulations. It's not 'exact', the docstring reflects this.
Other changes:

Dipole.copy() and some return self's: allows doing dpl.copy().savgol_filter(30)
revamped the PSD plotting function: the use of spectrogram suddenly weirded me out! And I decided against Welch because our trials are usually too short.
added units from Dipole.units to plot_dipole and plot_periodogram

Things to discuss

[ ] savgol_filter or just smooth?
[ ] periodogram OK, or should it be Welch with a winlen-parameter?
[ ] rather than reading from Dipole.units, might be better to have an explicit units-argument? Dipole.scale doesn't update the units, so we can easily end up in a mismatch. But we don't currently expose the scale-method, so I guess we can defer the decision for later?

I like the returning of self :)
what's the benefit of savgol_filter over smooth?

I like the returning of self :)
what's the benefit of savgol_filter over smooth?

OK to use periodogram, or should it be Welch with a winlen-parameter?

I guess it depends what you're trying to find. Welch will dampen any local effects but periodogram may show even artifacts

OK to use periodogram, or should it be Welch with a winlen-parameter?

I guess it depends what you're trying to find. Welch will dampen any local effects but periodogram may show even artifacts

should the method be called plot_spectrum, for simplicity?

sure. Okay I am deferring the review of the rest of the PR to @ntolley . Need to go underground for grant writing again :)

should the method be called plot_spectrum, for simplicity?

sure. Okay I am deferring the review of the rest of the PR to @ntolley . Need to go underground for grant writing again :)

@rythorpe @ntolley could you weigh in on these? I'd like to get you immediate reactions before moving forward (yes: even with tests ;)

I guess it depends what you're trying to find. Welch will dampen any local effects but periodogram may show even artifacts

Our windows are so short that there's hardly a case where we'd benefit from Welch, or is there?

@rythorpe @ntolley could you weigh in on these? I'd like to get you immediate reactions before moving forward (yes: even with tests ;)

I guess it depends what you're trying to find. Welch will dampen any local effects but periodogram may show even artifacts

Our windows are so short that there's hardly a case where we'd benefit from Welch, or is there?

should the method be called plot_spectrum, for simplicity?

Agree that this sounds reasonable as well.

rather than reading from Dipole.units, might be better to have an explicit units-argument? Dipole.scale doesn't update the units, so we can easily end up in a mismatch. But we don't currently expose the scale-method, so I guess we can defer the decision for later?

Unit argument sounds good since a large amount of fitting waveforms to real data involves appropriate scaling. Perhaps we could rename Dipole.units, or at least emphasize in the docs that it reflects the original units from a single cortical column before scaling.
I'll need to refresh my memory on these spectral methods but will comment on the proposed functions soon.

should the method be called plot_spectrum, for simplicity?

Agree that this sounds reasonable as well.

rather than reading from Dipole.units, might be better to have an explicit units-argument? Dipole.scale doesn't update the units, so we can easily end up in a mismatch. But we don't currently expose the scale-method, so I guess we can defer the decision for later?

Unit argument sounds good since a large amount of fitting waveforms to real data involves appropriate scaling. Perhaps we could rename Dipole.units, or at least emphasize in the docs that it reflects the original units from a single cortical column before scaling.
I'll need to refresh my memory on these spectral methods but will comment on the proposed functions soon.

Back from some light reading. Definitely supportive of the savgol filter. Specifying the frequency seems quite useful, but I am particularly a fan of the shape preserving properties.
Tough decision with welch vs. periodogram. While this isn't the ideal example, the periodogram may prove more useful in practice. PSD's from this sort of experiment would typically be averaged over multiple trials. I believe this would have a similar benefit to welch's method if applied to a single longer time series?
To stay consistent with the lab's literature, I'll plan to put together an example for beta events that shows where averaged spectral methods can misleading (after the 0.1 release).

Back from some light reading. Definitely supportive of the savgol filter. Specifying the frequency seems quite useful, but I am particularly a fan of the shape preserving properties.
Tough decision with welch vs. periodogram. While this isn't the ideal example, the periodogram may prove more useful in practice. PSD's from this sort of experiment would typically be averaged over multiple trials. I believe this would have a similar benefit to welch's method if applied to a single longer time series?
To stay consistent with the lab's literature, I'll plan to put together an example for beta events that shows where averaged spectral methods can misleading (after the 0.1 release).

might be a radical solution, but can we get rid of units attribute altogether? And we store always in the SI unit, Am like in MNE. For plotting, you can have a param called scalings which is 1e9 by default indicating that it's in nAm

might be a radical solution, but can we get rid of units attribute altogether? And we store always in the SI unit, Am like in MNE. For plotting, you can have a param called scalings which is 1e9 by default indicating that it's in nAm

5dee224 re-implements smooth: behaviour depends on argument passed (post_proc needed a minor change, otherwise simple)
ab26e26 implements Welch PSD: I'm more convinced than ever that it's not what we want! Note that nfft is much longer than the trial duration (16k vs 11k). For meaningful smoothing at low frequencies, we'd need a lot longer trials
5d31f4b shows some how we might demonstrate the effects of smoothing, and the two PSDs.

Are we OK with smooth having this dual role? I may be a slight antipattern, but I feel it's semantically pretty clear to a user who just wants to 'smooth' their data for visualisation. I could improve the docstring, if that would help?
How about dropping Welch and re-implementing plot_periodogram to take in a list of Dipoles? That would be equivalent to a Welch windowing with no overlap and nfft==nperseg. WDYT?
Next up: units scaling.

Before we go into the rabbit hole of implementing more sophisticated periodograms, let's ask ourselves ... do we really need this or is a TFR plot good enough for everything? Because that's what I have seen in HNN so far. I feel the efforts might be better spent in trying to copy the TFR code from MNE. It's also easier to interpret in HNN contexts where we can have transient oscillations. The periodogram that I had in the alpha oscillation was a lazy effort to prevent an MNE dependency while showing alpha for cheap with scipy

Are we OK with smooth having this dual role?

Need to sleep on it a bit. You could consider the following alternatives:
dipole.smooth_savgol(30)
dipole.smooth_hamming(500)

or
dipole.smooth('savgol', 30)
dipole.smooth('hamming', 500)

also not entirely sure about forcing named arguments in functions with only a few arguments. Might be annoying for a new user who doesn't know Python that much.

why does it return an instance if it works in-place?

Enables chaining, e.g.: `dpl.smooth(...).scale(...).plot(...)1

do we really need this or is a TFR plot good enough for everything? Because that's what I have seen in HNN so far.

Fair enough, but I do believe HNN has PSD plots too? The fundamental problem of too short data segments applies to either approach. With 300 ms of data it makes little sense even pretending to estimate power <10 Hz. The simulations we run are sampled at 40 kHz, but we know our aggregate dipoles are effectively silent above 200 Hz. I think it would be great to have a simple PSD routine available, such as the periodogram that could be used to average over trials to obtain a little of that sweet Welch feeling.

It's also easier to interpret in HNN contexts where we can have transient oscillations. The periodogram that I had in the alpha oscillation was a lazy effort to prevent an MNE dependency while showing alpha for cheap with scipy

Agreed, but I wouldn't sell the simple spectrum quite that short: many non-engineers balk at TFRs, but can easily get behind a power spectrum.

Need to sleep on it a bit. You could consider the following alternatives:

I guess I see what you're trying to avoid (e.g. forced named arguments), but having to memorise different smoothing methods is also an overhead. I still like my proposal best, but can easily be swayed :)
(P.S. Travis will have his pep8 with the next commit)

Enables chaining, e.g.: `dpl.smooth(...).scale(...).plot(...)1

Take a look at what happens in MNE. I don't think chaining is supposed to work with in-place operations, e.g., raw.filter

Travis will have his pep8 with the next commit

We should separate style checks into a separate CI build so it fails fast ...

I've added a first-pass at units and scaling and used them in the alpha-example; see what you think? Could this be the basis of solving #265 ?
Do you like the overlay of smoothing methods?
The Welch PSD is far too messy to warrant inclusion, IMHO. The periodogram-based plot_psd could easily be modified to take in a list of Dipoles, and compute an average of those (trials).

We should separate style checks into a separate CI build so it fails fast ...

Yes! Though I re-enabled linting in my editor, so should push less of those myself :)

Do you like the overlay of smoothing methods?

I like the description and showing the unsmoothed and smoothed signal! I think that has educational value. However, I am not entirely sure about the detour into different smoothing methods. I do agree that savgol makes more sense. If you want to push for that, I'd suggest mentioning that the GUI uses the "window" method as the default but if you want better control on h_freq, we have a better method ... tada savgol.

The Welch PSD is far too messy to warrant inclusion, IMHO. The periodogram-based plot_psd could easily be modified to take in a list of Dipoles, and compute an average of those (trials).

+1 for this
what's the scope of this PR though? :)

Also before introducing savgol it might worth asking folks how they set the window size parameter of hamming window smoothing. If there is a straightforward intuition, maybe we don't need to add savgol?

In the interest of time, and limiting the scope, I propose we stick to smoothing using the "old" convolution-method. SavGol can remain as a separate function? Also: after fiddling with it a bit, I can create pathological cases, so probably best to tread carefully (e.g., sync_evinput will generate spectacular fails).
This (or several) PR still needs to address #265. The smoothing-artefact in this alpha-example is due to the missing baseline_renormalize-step

Notice how the smoothed curve wants to return back to zero? The convolve-function uses zero boundary conditions. I'd like to emphasise that although detrending might seem like a solution, it's not a principled way to deal with this. Simulations will always have edge artefacts, there's no fundamentally 'most correct' way to deal with them.
I propose we educate users about the edge artefacts, and remove baseline_renormalize from default post-processing. In fact, remove post-processing entirely (except for units, see below) and scale and smooth explicitly in the examples.
The last unsolved issue is units and scaling. We need confirmation on:

[ ] internal unit of time (currently: ms)
[ ] internal unit of dipole moment (currently: fAm, postproc scales to nAm by default)

I propose we keep time as ms, and convert all dipole moments to nAm. I know these go against the mne-python convention, but our use case is very different. This would allow us to use sane defaults for both units ('nAm') and scaling. The latter could even be omitted entirely: the user would use scale for everything, and be responsible for setting the units accordingly if powers-of-ten are used.

okay with ms and nAm as default units. As long as it's documented I'm fine with deviating from MNE-Python. I would not add any attributes to Dipole object for units. So just to clarify, if you want to get the original unscaled data in nAm, you would divide dpl.data by dpl.scaling?
now about smoothing, I think this requires a bit more thinking/discussion. This reminds me of the MNE function fix_stim_artifact. There they do interpolation + windowing.
I do think that the smoothing artifact at the edge is weird. Sane defaults is not bad but magic is bad. So far, we had magic ... let's try to move towards sane defaults instead. One idea is to get rid of "postproc" boolean flag because it's an all encompassing thing (e.g., from simulate_dipole). Instead do:
dpl.scale(factor=1000, smooth=500, demean=True)

"demean" being your new/old "baseline re-normalize".  I like this better than:
dpl.scale(1000)
dpl.smooth(500)
dpl.demean()

because we can enforce a certain order to the operations (demean before smooth for example) if it's a single function.
what's the plan with backwards compatibility in all this?

thanks a lot @cjayb for taking a stab at this! It's very much appreciated. You did what I have been wanting to do for more than a year ;-) except with more principled discussions!

okay with ms and nAm as default units. As long as it's documented I'm fine with deviating from MNE-Python. I would not add any attributes to Dipole object for units. So just to clarify, if you want to get the original unscaled data in nAm, you would divide dpl.data by dpl.scaling?

Great! Where would you like to document it? I see you have an "Explanation" tab on autoreject, I think that might work nicely?
I actually propose to remove Dipole.units and document it's nAm. In cf21df7 I removed the scaling=-argument from the plotting functions I earlier added to. All that's left is a string argument that defaults to 'nAm'.
Now we still have and use the Dipole.scale method: this can be used to multiply with 1eN, i.e., changing the units, but then it's up to the user to adjust the plot units. Rather, scaling is useful for simulating a larger patch of cortex when comparing to empirical (source-localised) data.

dpl.scale(factor=1000, smooth=500, demean=True)

I find "smoothing" a semantically weird thing to include into scale. Demeaning should also occur before smoothing.
The problem with demeaning is that its behaviour is going to be data-dependent. If we go down this route, I think all our examples should have a baseline that can be subtracted. However, this also required the burn-in feature to be applied. I actually prefer this, for many reasons, though it will make the examples run a little longer.
I'm still on the fence over whether I prefer that over having to discuss why our pyramidal cells have 49 fAm running down them in the absence of synaptic input. BTW that value is likely (should?) change if channel densities are altered (Calcium dynamics), right?
For 0.1, how about:
def simulate_dipole(net, demean=True, scale=None, smooth=None):
    ...
    dpl.convert_fAm_to_nAm()  # Always
    dpl.demean()  # if demean=True
    dpl.scale(scale)  # scale is not None
    dpl.smooth(smooth)  # if smooth is not None
...

# in tests, using values in params:
dpl = simulate_dipole(net, demean=True, scale=params['dipole_scalefctr'], smooth=params['dipole_smooth_win'])

This doesn't address my concern about demeaning without baseline, though :( I'll try to make a commit with some moves in this direction, and see if I can visualise my concerns there.

Here's some code and the plots it produces to guide our discussion on what to do about 'normalisation'

Great! Where would you like to document it? I see you have an "Explanation" tab on autoreject, I think that might work nicely?

Maybe ... I think some tabs might get hidden if we go that route. I was thinking that just in the dipole object docstring? Also it will be evident when the user plots the data.

I actually propose to remove Dipole.units and document it's nAm.

agreed. I am not even sure if dipole.units is being used meaningfully anywhere.

but then it's up to the user to adjust the plot units.

this might lead to a unit mismatch if the user is not careful. I would even leave this param out. If the user really wants to do this, they can do plt.ylabel('pAm') and then any bugs in the code is not HNN's problem :)

I find "smoothing" a semantically weird thing to include into scale. Demeaning should also occur before smoothing.

right, any other name you can think of? I thought 'postproc' was too broad but maybe we can stick to it.

However, this also required the burn-in feature to be applied.

so you rather prefer that the user explicitly provides the 'burn in' period rather than determining it automatically? I could also live with:
dpl.postproc(burn_in=50, demean=True, scale=1e3, smooth=200):

maybe a burn_in = 'auto' would be nice? However, I do prefer to have this implemented in dipole class rather in simulate_dipole. If you want to change the smooth, you won't have to re-run the entire simulation which can be annoying.

I'm still on the fence over whether I prefer that over having to discuss why our pyramidal cells have 49 fAm running down them in the absence of synaptic input. BTW that value is likely (should?) change if channel densities are altered (Calcium dynamics), right?

I guess so? Is this a constant value across time or is there a dynamics too? I think a clear comment in the code will be enough for now. If you were a first year PhD student wanting to do some MEG source time course simulations with this cool-new tool called hnn-core, you probably don't want to be overwhelmed by too much info in the first tutorial.

Here's some code and the plots it produces to guide our discussion on what to do about 'normalisation'

I am a little confused with the scale of these plots. Is this shift meaningful when compared to simulated evoked. We could also totally save the results of the "blank" simulation, and fetch that data for the user and just subtract that. To avoid doing curve-fitting as was historically done. Looking through the emails, I guess that would work for L5? But for L2, there seems to be a slight slope in the curve.

I don't know why the mpi test hangs on CircleCI.
I've separated the baseline_renormalize-issue over to #270 , this PR will focus on getting the units-issue settled, and all the plotting routines cleaned up. Together these two would address #265

I don't know why the mpi test hangs on CircleCI.

are you sure it hangs? maybe it just needs longer to execute? You can make sphinx verbose here and see how far it goes?

Alright, review time! Note that I had to hack CircleCI to not use MPIBackend, which suddenly broke :(
I've used the alpha-example to demonstrate the new plotting methods and "post processing API".
This is the last hurdle before 0.1...

anything to update in whats_new.rst?

Did some work on making the visualisations more robust to different label widths and subplot combos (this is a great resource).
I made all the implicit post-processing stuff private, so we can easily remove them in the next round. Behaviour remains GUI-like (smoothing and scaling read from param-file by default).
Beginning to feel pretty done here...

Other than MPI issue, PR looks good to me. I'll give it a shot myself after lunch. Thanks @cjayb for the awesome PR as always!

@cjayb I left a few more comments. But let me know if you're too saturated with this PR, we can move those discussions elsewhere

All good merging. Thanks a lot @cjayb !! 🥳

Sweet!


.NET Data for Beginners - Intro to EF Core (video 2)

Describe the issue or suggestion
Child of https://github.com/dotnet/docs/issues/37021

Associated WorkItem - 275381

Closing -- Back Burnered


GH3978: Microsoft.Extensions.DependencyInjection to 6.0.1

fixes #3978

@devlead your changes have been merged, thanks for your contribution :+1:


Correct OSSL_sleep to support larger times for NonStop PUT model by introducing sleep().

This fix also removes SPT model support as it was previously deprecated. Upcoming threading models on the platform should be supportable without change to this method.
Fixes: #23923

This should contribute to #23925

merged

@nhorman How will we handle 3.2, 3.1, and 3.0? The OSSL_sleep defect is in all branches, but does not show up unless the tests hit that condition.

Well, we don't plan to backport RCU to any older branch (as it's a significant feature), so we're safe regarding this specific test.
That said, I agree it's a general defect that could use backporting, I just didn't want to hold up the 3.3 beta on it.  I would say just open a new issue requesting the backport from the original pr, and label it with openssl-3.2, 3.1 and 3.0.  if you assign it to me I can handle the cherry picks in the next week or so

Well, we don't plan to backport RCU to any older branch (as it's a significant feature), so we're safe regarding this specific test.
That said, I agree it's a general defect that could use backporting, I just didn't want to hold up the 3.3 beta on it. I would say just open a new issue requesting the backport from the original pr, and label it with openssl-3.2, 3.1 and 3.0. if you assign it to me I can handle the cherry picks in the next week or so

Thanks. I have created issue #23961 but do not have permission to assign you to it.

I've got it, no worries


On adding a text filter, set input focus to allow immediate typing

Upon choosing a text filter to add, it would be useful to be able to immediately type into the text box rather than first having to click in it.

The CI build failed on submitting this pull request, but the failure appears unrelated to this pull request.
One test failed: flask_admin.tests.test_form_upload.test_image_upload_field

Looks like the new Pillow 3.0.0 introduced the bug. The error I get when I try to save images looks like this: "Invalid image: cannot identify image file <FileStorage: u'copyleft.tiff' ('image/tiff')>"
One option is to set Pillow in the requirements to 2.9.0, but I'm looking into another fix.

@jnga can you also bump filters.js version to 1.0.1 here?: https://github.com/flask-admin/flask-admin/blob/e8b1b6b5aca047a4f83d685686d2632ce6206233/flask_admin/templates/bootstrap3/admin/model/list.html#L197
and here: https://github.com/flask-admin/flask-admin/blob/e8b1b6b5aca047a4f83d685686d2632ce6206233/flask_admin/templates/bootstrap2/admin/model/list.html#L197

@jnga Looks like this was already added in https://github.com/flask-admin/flask-admin/pull/1015
Your change removes "addFilter" and prevents the filter field from getting added at all.
You might need to install the newest version of flask-admin?: pip install -e git+https://github.com/flask-admin/flask-admin.git@master#egg=flask-admin

@pawl Oops, I mistakenly dropped the addFilter line while trying to clean up my prior pull request #1063. I'll try the newer version, though--thanks very much.


Z-wave Network Failing to Communicate After Controller Upgrade to SDK 7.19.3

Is your problem within Home Assistant (Core or Z-Wave JS Integration)?
YES, BUT a Home Assistant developer has told me to come here
Is your problem within Z-Wave JS UI (formerly ZwaveJS2MQTT)?
NO, my problem is NOT within Z-Wave JS UI
Checklist

[X] I have checked the troubleshooting section and my problem is not described there.

[X] I have read the changelog and my problem was not mentioned there.

Describe the bug
What causes the bug?
Every 6-12 hours, the Zwave controller stops communicating with most (all?) nodes. It seems like some commands are still coming in, but no outbound communication works, and eventually no inbound communication works either. If I leave it long enough, the controller itself seems to lock up and Zwave JS US returns an "Controller is unable to transmit" error. It seems this ultimly locks up HA as well, trigger the watchdog to restart it (although this restart does not resolve the error since the controller is not power cycled in the process).
What do you observe?
I recently upgrade my Zooz ZAC93 controller to the latest firmware 1.20 (SDK 7.19.3). Ever since, the controller seems to cease communicating with nodes every 6-12 hours, requiring a full power cycle to restore it. It's possible this is an issue with the new firmware, but I wanted to check here first to see if it might have something to do with the new SDK version and Zwave-JS compatibility. You can view a side effect of the error in the following graph, where Awake nodes tick up indefinitely until the controller is rebooted:

What did you expect to happen?
The controller to continues transmitting without error.
Steps to reproduce the behavior:

Reboot controller
Wait 6-12 hours
Observe behavior

Device information
Manufacturer: Zooz
Model name: ZAC93
Node ID in your network: 001
FW: 1.2
SDK: 7.19.3
How are you using node-zwave-js?

[X] zwave-js-ui (formerly zwavejs2mqtt) Docker image (latest)
[ ] zwave-js-ui (formerly zwavejs2mqtt) Docker image (dev)
[ ] zwave-js-ui (formerly zwavejs2mqtt) Docker manually built (please specify branches)
[ ] ioBroker.zwave2 adapter (please specify version)
[ ] HomeAssistant zwave_js integration  (please specify version)
[ ] pkg
[ ] node-red-contrib-zwave-js (please specify version, double click node to find out)
[ ] Manually built from GitHub (please specify branch)
[X] Other (please describe)

Which branches or versions?
I am running the Zwave JS UI add-on, version 1.16.0. I belive this was happening on the prior add-on version as well. This is running atop HAOS 10.5 running HA 2023.9.2.
node-zwave-js: 8.26.0
zwave-js-ui: 11.14.3
Did you change anything?
yes (please describe)
If yes, what did you change?
Upgrade controller to 1.2 FW (SDK: 7.19.3)
Did this work before?
Yes (please describe)
If yes, where did it work?
Seemed to be working fine on the 1.0 version of the controller firmware.
Attach Driver Logfile
The debug logs get really big when this issue is occuring, so I've tried to trim them down to the few minutes before/after it starts to occur. Let me know if you need different time versions, or if you want the full 500MB of logs (and that's just 1 day).
The issue seems to start occuring around 2023-09-22T00:03:07.761Z where the transmit status starts to fail.
zwavejs_2023-09-21.log

It's possible this is the same issue as #6260.

Yeah it is.


Group UI nodes based on workflow template ref

Summary
I was chatting with @mshatkhin23, and he mentioned that he'd like to have the workflow graph grouped based on the workflow template ref. Given this workflow snippet (using templates instead of refs here for simplicity):
- name: dag-tier-3
  dag:
    tasks:
      - name: task-1
        template: flakey-container
      - name: task-2
        depends: 'task-1'
        template: flakey-container
- name: dag-tier-2
  dag:
    tasks:
      - name: task-1
        template: dag-tier-3
      - name: task-2
        depends: 'task-1'
        template: dag-tier-3
- name: user-workflow
  dag:
    tasks:
      - name: task-1
        template: dag-tier-2
      - name: task-2
        depends: 'task-1'
        template: dag-tier-2

It produces the following graph:

We'd like to find a way to group or collapse things based on a given template. In the graph above, it's hard to know which task-1 is in user-workflow or dag-tier-2 or dag-tier-3. Ideally we:

collapse templateRefs from the start
adjust the display name so that the task name also includes which template is invoking it

Use Cases
This should help eliminate confusion when looking at the Argo Workflows graph. As workflows scale and orgs manage lots of templates, there will naturally be naming collisions that arise

Message from the maintainers:
Love this enhancement proposal? Give it a 👍. We prioritise the proposals with the most 👍.

Great idea

Thanks for posting @JPZ13 !
Small addition to adjust the display name so that the task name also includes which template is invoking it - it would also be nice to make tasks-in-dag-template (or steps-in-steps-template) relationships visually apparent, so that the developer can clearly discern between template levels.  Threw together some mock-ups below to illustrate what I mean (clearly I'm no designer 😅).  Definitely still some more thought needed around questions like how to discern between parallel tasks and template-levels, but I think you get the idea.

@mshatkhin23 I love the idea.
Also any other idea/suggestion that will allow easy rendering of big or huge workflows.
If it can be based on a state (like Failed or Error) or by label/template (inner template not templateRef).

Hey everyone!
I think that the option to group the graph is amazing! I think that grouping by template is only one option but if we go to that direction we should allow a more generic way to group.
Here's an example of a "complex" workflow that can be presented a 3 groups:
(imagine how more complex it can be if we had 15 test groups, and that the app update takes 5 jobs, and that we have 4 different layers of terraform)
- name: deployment
  dag:
    tasks:
     # First update infrastructure using terraform
      - name: terraform-plan
        template: terraform-plan
        group: infra

      - name: terraform-apply
        depends: 'task-1'
        template: terraform-apply
        group: infra

      # Then update app backend and frontend
      - name: update-backend
        depends: 'terraform-apply'
        template: argo-update
        group: app

     - name: update-cdn
        depends: update-backend
        template: update-cdn
        group: app

     # Then run validation
     - name: backend-e2e-A
        depends: update-backend
        template: backend-e2e
        arguments:
          parameters:
          - name: test_group
            value: "A"
        group: validation

     - name: backend-e2e-B
        depends: update-backend
        template: backend-e2e
        arguments:
          parameters:
          - name: test_group
            value: "B"
        group: validation

     - name: backend-e2e-C
        depends: update-backend
        template: backend-e2e
        arguments:
          parameters:
          - name: test_group
            value: "C"
        group: validation

     - name: frontend-tests
        depends: update-frontend
        template: frontend-tests
        group: validation

@or-shachar rly like the idea! Could we accomplish this through metadata labels/annotations you think? Although exposing as a top-level task/steps attribute does make things a bit cleaner.
We could maybe even have a group-based config field to expose style options? Although this would certainly just be a nice-to-have.  For example,
groupConfig:
    - name: infra
      value: '{"color": "red", "border": "blue"}'
    - name: app
      value: ...
...

Also do you imagine group to have a meaning other than UI grouping? (nothing obvious comes to mind)

Great Idea.

I'd be happy to handle this one

After taking a look on how to handle this issue, here is where I am at :

That could be nice to have 3 switchable distinct layouts

The existing one based on children props
A collapsing one, which would be the existing one but collapsed by templateRef

A grouping/collapsing one, based on templateRef and boundaryID which would be pretty similar to one required

The only drawback I found to handle this only working on the UI, is the missing link between step depending on an other one, represented here in red arrows on this image. We don't have this information at the moment.

If you have an insight on this matter that would be really helpful, otherwise, in my opinion it might already be a good step forward and I can start working on implementing that.


[C++][Parquet] PP] Do not return incorrect statistics

Implement PARQUET-251 and PARQUET-686 patches and prevent returning statistics for known bugs.
Reporter: Deepak Majeti / @majetideepak
Assignee: Deepak Majeti](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=mdeepak) / @majetideepak
Note: This issue was originally created as PARQUET-793. Please see the migration documentation for further details.

Deepak Majeti / @majetideepak:
PR: https://github.com/apache/parquet-cpp/pull/239

Wes McKinney / @wesm:
Issue resolved by pull request 239
https://github.com/apache/parquet-cpp/pull/239


shared storage on nfs article introduced

Fix #103 and #429

@shcheklein please have a look at the changes and let me know any other changes required.


Stochastic mipmap interpolation

Suggested by Luke Emrose, the idea here is that we introduce two new
MIP interpolation modes: StochasticTrilinear and StochasticAniso.
These work similarly to Trilinear and Aniso, respectively, except that
instead of sampling both of the bracketing MIP levels and blending
between them, in stochastic mode we use a random variate to select ONE
of the two MIP levels with probability proportional to the computed
blending weight.
If these mip modes are used, the caller needs to pass a
well-stratified value in the new "rnd" field of TextureOpt. Also note
that the method only really makes sense in the context of a renderer
that is using many samples per pixel. As a single texture lookup, it
looks horrible and noisy, as you can see by the testshade-based tests
we do of this, which are 1spp and looks pretty rough.
My benchmarks (in a hard stress test of the texture system using
testtex --threadtimes 8) show that this approach has speedups of
35-40% when using between 1-4 threads, dropping to more like 25-30%
speedup as threads are in the 12-32 range (that makes sense, it's
doing the same amount of total I/O).
In this first implementation, in order to preserve ABI compatibility
if we decide to backport this feature to the release branch,
TextureOpt::rnd is added as a union co-member with the unused "bias"
field. For TextureOptBatch, we had to add it outright, but it's
guarded by an #if and will not be backported to 2.3. (We may change
our minds and not backport it at all, I just wanted to leave the
option open with this initial patch. Also, there will probably be
additional further ABI-breaking changes coming later that will
definitely not be backported.)
In this first phase, we only use the stochastic component to turn the
2-MIP-level lookup into one level lookup.  It has been further
suggested that we could apply stochastic techniques to anisotropic
filtering (instead of many samples spaced across the major axis of the
filter footprint, take one sample distributed across the axis), and
even for the ordinary bilinear or bicubic within each level (instead
of 4 or 16 weighted texels, just retrieve one texel chosen with the
weights as probabilities). But these deserve to be benchmarked and
have their quality evaluated separtely and deliberately, and so will
be relegated to a later investigation and implementation.

I'm still in the middle of the OSL side. The simplest thing to do is to add a random variate to the shaderglobals. (Actually, maybe two because we are contemplating using them to stochastically choose closure nodes as well!) This is an ABI break, but maybe it's time for that.
Speaking of which, as I was in this code, I saw SO MANY OTHER THINGS to improve, many of which make me want to rearrange a lot about the TextureOpt struct. Do you think it's reasonable to just throw up our hands and say that all of this is going to be a 2.4 feature that has a number of things that change ABI and struct layout? Or should we bend over backwards (and not do it as cleanly) in the interest of allowing at least part of it to be backported to 2.3?

Speaking of which, as I was in this code, I saw SO MANY OTHER THINGS to improve, many of which make me want to rearrange a lot about the TextureOpt struct. Do you think it's reasonable to just throw up our hands and say that all of this is going to be a 2.4 feature that has a number of things that change ABI and struct layout? Or should we bend over backwards (and not do it as cleanly) in the interest of allowing at least part of it to be backported to 2.3?

It won't affect me as I'm still not using the mainline OSL anyway. Whatever you do I can adapt until our update. I'm sure other people would therefore have a stronger feeling on this.


fix(plugin-vue): handle null previous block during hot update

This is fixed in 8dbc2b4

This is fixed in 8dbc2b4


Drop "consume request on 401" behavior.

Resolves #11, #12.
Users wanting to help broken clients that aren't handling this properly
should explicitly opt into this behavior by configuring it in a reverse
proxy that implements it safely (see e.g.
http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size)
or in separate WSGI middleware.

I'm not comfortable dropping this altogether, as it might be a breaking change for some users, which could be triggered by something innocuous such as making a large post request or a file upload. From my own testing, without _consume_request, different wsgi servers have different limits on how much data would be consumed before disconnecting the client (usually in the MB range)
@mkomitee - do you have any more background on this? Was _consume_requests added because of issues you ran into in practice?
I'm inclined to just leave it as is - and if users are concerned about a DOS issue, the limit can be set in the wsgi/proxy server.

From the commit message:

Consume all data on a request before sending 401/403
This avoids problems that some clients have when they get an unexpected
and premature close from the server.
RFC2616: If an origin server receives a request that does not include an
Expect request-header field with the "100-continue" expectation, the
request includes a request body, and the server responds with a final
status code before reading the entire request body from the transport
connection, then the server SHOULD NOT CLOSE the transport connection until
it has read the entire request, or until the client closes the connection.
Otherwise, the client might not reliably receive the response message.
However, this requirement is not be construed as preventing a server from
defending itself against denial-of-service attacks, or from badly broken
client implementations.

I suspect I personally ran into client implementations which had this issue. The last bit:

However, this requirement is not be construed as preventing a server from
defending itself against denial-of-service attacks, or from badly broken
client implementations.

Makes me think we should allow the option to disable the behavior, but it ought to remain as is by default.

Sounds like we should continue with the approach in #15 then -- closing this.


Slack notification block not working

Description
This PR creates for solving the slack notification as the block is not working. I screenshot some images below.
Type of change

Bug fix (non-breaking change which fixes an issue)

Checklist

[x] My code follows the style guidelines of this project
[x] I ran ESLint and other linters for modified files
[x] I have performed a self-review of my own code and tested it
[x] I have commented my code, particularly in hard-to-understand areas
(including JSDoc for methods)
[x] My changes generate no new warnings
[] My code needed automated testing. I have added them (this is optional task)

Screenshots (if any)
Before change

After change

Hi @louislam - Could you please take a look at this PR?

I think the problem is here. https://github.com/louislam/uptime-kuma/blob/73fa6a1dee397f03a4d664f54624de93e909bda2/server/notification-providers/slack.js#L83-L96
This hasn't been updated to handle the new structure of data

@louislam Can you provide me the step to reproduce your issue? I will investigate it.

A simple slack notification
Down a HTTPS monitor

@Computroniks @louislam  Thanks for your cooperation.

TypeError: Cannot read properties of undefined (reading 'push')

Still not working. please be sure to test UP / DOWN notifications first.

@louislam I have tested both UP / DOWN. I realize that I forgot to loop through the attachment. In this case, We can do 2 ways

loop through attachments (I pick this one)
fix attachments[0] and push blocks inside


Display profile matching the one in git config

Fix #31
rename some variables to improve readability

@Shaokun-X thanks for the PR, your changes are merged to main - i am working few more changes, post that i will release the new version.


Make nested-trans-block exceptions nicer

Refs: https://github.com/python-babel/babel/issues/1049

Checklist:

[x] Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.
[ ] Add or update relevant docs, in the docs folder and in code.

Not relevant IMO.

[x] Add an entry in CHANGES.rst summarizing the change and linking to the issue.
[ ] Add .. versionchanged:: entries in any relevant code docs.

Not relevant IMO.

[x] Run pre-commit hooks and fix any issues.

There is an unrelated flake8 failure.

[x] Run pytest and tox, no tests failed.

Nice idea, thanks for making this error message clearer! I'm not sure when this will get merged in, but it's on the list.


Documentation is not clear at all

Are there built-in layers in this library? I want to use satellite tiles in my app.
Also, I can't find any examples of how to use map Props.

Hello,
I'm not the maintainer of this project but you can check the src/LeafletView/types.ts file. There is the definition of each type used by this project.
For your issue :

Add mapLayers prop to your LeaftelView and pass an array containing MapLayer structure.
In types.ts file, MapLayer structure is like this :

export interface MapLayer {
  attribution?: string;
  baseLayer?: boolean;
  baseLayerIsChecked?: boolean;
  baseLayerName?: string;
  bounds?: LatLngBounds;
  id?: string;
  layerType?: MapLayerType;
  opacity?: number;
  pane?: string;
  subLayer?: string;
  url?: string;
  zIndex?: number;
}

The result have to be something like this :

<LeafletView
mapLayers={[
{ url: 'https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png' }
]} />


Release azure-cli-container 0.1.1b3

Reviewers, please verify the following for this PR:

[ ] The PR title has format Release <component-name> <version>.
[ ] setup.py has been modified with the same version as in the PR title.
[ ] HISTORY.rst has been modified with appropriate release notes.
[ ] If releasing azure-cli or azure-cli-core, __version__ defined in __init__.py should also be modified to match.

Release of 'azure-cli-container' with version '0.1.1b3' successful. View at https://pypi.python.org/pypi/azure-cli-container/0.1.1b3.

GitHub release created. https://github.com/Azure/azure-cli/releases.


Selecting a nested subquery causes 'Record is not found' to be thrown

export function accounts() {
  return db.accounts.select("id", "publicKey", "name", "alias", "bio", "createdAt", "updatedAt", "lastSeenAt", "isVerified")
    .select({
      numPosts: q => db.posts.count().whereNotExists(db.commentsOnPosts, { commentId: "id" }).where(q.raw("posts.author_id = accounts.id")),
      numComments: q => db.posts.count().whereExists(db.commentsOnPosts, { commentId: "id" }).where(q.raw("posts.author_id = accounts.id")),
    });
}

const result = await db.posts.select({
  author: q => db.$from(accounts()).as("accounts_view").where(q.raw("accounts_view.id = posts.author_id")).take(),
});

    Record is not found

      at parseResult (../../node_modules/pqb/src/queryMethods/then.ts:238:38)
      at Object.numPosts (../../node_modules/pqb/src/queryMethods/select.ts:148:18)
      at parseRecord (../../node_modules/pqb/src/queryMethods/then.ts:257:31)
      at ../../node_modules/pqb/src/queryMethods/then.ts:191:36
          at Array.map (<anonymous>)
      at parseResult (../../node_modules/pqb/src/queryMethods/then.ts:191:23)
      at Object.author (../../node_modules/pqb/src/queryMethods/select.ts:148:18)
      at parseRecord (../../node_modules/pqb/src/queryMethods/then.ts:257:31)
      at ../../node_modules/pqb/src/queryMethods/then.ts:191:36
          at Array.map (<anonymous>)
      at parseResult (../../node_modules/pqb/src/queryMethods/then.ts:191:23)
      at Object.handleResult (../../node_modules/pqb/src/queryMethods/then.ts:51:10)
      at then (../../node_modules/pqb/src/queryMethods/then.ts:123:34)

The query produced for result after suffixing .log(true) however is correct.

The query builder has a method take which you have used for author sub-query, and this method ensures that the record was loaded, and will throw an error in case no record is found.
Here is my simplified example, the resulting type has a non-optional two, and query-builder must ensure that the actual result fully matches expectations:
type Result = Array<{ two: Two }>

const result: Result = db.one.select({
  two: () => db.two.take()
})

And if you expect sub query to not have results and it's okay for the use case, use takeOptional() instead:
type Result = Array<{ two?: Two }> // note the `?`

const result: Result = db.one.select({
  two: () => db.two.takeOptional()
})

So if this is the case it's not a bug and we can close it, but if you run the SQL and all records have author than it would be a bug.

I tried to use takeOptional() as well and it seems to throw the same error:
const result = await db.posts.select({
  author: q => db.$from(accounts()).as("accounts_view").where({ id: q.raw("posts.author_id") }).takeOptional(),
}).log(true);
console.log(result);

  ● Orchid ORM › should work

    Record is not found

      at parseResult (../../node_modules/pqb/src/queryMethods/then.ts:238:38)
      at Object.numPosts (../../node_modules/pqb/src/queryMethods/select.ts:148:18)
      at parseRecord (../../node_modules/pqb/src/queryMethods/then.ts:257:31)
      at parseResult (../../node_modules/pqb/src/queryMethods/then.ts:199:24)
      at Object.author (../../node_modules/pqb/src/queryMethods/select.ts:148:18)
      at parseRecord (../../node_modules/pqb/src/queryMethods/then.ts:257:31)
      at ../../node_modules/pqb/src/queryMethods/then.ts:191:36
          at Array.map (<anonymous>)
      at parseResult (../../node_modules/pqb/src/queryMethods/then.ts:191:23)
      at Object.handleResult (../../node_modules/pqb/src/queryMethods/then.ts:51:10)
      at then (../../node_modules/pqb/src/queryMethods/then.ts:123:34)

I double-checked in the database on how many entries may not have author:
# select count(*) from posts where not exists(select * from accounts where accounts.id = posts.author_id);
 count
-------
     0
(1 row)

Thanks for finding it, I'll fix

Published a fix for this.
By the way, there is a shorter form for where().take() - findBy:
// throw if not found
.findBy({ id: q.raw("posts.author_id") }),

// undefined if not found
.findByOptional({ id: q.raw("posts.author_id") }),


Add a basic gasp table to improve font rendering (bug 1769884)

See https://docs.microsoft.com/en-us/typography/opentype/spec/gasp

I mostly want to see what sort of effect, if any, this has across the test-suite.
/botio browsertest

Maybe we could use this gasp table only when hinting is missing. Do we have a way to detect such a situation ?

/botio browsertest

I played with the behavior flag and issue13130.pdf.
I see some real differences on my old DELL screen (U2415).
Here is what I see:
With your patch

Without

The same pdf but in Edge

and in Acrobat

So with your patch some curves are very thin (see the bottom, in the round part, e,p or c).
And I checked the pdf in https://bugzilla.mozilla.org/show_bug.cgi?id=1769884 and there is a real improvement.
I wonder if we should have different flags for different ranges.
I noticed that the gasp table isn't in the list:
https://github.com/mozilla/pdf.js/blob/master/src/core/fonts.js#L1220
and I was wondering if we correctly add it when it's present in the font.


feat(mapping): select - add size mapping

@nnixaa that’s what better to discuss. Because we don’t have this sizes in Input


Spotify player shouldn't load until GDPR consent

Spotify player has it's own tracking built in from Spotify and therefore should be blocked until consent granted.

Actually this won't matter because it will only happen for a logged in user


Nesting of Nodes DOES NOT WORK

Hi,
I was in love with this library until i hit this issue. :( I hope you could help me get this resolved.
I have a node that is both draggable and droppable.
I render two nodes into the playground like so
{nodes.map(node => {
return ;
})}
The issues with this approach.

Nodes do not drag smoothly - They flicker when we drag
The node 1 goes under node 2 when dragged over. Both have same z-index. Node 2 goes over node 1 correctly
The over property is null when node 2 is dropped over node 1. This is critical information to establish parent child relationship for nesting.
isOver from both Draggable and Droppable is not working as expected. They are false even when the node is dragged over.

Codesandbox - https://codesandbox.io/s/laughing-roentgen-6jopj
PS: In console log you can see the messages.

I don't really understand your use-case well, but from what I understand, these are all issues related to not using the library correctly:

Nodes do not drag smoothly - They flicker when we drag

This is because you added a transition on your nodes for transform:
.node {
  transition: transform 250ms ease;
}

The node 1 goes under node 2 when dragged over. Both have same z-index. Node 2 goes over node 1 correctly

The library does manage z-index for you, it's up to the consumer to manage z-index properly.

The over property is null when node 2 is dropped over node 1. This is critical information to establish parent child relationship for nesting.
isOver from both Draggable and Droppable is not working as expected. They are false even when the node is dragged over.

This is because you are rendering all of the contents of your Background component within a nested <DndContext> provider, so when you are dragging a Node component there are no other droppable areas within the context provider where those nodes are rendered, which explains why over is null.

Hi,
It does not work even if I remove the nested dnd-context. Over is still null.
Actually when I drop it, over is null. After dropping node 2 in node 1, if I just click on the handle without moving it. The over gets populated. It should definitely be a bug.


Crash in HeaderParser in dicer

Installed package<EMAIL_ADDRESS>which has dependency upon dicer "^0.3.0".
GitHub Advisory has notified me regarding the Crash in HeaderParser in dicer with High severity status.
Please help me fix this security issue.

Hi team, this issue seems to be critical as the dicer package hasn't had a patch fixing it:

"…affects all versions of package dicer."
Running "npm audit report" for me yields:
Severity: high
Crash in HeaderParser in dicer - https://github.com/advisories/GHSA-wm7h-9275-46v2
fix available via `npm audit fix --force`
Will install<EMAIL_ADDRESS>which is a breaking change
node_modules/dicer
  busboy  <=0.3.1
  Depends on vulnerable versions of dicer
  node_modules/busboy
    @apollographql/graphql-upload-8-fork  *
    Depends on vulnerable versions of busboy
    node_modules/@apollographql/graphql-upload-8-fork
      apollo-server-core  2.21.0-alpha.0 - 2.25.4
      Depends on vulnerable versions of @apollographql/graphql-upload-8-fork
      node_modules/apollo-server-core
        apollo-server-express  2.0.1 || 2.21.0-alpha.0 - 2.25.4
        Depends on vulnerable versions of apollo-server-core
        node_modules/apollo-server-express
          @vue/cli-ui  >=5.0.0-alpha.0
          Depends on vulnerable versions of apollo-server-express
          node_modules/@vue/cli-ui
            @vue/cli  >=5.0.0-alpha.0
            Depends on vulnerable versions of @vue/cli-ui
            node_modules/@vue/cli
  firebase-admin  >=7.1.0
  Depends on vulnerable versions of dicer
  node_modules/firebase-admin
    firebase-functions  >=3.0.0
    Depends on vulnerable versions of firebase-admin
    node_modules/firebase-functions

9 high severity vulnerabilities

To address all issues (including breaking changes), run:
  npm audit fix --force```

It seems it will be not fixed in dicer: https://github.com/mscdex/dicer/pull/22
However, a fix is on going in multer https://github.com/expressjs/multer/pull/1097

Duplicate of #1512

Duplicate of #1512

FYI, that issue was opened Dec 4, 2021

Please see my reply to https://github.com/firebase/firebase-admin-node/issues/1718#issuecomment-1137874274
The Admin Node.js SDK uses dicer to parse multipart responses from Firebase APIs so the risk here is pretty minimal. However, I agree that it would be great to address this properly. We are currently looking into the available options.
I am going to close this issue as we will continue to track this in #1718. Thanks everyone.

Is there any workaround available guys ?


Template: Adds 'characters' filter (similar to sentences)

Adds a 'characters' filter, where the input string is truncated
by limit characters, rounded up to nearest space (' ') and
extended with extension (default ' [...]').

Signed-off-by: Øystein Blixhavn<EMAIL_ADDRESS>

Well, which component names are recognized?


HostDB normalization and latency throughput metrics for host

@DavidVorick to elaborate

@DavidVorick what are your thoughts on what I wrote up?
Is that the scope of the issue as you saw it?
Are there other host metrics that you think the renter can negatively influence?

Option 2 is not really possible. Each renter has to be able to figure that out itself without relying on a separate hostdb.
Option 1 probably needs more elaboration on how we can do that. We need to find some average/threshold that determines a good number for hosts that haven't been scanned yet while still being performant. The functionality should also be contained within the hostdb which means we can't put it into managedMarkContractsUtility' which I think is called within the contractor's threadedContractMaintenance`.
I would also move the latency throughput metrics to a different PR since they are not strongly related to the normalization of the hostdb.
Something we should also normalize is the ratio between failed and successful host interactions. I guess that can be done with minimal overhead once we have figured out how to do it for uptime.

OK so Option 2 is out, didn't think it was possible, just wanted to check and see.

Option 1 probably needs more elaboration on how we can do that. We need to find some average/threshold that determines a good number for hosts that haven't been scanned yet while still being performant.

Would it make sense to use 50?  That way the renter would scan the hosts it currently has contracts with  or if no contracts, 50 host.

The functionality should also be contained within the hostdb which means we can't put it into managedMarkContractsUtility' which I think is called within the contractor'sthreadedContractMaintenance`.

Makes sense, but could we export it?  I'm just thinking about how it gets triggered.  Would it make sense for this to be some sort on real time normalization or should it be a triggered event to course correct?
Could we even do it in real time?  It seems like it would be a convoluted process of keeping track of the current host and pulling new hosts from the hostdb since all the functions in scan.go are looking at a single host.  It seems it would be more streamline if it was a triggered event that could then do some course correction on the host weights.

What I originally had in mind was just keeping track of all of the scans that we performed at all, and then tracking what percentage of those were successful. In general we are going to spend more time scanning hosts that are online than we are hosts that are offline.
Scans that wouldn't contribute to the total number would be scans of hosts which we've never seen online before, and scans of hosts that were never seen as online again (meaning starting from one bad scan, they are just offline from that point forward)

Hosts that we've never scanned before wouldn't have a score at all, they would be in the queue to be scanned immediately so that we could get a baseline for the hosts.

This is happening to me and my uptime is being trashed just for participating.


Clin var reload fix

Prevents the re-rendering of variant tracks when optianalTracks menu is close, check if data changed in a meaningful way when updating variant-viz

quarantest build successful. Demo link at
http://aecf63fd.quarantest.iobio.io

quarantest build successful. Demo link at
http://1cc8b2ca.quarantest.iobio.io

Available for final testing at http://1cc8b2ca.quarantest.iobio.io
To test - validate that tracks are no-longer re-rendered when the clinVar track is selected, or when optional tracks menu is closed.

quarantest build successful. Demo link at
http://dd2ead3d.quarantest.iobio.io


MAINT: disable codecov

@agoose77 - codecov fix is in https://github.com/executablebooks/jupyter-cache/pull/127

@bsipocz the actual upload fails (and seems to be a problem across lots of repos). I tried bare #127 alone, but it didn't resolve that problem (as it's with the action itself).
My battery level for "putting up with annoying breakages in nice-to-have CI" is fairly low, so for this release I'm turning off codecov. We should try and get it working across EB once that's done.


Small issue with the delete command

Small logical error, when amount is 2 bot still displays 'Can't delete less than 2 messages.' message.

seems like the cli failed to install the new activesupport version

I fixed this in master. Thanks for the PR.


Fix undefined date created

Issue

Close #107

Description

Change dateCreated to createdAt for consistency between jobs and projects page
Add createdAt in query

Screenshots

Before

After

looks ok to me, i will be focusing now on ltm and the paying cash feature, so won't be able to spend as much time on swarmerAI for a while

are you the only one working on this right now?

@jinlee8502
I see. I'll be working with paul and JC but just wanted to confirm if my first PRs are good.


don't work with RTL languages.

Hello , I loved the mod and I hope to fix this problem the language I'm using is Arabic and I also use an Arabic fix plugin in the server thank you.

It works for me. Could you send me a sample text which isn't working for you?
Is your problem while sending or receiving messages? Or both?
And does it work normally with minecraft, like if you write a normal chat message?

I'm going to close this issue because it's been a month and you haven't responded. If you are down to reply anytime just reopen it.


Fix error when trying to load nonexistent template

This makes sure that there is an error message printed when trying to use a template that doesn't exist and makes sure that no unhandled exceptions occur.
Fixes #10

This also fixes #7