How to replace a failed OSD with BlueStore the "ceph-ansible" way

Hi, i have a 160 OSD ceph Luminous deploy with Bluestore made with Ceph-Ansible.
the osd.yml is defined as follow.
devices:

/dev/sdb
/dev/sdc
/dev/sdd
/dev/sde
/dev/sdf
/dev/sdg
/dev/sdh
/dev/sdi
/dev/sdj
/dev/sdk
/dev/sdl
/dev/sdm
/dev/sdn
/dev/sdo
/dev/sdp
/dev/sdq
/dev/sdr
/dev/sds
/dev/sdt
/dev/sdu
/dev/sdv
/dev/sdw
/dev/sdx

dedicated_devices:

/dev/sdb
/dev/sdc
/dev/sdd
/dev/sde
/dev/sdf
/dev/nvme0n1
/dev/nvme1n1
/dev/nvme0n1
/dev/nvme1n1
/dev/nvme0n1
/dev/nvme1n1
/dev/nvme0n1
/dev/nvme1n1
/dev/nvme0n1
/dev/nvme1n1
/dev/nvme0n1
/dev/nvme1n1
/dev/nvme0n1
/dev/nvme1n1
/dev/nvme0n1
/dev/nvme1n1
/dev/nvme0n1
/dev/nvme1n1

bluestore_wal_devices:

/dev/sdb
/dev/sdc
/dev/sdd
/dev/sde
/dev/sdf
/dev/nvme0n1
/dev/nvme1n1
/dev/nvme0n1
/dev/nvme1n1
/dev/nvme0n1
/dev/nvme1n1
/dev/nvme0n1
/dev/nvme1n1
/dev/nvme0n1
/dev/nvme1n1
/dev/nvme0n1
/dev/nvme1n1
/dev/nvme0n1
/dev/nvme1n1
/dev/nvme0n1
/dev/nvme1n1
/dev/nvme0n1
/dev/nvme1n1

As you can see, all OSD have block.wal and block.db on nvme (the first ones are SSD, so they have those into their own disks, the rest are SATA and SAS).
Device sdx failed on one of the nodes (OSD # 104)
I was thnking about doing a "ceph crush reweight" until 0% then bringing down the OSD daemon to how-swap it.
After that, who can please tell me what's the best practice to re-add the OSD to the cluster using ceph-ansible again ?
Much apreciate it.

hi guys, any help ?
this is really important for me to know, since i dont want that when starting to do normal maintenance, things wont break by the time i need to add new resources.
best.

Hi, should i do this http://docs.ceph.com/docs/master/rados/operations/add-or-rm-osds/#replacing-an-osd and not worring about later ceph-ansible runs ?
anyone ?

@acomisario yes please follow the doc you mentioned and don't worry about ceph-ansible new runs. We could actually build a playbook to replace a disk, I'm just not sure if this is needed due to the fact you only have a single command to type.
I might have a quick prototype for this soon.

@leseb thanks for the reply.
In my case what im using right now on that OSD is this :
root@ndc-cl-osd4:~# ls -lsah /var/lib/ceph/osd/ceph-104
total 64K
0 drwxr-xr-x  2 ceph ceph  310 Sep 21 10:56 .
4.0K drwxr-xr-x 25 ceph ceph 4.0K Sep 21 10:56 ..
0 lrwxrwxrwx  1 ceph ceph   58 Sep 21 10:30 block -> /dev/disk/by-partuuid/0ffa3ed7-169f-485c-9170-648ce656e9b1
0 lrwxrwxrwx  1 ceph ceph   58 Sep 21 10:30 block.db -> /dev/disk/by-partuuid/5873e2cb-3c26-4a7d-8ff1-1bc3e2d62e5a
0 lrwxrwxrwx  1 ceph ceph   58 Sep 21 10:30 block.wal -> /dev/disk/by-partuuid/aed9e5e4-c798-46b5-8243-e462e74f6485
block.db and block.wal are on two different NVME partitions, witch are nvme1n1p17 and nvme1n1p18 so assuming after hot swaping the device, the drive letter is "sdx" according to the link above what would be the right command to re-use the two NVME partitions for block db and wal ?
I presume that everything else is the same.
best.

Hope you got your response somehow sorry for not replying earlier.
I'm closing this.


error 400

Hello and thank you for this program,
Everything works except all Ajax with "/admin/" in the URL,
I can log in, create an account, change my password
but in backend i can do absolutely nothing
https://img15.hostingpics.net/pics/746102Capture.png
Thank you!

@S8N02 can you check the body of the response, there should be the detail of the error.

I see nothing in body reponse
https://img15.hostingpics.net/pics/492303Capture.png
I think the problem comes from my environment (Apache, Mysql, PHP 5/7)
Directives Apache : DocumentRoot "{DOCROOT}/public" but where ?
If I use the URL of the Ajax in my browser I have no problem of error 400

@S8N02 I think there is something wrong with your IIS's configuration, but I'm not familiar with Windows/IIS.

I guess your IIS cannot accept request which content-type is application/json, so only ajax requests result in http 400

i'm so sorry, i tested on another server less secure and your site works perfectly
it's Unix, apache 2.x my server
the information(IIS) you see is false thanks to an apache plugin, i think mod_security than poses problem
Sorry


Feature Request: Add Ligature Support

Would it be possible to add ligature support to this font? I think it would make the text look more polished and improve readability.

Hi @diantongren and @alxzh, can you clarify what kinds of ligatures you're looking for? Programming ligatures?

Yes, I'm referring to programming ligatures, which are special character combinations in programming fonts.

Hi, I was also looking for programming ligatures and made modifications to include some until official ones were released! You can find them in the ligatures folder here: Fork with Ligatures.

Hi Danica, thanks for taking a pass at this! If/when we get to programming ligatures, we'll be doing it in-house, but appreciate you kicking it off.
If you're open to some feedback/want to tinker further in the meantime, @rektdeckard and I put together some notes. There are a few things I'd address to stay in the spirit of Departure Mono: snapping each character to the pixel grid (7x14), maintaining the fixed pitch (monospace), and reviewing some inconsistency/legibility questions:

We'll follow up here with updates on official support!


hijack-stream-support: Initial import

Parent: https://github.com/giantswarm/cli/pull/209

I've split it up a bit more

This is a public library - we must add our license (currently Apache 2.0 for open projects) and should add a proper README with an example (and a use case).

Cool! LGTM.


Evaluate PostgreSQL Server as backend to use with ml-metadata

I have just learned that ml-metadata does put in support for PostgreSQL from the Kubeflow Summit presentation. We need to explore the solution and figure out what it takes to adapt to it.

@rareddy I was attending too and I guess you mean

When I follow link however
https://github.com/kubeflow/pipelines/issues/9813
I'm still a bit confused as from the tracker (at the time of writing) some work is still in flux

the speaker mentioned the feature was done, so we just need to experiment with it and figure out t can be used if not we can provide the feedback in the community.

By the way, found this which is a bit more promising: https://github.com/google/ml-metadata/blob/de25304b6d123e3044b64be9ceaf979f61483fe5/RELEASE.md?plain=1#L20
Didn't found explicit documentation about it, so I'm planning to give it a try by just running data connection configuration and see what happens

@rareddy I have a demo ready with https://github.com/tarilabs/demo20231009-mlmdpg#readme
Assuming the following acceptance criteria for this GH issue:

[x] demonstrate ml-metadata Python library connects to PostgreSQL directly
[x] demonstrate ml-metadata Python library connects to ml-metadata server via gRPC, and for the ml-metadata server to connect to PostgreSQL

I would close this issue as resolved.
I can demo in a call if preferred.

/lgtm

👉 https://github.com/opendatahub-io/model-registry/issues/65#issuecomment-1761606779


Set up Project

[x] Create Project
[x] Add collaborators
[x] Configure status options
[x] Set up workflows
[x] Associate with repository
[x] Configure views

@ffund Please review our project!

@YingzhuoYang please add me as a collaborator on your project so that I have edit permissions there :)

I cannot review this because I haven't been added as a collaborator on the project (Project > Settings > Manage Access).

@ffund I just change the project permission from "read" to "Admin", could you try again, please?

@JerryWuZiJie Looks good, thanks.


added remaining links for ephemeral

Description
added remaining links for ephemeral
cc @karelhala
Fixes # (issue)
Type of change
What is it?

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Documentation update
[ ] Tests update

Checklist:

[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] I run npm run lint:js:fix to check that my code is properly formatted

@karelhala I believe so

@resoluteCoder good! Let's just keep that in mind.


intellij always executes StringSpec tests

I have a non kotlin-test unit test (junit 5) that I'm trying to run with ctrl+shift+r. When that runs a StringSpec test that I have also executes. This is unexpected. It seems that the test runner in intellij always picks it up.
Given these two tests.
import io.kotlintest.specs.StringSpec

class FooTest : StringSpec({
    "should_not_run" {
        println("but it does")
    }
})

import org.junit.jupiter.api.Test

class BarTest {
    @Test
    fun shouldOnlyRunThis() {
        println("test")
    }
}

When I run shouldOnlyRunThis with ctrl+shift+r, FooTest (and any StringSpec tests) also execute.

What versions of junit, intellij, and kotlintest are you using in your build so I can duplicate.

Gradle 4.8 wrapper, intellij 2018.1.5, testCompile "io.kotlintest:kotlintest-runner-junit5:3.1.6"

Yes confirmed. It seems to run all StringSpec tests in the project when you run the test method but not when you run the class.

Thanks, fixed in master. I'll be releasing 3.1.8 shortly.


Not supported on Task scheduler 1.0

Hi dahall and everyone,
I have a problem when used this task scheduler .  When I develop in windows 7 everything works successful , but when I develop my application in windows XP, application throw new exeception : " MonPropScheduleSystem.CreateFirstSchedule is not supported on Task Scheduler 1.0 "
MonPropScheduleSystem is class library and CreateFirstSchedule is method
this full code :
public static void CreateFirstSchedule(String PathInstallation)
{
try
{
using (TaskService ts = new TaskService())
{
using (Task t = ts.GetTask(_firstScheduleSystemName))
{
if (t == null)
{
TaskDefinition td = ts.NewTask();
td.RegistrationInfo.Description = "This is for Automate Daily Sending Email to other account";
td.RegistrationInfo.Author = "MonProp";
td.Principal.RunLevel = TaskRunLevel.Highest;
                            MonthlyTrigger mTrigger = (MonthlyTrigger)td.Triggers.Add(new MonthlyTrigger());
                            mTrigger.DaysOfMonth = new int[] { 1, 15, 28 };
                            mTrigger.StartBoundary = DateTime.Today.AddHours(8);
                            mTrigger.RandomDelay = TimeSpan.FromHours(3);

                            String InstalltionPath = PathInstallation.Remove(PathInstallation.Length - 1, 1) + "MonProp.Utilities.exe";
                            td.Actions.Add(new ExecAction(InstalltionPath, "-d -n", null));

                            const string taskName = _firstScheduleSystemName;
                            ts.RootFolder.RegisterTaskDefinition(taskName, td, TaskCreation.CreateOrUpdate, "SYSTEM", null, TaskLogonType.ServiceAccount, null);
                        }
                    }
                }
            }
            catch (Exception ex)
            {

                throw ex;
            }
        }

any ideas?
Thank you..
Originally posted: 2012-01-21T04:28:09

td.Principal.RunLevel and mTrigger.RandomDelay are not supported on systems prior to Vista. See the Examples Page link under the Documentation tab for the "complex example". It will show you how to detect the version of the Task Scheduler and only call those properties when they are supported.
Originally posted: 2012-01-21T10:25:17

dahall wrote:
td.Principal.RunLevel and mTrigger.RandomDelay are not supported on systems prior to Vista. See the Examples Page link under the Documentation tab for the "complex example". It will show you how to detect the version of the Task Scheduler and only call those  properties when they are supported.

Thank for your explanation.. Now, my problem already fixed..
Thank you.. :D
Originally posted: 2012-01-21T18:46:33


How to change startup mode from insert to normal?

When I call the rename command, the pop-up window for renaming opens in insert mode.
Quite often I just have to go to the letter and replace it to fix the typo. In insert mode, using the arrows is very inconvenient.
How to change the mode to normal when a pop-up window appears?
I use this plugin with LazyVim with default config:
https://www.lazyvim.org/extras/editor/inc-rename

Currently, I don't think this is possible since the command preview feature of Neovim that inc-rename uses, only works in command line mode. So you are actually in command line mode the whole time, not insert mode. Maybe it is possible to navigate in the noice.nvim window? Not sure

Agreed. It would be great if the pop-up supports normal and insert mode, with config of what the default mode is

i need block all text by default, so the text can be replaced faster

i need block all text by default, so the text can be replaced faster

That's impossible to achieve currently as the command preview only works in command line mode.


OffCanvas menu -webkit- prefixes in Safari

Hi,
Been using FoundationPress for a while, no issues at all. However I tested the Offcanvas menu in Safari today (both 5.1 via Windows & 10.9 in OSX), and the menu wasn't popping out, the opacity was changing but no transformation.
I tested this on a fresh build (2.61).
I noticed something though, the class:
.is-open-left {     -ms-transform: translateX(250px);     transform: translateX(250px); }
It's missing the transform property with the -webkit- therefore changing to:
.is-open-left {     -ms-transform: translateX(250px);     -webkit-transform: translateX(250px);     transform: translateX(250px); }
Get's it working again. This seems to have occurred with a lot of the transition properties in similar classes, (transition etc.) I checked the latest build of Foundation and it has the latter -webkit- prefix, (http://foundation.zurb.com/) I believe that it might just be me, I'm wondering about the prefix assignment which happens in the Sass task? I've been looking here and I'm unable to find any resolution, or why the npm module might not be working? All other Sass, watch and package tasks work fine.

Just seen an issue raised a couple of days ago that covers what I'm referring to exactly:

Therefore this is redundant.


CUDA error: an illegal memory access was encountered

Describe the bug
First of all - thank you for a great project
I installed this repo on the nvcr.io/nvidia/pytorch:20.10-py3 image (together with all prerequisites).
I'm trying to convert the LVIS model from mmdetection (https://github.com/open-mmlab/mmdetection/blob/master/configs/lvis/mask_rcnn_r101_fpn_sample1e-3_mstrain_1x_lvis_v1.py).
The conversion process seems to go OK, but when I try to do inference I get RuntimeError: CUDA error: an illegal memory access was encountered when accessing the result tensors.
I tried both with and without mask support.
Please let me know if I'm doing something wrong.. Thanks again!
To Reproduce
Convert model using this command line:
mmdet2trt --fp16 1 --enable-mask 0 --save-engine 1 --max-workspace-gb 4 \
mask_rcnn_r101_fpn_sample1e-3_mstrain_1x_lvis_v1.py \
mask_rcnn_r101_fpn_sample1e-3_mstrain_1x_lvis_v1-ec55ce32.pth \
faster_rcnn_r101_lvis

Inference code:
import mmdet2trt.apis
import mmdet.apis
import imageio
from skimage.transform import resize

config_path = 'mask_rcnn_r101_fpn_sample1e-3_mstrain_1x_lvis_v1.py'
chekpoint_path = 'mask_rcnn_r101_fpn_sample1e-3_mstrain_1x_lvis_v1-ec55ce32.pth'

img = imageio.imread('test_image_1.jpg')
img = resize(img, (800, 1333), order=1, anti_aliasing=True, preserve_range=True)

mmdet_model = mmdet.apis.init_detector(config_path, chekpoint_path, 'cuda:0')

mmdet_res = mmdet.apis.inference_detector(mmdet_model, img)

trt_model = mmdet2trt.apis.init_detector('faster_rcnn_r101_lvis')

trt_res = mmdet2trt.apis.inference_detector(trt_model, img, config_path, 'cuda:0')

enviroment:

OS: [e.g. Ubuntu]
python_version: 3.6
pytorch_version: 1.7
cuda_version: 11.1
cudnn_version: [e.g. <IP_ADDRESS>]
mmdetection_version: 2.6.0

Additional context
Add any other context about the problem here.

Hi,
Thanks for the bug report. There are some problems on cuda(or nvidia driver) 11.1. I will fix it after my business trip.
Please try on another docker with cuda11 or 10.2.

hi, Grimoire:
I had also meet a same issue. Model can be converted, but Inference Error using mmdetection-to-tensorrt/demo/inference.py to process  https://github.com/open-mmlab/mmdetection/tree/master/configs/faster_rcnn/faster_rcnn_r50_caffe_fpn_1x_coco.py.
My enviroment:
OS: [e.g. Ubuntu 16.04]
python_version: 3.7
pytorch_version: 1.8
cuda_version: 11.0
cudnn_version: [e.g. <IP_ADDRESS>]
mmdetection_version: 2.7.0
Driver_version: 450.57 (Is it must < 450.36??)
Thank you.

@buaalingming
Inference can be performed inside docker (even with host driver 455). You can use a docker with cuda10.2 for now.
I am trying to fix this. Please allow me some time.

@grimoire
hi, Grimoire:
I have tried your docker, Yes,  it works very well.
And i was debuging my enviroment for a long time, and i  have found something:

The key cause is pytorch and  torchvision Version.  torch==1.7.0+torchvision==0.8.1 will lead to that bug, and torch==1.6.0+torchvision==0.7.0 is fine.

The detail error info is :"
[TensorRT] ERROR: ../rtSafe/cuda/cudaConvolutionRunner.cpp (483) - Cudnn Error in executeConv: 8 (CUDNN_STATUS_EXECUTION_FAILED)
[TensorRT] ERROR: FAILED_EXECUTION: std::exception "

I hope my discovery can help you and I am Looking forward to your good news.
Thank you.
@davidas1 ：
hi, Davidas1:
You can try torch==1.6.0+torchvision==0.7.0. It may help you.

@buaalingming Thanks! That would be helpful!


Firebase & Firestore Plugins

Hello 👋

Just read this and would appreciate to know how far along the Firebase/Firestore plugins are.
Can you shed light on how it will work and if it will support both Firebase JS SDK on web (v8 and/or v9) and react-native-firebase on the native side?
Keep up the good work, you’re legends 😁

We have a Firebase Realtime Database plugin that we use for the sync system in Bravely and will use in Legend soon, but it's still in active development and not quite cleaned up for everyone to use.
It has a lot of complexity with offline caching, supporting saving/querying by timestamp, automatically shortening field names to a single character, etc... I'm not sure how much of that would be applicable to most developers, so we may want to remove some of the complexity for the open source version to be more approachable? Or otherwise it needs more cleaning up to make friendlier.
If a lot of people are interested in it, we could try to prioritize open sourcing it in its current (or slightly more cleaned up) state.
If you're able to share, it would be helpful to know how you generally structure your Firebase data so that the plugin can be more general purpose
The Firestore one is only a plan at this point. Maybe once we open up the Firebase plugin someone could make a similar plugin for Firestore?
And it does support both the JS SDK and react-native-firebase. It has a setFunctions to pass in the basic functions it uses. It's designed around the v9 api but you could probably massage the v8 api into it to make it work.

Would really appreciate this update!

Just a quick status update: the firebase plugin is close to complete but heavily in flux as Bravely is getting close to a release. Some of the recent updates here to persistObservable and the new trackHistory feature were built for that. Once we finish the Bravely release, we'll do a bit of cleanup and move it into this repo :). Hopefully that will be within a couple of weeks.

Just a quick status update: the firebase plugin is close to complete but heavily in flux as Bravely is getting close to a release. Some of the recent updates here to persistObservable and the new trackHistory feature were built for that. Once we finish the Bravely release, we'll do a bit of cleanup and move the firebase sync plugin into this repo :). Hopefully that will be within a couple of weeks.

Can't wait to try it out. Thanks.

would love to try it any soon

The trackHistory feature sounds interesting, how are you guys handling the diffs? Maybe porting that feature over first may be a good first step?

@raymonddaikon trackHistory is already available (docs). And it's actually pretty simple (source).
I should probably update about the Firebase plugin as it's been a while! We're focused now on releasing the update to Legend that uses the new sync system, then we'll clean up and document the plugin and release it here. I'm hoping that should be within the next few weeks.

Awesome! Looking forward to seeing how you guys are handling crdt, I'm currently manually creating diff patches with jsondiffpatch and patching/unpatching my state tree to go through the undo and redo stack


Expose AuthContext in C#

Expose C core's auth context in C#, ready for initial review.
@jboeuf  for general sanity
@apolcyn  for C#
@nathanielmanistaatgoogle  FYI

@apolcyn  this should be ready for review.

I believe I've addressed/answered all comments.
Also rebased against the latest master and added a note that AuthContext/AuthProperty api is experimental for now (so we have a bit of freedom to make adjustments to the API if needed).
Btw, master now has a high-level doc about server side auth (docs/server_side_auth.md)
PTAL.

Known failures:

https://github.com/grpc/grpc/issues/9399
https://github.com/grpc/grpc/issues/9956

@dgquintas  FYI I'd like to merge this one before cutting the 1.2.x release branch.

@jtattermusch in that case add the "release blocker" label


feat: Use service workers to precache sounds

Works in Chrome. Firefox compatibility seems not right but we can fix that later.


ssh: add support for extension negotiation (rfc 8308)

This adds support for SSH extension negotiation via SSH_MSG_EXT_INFO as defined in RFC 8308 [1]. It also adds support for the server-sig-algs extension on both the client and server sides.
[1] https://datatracker.ietf.org/doc/html/rfc8308
Fixes golang/go#49269

This PR isn't ready for merging yet! I created the PR to get some initial feedback to see if the direction it's going is appropriate or if there are larger changes that need to be handled. I have a number of // TODO(kxd) comments where I called out specific questions I was hoping to get upstream feedback on as well!

Hi @aphistic, I tried your changes along with the recently merged support for SHA2 signatures for RSA host keys (commit: b4de73f9ece8163b492578e101e4ef8923ac2c5c). Both my OpenSSH 8.8 client and Go SSH server seemed happy about it.
It looks like @FiloSottile is marked as the sole Gerrit reviewer... Perhaps another Go maintainer CC'ed on the change (such as @agl) can take a look and offer feedback about this implementation?

Hey @stephen-fox! Those are the same changes we're running prod now, so it's good to hear it's working for you!
With regard to the review, I talked with @FiloSottile on the Gopher Slack about this PR and the next steps are to document the public changes to the API that I'd like to propose as part of merging this upstream. The code right now is not ready for merging and I think the public API for configuring extensions isn't correct, so this is definitely something that needs to happen first. I haven't had a chance to do this documentation yet, though, but I will redouble my efforts once I'm back in the office on Monday!.

Ah, I didn't realize there is a slack! And no worries - thank you for implementing this feature. I look forward to using it once it is merged :)

This adds support for SSH extension negotiation via SSH_MSG_EXT_INFO as defined in RFC 8308 [1]. It also adds support for the server-sig-algs extension on both the client and server sides.
[1] https://datatracker.ietf.org/doc/html/rfc8308
Fixes golang/go#49269

https://www.cryptocaptrades.com

This PR isn't ready for merging yet! I created the PR to get some initial feedback to see if the direction it's going is appropriate or if there are larger changes that need to be handled. I have a number of // TODO(kxd) comments where I called out specific questions I was hoping to get upstream feedback on as well!
The client side of server-sig-algs isn't implemented yet because I wanted to have a discussion about how that should integrate into choosing a pubkey auth algorithm.

https://www.cryptocaptrades.com

This PR (HEAD: 29bf9ec) has been imported to Gerrit for code review.
Please visit https://go-review.googlesource.com/c/crypto/+/360195 to see it.
Tip: You can toggle comments from me using the comments slash command (e.g. /comments off) See the Wiki page for more info

https://www.cryptocaptrades.com

Message from Go Bot:
Patch Set 1:
Congratulations on opening your first change. Thank you for your contribution!
Next steps: A maintainer will review your change and provide feedback. See https://golang.org/doc/contribute.html#review for more info and tips to get your patch through code review.
Most changes in the Go project go through a few rounds of revision. This can be surprising to people new to the project. The careful, iterative review process is our way of helping mentor contributors and ensuring that their contributions have a lasting impact.
During May-July and Nov-Jan the Go project is in a code freeze, during which little code gets reviewed or merged. If a reviewer responds with a comment like R=go1.11 or adds a tag like "wait-release", it means that this CL will be reviewed as part of the next development cycle. See https://golang.org/s/release for more details.
Please don’t reply on this GitHub thread. Visit golang.org/cl/360195. After addressing review feedback, remember to publish your drafts!

https://www.cryptocaptrades.com

Message from Kristin Davidson:
Patch Set 1:
(1 comment)
Please don’t reply on this GitHub thread. Visit golang.org/cl/360195. After addressing review feedback, remember to publish your drafts!

https://www.cryptocaptrades.com

Hi @aphistic, I tried your changes along with the recently merged support for SHA2 signatures for RSA host keys (commit: b4de73f). Both my OpenSSH 8.8 client and Go SSH server seemed happy about it.
It looks like @FiloSottile is marked as the sole Gerrit reviewer... Perhaps another Go maintainer CC'ed on the change (such as @agl) can take a look and offer feedback about this implementation?

https://www.cryptocaptrades.com

Hey @stephen-fox! Those are the same changes we're running prod now, so it's good to hear it's working for you!
With regard to the review, I talked with @FiloSottile on the Gopher Slack about this PR and the next steps are to document the public changes to the API that I'd like to propose as part of merging this upstream. The code right now is not ready for merging and I think the public API for configuring extensions isn't correct, so this is definitely something that needs to happen first. I haven't had a chance to do this documentation yet, though, but I will redouble my efforts once I'm back in the office on Monday!.

https://www.cryptocaptrades.com

Ah, I didn't realize there is a slack! And no worries - thank you for implementing this feature. I look forward to using it once it is merged :)

https://www.cryptocaptrades.com

With regard to the review, I talked with @FiloSottile on the Gopher Slack about this PR and the next steps are to document the public changes to the API that I'd like to propose as part of merging this upstream.

@aphistic FYI, managed to leverage your work for the ssh client signers without having to change the API: https://github.com/rmohr/crypto/commit/e4ed9664ac545e290a287dc913e01b6939c837ea. Maybe it is helpful when looking into  the API changes.

👋 what is the status of this PR? Could it be merged?

AFAIK it's not complete. It does not, for example wire in the negotiation extension to the client (only the server). There are other things, too.

Hi @owenthereal! @pete-woods is correct, this PR shouldn't be merged in its current state. The server-side of this is implemented but the configuration side of things will likely change, and the client-side isn't fully implemented either. If you only need server-sig-algs on the server side, this could work for you in its current state. We've been using it in prod for a few months now as it is.
I'd still like to get some feedback on the proposed config changes from the maintainers before I continue down the road for this PR, though. I have some discussion in the tracking issue for this PR https://github.com/golang/go/issues/49269.

I think people are starting to get nervous about this now the GutHub March 15th date (when rsa with SHA1 is deprecated) is getting pretty close. Any Go based Git client not using this patch plus extra stuff will break for a sizeable chunk of users.

@aphistic do you plan to rebase this patch on the master branch? For what I can understand the upstream seems quite unresponsive. I'm a little short on time but if you're not going to work on this I might give it a try in the next few weeks, thanks

@drakkan I am not sure if you need client or server support, but client support got merged a few days ago. Bumping golang.org/x/crypto should fix client issues.

@drakkan I am not sure if you need client or server support, but client support got merged a few days ago. Bumping golang.org/x/crypto should fix client issues.

@rmohr thanks, I'm aware that client suppor was merged. I would like to add server support to SFTPGo

Here is a rebase of this patch against current master:
0001-ssh-add-support-for-extension-negotiation-rfc-8308.zip
I just modified extInfoMsg marshal/unmarshal to match the one introduced upstream and added support for client certificate authentication which didn't work in the previous patch.
I don't think this patch is production ready, one of the many companies interested in this feature should hire one of the upstream maintainers to get a proper patch and so give something back to the community (I know at least one company that is developing a new SFTP server in Go and it is silently waiting for this patch ...)

@aphistic FYI, managed to leverage your work for the ssh client signers with your current api exposure and without having to change the signatures of the signers themselves: rmohr@e4ed966. Maybe it is helpful when looking into the API changes.

That fork apparently also fixed the server part for me. Adding
replace golang.org/x/crypto => github.com/rmohr/crypto v0.0.0-20211203105847-e4ed9664ac54

to go.mod worked!


target logit and its curves

hi,I read your paper and your target logit curves code ,I feel puzzled,your paper say that Wf is also called as the target logit ,but I feel that your  target logit curves is  not correspond with the definied Wf,it seems  not to think about the f.

The definition of logit is from this paper: https://arxiv.org/pdf/1701.06548.pdf (z_i in Section 3). It originally means the values that are fed into Softmax loss, and we define the target logit as the logit which is corresponding to the ground truth label.
In the original Softmax, the target logit is W_y^T f. In AM-Softmax, we normalize the W and f and modify the target logit to be s*(W_y^T f - m). Here y is the ground-truth label of the optimizing sample.

hi，I read your target logit curves matlab code on your github draw_psi_curve.m ,I always feel the Angular softmax and AM softmax curves plot the ψ(θ).but conventional softmax plot cos(θ), the target logit is W_y^T f.Angular softmax target logit ||f|| ψ(θ),I feel not  corresponding.

You are right. I will change the y-label to ψ(θ) in the final version of my paper.

I do not  know whether arcface target logit curves have also the problem.

Yeah... ArcFace uses the same figure, and suffers from the same problem.


Migrate to Stable API - Alert to Incident mapping lookup

https://github.com/briandelmsft/STAT-Function/blob/b5f7bde50da95fb65576a570e920e0f7701878ad/modules/base.py#L113

As of today, no GA API is available for this call
https://learn.microsoft.com/en-us/rest/api/securityinsights/entities-relations/list?view=rest-securityinsights-2024-01-01-preview&tabs=HTTP


ES6 methods don't work with typescript syntax check

From @m3l7 on October 11, 2016 14:36

VSCode Version: 1.6
OS Version: fedora 23

my current tsconfig.json is
  {
      "compilerOptions": {
          "target": "es6",
          "module": "commonjs",
          "sourceMap": true,
          "outDir": "src",
          "typeRoots": ["./typings/modules", "./typings/globals"]
      },
      "include":[
          "src/**/*"
      ]
  }

let's say I have this:
  Object.assign({});

if I compile the project with tsc --lib es6 or with a gulp task, it works correctly. However, vscode syntax check gives:
  [ts] Property 'assign' does not exist on type 'ObjectConstructor'

Copied from original issue: Microsoft/vscode#13514

From @m3l7 on October 13, 2016 11:27
the same happens with Promise

@m3l7 thank you for opening this issue. I have confirmed this happens with the latest bits. This is a language service issue. Moving to that repo.

The issue here is that the tsconfig.json as listed above includes no files. The include list includes "src", but then the output directory is "src" as well. the compiler does not want to recompile the files it outputted last cycle, so it excludes the output directory by default. so the net results is no files to compile..
To solve this either:

use a different outDir
Do not set outDir at all, by default a .js file is emitted next to its source .ts file
add an empty "exclude": []

I have logged https://github.com/Microsoft/TypeScript/issues/11650 to track showing an error message if the compilation included no files.

sorry for the late reply.
not setting an outDir seems to fix. However, setting an outDir different from include array results in the debugger failing to start. (Cannot launch program 'api.ts'; setting the 'outFiles' attribute might help.')
But this seems like a different issue


Pipette Current Config Lost

As a user, I would like pipette current configs to persist across sessions/runs/etc.
Details are still a little fuzzy on this bug; we haven't deliberately recreated it yet. This is a blocking issue for delivery of a beta robot.
Expected Behavior

Pipette currents should not change except when manually modified

Observed

Pipette current reset overnight (?) after being manually modified (via config file change).
-- Note this results in the pipette plunger having insufficient current to home.
-- Note this is specifically a problem for the generation of pipettes with an o-ring issue (they require increased current to overcome o-ring resistance)

Steps to Recreate

Note we've observed this twice in the wild but have not yet attempted to recreate it.
Andy manually updated current on single channel pipette to 0.8 amps by replacing config file
-- Details on config file change?
-- Robots: 'Darkness' and 'Wandering River' (PP1-2 robots)
-- SW: Version 3.0.0 (<IP_ADDRESS>97)
Successfully run various protocols
Robots left overnight (we believe there were no SW updates pushed to robots)
Pipette plunger does not home when running various protocols (including standard logo protocol) due to insufficient current
-- Confirm current reset to lower value

Unable to recreate 2/19


Error when multiple services are defined

Do you want to request a feature or report a bug?
Bug
Did you try using a 1.7.x configuration for the version 2.0?

[ ] Yes
[x] No

What did you do?
Similarly to https://github.com/containous/traefik/issues/4807 i defined multiple services for a docker container. Contrary to the linked issue i already defined each router's service. This is the list of labels i am using:
      traefik.enable: "true"
      traefik.http.routers.fr24-web.rule: "Host(`fr24.{{ traefik_domain }}`)"
      traefik.http.routers.fr24-web.entrypoints: "web"
      traefik.http.routers.fr24-web.middlewares: "redirect@file"
      traefik.http.routers.fr24-web-secured.rule: "Host(`fr24.{{ traefik_domain }}`)"
      traefik.http.routers.fr24-web-secured.entrypoints: "web-secure"
      traefik.http.routers.fr24-web-secured.middlewares: "auth@file"
      traefik.http.routers.fr24-web-secured.service: "fr24-web"
      traefik.http.routers.fr24-web-secured.tls.certresolver: "le"
      traefik.http.services.fr24-web.loadbalancer.server.port: "8080"

      traefik.http.routers.frconf.rule: "Host(`frconf.{{ traefik_domain }}`)"
      traefik.http.routers.frconf.entrypoints: "web"
      traefik.http.routers.frconf.middlewares: "redirect@file"
      traefik.http.routers.frconf-secured.rule: "Host(`frconf.{{ traefik_domain }}`)"
      traefik.http.routers.frconf-secured.entrypoints: "web-secure"
      traefik.http.routers.frconf-secured.middlewares: "auth@file"
      traefik.http.routers.frconf-secured.service: "frconf"
      traefik.http.routers.frconf-secured.tls.certresolver: "le"
      traefik.http.services.frconf.loadbalancer.server.port: "8754"

What did you expect to see?
No errors, everything's working.
What did you see instead?
time="2019-09-19T11:39:10Z" level=error msg="Could not define the service name for the router: too many services" providerName=docker routerName=fr24-web
time="2019-09-19T11:39:10Z" level=error msg="Could not define the service name for the router: too many services" routerName=frconf providerName=docker

Note that thesse routers are the insecure routers which just should redirect to HTTPS via middleware.
Accessing the services via browser is working fine, even the redirect. It's just these two error messages.
Output of traefik version: (What version of Traefik are you using?)
Version:      2.0.0
Codename:     montdor
Go version:   go1.13
Built:        2019-09-16T17:35:17Z
OS/Arch:      linux/amd64

What is your environment & configuration (arguments, toml, provider, platform, ...)?
api:
  dashboard: true
  insecure: true

entryPoints:
  web:
    address: ":80"
  web-secure:
    address: ":443"
  traefik:
    address: ":8082"

metrics:
  prometheus: {}

accessLog: {}

certificatesResolvers:
  le:
    acme:
      email<EMAIL_ADDRESS>      storage: acme.json
      httpChallenge:
        entryPoint: web

providers:
  docker:
    endpoint: "unix:///var/run/docker.sock"
    exposedbydefault: false

  file:
    directory: /conf.d
    watch: true

Hi! I'm Træfiker :robot: the bot in charge of communication regulation.
Thanks for your interest in Traefik!
We dedicate the issue tracker to bug reports and feature requests only. My advanced AI has spotted that your issue might be a configuration problem or relates to something that doesn't look like a bug.
To confirm this, please join our Community Forum and reach out to us on the Traefik section.
In case I'm wrong (well, that would be embarrassing :sweat_smile:), my developers will re-open the issue and fix me!
In the meantime, you can double check Traefik's documentation.


Move drug profile page GraphQL queries to .gql files

Fixed except for the Profile query which is dynamic and cannot be extracted.

work done


completion: gracefully handle unexpected request

Panic occurs when a mistakenly implemented client requests for a completion despite the langserver had set InitializeResult.capabilities.completionProvider to false. (see onivim/oni#1378)
This change prohibits the langserver from processing the request with an uninitiated gocode daemon and offers helpful error message.

thanks! 🍻


[Bug Report] Cannot play any YouTube tracks

Bug Description
The bot is not able to find and play public YouTube videos since last restart.

Console throws this error
[22:47:21] [ERROR] [DefaultAudioPlayerManager]: Error in loading item https://www.youtube.com/watch?v=MZ1CJyEYgvI         at com.sedmelluq.discord.lavaplayer.tools.ExceptionTools.wrapUnfriendlyExceptions(ExceptionTools.java:44)         at com.sedmelluq.discord.lavaplayer.source.youtube.YoutubeAudioSourceManager.loadTrackWithVideoId(YoutubeAudioSourceManager.java:220)         at com.sedmelluq.discord.lavaplayer.source.youtube.YoutubeAudioSourceManager$LoadingRoutes.track(YoutubeAudioSourceManager.java:232)         at com.sedmelluq.discord.lavaplayer.source.youtube.YoutubeAudioSourceManager$LoadingRoutes.track(YoutubeAudioSourceManager.java:228)         at com.sedmelluq.discord.lavaplayer.source.youtube.DefaultYoutubeLinkRouter.routeFromUrlWithVideoId(DefaultYoutubeLinkRouter.java:99)         at com.sedmelluq.discord.lavaplayer.source.youtube.DefaultYoutubeLinkRouter.routeFromMainDomain(DefaultYoutubeLinkRouter.java:64)         at com.sedmelluq.discord.lavaplayer.source.youtube.DefaultYoutubeLinkRouter.route(DefaultYoutubeLinkRouter.java:42)         at com.sedmelluq.discord.lavaplayer.source.youtube.YoutubeAudioSourceManager.loadItemOnce(YoutubeAudioSourceManager.java:196)         at com.sedmelluq.discord.lavaplayer.source.youtube.YoutubeAudioSourceManager.loadItem(YoutubeAudioSourceManager.java:131)         at com.sedmelluq.discord.lavaplayer.player.DefaultAudioPlayerManager.checkSourcesForItemOnce(DefaultAudioPlayerManager.java:436)         at com.sedmelluq.discord.lavaplayer.player.DefaultAudioPlayerManager.checkSourcesForItem(DefaultAudioPlayerManager.java:418)         at com.sedmelluq.discord.lavaplayer.player.DefaultAudioPlayerManager.lambda$createItemLoader$0(DefaultAudioPlayerManager.java:217)         at java.util.concurrent.FutureTask.run(FutureTask.java:266)         at com.sedmelluq.discord.lavaplayer.tools.OrderedExecutor$ChannelRunnable.executeQueue(OrderedExecutor.java:98)         at com.sedmelluq.discord.lavaplayer.tools.OrderedExecutor$ChannelRunnable.run(OrderedExecutor.java:87)         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)         at java.lang.Thread.run(Thread.java:748)         Suppressed: com.sedmelluq.discord.lavaplayer.tools.exception.EnvironmentInformation:    lavaplayer.version: 1.3.78   os.arch: amd64   os.name: Linux   os.version: 5.10.0-10-amd64   java.vendor: Oracle Corporation   java.version: 1.8.0_252   java.runtime.version: 1.8.0_252-b09   java.vm.version: 25.252-b09 Caused by: java.lang.RuntimeException: Error when extracting data EID: 36814827-cfac-445e-a471-3303cd2738ff, mainJson <redacted>         at com.sedmelluq.discord.lavaplayer.tools.ExceptionTools.throwWithDebugInfo(ExceptionTools.java:134)         at com.sedmelluq.discord.lavaplayer.source.youtube.DefaultYoutubeTrackDetailsLoader.load(DefaultYoutubeTrackDetailsLoader.java:71)         at com.sedmelluq.discord.lavaplayer.source.youtube.DefaultYoutubeTrackDetailsLoader.loadDetails(DefaultYoutubeTrackDetailsLoader.java:46)         at com.sedmelluq.discord.lavaplayer.source.youtube.YoutubeAudioSourceManager.loadTrackWithVideoId(YoutubeAudioSourceManager.java:208)         ... 16 common frames omitted Caused by: java.lang.RuntimeException: Neither player nor playerResponse in result EID: c7c20786-b701-4881-b2f3-af4eef047c63, json <redacted>         at com.sedmelluq.discord.lavaplayer.tools.ExceptionTools.throwWithDebugInfo(ExceptionTools.java:134)         at com.sedmelluq.discord.lavaplayer.source.youtube.YoutubeTrackJsonData.fromMainResult(YoutubeTrackJsonData.java:53)         at com.sedmelluq.discord.lavaplayer.source.youtube.DefaultYoutubeTrackDetailsLoader.loadBaseResponse(DefaultYoutubeTrackDetailsLoader.java:81)         at com.sedmelluq.discord.lavaplayer.source.youtube.DefaultYoutubeTrackDetailsLoader.load(DefaultYoutubeTrackDetailsLoader.java:60)         ... 18 common frames omitted
Steps to Reproduce

Find a video on YouTube
Copy the link
Use the play command with the link as an argument

Expected Result
Play the given track
Debug Output
System Properties:
  java.version = 1.8.0_252
  java.vm.name = OpenJDK 64-Bit Server VM
  java.vm.specification.version = 1.8
  java.runtime.name = OpenJDK Runtime Environment
  java.runtime.version = 1.8.0_252-b09
  java.specification.version = 1.8
  os.arch = amd64
  os.name = Linux

JMusicBot Information:
  Version = 0.3.6
  Owner =<PHONE_NUMBER>84480011
  Prefix = -
  AltPrefix = @mention
  MaxSeconds = 0
  NPImages = true
  SongInStatus = false
  StayInChannel = true
  UseEval = true
  UpdateAlerts = true

Dependency Information:
  JDA Version = 4.3.0_324
  JDA-Utilities Version = 3.0.5
  Lavaplayer Version = 1.3.78

Runtime Information:
  Total Memory = 48
  Used Memory = 18

Discord Information:
  ID =<PHONE_NUMBER>84561960
  Guilds = 3
  Users = 2

Additional Info
No response
Checklist

[X] I have looked for information about this within the documentation
[X] I have searched for similar issues on the issues page
[X] I am running the latest version of the bot:

im also getting that error now, just started a few hours ago. feel like it might be something with discord?

I believe it's the youtube api and not discord

I have a fix for this issue. The fix will be part of the next version (0.3.7) coming in the following minutes or hours.

This also just begin within the last few hours with us. it wont play any YT links and if trying to play YT playlists you get "💡 All entries in this playlist were longer than the allowed maximum (00:00)" even if that setting is set to 0 or any higher number.

0.3.7 has now been released.

0.3.7 solved this issues, YT can now play single songs but trying to load up a YT playlist still errors
"💡 All entries in this playlist were longer than the allowed maximum (00:00)"
seems like a separate issues but this began happening the same moment the above YT issue began and changing the config time length has no effect

Please open a new issue for this.


ledger-live-desktop: fix libudev handling in fhs-env

Motivation for this change
Fix #116361.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

/marvin opt-in
/status needs_reviewer

Ledger live is now working flawlessly with this patch.

if this could be useful for other fhs-env packages then maybe its worth making a option in the systemd expr and a entry in all-packages.nix

@ofborg eval

Result of nixpkgs-review pr 138969 at b804b059 run on x86_64-linux 1

1 package built successfully:

ledger-live-desktop

1 suggestion:

warning: missing-patch-comment
Consider adding a comment explaining the purpose of this patch on the line preceeding.
Near pkgs/applications/blockchains/ledger-live-desktop/default.nix:24:28:
   |
24 |     patches = patches ++ [ ./systemd.patch ];
   |                            ^

@Artturin I don't know if this fix is useful elsewhere, that Steam controller issue seems relevant but I can't test it. Maybe someone in that issue can try to apply the same fix and if it works than we can do as you suggested, but I'd prefer to do it in a follow-up PR so that we can merge this one sooner.

This makes ledger work just fine for me out of the box.


Gsoc'21 fix the responsiveness of preloader and copyright section in footer in mobile version

Related Issuse
Preloader was not responsive in mobile version so i fix it and copy right section was also not looking good

Closes: #[109]
Describe the changes you've made
It is now looking like this

Checklist:

[ x] My code follows the style guidelines of this project.
[x ] I have performed a self-review of my own code.
[x ] I have commented my code, particularly in hard-to-understand areas.
[ ] I have made corresponding changes to the documentation.
[ x] My changes generate no new warnings.

Screenshots

Original
Updated

original screenshot
updated screenshot

sir please review it and please add the gsoc label.

@khannakshat7 sir please review it and please add the GSSoC'21 label before merging


fix(setup-tutorial.ts) json error

Hello,
In the saveWalletFile function, the data string is not correctly formatted as JSON.
The closing quote for the privateKey value is missing
I changed the code
Hope it helps
Br,
Tudor.

good catch! thank you!

please rebase to latest version to merge it

is it ok now?

will check with the team why I can't merge it


[BUG] Notification for AttributeChangeRequest cannot be opened directly

Describe the bug
After sending a AttributesChangeRequest a notification occurs in the Enmeshed app. Clicking on it does not open the send message (like I am used to for notifications of messaging apps).
To Reproduce
Steps to reproduce the behavior:

Create a relationship to an Enmeshed app.
Send a AttributesChangeRequest to the client.
Notification in the Enmeshed app cannot be opened directly.

For the AttributesChangeRequest we used something like:
 const client = ConnectorClient.create({ ... })

await client.messages.sendMessage({
      recipients: [session.enmeshedId],
      content: {
        '@type': 'RequestMail',
        to: [session.enmeshedId],
        cc: [],
        subject: '<Subject>',
        body: '<Body>',
        requests: [
          {
            '@type': 'AttributesChangeRequest',
            attributes: [{ name: "foo", value: "bar" }],
            applyTo: session.enmeshedId,
            reason: '<reason>',
          },
        ],
      },
})

Expected behavior
Clicking on the notification will open the message in the Enmeshed App.
Screenshots
Notification in the app after sending the AttributesChangeRequest:

Environment

Product: App
Version: 1.6.6
Device: Android 10

Hi @kulla,
thanks again for your report. This should be fixed with App v1.8.0, expected in stores next week. I'll leave the issue open until you can confirm.
Best Regards


Issue 371 cli command for creating a schedule

@nhoening to test out, I suggest you adjust this to fit your tutorial:
flexmeasures add schedule --sensor-id 5 --factor-id 13 --from 2021-10-09T12:00+02:00 --until 2021-10-09T22:00+02:00 --soc-at-start 0.03 --soc-target 0.03 2021-10-09T14:00:00+02:00 --soc-target 0.03 2021-10-09T19:00+02:00 --soc-min 0.01 --soc-max 0.06

I hope it fits what you had in mind.
Are you planning to add an automated test that follows your tutorial?
closes #371

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

23 of 37 (62.16%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.07%) to 70.495%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

flexmeasures/data/models/planning/utils.py
3
4
75.0%

flexmeasures/cli/data_add.py
15
28
53.57%

Totals

Change from base Build<PHONE_NUMBER>:
-0.07%

Covered Lines:
6700

Relevant Lines:
9049

💛  - Coveralls

Does soc translate well to assets other than batteries?

No, not to assets with shifting flexibility, for example, but it does translate well to assets with storage or buffer flexibility.

I was planning on an automated test for the toy-account CLI command. I'd expect we make a test only for this if it's not too much trouble.

Okay. And do the current CLI options work well for the tutorial, or would you like to see adjustments / smarter defaults? For example, starting the schedule now and ending the schedule some default duration from now.

Two ideas to simplify:

--until could maybe become a --duration parameter. Duration (e.g. 4h or PT4H) is simpler than a complete datetime
For the soc specs, can either --soc-at-start, --soc-min and --soc-max be left out - i.e. can they in principle be inferred from asset/sensor/beliefs data? For instance, maybe the last two could also be asset attributes?

Could --from be optional, and then FlexMeasures selects the next sensible interval (given the sensor resolution)? Can also be a ticket.

For flexibility, but probably also for ease of use in many use cases, I believe it might be helpful to use soc values as percentages.

a lot, but not many use cases are electricity
percentages are often what we have in mind when we sketch a scheduling problem (certainly with min and max, but possibly also with the starting state and targets).

I computed it on 26th of February around 6pm. Is the horizon not somewhat off? I'd expected -2days plus a few hours. I the price horizon subtracted?

I did a code check to see where the horizon was being determined. The horizon was indeed off, but only by the knowledge horizon (in your case, that should have been just 15 minutes). I fixed this just now in https://github.com/FlexMeasures/flexmeasures/pull/372/commits/b6603de31f284dba491fa9b7460f5bf37bf7de9e. I believe an explanation for the remaining discrepancy (you expected something like 2 days instead of 3 days) should be found in your interpretation of printed negative timedeltas (which, I'll admit, is definitely confusing):
>>> import pandas as pd
>>> pd.Timedelta("-60H")  # 2.5 days
-3 days +12:00:00

One more thing: I now realise that soc is in percent, while roundtrip efficiency is given in a [0,1] range.
What would you recommend ― are both of these the most natural units?


KhronosTextureContainer2: minor code formating

Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s).
To prevent this PR from going to the changelog marked it with the "skip changelog" label.

Snapshot stored with reference name:
refs/pull/13506/merge
Test environment:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/13506/merge/index.html
To test a playground add it to the URL, for example:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/13506/merge/index.html#WGZLGJ#4600
Links to test babylon tools with this snapshot:
https://playground.babylonjs.com/?snapshot=refs/pull/13506/merge
https://sandbox.babylonjs.com/?snapshot=refs/pull/13506/merge
https://gui.babylonjs.com/?snapshot=refs/pull/13506/merge
https://nme.babylonjs.com/?snapshot=refs/pull/13506/merge
To test the snapshot in the playground with a playground ID add it after the snapshot query string:
https://playground.babylonjs.com/?snapshot=refs/pull/13506/merge#BCU1XR#0


Update weaver-cats to 0.6.7

Updates com.disneystreaming:weaver-cats from 0.6.0-M6 to 0.6.7.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.disneystreaming", artifactId = "weaver-cats" } ]

labels: library-update, semver-pre-release

Superseded by #278.


DayCellContent hooks not working with Fullcalendar v6

After a lot of trial and error I couldn't find the answer to my problem anywhere and when I tried downgrading the version to v5 the dayCellContent Hook worked successfully. I think this is a bug that occurred in v6.
note: I'm using FullCalendar v6.1 with vue3.
This bug has been detected only in vue3 and its status is unknown in other frameworks.
Here is the live bug; https://stackblitz.com/edit/github-cwba2n?file=src/DemoApp.vue


autogenerate docs

Seems like sphinx is the standard (Kudos @pmrowla for the suggestion), but dvc-task and dvc-render use mkdocs. Need to choose.

For the record: just needed to enable issues in py-template first. Transfered.

36% of Python programmers use documentation tools. The most popular one is Sphinx.[^1] #pythondevsurvey https://lp.jetbrains.com/python-developers-survey-2021

[^1]: Sphinx (61%) 🥇 followed by MKDocs (22%) 🥈

In case it's useful, we have a page that lists docs-related repos (and what they use) as of now:
https://www.notion.so/iterative/Docs-related-repositories-list-c23f24dca6154dc49026923ff67d20f4

give us details on what engines they use

oh is that the intention? Why?


Is this production-ready?

Could someone use this instead of lens? Are there downsides?

I would be very interested in using this, so it would be nice if it were updated to support newer versions of GHC.

@RobertFischer I've not actually had any significant trouble using lens as is when it comes to developer productivity. But I would definitely prefer a more beginner friendly tool if it doesn't degrade other aspects of my code (namely, run-time performance).


Use Default::default instead of new in traits

I'm submitting a

[x] improvement.

Current Behaviour:
Currently, traits in https://github.com/smartcorelib/smartcore/blob/development/src/api.rs#L24 requires implementation of  fn new() -> Self;, I think that instead we should rely on Default::default,
Do you want to work on this issue?
Yes
Any thoughts?

I had to implement the new() method as it looked like the best way of passing the estimators to cross_validate and cross_validate_predict. If you find a better way would be happy to go for it.

gotcha, I think that we can use generics to define the type that we need to use instead of passing a blank parameter that is not used


BlazorWorker breaking the debugger

I spent a time trying to solve a problem where the debugger just ignore all breakpoints after my app initializes,
but after step the whole initialization, I've found that the debugger does not break (or step) after this line:
await Worker.CreateBackgroundServiceAsync<T>();

The debugger output print this as well:
The 0x3f2c thread was closed with code 0 (0x0).
The thread '.NET TP Worker' (0x2ec8) was closed with code 0 (0x0).
The thread '.NET TP Worker' (0x20a4) was closed with code 0 (0x0).
The thread '.NET TP Worker' (0x4454) was closed with code 0 (0x0).
The thread '.NET TP Worker' (0x49d8) was closed with code 0 (0x0).
The thread '.NET TP Worker' (0x61d4) was closed with code 0 (0x0).
The thread '.NET TP Worker' (0x802c) was closed with code 0 (0x0).
The thread '.NET TP Worker' (0x4B34) was closed with code 0 (0x0).
The thread 'sermone' (0x0) was closed with code 0 (0x0).
The "JavaScript Decoration Adapter: localhost: 5004" program was closed with code<PHONE_NUMBER> (0xfffffff).
The thread 'Service Worker http://localhost:5004/service-worker.js' (0x1) was closed with code 0 (0x0).
The "Service-Worker.js" program was closed with code<PHONE_NUMBER> (0xfffffff).
Thread 0x2 was closed with code 0 (0x0).
The program "04099907-0717-4d89-84d2-B23CC16d7EEE" was closed with code<PHONE_NUMBER> (0xfffffff).
Browser connection failure, will be repeated: Connection Closed

I was doing a upgrade from the .NET 5 to .NET 8 this may be a problem that happened due the upgrade,
but I would appreciate if you know if there are something that can be done to solve this issue.
Currently I can debug my app by just including #if !DEBUG in worker related features.

Hello,
The debugging experience has always been very limited. It's possible that creating a new process while attached somehow breaks the debugger connection, like a conflict or something.
I don't have any quick fix for this problem unfortunately.
I know there is a debugger flag for the the new dotnet process in there somewhere, it may have some impact and indeed there may be differences between runtime behavior for this kind of stuff.
So this worked for you in .net 5? Could be an interesting starting point. However the init code it wildly different starting .net 7

This project it was pretty lost in space, I didn't used with .NET 5 for a long time, but I belive it worked before the debugger in the main process at least (nothing in worker process)
After this upgrade I faced this issue.
What if the blazor worker let I choose a subdir as root for the .net related files, then I can let a release build inside that folder.
I think with worker using a release build should not disturb the debugger.
But not sure, just a quick idea.

I haven't found any workaround.
However I have found this issue which is surely related:
https://github.com/dotnet/runtime/issues/98208

Yeah, pretty likely to be the same problem, thank you, I will keep an eye in that issue.


Can't put syn::Ty in lazy_static

I have some instances of syn::Ty in a lazy_static that works with syn v0.11.11. When updated to use syn's master branch (c1b76f51feee4d737eea59ff434ea775c2ebbf7f), it fails to compile with:

Toggle
error[E0275]: overflow evaluating the requirement `syn::delimited::Delimited<syn::FieldValue, syn::tokens::Comma>: std::marker::Sync`
   --> src\lib.rs:217:1
    |
217 | / lazy_static! {
218 | |         static ref TY_BOOL: ::syn::Ty = syn::parse("bool").unwrap();
219 | |         static ref TY_SEMVER_VERSION: ::syn::Ty = syn::parse("::semver::Version").unwrap();
220 | |         static ref TY_SEMVER_VERSIONREQ: ::syn::Ty = syn::parse("::semver::VersionReq").unwrap();
221 | |         static ref TY_STRING: ::syn::Ty = syn::parse("String").unwrap();
222 | |         static ref TY_U64: ::syn::Ty = syn::parse("u64").unwrap();
223 | | }
    | |_^
    |
    = help: consider adding a `#![recursion_limit="800"]` attribute to your crate
    = note: required because it appears within the type `syn::ExprStruct`
    = note: required because it appears within the type `syn::ExprKind`
    = note: required because it appears within the type `syn::Expr`
    = note: required because it appears within the type `syn::TyArray`
    = note: required because it appears within the type `syn::Ty`
    = note: required because it appears within the type `std::option::Option<syn::Ty>`
    = note: required because it appears within the type `syn::TyParam`
    = note: required because it appears within the type `(syn::TyParam, std::option::Option<syn::tokens::Comma>)`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<(syn::TyParam, std::option::Option<syn::tokens::Comma>)>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<(syn::TyParam, std::option::Option<syn::tokens::Comma>)>`
    = note: required because it appears within the type `std::vec::Vec<(syn::TyParam, std::option::Option<syn::tokens::Comma>)>`
    = note: required because it appears within the type `syn::delimited::Delimited<syn::TyParam, syn::tokens::Comma>`
    = note: required because it appears within the type `syn::Generics`
    = note: required because it appears within the type `syn::FnDecl`
    = note: required because it appears within the type `syn::MethodSig`
    = note: required because it appears within the type `syn::TraitItemMethod`
    = note: required because it appears within the type `syn::TraitItemKind`
    = note: required because it appears within the type `syn::TraitItem`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::TraitItem>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::TraitItem>`
    = note: required because it appears within the type `std::vec::Vec<syn::TraitItem>`
    = note: required because it appears within the type `syn::ItemTrait`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Item>`
    = note: required because it appears within the type `std::vec::Vec<syn::Item>`
    = note: required because it appears within the type `(syn::tokens::Brace, std::vec::Vec<syn::Item>)`
    = note: required because it appears within the type `std::option::Option<(syn::tokens::Brace, std::vec::Vec<syn::Item>)>`
    = note: required because it appears within the type `syn::ItemMod`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `std::boxed::Box<syn::Item>`
    = note: required because it appears within the type `syn::Stmt`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Stmt>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Stmt>`
    = note: required because it appears within the type `std::vec::Vec<syn::Stmt>`
    = note: required because it appears within the type `syn::Block`
    = note: required because it appears within the type `syn::ImplItemMethod`
    = note: required because it appears within the type `syn::ImplItemKind`
    = note: required because it appears within the type `syn::ImplItem`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::ImplItem>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::ImplItem>`
    = note: required because it appears within the type `std::vec::Vec<syn::ImplItem>`
    = note: required because it appears within the type `syn::ItemImpl`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Item>`
    = note: required because it appears within the type `std::vec::Vec<syn::Item>`
    = note: required because it appears within the type `(syn::tokens::Brace, std::vec::Vec<syn::Item>)`
    = note: required because it appears within the type `std::option::Option<(syn::tokens::Brace, std::vec::Vec<syn::Item>)>`
    = note: required because it appears within the type `syn::ItemMod`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `std::boxed::Box<syn::Item>`
    = note: required because it appears within the type `syn::Stmt`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Stmt>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Stmt>`
    = note: required because it appears within the type `std::vec::Vec<syn::Stmt>`
    = note: required because it appears within the type `syn::Block`
    = note: required because it appears within the type `syn::ImplItemMethod`
    = note: required because it appears within the type `syn::ImplItemKind`
    = note: required because it appears within the type `syn::ImplItem`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::ImplItem>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::ImplItem>`
    = note: required because it appears within the type `std::vec::Vec<syn::ImplItem>`
    = note: required because it appears within the type `syn::ItemImpl`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Item>`
    = note: required because it appears within the type `std::vec::Vec<syn::Item>`
    = note: required because it appears within the type `(syn::tokens::Brace, std::vec::Vec<syn::Item>)`
    = note: required because it appears within the type `std::option::Option<(syn::tokens::Brace, std::vec::Vec<syn::Item>)>`
    = note: required because it appears within the type `syn::ItemMod`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `std::boxed::Box<syn::Item>`
    = note: required because it appears within the type `syn::Stmt`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Stmt>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Stmt>`
    = note: required because it appears within the type `std::vec::Vec<syn::Stmt>`
    = note: required because it appears within the type `syn::Block`
    = note: required because it appears within the type `syn::ImplItemMethod`
    = note: required because it appears within the type `syn::ImplItemKind`
    = note: required because it appears within the type `syn::ImplItem`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::ImplItem>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::ImplItem>`
    = note: required because it appears within the type `std::vec::Vec<syn::ImplItem>`
    = note: required because it appears within the type `syn::ItemImpl`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Item>`
    = note: required because it appears within the type `std::vec::Vec<syn::Item>`
    = note: required because it appears within the type `(syn::tokens::Brace, std::vec::Vec<syn::Item>)`
    = note: required because it appears within the type `std::option::Option<(syn::tokens::Brace, std::vec::Vec<syn::Item>)>`
    = note: required because it appears within the type `syn::ItemMod`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `std::boxed::Box<syn::Item>`
    = note: required because it appears within the type `syn::Stmt`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Stmt>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Stmt>`
    = note: required because it appears within the type `std::vec::Vec<syn::Stmt>`
    = note: required because it appears within the type `syn::Block`
    = note: required because it appears within the type `syn::ImplItemMethod`
    = note: required because it appears within the type `syn::ImplItemKind`
    = note: required because it appears within the type `syn::ImplItem`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::ImplItem>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::ImplItem>`
    = note: required because it appears within the type `std::vec::Vec<syn::ImplItem>`
    = note: required because it appears within the type `syn::ItemImpl`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Item>`
    = note: required because it appears within the type `std::vec::Vec<syn::Item>`
    = note: required because it appears within the type `(syn::tokens::Brace, std::vec::Vec<syn::Item>)`
    = note: required because it appears within the type `std::option::Option<(syn::tokens::Brace, std::vec::Vec<syn::Item>)>`
    = note: required because it appears within the type `syn::ItemMod`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `std::boxed::Box<syn::Item>`
    = note: required because it appears within the type `syn::Stmt`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Stmt>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Stmt>`
    = note: required because it appears within the type `std::vec::Vec<syn::Stmt>`
    = note: required because it appears within the type `syn::Block`
    = note: required because it appears within the type `syn::ImplItemMethod`
    = note: required because it appears within the type `syn::ImplItemKind`
    = note: required because it appears within the type `syn::ImplItem`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::ImplItem>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::ImplItem>`
    = note: required because it appears within the type `std::vec::Vec<syn::ImplItem>`
    = note: required because it appears within the type `syn::ItemImpl`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Item>`
    = note: required because it appears within the type `std::vec::Vec<syn::Item>`
    = note: required because it appears within the type `(syn::tokens::Brace, std::vec::Vec<syn::Item>)`
    = note: required because it appears within the type `std::option::Option<(syn::tokens::Brace, std::vec::Vec<syn::Item>)>`
    = note: required because it appears within the type `syn::ItemMod`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `std::boxed::Box<syn::Item>`
    = note: required because it appears within the type `syn::Stmt`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Stmt>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Stmt>`
    = note: required because it appears within the type `std::vec::Vec<syn::Stmt>`
    = note: required because it appears within the type `syn::Block`
    = note: required because it appears within the type `syn::ImplItemMethod`
    = note: required because it appears within the type `syn::ImplItemKind`
    = note: required because it appears within the type `syn::ImplItem`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::ImplItem>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::ImplItem>`
    = note: required because it appears within the type `std::vec::Vec<syn::ImplItem>`
    = note: required because it appears within the type `syn::ItemImpl`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Item>`
    = note: required because it appears within the type `std::vec::Vec<syn::Item>`
    = note: required because it appears within the type `(syn::tokens::Brace, std::vec::Vec<syn::Item>)`
    = note: required because it appears within the type `std::option::Option<(syn::tokens::Brace, std::vec::Vec<syn::Item>)>`
    = note: required because it appears within the type `syn::ItemMod`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `std::boxed::Box<syn::Item>`
    = note: required because it appears within the type `syn::Stmt`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Stmt>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Stmt>`
    = note: required because it appears within the type `std::vec::Vec<syn::Stmt>`
    = note: required because it appears within the type `syn::Block`
    = note: required because it appears within the type `syn::ImplItemMethod`
    = note: required because it appears within the type `syn::ImplItemKind`
    = note: required because it appears within the type `syn::ImplItem`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::ImplItem>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::ImplItem>`
    = note: required because it appears within the type `std::vec::Vec<syn::ImplItem>`
    = note: required because it appears within the type `syn::ItemImpl`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Item>`
    = note: required because it appears within the type `std::vec::Vec<syn::Item>`
    = note: required because it appears within the type `(syn::tokens::Brace, std::vec::Vec<syn::Item>)`
    = note: required because it appears within the type `std::option::Option<(syn::tokens::Brace, std::vec::Vec<syn::Item>)>`
    = note: required because it appears within the type `syn::ItemMod`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `std::boxed::Box<syn::Item>`
    = note: required because it appears within the type `syn::Stmt`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Stmt>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Stmt>`
    = note: required because it appears within the type `std::vec::Vec<syn::Stmt>`
    = note: required because it appears within the type `syn::Block`
    = note: required because it appears within the type `syn::ImplItemMethod`
    = note: required because it appears within the type `syn::ImplItemKind`
    = note: required because it appears within the type `syn::ImplItem`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::ImplItem>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::ImplItem>`
    = note: required because it appears within the type `std::vec::Vec<syn::ImplItem>`
    = note: required because it appears within the type `syn::ItemImpl`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Item>`
    = note: required because it appears within the type `std::vec::Vec<syn::Item>`
    = note: required because it appears within the type `(syn::tokens::Brace, std::vec::Vec<syn::Item>)`
    = note: required because it appears within the type `std::option::Option<(syn::tokens::Brace, std::vec::Vec<syn::Item>)>`
    = note: required because it appears within the type `syn::ItemMod`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `std::boxed::Box<syn::Item>`
    = note: required because it appears within the type `syn::Stmt`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Stmt>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Stmt>`
    = note: required because it appears within the type `std::vec::Vec<syn::Stmt>`
    = note: required because it appears within the type `syn::Block`
    = note: required because it appears within the type `syn::ImplItemMethod`
    = note: required because it appears within the type `syn::ImplItemKind`
    = note: required because it appears within the type `syn::ImplItem`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::ImplItem>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::ImplItem>`
    = note: required because it appears within the type `std::vec::Vec<syn::ImplItem>`
    = note: required because it appears within the type `syn::ItemImpl`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Item>`
    = note: required because it appears within the type `std::vec::Vec<syn::Item>`
    = note: required because it appears within the type `(syn::tokens::Brace, std::vec::Vec<syn::Item>)`
    = note: required because it appears within the type `std::option::Option<(syn::tokens::Brace, std::vec::Vec<syn::Item>)>`
    = note: required because it appears within the type `syn::ItemMod`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `std::boxed::Box<syn::Item>`
    = note: required because it appears within the type `syn::Stmt`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Stmt>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Stmt>`
    = note: required because it appears within the type `std::vec::Vec<syn::Stmt>`
    = note: required because it appears within the type `syn::Block`
    = note: required because it appears within the type `syn::ImplItemMethod`
    = note: required because it appears within the type `syn::ImplItemKind`
    = note: required because it appears within the type `syn::ImplItem`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::ImplItem>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::ImplItem>`
    = note: required because it appears within the type `std::vec::Vec<syn::ImplItem>`
    = note: required because it appears within the type `syn::ItemImpl`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Item>`
    = note: required because it appears within the type `std::vec::Vec<syn::Item>`
    = note: required because it appears within the type `(syn::tokens::Brace, std::vec::Vec<syn::Item>)`
    = note: required because it appears within the type `std::option::Option<(syn::tokens::Brace, std::vec::Vec<syn::Item>)>`
    = note: required because it appears within the type `syn::ItemMod`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `std::boxed::Box<syn::Item>`
    = note: required because it appears within the type `syn::Stmt`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Stmt>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Stmt>`
    = note: required because it appears within the type `std::vec::Vec<syn::Stmt>`
    = note: required because it appears within the type `syn::Block`
    = note: required because it appears within the type `syn::ImplItemMethod`
    = note: required because it appears within the type `syn::ImplItemKind`
    = note: required because it appears within the type `syn::ImplItem`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::ImplItem>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::ImplItem>`
    = note: required because it appears within the type `std::vec::Vec<syn::ImplItem>`
    = note: required because it appears within the type `syn::ItemImpl`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Item>`
    = note: required because it appears within the type `std::vec::Vec<syn::Item>`
    = note: required because it appears within the type `(syn::tokens::Brace, std::vec::Vec<syn::Item>)`
    = note: required because it appears within the type `std::option::Option<(syn::tokens::Brace, std::vec::Vec<syn::Item>)>`
    = note: required because it appears within the type `syn::ItemMod`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `std::boxed::Box<syn::Item>`
    = note: required because it appears within the type `syn::Stmt`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Stmt>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Stmt>`
    = note: required because it appears within the type `std::vec::Vec<syn::Stmt>`
    = note: required because it appears within the type `syn::Block`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Block>`
    = note: required because it appears within the type `std::boxed::Box<syn::Block>`
    = note: required because it appears within the type `syn::ItemFn`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Item>`
    = note: required because it appears within the type `std::vec::Vec<syn::Item>`
    = note: required because it appears within the type `(syn::tokens::Brace, std::vec::Vec<syn::Item>)`
    = note: required because it appears within the type `std::option::Option<(syn::tokens::Brace, std::vec::Vec<syn::Item>)>`
    = note: required because it appears within the type `syn::ItemMod`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `std::boxed::Box<syn::Item>`
    = note: required because it appears within the type `syn::Stmt`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Stmt>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Stmt>`
    = note: required because it appears within the type `std::vec::Vec<syn::Stmt>`
    = note: required because it appears within the type `syn::Block`
    = note: required because it appears within the type `syn::ImplItemMethod`
    = note: required because it appears within the type `syn::ImplItemKind`
    = note: required because it appears within the type `syn::ImplItem`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::ImplItem>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::ImplItem>`
    = note: required because it appears within the type `std::vec::Vec<syn::ImplItem>`
    = note: required because it appears within the type `syn::ItemImpl`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Item>`
    = note: required because it appears within the type `std::vec::Vec<syn::Item>`
    = note: required because it appears within the type `(syn::tokens::Brace, std::vec::Vec<syn::Item>)`
    = note: required because it appears within the type `std::option::Option<(syn::tokens::Brace, std::vec::Vec<syn::Item>)>`
    = note: required because it appears within the type `syn::ItemMod`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `std::boxed::Box<syn::Item>`
    = note: required because it appears within the type `syn::Stmt`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Stmt>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Stmt>`
    = note: required because it appears within the type `std::vec::Vec<syn::Stmt>`
    = note: required because it appears within the type `syn::Block`
    = note: required because it appears within the type `syn::ImplItemMethod`
    = note: required because it appears within the type `syn::ImplItemKind`
    = note: required because it appears within the type `syn::ImplItem`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::ImplItem>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::ImplItem>`
    = note: required because it appears within the type `std::vec::Vec<syn::ImplItem>`
    = note: required because it appears within the type `syn::ItemImpl`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Item>`
    = note: required because it appears within the type `std::vec::Vec<syn::Item>`
    = note: required because it appears within the type `(syn::tokens::Brace, std::vec::Vec<syn::Item>)`
    = note: required because it appears within the type `std::option::Option<(syn::tokens::Brace, std::vec::Vec<syn::Item>)>`
    = note: required because it appears within the type `syn::ItemMod`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `std::boxed::Box<syn::Item>`
    = note: required because it appears within the type `syn::Stmt`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Stmt>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Stmt>`
    = note: required because it appears within the type `std::vec::Vec<syn::Stmt>`
    = note: required because it appears within the type `syn::Block`
    = note: required because it appears within the type `syn::ExprIf`
    = note: required because it appears within the type `syn::ExprKind`
    = note: required because it appears within the type `syn::Expr`
    = note: required because it appears within the type `syn::FieldValue`
    = note: required because it appears within the type `(syn::FieldValue, std::option::Option<syn::tokens::Comma>)`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<(syn::FieldValue, std::option::Option<syn::tokens::Comma>)>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<(syn::FieldValue, std::option::Option<syn::tokens::Comma>)>`
    = note: required because it appears within the type `std::vec::Vec<(syn::FieldValue, std::option::Option<syn::tokens::Comma>)>`
    = note: required because it appears within the type `syn::delimited::Delimited<syn::FieldValue, syn::tokens::Comma>`
    = note: required because it appears within the type `syn::ExprStruct`
    = note: required because it appears within the type `syn::ExprKind`
    = note: required because it appears within the type `syn::Expr`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Expr>`
    = note: required because it appears within the type `std::boxed::Box<syn::Expr>`
    = note: required because it appears within the type `syn::ItemStatic`
    = note: required because it appears within the type `syn::ItemKind`
    = note: required because it appears within the type `syn::Item`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Item>`
    = note: required because it appears within the type `std::boxed::Box<syn::Item>`
    = note: required because it appears within the type `syn::Stmt`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<syn::Stmt>`
    = note: required because it appears within the type `alloc::raw_vec::RawVec<syn::Stmt>`
    = note: required because it appears within the type `std::vec::Vec<syn::Stmt>`
    = note: required because it appears within the type `syn::Block`
    = note: required because it appears within the type `syn::ExprIf`
    = note: required because it appears within the type `syn::ExprKind`
    = note: required because it appears within the type `syn::Expr`
    = note: required because it appears within the type `syn::TyArray`
    = note: required because it appears within the type `syn::Ty`
    = note: required by `lazy_static::lazy::Lazy`
    = note: this error originates in a macro outside of the current crate

error: aborting due to previous error

It happens with both stable rustc 1.18.0 (03fc9d622 2017-06-06) and nightly rustc 1.20.0-nightly (9b85e1cfa 2017-07-07)

AST nodes in the new version of syn aren't Sync anymore unfortunately. This is because unlike in syn v0.11, we now use proc_macro's (or proc_macro2's) Term (which represents a thread-local interned identifier), TokenTree, and other such types.
I don't think there is any good way to get around the fact that proc_macro's interface is designed to generate non-threadsafe tokens, and thus our ASTs are not going to be threadsafe if we include them.

That makes sense.
I can just initialize them in the proc macro and pass them down. Don't strictly need them to be globals.

(Actually, since Ty no longer implements Eq, I don't have a reason to pre-create these Tys anyway.)


Fix forward required in GraphQL mutations

If no forward variable is set, the API responds with

Cannot read properties of undefined (reading 'map')

I have noticed this because @hn stopped working

error posting link: [{"message":"Cannot read properties of undefined (reading 'map')"}]

You can test this with the following payload:
link.json:
{
 "operationName": "upsertLink",
 "variables": {
   "sub": "bitcoin",
   "title": "Hacker News",
   "url": "https://news.ycombinator.com/"
 },
 "query": "mutation upsertLink($sub: String, $id: ID, $title: String!, $url: String!, $boost: Int, $forward: [ItemForwardInput], $invoiceHash: String, $invoiceHmac: String) {\n  upsertLink(\n    sub: $sub\n    id: $id\n    title: $title\n    url: $url\n    boost: $boost\n    forward: $forward\n    invoiceHash: $invoiceHash\n    invoiceHmac: $invoiceHmac\n  ) {\n    id\n    __typename\n  }\n}"
}

$ curl -XPOST -H "Cookie: <next_auth_cookie>" -H "Content-type: application/json" --data @link.json https://sn.ekzyis.com/api/graphql

@SatsAllDay,