[Documentation][Bug] Code snippet won't compile: Docs -> Errors -> The Handler Chain

This code snippet does not compile:
http://reactiveui.readthedocs.org/en/stable/basics/errors/   -   'The Handler Chain'
var disconnectHandler = UserError.RegisterHandler(async error => {
    // We don't know what thread a UserError can be thrown from, we usually
    // need to move things to the Main thread.
    await RxApp.MainThreadScheduler.ScheduleAsync(() => {
        // NOTE: This code is Incorrect, as it throws away
        // Recovery Options and just returns Cancel. This is Bad™.
        return MesssageBox.Show(error.ErrorMessage);
    });

    return RecoveryOptionResult.CancelOperation;
});

Reasons:

outdated API;
spelling error: 'MesssageBox'.

If you're feeling up to the challenge, this is the source for that page:
https://github.com/reactiveui/ReactiveUI/blob/master/docs/basics/errors.md#the-handler-chain

@shiftkey I am too new to Rx and async to be confident about creating a code snippet for official documentation. This is the best I could do:
RxApp.MainThreadScheduler.Schedule(() => MessageBox.Show(message));

@ghuntley This issue could probably be closed as UserError is deprecated (and removed?) and the documentation doesn't mention it anymore.

Yup. Thanks you help with triaging.


Move penguins.png into top-level assets

Currently there is an /examples/reference/elements/assets folder that contains penguins.png. This file should be moved to the top level assets folder.

As far as I can tell this was done a while back, closing.


v4.0.4 minor but breaking changes on node 6

export default function typeDetect(obj) {
^^^^^^
SyntaxError: Unexpected token export

We are still using node6 LTS and this morning, our tests (using chai) fails with this error.

This issue is currently blocking deploys in our projects based on Docker with Alpine 3.6 nodejs-current -> 7.10.1.

👍 We'll get this fixed, thanks.

Temporary workaround is possible: npm i<EMAIL_ADDRESS>

4.0.5 will be released in the next few minutes, which should fix this.

Thanks for the quick fix 🥇

@keithamus 4.0.5 doesn't work here.  ;)


Non Radial and Non Target Option

Maybe with some Markers?

I don't think it uses markers.

Meaning If you can make this?

Meaning If you can make this?

无法存放汽车

Unable to store the car

Check last version.


Error: Cannot find primary outlet to load 'HomePage'

I have been trying to get my first Angular2-Meteor app working for the past week.
Everything I try fails.  The problems relate to importing pages.  I cannot get the app to load any of my HTML templates from other files.  And routing also fails.
When I run my app I get this error in the browser console

browser_adapter.js:84 Error: Uncaught (in promise): Error: Cannot find primary outlet to load 'HomePage'
at resolvePromise (zone.js:538)
at zone.js:515
at ZoneDelegate.invoke (zone.js:323)
at Object.NgZoneImpl.inner.inner.fork.onInvoke (ng_zone_impl.js:53)
at ZoneDelegate.invoke (zone.js:322)
at Zone.run (zone.js:216)
at zone.js:571
at ZoneDelegate.invokeTask (zone.js:356)
at Object.NgZoneImpl.inner.inner.fork.onInvokeTask (ng_zone_impl.js:44)
at ZoneDelegate.invokeTask (zone.js:355)

I am running Meteor <IP_ADDRESS>
Here is my app.web.ts file:
import 'reflect-metadata';
import 'angular2-meteor-polyfills';
import { Component, provide } from '@angular/core';
// import { bootstrap } from '@angular/platform-browser-dynamic';
import { bootstrap } from 'angular2-meteor-auto-bootstrap';
import { provideRouter, RouterConfig, ROUTER_DIRECTIVES } from '@angular/router';
import { APP_BASE_HREF } from '@angular/common';
import { HomePage } from './pages/home/home';
import { AboutPage } from './pages/about/about';

import template from './app.html';

@Component({
  selector: 'app',
  directives: [ROUTER_DIRECTIVES],
  // template
  template:`

        Home

        About

  `
})
class MyApp { }

const routes: RouterConfig = [
  { path: '',   component: HomePage },
  { path: 'about',  component: AboutPage },
];

const APP_ROUTER_PROVIDERS = [
  provideRouter(routes)
];

export function run(): void {
  bootstrap(MyApp, [APP_ROUTER_PROVIDERS, provide(APP_BASE_HREF, { useValue: '/' })]);
}

Here is my package.json
{
  "name": "testangularrouting",
  "private": true,
  "scripts": {
    "start": "meteor run"
  },
  "dependencies": {
    "@angular/common": "^2.0.0-rc.4",
    "@angular/compiler": "^2.0.0-rc.4",
    "@angular/core": "^2.0.0-rc.4",
    "@angular/http": "^2.0.0-rc.4",
    "@angular/platform-browser": "^2.0.0-rc.4",
    "@angular/platform-browser-dynamic": "^2.0.0-rc.4",
    "@angular/router": "^3.0.0-beta.2",
    "angular2-meteor": "^0.5.6",
    "angular2-meteor-auto-bootstrap": "^0.5.6",
    "angular2-meteor-polyfills": "^0.1.1",
    "ionic-angular": "^2.0.0-beta.10",
    "meteor-node-stubs": "^0.2.3",
    "reflect-metadata": "^0.1.3",
    "rxjs": "^5.0.0-beta.6",
    "zone.js": "^0.6.12"
  }
}

Here is my .meteor/packages
meteor-base             # Packages every Meteor app needs to have
mobile-experience       # Packages for a great mobile UX
mongo                   # The database Meteor supports right now
reactive-var            # Reactive variable for tracker
jquery                  # Helpful client-side library
tracker                 # Meteor's client-side reactive programming library

standard-minifier-css   # CSS minifier run for production mode
standard-minifier-js    # JS minifier run for production mode
es5-shim                # ECMAScript 5 compatibility for older browsers.
ecmascript              # Enable ECMAScript2015+ syntax in app code

barbatus:angular2-runtime
angular2-compilers

@dpdonohue Looks like you are missing the <router-outlet></router-outlet> in your HTML template.
@Component({
  selector: 'app',
  directives: [ROUTER_DIRECTIVES],
  // template
  template:`

        Home

        About

<router-outlet></router-outlet>
  `
})
class MyApp { }

Without the  <router-outlet></router-outlet> your app does not know where to render your HomePage, AboutPage, etc components and that's why it this giving you this error message.

Thanks @derek-fong I now added <router-outlet></router-outlet> and I get the same error.  (I had tried this previously and omitted it here).
Also note that I cannot import HTML files.  In my app.web.ts file, I have
import template from './app.html';

On the command line I see this:
client/imports/app/app.web.ts (13, 22): Cannot find module './app.html'.
In fact the only way my application can find the HTML is if i embed it in the @Component declaration, as I have done above.  This also fails: templateUrl: './app.html'
I think there is some fundamental problem loading templates and loading pages.
It seems to break when I import using relative paths.
Is this related to a known bug?  Such as the one @Urigo referenced here?
https://forums.meteor.com/t/problem-with-angular-templates/26280

@dpdonohue

I now added  and I get the same error. (I had tried this previously and omitted it here).

Just want to confirm - Does your project contain an index.html file to specify the root component of your app?

  <app></app>

I cannot import HTML files. In my app.web.ts file, I have

import template from './app.html';
On the command line I see this:
client/imports/app/app.web.ts (13, 22): Cannot find module './app.html'.

This issue has been reported in #328 (Please see Urigo's comments). Although it shows Cannot find module './app.html' when compiling, your code should still run. I guess we just have to wait until typescript 2.0 becomes available and ignore these typescript warnings in the meantime.

In fact the only way my application can find the HTML is if i embed it in the @Component declaration, as I have done above. This also fails: templateUrl: './app.html'

Consider upgrading angular2-meteor to 0.6.0 and make sure your meteor packages angular2-compilers and barbatus:angular2-runtime are up-to-date.
Once you have updated to version 0.6.0 then you can checkout Static Resources which shows the recommended way of handling templates and stylesheets.

OK thanks to you @derek-fong I have found the mystery workaround to getting this to work.
I did upgrade angular2-meteor to 0.6.0 but I don't think that was the solution.
So in my file client/main.ts wants to load relative to the current client directory
import 'reflect-metadata';
import { Meteor } from 'meteor/meteor';
import { run as runWeb } from './imports/app/app.web';

if (Meteor.isCordova) {
  document.addEventListener('deviceready', () => {
    // ionicSelector('app');
    // runMobile();
    setClass('mobile');
  });
} else {
  runWeb();
  setClass('web');
}

function setClass(css): void {
  if (!document.body.className) {
    document.body.className = "";
  }
  document.body.className += " " + css;
}

However in my file client/imports/app/app.web.ts, it wants to

import HTML templates relative to the current directory
import pages relative to some other, far-off directory (wild speculation: node_modules/angular2-meteor?)

import 'reflect-metadata';
import 'angular2-meteor-polyfills';
import { Component, provide } from '@angular/core';
import { bootstrap } from 'angular2-meteor-auto-bootstrap';
import { provideRouter, RouterConfig, ROUTER_DIRECTIVES } from '@angular/router';
import { APP_BASE_HREF } from '@angular/common';
import { HomePage } from '../../imports/app/pages/home/home';
import { AboutPage } from '../../imports/app/pages/about/about';

import template from './app.html';

@Component({
  selector: 'app',
  directives: [ROUTER_DIRECTIVES],
  template:`

        Home

        About

<router-outlet></router-outlet>
  `

})
class MyApp { }

const routes: RouterConfig = [
  { path: '',   component: HomePage },
  { path: 'about',	component: AboutPage },
];

const APP_ROUTER_PROVIDERS = [
  provideRouter(routes)
];

export function run(): void {
  bootstrap(MyApp, [APP_ROUTER_PROVIDERS, provide(APP_BASE_HREF, { useValue: '/' })]);
}

So for now I am back in business, thanks!  I can actually (after a week of effort) load pages in Meteor/Angular 2.  Crossing my fingers for no more gotchas!
Should the documentation/tutorials be updated?  Or is there some way to make this Angular2 importing behave more intuitively/consistently?

@dpdonohue it's not related to Angular2 itself but rather to Node modules resolution style which is preset in the tsconfig by default "moduleResolution": "node".


[Icon Request] Double Check

A double check icon for indicating read / received status like in whatsapp...

I would like to work on this. If this is still available @ps73 @RobinMalfait @sschoger @adamwathan


[SPARK-22025] Speeding up fromInternal for StructField

What changes were proposed in this pull request?
Change function call to references can greatly speed up function calling.
How was this patch tested?
Existing tests.

Test build #81821 has started for PR 19246 at commit e3dfd22.

Test build #81821 has finished for PR 19246 at commit e3dfd22.

This patch fails PySpark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/81821/
Test FAILed.

Merged build finished. Test FAILed.

Test build #81822 has started for PR 19246 at commit 2e6160e.

Test build #81822 has finished for PR 19246 at commit 2e6160e.

This patch fails Python style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/81822/
Test FAILed.

Test build #81823 has started for PR 19246 at commit f8e0ac4.

Test build #81823 has finished for PR 19246 at commit f8e0ac4.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/81823/
Test PASSed.

Hi, @maver1ck .
Could you add your benchmark result on PR description for reviewers? That will be your commit log finally.

greatly speed up function calling

@dongjoon-hyun
I'll do it on Monday.

Could you mark [PySpark] in the title? cc @ueshin

I'd close this PR if there is no objection @maver1ck and I didn't miss something.

@HyukjinKwon
I created this before https://github.com/apache/spark/pull/19249, which greatly decrease function call.
I agree we can close it.

Yea, thanks. That was a cool patch BTW.


Wrong url for m3u when using Xteve behind reverse proxy

I use xteve behind a reverse proxy. When i login to xteve using https the M3U and EPG url provided are not correct as they are still based on http

OS : Linux
Arch Intel
xTeVe Version 2.1.0 (0101)

Update to version 2.1.0 (0104)
The first HTTP / HTTPS request will rewrite the URL in the file.
If that does not work, I need the log in debug mode 2, this lines would be interesting:
2019/11/15 20:40:28 [DEBUG] Web Server Request:    Path: /lineup.json
2019/11/15 20:40:28 [DEBUG] Web Server Request:    URL: http://localhost:34400/lineup.json
2019/11/15 20:40:28 [DEBUG] Web Server Request:    Scheme: http

I've just tested it, the xteve m3u  is correct so I can retrieve the list of urls for each stream in vlc but now each stream url is changed to https, the stream url should not change

It works now thanks!

In fact I still have the same issue, when I want to stream locally using http, vlc is using https urls

I need the log in debug mode 2 when VLC downloads the xteve.m3u

I think i understood the issue, it depends on the way i am logged in xteve web interface
When i open xteve web interface through my proxy using https, the url used is https
2019/11/17 12:03:02 [DEBUG] Web Server Request:    URL: http://<IP_ADDRESS>:34400/web/
2019/11/17 12:03:02 [DEBUG] Web Server Request:    Scheme: https
2019/11/17 12:03:02 [DEBUG] Web Server Request:    Path: /favicon.ico

when i use VLC then i can see that the url used is https
then when i log in using http (local address) i can see that the scheme used is http
2019/11/17 12:03:02 [DEBUG] Web Server Request:    URL: http://<IP_ADDRESS>:34400/web/
2019/11/17 12:03:02 [DEBUG] Web Server Request:    Scheme: http
2019/11/17 12:03:02 [DEBUG] Web Server Request:    Path: /favicon.ico

then if log in again using https, etc.
2019/11/17 12:15:05 [DEBUG] Web Server Request:    URL: https://xteve.hidea.synology.me/web/
2019/11/17 12:15:05 [DEBUG] Web Server Request:    Scheme: https

So xteve will behave differently depending on the scheme and last log in
If i log in using my local address, my local vlc will work, but if i login using https and proxy, the stream url will change.

M3U request HTTP header:
GET /m3u/xteve.m3u HTTP/1.1 1 1 map[Accept:[*/*] Accept-Language:[de] Range:[bytes=0-] User-Agent:[VLC/3.0.8 LibVLC/3.0.8]] {} <nil> 0 [] false localhost:34400 map[] map[] <nil> map[] [::1]:63466 /m3u/xteve.m3u <nil> <nil> <nil> 0xc001dc4480

Web request HTTP header:
GET /favicon.ico HTTP/1.1 1 1 map[Accept:[image/webp,image/apng,image/*,*/*;q=0.8] Accept-Encoding:[gzip, deflate, br] Accept-Language:[de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7] Cache-Control:[no-cache] Connection:[keep-alive] Pragma:[no-cache] Referer:[http://localhost:34400/web/] Sec-Fetch-Mode:[no-cors] Sec-Fetch-Site:[same-origin] User-Agent:[Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.97 Safari/537.36]] {} <nil> 0 [] false localhost:34400 map[] map[] <nil> map[] [::1]:63477 /favicon.ico <nil> <nil> <nil> 0xc001cf4280

xTeVe evaluates Referer:
Referer:[http://localhost:34400/web/]
If the value is missing, the files can not be rewritten.

Thanks for your feedback, i did not get it, how is it fixed? Am I supposed to do something to test a fix?

Since it is not possible to detect whether the download was done via HTTP or HTTPS, I will undo my recent changes.
But I will give the possibility to define this in the settings.json file (if HTTP or HTTPS should be generated for the URLs)

actually it is working fine now if i login locally or remotely before on the web interface, it switches the scheme and the stream works

The issue is back, when i am logged using https, the blue wheel keeps spinning and there is an issue : No websocket connection to xTeVe could be established. Check your network configuration.

seems to be related to my synology settings, it is fixed now

seems to be related to my synology settings, it is fixed now

Hi, you mind clarifying how you managed to solve this ? Thanks !


Tracking refactor(nested-loop-join)

[ ] #790
[x] #792

Is this issue resolved? cc @BowenXiao1999

If not, please describe in detail what this issue is about. "Refactor nested loop join" seems too generic for a good first issue.

Done.
Closed for now.


Burst support

Please add support for burstcoin.
https://poloniex.com/exchange#btc_burst

Sorry. My mistake. Polo doesn't support burst for lending.


Migration to FCM

As GCM is now deprecated and will be disabled on April 2019, will we have a new release 1.1.2 with FCM support?
I see that we already have an updated URL to FCM in master branch.

Link to GCM to FCM migration guide: https://developers.google.com/cloud-messaging/android/android-migrate-fcm


fixed btn view in mobile view

Fixed #121
Now the button does not collid with the text in this view.

@anushbhatia @smaranjitghose


Installation on 32-bit Windows

I understand from the changelog that 32-bit support is dropped, but is this necessarily a permanent decision? Sharp is the better alternative for image resizing and effects, and I rely on gulp-responsive in my development workflow. Unfortunately, one of my development environments runs 32-bit Windows 8.1 - with no chance of an upgrade to 64-bit.
I was wondering if someone had an installation process for Sharp using 32-bit, even using an older version (presumably @0.11.4). Currently I fail on C:\VIPS\include\glib-2.0\glib/gtypes.h(32): fatal error C1083: Cannot open include file: 'glibconfig.h', running npm install<EMAIL_ADDRESS>--save-exact --arch=ia32. Per Sharp.io/0.11.4/ I have set a VIPS_HOME environment variable to C:\VIPS and added C:\VIPS\bin to path.
However, given the name - vips-dev-w64-8.2.2.zip - it would perhaps be the case that this is the Windows 64-bit version of these files (as referred to by the docs). Has anyone recently installed Sharp on a 32-bit Windows system successfully?

Hei Ole, the last version combination to work with a 32-bit Node executable was, as you've discovered, sharp v0.11.4 with libvips v8.1.1.
Archived installation instructions are at http://sharp.dimens.io/en/v0.11.4/install/#windows
libvips v8.1.1 is available from http://www.vips.ecs.soton.ac.uk/supported/8.1/win32/vips-dev-8.1.1.zip
The newer w64 builds of libvips won't work with 32-bit.
If you're really stuck (and have lots of time), a hardware virtualisation tool such as QEMU might allow the use of a 64-bit environment on a 32-bit CPU. Good luck!

That libvips v8.1.1 was indeed the missing piece: Now npm install<EMAIL_ADDRESS>--save-dev --arch=ia32 runs as expected, and can be followed by npm install<EMAIL_ADDRESS>--save-dev --arch=ia32 (v1.2.0 runs Sharp v0.11).
This development environment is in reality a Windows-tablet with very limited hardware, so virtualization or other solutions are limited. Just finding the space for Visual Studio (currently needed for node-gyp) took a lot of effort, I'd be hard-pressed to find more.
Hopefully this sheds some light for anyone else in the same situation: It can be done with 32-bit, just be sure to acquire the right versions of the libraries.

Sharp is so fast, but reverted back to Jimp as on Azure web app deployment causing issues. Tried older version of Sharp no luck. Not sure how to compile the libvips dependency myself for Azure.


Karpenter does not consolidate nodes that don't fit a new DaemonSet

Version

Karpenter Version: v0.22.1 (also in previous version we have been using)

Kubernetes Version: v1.24.9
Expected Behavior
When new DaemonSets are deployed on a existing cluster with existing Karpenter Nodes, those DaemonSets will not fit on the existing Nodes. Karpenter will automatically Consolidate those existing Nodes to replace them with bigger/multiple new Nodes so all DaemonSets will fit.
Actual Behavior
When new DaemonSets are deployed on a existing cluster with existing Karpenter Nodes, those DaemonSets will not fit on the existing Nodes.
Steps to Reproduce the Problem

Deploy a cluster
Deploy a couple of workloads (Deployments, StatefullSets, DaemonSets) (specify resource limits and requests)
Wait for Karpenter to spin up those new Nodes and wait for the deployments to be ready.
Now install another Helm chart that adds a couple of workloads including daemonsets (specify resource limits and requests). e.g. https://artifacthub.io/packages/helm/philips-labs/spire
Some of your existing nodes will not fit the DaemonSet

Workaround to make them fit manually (Hopefully Karpenter can automate one of these approaches):

Check which nodes do not have the DaemonSet
Drain those nodes one by one (easiest, lazy approach, which probably Karpenter consolidation could apply), this also requires your pods to be deployed in HA to prevent downtime of deployments that might be on this node.

More advanced/least impacting other deployments:

Check which nodes do not have the DaemonSet
Taint the affected nodes as NoSchedule, evict another non DaemonSet pod (That at least makes room for the resource requests and limits of the other Pod), wait for Karpenter to spin up a new node for the pod we evicted.
and remove the taint NoSchedule so the DaemonSet will take the free space that was created.

Resource Specs and Logs
Our clusters have 2 provisioners depending on what users of our platform choose. It can be a single one, or both of them.
amd64 provisioner
apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: amd64
spec:
  consolidation:
    enabled: true
  labels:
    intent: apps
  limits:
    resources:
      amd.com/gpu: 0
      aws.amazon.com/neuron: 0
      cpu: 1000
      memory: 100Gi
      nvidia.com/gpu: 0
  providerRef:
    name: bottlerocket
  requirements:
    - key: karpenter.sh/capacity-type
      operator: In
      values:
        - on-demand
        - spot
    - key: kubernetes.io/arch
      operator: In
      values:
        - amd64

arm64 provisioner
apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: arm64
spec:
  consolidation:
    enabled: true
  labels:
    intent: apps
  limits:
    resources:
      amd.com/gpu: 0
      aws.amazon.com/neuron: 0
      cpu: 1000
      memory: 100Gi
      nvidia.com/gpu: 0
  providerRef:
    name: bottlerocket
  requirements:
    - key: karpenter.sh/capacity-type
      operator: In
      values:
        - on-demand
        - spot
    - key: kubernetes.io/arch
      operator: In
      values:
        - arm64

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Thanks for raising this issue!
It sounds like this case should only come up when the node's total capacity doesn't fit all DaemonSets (not including any other pods) since other lower priority pods should be preempted to make room for the DS. https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption
Do your other pods have a higher priority than your daemonsets?

That did the trick. We have used the out of the box system-node-critical class to ensure these critical components in our case are always on the nodes.


Change package_managers to package-managers

This was meant to happen in #9, but I missed this one out.

changed in https://github.com/inttter/mdbadges-cli/commit/5d991cbb0cd345fbb2c22798e243e6431c29c76d


Prebid 8 adapter modules : changes in buildRequests

Running a bid adapter in prebid 8 seem to have a breaking change which I haven't found informations about: objects sent in the buildRequests function no longer are the same than with previous version and some of their attributes are not accessible. For example in the validBidRequests[] object, while I can iterate it and find values for the bidder or bidId attributes, the auctionId and transactionId attributes are null. Same is for the bidderRequest object.
I don't really get why these objects are no longer shared ?
Attached file is what I get when buildRequests is called

Sorry, somehow I was on prebid.github.io repo and not on the prebid.js one


Are we going to have a 1.2.0 stable?

Hi!
One of my favorite times of the day is when I go with great excitement to the Jetbrains maven's repo to see if there is a new version to be tested, now I've realized that there is a brand new 1.3.0-alpha01 🎉 ! instead of a new version for the 1.2.XXX.
In fact it jumped from 1.2.0-alpha01-dev755 to 1.3.0-alpha01.
What are the plans for the 1.2.0 version and what exciting things are you planning to bring us on the 1.3.0?

Will this 1.3.0 version allow us to use small UI sections embedded into iOS storyboards #2211  🤔 ?
Thanks!
CC: @arkivanov and @dima-avdeev-jb 😃

I'm eagerly waiting for a stable version of Compose for Desktop based on Kotlin 1.7.x. This would unblock releasing a stable version of Decompose.
Also if I understand it correctly, MPP Compose has its versions aligned with Jetpack Compose. E.g. one can use a library that depends on MPP Compose v1.1.x in a pure Android project with Jetpack Compose v1.1.x. Such a project wouldn't be able to migrate to Jetpack Compose v1.2.0, because the library would have to wait for MPP Compose v1.2.0.

Yes, we already decided the release date of Compose Multiplatform 1.2.0, which will be based on Jetpack Compose 1.2.1 and probably on Compose Compiler 1.3.0.
Targets other than Desktop and Web DOM will still be experimental.
The version 1.3.0-alpha01 in Maven repo is just for Compose Compiler 1.3.0-alpha01. Google recently switched to a separate release cycle of Compose Compiler, and we are also experimenting with that now.
1.3.0-alpha version of the main Compose (ui, foundation, material) will be built near or after the Compose Multiplatform 1.2.0 release.

Ok, that makes sense, thanks @igordmn!

If it is "based on Jetpack Compose 1.2.1" why isn't it also called then Compose Multiplatform 1.2.1? I wouldn't like such a confusion on version numbers.

Compose Multiplatform depends on Jetpack Compose, but it can have its own bugs, so we need our own hotfix versioning. Keeping first two versions aligned is easier.
We can name our versions <IP_ADDRESS> though, but for now we stick to the usual versioning, and just write corresponding Jetpack Compose versions in CHANGLOG/Updated Dependences.

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.


Watchman Causes HA to Crash or Become Temporarily Unresponsive

Home Assistant 2022.12.0
Supervisor 2022.11.2
Frontend 20221207.0 - latest
Watchman v0.6.0
I've been working on tracking down an issue I'm having when I update, edit, or delete an Automation, Script, or Scene in my HA installation and it has lead me to believe that Watchman is causing my HA to become temporarily unstable when when it updates.
I see messages like this in my logs whenever I save a change to an automation, script, or scene.
Dec 08 14:42:03 elsa homeassistant[914]: 2022-12-08 14:42:03.423 INFO (MainThread) [custom_components.watchman] 1968 files parsed and 0 files ignored in 34.59s. due to HA restart
Typically what happens is I edit an automation, hit save and my dashboard becomes unresponsive. After 35-45 seconds I see the message above in my system logs and the dashboard either starts to respond or my HA appears as though it restarts.
All the times today I have noticed this happen are when watchman updated.

I also see this behavior and finally discovered watchman as the culprit, was driving me insane....

Indeed. An integration causing Core to get fully blocked (for 30 seconds in my case, your mileage may vary due to system performance) is an absolute no-go.
The biggest no-go is, this issue is very old - and nobody fixed it until today. What a pity.

Took me weeks to identify what had been causing to freeze my HA when I click reload "All yaml configuration". Without Watchman it usually takes 20s, with Watchmap – 2 minutes.

Even more annoying is it intercepts editing automations and scripts ⚠⚠⚠
On every save (using the UI, which probably causes scripts.yaml and automations.yaml to be parsed again bei WM) my HA is frozen for roughly 30 seconds. Caused by Watchman.
Not sure if this integration is maintained at all cause such a major issue not being worked on for years ⚠ is very sad.

causing to freeze my HA when I click reload "All yaml configuration"

Same as "why a PC antivirus makes my file operations slower???".
What else do you expect? Do not run Watchman constantly. Watchman is processing config changes as it is supposed.

Do not run Watchman constantly.

Do you really mean this like you wrote it? Is this a "You are holding it wrong!" blaming? Are we now discussing if this issue even is an issue? In case we do I think this is the final dead plug for this integration :-)

Is this a "You are holding it wrong!" blaming?

You are exaggerating, dear disliker.
And yes, this is about an intelligent use of Watchman. If it tracks EVERY config_change & re-evaluate itself - then possible (not mutually excepting) solutions could be:
-- do not react in every config change since they could be like an avalanche;
-- do not run it constantly, run it periodically.

v0.6.3 should be fully compliant with HA async requirements for custom integrations

v0.6.3 should be fully compliant with HA async requirements for custom integrations

...unfortunately saving automations or scripts in the UI still makes whole HA freeze for 20 to 30 seconds when Watchman is enabled.

No, nothing has changed in version 0.6.4 according to this issue yet.
Ok, then we need a switch in the Watchman settings to disable it.
Just out of curiosity, what hardware do you run Home Assistant on?

That switch would be nice. It would allow things like using the automation_reload event to trigger an automation which waits for 30 seconds and enables Watchman etc.
In short: good idea 👍
My HA runs on a Pi 4.


Understanding 802.11(Wi-Fi) Standards

Proposed title of the article
Understanding 802.11 Standards
Introduction paragraph (2-3 paragraphs):
802.11 based networks, also known as Wi-Fi networks, have progressively developed into the most common types of networks available and widely used in the modern world. It is common for you to connect to the internet through a wireless access point available in your office, bedroom, or favourite fun spot. Thus, understanding the history, types, standards and characteristics of wifi networks is fundamental in remaining up to date with modern technologies.
Key takeaways:

Definition and history of 802.11 networks
The various types of 802.11 standards
Key characteristics and features of each type of 802.11 standards

References:
N/A
Templates to use as guides

How To Guide Template
Software Review Template
Tutorial Template

Good afternoon and thank you for submitting your topic suggestion.
Your topic form has been entered into our queue and should be reviewed (for approval) as soon as a content moderator is finished reviewing the ones in the queue before it.  @lin-chez

Good afternoon @lin-chez and thank you for submitting your topic to the EngEd program.
After some careful consideration it struck us that this topic may be a bit over saturated throughout other blog sites and official documentations.
We typically refrain from publishing content that is covered widely on the net or other blogs. We're more interested in original, practitioner-focused content that takes a deeper dive into programming-centric concepts.
Please feel free to suggest an alternate topic to explore. 🚀


When stopping a SkeletonIK3D, the jigglebone isn't active anymore

If I do skeleton_ik_3d.stop(), my jigglebones aren't active anymore, even if the ik and the jigglebone aren't related in the scene.
Based on the documentation (check here), the function stop() also calls the function Skeleton3D.clear_bones_global_pose_override(), which is probably the cause for the jigglebones deactivation.
Do you agree with this statement?
And if so, I don't know how to work around this.

I forgot we don't need to stop a skeleton_ik_3d, we can just set skeleton_ik_3d.interpolation = 0.0, so the IK doesn't force any position.
So the IK can always be active.
So technically, my problem is resolved :)


fix(pie): hide labelLine emphasis when inside

Brief Information
This pull request is in the type of:

[x] bug fixing
[ ] new feature
[ ] others

What does this PR do?
Currently the label line will stay visible on emphasis when changing from outside to inside. This PR fixes this problem and adds a test to show that emphasis works even after changing back and forth.
Details
Before: What was the problem?

After: How is it fixed in this PR?

Merging options

[x] Please squash the commits into a single one when merge.

Other information

LGTM, @pissang could you double check?


upgrade puma to address security alert

https://github.com/Betterment/test_track/security/dependabot/55
Summary

Provide a general description of the code changes in your pull
request... were there any bugs you had fixed? If so, mention them. If
these bugs have open GitHub issues, be sure to tag them here as well,
to keep the conversation linked together.

upgrade puma to address security alert
/no-platform

Proposing a chromedriver fix here: https://github.com/Betterment/test_track/pull/201


[BUG] Connect-PnPOnline from VS Code integrated terminal stalls on first attempt

Reporting an Issue or Missing Feature
When using Connect-PnPOnline with parameter -Interactive from the integrated terminal in Visual Studio Code on Mac the initial attempt hangs. My browser is Safari. Something in the communication between VS Code and Safari seems to malfunction.
When I abort the command and retry it does succeed.
Using iTerm this problem does not occur.
Expected behavior
I would expect Connect-PnPOnline to log me into the SharePoint.
Actual behavior
Not really comfortable with sharing screenshots due to log-in information.
If needed I can provide screenshots/casts through discrete channels.
Steps to reproduce behavior
Connect-PnPOnline $SharePoint -Interactive on Visual Studio Code Mac
What is the version of the Cmdlet module you are running?
1.6.0
Which operating system/environment are you running PnP PowerShell on?

MacOS
Visual Studio Code, Version: 1.57.1, Commit: 507ce72a4466fbb27b715c3722558bb15afa9f48

@DanielNoord - This command (Connect-PnPOnline) is used thousand of times everyday, so we can safely say it works. Furthermore, we're not going to be able to troubleshoot third-party software like VSCode (PowerShell extension) or Safari unfortunately. We don't have the capacity / resources.

I can understand the lack of capacity/resources might make fixing this bug impossible, although I am more than happy to provide any data/details needed.
I don't necessarily agree with the conclusion that the commands "works" though. It does, but for me only after two tries. I don't believe that is how it is supposed to work. But again, I can understand the circumstances which would prevent you from fixing this.


manifest asks for standard services instead of free.  Doesn't work w/ free trial.

Corrected. It does run, but gives warnings. Would want dev journey to use free where possible.

Yes Mark, we had started off using free plans of APIs, but as an example we are having more than 25 intents in the conversation workspace. So, used the standard plan

Mostly done.  Tone Analyzer needs to change to "Lite" (which is a free plan).  The others are now on free.

Resolved in #46


Use gitmojis.json from carloscuesta/gitmoji

By doing this, we don't need to manually update this lib every time
gitmoji adds a new emoji.
Closes #5.

+1, would be great !

Would be cool to have this merged!

Why this feature hasn't been merged yet?


[Task] Test proofmode verification

Confirm that Proofmode data can still be verified after being processed and put into the proofmode attribute. If it can't there's some bug somewhere.

It does work, both the signature of the metadata and of the media file itself could be verified using the included public key.


Use network events from PW instead of using CDPSession

Currently, we use own internal CDP session for monitoring network info and construct the network waterfall. It works good, but requires a heavy work when we want to capture network events from popups and other tabs.
We uses this approach as playwright previous did not have any HAR tracer and used page level network events which is pretty much same as ours. Now PW exposes all these events from the browser context https://github.com/microsoft/playwright/pull/6370 which means we can extract all the network information for cross pages, popups and windows relying on the same.
However, we need to do this after a new release of PW is published including the network events changes and also the security details.

However, we need to do this after a new release of PW is published including the network events changes and also the security details.

1.12.0 is published, this can be picked up now - https://github.com/microsoft/playwright/releases/tag/v1.12.0

Need both of these issues to be addressed in PW to keep the parity with directly hooking in to CDP

https://github.com/microsoft/playwright/issues/7662 - Add support for blocked, queuing
https://github.com/microsoft/playwright/issues/7663 - TLS cipher info - We can also do this later.


Add License file

Really awesome work with this model. I would love to add it to the darts  forecasting library. Can you add a license?

Hi @gdevos010,
Thanks for your interest! You can use it as a research proposal.
BTW, we are working on an additional linear model with better performance. I hope it will be helpful!


Add Userspace networking mode flag (+ bump version)

As discussed in #22 #32 this plugin is currently not able to correctly route local traffic. If understood the docs correctly if it is running in a container (as it does in this plugin) it needs to set this, to be able to keep iptables between host and container in sync. Otherwise local routing will not work correctly.
More on this here:

https://github.com/tailscale/tailscale/issues/504
https://tailscale.com/kb/1112/userspace-networking/

I've successfully tested this with my setup and I can access all the local IPs (like 192.168.1.*) in my network. Of course Subnets need to be enabled from Tailscale admin panel. Furthermore, this PR bumps the tailscale version.
I have a working repository with these changes so anyone can test easily: https://github.com/moritzgloeckl/addon-tailscale

@frenck can we get this merged and released?

Rebased the PR (skipping the version bump) to sync up with the current development branch.


[Daemon] Add version args

I'm reluctant to add more than a single command line argument. Maybe the version could be displayed in the help?

let you decide about that, i think -v/--version is a kind of standard 'non-argument' as it's not a way to launch the program and i feel almost (CLI) program use it but no strong opinion.

Fine, let's do this. A --help / -h which simply calls print_help (but doesn't return 1) would be helpful too in the same spirit i guess.

Fine, let's do this. A --help / -h which simply calls print_help (but doesn't return 1) would be helpful too in the same spirit i guess.

instead creating a nec print_help() method, i just add an argument to pass the return code to print_help_exit(code), wdyt @darosior ?

I'm a bit confused. You introduce a new --help argument as i suggested, but then dropped the --version argument. Do you think they are redundant? I'm fine with having only --help, just in this case please squash your commits into one (and update the commit / PR titles).

instead creating a new print_help() method, i just add an argument to pass the return code to print_help_exit(code), wdyt @darosior ?

Sounds good.

I'm a bit confused. You introduce a new --help argument as i suggested, but then dropped the --version argument. Do you think they are redundant? I'm fine with having only --help, just in this case please squash your commits into one (and update the commit / PR titles).

instead creating a new print_help() method, i just add an argument to pass the return code to print_help_exit(code), wdyt @darosior ?

Sounds good.

some misunderstanding, on my side, done


bug: Getting error when click mark as completed

Describe the bug
Getting 400 when click on mark as completed
To Reproduce
Steps to reproduce the behavior:

Go to week 9 and click on mark as completed
open network tab and you will see the error

Works fine when you unsave your previous bookmarks and re save it. Errors out for existing bookmarks, incase you want to unsave it, also existing bookmarks aren't rendered.

Issue is not for saving bookmarks, issue is when you finished watching video and you click "Mark as completed" then it through 400 error.

When the video completesz it's automatically marked as completes, hence the issue if you click it again. Need to handle this in a global state, so that the button changes the state as soon as mark as complete request is being sent.

This does reproduce @rahulpandey70. I am working on this.


ci: add signed releases

Unfortunately the release bot commits (and releases) are "Unverified" and apparently there's no a way for resolve the problem


[Request] Support Command Groups

(First of all, thank you for creating this wonderful command runner. After spending a long time debating between the various alternates to Makefile, writing my own shell scripts, or what, I discovered just a brief while ago, and it immediately became my favorite.)
As the title says, I would like to be able to organize recipes into groups, similar to GitHub's gh command. Example usage:
# user group
just user list
just user show NAME
just user create NAME
just user delete NAME

# product group
just product list
just product show NAME
just product create NAME
just product delete NAME

# etc.

As for how the syntax or mechanism for achieving this inside justfiles might look like, there could be multiple ways for doing so, and I suppose deciding which one is best might need some discussion among the developers and community, but I'm going to both humor you and give you a serious suggestion by telling you the following story.
I asked ChatGPT: "I want to write a just file where commands are divided into groups, where each group contains sub-commands. Is there a particular way that is considered idiomatic for doing so in just files?"
In its sheer magnificence, ChatGPT hallucinated the following answer:

Yes, there is a common way to organize commands into groups with sub-commands in a Justfile. Here's an example of how you can achieve this:

# Define a group of tasks with a common prefix
# Example: just build.app
# Example: just build.library
build:
    # The build group has its own set of sub-tasks
    # Example: just build.app.android
    app.android:
        echo "Building Android app"

    app.ios:
        echo "Building iOS app"

    library:
        echo "Building library"

Initially wondering whether a feature like this actually exists and I simply missed it, I pasted it into a justfile and invoked it, only to get some syntax errors...
That said, I think ChatGPT's entertaining hallucination seriously seems like a nice idea, as it would make writing justfiles with command groups very simple, natural and easy as a breeze, at least from the perspective of the user.
However, from the perspective of Just's developers, it might be troublesome, as determining that whether something is a recipe or a group relies on matching the first line of the indented block against recipe definition syntax and then checking if the subsequent line is indented, and unfortunately this is error-prone and can result in confusing errors for the user.
Fortunately, the ambiguity can be alleviated by requiring that groups headings are marked in some unambiguous way. For example:
[group]
build:
    android:
        echo "Building Android app"

    ios:
        echo "Building iOS app"

Also note that ChatGPT's suggestion involves using a period between the group name and the command name in the command-line. While personally I prefer not to have it that way from a pure stylistic perspective, but from an implementation perspective, it might simplify things a great deal for both Just's developers and even the users, as you no longer have to wonder if a command-line like just build android means "Invoke the two recipes build and android" or "Invoke the android recipe from the build group".
I have another suggestion that might make implementing groups even simpler, which is allowing periods in recipe names and making it so that the shell completion only lists commands in the current nesting level. For example, if we have recipes called build.android, build.ios, test.android, test.ios, then typing just and pressing tab would just list only build. and test., but if the command-line is just build., then the completion function would list build.android and build.ios, and this would work with an arbitrary number of nesting levels.
If done like this, it would be much easier to implement, and as a bonus, it would allow offering an extra feature, which is that unless a recipe called build is explicitly defined, then invoking just build would automatically invoke all recipes with the build. prefix.
As you can see, there are various ways to do this, and deciding which one is best might need some discussion, but in any case personally I think it would be pretty nice to have in one form or another.
Thank you in advance.

Check out #383, which I think tracks what you're interested in.


Fix codestyle error reported by prettier

This PR fixes the codestyle error reported by prettier (see the current CI status).

This causes the tests to fail because the function returns undefined now :) I'm not getting any lint warnings with what's in master right now and the CI status looks ok:

Did you clone and check out? Also see https://travis-ci.org/tailwindcss/tailwindcss/builds/537588973

I fixed the code style in this commit:
https://github.com/tailwindcss/tailwindcss/commit/5e7c263e0a4b0e33af6df02e4122c4b9dc70d1ee
This PR breaks Tailwind because of automatic semi-colon insertion, this code:
    return
      postcss([
        postcssNested({
          bubble: ['screen'],
        }),
      ]).process(style, {
        parser: postcssJs,
      }).root.nodes

...will always return undefined because it's evaluated like this:
    return;
      postcss([
        postcssNested({
          bubble: ['screen'],
        }),
      ]).process(style, {
        parser: postcssJs,
      }).root.nodes;

I'm on commit ee42b26 locally and yarn run style reports no errors for me 🤔

Running a new build for the master branch right now:
https://travis-ci.org/tailwindcss/tailwindcss/builds/538930343

Well, we should tell prettier to ignore some things. Too opinion based what it wants to do.
-    return postcss([
+    return;
+    postcss([
       postcssNested({
-        bubble: ['screen'],
-      }),
+        bubble: ["screen"]
+      })
     ]).process(style, {
-      parser: postcssJs,
-    }).root.nodes
-  })
+      parser: postcssJs
+    }).root.nodes;
+  });

But why does it fail locally?

Not sure, it doesn't fail locally for me. Running yarn run style fails for you?

Nevermind, it seems to work now. Not sure if there is some issue between npm and Yarn because the scripts use npm and I run yarn like you do in the CI. Probably something npm related (caches?).

At least I had also issues that files could not be resolved. After some retries and clearing the npm cache it magically worked again.


isZip() Regex

The pattern for the isZip() method could be shortened to: /^\d{5}(?:-\d{4})?$/, ?: isn't strictly necessary.

Yep! I've made this change.


fuse_get_context() returns 0-filled tuple during release

Not sure if this is a known FUSE limitation or an issue with fusepy.  When calling fuse_get_context() from the release method, the returned tuple will contain three 0's instead of the uid/gid/pid.
Is there a way of obtaining the context's pid for a call that is guaranteed to happen only once (when the file is closed)?  Flush/fsync retrieve a valid context, but they could be called multiple times prior to the file being closed.  Thanks for your help.

@twestbrookunh Thanks for submitting this issue. Without some context, I am not sure I fully understand the problem. Would you mind posting a simple code example of the problem you are experiencing in a comment?

Hi @eestrada - sure, can do.  The following shows calling fuse_get_context() from the FUSE API's release method:
def release(self, path, fh):
     print(fuse_get_context())

Output:
(0, 0, 0)
Whereas fuse_get_context() from any other FUSE method (read/write/open/truncate/etc) returns a populated tuple.  Thanks -


Increase dpi of image output

I don't know if this is too similar to https://github.com/mapbox/leaflet-image/issues/9. But I was wondering if there is a way to increase the dpi of the outputted canvas (my goal is to create an image with 300 dpi).  I used the method found in https://github.com/Leaflet/Leaflet/issues/6187 but this didn't seem to improve the dpi of the image. Any thoughts on this?

Closing.  See my comment in https://github.com/mapbox/leaflet-image/issues/9 on June 25th 2019.  Divide your dpi by 96 and then multiply the specified variables by that value instead of 2.  It satisfies my current use anyway.


Alignfix

There's a bug in the _pages/_about.md file, in that there's a profile: align: property defined in the front matter, but changing it doesn't do anything. I realised it's because there's an align: right !important; line in the _sass/_profile.scss file, which shouldn't be there. The _layout/about.html file creates a div for the profile image with a class given by the profile: align: property of the about.md page, and these classes are defined in _sass/_positions.scss simply to set the alignment, so the alignment should be set from this class, rather than separately in the profile class. If one changes the profile: align: property to left instead of right as it is in the template file, then nothing happens, as the important property of profile overrides the left class. If one just removes the alignment from the profile class, then there's still an error, as the col class in _sass/_gallery.scss is also defined to be left aligned, and as the profile image is also set to have the col class, then there is still a conflict. My fix is therefore to also remove the left align property from the col class seeing as a left/right class exists which makes all alignment explicit. Finally, this requires the project pages to have the images also have the left class in order to get the nice 2/1 or 1/1/1 images. I also updated the code snippet in the projects to match the changed classes.

Thanks a lot for spotting the bugs and contributing!! Happy to merge after some minor fixes.

Hey, yes sorry I shouldn’t have had the readme or config files in this pull request. I’ll change those files back how you say later.

I've changed the markdown in the README to only use the hash symbol before the title name, and changed the baseurl property back in the config file as requested. I've left the license change as-is in order to match the default you get if you use the jekyll new-theme command. I can change it back to the simple 'MIT' string if you'd rather?

Wonderful, thanks again for the contribution!

No worries, thanks for the lovely theme :)


mfcj470dw-cupswrapper: fixed issue #147793

Motivation for this change
Issue #147793
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, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 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
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Tested on Linux x86_64 unstable, added the printer, it now shows up as expected by @mayl. Printed one page.

Wow, thank you for getting this so quick! I added this package to my config as an overlay and was able to successfully print.
I noticed that I need to add both the cupswrapper AND lpr driver to my config.  Only adding the cupswrapper would populate the database with an appropriate entry, but actually trying to select and print with it led to file not found errors in cups with a path into the nix-store (presumably looking for the LPR driver).  I admittedly haven't done much printing with NixOS but I did previously add a brgenml1cupswrapper compatible printer and adding that single driver to my config worked.  Can/should mfcj470dw work the same way?

Thanks for the feedback, I can't think of any reason to avoid that, and it will be more convenient. Updated the PR to include the change. Can you confirm it's working for you as expected ?

Success! Your latest version works as expected for me with just the cupswrapper added to my drivers.  This gets a big :+1: from me!  Thanks for fixing this so quickly :smile:


Remove spurious warning when user has no follows

r? @keybase/react-hackers only visible when i'm testing with a new test account on a dev build, but still annoying.


Creative Wings doesn't work

Attached Creative Wings doesn't give you the skill to fly like Creative.
INFO: I take the creative Wings from Creative Mode.

This issue lacks a bunch of information.
What Minecraft version are you using?
What other mods do you have on your modpack?
Did any errors or warnings appeared on Minecraft's console log on startup or when trying to place the wings?
Can you give steps on how to reproduce this?
Also, AFAIK there's no difference between a crafted Creative Flight wing and a creative-tab Creative Flight wing. Both are literally the same item, down to the NBT data. (Thanks Steven for the lazy implementation)

What Minecraft version are you using?
1.16.5 - Newest Release Version of Fabric Server
What other mods do you have on your modpack?
http://game.mineasia.de/downloads/mineasia-alpha/MineAsia-Alpha.xml
Did any errors or warnings appeared on Minecraft's console log on startup or when trying to place the wings?
Nope
Can you give steps on how to reproduce this?
Take the Wings with (Creative) name from Creative-Inventory.
Put the Wings on with Rightclick
Change to Survival
Try to fly like Gamemode Creative but doesn't work.

Can you give steps on how to reproduce this?
Take the Wings with (Creative) name from Creative-Inventory.
Put the Wings on with Rightclick
Change to Survival
Try to fly like Gamemode Creative but doesn't work.

Could not reproduce with latest Winged version.
Please, update Winged both on client and server and try again.
If it persists, it is most likely a mod incompatibility between some mod and PlayerAbilityLib. Anyways, this issue is out of Winged's scope since we don't directly handle with creative flight. (PlayerAbilityLib does that for us)


Service without labels returns null, not {}

if no labels are set on a service, Spec.Labels is null, not an empty map/object;
$ docker service create --name nolabels nginx:alpine
$ docker service inspect --format '{{ json .Spec.Labels}}' nolabels
null

This is inconsistent with containers, where it's always a map/object;
$ docker run --name nolabels busybox sh
$ docker inspect --format '{{json .Config.Labels }}' nolabels
{}

I think we should fix that, to keep consistency in our UX.

/cc @tiborvass

Agreeing on the inconsistency, I'll take a look.
#dibs 👼

@vdemeester Thanks! I didn't check other properties (env-vars, etc), so those may need a change as well. Also didn't compare the API between "containers" and "services"

ping @vdemeester just found this one, did we ever change this?

#dibs
A few other types also behave the same, e.g.:
$ docker node inspect --format '{{ json .Spec.Labels }}' self
null


v3.8.24

This is a version up due to the merge at web-components, https://github.com/VEuPathDB/web-components/pull/391.
As usual, thank you for your super fast review, @jtlong3rd ! 😄

@jtlong3rd I already knew that! 😄

This was updated by Connor so closing this PR


Any plans to use SVG icons instead of the current ones?

Thanks

Duplicate : #712

Yup, as tspoke says, this is a duplicate of #712.
This feature is on the roadmap, it just hasn't been a high priority since we've been working mostly on the new ToC. We'll get to it eventually!


error: linking with gcc failed: exit code: 1

error: linking with gcc failed: exit code: 1
|
= note: "gcc" "-fno-use-linker-plugin" "-Wl,--nxcompat" "-nostdlib" "-m64"
= note: *\target\debug\deps\libbacktrace_sys-31ba6dea43c3d34c.rlib(alloc.o):alloc.c:(.text$__rbt_backtrace_alloc+0x37): undefined reference to __errno'           *\target\debug\deps\libbacktrace_sys-31ba6dea43c3d34c.rlib(alloc.o):alloc.c:(.text$__rbt_backtrace_vector_grow+0xbf): undefined reference to __errno'
*\target\debug\deps\libbacktrace_sys-31ba6dea43c3d34c.rlib(alloc.o):alloc.c:(.text$__rbt_backtrace_vector_release+0x80): undefined reference to __errno'           *\target\debug\deps\libbacktrace_sys-31ba6dea43c3d34c.rlib(posix.o):posix.c:(.text$__rbt_backtrace_open+0x48): undefined reference to __errno'
*\target\debug\deps\libbacktrace_sys-31ba6dea43c3d34c.rlib(posix.o):posix.c:(.text$__rbt_backtrace_open+0x60): undefined reference to __errno'           *\target\debug\deps\libbacktrace_sys-31ba6dea43c3d34c.rlib(posix.o):posix.c:(.text$__rbt_backtrace_close+0x20): more undefined references to __errno' follow

mysql version 17.0.0 OR 18.1.0

Hi. I believe the issue is in your environment? Did you try to build something without mysql dependency?

very strange, without mysql dependency, my program can be compiled through

I think it's because libbacktrace-sys is in your dependency tree because of mysql`. I'll try to recreate your environment.
Btw, did you tried rust msvc?

backtrace-rs issues

I think it's because libbacktrace-sys is in your dependency tree because of mysql. I'll try to recreate your environment.
Btw, did you tried rust msvc?

i will try

Hi, here:
.rustup\toolchains\stable-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\bin>gcc.exe -v
Using built-in specs.
COLLECT_GCC=gcc.exe
Target: x86_64-w64-mingw32
Configured with: '*'
Thread model: posix
gcc version 6.3.0 (x86_64-posix-seh-rev2, Built by MinGW-W64 project)
so issue is my environment.
OS : win10
Cygwin64: 3.1.4 => GCC: 9.3.0
Rust : 1.42

rust's x86_64-pc-windows-gnu rust needs to match GCC version 6.3.0.
I have switched Cygwin64 to MinGW-W64 project ...... DONE


Update CHANGELOG.md

This is probably just a copy-paste that has gone wrong

What do you know people actually read the CHANGELOG. 😲

@robertohuertasm You may need to re-run the build in AppVeyor.


rescuefunding for a transaction that generated neither channel nor pending channel

I tried to open 4 channels in one transaction by running the bos open command, but although the transaction was confirmed, only 3 channels were created and the remaining one generated neither a channel nor a pending channel.
The transaction is shown below, and based on the channel points of the other channels that worked, I am guessing that the index that did not create a channel is 1.
https://mempool.space/tx/67a15827b95c68b7e708e82732ff33f92ce39c1547e09714acecc09789fcebfc
The detailed situation is described in this bos issue.
Fortunately I was able to get cooperation from the pier I tried to open the channel with, so I am planning to use the resucuefunding command to recover the funds. In this case, I think I need to run the command without using channel.db, but how do I get the "--localkeyindex" that I need?

Take a look at the zombierecovery subcommands. Those can be used if no channel DB information is available.
Those aren't well documented yet, so if you'd like to write a HOWTO on how to use them, I'd throw in 200k sats as a bounty for a PR that adds the HOWTO.

Thanks for the reply. It gave me some hope.
I immediately registered my node ID in Lightning Network Node Recovery.
If I am successful, I will try to create a HOWTO.

You don't need to register at node-recovery.com if you already know who your other node of the channel to rescue is.
Then you can directly create a JSON file like this and start with step [1/3] (which I think you did, just commenting here in case someone else finds this issue):
{
 "node1": {
  "identity_pubkey": "03.....",
  "contact": "node1 contact info (not really relevant)"
 },
 "node2": {
  "identity_pubkey": "03.....",
  "contact": "node2 contact info (not really relevant)"
 },
 "channels": [
  {
   "short_channel_id": "zzzzzz",
   "chan_point": "xxxxx:y",
   "address": "bc1q....,
   "capacity": 123...
  }
 ]
}

Thanks for the reply. I created the following match_file.
{
    "node1": {
        "identity_pubkey": "03910da61c1b42e135f134ed92a537c758d1edac5436efbec5ee8cec1928e1a095"
    },
    "node2": {
        "identity_pubkey": "022eb09a7993a0edde69537b420f4119c0de833e0ee47651753b46bf884db75235"
    },
    "channels" : [{
        "short_channel_id" : "7262096251",
        "chan_point" : "67a15827b95c68b7e708e82732ff33f92ce39c1547e09714acecc09789fcebfc:1",
        "address" : "bc1qrzhnszht65ukvcjlnmkk08mvd6glqa0uyq4jway0dqm49mrykmasnqhf0v",
        "capacity" : 3000000
    }]
}

I have also successfully sent this file to the other party to run preparekeys. However, when I ran makeoffer along with my pubkeys, chantools output the following message and did not work.
didn't find matching multisig keys for channel 67a15827b95c68b7e708e82732ff33f92ce39c1547e09714acecc09789fcebfc:1

Is there something wrong with my match_file? Or is it possible that the first 2500 pubkey does not match?

I recently fixed a bug in chantools that derived the node identity incorrectly. Can you try with the most recent version please?
Also, I think your short channel ID should be<PHONE_NUMBER>36541185. The rest looks okay.

I am running preparekeys and makeoffer with v0.10.2 after the update.
I replaced the short_channel_id as you pointed out for my and the other party's preparedkeys file, and ran makeoffer again, but unfortunately the result did not change.

Hmm... Without any log or pending channel, how did you determine what peer this channel was supposedly opened with?  Just trying to make sure everything is correct. I assume (by looking at the BOS issue) that it's just process of elimination? Since all the other channels to the other peers opened successfully?
Maybe you were really unlucky and the other party running preparekeys with the previous version of chantools ran into the issue I fixed recently. I'm sorry, you might have to ask them to run the command again with the new version.
If that still doesn't match, then it's possible it really isn't the right peer? Are you sure you can't dig up more of your lnd logs?

Yes, you are right, I estimated the peers by process of elimination from the indexes of the other three successful channels, as I could not find any channel or pending channel in my lnd.
And this is what we found out recently, that on the peer side, when running the lncli closedchannels command, this txid was seen as a funding canceled channel.
My peer tried to run the preparekeys command and it didn't work, so he put up issue #42. So I am sure my peer ran the command using the latest version.
The logs have been lost due to log rotation, which is very sad and regrettable, but it does not appear to be possible to investigate further.

And this is what we found out recently, that on the peer side, when running the lncli closedchannels command, this txid was seen as a funding canceled channel.

Ah, that is good news though, it means we can get some additional info. @cryptosharks131 could you please run chantools dumpchannels --closed --channeldb <your_channel.db> and send the output to me please?
Email or Slack works.
This means you have to shut down lnd to access the channel DB though, so I'm sorry for the inconvenience. But I think that output should contain the public key that was used for the multi-sig output.

I keep getting the following error when trying to run chantools dumpchannels --closed even when having more than 2x the memory available than the size of the channel.db file.
Error: error opening rescue DB: CreateFileMapping: Not enough memory resources are available to process this command.

Are you using the 64bit (either amd64 or arm64 depending on your machine) version of chantools?

Yes, this was using a 64bit version.

Leaving this comment here for anyone finding this issue through a search engine.
The Error: error opening rescue DB: CreateFileMapping: Not enough memory resources are available to process this command. error seems to be Windows specific. If that happens to you, try to find a Unix based machine to run the command on (for example MacOS or Linux).

We finally unlocked the multisig and recovered the funds we thought we had lost!
https://mempool.space/address/bc1qrzhnszht65ukvcjlnmkk08mvd6glqa0uyq4jway0dqm49mrykmasnqhf0v
I could not have accomplished so much without your kind advice and quick fixes. Thank you so much!

So happy to hear that!
Thank you for your patience with all the bugs you (and @cryptosharks131) uncovered along the way!


Bug: --sync-usage-file flag is destructive when used with wildcard resource usage

When using --sync-usage-file flag with wildcard resource usage such as:
aws_cloudwatch_log_group.my_group[*]:
  storage_gb: 1000
  monthly_data_ingested_gb: 1000
  monthly_data_scanned_gb: 200

the values are removed and replaced with each index/key specific resources with default 0 usage value:
aws_cloudwatch_log_group.my_group[0]:
  storage_gb: 0
  monthly_data_ingested_gb: 0
  monthly_data_scanned_gb: 0
aws_cloudwatch_log_group.my_group[1]:
  storage_gb: 0
  monthly_data_ingested_gb: 0
  monthly_data_scanned_gb: 0

This is also true for resource maps with for_each.
Expected behavior:
--sync-usage-file flag

should not delete the wildcard usages for resources with count and for_each
should delete the wildcard usages for resources if they got removed or count/for_each argument is removed.
should not add any element to resource usage file if a wildcard exists for that (since element values will override the wildcard).
should delete any out of range index / non-existing keys if resource array/map is updated.

Hey @alikhajeh1 , is this the bug in the breakdown command? Can I try to attempt this issue if not time crunch? I might have to go through the breakdown command code though to understand before starting to work.

I suspect it's a bug in the SyncUsageData function, no time crunch yet (if it does become time-sensitive then I'll comment here)

sounds good, I will start looking into this. Does that work?

@krishnaindani sure, I assigned it to you, and maybe @m-yosefpor can review the PR later on since his GH issue descriptions is nicely detailed :)

@krishnaindani just wondered if there were any updates to this?

@ajoulie awesome! Heads up that there's some big changes going into that part of the code that might affect this in #1036. I'll be merging it today.

Thanks @ajoulie and @aliscott - I added https://github.com/infracost/docs/pull/99/commits/2c463e157a45a2d952cbfd450a12a0386ce536c4#diff-127ccf771949de22c36f72306c28f3f448853733f173a2f658d4d6f5464de803R106-R108, feel free to tweak https://github.com/infracost/docs/pull/99 if needed


DAI - Handshape display should not be wrapping

There should be a minimum width so that the text doesn't wrap

Fixed


Add link to Zulip

Link to Zulip when we're ready to allow normal users to join. Write some guide to educate users how to communicate effectively.

If Gitter is going to be dropped, we need to remember to update links in existing docs too. One place I can think of is page Troubleshooting your solution, but maybe you know more.

Links to Gitter exists in:

https://github.com/codewars/docs/blob/master/wiki/troubleshooting-your-solution.md
https://github.com/codewars/docs/blob/master/wiki/community-code-of-conduct.md
https://github.com/codewars/codewars.com/blob/master/README.md
https://github.com/codewars/codewars.com/wiki

I changed my mind about opening up Zulip. I'd like to keep it private to avoid the noise, so I can keep the tab open and have the notification enabled for the mods.
Considering Dicord for the community instead.


GraphQL subscription sequence is not guaranteed

HI,
thanks for a great library!
today I started testing the client with subscriptions and found out that sometimes subscription completes before emitting the last message.
After investigation I found the lines that are responsible for this behavior
https://github.com/hasura/go-graphql-client/blob/43b90bcfebe0df74164ba120d29235d234112916/subscription.go#L809
go func() {
	if err := sc.protocol.OnMessage(subContext, *sub, message); err != nil {
		sc.errorChan <- err
	}

	sc.checkSubscriptionStatuses(subContext)
}()

It seems that every message is handled in a separate goroutine, thus the order of all incoming messages (incl. errors and complete message) is not anyhow guaranteed which can be a problem in certain scenarios.
Current workaround for original issue where complete is coming before the last message is :
.OnSubscriptionComplete(func(sub graphql.Subscription) {
  handler := sub.GetHandler()
  time.Sleep(1 * time.Second) // hope for the best
  handler(nil, io.EOF)
})

that's however is quite nasty and does not anyway guarantee the message order.
How to deal with this? Does it make sense to add a configuration parameter that enforces the correct execution order even sacrificing some performance?

Adding a sync mode to subscription configs that execute the OnMessage callback in sequence is possible. However, it may not solve the unordered messages from the server, for example, the server emits the completed message before the error message.

You are right. There is no way to control the sequence of the messages that the server emits, but it would be nice to have this option, at least on the client side.
The current subscription API doesn't give the subscriber an option to know when its subscription is completed. In my example, I've attempted to solve this problem by calling a subscription's handler with the 'io.EOF' error. This way, the subscriber knows when its subscription is completed. In my test case, the server sends only one message and then completes the subscription. However, on the client side, the result is not consistent: sometimes it receives the message, and sometimes it does not. This depends on which message is processed first: 'next' or 'complete'.

@andrexus would you mind verifying this PR and confirm if it works


docs: Add FAQ re capitalization

The important questions!
Do folks this is a good idea? Or we could do lowercase for everything?

It's an abbreviation - so it should be uppercase, right?

Yes, fair point. But then should we rename everything to the uppercase? e.g. this repo? Or we say repos are generally lowercase but we use uppercase in all prose?

Yes, exactly. We just use kebab-casing for naming repos and crates, but it's uppercase actually.

OK, I'm fine with that — I'll make the change unless anyone else has a view

And are we OK to rename the organization to PRQL so this repo is PRQL/prql?

Go ahead with rename and merge of this.

I changed the org name, I'll update the PR and do some more renames (unless anyone gets there first, but not expecting anyone to)


It takes a long time to detect connection lost

Small test program based on the examples in this repo:
#include <boost/redis/connection.hpp>
#include <boost/asio/detached.hpp>
#include <boost/asio/co_spawn.hpp>
#include <boost/asio/redirect_error.hpp>
#include <boost/asio/steady_timer.hpp>

#include <iostream>
#include <chrono>

namespace asio = boost::asio;
using boost::redis::request;
using boost::redis::ignore;
using boost::redis::config;
using boost::redis::connection;
using boost::redis::logger;
using boost::asio::awaitable;
using boost::asio::detached;
using boost::asio::consign;

awaitable<void> run_publisher(std::shared_ptr<connection> conn)
{
  asio::steady_timer timer(co_await asio::this_coro::executor);
  while (conn->will_reconnect())
  {
    request req;
    req.push("PUBLISH", "channel", "some data");
    boost::system::error_code ec;
    co_await conn->async_exec(req, ignore, asio::redirect_error(asio::use_awaitable, ec));
    if (ec)
    {
      std::clog << std::chrono::system_clock::now()
        << " PUBLISH failed with message: " << ec.message()
        << std::endl;
    }
    timer.expires_after(std::chrono::seconds(2));
    co_await timer.async_wait(asio::redirect_error(asio::use_awaitable, ec));
  }
}

awaitable<void> co_main(config cfg)
{
  cfg.health_check_interval = std::chrono::seconds(30);
  auto conn = std::make_shared<connection>(co_await asio::this_coro::executor);
  conn->async_run(cfg, {logger::level::debug}, consign(detached, conn));

  co_await run_publisher(conn);
  conn->cancel();
}

Using 30 seconds health check interval as indicated in this comment will be default in a future version.
Typically seeing a delay between 3x to 4x health check interval after restarting Redis before connection lost is detected and reconnect attempted.
When restarting Redis the run-op completes almost immediately. This log shows that almost 2 min later connection lost is detected:
2024-07-26 10:54:51.1038269 (Boost.Redis) run-all-op: resolve addresses <IP_ADDRESS>:6379
2024-07-26 10:54:51.1085491 (Boost.Redis) run-all-op: connected to endpoint <IP_ADDRESS>:6379
2024-07-26 10:54:51.1090630 (Boost.Redis) writer-op: 130 bytes written.
2024-07-26 10:54:51.1110903 (Boost.Redis) reader-op: 973 bytes read.
2024-07-26 10:54:51.1117493 (Boost.Redis) hello-op: Success
2024-07-26 10:54:53.1252447 (Boost.Redis) writer-op: 45 bytes written.
2024-07-26 10:54:53.1268255 (Boost.Redis) reader-op: 4 bytes read.
2024-07-26 10:54:55.1416191 (Boost.Redis) writer-op: 45 bytes written.
2024-07-26 10:54:55.1428586 (Boost.Redis) reader-op: 4 bytes read.
2024-07-26 10:54:57.1517312 (Boost.Redis) writer-op: 45 bytes written.
2024-07-26 10:54:57.1527005 (Boost.Redis) reader-op: 4 bytes read.
2024-07-26 10:54:59.1575930 (Boost.Redis) writer-op: 45 bytes written.
2024-07-26 10:54:59.1581645 (Boost.Redis) reader-op: 4 bytes read.
2024-07-26 10:55:01.1650597 (Boost.Redis) writer-op: 45 bytes written.
2024-07-26 10:55:01.1659037 (Boost.Redis) reader-op: 4 bytes read.
2024-07-26 10:55:03.1787981 (Boost.Redis) writer-op: 45 bytes written.
2024-07-26 10:55:03.1792210 (Boost.Redis) reader-op: 4 bytes read.
2024-07-26 10:55:05.1378655 (Boost.Redis) reader-op: End of file
2024-07-26 10:55:05.1382268 (Boost.Redis) reader-op: EOF received. Exiting ...
2024-07-26 10:55:05.1386657 (Boost.Redis) writer-op: canceled (3). Exiting ...
2024-07-26 10:55:05.1389448 (Boost.Redis) run-op: The operation completed successfully (reader), The operation completed successfully (writer)
2024-07-26 10:56:51.1219054 (Boost.Redis) check-timeout-op: Response has no value. Exiting ...
2024-07-26 10:56:51.1228789 (Boost.Redis) ping_op: error/cancelled (1).
2024-07-26 10:56:51.1236270 (Boost.Redis) check-health-op: The I/O operation has been aborted because of either a thread exit or an application request (async_ping), Pong timeout. (async_check_timeout).
2024-07-26 10:56:51.1239811 (Boost.Redis) runner-op: The operation completed successfully (async_run_all), Pong timeout. (async_health_check) The operation completed successfully (async_hello).
2024-07-26 10:56:51.1243785 (Boost.Redis) Connection lost.
2024-07-26 10:56:52.1326278 (Boost.Redis) run-all-op: resolve addresses <IP_ADDRESS>:6379
2024-07-26 10:56:52.1333834 (Boost.Redis) run-all-op: connected to endpoint <IP_ADDRESS>:6379
2024-07-26 10:56:52.1337355 (Boost.Redis) writer-op: 130 bytes written.
2024-07-26 10:56:52.1354276 (Boost.Redis) reader-op: 973 bytes read.
2024-07-26 10:56:52.1358929 (Boost.Redis) hello-op: Success
2024-07-26 10:56:54.1395472 (Boost.Redis) writer-op: 45 bytes written.
2024-07-26 10:56:54.1408228 (Boost.Redis) reader-op: 4 bytes read.
2024-07-26 10:56:56.1418841 (Boost.Redis) writer-op: 45 bytes written.
2024-07-26 10:56:56.1428140 (Boost.Redis) reader-op: 4 bytes read.
2024-07-26 10:56:58.1477065 (Boost.Redis) writer-op: 45 bytes written.

Added a small change to logger to get the timestamps:
void logger::write_prefix()
{
   std::clog << std::chrono::system_clock::now() << " ";
   if (!std::empty(prefix_))
      std::clog << prefix_;
}

Setting cancel_if_not_connected = true in the request will result in async_exec failing with the expected not connected error:
2024-07-26 11:17:43.6053426 PUBLISH failed with message: Not connected.
2024-07-26 11:17:43.6057837 (Boost.Redis) run-all-op: resolve addresses <IP_ADDRESS>:6379
2024-07-26 11:17:43.6074385 (Boost.Redis) run-all-op: connected to endpoint <IP_ADDRESS>:6379
2024-07-26 11:17:43.6078098 (Boost.Redis) writer-op: 85 bytes written.
2024-07-26 11:17:43.6107975 (Boost.Redis) reader-op: 969 bytes read.
2024-07-26 11:17:43.6115954 (Boost.Redis) hello-op: Success
2024-07-26 11:17:45.6173984 (Boost.Redis) writer-op: 45 bytes written.
2024-07-26 11:17:45.6179272 (Boost.Redis) reader-op: 4 bytes read.
2024-07-26 11:17:47.6251202 (Boost.Redis) writer-op: 45 bytes written.
2024-07-26 11:17:47.6257825 (Boost.Redis) reader-op: 4 bytes read.
2024-07-26 11:17:49.6389446 (Boost.Redis) writer-op: 45 bytes written.
2024-07-26 11:17:49.6398523 (Boost.Redis) reader-op: 4 bytes read.
2024-07-26 11:17:49.9818766 (Boost.Redis) reader-op: End of file
2024-07-26 11:17:49.9822220 (Boost.Redis) reader-op: EOF received. Exiting ...
2024-07-26 11:17:49.9825654 (Boost.Redis) writer-op: canceled (3). Exiting ...
2024-07-26 11:17:49.9827326 (Boost.Redis) run-op: The operation completed successfully (reader), The operation completed successfully (writer)
2024-07-26 11:17:51.6439209 PUBLISH failed with message: Not connected.
2024-07-26 11:17:53.6537792 PUBLISH failed with message: Not connected.
2024-07-26 11:17:55.6638643 PUBLISH failed with message: Not connected.
2024-07-26 11:17:57.6701620 PUBLISH failed with message: Not connected.
2024-07-26 11:17:59.6732612 PUBLISH failed with message: Not connected.
...
2024-07-26 11:19:42.0683707 PUBLISH failed with message: Not connected.
2024-07-26 11:19:43.6180784 (Boost.Redis) check-timeout-op: Response has no value. Exiting ...
2024-07-26 11:19:43.6187335 (Boost.Redis) ping_op: error/cancelled (1).
2024-07-26 11:19:43.6193823 (Boost.Redis) check-health-op: The I/O operation has been aborted because of either a thread exit or an application request (async_ping), Pong timeout. (async_check_timeout).
2024-07-26 11:19:43.6198053 (Boost.Redis) runner-op: The operation completed successfully (async_run_all), Pong timeout. (async_health_check) The operation completed successfully (async_hello).
2024-07-26 11:19:43.6200351 (Boost.Redis) Connection lost.
2024-07-26 11:19:44.0833046 PUBLISH failed with message: Not connected.
2024-07-26 11:19:44.6271292 (Boost.Redis) run-all-op: resolve addresses <IP_ADDRESS>:6379
2024-07-26 11:19:44.6283678 (Boost.Redis) run-all-op: connected to endpoint <IP_ADDRESS>:6379
2024-07-26 11:19:44.6290895 (Boost.Redis) writer-op: 85 bytes written.
2024-07-26 11:19:44.6397801 (Boost.Redis) reader-op: 969 bytes read.
2024-07-26 11:19:44.6403232 (Boost.Redis) hello-op: Success
2024-07-26 11:19:46.0852712 (Boost.Redis) writer-op: 45 bytes written.
2024-07-26 11:19:46.0861008 (Boost.Redis) reader-op: 4 bytes read.
2024-07-26 11:19:48.1011338 (Boost.Redis) writer-op: 45 bytes written.
2024-07-26 11:19:48.1018705 (Boost.Redis) reader-op: 4 bytes read.
2024-07-26 11:19:50.1027101 (Boost.Redis) writer-op: 45 bytes written.
2024-07-26 11:19:50.1036486 (Boost.Redis) reader-op: 4 bytes read.

Thanks for the detailed analysis (and sorry for the delayed response).

Using 30 seconds health check interval as indicated in this comment
will be default in a future version.

I am not yet sure what is better.

When restarting Redis the run-op completes almost immediately. This
log shows that almost 2 min later connection lost is detected:

Yeah it takes 1min52s more precisely. My analysis below shows the following
# This is the log of the last successful health check. After it
# completes a new ping is scheduled for 30s later or at
# 10:55:03 + 30s = 10:55:33.
# https://github.com/boostorg/redis/blob/e8dd4d69eb3524c9a0efb0c9723790b479a4ba8f/include/boost/redis/detail/health_checker.hpp#L56
10:55:03 writer-op: 45 bytes written.
10:55:03 reader-op: 4 bytes read.

# This block is the first reaction to restarting the Redis server. The
# server closed the connection cleanly by sending and EOF. Once the
# read operation detects it and exits, the write op is also canceled
# since I use wait_for_one in https://github.com/boostorg/redis/blob/e8dd4d69eb3524c9a0efb0c9723790b479a4ba8f/include/boost/redis/detail/connection_base.hpp#L196
10:55:05 reader-op: End of file
10:55:05 reader-op: EOF received. Exiting ...
10:55:05 writer-op: canceled (3). Exiting ...
10:55:05 run-op: The operation completed successfully (reader), The operation completed successfully (writer)

# 30s passes since the last successfull health-check and the next one
# is scheduled. But since there is no connection it sits there waiting
# for a new connection to be stablished. If cancel_if_not_connected
# were set in the health check it would fail immediately here, but
# that can't be used reliably since it uses socket.is_open().
10:55:33 ... # No log entry.

# The check-health operation wakes up here to check if the
# health-check pings are being received, cleans up the response of the
# last successful health-check, that happended at 10:55:03 and goes
# sleep for another 2 * 30s = 60s.
# https://github.com/boostorg/redis/blob/e8dd4d69eb3524c9a0efb0c9723790b479a4ba8f/include/boost/redis/detail/health_checker.hpp#L81
10:55:51 ... # No log entry.

# After 60s the check-health operation wakes up just to see no
# successful response was received, then it exits to the reconnect
# loop to stablish a new connection.
10:56:51 check-timeout-op: Response has no value. Exiting ...
10:56:51 ping_op: error/cancelled (1).
10:56:51 check-health-op: The I/O operation has been aborted because of either a thread exit or an application request (async_ping), Pong timeout. (async_check_timeout).
10:56:51 runner-op: The operation completed successfully (async_run_all), Pong timeout. (async_health_check) The operation completed successfully (async_hello).
10:56:51 Connection lost.
10:56:52 run-all-op: resolve addresses <IP_ADDRESS>:6379
10:56:52 run-all-op: connected to endpoint <IP_ADDRESS>:6379
10:56:52 writer-op: 130 bytes written.
10:56:52 reader-op: 973 bytes read.
10:56:52 hello-op: Success

I am not sure yet, but the only place where I still can adjust to
reduce the delay is on how long the check-health operation waits, at
the moment it is 2 * ping_interval, in principle it could be reduced
to ping_interval + small number so that instead of 2min you would
experience 1min30s.

The design of the health checks looks OK.
I think the actual problem is the wait_for_all here: https://github.com/boostorg/redis/blob/e8dd4d69eb3524c9a0efb0c9723790b479a4ba8f/include/boost/redis/detail/runner.hpp#L96
When async_run_all completes the health check can no longer succeed and should be canceled.

I think the actual problem is the wait_for_all here:
asio::experimental::wait_for_all(),
When async_run_all completes the health check can no longer succeed and should be canceled.

Good point, perhaps wait_for_one_error is the correct token here, I will check.
         BOOST_ASIO_CORO_YIELD
         asio::experimental::make_parallel_group(
            [this](auto token) { return runner_->async_run_all(*conn_, logger_, token); },
            [this](auto token) { return runner_->health_checker_.async_check_health(*conn_, logger_, token); },
            [this](auto token) { return runner_->async_hello(*conn_, logger_, token); }
         ).async_wait(
            asio::experimental::wait_for_all(),
            std::move(self));

Testing with wait_for_one_error did not make any difference. Maybe because the sever disconnect is not considered an error?
2024-08-19 07:40:47.8739521 (Boost.Redis) writer-op: 45 bytes written.
2024-08-19 07:40:47.8746217 (Boost.Redis) reader-op: 4 bytes read.
2024-08-19 07:40:49.3554511 (Boost.Redis) reader-op: End of file
2024-08-19 07:40:49.3557639 (Boost.Redis) reader-op: EOF received. Exiting ...
2024-08-19 07:40:49.3560638 (Boost.Redis) writer-op: canceled (3). Exiting ...
2024-08-19 07:40:49.3562413 (Boost.Redis) run-op: The operation completed successfully (reader), The operation completed successfully (writer)
2024-08-19 07:42:31.8046087 (Boost.Redis) check-timeout-op: Response has no value. Exiting ...
2024-08-19 07:42:31.8054157 (Boost.Redis) ping_op: error/cancelled (1).
2024-08-19 07:42:31.8061572 (Boost.Redis) check-health-op: The I/O operation has been aborted because of either a thread exit or an application request (async_ping), Pong timeout. (async_check_timeout).
2024-08-19 07:42:31.8066630 (Boost.Redis) runner-op: The operation completed successfully (async_run_all), Pong timeout. (async_health_check) The operation completed successfully (async_hello).
2024-08-19 07:42:31.8073355 (Boost.Redis) Connection lost.

As a simple test I added conn_->cancel(operation::health_check); here:
https://github.com/boostorg/redis/blob/e8dd4d69eb3524c9a0efb0c9723790b479a4ba8f/include/boost/redis/detail/runner.hpp#L158
Then I get:
2024-08-19 08:19:00.5407450 (Boost.Redis) writer-op: 45 bytes written.
2024-08-19 08:19:00.5420529 (Boost.Redis) reader-op: 4 bytes read.
2024-08-19 08:19:01.5827613 (Boost.Redis) reader-op: End of file
2024-08-19 08:19:01.5830703 (Boost.Redis) reader-op: EOF received. Exiting ...
2024-08-19 08:19:01.5833432 (Boost.Redis) writer-op: canceled (3). Exiting ...
2024-08-19 08:19:01.5834968 (Boost.Redis) run-op: The operation completed successfully (reader), The operation completed successfully (writer)
2024-08-19 08:19:01.5839292 (Boost.Redis) ping_op: error/cancelled (2).
2024-08-19 08:19:01.5840782 (Boost.Redis) check-timeout-op: error/canceled. Exiting ...
2024-08-19 08:19:01.5842141 (Boost.Redis) check-health-op: The I/O operation has been aborted because of either a thread exit or an application request (async_ping), The I/O operation has been aborted because of either a thread exit or an application request (async_check_timeout).
2024-08-19 08:19:01.5844371 (Boost.Redis) runner-op: The operation completed successfully (async_run_all), The I/O operation has been aborted because of either a thread exit or an application request (async_health_check) The operation completed successfully (async_hello).
2024-08-19 08:19:01.5846814 (Boost.Redis) Connection lost.

The reasoning is that no more reads and writes will be attempted after run_all_op completes. Health check can no longer succeed. Canceling it instead of waiting for timeout will remove the long delay before reconnect logic is started.
I have not familiarized myself enough with the code and design to see if this change will have any negative side-effects.

Been out for a few days. Without being a Boost.Redis expert, I'd say @mzimbres diagnostics is mainly correct. But bear in mind that from this log line:
2024-07-26 10:55:05.1389448 (Boost.Redis) run-op: The operation completed successfully (reader), The operation completed successfully (writer)

This op is completing successfully. I don't know under which circumstances the other ops may complete, but I'd say it makes sense to cancel the other operations once one of them exits.
Instead of conn_->cancel(operation::health_check);, I think using asio::experimental::wait_for_one() is better, as it provides exactly this semantics.
The degree of nesting async ops makes testing quite difficult, so I'd suggest exploring the option of replacing some of these by a sans-io state machine, which usually leads to more testable code.

Back form summer vacation ...
@VemundH I couldn't reproduce this problem so far, I tried to run Redis manually, on systemd and on docker as you explained in the PR. But I think you are  correct on the fact that since EOF is not considered and error the parallel group linked above will have to wait until the health-check returns an error. I have changed this in the PR here. Can you please try again?

@mzimbres I have tested with the changes in the PR and now the disconnect is detected when EOF is received. Thanks!
2024-09-09 07:39:57.9455664 (Boost.Redis) writer-op: 45 bytes written.
2024-09-09 07:39:57.9461189 (Boost.Redis) reader-op: 4 bytes read.
2024-09-09 07:39:58.8449635 (Boost.Redis) reader-op: End of file
2024-09-09 07:39:58.8454481 (Boost.Redis) reader-op: EOF received. Exiting ...
2024-09-09 07:39:58.8458182 (Boost.Redis) writer-op: canceled (3). Exiting ...
2024-09-09 07:39:58.8460415 (Boost.Redis) run-op: The operation completed successfully (reader), The operation completed successfully (writer)
2024-09-09 07:39:58.8465081 (Boost.Redis) ping_op: error/cancelled (2).
2024-09-09 07:39:58.8467220 (Boost.Redis) check-timeout-op: error/canceled. Exiting ...
2024-09-09 07:39:58.8469090 (Boost.Redis) check-health-op: The I/O operation has been aborted because of either a thread exit or an application request (async_ping), The I/O operation has been aborted because of either a thread exit or an application request (async_check_timeout).
2024-09-09 07:39:58.8472674 (Boost.Redis) runner-op: The operation completed successfully (async_run_all), The I/O operation has been aborted because of either a thread exit or an application request (async_health_check) The operation completed successfully (async_hello).
2024-09-09 07:39:58.8476614 (Boost.Redis) Connection lost.

This op is completing successfully. I don't know under which
circumstances the other ops may complete, but I'd say it makes sense
to cancel the other operations once one of them exits.

Correct, that is achieved with the PR by making EOF an error and using wait_for_one_error instead of wait_for_all.

Instead of conn_->cancel(operation::health_check);, I think using
asio::experimental::wait_for_one() is better, as it provides exactly
this semantics.

The problem with that set of operation is that two of them are long running (async_run and the health check) and the other is short lived (resp3 handshake) so if we used wait_for_one instead when the latter finishes it would trigger cancellation of the other two.

The degree of nesting async ops makes testing quite difficult, so
I'd suggest exploring the option of replacing some of these by a
sans-io state machine, which usually leads to more testable code.

At first I tried to launch all operations in the same group i.e. read, write, handshake, health_check. That reduces the nested ops but bloated the connection class, that is why I split it in two classes. I agree however there is still room for improvements.


fix: remove.d.ts from the default resolve.extensions

Related issue (if exists)
Resolve.extensions should not resolve .d.ts by default
Summary

🤖 Generated by Copilot at 844033e
This pull request improves the code quality and functionality of rspack by fixing indentation, resolving extensions, and correcting a typo in defaults.ts and its unit test file.

Walkthrough

🤖 Generated by Copilot at 844033e

Adjust indentation of ternary operators to match style guide and improve readability (link, link)
Remove .d.ts extension from default resolve extensions in defaults.ts, as it is not a valid output format for webpack and can cause errors when resolving modules (link)
Update unit test in Defaults.unittest.ts to reflect the removal of .d.ts extension from default resolve extensions (link)
Add space between curly braces of export statement in Defaults.unittest.ts, to match style guide and avoid linting errors (link)

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.张利鹏 seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

Remove .d.ts in the document

https://github.com/web-infra-dev/rspack-website/blob/main/docs/en/config/resolve.mdx?plain=1#L39
https://github.com/web-infra-dev/rspack-website/blob/799b2db42848c6a3d0c1fded5ee46ea9ef0ee6ce/docs/zh/config/resolve.mdx?plain=1#L39

Could you also correct the document?

Remove .d.ts in the document

https://github.com/web-infra-dev/rspack-website/blob/main/docs/en/config/resolve.mdx?plain=1#L39
https://github.com/web-infra-dev/rspack-website/blob/799b2db42848c6a3d0c1fded5ee46ea9ef0ee6ce/docs/zh/config/resolve.mdx?plain=1#L39

Thanks. Could you also correct the document?

OK

Resolve.extensions should not resolve .d.ts by default

yes, has been corrected the document.
https://github.com/web-infra-dev/rspack-website/pull/290

Update test snapshots test of the JavaScript side.

We have a snapshot test for our default configuration. You need to update it.
you could cd packages/rspack and run pnpm jest --updateSnapshot

Update test snapshots test of the JavaScript side.

We have a snapshot test for our default configuration. You need to update it.
you could cd packages/rspack and run pnpm jest --updateSnapshot
---edited
Please sign the CLA.

has done