Automatically inserting functions

I've noticed that my function results in Deoplete seem to be inserting themselves when I don't want them to.
For example, if I start typing and Deoplete suggests a list of items, and the first one is a function from Jedi, as soon as I hit <C-n> to start navigating through the list, the item gets inserted.  I think this is due to the fact that the ( is added automatically.  If I cycle through the list backwards, it correctly passes over other Deoplete options, and variables from Jedi, but as soon as it hits a function and the ( is inserted, the behavior breaks.
I can't get the behavior to break all the time, but can upload a file and describe what I'm doing that triggers the undesired behavior.
The follow Python file shows the error:
// error.py
def test_model(test_file_name):
    pass

If you place the cursor at the end of the file and write test I get a completion that looks like this:

After pressing <C-n> I would expect the first item in the list to be highlighted, but not actually entered.  However, pressing <C-n> only once brings me to the following instead:

I think you're confused on how completion works in vim. Read up on :help ins-completion-menu

@nhooyr exactly

@alexlafroscia does this happen with manual completion?

@nhooyr what do you mean by manual completion?

@alexlafroscia Please create minimal init.vim less than 50 lines and without the plugin manager configurations.
I will test it.

Alright, so assuming you're using vim-plug for addon management, the following configuration shows the error:
if empty(glob('~/.config/nvim/autoload/plug.vim'))
  silent !curl -fLo ~/.config/nvim/autoload/plug.vim --create-dirs
    \ https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim
  autocmd VimEnter * PlugInstall
endif

let &runtimepath .= "," . $DOTFILES . "/nvim"

call plug#begin()
Plug 'airblade/vim-gitgutter'
Plug 'Shougo/deoplete.nvim'
Plug 'zchee/deoplete-jedi',               { 'for': 'python' }
call plug#end()

let g:deoplete#enable_at_startup = 1
let g:deoplete#sources = {}
let g:deoplete#sources.python = ['jedi', 'ultisnips']

I ran the command as nvim -u init.vim error.py where init.vim has the contents listed above.  Note, I had to run :UpdateRemotePlugins this first time, closed Neovim, and then ran the same command again.
The issue seems to be vim-gitgutter, strangely enough.  Using my normal configuration, removing that single plugin fixed the problem.

OK.  I think it is vim-gitgutter's bug.
It is not deoplete-jedi's problem.  Closing.
https://github.com/airblade/vim-gitgutter/issues/310

👍 thanks!


Incorrect "" JSX syntax highlighting

plugin version: 0.90.1-2020.1
Description
Repro: type <option>yadda</option> in JSX context
Expected: <option> and </option> are highlighted evenly
Instead: they are not, see screenshot below

Fixed in 0.92.1


Live

Test PR

Docs Build status updates of commit 98cde8f:
:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Test PR


Build Windows EXE with build-wine failed

I checked out the latest code base (bdf4d843739a1ac8ecc02e5d99acfd6de394c83f) and want to compile Windows EXE with build-wine. See https://github.com/electrum-altcoin/electrum/tree/master/contrib/build-wine
I executed the following command:
sudo docker run -it \
    --name electrum-wine-builder-cont \
    -v $PWD:/opt/wine64/drive_c/electrum \
    --rm \
    --workdir /opt/wine64/drive_c/electrum/contrib/build-wine \
    electrum-wine-builder-img \
    ./build.sh

The build failed with:
[...]
Build failed
 -> task in 'run_d' failed with exit status 1 (run with -v to display more information)
 -> task in 'run_d' failed with exit status 1 (run with -v to display more information)
/opt/wine64/drive_c/electrum/contrib/build-wine/.cache/pyinstaller
🗯 ERROR: Could not find runw.exe in target dir!
🗯 ERROR: PyInstaller build failed
🗯 ERROR: prepare-wine failed

I used Ubuntu 20.04.2 LTS and Docker version 20.10.5

building the codebase is a bit more complex than that. please see the github CI files to see the process


the css file needs to be in the export section of the package.json

I see you copy the "css" file to the root: /css/angular-tree-component.css
also ng-packages also has it as an asset (i guess you can remove that line?) https://github.com/ali-hm/angular-tree-component/blob/master/projects/angular-tree-component/ng-package.json#L4
Because that for some reason does include it, but doesn't include it in the package.json exports list it seems that you really need todo that in the package.json of the project:
https://github.com/ng-packagr/ng-packagr/blob/main/docs/copy-assets.md
so on this line:
https://github.com/ali-hm/angular-tree-component/blob/master/projects/angular-tree-component/package.json#L47
we need:
 "exports": {     "./css/angular-tree-component.css": {       "style": "./css/angular-tree-component.css"     }   }
so that it will compile because else if i include that lib and it try to import that css in my own:
@import<EMAIL_ADDRESS>then i get:
Error: Package path ./css/angular-tree-component.css is not exported from package node_modules@ali-hm\angular-tree-component (see exports field in<EMAIL_ADDRESS>

I will consider your solution, but for the time being (as I mentioned in the README) you can use this line for the css:
@import<EMAIL_ADDRESS>make the relational path based on the file that you are importing the "angular-tree-component.css".

ah no, that is horrible for us, because that path can be quite specific,  can be a parent of a parent node modules...
if you ship stuff in the package there just needs to be a export entry in the package.json

It is resolved in v12.0.4. Now you can import css using this line:
@import<EMAIL_ADDRESS>


[SPARK-29906] Reading of csv file fails with adaptive execution turned on

What changes were proposed in this pull request?
Switch to rdd to avoid adaptive execution when reading first line, because it seems adaptive execution can insert a ShuffleMapStage after which the first line read is not necessarily the csv header anymore.
Note that this is a workaround. It is not clear to me why adaptive exection inserts a shuffle stage when all we are doing is filtering and reading first line. If this is unwanted behavior then the fix should be in adaptive execution.
Why are the changes needed?
Without this change spark can read csv files incorrectly when adaptive execution is turned on resulting in errors and/or data corruption.
Does this PR introduce any user-facing change?
No
How was this patch tested?
It is not clear to me how reproduce issue in a unit test, because so far the issue only shows up with 6+ executors and decent sized files. This patch was only tested by rebuilding spark and re-running the steps as decribed in the jira and confirming the issue did not show up again.

Test build #113949 has started for PR 26560 at commit e876031.

Merged build finished. Test PASSed.

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

Test build #113949 has finished for PR 26560 at commit e876031.

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

Merged build finished. Test PASSed.

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

cc @gatorsmile and @cloud-fan .

thanks for reporting! This is indeed a bug in AQE. I've sent a PR to fix it: https://github.com/apache/spark/pull/26576


Fix copyright check

What I intended seems to have been done already. I see this PR changes nothing.


Change caching implementation

Description:
Caching implementation needs to be changed so that it behaves like a map (element adding, retrieving, etc).
Steps to reproduce:
N/A
Affected Versions:
N/A
OS, DB, other environment details and versions:
N/A
Related Issues (optional):
N/A
Suggested Labels (optional):
N/A
Suggested Assignees (optional):
N/A

Will not implement


The links in the Usage section of the SD JWT Present README.md are not working

Hi! I'll check the link and fix it :)
Thank you


[Bug]: Using Docker deployllama in Windows environment, ragflow after using ragflow API call prompt Token is not valid!

Is there an existing issue for the same bug?

[X] I have checked the existing issues.

Branch name
main
Commit ID
cccc
Other environment information
No response
Actual behavior
After I deployed Olama and Ragflow using Docker on Windows, when I used Ragflow's API call, it came up with Token is not valid! If I don't use APIs, it's okay to use web conversations

Expected behavior
No response
Steps to reproduce
Firstly, I installed DockerDesktop on Windows, and then I used Docker to install Ollama and Ragflow. After that, using Ragflow's web, I was able to have normal conversations, but when using Ragflow's API, it stopped working and prompted Token is not valid!, Even if I create a new API key, it is not possible

Additional information
No response

How did you fix this? I found the same question when I run the demo on my own server, but it's ok when I use the web url(demo.ragflow.io) instead of my server ip.


[SSL, ZT] mTLS CA certificate requirements

CUSTESC-33284

Hey! Thanks for raising this. Moving to https://github.com/cloudflare/cloudflare-docs/pull/12495 as I ran into issues with the build here.
Also, ended up creating PCX-9441 for myself so it's easier to track the documentation changes that were triggered based on that CUSTESC you linked.


Fix update mail script

The script to update email lists was broken after the addition of
blueprints/modules in PR #71. This is because the import was incorrect.
As a fix, I've moved the update script out of the
RuddockHouse/RuddockHouse/ folder. This is also nicer because the
update script isn't run on the website, so it makes sense to have it
outside that directory.

Yeah, I noticed this when I was updating migrate_passwords.py in the auth branch too.


OTA update check: inform about uncommon version mismatch

Added debug message for cases where device firmware is newer than the latest version online. This should not happen but might be a helpful log message when version numbers were incorrectly interpreted or a manufacturer changed up the numbering scheme.
See https://github.com/Koenkk/zigbee-herdsman-converters/issues/1000#issuecomment-589443800

Hey @andreasbrett sorry I didn't reply before but only now I notice your PR!
I see real value in your proposal, but I would recommend doing it against the base https://github.com/Koenkk/zigbee-herdsman-converters instead of my fork as this is specific for the current Ledvance OTA update support work only.


must-gather: switch velero labelselector to be oadp-1.0 compatible.

closing.. no-op. blind dev forgot to double check code.
component=velero was used consistently since before 1.0 release. and is in latest 1.1 and 1.0 versions.


Error compiling donut msvc

`C:\Users\Ahmed\Desktop\donut>nmake -f Makefile.msvc
Microsoft (R) Program Maintenance Utility Version 14.34.31937.0
Copyright (C) Microsoft Corporation.  All rights reserved.
Could Not Find C:\Users\Ahmed\Desktop\donut\lib\donut.lib
Building exe2h
    cl /nologo loader\exe2h\exe2h.c loader\exe2h\mmap-windows.c

exe2h.c
mmap-windows.c
Generating Code...
Building loader
    cl -DBYPASS_AMSI_B -DBYPASS_WLDP_A -DBYPASS_ETW_B -Zp8 -c -nologo -Gy -Os -O1 -GR- -EHa -Oi -GS- -I include loader\loader.c hash.c encrypt.c loader\depack.c loader\clib.c

loader.c
hash.c
encrypt.c
depack.c
clib.c
Generating Code...
link -nologo<EMAIL_ADDRESS>-entry:DonutLoader -fixed -subsystem:console -nodefaultlib loader.obj hash.obj encrypt.obj depack.obj clib.obj
exe2h loader.exe
[ Found valid DOS and NT header.
[ Locating .text section.
[ saved code to loader_exe_x86.h
[ saved code to loader_exe_x86.go
Building generator
    rc include\donut.rc

Microsoft (R) Windows (R) Resource Compiler Version 10.0.10011.16384
Copyright (C) Microsoft Corporation.  All rights reserved.
    cl -Zp8 -nologo -DDONUT_EXE -I include donut.c hash.c encrypt.c format.c loader\clib.c lib\aplib64.lib include\donut.res

donut.c
hash.c
encrypt.c
format.c
clib.c
Generating Code...
donut.obj : error LNK2019: unresolved external symbol _aP_pack referenced in function _compress_file
donut.obj : error LNK2019: unresolved external symbol _aP_workmem_size referenced in function _compress_file
donut.obj : error LNK2019: unresolved external symbol _aP_max_packed_size referenced in function _compress_file
lib\aplib64.lib : warning LNK4272: library machine type 'x64' conflicts with target machine type 'x86'
donut.exe : fatal error LNK1120: 3 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.34.31933\bin\HostX86\x86\cl.EXE"' : return code '0x2'
Stop.`

This is because you are using the x86 Native Tools Command Prompt for Visual Studio instead of the x64 Native Tools Command Prompt for Visual Studio. The makefile is configured for 64-bit by default. To compile for 32-bit, do a find-and-replace in the makefile for "64" -> "32".


Feature Request: Adding Tab support

I have some messages with subjects as snippets like the following:
The message subject#{tab}Dear All,
...
...
I want for example to enter the snippet in the Thunderbird subject field then what Beeftext will do is typing the subject then hit the Tab key then adding the message body.

Usually i never comment on anything on the internet, but this would be a very welcome addition for me. It would cut the ammount of combos i need in half and it would increase my productivity tremendously.

I also vote +1 for this request. This feature would be very useful for me.

what about inputting enter?
It seems there is no things like #{enter}

Input of key (Enter, tabs, or modifiers keys like control) are problematic for some internal reason I won't detail. It will be implemented at some point, but not in the near future.

Yeah, would be a huge improvement of beeftext.
@xmichelo What needs to happen from our side to make this feature come true? :-)

Only patience ;) It will come at some point, but unfortunately, these days I have no time to work on Beeftext,

In case anyone else runs across this in the future, this request has been fulfilled.  Here's the docs:
https://github.com/xmichelo/Beeftext/wiki/Variables
Scroll down to the #{key} section


Re-render map on coordinate change

Hello!
Is it possible to re render the map if the coordinate (lat/long) change in the backend. If the location().lat/location().long change, I would ideally like the map to update. Is this possible?
Thanks!
locationData: function() {
    if (GoogleMaps.loaded() && this.location()) {
    	var output = {
    		center: new google.maps.LatLng(this.location().lat, this.location().long),
    		zoom: 8
    	}

    	return output;
    }
  }

Yes, rather than updating in the helper, you'll want to do that within the ready callback. Something like:
Template.myMap.onCreated(function() {
  GoogleMaps.ready('myMap', (map) => {
    this.autorun(() => {
      // I *think* this is the correct method, you might want to refer to the Google docs
      map.instance.setCenter(..., ...);
    });
  });
});


The instanceof operator in TypeScript always returns true when comparing different L1 Constructs

Description of the bug:

The instanceof operator in TypeScript always returns true when comparing different L1 Constructs.
This is unexpected behavior.
Reproduction Steps:

import {Construct} from 'constructs';
import {App, Chart, ChartProps} from 'cdk8s';
import {KubeConfigMap, KubeDeployment, KubeJob} from './imports/k8s';

export class MyChart extends Chart {
  constructor(scope: Construct, id: string, props: ChartProps = {}) {
    super(scope, id, props);

    const cm = new KubeConfigMap(this, 'cm');
    const deploy = new KubeDeployment(this, 'deploy');
    const job = new KubeJob(this, 'job');

    console.error(cm instanceof KubeConfigMap);
    console.error(cm instanceof KubeDeployment);
    console.error(cm instanceof KubeJob);
    console.error(deploy instanceof KubeConfigMap);
    console.error(deploy instanceof KubeDeployment);
    console.error(deploy instanceof KubeJob);
    console.error(job instanceof KubeConfigMap);
    console.error(job instanceof KubeDeployment);
    console.error(job instanceof KubeJob);
  }
}

const app = new App();
new MyChart(app, 'test');
app.synth();

Error Log:

No errors.
Environment:
package.json
{
  "name": "bug-report",
  "version": "1.0.0",
  "private": true,
  "description": "",
  "scripts": {
    "import": "cdk8s import",
    "compile": "tsc",
    "synth": "cdk8s synth",
    "build": "npm run compile && npm run synth"
  },
  "dependencies": {
    "cdk8s": "^2.7.55",
    "constructs": "^10.1.311"
  },
  "devDependencies": {
    "cdk8s-cli": "^2.2.12",
    "typescript": "~5.0.4"
  }
}

OS: maxOS, Ubuntu 22.04
Node.js: v18.7.0
Imported k8s: v1.25.0

Other:

I have confirmed that the issue does not occur in cdk8s v2.6.36.

This is :bug: Bug Report

Interesting. Thanks for reporting this, we will take a look. In the meantime I would suggest using cm.kind to do these types of comparisons. E.g:
if (cm.kind === 'Deployment') ....


Add Orchard commitment to GetTreeState gRPC

Support for this was added to zcashd's z_gettreestate RPC by https://github.com/zcash/zcash/pull/5560, this should be a simple change.

@LarryRuane Currently GetTreeState returns only the Sapling finalState as the "tree" value. Should this now return saplingTree and orchardTree or how would you suggest the output is structured?


PrincipalClass encodeValue is breaking compatibility with old Principal

PrincipalClass encodeValue is breaking compatibility with old Principal
Summary
If you are using old Principal library with new Agent library, when you call a method with a Principal like parameter, it breaks. So you may wrap the principal into Principal of the new library.
https://github.com/dfinity/agent-js/blob/7102eb715dc026d90ebd3b86b11adeaa4e2fde9f/packages/candid/src/idl.ts#L1142

This was not actually resolved by #502

Is there a quick fix for it ? @krpeacock

I'm not sure how pressing of a priority it is to support calling across different minor versions of these packages, when the update to principal was intended to be a breaking change

If you need the type guard, I recommend using Principal.from on the different version to bring it into your preferred package version. We'll be addressing this in an overall backwards compatibility epic


Add topologySpreadConstraints

Please provide a description of this PR:
The intention of this PR is to provide support for topologySpreadConstraints. You can have this today using the Operator API with overlays, but it is not possible with helm.

/ok-to-test

Hi, shouldnt the Istio-Pilot also have topologySpreadConstraints ?


Update implementation.md

changing from 'master' to 'main'

@krnese : Thanks for your contribution! The author(s) have been notified to review your proposed change.


SockRef::from, Socket::sendfile and other functions that operate on arbitrary file descriptors or SOCKETs potentially should be unsafe

See rust-lang/rust#72175 and nix-rust/nix#1421: it seems an external library is allowed to assume a file descriptor is private, for example:
#![allow(clippy::blacklisted_name)]
#![deny(unsafe_code)]

use socket2::SockRef;
use std::mem;

#[allow(unsafe_code)]
mod external_library {
    use std::{mem, os::unix::io::RawFd, ptr};

    static DATA: i32 = -1;

    pub struct Foo([RawFd; 2]);

    impl Foo {
        pub fn new() -> Self {
            let mut sockets = [-1; 2];
            assert_eq!(
                unsafe {
                    libc::socketpair(
                        libc::AF_UNIX,
                        libc::SOCK_SEQPACKET | libc::SOCK_CLOEXEC,
                        0,
                        sockets.as_mut_ptr(),
                    )
                },
                0
            );
            Self(sockets)
        }

        pub fn foo(&self) {
            let data: *const _ = &DATA;
            assert_eq!(
                unsafe {
                    libc::send(
                        self.0[0],
                        ptr::addr_of!(data).cast(),
                        mem::size_of_val(&data),
                        0,
                    )
                },
                mem::size_of_val(&data) as _
            );
        }

        pub fn bar(&self) -> i32 {
            let mut ptr: *const i32 = ptr::null();
            assert_eq!(
                unsafe {
                    libc::recv(
                        self.0[1],
                        ptr::addr_of_mut!(ptr).cast(),
                        mem::size_of_val(&ptr),
                        0,
                    )
                },
                mem::size_of_val(&ptr) as _
            );
            unsafe { *ptr }
        }
    }
}

fn main() {
    let foo = external_library::Foo::new();
    SockRef::from(&3)
        .send(&[0; mem::size_of::<*const i32>()])
        .unwrap();
    foo.foo();
    dbg!(foo.bar());
}

Here, the safe SockRef::from allows to crash a (fake) "external library" by letting it dereference a null pointer using only safe code. Making functions that accept arbitrary file descriptors or SOCKETs unsafe can probably solve this problem.

See rust-lang/rust#72175 and nix-rust/nix#1421: it seems an external library is allowed to assume a file descriptor is private, for example:

I have no idea what you mean with private, but if you mean shouldn't be modified by external (outside of the type's impls) that it should not implement AsRawFd/AsRawSocket. If it does implement AsRawFd/AsRawSocket that it must be able to deal with the situation it's actually used.

Here, the safe SockRef::from allows to crash a (fake) "external library" by letting it dereference a null pointer using only safe code. Making functions that accept arbitrary file descriptors or SOCKETs unsafe can probably solve this problem.

The SocketRef::from(&3) should be unsafe, but not because SocketRef::from should be unsafe. Because you're creating (implicitly) a RawFd which should be valid, but isn't in this example, that is the unsafe part.
Furthermore you're dereferencing a raw pointer using unsafe, so you're clearing not only using safe code. Putting code in an "external library" doesn't mean it shouldn't count towards unsafe code, it still is.
So, I do agree that creating RawFd from literals, especially when passing them directly to function as you did in the example should be unsafe or at least clearer. But I don't agree SocketRef::from is unsafe, or should be marked as such.

The SocketRef::from(&3) should be unsafe, but not because SocketRef::from should be unsafe. Because you're creating (implicitly) a RawFd which should be valid, but isn't in this example, that is the unsafe part.
So, I do agree that creating RawFd from literals, especially when passing them directly to function as you did in the example should be unsafe or at least clearer. But I don't agree SocketRef::from is unsafe, or should be marked as such.

Fair. I think at least something in the 3_i32 -> ... -> SockRef path should be unsafe. Maybe a wrapper type that is unsafe to construct from an arbitrary number?

It turns out that RawFd itself implements AsRawFd. So AsRawFd doesn't say anything about the validity or ownership of the returned RawFd value.
rust-lang/rust#72175 is still being discussed, and looks like it may lead to an RFC. If that happens, and if the RFC is accepted, functions that operate on RawFd values should be unsafe. That includes SockRef::from in its current form, since it accepts any type that implements AsRawFd which includes RawFd itself.
That said, SockRef::from is a valuable use case, and ideally it should be possible to do what it's doing without unsafe in its API. As one possible approach, the unsafe-io crate has an OwnsRaw trait which types that implement AsRawFd etc. can implement to additionally state that they really do own their handles, and traits like AsUnsafeSocket type which combine OwnsRaw and AsRawFd (AsRawSocket on Windows). With these, it should be possible to have fn SockRef::from(t: &T) where T: AsUnsafeSocket as a safe API. (Aside: unsafe-io is a new crate, and I'm interested if anyone has ideas for how to improve the API!)
But of course, it makes sense to wait and see how the discussion in rust-lang/rust#72175 and the possible RFC turn out before making major changes here.

I'm working on a draft of a proposal to add new official wording about RawFd to Rust.
In particular, this proposal would mean functions like SockRef::from with AsRawFd arguments should be marked unsafe, or migrated to alternatives. But the upside would be clearer guarantees for many use cases. I'd be interested in any feedback from folks working on socket2!

I'm working on a draft of a proposal to add new official wording about RawFd to Rust.
In particular, this proposal would mean functions like SockRef::from with AsRawFd arguments should be marked unsafe, or migrated to alternatives. But the upside would be clearer guarantees for many use cases. I'd be interested in any feedback from folks working on socket2!

I don't have time to look through the entire proposal, but SockRef::from will remain a safe function. In my opinion the AsRawFd/AsRawSocket documentation should be clearer that the returned fd/socket should be valid. The current documentation for AsRawFd says the following

This method does not pass ownership of the raw file descriptor to the caller. The descriptor is only guaranteed to be valid while the original object has not yet been destroyed.

The second sentence says to me that the implementation needs to ensure the file descriptor is valid (while the object is alive). Unfortunately RawFd is just a c_int (because it needs to match C semantics) and can "just be created" without being valid, i.e. the literal 123 is a "valid" (as in type) RawFd but of course isn't a valid fd. Couple that with the AsRawFd impl for RawFd and we got a problem as shown in the initial issue report.
I think the problem is that the creation of RawFd should be an unsafe operation in which the programmer needs to ensure it's a valid descriptor. But we can't change that anymore. We can improve the documentation however.

Instead of making it unsafe, what would you think about changing SockRef::from to use AsUnsafeSocket in place of AsRawFd?
AsUnsafeSocket is implemented for all the relevant std types, TcpStream, TcpListener, UdpSocket, UnixStream, UnixListener, and UnixDatagram. For other types, the only thing needed is to add an impl OwnsRaw, so types like socket2::Socket and others could easily implement it. That way, SockGet::from wouldn't be unsafe, and many use cases would continue to work as-is.
And to be sure, this isn't urgent; I'm still in the process of exploring the options.

Instead of making it unsafe, what would you think about changing SockRef::from to use AsUnsafeSocket in place of AsRawFd?

I don't think socket2 should dependencies outside of libc/winapi. Furthermore exposing those dependencies in a public API is a bad idea as we're then tied to a fixed version of the crate (i.e. we couldn't update to unsafe-io v2 without also updating to socket2 v2).
I'm also not convinced that AsUnsafeSocket is an improvement of AsRawFd. I think the best way forward is improving the documentation of AsRawFd/AsRawSocket.

AsUnsafeSocket is implemented for all the relevant std types, TcpStream, TcpListener, UdpSocket, UnixStream, UnixListener, and UnixDatagram. For other types, the only thing needed is to add an impl OwnsRaw, so types like socket2::Socket and others could easily implement it. That way, SockGet::from wouldn't be unsafe, and many use cases would continue to work as-is.
And to be sure, this isn't urgent; I'm still in the process of exploring the options.

Right now, it's possible for code in one library to use functions like SockRef::from to break the encapsulation of code in another library without itself using any unsafe. It's a small loophole in Rust, and it is fixable, so I'm interested in whether any of the possible fixes are practical, rather than just leaving the loophole open and documenting it.
One option would be to propose adding the parts of unsafe-io needed to fix this to std. The OwnsRaw trait might be sufficient. That way you could implement OwnsRaw and use AsRawFd + OwnsRaw, without any dependencies. Does something like that sound practical?

Right now, it's possible for code in one library to use functions like SockRef::from to break the encapsulation of code in another library without itself using any unsafe.

This is not true. If the encapsulation implements AsRawFd, which allows external access to the file descriptor, it must be able to handle changes to the file descriptor, e.g. options are set on it. If it can't deal with this it shouldn't implement AsRawFd, it's as simple as that.

It's a small loophole in Rust, and it is fixable, so I'm interested in whether any of the possible fixes are practical, rather than just leaving the loophole open and documenting it.

It's not a loophole, it's by design. It's required to deal with C/Unix/Windows I/O model of using integers/void pointers as identifiers to a kernel file description.

One option would be to propose adding the parts of unsafe-io needed to fix this to std. The OwnsRaw trait might be sufficient. That way you could implement OwnsRaw and use AsRawFd + OwnsRaw, without any dependencies. Does something like that sound practical?

I still don't get the point of OwnsRaw and the benefit over AsRawFd, could you elaborate why you think it's an improvement?

Suppose library A holds a RawFd it never exposes, which happens to have the value 4. Suppose library B does this:
let s = socket2::SockRef::from(&4);
let mut buf = vec![std::mem::MaybeUninit::new(0u8); 32];
s.peek(&mut buf[..])?;

This compiles on stable Rust today. B can read A's otherwise encapsulated data, with no unsafe of its own.
Another example would be B accidentally holding a RawFd value after closing it, which then aliases a newly created file descriptors in A. POSIX considers all this defined behavior. But in Rust, it's expected that one library shouldn't be able to read another's encapsulated data without using unsafe.
There's a way to fix this: from_raw_fd is unsafe. However there's a loophole: AsRawFd and IntoRawFd are not unsafe, so anything can implement them. It's tempting to just document this, and say that implementing them should imply certain guarantees, however std itself implements them for RawFd and makes no guarantees.
OwnsRaw solves this by being an unsafe trait. Types which implement it have to use the keyword unsafe, and in doing so they commit to the desired guarantees.

Suppose library A holds a RawFd it never exposes, which happens to have the value 4. Suppose library B does this:
let s = socket2::SockRef::from(&4);
let mut buf = vec![std::mem::MaybeUninit::new(0u8); 32];
s.peek(&mut buf[..])?;

This comment by withoutboats (not pinging) points to the core issue: https://github.com/rust-lang/rust/pull/76969#issuecomment-695999201, that RawFd is just a type alias. In your example you're creating a RawFd from nothing: that should be unsafe, but isn't. That is not a problem with socket2, but one with std lib, which due to the v1 stability guarantees can't be changed.
We should clearly document this footgun of using integer literals as RawFd in both SocketRef::from and AsRawFd.

Integer literals are one example. Use-after-close is another. Arithmetic and deserialization are others.
I agree, we could better document the current situation. At the same time, this problem has the same form as problems with raw pointers, such as dangling and aliasing, which Rust does more than just document. Fixing it seems desirable in principle. And it seems possible. Is it practical?
I agree with withoutboats; the underlying problem is in std. OwnsRaw is a new trait, designed to be used with the existing types and traits without changing or replacing them. If there's a consensus around an RFC, then we should be able to arrange for all the important types that implement AsRawFd to implement OwnsRaw too—it's just one line of code per type, and it doesn't break anything to add them. std itself wouldn't need any breaking changes. Functions like SockRef::from could wait until the OwnsRaw impls are in place before adding + OwnsRaw to their bound to minimize disruption.

I have no idea what you mean with private, but if you mean shouldn't be modified by external (outside of the type's impls) that it should not implement AsRawFd/AsRawSocket. If it does implement AsRawFd/AsRawSocket that it must be able to deal with the situation it's actually used.

I strongly disagree. AsRawFd for a file descriptor is the equivalent of casting a reference to an integer. The latter is a safe operation, and so is the former. The inverse, turning an integer to a reference, is unsafe -- not just because the integer could be dangling, but also because that memory could be owned by other parties that e.g. have &mut or Box pointers.
The situation here is entirely analogous: as_raw_fd (the "ptr-to-int cast") is safe; anything working with such potentially dangling, potentially aliased FDs ("dereferencing a raw pointer") should be unsafe.

This is not true. If the encapsulation implements AsRawFd, which allows external access to the file descriptor, it must be able to handle changes to the file descriptor, e.g. options are set on it. If it can't deal with this it shouldn't implement AsRawFd, it's as simple as that.

Again, consider the analogy with references and integers: just because &mut can be safely cast to a raw pointer, does not mean that references can handle arbitrary changes to the underlying data this raw pointer -- it is still wrong to violate the uniqueness assumption of the &mut reference.
Taking a step back, there are two options for how the Rust ecosystem as a whole could treat raw FDs:

"free-for-all", no ownership, doing arbitrary operations on arbitrary FDs is, in principle, allowed.
"exclusive", with ownership, one may only operate on FDs that one owns.

Both options are self-consistent and internally coherent. The standard library quite clearly took option 2, as a consequence as_raw_fd is safe and from_raw_fd is unsafe. This is also the option Rust took for pointers/memory. (Here, option 1 is not really realistic as that would violate memory safety.) You seem to claim that what the standard library does is somehow incoherent; that claim is wrong. It is entirely coherent to say both "AsRawFd is safe" and "working with non-owned FDs is unsafe"; this is exactly what Rust does for pointers and it works equally well for FDs. The only incoherence we have here is parts of the ecosystem picking option 2 with others picking option 1.

I strongly disagree. AsRawFd for a file descriptor is the equivalent of casting a reference to an integer. The latter is a safe operation, and so is the former. The inverse, turning an integer to a reference, is unsafe -- not just because the integer could be dangling, but also because that memory could be owned by other parties that e.g. have &mut or Box pointers.
The situation here is entirely analogous: as_raw_fd (the "ptr-to-int cast") is safe; anything working with such potentially dangling, potentially aliased FDs ("dereferencing a raw pointer") should be unsafe.

I see your point and partially agree. I don't working with fd should be as unsafe as it can/should never cause memory unsafety as the OS always checks the validity of the file descriptor and returns an error if it's invalid. But I do see the point your making.

Again, consider the analogy with references and integers: just because &mut can be safely cast to a raw pointer, does not mean that references can handle arbitrary changes to the underlying data through this raw pointer -- it is still wrong to violate the uniqueness assumption of the &mut reference.

I have to disagree here. If a type needs to hold some invariant it shouldn't allow arbitrary access to the underlying data. Take NonZeroUsize for example, it needs to ensure that the underlying data (usize) is never zero. So it can hand out mutable reference to the underlying data as they might break the invariant. Compared to say Wrapping (which doesn't have any such invariant) it's underlying data is public.

Taking a step back, there are two options for how the Rust ecosystem as a whole could treat raw FDs:
1. "free-for-all", no ownership, doing arbitrary operations on arbitrary FDs is, in principle, allowed.

2. "exclusive", with ownership, one may only operate on FDs that one owns.

Both options are self-consistent and internally coherent. The standard library quite clearly took option 2, as a consequence as_raw_fd is safe and from_raw_fd is unsafe and RawFd is just a type aliased. This is also the option Rust took for pointers/memory. (Here, option 1 is not really realistic as that would violate memory safety.) You seem to claim that what the standard library does is somehow incoherent; that claim is wrong. It is entirely coherent to say both "AsRawFd is safe" and "working with non-owned FDs is unsafe"; this is exactly what Rust does for pointers and it works equally well for FDs. The only incoherence we have here is parts of the ecosystem picking option 2 with others picking option 1.

In your example you're creating a RawFd from nothing: that should be unsafe, but isn't.

Here you are presuming option 1 -- but that is simply not the option the standard library took. Under option 2, there is nothing wrong with creating a RawFd being a safe operation. This is in analogy with how turning a usize to a *mut i32 is a safe operation.
So, it could be unsafe (if option 1 is what we'd use), but saying it "should" be unsafe is incorrect.

I see your point.
What do you (not just @RalfJung) suggest the new API would look like? I have some requirements:

No external dependencies.
Preferably the operation requires no unsafe for known valid fds, e.g. going from &TcpStream to SocketRef should be safe (as it is with the current API).
Preferably crates that expose socket types, e.g. mio::net::TcpStream, don't need to have a (public) dependency on socket2.

What do you (not just @RalfJung) suggest the new API would look like? I have some requirements:
* No external dependencies.

* _Preferably_ the operation requires no unsafe for known valid fds, e.g. going from `&TcpStream` to `SocketRef` should be safe (as it is with the current API).

* _Preferably_ crates that expose socket types, e.g. `mio::net::TcpStream`, don't need to have a (public) dependency on socket2.

To eliminate the need for a dependency, I've now added the OwnsRaw trait to my RFC draft. So if the RFC is accepted, and once we have OwnsRaw impls for mio::net::TcpStream, socket2::Socket, and other important types, the new API could look like this:
use std::io::OwnsRaw;
...
impl<'s, S> From<&'s S> for SockRef<'s>
where
    S: AsRawFd + OwnsRaw,

That would meet all three requirements. Does that look reasonable?

To eliminate the need for a dependency, I've now added the OwnsRaw trait to my RFC draft. So if the RFC is accepted, and once we have OwnsRaw impls for mio::net::TcpStream, socket2::Socket, and other important types, the new API could look like this:
use std::io::OwnsRaw;
...
impl<'s, S> From<&'s S> for SockRef<'s>
where
    S: AsRawFd + OwnsRaw,

That would meet all three requirements. Does that look reasonable?

I think so after a could look at the RFC (https://github.com/sunfishcode/rfcs/blob/3abe7cc704decf63beee16489123e0f2c996f6f3/text/0000-io-safety.md). Also a side note: you might want to include (parts of) @RalfJung comment https://github.com/rust-lang/socket2/issues/218#issuecomment-825671938 in the RFC.
In the mean time any suggestions? We could simply add a trait like OwnsRaw to socket2 as a stop gap and optionally an unsafe version of From::from for types that don't implement OwnsRaw, forcing the caller to ensure the fd is valid.

I think so after a could look at the RFC (https://github.com/sunfishcode/rfcs/blob/3abe7cc704decf63beee16489123e0f2c996f6f3/text/0000-io-safety.md). Also a side note: you might want to include (parts of) @RalfJung comment #218 (comment) in the RFC.

Cool, and good idea, I've now incorporated more of those ideas.

In the mean time any suggestions? We could simply add a trait like OwnsRaw to socket2 as a stop gap and optionally an unsafe version of From::from for types that don't implement OwnsRaw, forcing the caller to ensure the fd is valid.

You could do that if you want, however I also think it'd be ok to just wait to see how the RFC goes before making any changes here.

I have to disagree here. If a type needs to hold some invariant it shouldn't allow arbitrary access to the underlying data. Take NonZeroUsize for example, it needs to ensure that the underlying data (usize) is never zero. So it can hand out mutable reference to the underlying data as they might break the invariant. Compared to say Wrapping (which doesn't have any such invariant) it's underlying data is public.

NonZeroUsize can be converted to usize in safe code. In other words, even types that need to hold invariants can safely and reasonably provide read-only access to their internal data. That is exactly what as_raw_fd does.

To eliminate the need for a dependency, I've now added the OwnsRaw trait to my RFC draft. So if the RFC is accepted, and once we have OwnsRaw impls for mio::net::TcpStream, socket2::Socket, and other important types, the new API could look like this:

I guess your proposal uses the 's lifetime of SocketRef to ensure that the ref does not outlive the owned FD?

Btw, there is another aspect of I/O safety that is worth documenting: do "I/O references" (aka File Descriptors) follow the usual mutability rules? &File implements Write, so that type certainly does not -- but in principle we could imagine making the marker trait(s) like OwnsRaw expressive enough to indicate if this type owns read-only or read-write (or read-write-close) access to the underlying data, corresponding to &, &mut (or Box).

Btw, naively I would expect an API more like
/// Safe to convert to RawFd but unsafe to construct from it
struct OwnedFd(RawFd);

trait AsOwnedFd {
  /// Performs *ownership transfer* of the file descriptor embedded in `self` to the caller.
  fn as_owned_fd(self) -> OwnedFd
}

Your proposal seems to instead express borrowing an FD from some other type (for the duration of the lifetime of &self in as_raw_fd), and IMO that should be reflected in the name.

NonZeroUsize can be converted to usize in safe code. In other words, even types that need to hold invariants can safely and reasonably provide read-only access to their internal data. Even &mut T maintains some very important invariant on the underlying data, and yet that data can be safely inspected (by casting to usize). That is exactly what as_raw_fd does as well.

What I meant was that NonZeroUsize doesn't hand out &mut usize, because it couldn't ensure the invariant. In my opinion AsRawFd is similar to handing out a OsLock<FileDescription>. Yes, access to Rust's memory isn't possible with just a RawFd, but the implementer should known mutable access in possible to the kernel's file description (the data the kernel holds for each file/socket/etc.). So, what I tried to convey was that handing out a RawFd, even when the method is safe, does allow mutable access to the file description. And types that implemented AsRawFd should be able to handle this.

Note that the file descriptor in File is not public, and you cannot safely construct a File from the raw underlying data (unlike Wrapping). So I do not understand which analogy you are making here.

I was referring to mutable access to Wrapping's internal data (e.g. usize), compared to NonZeroUsize. But let's leave this, me bringing this type up sidetracks us more then anything else.

To eliminate the need for a dependency, I've now added the OwnsRaw trait to my RFC draft. So if the RFC is accepted, and once we have OwnsRaw impls for mio::net::TcpStream, socket2::Socket, and other important types, the new API could look like this:

I guess your proposal uses the 's lifetime of SocketRef to ensure that the ref does not outlive the owned FD? Neat.

Exactly, that's why it only implements From<&'s  AsRawFd>, so we always ensured the owned socket outlives the SockRef.

(Moved other things to the IRLO thread.)

Could you link to that I can't find it.

In my opinion AsRawFd is similar to handing out a OsLock.

I think here we are getting to the bottom of the problem -- the ownership associated with the return value of AsRawFd is unspecified. This is the exact problem that C has with pointers (types don't say who owns what); Rust solved that with Box and reference types.
You interpret it to be actually returning some form of ownership (even though I am not sure what the OsLock is about). However, note that as_raw_fd takes a type with a lifetime, so surely your idealized return type must have a lifetime as well? That file descriptor is definitely not valid forever.
I interpret it to be like this:
type RawInt = usize;
pub fn as_raw_integer<T>(x: &mut T) -> RawInt { x as *mut _ as usize }

IOW, I do not think any ownership is returned here.
I do think that there are some indications in std that as_raw_fd does not return ownership. Given your idealized return type, you do seem to entertain the idea that FDs can be exclusively owned -- but clearly, that is in contradiction with having safe ways to access arbitrary usize file descriptors, i.e., it is in contradiction with the APIs currently offered by this crates. Or am I misunderstanding something?
That said, I also admit that the AsRawFd trait seems kind of useless in this world.

Could you link to that I can't find it.

Sure, sorry: https://internals.rust-lang.org/t/pre-rfc-i-o-safety/14585

In my opinion AsRawFd is similar to handing out a OsLock.

I think here we are getting to the bottom of the problem -- the ownership associated with the return value of AsRawFd is unspecified. This is the exact problem that C has with pointers (types don't say who owns what); Rust solved that with Box and reference types.
You interpret it to be actually returning some form of ownership (even though I am not sure what the OsLock is about).

I interpret it not about ownership, but it's about access. With OsLock meant that the OS serialises access to the file desctiption (avoiding data races inside the kernel etc.), so it's like handing out a lock. I shouldn't been clearer about this.

However, note that as_raw_fd takes a type with a lifetime, so surely your idealized return type must have a lifetime as well? That file descriptor is definitely not valid forever.

Indeed that why SockRef has a lifetime. In a sense SockRef is already the idealized return type to me. It holds the raw fd, but has a lifetime to ensure the fd remains valid.

I interpret it to be like this:
type RawInt = usize;
pub fn as_raw_integer<T>(x: &mut T) -> RawInt { x as *mut _ as usize }

IOW, I do not think any ownership is returned here.

In a sense, but file descriptor are of course special. They aren't about the value themselves, but what give you access to the file description. Returning a file descriptor (to me at least) also implicitly returning access to the file description.

I do think that there are some indications in std that as_raw_fd does not return ownership.

I agree AsRawFd doesn't return ownership, for that we IntoRawFd which passes ownership.

Given your idealized return type, you do seem to entertain the idea that FDs can be exclusively owned

I indeed think file descriptor can be exclusively owned. AsRawFd (to me) allows the user to borrow the file descriptor, meaning the type doesn't have exclusive access anymore

-- but clearly, that is in contradiction with having safe ways to access arbitrary usize file descriptors, i.e., it is in contradiction with the APIs currently offered by this crates. Or am I misunderstanding something?

The API in question From<&T> where T: AsRawFd was never about accessing arbitrary usize file descriptors, in fact quite the opposite. It was about borrowing, safely, a socket type without having go through the unsafe hoop of AsRawFd/FromRawFd (as the From implementation did that for the user). So they can do SockRef::from(&TcpStream) without having to deal with unsafe or raw file desctiptors.
An ideal trait, perhaps as a safer alternative to AsRawFd, would look something like the following:
struct BorrowedFd<'fd> {
    fd: RawFd,
    _lifetime: PhantomData<&'fd RawFd>, // Lifetime of the file descriptor we're borrowing from
}

trait AsBorrowedFd {
    // Perhaps some types need mutable access, so `&'fd mut self`.
    fn as_borrow_fd<'fd>(&'fd self) -> BorrowedFd<'fd>;
}

That said, I also admit that the AsRawFd trait seems kind of useless in this world.

Could you link to that I can't find it.

Sure, sorry: https://internals.rust-lang.org/t/pre-rfc-i-o-safety/14585

In a sense, but file descriptor are of course special. They aren't about the value themselves, but what give you access to the file description. Returning a file descriptor (to me at least) also implicitly returning access to the file description.

One could say the same thing about pointers. :) You don't care about the address itself, you care about the data the ptr gives you access to. FDs might be special but not more special than pointers.
In Rust, we all agree that returning a usize that represents the underlying address of some data in memory does not implicitly give you the right to do anything with that address. You need to carefully read the docs to figure out who is allowed to do what with which piece of memory and when. We use ownership to encode those things in the type system and have the compiler help us. I think using the same strategy and terminology makes a lot of sense for FDs, as well. They are just pointers into a different address space.

I indeed think file descriptor can be exclusively owned. AsRawFd (to me) allows the user to borrow the file descriptor, meaning the type doesn't have exclusive access anymore

The thing is, without the "I/O safety" proposal, FDs cannot be exclusively owned. You need to accept that proposal to even have the notion of "owning an FD" in the vocabulary of Rust type invariants. If anyone can just take the integer "5" and treat it as an FD and write to it, all in safe code -- that is a counterexample to ownership of FDs.

The API in question From<&T> where T: AsRawFd was never about accessing arbitrary usize file descriptors, in fact quite the opposite. It was about borrowing, safely, a socket type without having go through the unsafe hoop of AsRawFd/FromRawFd (as the From implementation did that for the user). So they can do SockRef::from(&TcpStream) without having to deal with unsafe or raw file desctiptors.

You can also do SockRef::from(&(5 as RawFd)), though. So this story never quite worked, did it?
It looks like AsRawFd is simply the wrong trait for what you want to achieve. The name already says that this is about getting "raw" FD access -- the "raw" here is in direct analogy to "raw pointer". The fact that any integer can be safely turned into an impl AsRawFd is another giveaway. So since you have been using AsRawFd I interpreted this as a deliberate choice; now it looks to me like you did this for lack of a better alternative? (You could have created your own trait for this, but I guess that has non-obvious downsides as well and anyway now is not the time to rehash the design of this crate.^^)
AsBorrowedFd looks great, yes! Crucially, BorrowedFd borrows ownership of the underlying FD and thus this type must be unsafe-to-construct from a RawFd (but it can implement AsRawFd for the conversion the other way around). Please post it in that forum thread. I was imagining something like AsOwnedFd, which would be basically the same but forIntoRawFd.

One could say the same thing about pointers. :) You don't care about the address itself, you care about the data the ptr gives you access to. FDs might be special but not more special than pointers.

Indeed both pointer and fds are special cases on integers.

In Rust, we all agree that returning a usize that represents the underlying address of some data in memory does not implicitly give you the right to do anything with that address. You need to carefully read the docs to figure out who is allowed to do what with which piece of memory and when. We use ownership to encode those things in the type system and have the compiler help us. I think using the same strategy and terminology makes a lot of sense for FDs, as well. They are just pointers into a different address space.

I indeed think file descriptor can be exclusively owned. AsRawFd (to me) allows the user to borrow the file descriptor, meaning the type doesn't have exclusive access anymore

The thing is, without the "I/O safety" proposal, FDs cannot be exclusively owned. You need to accept that proposal to even have the notion of "owning an FD" in the vocabulary of Rust type invariants. If anyone can just take the integer "5" and treat it as an FD and write to it, all in safe code -- that is a counterexample to ownership of FDs.

But we can't write to integer 5 without unsafe code (well we can with the current SocketRef::from, but we already established that is unsound and undesired), you need to call the unsafe libc::write function or similar. But I very much agree that Rust would benefit from a ownership, lifetime and borrowing systems (equivalents) for file descriptors.

The API in question From<&T> where T: AsRawFd was never about accessing arbitrary usize file descriptors, in fact quite the opposite. It was about borrowing, safely, a socket type without having go through the unsafe hoop of AsRawFd/FromRawFd (as the From implementation did that for the user). So they can do SockRef::from(&TcpStream) without having to deal with unsafe or raw file desctiptors.

You can also do SockRef::from(&(5 as RawFd)), though. So this story never quite worked, did it?
It looks like AsRawFd is simply the wrong trait for what you want to achieve.

Agreed.

The name already says that this is about getting "raw" FD access -- the "raw" here is in direct analogy to "raw pointer". The fact that any integer can be safely turned into an impl AsRawFd is another giveaway. So since you have been using AsRawFd I interpreted this as a deliberate choice; now it looks to me like you did this for lack of a better alternative?

Yes.

(You could have created your own trait for this, but I guess that has non-obvious downsides as well and anyway now is not the time to rehash the design of this crate.^^) In that case I think we have agreement, even though we are not using all the same words for the same things. :)

Great.

AsBorrowedFd looks great, yes! Crucially, BorrowedFd borrows ownership of the underlying FD and thus this type must be unsafe-to-construct from a RawFd (but it can implement AsRawFd for the conversion the other way around). Please post it in that forum thread.

Done.

I was imagining something like AsOwnedFd, which would be basically the same but forIntoRawFd.

Pr #237 adds an example and some more docs around the unsafe/unsound usage of SockRef::from as a stop-gap for v0.4. Hopefully we can figure out a proper fix for v0.5.

Could we add an Into<Socket> bound to this, since the types that can be fed into Into<Socket> are well-known to be able to be converted into sockets?

Could we add an Into<Socket> bound to this, since the types that can be fed into Into<Socket> are well-known to be able to be converted into sockets?

@notgull Anything that implements From<T> for Socket implies Into<Socket> for T, see https://doc.rust-lang.org/std/convert/trait.From.html#generic-implementations.

Looks like I/O safety might be stabilised in 1.62: https://github.com/rust-lang/rust/pull/95118.

I/O Safety has been stabilized in 1.63.0. I would be willing to write a PR that changes this crate to use the new I/O-safe traits, if the MSRV bump is acceptable.

@notgull we're going to bump to 1.63 in v0.5 for that reason, see https://github.com/rust-lang/socket2/pull/320.
We do have to be careful about the change in API though, we'll want to give people and nice path to upgrade. So, maybe we add the owned variants of the traits and leave the current (unsound) ones in place an deprecate them, removing them in the next version.


"uv venv"  should ask for confirmation before overwriting an existing venv

using uv --version 0.16
uv currently silently deletes an existing venv.
creating a new venv and install a package:
> uv venv /tmp/foo/.venv
Using Python 3.11.6 interpreter at /opt/tools/pyenv/var/repo/versions/3.11.6/bin/python3
Creating virtualenv at: /tmp/foo/.venv
Activate with: source /tmp/foo/.venv/bin/activate

>cd /tmp/foo
> uv pip install pytest

> ls -al .venv/bin/
   ...
   pytest
   ....

executing "uv venv" in the same directory will delete the existing venv and replace it with a pristine one.
> uv venv
Using Python 3.11.6 interpreter at /opt/tools/pyenv/var/repo/versions/3.11.6/bin/python3
Creating virtualenv at: .venv
Activate with: source .venv/bin/activate

Better usability:
> uv venv
   An existing venv is found in /tmp/foo/.venv .
   Replace? [y/N]

or a force-option (force/overwrite/override)
> uv venv --force
Using Python 3.11.6 interpreter at /opt/tools/pyenv/var/repo/versions/3.11.6/bin/python3
Creating virtualenv at: .venv
Activate with: source .venv/bin/activate

But virtualenv behaves differently:
> virtualenv --version
virtualenv 20.25.0

# create new venv
> virtualenv /tmp/foo
created virtual environment CPython3.11.5.final.0-64 in 122ms
  creator CPython3Posix(dest=/opt/tools/uv/var/tmp/foo, clear=False, no_vcs_ignore=False, global=False)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/opt/tools/virtualenv/var/cache)
    added seed packages: pip==23.3.2, setuptools==69.0.3, wheel==0.42.0
  activators BashActivator,CShellActivator,FishActivator,NushellActivator,PowerShellActivator,PythonActivator

# install a package with an executable
> /tmp/foo/bin/pip install pytest

Collecting pytest
  Using cached pytest-8.0.1-py3-none-any.whl.metadata (7.7 kB)
...
Successfully installed iniconfig-2.0.0 packaging-23.2 pluggy-1.4.0 pytest-8.0.1

# the entrypoint is there:
> ls -al bin /tmp/foo/bin
...
-rwxr-xr-x 1 wouter wouter  241 Feb 20 20:18 pytest*

# now try to repace this env,
> virtualenv /tmp/foo

created virtual environment CPython3.11.5.final.0-64 in 170ms
  creator CPython3Posix(dest=/opt/tools/uv/var/tmp/foo, clear=False, no_vcs_ignore=False, global=False)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/opt/tools/virtualenv/var/cache)
    added seed packages: iniconfig==2.0.0, packaging==23.2, pip==23.3.2, pluggy==1.4.0, pytest==8.0.1, setuptools==69.0.3, wheel==0.42.0
  activators BashActivator,CShellActivator,FishActivator,NushellActivator,PowerShellActivator,PythonActivator

# although it looks to override, the aerlier package is still there:
/opt/tools/uv/var/tmp/foo  ls -al bin
-rwxr-xr-x 1 wouter wouter  241 Feb 20 20:18 pytest*

same issue here https://github.com/astral-sh/uv/issues/1472

+1, I though about having uv venv just simply warning you that you're deleting an existing venv, but this behavior is best

Thanks for the thorough report but we'll track this in the original issue.


Update pcs.py

Add error handling for HTTPError exception to cope with http 403 error.

This is for issue #95

Can you make sure that the 403 status code is the unavailable signal of downloading url?

Hi Peter,

Can you make sure that the 403 status code is the unavailable signal of downloading url?
I think 403 is "Forbidden". And the exception should now terminate the other downloading processes.
BTW there was a type which I have just rectified.
Cheers
Ben

Thanks for your contribution.


FE: Topics: Remember user polling options

Polling options changed by the user should be persisted in localstorage per topic.
Settings to consider:

Polling mode (oldest/newest/etc)
Key/value serdes
Active filter(-s)
Search box text field

Local storage and the URL can conflict with each other we must determine which one has a priority and is the source of truth

Local storage and the URL can conflict with each other we must determine which one has a priority and is the source of truth @Haarolean

I think, that in my case the URL will have the priority. That is what I discussed with @Haarolean


Terminal always show uppercase letters when using caps lock to switch input source

VSCode Version: 1.50.1
OS Version: 10.15.7

Steps to Reproduce:

Set system input source to shuangpin, before which add shuangpin as an input source.

Lock caps lock, with caps lock unlock, you will input Chinese character, which is an expected behavior.
Input something in the integrated terminal, I can only input upper case letters. But when I input something in editor or some other application, I can input lower case letters.

Does this issue occur when all extensions are disabled?: Yes.
Actually I think it might be the problem of xterm.js. Xterm.js might decide the letters by cap lock. This is not as expected with shuangpin mode.

This looks like an upstream issue in https://github.com/xtermjs/xterm.js

Thanks for replying. Opened an issue for xterm.js. https://github.com/xtermjs/xterm.js/issues/3155


Possibly wrong description for /P

[Enter feedback here]
The internet(Tm) tells that the /P-option of format works like this: "
Zero every sector on the volume.  After that, the volume will be
overwritten "count" times using a different random number each time.
If "count" is zero, no additional overwrites are made after
zeroing every sector."
Either the ms doc is wrong or the internet(Tm) is wrong.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: c9fbdba6-cfee-e68d-e1a9-e97d09f0cfad
Version Independent ID: 26f12948-5d6d-41c2-21ac-538da6e25f7a
Content: format
Content Source: WindowsServerDocs/administration/windows-commands/format.md
Product: windows-server
Technology: windows-commands
GitHub Login: @JasonGerend
Microsoft Alias: jgerend

Hi @karniemi, thanks for raising this issue. I have updated the description for that parameter and also added a few missing parameters that are newer. The PR should be merged soon and the changes visible later today.
Thanks.
#please-close


brackets on both sides of username in minichat

I believe having just the right-side bracket indicates a (text) prompt. So I don't think not having a left-side bracket is an oversight and needs to be added.  On the contrary, having brackets on both sides of the username would look quite bad/stupid in my opinion. Just my 2 cents.


Ensure security vulnerabilities are patched in MCR images

This includes changes for:

A scheduled pipeline to scan and patch the latest published images in MCR.
Extra steps in our publishing pipelines (GHCR and MCR) to patch before publishing.

There is also some renaming and restructuring for consistency.
Notes on why we're making these particular changes:
Should we create a pipeline that runs on a schedule, or on demand? I think it makes more sense to run it on a schedule. Reason: any issues that we detect should be in our dependency tree, and will change when new vulnerabilities are discovered in those dependencies. We won't know when that happens, so nothing will prompt us to run the pipeline.
Should that pipeline scan the image built from the latest code in master, or the latest published images? The published images are the ones that actually matter, because they're being used, but it would still be useful to know if our code introduced a dependency with a vulnerability. For a pipeline that runs on a schedule, I think we should be checking the latest published images, because our code doesn't change on a regular schedule. (In theory we could patch older images too, but that would be more work and massively increase pipeline execution times, and we can add that in later if we really need it.)
Should the pipeline just create a report and send some notification if there are vulnerabilities, and let us know so we can manually run a pipeline to patch the images? Or just go ahead and patch them? I think it should go ahead and patch. Realistically, we're not going to analyze the report ourselves and have the knowledge to make good decisions. And even if there's a risk that the patch breaks our functionality, security is more important than functionality.
Can we test the patched images before publishing? We have no automated tests for images, and I don't think it'd be trivial to create them. But if we add the patching to the GHCR publishing pipeline, we can manually check the published images from VS Code, which we should probably be doing before publishing to MCR anyway.

Codecov Report

Merging #233 (67ece06) into master (a73086c) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #233   +/-   ##
=======================================
  Coverage   80.53%   80.53%
=======================================
  Files          14       14
  Lines         786      786
=======================================
  Hits          633      633
  Misses         94       94
  Partials       59       59


Deserialization problem with Beta.AccessRequestsAPI.ListAccessRequestStatus

It looks like there may be a problem deserializing the results from Beta.AccessRequestsAPI.ListAccessRequestStatus. The following code produces the expected number of results, but all of the objects are empty/default values.
result, res, err := api.Beta.AccessRequestsAPI.ListAccessRequestStatus(context.Background()).Limit(10).Execute()

Result

Hey @wcarson,
This has to do with the same timestamp issue and is fixed in https://github.com/sailpoint-oss/golang-sdk/commit/669e9bcbd062d8ce934d8b085146e9e08e24ec17
This will be a part of the next release.


Fix Module.clone in deepclone mode for internal usage.

Codecov Report

Merging #3459 (5587371) into main (c1023d9) will decrease coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #3459      +/-   ##
==========================================
- Coverage   83.56%   83.55%   -0.01%
==========================================
  Files          56       56
  Lines        6766     6768       +2
==========================================
+ Hits         5654     5655       +1
- Misses       1112     1113       +1

Files
Coverage Δ

flax/linen/module.py
91.90% <100.00%> (-0.11%)
:arrow_down:


Feature suggestion: Altitude measurement

After the new offset configuration options are implemented, it'd make sense to instruct user on how to measure altitude changes using air pressure sensor.
User would reset first altitude offset to zero and then it'd be possible to measure altitude changes (in metres of feet) with the sensor.

Closing, will be added as voting item on forum


Unicode symbols not working

When having unicode symbols in class names or grade descriptions, when exporting grades the unicode characters get misinterpreted.


DIETClassifier wrongly detects an entity with another

Rasa version: Rasa 1.9.4
Python version: Python 3.6.9
Operating system: Ubuntu 18.04
Issue:
I have an entity annotated as: [MAD](iata:mad) and with a regex: [a-zA-Z]{3}
And I have another entity: [OABC123](booking_id) with regex: [OHWFGA]{1}[\dA-Z]{6}
I have around 100 iata examples and around 40 booking id examples.
For some reason, NLU detects a booking id as iata consistently, which is wrong.
I recently migrated from 1.7.4 to 1.9.4.
In 1.7.4 the exact same dataset produced expected results, but not in 1.9.4.
Is it related to https://github.com/RasaHQ/rasa/issues/5475?
2020-04-02 13:08:25 DEBUG    rasa.core.processor  - Received user message 'BCF4D6E' with intent '{'name': 'inform', 'confidence': 0.9982755780220032}' and entities '[{'entity': 'iata', 'start': 0, 'end': 7, 'extractor': 'DIETClassifier', 'value': 'BCF4D6E'}, {'start': 3, 'end': 4, 'text': '4', 'value': 4, 'confidence': 1.0, 'additional_info': {'value': 4, 'type': 'value'}, 'entity': 'number', 'extractor': 'DucklingHTTPExtractor'}, {'start': 5, 'end': 6, 'text': '6', 'value': 6, 'confidence': 1.0, 'additional_info': {'value': 6, 'type': 'value'}, 'entity': 'number', 'extractor': 'DucklingHTTPExtractor'}]'

Command or request that led to error:
rasa train && rasa shell -vv

Content of configuration file (config.yml)
language: en
pipeline:
  - name: "SpacyNLP"
    case_sensitive: false
    model: "en_core_web_lg"
  - name: "SpacyTokenizer"
  - name: "SpacyFeaturizer"
  - name: "RegexFeaturizer"
  - name: LexicalSyntacticFeaturizer
    features: [
      ["low", "title", "upper"],
      [
        "BOS",
        "EOS",
        "low",
        "prefix5",
        "prefix2",
        "suffix5",
        "suffix3",
        "suffix2",
        "upper",
        "title",
        "digit",
      ],
      ["low", "title", "upper"],
    ]
  - name: "CountVectorsFeaturizer"
  - name: "CountVectorsFeaturizer"
    analyzer: "char_wb"
    min_ngram: 1
    max_ngram: 4
  - name: DIETClassifier
    epochs: 100
  - name: "EntitySynonymMapper"
  - name: ResponseSelector
  - name: "DucklingHTTPExtractor"
    url: "http://<IP_ADDRESS>:8000"
    dimensions: ["time", "number", "ordinal", "distance", "amount-of-money", "email", "url", "phone-number"]
    locale: "en_US"
    timezone: "Europe/Chisinau"
  - name: "SpacyEntityExtractor"
    dimensions: ["GPE", "FAC"]
  - name: "components.extractors.entity_filter.EntityFilterExtractor"
    mappings:
    - entities: ["FAC", "iata"]
      mapTo: "FAC"
    - entities: ["GPE", "iata"]
      mapTo: "GPE"

policies:
  - name: TEDPolicy
    max_history: 10
    epochs: 20
    batch_size:
    - 32
    - 64
  - name: AugmentedMemoizationPolicy
    max_history: 6
  - name: TwoStageFallbackPolicy
    core_threshold: 0.3
    nlu_threshold: 0.6
  - name: FormPolicy
  - name: MappingPolicy

Thanks for the issue, @chkoss will get back to you about it soon!
You may find help in the docs and the forum, too 🤗

My issue was solved by changing the pipeline.

If your pipeline contains CRFEntityExtractor and EmbeddingIntentClassifier you can substitute both components with DIETClassifier. You can use the following pipeline for that:

Migration guide from 1.7 to 1.8 didn't work out for me, so I just used spacy pipeline from docs
My current working config:
# Configuration for Rasa NLU.
# https://rasa.com/docs/rasa/nlu/components/
language: en
pipeline:
  - name: "SpacyNLP"
    case_sensitive: false
    model: "en_core_web_lg"
  - name: "SpacyTokenizer"
  - name: "SpacyFeaturizer"
  - name: "RegexFeaturizer"
  - name: LexicalSyntacticFeaturizer
  - name: "CountVectorsFeaturizer"
  - name: "CountVectorsFeaturizer"
    analyzer: "char_wb"
    min_ngram: 1
    max_ngram: 4
  - name: DIETClassifier
    epochs: 100
  - name: "EntitySynonymMapper"
  - name: ResponseSelector
    epochs: 100
  - name: "DucklingHTTPExtractor"
    url: "http://<IP_ADDRESS>:8000"
    dimensions: ["time", "number", "ordinal", "distance", "amount-of-money", "email", "url", "phone-number"]
    locale: "en_US"
    timezone: "Europe/Chisinau"
  - name: "SpacyEntityExtractor"
    dimensions: ["GPE", "FAC"]
  - name: "components.extractors.entity_filter.EntityFilterExtractor"
    mappings:
    - entities: ["FAC", "iata"]
      mapTo: "FAC"
    - entities: ["GPE", "iata"]
      mapTo: "GPE"

policies:
  - name: TEDPolicy
    max_history: 10
    epochs: 20
    batch_size:
    - 32
    - 64
  - name: AugmentedMemoizationPolicy
    max_history: 6
  - name: TwoStageFallbackPolicy
    core_threshold: 0.3
    nlu_threshold: 0.6
  - name: FormPolicy
  - name: MappingPolicy


left+right click or left+scrooll button push unregister ZoomEnd and ZoomStart events

I experienced a problem with zoom behavior.
When on a object where zoom behavior is registered I push left and right button at once and move with mouse, ZoomStart and ZoomEnd handlers are unregistered (not being called anymore).
The same happen when I click to zoom button and left button and move.
Any ideas how to prevent this behavior ?
Experienced with Chrome: Version 41.0.2272.101 m
Many thanks
Vaclav

zoom event not released.

If it wasn't clear from the description, of course I release the buttons then. And since then it doesn't work. My other colleagues experienced the same problem on other machines with other D3 apps.
Edited in original description

i mean the default zoom event,not button event

This sounds like a duplicate of #1627.


C++ comment highlighing doesn't support continuation backslashes

Code such as:
// I am a comment \
and this is still part of the comment

...is not interpreted as a two-line comment.
See compiler-explorer/compiler-explorer#2682

Thanks for reporting! This is a bug in the C++ tokenizer.
Unfortunately, we don't have the resources to address this right now, but we're more than happy to accept a PR for this!

This was fixed in the meantime via https://github.com/microsoft/monaco-languages/pull/143


Stand-alone Toolbar class

The best way forward for this was to start over after the big CSS merge.
Fixes https://github.com/jupyter/jupyterlab/issues/844

cool i will have a look

@ellisonbg FYI, this is still work-in-progress.

LGTM, thanks!


[CSL-1575] Rewrite embed-config

Now we have a no-embed flag which makes CSL load constants.yaml and genesis at runtime, and we also have two environment variables that are read when no-embed is on:

CSL_RES_PATH says where to look for the config and genesis files.
CSL_CONFIG_NAME says which section to take from the config file.

Nice :) cc @cleverca22

BTW, we should pass these params from CLI, env variables are hard from Windows

@volhovM what's the status on this, can we prioritize it?

@domenkozar I'm working on fixing @georgeee's comments now.

@neongreen @georgeee can we keep the CSL_RES_PATH. We want this for the benchmarking setup. For the benchmarking the current approach with using the dev mode and generating the genesis block on the fly is not working well at all (it takes up all memory and fails when using several thousand addresses). We want to generate an external genesis block using the normal tool and pass that in at runtime.

@dcoutts it was later decided to use flags to node, following set:
--custom-config-file=constants_new.yaml
--custom-config-name=devnet_shortep
--custom-genesis-core-bin=..
--custom-genesis-gt-bin=..

Great. I prefer flags vs env vars anyway!

@neongreen needs a rebase on top of master

Okay, @georgeee @domenkozar this is ready for re-review. Will rebase in the morning.

I will test this today - please don't merge yet.

@domenkozar Travis tests are failing, I'm investigating

@neongreen ready for testing?

@domenkozar should be, yes

@domenkozar you were planning to test this

Will do tomorrow.

@georgeee I asked not to merge, why did you merge it?


Add option to parse lastmod and changefreq and priority

I would love this!

i wanted it too so i created a pull request to offer this solution. Don't know if and how fast it will be accepted. If you need it quick @Nedi11 & @lh15 you could also use my branch of sitemapper to run your project with.


Fixing latest Docker image vulnerabilities

Upgrading Node base image

Includes latest version upgrades for detected vulnerable packages - openssl.

Removed busy box upgrade as latest secure version is available in the base image upgrade itself. Had added it in the previous PR as back then base image didn’t have the latest package version.

@MukuFlash03 you didn't move this back to "Ready for review", but I got the GitHub update, so I'm looking at it anyway...


DPL-188 deployment fix

move new Heron submission templates to record loader

because deployment was failing
they are dependent on the new request type which was in record loader, and limber:setup is run before record loader, on deploy
had to also move some existing request types over otherwise it didn't work locally when running db:setup

Not ready to go yet as needs:

things removing from seeds
things removing from sequencing.rake
and extra things adding like RequestType::Validator, and other records

This approach is too complex (too many dependencies). Going to try a different approach.


Ingest Script for Y-Dwarf Photometry

Started playing around with a script for ingesting Y-dwarf photometry data. I've started making this by adapting the script I just wrote for the Y-dwarf proper motion ingest.

For some reason this pull request is trying to merge all of my changes from the proper motion ingest also, so I'm going to close it for now to fix that


Error when trying to download image

flagrow/upload extension version: 0.5.0
flarum version: 0.1.0-beta.6
Upload adapter causing issues: local

I have disabled download logging.
2017/04/19 22:45:30 [error] 1708#1708: *2016 FastCGI sent in stderr: "PHP message: PHP Notice:  Undefined variable: download in /var/www/forum/vendor/flagrow/upload/src/Commands/DownloadHandler.php on line 100" while reading response header from upstream, client: <IP_ADDRESS>, server: xxx, request: "GET /api/flagrow/download/5ae1e98a-7f36-4c01-9019-52bc670d5eea/231/qo00gjAWzIx8trjbuH9MTE4vEFsMsbmP8a23gPfX HTTP/2.0", upstream: "fastcgi://unix:/var/run/php/php7.0-fpm.sock:", host: "xxx", referrer: "xyz"

The relevant line: https://github.com/flagrow/upload/blob/7ce01cf6a80c494d07ad09953dbd5147f643d151/src/Commands/DownloadHandler.php#L100

Looks like the variable isn't defined or, you meant $downloader

Nope it was download, but if you disable download logging, the variable was not set.


Improve breaking change notice in 5.18 changelog regarding module path

Summary
Ticket Link
https://community.mattermost.com/core/pl/76uzwugmt38758a54ozf7tp7wa

Same for https://docs.mattermost.com/administration/important-upgrade-notes.html.

Will update source/administration/important-upgrade-notes.rst once the PR is approved.


Add RoundButton and BadgedButton shared components

Added the RoundButton and BadgedButton shared components
Added the storybook entries

Out of two options:

Having a Button component, a Badge component, and a component combining the two:

vs:

Having a Button component and a button-with-a-badge component:

why, do you think, the second option is preferable?

Doing it this way, the syntax will be:

Would it be as simple as this if we do it the other way?

On 5 Apr 2019, at 11:20, Andrey Azov<EMAIL_ADDRESS>wrote:
Out of two options:
Having a Button component, a Badge component, and a component combining the two:
https://user-images.githubusercontent.com/6834224/55621052-5f783300-5794-11e9-9401-be8275f4998d.png
vs:
Having a Button component and a button-with-a-badge component:
https://user-images.githubusercontent.com/6834224/55621176-afef9080-5794-11e9-89c2-d3ae46a8e273.png
why, do you think, the second option is preferable?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/Ensembl/ensembl-client/pull/31#issuecomment-480224753, or mute the thread https://github.com/notifications/unsubscribe-auth/AC8V90IxfBYTFf-6sNqzxkKHmZzCcRSrks5vdyNcgaJpZM4cbDMk.

const button = <Button>Something</Button>
const badge = <Badge>lol</Badge>

<BadgedButton
  button={button}
  badge={badge}
/>

This way looks simple as well.

It does but the current structure does not require us to define two additional variables.

On the other hand, it leaves us with only one type of badge — green circle ¯\_(ツ)_/¯

As discussed, the badge can be customised using the className prop.


Trigger violates primary

Summary of Issue and Troubleshooting Steps
Issue:
When executing the PL/SQL code to populate the puntos_mes_huesped table using a trigger, you encounter a unique constraint violation (ORA-00001). This occurs because the trigger attempts to insert duplicate primary key values into puntos_mes_huesped.
Trigger Overview:
You have a trigger (tr_puntos) designed to calculate and insert data into puntos_mes_huesped based on data inserted into detalle_diario_huespedes.
Troubleshooting Steps:
Dropped and Recreated Table:
Initially, you dropped the puntos_mes_huesped table, removed its primary key constraint, and recreated it to test the trigger successfully. However, this approach is not feasible for a production environment due to security concerns.
Unique Constraint Violation:
Even after ensuring no duplicate data is present (by truncating tables before testing), you continue to face issues due to the primary key constraint on puntos_mes_huesped.
Desired Outcome:
You need to modify the trigger so that it correctly inserts data into puntos_mes_huesped without violating the primary key constraint, allowing for repeated execution without needing to drop and recreate constraints.
Steps Taken for Resolution:
Verified the structure and data flow between detalle_diario_huespedes and puntos_mes_huesped.
Adjusted the trigger logic and data calculations to ensure accurate and non-duplicate inserts.

checked data base connection for preexisting triggers that could conflict with tr_puntos, deleted the preexisting triggers and now script runs smoothly


Turbsim excecutables and version numbering

Hi,
I was wondering if the executables for the updated versions of TurbSim are available from the GitHub repository (or somewhere else)? We are about to launch the latest release of our software SIMA (which includes wind turbines), where TurbSim-type wind files can be used as input. We would, therefore, like to provide a link to your software, but the latest compiled version I could find was on the legacy TurbSim page (v2.0, https://www.nrel.gov/wind/nwtc/turbsim.html)

Dear @stiansorum,
I forgot to add the TurbSim to the latest release.  It will be available here in a few hours: https://github.com/OpenFAST/openfast/releases/tag/v3.5.3.
Regards,

The latest windows executable is now available in the asset download for version 3.5.3.


kdialog title option with double dash

The options for kdialog in KDE use double dashes.

Good catch!


Microsoft Sql Server icon not rendered

For some reason Microsoft Sql Server icon isn't being rendered by shields.io

Looks like you may have the wrong reference to the logo
?logo=microsoft-sql-server
https://img.shields.io/badge/style-for--the--badge-green?logo=microsoft-sql-server&style=for-the-badge

Thanks, I thought it used the same name as simple icon.


[Bug] CleanRepo and build-docs-verifier need to upgrade to .NET 8

Associated WorkItem - 196931

Closed by #284 and #285


Ad overlaps tab bar

Thanks for making this plugin. Looking forward to using a Capacitor plugin for this.
Am I doing anything wrong in the setup?
This is happening in iOS simulator.

This is my options:
  options: AdOptions = {
    adId: 'myAdId,
    adSize: AdSize.BANNER,
    position: AdPosition.BOTTOM_CENTER,
    hasTabBar: true,
    tabBarHeight: 100, // Tried this to see if it did anything.
  };

@letsbelopez Thank you for your report. I am sorry for that. Currently iOS dose not support this two arguments. Next release will be fixed this issue.

Is there an ETA for the next release that fixes this issue?

Yes I am going to fixed this issue in next release.

When do you plan your next release?

Hello, any on this issue? Currently tabBarHeight still has no effect on iOS.

Tested in Android Marshmallow and it also overlaps buttons, text, etc. at the bottom. I think it would be better if the ad position will just consume a space at the bottom instead of a floating one. This may lead to Google Play app rejection as it obstructs UI components of the app.


merge: Batches not getting Unreferenced

This commit fixes an issue where the merge operator was not properly unreferencing batches.

Since this PR held the promise of reducing the memory usage during compaction, I re-ran the tests that had previously flagged the problem and posted a write-up. The tl;dr is that it does indeed reduce memory during compaction by about 3.5x at the smaller object sizes, though memory consumption is still higher during the compaction phase than the load phase at these smaller object sizes.
Also just to test for general stability, I did a run through all the Autoperf tests using this branch at commit 6f67560. I can testify that it survived all the tests and I reviewed the summary dashboard and rather than assemble a bunch of screenshots that effectively show flat lines I can also say that it didn't cause any statistically significant deltas in the macro trends compared to other recent test runs at tip of main.
In conclusion, it's a functional 👍 for me.


Fix relative path for KNOWN_HOSTS and --key-file=

Currently these have to be set with full path. Using relative paths will not work.

Implemented in 7706c18 @martivo

Implemented in 7706c18 @martivo