DarajaAuth receive a token instead of two variables consumer key and consumer secret

[ ] consider passing consumer key and consumer secret as arguments for DarajaAuth for the token to be dynamically generated.

DarajaAuth changed to ClientAuth will not receive any arguments. Access Token is automatically generated from the computation of both consumer key and secret obtained from the Daraja Client that pre-configures envs from the path that it receives as an argument during initialization.


Example: Peer fanout in peer set

Motivation
This PR has some example code for ticket #2214.
It should not be merged.

@oxarbitrage I'm going to close this PR, because we're not going to merge it :-)


KeyError - light hue

I see this eror in the log using Philips hue:
Feb 25 20:24:00 raspberrypi hass[30173]: Traceback (most recent call last):
Feb 25 20:24:00 raspberrypi hass[30173]: File "/usr/local/lib/python3.4/dist-packages/homeassistant/core.py", line 779, in job_handler
Feb 25 20:24:00 raspberrypi hass[30173]: func(arg)
Feb 25 20:24:00 raspberrypi hass[30173]: File "/usr/local/lib/python3.4/dist-packages/homeassistant/helpers/event.py", line 183, in pattern_time_change_listener
Feb 25 20:24:00 raspberrypi hass[30173]: action(now)
Feb 25 20:24:00 raspberrypi hass[30173]: File "/usr/local/lib/python3.4/dist-packages/homeassistant/helpers/entity_component.py", line 172, in _update_entity_states
Feb 25 20:24:00 raspberrypi hass[30173]: entity.update_ha_state(True)
Feb 25 20:24:00 raspberrypi hass[30173]: File "/usr/local/lib/python3.4/dist-packages/homeassistant/helpers/entity.py", line 149, in update_ha_state
Feb 25 20:24:00 raspberrypi hass[30173]: attr = self.state_attributes or {}
Feb 25 20:24:00 raspberrypi hass[30173]: File "/usr/local/lib/python3.4/dist-packages/homeassistant/components/light/__init__.py", line 311, in state_attributes
Feb 25 20:24:00 raspberrypi hass[30173]: value = getattr(self, prop)
Feb 25 20:24:00 raspberrypi hass[30173]: File "/usr/local/lib/python3.4/dist-packages/homeassistant/components/light/hue.py", line 197, in brightness
Feb 25 20:24:00 raspberrypi hass[30173]: return self.info['state']['bri']
Feb 25 20:24:00 raspberrypi hass[30173]: KeyError: 'bri'

I get an further error trying to switch a light on:
Feb 25 20:33:45 raspberrypi hass[6555]: INFO:homeassistant.core:Bus:Handling <Event call_service[L]: service_data=entity_id=['light.arbeitszimmer'], service_call_id=1982166288-14, service=turn_on, domain=light> Feb 25 20:33:45 raspberrypi hass[6555]: ERROR:homeassistant.core:BusHandler:Exception doing job Feb 25 20:33:45 raspberrypi hass[6555]: Traceback (most recent call last): Feb 25 20:33:45 raspberrypi hass[6555]: File "/usr/local/lib/python3.4/dist-packages/homeassistant/core.py", line 779, in job_handler Feb 25 20:33:45 raspberrypi hass[6555]: func(arg) Feb 25 20:33:45 raspberrypi hass[6555]: File "/usr/local/lib/python3.4/dist-packages/homeassistant/core.py", line 633, in _execute_service Feb 25 20:33:45 raspberrypi hass[6555]: service(call) Feb 25 20:33:45 raspberrypi hass[6555]: File "/usr/local/lib/python3.4/dist-packages/homeassistant/core.py", line 500, in __call__ Feb 25 20:33:45 raspberrypi hass[6555]: self.func(call) Feb 25 20:33:45 raspberrypi hass[6555]: File "/usr/local/lib/python3.4/dist-packages/homeassistant/components/light/__init__.py", line 263, in handle_light_service Feb 25 20:33:45 raspberrypi hass[6555]: light.update_ha_state(True) Feb 25 20:33:45 raspberrypi hass[6555]: File "/usr/local/lib/python3.4/dist-packages/homeassistant/helpers/entity.py", line 146, in update_ha_state Feb 25 20:33:45 raspberrypi hass[6555]: self.update() Feb 25 20:33:45 raspberrypi hass[6555]: File "/usr/local/lib/python3.4/dist-packages/homeassistant/components/light/hue.py", line 269, in update Feb 25 20:33:45 raspberrypi hass[6555]: self.update_lights(no_throttle=True) Feb 25 20:33:45 raspberrypi hass[6555]: File "/usr/local/lib/python3.4/dist-packages/homeassistant/util/__init__.py", line 275, in wrapper Feb 25 20:33:45 raspberrypi hass[6555]: result = method(*args, **kwargs) Feb 25 20:33:45 raspberrypi hass[6555]: File "/usr/local/lib/python3.4/dist-packages/homeassistant/util/__init__.py", line 275, in wrapper Feb 25 20:33:45 raspberrypi hass[6555]: result = method(*args, **kwargs) Feb 25 20:33:45 raspberrypi hass[6555]: TypeError: update_lights() got an unexpected keyword argument 'no_throttle'

Which Home Assistant version are you running?
Which Hue light bulbs do you have?
Which version of the hub do you have (2013, 2015) and what is the firmware version of the hub.

Home Assistant: 0.13.1
Hue light bulbs: Iris, white light bulbs (Model LWB006), OSRAM Plug
hub version: 2015
bridge version: 1.11.0 (software version 01030262)

Fixed in 73ec049d1ca800a9bbc51ff6cf76e9fc8fc6c51e


[stable/nginx-ingress] consider values in nodePorts for LoadBalancer

What this PR does / why we need it:

Makes it possible to specify nodePort values when the controller
service type is LoadBalancer
Update README.md
Bump the version

Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[X] DCO signed
[X] Chart Version bumped
[X] Variables are documented in the README.md
[X] title of the PR contains starts with chart name e.g. [stable/chart]

I am not certain that this is valid. Can you point me to the documentation/code that allows you to define the nodeport when using type load-balancer. All I see is https://kubernetes.io/docs/concepts/services-networking/#publishing-services-service-types where it calls it out as being auto created.

NodePort and ClusterIP services, to which the external load balancer will route, are automatically created.

/assign

From API reference doc,

The port on each node on which this service is exposed when type=NodePort or LoadBalancer. Usually assigned by the system. If specified, it will be allocated to the service if unused or else creation of the service will fail. Default is to auto-allocate a port if the ServiceType of this Service requires one. More info: https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.14/#serviceport-v1-core

/ok-to-test

/test pull-charts-e2e

/lgtm


External USB Camera not recognized

Steps to Reproduce

connect USB camera to iPad

Expected results
CameraAwesome should recognize USB Camera.
Actual results
No recognization.
Actually, other dual camera app works well.
How do I?
About your device
iPad
Your flutter version
Run this in your command line
Flutter 3.22.0 • channel stable • https://github.com/flutter/flutter.git

how about ?

is there any update regarding this issue???


Initial MultiQC parsing

Connected the molcartQC outputs to MultiQC to be included in the report.
Added emit overview for createtrainingtiff so that the png file can be accessed later.
Added custom multiqc config.
PR checklist

[x] This comment contains a description of changes (with reason).
[x] Make sure your code lints (nf-core lint).
[ ] Ensure the test suite passes (nextflow run . -profile test,docker --outdir <OUTDIR>).
[ ] Usage Documentation in docs/usage.md is updated.
[ ] Output Documentation in docs/output.md is updated.
[x] CHANGELOG.md is updated.
[ ] README.md is updated (including new tool citations and authors/contributors).

Looks good for what it is implementing! Will add more QC details in the future, but the basic functionality works. Important to note, that the logo doesn't seem to work yet but I couldn't fix it!
Closes #9


Allow for temporary maximization of editor tabs

It would be great if VS Code could "temporarily maximize" editor tabs similarly to Konsole in

The idea is that one can partition the screen space in 2, 4 or more editor areas but can always temporarily focus on a single editor without having to close or get rid of the other editor tabs, then reduce the focused editor view back to its partitioned size.
Any thoughts?

Does https://github.com/microsoft/vscode/issues/196722#issuecomment-1782251148 help?

Indeed, a very good

Does #196722 (comment) help?

Indeed a very good pointer. I would have expected some tiny maximizing icon at the corner for this but it will likely clutter the interface too much anyway. Resolving since this seems to already be possible :+1:


i3: 4.12 -> 4.13

Motivation for this change
#20296
Things done

[x] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] Linux

[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

cc @NeQuissimus

LGTM
Thank you!


keep-db-file option unrecognised

Version GoAccess - 0.9.4 (Shipped with Ubuntu 16.04)
When trying to use the keep-db-file option, either as a command line parameter or in the config, goaccess reports:
goaccess: unrecognized option '--keep-db-files'

Tested with 1.0.2 and issue still exists.

You need to build goaccess with --enable-tcb=btree for the on-disk storage to be enabled.

That worked thanks... shame the Ubuntu package negates it.

Glad that worked. Feel free to use the oficcial deb repo (default hash tables).

Thanks - appreciated.
Would I be correct in saying using btree is the only way to maintain previous stats if the current log file has been rotated? I.e. the log file which is parsed by goaccess gets rotated so goaccess needs to store previous processed logs, else having to use a single file would mean it would be uncontrollably large.
Losing the file handle on the log is something I've not tested yet, but  I presume goaccess will need restarted one way or another.

That's correct. The btree is the only way to do incremental log processing.


Could not pass event ChunkLoadEvent to SpectatorMode v1.5.1

Describe the bug
The console was then spammed with dozens of errors until the server froze and shutdown.
To Reproduce
Appears to happen when a spectator player teleports away from their own loaded chunk. But happens rather randomly that I cannot consistently reproduce.
Minecraft version
1.16.5
Console error
https://paste.gg/p/anonymous/8dd5293251bb41309514d42ef086edde
Expected behavior
Nothing to happen.
Additional context
I acknowledge that you might not be willing to provide support for the server core I'm using (Yatopia). However I was only able to encounter it on this active server with players.
Looking for anyone using Paper/Spigot sharing this issue.

It is a problem with placeholder mob (even if you do not have it enabled) placeholder mob will be removed in the next version. For now I would recommend a rollback to the previous version.

Should be resolved now


OPTIONS request before GET request with Authorization Header not working

I have cloned this skeleton which already have CORS implemented.
But still when API calls OPTIONS before GET, it sends 405 ERROR "Method not allowed. Must be one of: GET"
Here is my route where I face this error. $group->get('/users', ListUsersAction::class);
    $app->group('', function (Group $group) {
        $group->post('/user/create', CreateUsersAction::class);
        $group->get('/users', ListUsersAction::class);
        $group->get('/user/{id}', ViewUserAction::class);
    })->add(AuthenticationMiddleware::class);

The same route is working from postman. And same route is working if I remove Authorization token from header.
Execution does not even reach to first line of "AuthenticationMiddleware".
However I tested it by adding same option route without "AuthenticationMiddleware".
like this:
    $app->options('/users', function(Request $request, Response $response) {return $response;});

    $app->group('', function (Group $group) {
        $group->post('/user/create', CreateUsersAction::class);
        $group->get('/users', ListUsersAction::class);
        $group->get('/user/{id}', ViewUserAction::class);
    })->add(AuthenticationMiddleware::class);

This is working. So I guess I forgot to add some code or I did any miskate which causing the error, or the skeleton has a bug.
Can anyone help on this?
Thanks in advance.

That’s because you need to add CORS route handling to the routes.php file.
$app->options('/{routes:.+}', function ($request, $response, $args) {
    return $response;
});

Hell @l0gicgate,
Thankyou very much for the reply.
Yes your solutin worked. - Working Now.
Also when I added options route for /users, it was working, like I mentioned below code block.
But I wasn't sure if that is the right way to make it working, b'cos I thought I was just using a patch to solve the problem.
So yes better option is to use a wildcard route of option method.
But is this the right way to solve it? Or this is still a patch?
Thank you very much for reply and helping with the issue.

@ankur2194 it's not a patch. It's the default way of handling the OPTIONS pre-flight request as seen in the documentation:
http://www.slimframework.com/docs/v4/cookbook/enable-cors.html
We should definitely add that to the skeleton though. I'll make a PR.

Maybe this can help you
https://stackoverflow.com/questions/60274846/slim-framework-throws-405-not-found-error-on-every-request/69916314#69916314


Make selectXpath simpler to use by disabling namespaces

Current, Element#selectXpath() has namespace awareness for its queries. However, this makes selecting anything from a document with an xmlns attribute set a pain, and expressions end up looking like: //*[local-name()="input"]. See #1746 for an example of the problems this causes.
It will be an improvement to disable namespaces when used in the Element#selectXpath() method. If users really want to use XPath with namespaces they can still use the W3CDom factory, which then also gives the path to registering namespace URI handlers.

Completed by 2b573de884aad36f3f6be3dc46e51ee06b7269f1


Edit Voice Channel Console Error

In Console:
Error with Event "Edit Channel", Action #3: TypeError: this.getVoiceChannel is not a function

Hey.
Thank you for opening an issue. We need some more information.
Are you using the DBM Beta and/or beta mods?
Kind regards,
Lasse

I'm using DBM Beta Mods, without DBM Beta.

Okay. That's the problem. In order to use all features of the DBM Mods (Beta), you need to use the DBM Beta as well. Most music and voice functions are part of the DBM Beta. You are most likely trying to edit a voice channel.
Here is how to install the beta:
0. Make a backup of your project's data folder!

Close DBM
Open Steam
Open your software library
Right-click Discord Bot Maker
Select Properties (at the bottom)
Select Betas
Select beta in the drop down menu (no key is required)
DBM should update now. Otherwise restart Steam.

Have a nice day!

Thank You! :)
You can close this "issue".


Wheelmap Embed Mode

Disclaimer: I couldn't find a more elegant way to deal with the differences of embedded vs non-embedded mode other than to just use conditionals throughout. Code is a little bit distributed, so I wasn't able to abstract it better.
This enables a wheelmap configuration with a query parameter embedded=true. When this is set Wheelmap changes in the following ways:

The main menu is not displayed
The search toolbar is not displayed
The node toolbar is uses more space towards the top (since missing main menu and search toolbar opened up more space
There is a Wheelmap home link that opens the full wheelmap site in a new tab now. The button is positioned on the right on wide viewports and on top for small viewports
The previous redirect for the classic embed urls now instead redirects to the new wheelmap embed url

Ready for Review, but no merging please. Needs to be tested in external page first.

The styling and logic looks straightforward enough!

You mean the redirect of the embed page is ok, except for the query parameter being thrown away? But other than that we can do the redirect of old embed links to the new embed mode right?

@mutaphysis You mean the redirect of the embed page is ok, except for the query parameter being thrown away? But other than that we can do the redirect of old embed links to the new embed mode right?

Yes, thanks!


admin-api-client + node-fetch erroring since a few days: Client network socket disconnected before secure TLS connection was established

Issue summary
Before opening this issue, I have:

[x] Upgraded to the latest version of the relevant packages

@shopify/admin-api-client package and version: 1.0.4 + node-fetch 2.7.0 (as a fetch agent)
Node version: 18.20.4
Operating system: Deployed on AWS ECS/ECR

[x] Found a reliable way to reproduce the problem that indicates it's a problem with the package
[x] Looked for similar issues in this repository
[x] Checked that this isn't an issue with a Shopify API

Write a short description of the issue here.
This happens even on the deployed app that never had issues. We have the app deployed on AWS ECR/ECS.

Admin API Client: request to https://xx-xx-xx.myshopify.com/admin/api/2024-10/customers/7572172243096.json failed, reason: Client network socket disconnected before secure TLS connection was established
Admin API Client: request to https://xx-x-xx.myshopify.com/admin/api/2024-10/orders/5116455780504.json failed, reason: socket hang up

I was reading around

https://github.com/Shopify/cli/issues/4399
https://community.shopify.com/c/shopify-cli-and-tools/error-client-network-socket-disconnected-before-secure-tls/m-p/2425739
https://github.com/Shopify/cli/issues/3225

And it seems now we have to do some kind of a proxy. This has not happened since last week. We changed nothing in our system, and it has started spitting this error out. So, I am not sure what I should try now and how I should change the code so it works:
const fetch = require('node-fetch');

this.shopify = createAdminRestApiClient({
            storeDomain: process.env.SHOPIFY_URL,
            apiVersion: '2024-10',
            accessToken: process.env.SHOPIFY_ADMIN_API_TOKEN,
            customFetchApi: fetch
        });

Notes on above

I have created a proxy in AWS and then added it with https-proxy-agent but it does not work, the error still happens.
The only way it currently works is if I use, with the node-fetch instance, a reject unauthorized param on a https agent

        const httpsAgent = new https.Agent({
            rejectUnauthorized: false // Disables TLS certificate validation (not good for long term use)
        });

 const customFetch = (url, options = {}) => {
            options.agent = httpsAgent; // Add the custom agent to each request
            return fetch(url, options);
        };

        this.shopify = createAdminRestApiClient({
            storeDomain: process.env.SHOPIFY_URL,
            apiVersion: '2024-10',
            accessToken: process.env.SHOPIFY_ADMIN_API_TOKEN,
            customFetchApi: customFetch // Pass the custom fetch API
        });

However, now I keep getting socket hang up errors at random times. However, no TLS issues anymore.


[Bug]: Cannot create container inside blob storage with network rules

Is there an existing issue for this?

[X] I have searched the existing issues

Affected Resource(s)
No response
Resource MRs required to reproduce the bug
No response
Steps to Reproduce
apiVersion: storage.azure.upbound.io/v1beta2
kind: Account
metadata:
  annotations:
    crossplane.io/external-name: genxp0000001nfs
  name: genx-nfs
spec:
  deletionPolicy: Delete
  forProvider:
    accountKind: BlockBlobStorage
    accountReplicationType: ZRS
    accountTier: Premium
    allowNestedItemsToBePublic: false
    blobProperties: {}
    crossTenantReplicationEnabled: true
    enableHttpsTrafficOnly: true
    infrastructureEncryptionEnabled: true
    isHnsEnabled: true
    localUserEnabled: true
    location: East US
    minTlsVersion: TLS1_2
    networkRules:
      defaultAction: Deny
      ipRules:
      -
      virtualNetworkSubnetIds:
      -
      -
    nfsv3Enabled: true
    publicNetworkAccessEnabled: true
    queueEncryptionKeyType: Service
    resourceGroupName:
    sharedAccessKeyEnabled: true
    tableEncryptionKeyType: Service
  initProvider: {}
  managementPolicies:
  - '*'
  providerConfigRef:
    name: crossplane-azure-provider
---
apiVersion: storage.azure.upbound.io/v1beta1
kind: Container
metadata:
  annotations:
    crossplane.io/external-name: dev-nfs
  name: dev-nfs
spec:
  deletionPolicy: Delete
  forProvider:
    containerAccessType: private
    storageAccountName: genxp0000001nfs
  initProvider: {}
  managementPolicies:
  - '*'
  providerConfigRef:
    name: crossplane-azure-provider

What happened?
Warning  CannotObserveExternalResource  1s (x9 over 8m4s)  managed/storage.azure.upbound.io/v1beta1, kind=container  (combined from similar events): failed to observe the resource: [{0 retrieving Container "dev-nfs" (Account "genxp0000001nfs" / Resource Group "rg-lz-npr-eastus-03"): containers.Client#GetProperties: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service returned an error. Status=403 Code="AuthorizationFailure" Message="This request is not authorized to perform this operation.\nRequestId:c638949e-d01e-0066-181b-fe3a6d000000\nTime:2024-09-03T16:10:04.6926215Z"  []}]

Relevant Error Output Snippet
No response
Crossplane Version
1.5.0
Provider Version
1.5.0
Kubernetes Version
No response
Kubernetes Distribution
No response
Additional Info
No response

Is it related to this? https://github.com/hashicorp/terraform-provider-azurerm/issues/2977


Notification System

Would be nice if we could have a bell icon near the user profile picture
This way we can inform them about the status of their reviews and stuff conveniently

For now users will need to check their review status through the "My Reviews" page

Integrate the kafka, when review is approved, rejected --> send toast message


Fix #27508: az network private-dns zone import: Cannot import when zone already exists

Related command

Description

Fix: https://github.com/Azure/azure-cli/issues/27508
Testing Guide

History Notes

[Component Name 1] BREAKING CHANGE: az command a: Make some customer-facing breaking change
[Component Name 2] az command b: Add some customer-facing feature

This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] The PR title and description has followed the guideline in Submitting Pull Requests.

[ ] I adhere to the Command Guidelines.

[ ] I adhere to the Error Handling Guidelines.

Thank you for your contribution! We will review the pull request and get back to you soon.

/azp run


Error while building

I'm getting an error while building the site
if i run the dev environment with
npm run dev
everything works normally
if i build the website with
npm run build
i get this

λ src/pages/og-image/[slug].png.ts
 error   Unsupported OpenType signature <!DO
  File:
    /tmp/astro-theme-cactus/node_modules/@shuding/opentype.js/dist/opentype.js:11450:18
  Code:
    11449 |        } else {
    > 11450 |            throw new Error('Unsupported OpenType signature ' + signature);
            |                  ^
      11451 |        }
      11453 |        var cffTableEntry;

The code is freshly cloned from github with NO modifications

It's clearly something related to opentype.js e therefore Satori, I tried removing the og-images directory (and it's content) and the site build correctly

Hi @hacktivateit, yep you're correct, unfortunately it looks like they're having server issues

Still down, i think it would be better to have those fonts offline as part of the project or to implement a failover if fontsource (or the user internet connection) is down

Should be fixed by #74


fix: fix widget ui minor bugs

Summary

[x] fix  input placeholder in Firefox
[x] some buttons colors are not correct
[x] fix max button not working when the balance is 0
[ ] fix animation for modal close -> Will be addressed in a separate PR.

Fixes # 1230
How did you test this change?
Tested this by running widget on Chrome and Firefox browsers and checking each of listed items.
Checklist:

[x] I have performed a self-review of my code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] Implemented a user interface (UI) change, referencing our Figma design to ensure pixel-perfect precision.

I resolved my comments since it was related to number 4 of the list which is going to be handled in a separate PR.


#[ffi_returns_twice]

Rendered.
Implementation PR.
Closes #2625.

My initial thought is that I’m not sure from the RFC what the soundness and safety implications are, e.g.:

I feel like you should only be able to apply this attribute to unsafe fn and maybe only externs.
Is it sound to allow this on a function that has parameters with lifetimes?
Is it safe to invoke drop in a function with this attribute?

I feel like you should only be able to apply this attribute to unsafe fn and maybe only externs.

This attribute can only applied to extern functions (wasn't that clear?), these are unsafe to call.

Is it sound to allow this on a function that has parameters with lifetimes?

C FFI is unsound.

Is it safe to invoke drop in a function with this attribute?

This RFC does not propose being able to implement these functions in Rust.

The RFC only mentions that it can be added to unsafe functions, but it does not explicitly prohibit use anywhere else (in fact, it doesn’t mention what happens for other types of functions at all). Perhaps that can be clarified?

The RFC only mentions that it can be added to extern functions, but it does not explicitly prohibit use anywhere else (in fact, it doesn’t mention what happens for other types of functions at all). Perhaps that can be clarified?

Uh, indeed. I meant functions in an extern { ... } block not fn "extern" .... I've replaced all uses of "extern" with "foreign", does that make it clear?

I thinks that’s a big improvement, but I think it would also be good to have a statement like “Adding this attribute to any other type of item is an error”.

This RFC adds a new function attribute, #[ffi_returns_twice], which indicates that an foreign function can return multiple times.

I find it confusing that the RFC always talks about returning multiple times but the attribute is called "twice".

I find it confusing that the RFC always talks about returning multiple times but the attribute is called "twice".

I do so too.
This attribute is called #[ffi_returns_twice] and only works in Rust FFI function declarations. Those need to match the C function declaration, and in C this attribute is called returns_twice for whatever reason (maybe returns_multiple_times was too long).
The only people that will need this attribute is those reading C code on one side, and writing the Rust FFI wrapper on the other. So keeping the name the same, even if its unfortunate, makes the lives of the only users that this attribute will have easier.

Since you have a couple of these ffi_* attributes, another alternative I'd like considered is having it be one attribute with different parameters #[ffi(returns_twice)], #[ffi(nounwind, readnone)], etc.
(I don't know if it's better, but if they interact with each other -- like IIRC you mentioned const and pure would -- it might be easier to check and read one attribute than multiple.)

@scottmcm see https://github.com/rust-lang/rfcs/issues/2637

cc @RalfJung

Basically all I ask is that you make sure this

In the presence of types that implement Drop, usage of APIs that return multiple times requires extreme care to avoid deallocating memory without invoking constructors.

is known to everyone using setjmp/longjmp.

Though shall not jump over stack frames though do not own.

Rust implementations of such libraries (for example, see: steed) should be able to call these platform interfaces without invoking undefined behavior.

Regarding steed, it is really an implementation of libcore/libstd, which are allowed to do things that other code isn't allowed to do.

Another alternative could be to not support interfacing with this type of platform APIs, requiring users to use a different programming language (C, Assembly, etc.) to do so.

My understanding is that the original motivation was that some PostgreSQL thing uses setjmp/longjmp to emulate something like C++ exceptions and in order to do support that PostgreSQL thing, it is suggested that setjmp/longjmp be supported. Yet, this, the actual motivation, isn't even mentioned in the Motivation section of the RFC. It should be mentioned.
Also, the RFC should mention C++ exceptions.
I support (1) NOT implementing this, and (2) promising we won't implement this any time soon. C++ exceptions and Windows's similar exception mechanism are in a lot more widespread use than setjmp/longjmp as far as I can tell, yet C++ have been (AFAICT) categorically rejected. This adds unnecessary complication to the implementation of Rust, especially implementations that aren't based on LLVM or similar things that already support C. Even compcert doesn't really support this kind of functionality fully. Further, even taking the time to discuss it is a highly questionable use of time. I intend to comment on this RFC again if and only if I change my mind; any silence from me should be interpreted as reinforcing my objection to this feature.

I think writing some glue code that calls Rust function alongside with all the setjmp/longjmp calls is enough for the motivation?
There is not much motivation for writing setjmps in Rust.
longjmp doesn't need this mechanism to get defined, though i'm not sure longjmping throughout the ffi boundary is defined behavior. if it isn't, it's not appealing to define it too, since you can't use it in any useful way.
The workaround is simply define a function in Rust that may return an error, when it does return a Err, the calling code longjmps to wherever it want.

This adds unnecessary complication to the implementation of Rust, especially implementations that aren't based on LLVM or similar things that already support C.

I am confused. The implementation of this takes <100 lines. That doesn't seem like a lot of complication. Also, LLVM supports this attributes, all we do is expose it at the Rust level.

Honestly, I'm not sure why Rust doesn't support C++ exceptions, at least unwinding across them (as opposed to catching them), if only to remove an undefined behavior footgun.  After all, panic handling already uses the same basic mechanisms as C++ exceptions (SEH on Windows, libunwind on Unix), and those OS mechanisms are already designed to support multiple languages at once via "personality" routines.  Part of the reason is probably that LLVM's support seems to be a mess.  Two quotes from two different parts of the rustc codebase:
// Note that MSVC is a little special here in that we don't use the
// `eh_personality` lang item at all. Currently LLVM has support for
// both Dwarf and SEH unwind mechanisms for MSVC targets and uses the
// *name of the personality function* to decide what kind of unwind side
// tables/landing pads to emit.

// This implementation uses the new exception handling instructions in LLVM
// which have support in LLVM for SEH on MSVC targets. Although these
// instructions are meant to work for all targets, as of the time of this
// writing, however, LLVM does not recommend the usage of these new instructions
// as the old ones are still more optimized.

I am confused. The implementation of this takes <100 lines. That doesn't seem like a lot of complication. Also, LLVM supports this attributes, all we do is expose it at the Rust level.

That is based on LLVM's implementation. What I said is that it is an unnecessary complication for implementations that "aren't based on LLVM or similar things that already support C."

Oh, sorry, I misunderstood.
Such implementations are not really worse off though. Without this attribute, they cannot call setjmp. With this attribute, they still cannot. Postgres is not the only API based on this, I know Lua does this as well -- though I wonder why they don't seem to need this attribute?

Such implementations are not really worse off though. Without this attribute, they cannot call setjmp. With this attribute, they still cannot. Postgres is not the only API based on this, I know Lua does this as well -- though I wonder why they don't seem to need this attribute?

It would be better for people to implement their PostreSQL (etc.) integration in a way that works without this attribute, to allow for new implementations to be able to use it. The harm in adding this attribute to the LLVM-based implementation is that things will use it and then that will increase the cost of creating compatible brand new implementations.

(Note: I have some other concerns about the idea of returns_twice specifically, and in particular about interactions with lifetime boundaries. This comment doesn't take that into account, and just addresses concerns about portability.)
While I don't believe we should provide support for completely LLVM-specific attributes, that's not the case here. returns_twice exists in both LLVM and GCC, and any compiler supporting the ability to call certain system functions would need to support it. If a compiler backend doesn't support that attribute, that would be a completeness issue with that compiler. rustc with such a backend could simply error if you try to declare a function with that attribute, and we could potentially implement a cfg mechanism to detect platforms lacking that support. (Or, implement it in those platforms, which might be easier.)
I don't believe, in general, that we should hold back from using functionality like this that LLVM implements.

What does this attribute actually do in LLVM?
I would've assumed it only disables certain optimizations, but maybe I'm wrong?

@eddyb In GCC at least, it's described as:

The returns_twice attribute tells the compiler that a function may return more than one time. The compiler will ensure that all registers are dead before calling such a function and will emit a warning about the variables that may be clobbered after the second return from the function. Examples of such functions are setjmp and vfork.

Then the implementation is misleadingly incomplete, since we should probably have the frontend diagnostics gcc (and presumably clang) have, regarding this, and possibly more.
The "dead registers" part can be emulated with the right asm! invocation AFAIK (see https://github.com/edef1c/libfringe for something similar to setjmp/longjmp but the control-flow is redirected in a cooperative multitasking way, so no double-returns), so I doubt backends would have more trouble with it than asm! itself.

@eddyb I tracked that down in an earlier thread:
https://github.com/rust-lang/rfcs/issues/2625#issuecomment-460849462
In particular, LLVM (and thus Clang) actually does not do the dead-registers thing; the effects are more subtle.

Thanks, that's pretty comprehensive.
I'm not sure "returns twice" is even the right way to describe this, it seems everything about it is designed around "capturing state".
Wouldn't you need all those effects even if you had a function which, after storing enough state, never returned the first time, but rather switched to some other execution (with a different stack pointer), to come back later and "returned" via longjmp?
If not, why? It's still a bit unclear to me why LLVM goes to such lengths (is it working around platform bugs/limitations?).
If yes, then maybe this could be made more general than "returns twice", and serve more purposes.
cc @sunfish @edef1c @Amanieu

Wouldn't you need all those effects even if you had a function which, after storing enough state, never returned the first time, but rather switched to some other execution (with a different stack pointer), to come back later and "returned" via longjmp?

Mostly no, one yes.
No:

Stack slot coloring (and wasm local coloring): has to do with the current function's stack frame.  It would normally allow a stack slot used for one variable at the time of setjmp to be reused for another variable later in the function if, based on the function's control flow, the original variable is dead.  This would be a problem if you longjmp back and then try to access the original variable.

Tail call optimization: also has to do with the stack frame.  If you do a tail call, the caller's stack frame will be clobbered in its entirety by the callee :)

Inlining: not a correctness issue AFAIK.  Rather, since the above two pessimizations apply to the entire function that contains a call to setjmp, avoid inlining it into another function since that would pessimize that function as well.

For the SPARC-specific check: well, I looked into it a bit more, and you probably don't care about the details, but TL;DR: on SPARC, after longjmp, registers will be restored to the most recent values they had within the setjmp-ing function, not the values they had at the time of setjmp.  This is the same behavior as stack variables.  But whereas reusing stack slots for unrelated things in a function is unusual (see above), reusing registers is necessary since there's only a fixed number of them; therefore the check just avoids saving data in registers across the call.

ASAN: supposedly because it introduces variables which might be modified between setjmp and longjmp (I think the check is wrong)

Yes:

The X86SpeculativeLoadHardening check is really about the fact that the "return" from longjmp may not be an actual ret instruction.  It should probably be fixed to also apply to coroutine-switching functions such as Unix swapcontext and Windows SwitchToFiber.  (X86SpeculativeLoadHardening is rather new code, being a Spectre mitigation.)

Postgres is not the only API based on this, I know Lua does this as well -- though I wonder why they don't seem to need this attribute?

Lua provides a function lua_pcall ("protected call") which encapsulates the setjmp for you.  I looked at rlua and hlua and they both use this.  Interestingly,  rlua also uses the non-protected lua_call in some circumstances, which can longjmp to an outer stack frame, killing the Rust stack frame in the middle.  That's a bit spooky, but it seems to be careful about it (not having variables with destructors in those functions)... anyway, that's not relevant to ffi_returns_twice.

@comex So all the pessimisations are all about reloading a saved state knowing it couldn't have been invalidated by anything "downstack" of the call that saved said state?
Which would mean "returns twice" is really "can return more than once", right? Other than for vfork I guess.
Couldn't a hypothetical setjmp take a closure instead of returning, making it a lot more like catch_unwind?
In Rust, that would mean jmp_buf can be passed to the closure by reference, ensuring it cannot be used outside of the scope it's valid for.
And longjmp could have semantics similar to unwinding, except without destructors running.

For my use case -- catching longjmps from C code -- a setjmp with semantics like catch_unwind sounds like it would also work. I might have to see some more details though to make sure I can set up the C globals properly to interface with the C code to longjmp to the right place.

Which would mean "returns twice" is really "can return more than once", right?

Correct (see the RFC).

Couldn't a hypothetical setjmp take a closure instead of returning, making it a lot more like catch_unwind?

I haven't tried but I believe you could implement similar APIs on top of setjmp, sigsetjmp, etc. I don't know if you could make them safe, you'll need a way to prevent closures not only from moving Drop types in, but also from using Drop types at all.

@gnzlbg Disallowing the closure having a Drop can be done with bounds on the closure itself (e.g. F: Copy, although that's a bit too restrictive), but restricting what the code inside does it outside the scope of Rust right now.
You'd need "no unwind cleanup in any code reachable from here" which is just as hard as reentrance restrictions (you can make a safe Cell::with_mut with those, they're really powerful inter-procedural analyses to expose via traits).

but restricting what the code inside does it outside the scope of Rust right now.

Yeah, I don't know if writing a catch_unwind-like API is worth it. It would restrict and contain the scope in which users need to make sure that no destructors are skipped, which adds some value, but within those scopes this would still need to be checked manually, so it wouldn't just allow you to rely on the compiler for catching issues with destructors.
There are also another whole variety of things that can trigger undefined behavior while performing a longjmp: not performing volatile reads / writes to memory that's modified between the setjmp and the longjmp (across multiple functions, e.g., if these functions get inlined), calling longjmp from a different thread (e.g. spawning a thread down the stack and calling longjmp there, or creating a task and sending it to an executor and trying to do longjmp from there), you need to be aware of signals, etc.

Yeah I was only interested in mitigating the "returns multiple times" and "can't longjmp after exiting the stack frame setjmp was called in" aspects, although you'd probably still need a way to tell LLVM about the state saving and potential downstack restore.
I wasn't thinking about destructors at all.

I'm against adding this.
If it was followed by support in the borrow checker, it would add extra baggage to an already very complex and critical component of the language. Extra complexity in the borrow checker for such niche feature is IMHO not acceptable.
OTOH without support in the borrow checker, these functions are inherently dangerous to use. It's questionable why to even try to use them in Rust when all Rust adds is more footguns. Calling an intermediate C function to access these two unusual functions seems perfectly fine, and it even makes the code safer and more robust, since in the context of C functions returning twice is easier to reason about.
For emulating exceptions (such as aforementioned Postgresql, as well as libjpeg and libpng), catch_unwind + panic!() is a much much better solution.

If it was followed by support in the borrow checker, it would add extra baggage to an already very complex and critical component of the language. Extra complexity in the borrow checker for such niche feature is IMHO not acceptable.

I'd guess its a good thing nobody is proposing that.

OTOH without support in the borrow checker, these functions are inherently dangerous to use

So is all unsafe code that we can't prove correct.

Note that #[returns_twice] only allows a function to return twice, nothing more, nothing less. vfork is such a function: the process gets cloned, so you end up with two processes, and the vfork function returns twice, once in each process. It returns different values each time, but it does not return two different values in the same process, so AFAICT this isn't really that dangerous at all.
Sure, #[returns_twice] is one of the many things one would need to get setjmp to work properly. But this RFC does not propose adding setjmp to the language, only adding an attribute to specify that some functions might return multiple times.

vfork is such a function: the process gets cloned, so you end up with two processes, and the vfork function returns a different value in each process (so it returns twice). AFAICT this isn't really that dangerous at all.

Actually vfork acts exactly like setjmp from the point of view of the language. The fact that you are missing is that vfork doesn't really create a new process: it creates a "thread" in the current process (sharing the same address space) and runs it on the same stack as the original thread.
Since another thread is using its stack, the original thread is suspended until the vfork child has either exited or called execve. Once that happens, the effects are just as if a longjmp has been performed back to the vfork call.
Incidentally this is also why, like with setjmp, it is UB for a vfork child to return from the function that called vfork.

Also, note that even fork is dangerous in some sense.

@kornelski I don't understand the point about catching a postgresql exception using catch_unwind + panic(). Are you saying that catch_unwind is guaranteed to catch a longjmp regardless of the argument to longjmp? Is that documented somewhere?

@jeff-davis No, never! You can't mix the two. But you can nicely replace it altogether. In case of libjpeg you set your error callback to extern "C" handler() {panic!()}.

@kornelski OK. My use case is working with postgres, and its error reporting / exception facility is based on longjmp. Even if I could replace it, I don't think panic!() would be appropriate, because sometimes those exceptions must be caught in C.
So I would really like some form of setjmp in rust, even if it's dangerous and must be used in very specific ways. #[ffi_returns_twice] seems like a reasonable solution, but my knowledge of rust internals is limited.

I was the one that personally suggested augmenting the borrow checker to account for multiple returns (to support library implementations of continuation mechanisms). I still have getting that through as a long-term goal, but if making it initially ffi-only and without borrow checker additions is the plan, well then.

@kornelski Do you mean with some #[unwind] attributes on the Rust side and compiling the C code with... -fexceptions I guess?
Otherwise unwinding is UB.

@eddyb Yes, that's what I mean. I realize it's not fully baked in Rust yet.

I see that this is merged and available in nightly (behind a feature gate). What is the path toward stabilization? Is more input/discussion needed, or just bake time?
If it helps, this addresses my use case.

This RFC specifies what the attribute does, and there are some issues that have been raised about the RFC but have not been resolved yet, so that would need to be done.
This RFC leaves the syntax as an unresolved question, so even if this RFC is merged, stabilization would be blocked on that issue being resolved. We will probably need a different RFC proposing a more holistic approach to FFI attributes in general. There is an issue open about that:  #2637 .

Interesting factoid: there are functions that might return twice for which this attribute would be incorrect. _xbegin or generally anything that starts a HTM region does not require this attribute.
The naming consistency with C, along with ffi or other similar prefix, helps to make it clear that rust is not doing anything different from clang, and porting of the rtmintrin.h more straightforward.

Interesting factoid: there are functions that might return twice for which this attribute would be incorrect. _xbegin or generally anything that starts a HTM region does not require this attribute.

@mtak- why would adding returns_twice to _xbegin be incorrect ?

@gnzlbg Because on the second return of setjmp and vfork, they are able to observe data on the stack and in caller-saved registers that has been modified by the first return. This is not the case with _xbeing since the CPU will revert any changes to memory and registers that may have occurred in a transaction, thus effectively "rewinding" execution to the _xbegin call perfectly.

That doesn't make it incorrect though, just unnecessary, right?
Or maybe that is always true for all functions, that in the worst case the attribute is unnecessary?

I guess you could say that about all functions. It is only necessary when the first return has visible side-effects, which is not the case with _xbegin because the hardware reverts any changes in the aborted transaction.
Essentially, consider the following code:
fn foo() -> i32 {
    let mut x = 0;
    let second_return = setjmp(env) != 0;
    x += 1;
    if second_return {
       return x;
    } else {
        longjmp(env);
    }
}

If the compiler is allowed to perform its normal optimizations, it will see that the address of x never escapes the function, and the return value can therefore be constant-folded to 1. However this is incorrect since the x += 1 line is executed twice because of the longjmp. The returns_twice attribute effectively tells the compiler to assume that all local variables may be clobbered by the setjmp call.
However if you used _xbegin and _xabort instead of setjmp and longjmp then foo can only ever return 1 since the full state is reverted by _xabort. The compiler does not need to treat _xbegin specially and can just const-propagate x to 1.

@Amanieu note that returns_twice does not even mark x as clobbered there. Reading / writing to it without using volatile is UB even if setjmp is returns_twice. @comex wrote a great summary of what returns_twice does here: https://github.com/rust-lang/rfcs/issues/2625#issuecomment-460849462
This does not invalidate your point about _xbegin.

Everything @Amanieu said.
The CPU is really taking care to undo everything up until the point of the _xbegin abort handler. With setjmp/longmp, the software/libc has the responsibility of undoing the parts it wants undone. For _xbegin a compiler barrier is about all that's needed.
On powerpc you can suspend and resume transactions, which might mean power's tbegin needs the returns_twice attribute, since side effects can occur in the middle of a transaction. However, I'm not sure what from @comex's would be necessary for tbegin.

FYI, I am now of the opinion that I think I would prefer a #[returns_twice] attribute that we would be able to commit to for Rust "in general", and not only for FFI, whatever that might mean, and even if one cannot write functions in Rust itself that return more than once. One might not be able to do this today, but maybe someday, with inline assembly, one will be able to.
In the meantime, I think it would be better to just require code that needs this to live on nightly, and provide, for example, a general #[llvm_attribute(...)] mechanism to apply LLVM attributes to function, arguments, etc. so that one can just write #[llvm_attribute(returns_twice)] and call it a day here.
I think that for the time being, it is more important for us to be able to gain experience with this on nightly, than to ship this as a stable feature. We can always come back to this later.
Thoughts?

Seems like a step backwards from not having LLVM be the only backend?

@Centril #[llvm_attribute(..)] would be perma unstable, with no intend to ever stabilize it. It would allow people to experiment on nightly with these, and other attributes, like the ones implemented in https://github.com/rust-lang/rust/pull/58327 . I think that for those attributes as well, I would prefer a solution that works for Rust in general, more than something that only works in C FFI.

@gnzlbg I appreciate that you are taking this all the way back to first principles, but it has left the problem quite open ended, and I hope there is some way we can work from both sides of the problem at once. While experimenting with a first-class #[returns_twice] attribute that works with FFI, inline asm, etc., we can also try to support the specific case of setjmp in libc.
The people who need it (like me) are probably better off with a supported setjmp that might be buggy than relying on undefined behavior, and whatever problems we do find can then be reported. It's likely to get a lot more use if there's a short- or medium-term path to stabilization.
We will need documentation around setjmp, just like C, to tell you how you can and can't use it, and suggest things like marking the caller #[inline(never)]. I don't think that kind of ugliness is avoidable anyway (at least not all of it).
My use case, by the way, is about writing complex extensions for postgres in pure rust. I just got an extension working that creates a background worker, listens on a port, and handles requests with tokio by passing queries to SPI (postgres internal query processing API), and returns the results to the client. I've been super happy with rust in every way, and I'm presenting the work at PGCon next week. There are only two holes in this story:

Rust and C strings don't align very well and require extra allocations (perhaps there are ways to mitigate this).
I'm relying on platform-specific code and undefined behavior to use setjmp for error handling.

@jeff-davis right now there is no setjmp, but we could expose it on nightly as an unstable feature. Would that work for you? Or do you need it on stable Rust ASAP ?

@gnzlbg I would like setjmp to be on a path to stable libc in the short to medium term. I would be very happy with that.

Note that this RFC does not stabilize setjmp, it just provides an attribute that allows calling setjmp via C FFI with less issues than what we have now.

@gnzlbg Right, setjmp is #2625 which is blocked on #2633 (this issue) which is blocked on #2637. If the latter two are still far out, I'll move the discussion back to #2625 to see if we can find a near-term solution.

I'm going to go ahead and close this; this exact area of work (longjmp, in partcular) is being worked on in the ffi-unwind project group (in which @gnzlbg has been active from time to time). This seems like it should be discussed in that context.

If you're like to learn about the ffi-unwind project group, check out this repository. =)


Add jsbsim bridge to enable jsbsim for px4 SITL on jsbsim

Describe problem solved by this pull request
Current SITL integrations either lack good aerodynamic simulation (gazebo) or does not support lockstep (flightgear). This has shown to be problematic on modeling complex aerodynamics for fixedwing / VTOL applications
Describe your solution
This is a PX4 HIL/SITL integration into JSBSim. JSBSim is an open source flight dynamics model (http://jsbsim.sourceforge.net/), which allows simulating complex flight dynamics behavior.
The implementation comes from Auterion/px4-jsbsim-bridge
and is directly integrated into JSBSim, allowing lockstep with PX4 SITL simulations.
The difference with flightgear-bridge is Flightgear is only used as a visualizer and is not part of the flight dynamics simulation. This means that the simulation rate does not depend on the render rates and can be sped up faster than realtime with lockstep.
Currently there are three models available which is the rascal(fixedwing), quadrotor_x(multirotor), hexarotor_x(multirotor) integrated into the bridge.
The visualization is done with flightgear and is done by the bridge sending UDP packets to flightgear. To disable the visualization HEADLESS=1 when running the make command.
The simulation can be configured through the configuration files under the config directory through a xml file.
Dependencies

JSBsim can be installed through one of the rolling releases
For visualization, the latest flightgear needs to be installed

Test data / coverage
The simulation can be run with the firmware with the following command for example
make px4_sitl jsbsim_rascal

@hamishwillee Docuementation will folllow

@Jaeyoung-Lim  This is great!
I want to ask how should I add new models (e.g. tailsitter)? thanks :smiley:

@xdwgood I will add documentation on how to configure the jsbsim-bridge. Prior to this, you would need a tailsitter jsbsim model.
You can find how this can be done in the jsbsim Reference Manual


Error on file lock when multiple instances are running parallel

Hello,
we having a Problem since some weeks. We updated some of our node-modules recently and since then we're getting some errors when the report is created.
We are running multiple instances parallel. We think the problem is, when two or more instances are trying to create the report nearly at the same time:
[chrome #01-118] [08:41:46] I/plugins -  	 Fail:  protractor-multiple-cucumber-html-reporter-plugin Runtime
[chrome #01-118] [08:41:46] E/plugins - 		Failure during postResults: EBUSY: resource busy or locked, unlink 'C:\dev\clientapplication\e2e\reports\assets\fonts\fontawesome-webfont.woff'
[chrome #01-118] [08:41:46] E/plugins - 		Error: EBUSY: resource busy or locked, unlink 'C:\dev\clientapplication\e2e\reports\assets\fonts\fontawesome-webfont.woff'
[chrome #01-118] 		    at Object.unlinkSync (fs.js:949:3)
[chrome #01-118] 		    at mayCopyFile (C:\dev\clientapplication\node_modules\multiple-cucumber-html-reporter\node_modules\fs-extra\lib\copy-sync\copy-sync.js:69:8)
[chrome #01-118] 		    at onFile (C:\dev\clientapplication\node_modules\multiple-cucumber-html-reporter\node_modules\fs-extra\lib\copy-sync\copy-sync.js:60:12)
[chrome #01-118] 		    at getStats (C:\dev\clientapplication\node_modules\multiple-cucumber-html-reporter\node_modules\fs-extra\lib\copy-sync\copy-sync.js:51:39)

[chrome #01-118] 		    at startCopy (C:\dev\clientapplication\node_modules\multiple-cucumber-html-reporter\node_modules\fs-extra\lib\copy-sync\copy-sync.js:41:10)
[chrome #01-118] 		    at fs.readdirSync.forEach.item (C:\dev\clientapplication\node_modules\multiple-cucumber-html-reporter\node_modules\fs-extra\lib\copy-sync\copy-sync.js:142:5)
[chrome #01-118] 		    at Array.forEach (<anonymous>)
[chrome #01-118] 		    at copyDir (C:\dev\clientapplication\node_modules\multiple-cucumber-html-reporter\node_modules\fs-extra\lib\copy-sync\copy-sync.js:141:23)
[chrome #01-118] 		    at mayCopyDir (C:\dev\clientapplication\node_modules\multiple-cucumber-html-reporter\node_modules\fs-extra\lib\copy-sync\copy-sync.js:131:10)
[chrome #01-118] 		    at onDir (C:\dev\clientapplication\node_modules\multiple-cucumber-html-reporter\node_modules\fs-extra\lib\copy-sync\copy-sync.js:120:12)
[chrome #01-118] 		    at getStats (C:\dev\clientapplication\node_modules\multiple-cucumber-html-reporter\node_modules\fs-extra\lib\copy-sync\copy-sync.js:48:32)
[chrome #01-118] 		    at startCopy (C:\dev\clientapplication\node_modules\multiple-cucumber-html-reporter\node_modules\fs-extra\lib\copy-sync\copy-sync.js:41:10)
[chrome #01-118] 		    at fs.readdirSync.forEach.item (C:\dev\clientapplication\node_modules\multiple-cucumber-html-reporter\node_modules\fs-extra\lib\copy-sync\copy-sync.js:142:5)
[chrome #01-118] 		    at Array.forEach (<anonymous>)
[chrome #01-118] 		    at copyDir (C:\dev\clientapplication\node_modules\multiple-cucumber-html-reporter\node_modules\fs-extra\lib\copy-sync\copy-sync.js:141:23)
[chrome #01-118] 		    at mayCopyDir (C:\dev\clientapplication\node_modules\multiple-cucumber-html-reporter\node_modules\fs-extra\lib\copy-sync\copy-sync.js:131:10)

Any movement on this? I am experiencing the same issue.

@Doschdn1 and @dannycohn
First of all this is cause by the https://github.com/wswebcreation/protractor-multiple-cucumber-html-reporter-plugin module and not with this module.
Secondly the architecture of Protractor Plugins is that it will will be called for each instance (read capability) in your config. This means that when an instance is done running, it will generate the report for you. This could mean in some situations the report is generated and at the same time a new report is generated locking the files.
There is no beforeLaunch and onComplete hook available within the plugin architecture that might be able to do that.
Maybe there is a way to not write files if the exists, might be a good option for a PR 😉

I just created a small fix for multiple-cucumber-html-reporter and release a fix version for https://github.com/wswebcreation/protractor-multiple-cucumber-html-reporter-plugin/releases/tag/v1.8.1.
I'm going to close this for now because it should not happen with the latest version anymore


Change Specimen "Name" field so avoid confusing user with taxonomic name

Current suggestions to replace "Name" under consideration: Number, Catalogue Number, Specimen Code.

Heavily requested at meeting

Decision made! Change the field "Name" to "Specimen number"

this keeps coming up with people I am trying to get to use Pbot, the term "name" for a specimen is confusing.
need to change "name" to "specimen number"


Scroll needed when upload a huge number of documents

Bug Report
Hey! When upload a huge number of documents the prompt text area dissapear an its unacessible

Fixed on dev!


Results Question

Hi! Thisi is a very insteresting paper. I have a question on results comparison.
In Table 6. Results of the KINS dataset,
AP_seg of Mask R-CNN + ASN : 25.62
AP_seg of PANet + ASN  : 26.81
But in [46]Amodal instance segmentation with kins dataset,
AP_seg of Mask R-CNN + ASN : 31.1
AP_seg of PANet + ASN  : 32.2
AP_Det values are also different.
Why these results are different?

Hi, thanks for the question. I think it is due to the selection of different backbone networks, like resnet-50 and resnet-101 etc, which is not detailed in their paper. Thus, I obtained the results by running their official code for comparison.


add --unprocessed-images-inspect flag

Sketch for conversation: https://kubernetes.slack.com/archives/CH8KCCKA5/p1630636823106500

any thoughts on naming and output for processed images?

any thoughts on naming and output for processed images?

Updated per suggestions. E2E tests are running (takes ~30min); these changes should have no affect on them.


"Uncaught TypeError: Cannot call method 'apply' of undefined" while running Angular based on WebPack with Cordova.

Do you want to request a feature or report a bug?
Bug report.
What is the current behavior?
While running Angular app with Cordova, I see only white screen on device and error "Uncaught TypeError: Cannot call method 'apply' of undefined in vendor.bundle.js:5706" in chrome://inspect/#devices. Angular not works in Cordova+WebKit nor Cordova+Crosswalk.

If the current behavior is a bug, please provide the steps to reproduce.

No errors in console and "App works!" text on device screen.
Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.
Angular version: 4.2.4 (latest)
Browser - Android WebView version 33
Browser - Crosswalk WebView version 23
Node version: 6.11.0
Platform: Windows 10 x64
Cordova version 7.0.1
Android version 4.4 KitKat
Crosswalk version 23

Is Object.assign available in this environment?

Problem solved by including polyfill core-js/es6/Object

Can anybody further elaborate on the above comment pls ?

@ichorville my PC is now broken cause of electricity events on my street (I have recoverable UEFI problem), so I can't remember what's file you must edit. Maybe it was polyfills.ts

@ichorville (offtop) can you explain why most of devs are indians? XD

@z56 Asians probably lol :D


Module Health: Node Manager: First Iteration

This PR seeks to provide modular health status checking on the "node manager" component of the Agent. Specifically the goals are:
Intentions of this PR:
Bubble-up all errors in Linux node handler code
Node Manager related code relies heavily on logging (or just ignoring) errors far down the stack, instead of bubbling them up.
The result of this is:

Logged errors have little context on the root event causing them to be invoked.
It's hard to trace failure from a particular event relating to all reconcile procedures that need to run.
It's hard to definitively to say if reconciliation for a Node Event was successfully.

The changes in this PR seek to address this by handling and bubbling up all relevant errors that may be encountered while doing Linux Node update reconciliation logic.
As well, this PR seeks to avoid any changes to the control-flow logic of the reconciliation by not immediately returning at places where errors may occur.
Rather, this follows a pattern of combining lists of errors into relevant/scoped multi errors (using the multierr library). All code will execute as before, with the difference being that errors are handled up the stack.
Use Hive's Modular Health Reporter to report status of node manager.
This is a first attempt at trying to manage health status for a module.
Follow up work:

Investigate Reconciliation: Break Linux node logic into atomic and idempotent tasks that can be executed and retried (+ reported on more easily).

@timoreimann @chancez
I was running into some issues with seeing my force-pushed changes on the last PR, when I closed it it no longer allowed me to reopen that one so I had to fully recreate it 😵💫
Please refer to some of my previous comments on the last PR: https://github.com/cilium/cilium/pull/25912

/test

/test

/test

/test

/test

/test

/test-1.26-net-next

/test

/test

@pippolo84 Reworked the manager test, should be much more reliable now PTAL.

/test

/test-1.24-5.4

/test-1.26-net-next

/test

Looks like this needs a rebase!

@pippolo84 Had to make some clustermesh changes in last rebase, mind taking a look/re-approving for those changes?

@jibi Mind taking a look at this for cilium/ipsec 🥺

/test

@brb could you take a look at this as well for sig-ipsec? jibi is no longer on that review team.

/test

/test

/test

/test

@tommyp1ckles I will hold off on merging for now given the open nits of Martynas, if you don't want to address them now and just merge thats also fine by me, just give the signal.

@dylandreimerink @brb leaving in the logging was a conscious choice, this is already a large PR so I wanted to avoid making too many changes that might affect debugging ipsec.  I'd like to do that in a follow up PR.

Depending on how far down this track we think it's viable to go during the v1.15 cycle, we may want to nominate this for release-note/major to highlight during v1.15 final release communications about how we're making Cilium easier to understand, operate and debug through more structured health visibility.

@tommyp1ckles can you write a release note that is user-facing? Thanks! Don't forget to use the right format so that the automation picks it up.


auto suggest soql bug

auto suggest
foo,ba
suggest bar
but replace to bar instead of foo,bar

after few try I do not succeed to reproduce....


Implement account.username

As described in https://github.com/hoodiehq/hoodie-client-account#accountusername
See how hoodie.id is implemented in hoodie-client for comparison

I'll take this one as I need it for a project by Sunday


simple-cipher: Disallow mixed case key

This test has already been added to the TypeScript version of this exercise. The JavaScript example implementation already passes, but I still think the test is valuable as I've seen the same error in JavaScript student submissions.
A solution that checks if the key is valid (i.e. only contains alpha ascii lower-case letters) by testing
if (key === key.toUpperCase()) { throw new Error('Bad key') }`

passes the current "throws an error with an all caps key" test but allows mixed-case keys, which should actually be invalid.

Good point @matthewmorgan!
I've created a PR to add the test to the canonical test file for the problem.

Awesome!  Thanks for doing that.  I'm not a maintainer on that track, but they tend to be pretty speedy about giving feedback.


allow setting epic when creating a Shortcut story

Description
This allows setting the epic when creating a story using the Shortcut extension.
Screencast

Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

Hi @BrianHicks 👋
Thanks for your contribution 🔥
@Yukaii could you check this?


DatePicker doesn't complete date input if calendar is not rendered

Describe the bug
DatePicker doesn't correct/complete date string in input, if open property is false.
To Reproduce
Steps to reproduce the behavior:

Pass open={false} prop to DatePicker
Start typing your date, but not complete it.
Leave the input.
Your input string stays as is, instead of complete to closest valid date.

Expected behavior
DatePicker should behave similar to when open={true} or open={undefined} and correct/complete user input.
Screenshots
With calendar:

Without calendar:

Desktop (please complete the following information):

OS: any
Browser any
Version any

Smartphone (please complete the following information):

Device: any
OS: any
Browser any
Version any

Additional context
In my use case I need to use DatePicker without calendar. I've not found any prop to disable/hide calendar except of open. But when I'm using it I'm losing all the cool features with visual date correctness/complete (only in state layer).

@khanilov any solution or workaround you found  ?

@khanilov any solution or workaround you found  ?


Parse errors

Hi,
I'm having some many parsing errors like this one with different already type-checked files.
Sometimes happens but not always. I'm using Agda 2.6.0. Is this version supported?

And another issue is when it gets stuck while type-checking some codes.
I'm sorry, this time I couldn't find the MBPs, but I'm sure these need attention. hehe
Maybe this is something about my installation? I don't know.

Thank you for reporting this!
There's nothing's wrong about your installation. (However, you might will want to upgrade from Agda-2.6.0 to Agda-<IP_ADDRESS>)
I've found a glitch in the parsing and fixed it, the patch is on the way!

Please reopen this issue if the problem persists

The holes are not showing up. They keep the question mark, any reason?
PD. I updated the Agda version.

@jonaprieto sorry for the inconvenience, did that parse error occurred again after you've upgraded to v0.9.3?
Is the holes not showing up thing related to the previous parsing issue, or another issue of its own?

@jonaprieto sorry for the inconvenience, did that parse error occurred again after you've upgraded to v0.9.3?
Yes, it did.
Is the holes not showing up thing related to the previous parsing issue, or another issue of its own?
I might say yes, it is a different issue, but I'm not sure. Btw, it seems the holes in comments are also being active, you can jump to them with ctrl+c+f.

@jonaprieto  I see, could you please open another issue for the holes? (Also it would be nice to attach a example Agda file for reproducing the issue).
I'm closing this issue to mark the parse errors solved.


AttributeError: function 'bleu_zero_init' not found

python XSum-Topic-ConvS2S/generate.py D:\NLP\XSum\XSUM-EMNLP18-topic-convs2s\topic-convs2s-emnlp18\data-topic-convs2s --path D:\NLP\XSum\XSUM-EMNLP18-topic-convs2s\topic-convs2s-emnlp18\checkpoints-topic-convs2s\checkpoint_best.pt --batch-size 1 --beam 10 --replace-unk --source-lang document --target-lang summary --doctopics doc-topics --encoder-embed-dim 512 > test-output-topic-convs2s-checkpoint-best.pt
Traceback (most recent call last):
File "XSum-Topic-ConvS2S/generate.py", line 164, in
main(args)
File "XSum-Topic-ConvS2S/generate.py", line 88, in main
scorer = bleu.Scorer(dataset.dst_dict.pad(), dataset.dst_dict.eos(), dataset.dst_dict.unk())
File "D:\PycharmFile\XSum\XSum-Topic-ConvS2S\fairseq\bleu.py", line 44, in init
self.reset()
File "D:\PycharmFile\XSum\XSum-Topic-ConvS2S\fairseq\bleu.py", line 50, in reset
C.bleu_zero_init(ctypes.byref(self.stat))
File "D:\python3.6.8\lib\ctypes_init_.py", line 361, in getattr
func = self.getitem(name)
File "D:\python3.6.8\lib\ctypes_init_.py", line 366, in getitem
func = self._FuncPtr((name_or_ordinal, self))
AttributeError: function 'bleu_zero_init' not found
And the output file "test-output-topic-convs2s-checkpoint-best.pt":
Loading  D:\NLP\XSum\XSUM-EMNLP18-topic-convs2s\topic-convs2s-emnlp18\data-topic-convs2s\dict.document-lemma.lda.txt
Done!
Loading  D:\NLP\XSum\XSUM-EMNLP18-topic-convs2s\topic-convs2s-emnlp18\data-topic-convs2s\test.document
Done!
Loading  D:\NLP\XSum\XSUM-EMNLP18-topic-convs2s\topic-convs2s-emnlp18\data-topic-convs2s\test.summary
Done!
Loading  D:\NLP\XSum\XSUM-EMNLP18-topic-convs2s\topic-convs2s-emnlp18\data-topic-convs2s\test.document-lemma
Done!
Loading  D:\NLP\XSum\XSUM-EMNLP18-topic-convs2s\topic-convs2s-emnlp18\data-topic-convs2s\test.doc-topics
Done!
| loading model(s) from D:\NLP\XSum\XSUM-EMNLP18-topic-convs2s\topic-convs2s-emnlp18\checkpoints-topic-convs2s\checkpoint_best.pt
| [document] dictionary: 50004 types
| [summary] dictionary: 50004 types
| D:\NLP\XSum\XSUM-EMNLP18-topic-convs2s\topic-convs2s-emnlp18\data-topic-convs2s test 5 examples

I am facing the same issue. Has anyone found the fix?

I am facing the same issue. Has anyone found the fix?

Following https://github.com/pytorch/fairseq/issues/292  fixed the problem

I am sorry I did not fix the problem. I left it and did other things.


Verification check when API key is added

Make a randomized call to the API to verify that the key entered by the user works correctly.
If the call results in an error due to verification failure, prompt the user to re-enter their API key.

I will do that.

How do you intend to add this check?


Provide OSGi Meta-information

To make it easier to use this lib in OSGi-Env it would be cool to add OSGi-Metainfos to the Manifest. This can be done manually or automatic e.g. with http://njbartlett.name/2015/03/27/announcing-bnd-maven-plugin.html
Since this meta-infos are only added to the manifest and no other dependecies are introduced this can be done without influence other usages.
This relates to https://issues.apache.org/jira/browse/WICKET-6402 / https://ops4j1.jira.com/browse/PAXWICKET-486

Maybe you can provide PR?

Can you tell if this is already released (what version?)

Latest version is 1.0.10, it was released in October, so it should have these changes ....


Incorrect token type for Figma variable with an alias

I have an issue where dimension tokens are being exported as color tokens. In the sample below, I'd expect the space.component.button.inside tokens to be dimension, not color tokens.
Here is an example file with Figma variables set up with aliases that produce this output.
https://www.figma.com/file/1eQQNyiQprQJ8GlJnjnDzT/Untitled?type=design&node-id=0%3A1&mode=design&t=axtP1XAWGj3kvM9x-1
{
  "dimension": {
    "default": {
      "base": {
        "25": {
          "type": "dimension",
          "value": 4,
          "extensions": {
            "org.lukasoppermann.figmaDesignTokens": {
              "mode": "Default",
              "collection": "dimension",
              "scopes": [
                "ALL_SCOPES"
              ],
              "variableId": "VariableID:1:3",
              "exportKey": "variables"
            }
          }
        },
        "50": {
          "type": "dimension",
          "value": 8,
          "extensions": {
            "org.lukasoppermann.figmaDesignTokens": {
              "mode": "Default",
              "collection": "dimension",
              "scopes": [
                "ALL_SCOPES"
              ],
              "variableId": "VariableID:1:4",
              "exportKey": "variables"
            }
          }
        },
        "75": {
          "type": "dimension",
          "value": 12,
          "extensions": {
            "org.lukasoppermann.figmaDesignTokens": {
              "mode": "Default",
              "collection": "dimension",
              "scopes": [
                "ALL_SCOPES"
              ],
              "variableId": "VariableID:1:5",
              "exportKey": "variables"
            }
          }
        },
        "100": {
          "type": "dimension",
          "value": 16,
          "extensions": {
            "org.lukasoppermann.figmaDesignTokens": {
              "mode": "Default",
              "collection": "dimension",
              "scopes": [
                "ALL_SCOPES"
              ],
              "variableId": "VariableID:1:6",
              "exportKey": "variables"
            }
          }
        },
        "125": {
          "type": "dimension",
          "value": 20,
          "extensions": {
            "org.lukasoppermann.figmaDesignTokens": {
              "mode": "Default",
              "collection": "dimension",
              "scopes": [
                "ALL_SCOPES"
              ],
              "variableId": "VariableID:1:7",
              "exportKey": "variables"
            }
          }
        },
        "150": {
          "type": "dimension",
          "value": 24,
          "extensions": {
            "org.lukasoppermann.figmaDesignTokens": {
              "mode": "Default",
              "collection": "dimension",
              "scopes": [
                "ALL_SCOPES"
              ],
              "variableId": "VariableID:1:8",
              "exportKey": "variables"
            }
          }
        }
      }
    }
  },
  "space": {
    "default": {
      "semantic": {
        "inside": {
          "x-small": {
            "type": "dimension",
            "value": "{dimension.base.50}",
            "extensions": {
              "org.lukasoppermann.figmaDesignTokens": {
                "mode": "Default",
                "collection": "space",
                "scopes": [
                  "GAP"
                ],
                "variableId": "VariableID:1:10",
                "exportKey": "variables"
              }
            }
          },
          "small": {
            "type": "dimension",
            "value": "{dimension.base.75}",
            "extensions": {
              "org.lukasoppermann.figmaDesignTokens": {
                "mode": "Default",
                "collection": "space",
                "scopes": [
                  "GAP"
                ],
                "variableId": "VariableID:1:12",
                "exportKey": "variables"
              }
            }
          },
          "medium": {
            "type": "dimension",
            "value": "{dimension.base.100}",
            "extensions": {
              "org.lukasoppermann.figmaDesignTokens": {
                "mode": "Default",
                "collection": "space",
                "scopes": [
                  "GAP"
                ],
                "variableId": "VariableID:1:13",
                "exportKey": "variables"
              }
            }
          },
          "large": {
            "type": "dimension",
            "value": "{dimension.base.125}",
            "extensions": {
              "org.lukasoppermann.figmaDesignTokens": {
                "mode": "Default",
                "collection": "space",
                "scopes": [
                  "GAP"
                ],
                "variableId": "VariableID:1:14",
                "exportKey": "variables"
              }
            }
          },
          "x-large": {
            "type": "dimension",
            "value": "{dimension.base.150}",
            "extensions": {
              "org.lukasoppermann.figmaDesignTokens": {
                "mode": "Default",
                "collection": "space",
                "scopes": [
                  "GAP"
                ],
                "variableId": "VariableID:1:15",
                "exportKey": "variables"
              }
            }
          }
        }
      },
      "component": {
        "button": {
          "inside": {
            "start": {
              "type": "color",
              "value": "{space.semantic.inside.medium}",
              "extensions": {
                "org.lukasoppermann.figmaDesignTokens": {
                  "mode": "Default",
                  "collection": "space",
                  "scopes": [
                    "GAP"
                  ],
                  "variableId": "VariableID:1:17",
                  "exportKey": "variables"
                }
              }
            },
            "bottom": {
              "type": "color",
              "value": "{space.semantic.inside.small}",
              "extensions": {
                "org.lukasoppermann.figmaDesignTokens": {
                  "mode": "Default",
                  "collection": "space",
                  "scopes": [
                    "GAP"
                  ],
                  "variableId": "VariableID:1:18",
                  "exportKey": "variables"
                }
              }
            },
            "end": {
              "type": "color",
              "value": "{space.semantic.inside.medium}",
              "extensions": {
                "org.lukasoppermann.figmaDesignTokens": {
                  "mode": "Default",
                  "collection": "space",
                  "scopes": [
                    "GAP"
                  ],
                  "variableId": "VariableID:1:19",
                  "exportKey": "variables"
                }
              }
            },
            "top": {
              "type": "color",
              "value": "{space.semantic.inside.small}",
              "extensions": {
                "org.lukasoppermann.figmaDesignTokens": {
                  "mode": "Default",
                  "collection": "space",
                  "scopes": [
                    "GAP"
                  ],
                  "variableId": "VariableID:1:20",
                  "exportKey": "variables"
                }
              }
            }
          }
        }
      }
    }
  }
}

This repo is awesome and your focus on the spec too. I want to get into working with the spec as defining your own can be tough. I noticed you were looking for more dev help on this project from your bio. Let me know if I can help in the implementation on this 👍
In any case, I work with Andrew. A few things I've noticed so far:

The type is being set so that's good because the spec seems intent on having a type: "A token's type can be set directly by giving it a $type property specifying the chosen type. Alternatively, it can inherit a type from one of its parent groups, or be an alias of a token that has the desired type."
color type seems to be the default type for handling variables https://github.com/lukasoppermann/design-tokens/blob/bec866ae0bbb5b2704f6aca3dce8b841ada2ba4e/src/utilities/getVariables.ts#L11. Yet the output here does not have the blend mode set so I don't think that this color type is getting all the way to the color category https://github.com/lukasoppermann/design-tokens/blob/bec866ae0bbb5b2704f6aca3dce8b841ada2ba4e/src/transformer/standardTransformer.ts#L274
Yet it is a fallback for object value. https://github.com/lukasoppermann/design-tokens/blob/bec866ae0bbb5b2704f6aca3dce8b841ada2ba4e/src/utilities/getVariableTypeByValue.ts#L4-L5  Since we're working with aliases of aliases, I wonder if the object value may be getting set. We're not having issues with single alias values. (Based on product requirements, we're working with aliases of aliases that can inherit based on user preference.)

Based on the observations and figma linked, I was curious about how best to approach this in your experience. I noticed that there were integration tests including aliases in the standard tokens json.
Since this is using a color, it would be hard to test a non-color type.
https://github.com/lukasoppermann/design-tokens/blob/bec866ae0bbb5b2704f6aca3dce8b841ada2ba4e/tests/files/standard-tokens.json#L674
      "ref blue": {
        "description": "Some other description",
        "type": "color",
        "value": "{color.colors.single blue}",
        "blendMode": "normal",
        "extensions": {
          "org.lukasoppermann.figmaDesignTokens": {
            "styleId": "S:a466a5c4f753617558885425bf0c42b7a53fcda4,",
            "exportKey": "color",
            "alias": "color.colors.single blue"
          }
        }
      },

Thanks so much for the time!


Need package `company-0.9.0', but only 0.8.12 is available

I'm unable to install interno. It is failing with following error.
Need package `company-0.9.0', but only 0.8.12 is available
I refreshed package content and I could see only version of 0.8.12 of company package available in MELPA repo.
Is there any thing I'm missing here

Hm. Perhaps you are on melpa stable? 0.9 is on MELPA presently.
But I can set the lower bound to 0.8.12, I'm not using any fancy features of company.


Feature request - Join Battery voltage and Signal level to device

##Hello yesterday installed your plugin and replaced xiaomi gateway, allready all works great (better signal and faster response imho). One thing (feature request):
can you join device, battery and signal to have one id... (its supported in domoticz, for example my rflink devices use this)?
with this i can have one id device instead of three...
dunno how to handle this with device with multiple id actions (maybe copy signal and battery to all device ids)
thanks for your work :)

Currently plugin adds information about battery and signal level to each device. Is it what you need or you meant something else?

oh i see its reporting now (maybe it take some time before its start reporting batery and signal). Extra idx with signal and idx is wasting memory imho if its allready reported in device. Maybe creating extra idx with signal and battery could be only option.

noticed one more thing - when i remove signal and battery idx devices in list and Zigbee pairing:
and then when i use device with removed idxs (mem and signal) log is full of errors
Error: (ZB) Device creation failed, Domoticz settings prevent accepting new devices.
can we disable this warning (at least for subdevices, where is allready one idx used)


Fix method signature to comply with the interface implemented by the class

Hi!
First of all, thanks for this great tool!  🙂It's really going to improve automated browser testing with Laravel Dusk.
When running php artisan dusk:dashboard I get error that declaration of onMessage method on BeyondCode\DuskDashboard\Ratchet\Socket class is not compatible with the signature of Ratchet\WebSocket\MessageCallableInterface interface that is implemented through Ratchet\WebSocketMessageComponentInterface.
See the screenshot:

This PR fixes that.
Thanks again!

Thanks. No idea why it didn't complain on my end.

Don't know, but I've noticed this happens when using PHP 7.1 but not with version 7.2


Actor - Activities - Opposed ability value removed from chat card save button

Previous to the 0.10.046 release, the chat card button for a save contained the ability as part of the text.  For example, “DC 17 Dexterity Save” vs. “DC 17 Save”

Looks like it was using the DC calculation ability rather than the save ability when trying to make the label.


Images slow elfeed to a crawl

Images/gifs in an article slow Emacs/elfeed to a crawl. Even just hitting "n" to go to the next article can take upwards of 5 seconds. Gifs are especially problematic.

This is a known issue with Emacs itself. What's worse, I've found that
SVGs often hard crash Emacs. Elfeed just puts the images in the buffer
and the rest is handled by Emacs. Also, I don't remember if images are
downloaded asynchronously or not, so that may be part of the delay.

Is there an option to disable images by default (and then, hopefully, a command to toggle them on)?

Sorry, I should have mentioned this in my other response. Entry
rendering is done with the built-in package shr (Simple HTML Renderer).
This is undocumented, but currently you can set shr-inhibit-images to
non-nil to disable images.


New version selection experience

Changes

New dropdown control to select version of current product

Warning for outdated documentation

Cleanup of navigation rendering logic

Preview: https://chilly-version-selection.netlify.app/docs/hotchocolate/

Looks pretty good!

@rstaib done!
Could we maybe first get #3879 in, then I can re-use the variables I declared there here.

@tobias-tengler merged #3879 👍


Allow users to change type checking problems from 'errors' to 'warnings' (or 'information').

Type checking in VSCode reports type violations at the bottom of the VScode screen--as errors in red in the 'Problems' tab (screenshot).  It would be nice to be able to change this to another type of notification (in another color) like warning or information (as in this screenshot).
If this is already possible, can you please let me know how to approach it?  I've asked on Stack Overflow (see here), but there were no answers.
In my case, I do not have TypeScript installed in my project, so ignoring these errors will not result in any compile errors for me.
But I have many JSDoc block tags in my code, and I'd like to use VScode's type checking feature to read these and notify me when I call functions with type violations.
The reason I would like this feature is because in many of my project files, as soon I turn on type checking, scores (even hundreds) of type violations suddenly appear in the 'Problems' tab, making it very cluttered.  I rely on the Problems tab to notify me of critical errors--those that will result in some error thrown (e.g. parse errors)--so having it cluttered with hundreds of non-crtical notifications reduces its utility.  Of course I would like to fix all of the type violations, and I hope to do that at some point.  But right now I'm not approved for that :-(
Thanks.

/duplicate

https://github.com/microsoft/vscode/issues/66982

Thanks for the reply.  I see you've marked this as a duplicate to this post.  But I had a read, and that looks to be a separate request from mine--one to resolve a separate issue.  That request is to allow users to completely clear the entries in Problems tab.  I don't want to clear any entries from the Problems tab--I want to see them all.  What I want is the option to change the 'designation' certain entries (the entries from VSCode's type checking feature)  from red 'errors' to yellow 'warnings' or  'information' (as per the icons in this screenshot).
Again, I think the type checking entries in the Problems tab are helpful, and very much want to read/process them.  I'd just like to ensure they are displayed as something other than red errors.
Do you still think mine is a duplicate request?

Ok I see. Thanks for detail explanation.
These diagnostics are provided by extensions and they own all information of them. Please file an issue against the corresponding extension providing these diagnostics. FYI our CSS extension also provides customization to switch from warning to errors.

These diagnostics are provided by extensions and they own all information of them

The behavior and issue I am describing is not related to any extension. It pertains to this native VSCode feature:  Type checking JavaScript.

Assigning to @mjbvz since it is related to TS.

This is tracked upstream by https://github.com/microsoft/TypeScript/issues/13408
It's a long running discussion so if you have something new to add, please share it on that issue

@mjbvz OK thanks for that.
@sandy081 earlier you mentioned, "FYI our CSS extension also provides customization to switch from warning to errors."  Can you tell me which CSS extension you are referencing?


In callback function array is not visible from scope

Hi,
when you run $scope.AddItem function for example 3 times and call function $scope.Test you will see that the size of $scope.items is equal 3.
But when you click 'del' you will see that $scope.items size is 0.
Why ?
        hotkeys.bindTo($scope)
            .add({
                combo: 'del',
                description: 'blah blah',
                callback: function () {
                    $scope.Test();
                }
            })

            $scope.Test = function()
            {
                alert($scope.items.length);
            }

            $scope.AddItem = function()
            {
                $scope.items.push({ test: 'Test' });
            }

Works fine for me: https://plnkr.co/MtiI5X

The link does not work. Can you send working example ?


[L] Convert Lambda Function to SAM

Description:
As one of the first steps to "Samifying" A&R we need to convert the lambda functions to work with sam. This will include changing imports, including layers, adding functions to template, setting up dependencies, and testing locally.
Acceptance Criteria:
API builds locally. All functions have been invoked and tested with local setup.
Development Checklist:

[ ] Lambda Function meet SAM Requirements
[ ] All Lambdas build and function locally using the SAM API

Dependencies

Blocked by
Blocking

Relevant documentation as reference
Definition of Ready

[ ] Acceptance criteria are included
[ ] Wireframes are included (if applicable)
[ ] Design / Solution is accepted by Product Owner (if applicable)
[ ] Dependencies are identified (technical, business, regulatory/policy)
[ ] Story has been estimated (under 13 pts)

Definition of Done

In progress:

[ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
[ ] UI meets accessibility requirements
[ ] Unit tests are written
[ ] Work is traceable in GitHub
[ ] PR linked to ticket number
[ ] If needed/required - Dev adds flag/label to highlight any migration steps necessary prior to PROD deployment

Code review:

[ ] Code is peer reviewed and has passed CI/CD tests

QA:

[ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
[ ] Code is potentially shippable to the production environment
[ ] Functional features have been tested and passed by QA
[ ] UI components tested by designer
[ ] Code is deployed to PROD when moved to 'done' column (unless requested otherwise by PO)

PO Review:

[ ] Acceptance criteria are tested (Functionality meets the acceptance criteria defined in the ticket)
[ ] Reviewed and approved by Product Owner

Notes:

Testing will be done using the main ticket https://github.com/bcgov/bcparks-ar-api/issues/291. Moving this to PO review.

Testing will be completed in #291 - moving to done.


Limit total number of word examples and phrases

Currently, the backend will return all the examples and phrases associated with that word.
But as the number of phrases and examples associated with a word grows, we should limit the data that gets handed over to the client.
Limit a word's examples and phrases array down to 3.

Hi @ijemmao, Is anyone on this already or do I take it up?

@Ebugo Hey, yeah this ticket is actually outdated since we removed the concept of Phrases. You can pick up another ticket that you find interesting!

Okay, thanks. I'm now working on the web scraping issue.


Update web payments samples.

Use a merchant ID and Stripe publishable key in Android Pay demo.
Simplify feature detection.
Listen to 'shippingaddresschange' events when requesting shipping
information.
Print 'languageCode' of the shipping address.

Addresses comments. PTAL.

👍


Renovate bot doesn't create PRs

It seems renovate bot doesn't work anymore. Otel core repo was released more then a week ago but still no PR.

Update: We're having issues troubleshooting as we can't access logs, I'm talking to the renovate folks to see what we can do about it.

Getting a hold of the logs took more work than expected. The fix I came up with looks unrelated, but it looks like a docker image that's been removed from Docker Hub is making the bot fail. Opened #1458 to update it to the latest collector.

Closing this as the PRs were updated when #1458 merged.
Looks like it's intentional that the bot does not continue when the images go missing from docker hub: https://github.com/renovatebot/renovate/discussions/21248#discussioncomment-5522649


⚠ universalis has degraded performance

In 6ca0985, universalis (https://universalis.app/) experienced degraded performance:

HTTP code: 200
Response time: 10947 ms

Resolved: universalis performance has improved in 7888a90.


adds decommission support to SQLOperations

DecommissionService calls enable/disable on SQLOperations
now instead of the transport sql actions in order
to forbid/allow processing of new sql statements

@matriv pls review

Igtm.


[microTVM][Zephyr] Add skip for AOT test

This PR adds pytest.skip for platforms that cannot fit the model.

@mehrdadh Thanks a lot for improving the AOT test suite by skipping boards like ST Disco board, where the test in question doesn't fit! Also thanks for making it clear that the error number is a hex number. Small but important changes! :) The CI has failed, but I've got the same error in "BUILD: CPU" for my changes in PR 8613, which is a pure textual change, so I believe it's a CI glitch again (re-trigger so?). Bummer. The change LGTM!

thanks for the review @gromero! I just triggered it.


Donation account deeplink issue.

When we paste donation link in browser it provides me option "Open with hexa or different app" and when we open it with hexa it opens in hexa app but nothing happens after that.
So, it should open in browser and not in hexa app.
I have Hexa 1.0,Hexa live app 2.0.5(381) and Hexa staging app 2.0.5(381) installed on phone.But the option is showing only Hexa 1.0 app.
This is happening on Android upgraded app from 2.0.5(379) to 2.0.5(381) and also on newly installed app.

Should not be needed when we decommission 1.0

is this issue fixed

This issue is not reproducible.

Unable to reproduce this issue on dev app v2.0.80(485)


DNVM produce incorrect script for adding to PATH for non-English users

When I resolve issue with white spaces in the path I encounter next issue this time with non-English characters in the path. My path is C:\Users\Wojtek Gadziński\.dnx\...
When dnvm.ps1 generate temp script for adding runtime to the PATH is used cmdlet Out-File with option ASCII
function Set-Path() {
    param(
        [string] $newPath
    )

    $env:PATH = $newPath

    if($CmdPathFile) {
        $Parent = Split-Path -Parent $CmdPathFile
        if(!(Test-Path $Parent)) {
            New-Item -Type Directory $Parent -Force | Out-Null
        }
        _WriteDebug " Writing PATH file for CMD script"
        @"
SET "PATH=$newPath"
"@ | Out-File $CmdPathFile ascii
    }
}

and this produce for me command like SET "PATH=C:\Users\Wojtek Gadzi?ski\.dnx\runtimes\...
It convert my ń to ? and after that script stops working. I feel discriminated :)
I found solution/workaround for it. Helps change ascii encoding to oem
Out-File $CmdPathFile oem - It uses the current original equipment manufacturer code page identifier for the operating system. I'm not sure if this is solution for everyone. It should be checked.
Best Regards.

I think I should move this issue to dnvm repository.


fix(plugin/azure-function): clear upstream uri and request uri inject plugin logic

Summary

Checklist

[x] The Pull Request has tests
[x] A changelog file has been created under changelog/unreleased/kong or skip-changelog label added on PR if changelog is unnecessary. README.md
[ ] There is a user-facing docs PR against https://github.com/Kong/docs.konghq.com - PUT DOCS PR HERE

Full changelog

[Implement ...]

Issue reference
KAG-2841

@bungle Hi Apo, I do not know how this plugin is designed, but I think these upstream URIs and request URIs can not inject azure function plugin logic, Which do you mean?

@Tieske Do you happen to know / remember why this plugin concatenated the upstream path? This PR changes the existing behavior. It honestly seems like the common case would be to create a serviceless route.

@Tieske do you have any further information?

I don't recall anything about this either.

@brentos I have changed the entry to breaking change type. Please help me review it again.