Protobuf loader fixes.

This fixed two issues:

Sometimes the the glob would not find the common protos.

Fixed by explicitly using the dirname to and finding the protos from there

The protobuf v6 resolver is not robust enough to handle fully include paths.

i.e. if you load the proto /user/.../proto/google/test/example.proto which includes the proto google/test/other.proto, the protobufjs resolver would resolve to /user/.../proto/google/test/google/test/other.proto.
I fixed this by searching at each level of the original proto path for the include. If this falls through try the last ditch effort of using the protobufjs resolver.

i.e. if you load the proto /user/.../proto/google/test/example.proto which includes the proto google/test/other.proto, the protobufjs resolver would resolve to /user/.../proto/google/test/google/test/other.proto.

We've always used the root option on grpc.load to handle this. Does that not work here?

We've always used the root option on grpc.load to handle this. Does that not work here?

The issue is that we fundamentally need more than one root. One location houses the API specific stuff, but the general cross-API protos still live in google-proto-files.

Does that mean you're loading some files from a local path and others from google-proto-files? Why not just copy over the common files as well? Adding more features to this lib and making it support half-using it doesn't seem like the right path towards its deprecation.

I think there a couple of reasons to not just copy over the common files. One reason is to minimize duplication across multiple apis. Another reason is for consistency across languages. For every other language, the pattern is to only copy the service specific files and depend on a common proto package to supply those protos.
I think the path towards deprecation is not deprecation of the module as a whole but deprecation of using this as the source of truth for service specific protos.
@lukesneeringer is my understanding correct?

This is a good question and worth exploring.
Question Restatement
Should we copy over all proto dependencies into every API? (So, if Speech uses timestamps and so does Vision, then each of them would get that proto separately.)
Thoughts

In most languages, this is not even an option. Creating the Descriptor class in multiple places (e.g. g.c.speech.types.Timestamp and g.c.vision.types.Timestamp) would cause problems because if a user using both APIs used one of the constructors to make an object, it would not be usable in the other API, and that would be surprising.
Pro: Copying the protos everywhere is slightly more in keeping with how Node thinks about this kind of stuff.
Con: This introduces "another way to do it" that needs to be separately maintained and can be a source of bugs or process problems. The existing google-proto-files is proof positive of this; Node did it a different way than the other six languages and it causes a lot of process issues.
Con: It would be more initial work to write the code that would copy the common files. We could get around this by just copying all common protos all the time (which would be super easy).
Pro/Con: What is the story if a common proto is updated (e.g. a new field added)?

It could actually be better if we do the copy-the-world because we do not instantly opt everyone in.
It could be a lot worse if the new field was used widely quickly; updating the world could be painful.
We eventually want to support generation of APIs where we do not control the protos being used for the APIs, but we will always control the common ones. This seems to argue for a central package.

Recommendation
I personally think we should do what @landrito is doing and "make Node work like everyone else". I think I see more cons and pros for the "copy them to all the APIs" approach.
However, I am not entirely sure I understand @stephenplusplus' concern, and I want to make sure I at least understand it even if I end up not agreeing with him. :-) So, ideally I would like to either convince him that this is the right answer or, at minimum, make sure I fully understand why he does not intuitively think that.

Node did it a different way than the other six languages and it causes a lot of process issues.

I'm playing catch-up here, because I haven't heard a reason articulated; only that @lukesneeringer doesn't like it :)
The most Node.js way to solve this problem is how this library is; one module has the most current version of all Google .proto files. When APIs change, we update this module, and publish a release. I suppose an even Node-ier way would be to have a module for each individual API, which uses the module's semver notation to describe the API's version increments. But, you gotta draw the line somewhere with modularity, and that might be where it is.
Without fully understanding what the issue is now, I figure it might have to do with when an API is developing a new feature or is altogether private. A new set of private .proto files needs to be tested against a Node.js client library, and suddenly, we're stuck. If we can't publish them on google-proto-files, how can we test them?
If that's the premise for this solution-- and the only other solution I knew up until now, which was "kill google-proto-files"-- then let me try to understand the new load() functionality. Is this the intended usage:
Is the API public?
var grpc = require('grpc')
var protoFilePath = require('google-proto-files').pubsub.v1
grpc.load(protoFilePath)

Is the API private?
require('google-proto-files').load('my-custom-path') // no `grpc.load()` necessary

I think that's a fine solution, and I'd just like to be clear this is "the" solution for the long-term. As-in, I'm still not sure if we're killing off google-proto-files, or if this new load() functionality fixes the problems you've been having with this module.
However, if I'm following correctly, load() is only for the benefit of private/pre-release APIs. But, we're forcing all users of google-proto-files to install the version of grpc that we declare as our dependency. If the user of google-proto-files is not using it the private way:

It's extra weight
That module is historically a difficult install, because of the native compilation step

If they are using google-proto-files the private way:

The version of grpc loaded from google-proto-files is predetermined and inaccessible for customization. I'm not sure how, but I imagine that is a limiting factor

This module was meant to be just a collection of files that previously weren't easily available without copying / pasting into your app (or in our case, client library). It didn't have any functionality to return an actual API interface for the proto's APIs. I don't mind going that direction at all, however this is where I would consider modularization.
google-proto-files = Get the Google API proto files
google-proto-apis = Get a gRPC-proto-loaded API
Because, ideally, all of the current google-proto-files shortcut filepaths would be consistent with how the new load() works:
require('google-proto-apis').pubsub.v1() // instantiates gRPC client

That would draw a clear line of responsibility between the modules, and avoid forcing the public API users to load the extra grpc. I can definitely see ways to keep one module if we intend to go in the new direction of "not just returning file paths", where all client libraries would use the load() functionality. But, I'm still working backwards trying to figure out what problem we're solving, so apologies if my solution is aimed in the wrong direction. I'll appreciate any course correction, and thank you for hearing me out! :)

@stephenplusplus Thanks so much for the well thought out response. Based on that I think that this logic is in the wrong place. I am moving the logic into google-gax.


fix test

References and relevant issues
Follow on from #4991
see: https://github.com/napari/napari/pull/4991#discussion_r1518553921
Description
Better naming in test_widget_hide_destroy
Adds more widget clean up steps. Draga suggested it was best to add these back.

cc @DragaDoncila

@Czaki I suggested to Lucy that these be added back because I thought when we destroy the enclosing dock_widget, the widget will become unparented and so may leak? But it would be good if you could confirm

ping @Czaki


DHP throws error and does not start

The directory structure looks like this:

Version is 1.13.1, but also happened at 1.13.0

This only happens in certain directories

:tada: This issue has been resolved in version 1.13.2 :tada:
The release is available on:

npm package (@latest dist-tag)
Visual Studio Marketplace
GitHub release

Your semantic-release bot :package::rocket:


Great work

Hi, @ajabri
Very great work. Your talk at CVPR20 about this work is also impressive. Looking forward to the code.

+1

+1 Great work, hope the code is release soon!

+1 again


Add hyperref config

This config replaces the boxes with coloring the link text. This change makes the document more readable.
Applies only to the simple mode.

The colored links would appear in a printout as well. Can you wrap this as an boolkey option for the basimple environment, like it is with the blocknotice? Should not be to hard. https://github.com/Nuckal777/ba-latex-template/blob/rewrite/baarticle.cls#L296
   \define@boolkey[BA]{simple}{blocknotice}[true]{}

   \presetkeys[BA]{simple}{type=undefined,blocknotice=true}{}
   ...
    \newenvironment{basimple}[1][]{
        \setkeys[BA]{simple}{#1}
       ...
        \ifBA@simple@blocknotice
            \mkblocknotice{
                signature=\@basimplesignature,
                date=\@basimplereturndate,
                location=\@basimplelocation
            }
        \fi
        ...
    }

Done ✅
The default value is false. Perhaps a note in the documentation would be handy.


[ETL-690] Add additional expectations for fitbit data types

~There is an issue with the upload-and-deploy workflow that is causing tests to fail, which I've documented here: https://sagebionetworks.jira.com/browse/ETL-699~
There is no issue.
I was able to deploy this manually and did not have any issues generating validation docs for the additional data types. Additionally, I ran the tests which were prevented from running due to the issue mentioned above and they all passed (as expected -- there weren't any changes made to the code).

@rxu17

I noticed that upload-and-deploy is not included in the build checks anymore

That's strange. I can see upload-and-deploy.
The workflow completes successfully now.

That's strange. I can see upload-and-deploy.

Yup, it appears now for me - after your recent deployments/pushes


Xiaomi/Redmi Support

I really love this app but unfortunately it doesn't work with Xiaomi/Redmi devices, for example the Redmi Note 12 Pro Plus 5g. As far as I can tell it is impossible to get this feature working on this device without root permissions. Since I only have access to the Redmi device I mentioned I couldn't check on any other one but on the Note 12 Pro Plus the brightness is controlled by a 0-16 integer value in /sys/class/leds/torch-light0/brightness which is only accessible on a rooted device (as far as I can tell anyway). I haven't looked much into the inner workings of FlashDim but I'd love Xiaomi devices to be supported. I wrote a quick and dirty proof of concept (Github Repo) which just does echo BRIGHTNESS_VALUE > /sys/class/leds/torch-light0/brightness using the Shell.cmd(command).exec() method provided by the topjohnwu libsu API.

Thanks Emil for your idea.
Somehow related to #61.
I think this does not only regard Xiaomi and Redmi phones, but all phones which do support flashlight dimming but do not implement the Android API I am using to change that.
I still don't have a rooted phone where I could develop this on and test it out.
An emulator wouldn't really help when playing with the flashlight.

Hi @EmilEmilchen again,
I finally have a rooted emulator up and running now and I can see the different LEDs at the mentioned path /sys/class/leds/.
Your POC seems to work for my adapted path to one of the LEDs, even though I can not verify I the flashlight brightness would change because I still don't have a rooted physical device.
I plan on implementing some kind of fallback root access, but all development would be by imagining the outcome without being able to test it. Then I would need a user like you who can test it out on their rooted physical devices.
For now I have a question: What happens, if you write invalid values to the mentioned path? So writing a value from 1 to 16 in your case would obviously just change the flashlight brightness. But what happens if you write 0, -1, 99 and so on.
This information would be crucial to be able to properly implement this change.

Of course I'd love to help out with testing! From what I can recall I'm pretty confident that if any invalid value is written its just sort of ignored. As this file is part of sysfs it's sort of write-only and you e.g. can't read it's contents at all but writing invalid values definitely doesn't "break" anything. I'll double check the exact behavior in the next few days.
One more thing: I don't know whether the file path as well as the range of valid inputs is the same on every device where you need to use this method for brightness control but in assuming it is not perhaps some kind of advanced setting could at least be considered.

Of course I'd love to help out with testing! From what I can recall I'm pretty confident that if any invalid value is written its just sort of ignored. As this file is part of sysfs it's sort of write-only and you e.g. can't read it's contents at all but writing invalid values definitely doesn't "break" anything. I'll double check the exact behavior in the next few days.

That would be nice, you can check it with your "simpleFlashDimmer" and just set something like 50.
I don't think it's write-only as I can read these files with a file explorer.

One more thing: I don't know whether the file path as well as the range of valid inputs is the same on every device where you need to use this method for brightness control but in assuming it is not perhaps some kind of advanced setting could at least be considered.

As mentioned by rabaimor in #61 there are path differences. And of course different devices have different max levels, so we would need to be able to adjust that.

Sorry for my late response. I tried it out and I was partially right: The file isn't strictly speaking read only, it's just that reading it always reads 0 or 1 depending on if the torch is on or off, no matter the brightness:
rubypro:/sys/class/leds/torch-light0 # echo 10 > brightness     //turned on
rubypro:/sys/class/leds/torch-light0 # cat brightness
1
rubypro:/sys/class/leds/torch-light0 # echo 15 > brightness     // still on, brighter
rubypro:/sys/class/leds/torch-light0 # cat brightness
1
rubypro:/sys/class/leds/torch-light0 # echo 1 > brightness      // dim but on
rubypro:/sys/class/leds/torch-light0 # cat brightness
1
rubypro:/sys/class/leds/torch-light0 # echo 0 > brightness      // off
rubypro:/sys/class/leds/torch-light0 # cat brightness
0
rubypro:/sys/class/leds/torch-light0 # echo -1 > brightness     // no change, note exit code at start of line, also no change if torch was on before
1|rubypro:/sys/class/leds/torch-light0 # cat brightness
0
rubypro:/sys/class/leds/torch-light0 # echo 100 > brightness    // on but pretty dim, about equivalent to 4-5
rubypro:/sys/class/leds/torch-light0 # cat brightness
1
rubypro:/sys/class/leds/torch-light0 # echo 500 > brightness    // on but pretty dim as well, about equivalent to 3-4, definitely dimmer then with 100
rubypro:/sys/class/leds/torch-light0 # cat brightness
1

I also checked with a photoresistor and the maximum brightness where there is a change compared to the next lower number is 15. I don't know why I wrote 16 in my initial post, I mean including 0 that would be 17 but anyway, its 0 - 15 for this device.
Regarding invalid values see the comments in my code block.
Hope that helped!


Update Cryptor.php

I think is better uses pbkdf2 function because hash_pbkdf2 is only in php 5.5 and later and this other function can work in 5.3 and 5.4... Saludos desde Mexico!!!

Thanks @raulsilvamx . I ended up fixing this by including a polyfill library via Composer, which means this project should work fine back to PHP 5.5.  The latest stable version of this project is now 3.1.0.
Since PHP 5.4 and earlier are all at End Of Life, I have decided not to support anything earlier than 5.5 any more.


📃: Phonepe landing page

:red_circle: Title : Phonepe landing page
:red_circle: Aim : to create the replica of phonepe website
:red_circle: Tech Stack Used : HTMl,CSS
Screenshots 📷

:white_check_mark: To be Mentioned while taking the issue :

Full name :  Damini Chachane
What is your participant role? GSSOC

Happy Contributing 🚀
All the best. Enjoy your open source journey ahead. 😎

@Avdhesh-Varshney  assign this issue to me

@Damini2004 go ahead.


Default filter to show not active redirects

Fixed by https://github.com/tinect/TinectRedirects/commit/02868ba0eb7aad4563d7960d3bffde27524b22a0


[Bug] AMF does not handle SCTP stream identifier

Hello everyone, I am the maintainer of UERANSIM, and recently made some improvement on SCTP stream handling. However we could not use your core network for the relevant cause. I think the AMF does not handle streams properly.
Although it may be considered as a missing feature, here is the bug:
AMF does not handle SCTP stream identifier as specified by 3GPP, it always uses "0" as stream identifier.
To Reproduce

Clone https://github.com/aligungr/UERANSIM
Set configuration of UERANSIM to free5gc, by modifying config/profile.yaml
Run the simulator, trigger initial-registration

Expected behavior
I am not completely sure, but NgSetupResponse and DownlinkNASTransport should have been sent with different stream numbers since one is non-UE-associated signalling and the other is UE-associated signalling. But the stream identifier is always zero.
For additional information please refer to 3GPP specs such as TS 38.412
Environment:

free5GC Version: v3.0.1
OS: Ubuntu 20.04
Kernel version: 5.4.0-42-generic
go version: 1.14.4
c compiler version (Option): gcc 9.3.0

Trace File
Configuration File
(not included since the bug is easily reproducible. )
PCAP File
sctp_stream.zip
Log File
(not included since the bug is easily reproducible. )
Additional context
n/a

I also tried it, when I look at the line of localhost.38412 > localhost.41470, it seems like that.
root@free5gc05:~# tcpdump -r free5gc.pcap |grep sctp|grep SID
reading from file free5gc.pcap, link-type LINUX_SLL (Linux cooked)
11:08:13.897123 IP localhost.41470 > localhost.38412: sctp (1) [DATA] (B)(E) [TSN:<PHONE_NUMBER>] [SID: 1] [SSEQ 0] [PPID 0x3c]
11:08:13.906372 IP localhost.38412 > localhost.41470: sctp (1) [DATA] (B)(E) [TSN: 786140333] [SID: 0] [SSEQ 0] [PPID 0x3c]
11:08:20.298951 IP localhost.41470 > localhost.38412: sctp (1) [DATA] (B)(E) [TSN:<PHONE_NUMBER>] [SID: 1] [SSEQ 1] [PPID 0x3c]
11:08:20.492203 IP localhost.38412 > localhost.41470: sctp (1) [SACK] [cum ack<PHONE_NUMBER>] [a_rwnd 106496] [#gap acks 0] [#dup tsns 0] , (2) [DATA] (B)(E) [TSN: 786140334] [SID: 0] [SSEQ 1] [PPID 0x3c]
11:08:21.096914 IP localhost.41470 > localhost.38412: sctp (1) [DATA] (B)(E) [TSN:<PHONE_NUMBER>] [SID: 1] [SSEQ 2] [PPID 0x3c]
11:08:21.200157 IP localhost.38412 > localhost.41470: sctp (1) [SACK] [cum ack<PHONE_NUMBER>] [a_rwnd 106496] [#gap acks 0] [#dup tsns 0] , (2) [DATA] (B)(E) [TSN: 786140335] [SID: 0] [SSEQ 2] [PPID 0x3c]
11:08:21.436550 IP localhost.41470 > localhost.38412: sctp (1) [DATA] (B)(E) [TSN:<PHONE_NUMBER>] [SID: 1] [SSEQ 3] [PPID 0x3c]
11:08:21.751484 IP localhost.38412 > localhost.41470: sctp (1) [DATA] (B)(E) [TSN: 786140336] [SID: 0] [SSEQ 3] [PPID 0x3c]
11:08:21.932471 IP localhost.41470 > localhost.38412: sctp (1) [SACK] [cum ack 786140336] [a_rwnd 106496] [#gap acks 0] [#dup tsns 0] , (2) [DATA] (B)(E) [TSN:<PHONE_NUMBER>] [SID: 1] [SSEQ 4] [PPID 0x3c]
11:08:22.137431 IP localhost.41470 > localhost.38412: sctp (1) [DATA] (B)(E) [TSN:<PHONE_NUMBER>] [SID: 1] [SSEQ 5] [PPID 0x3c]

The environment tested here is as follows.

free5GC Version: v3.0.3
OS: Ubuntu 18.04
Kernel version: 5.0.0-23-generic
go version: 1.14.4
c compiler version (Option): gcc version 7.5.0

Update: You can now use master branch of UERANSIM. Also since this error avoids free5gc to be used by UERANSIM, I made this error ignorable in our side.
In /config/free5gc/gnb.yaml there is an option called ignoreStreamIds. You can set this value to true in order to ignore this error in gNB side.

I would like to emphasize on this issue.
At current time, free5gc is only using SCTP stream id 0 for every NGAP signaling messages. Using the SCTP stream id 0 for non-UE signaling, and > 0 for UE-associated signaling (eventually the RAN-UE-NGAP-ID value), seems a common practice that already existed in 4G. Some applications and gNB implementations are relying on the SCTP stream id to dispatch the signaling messages to the correct handler. Therefore it could be nice to adopt this behavior in free5gc: that would enable a better interoperability.
The exact description related to the handling of SCTP stream ids lies in the TS 38.412, section 7, which is not very explicit unfortunately...
I am running free5gc with the following env:

free5GC Version: v3.0.5
OS: Ubuntu 20.04
Kernel version: 5.4.0-62-generic
go version: go1.14.4

I would like to emphasize on this issue.
At current time, free5gc is only using SCTP stream id 0 for every NGAP signaling messages. Using the SCTP stream id 0 for non-UE signaling, and > 0 for UE-associated signaling (eventually the RAN-UE-NGAP-ID value), seems a common practice that already existed in 4G. Some applications and gNB implementations are relying on the SCTP stream id to dispatch the signaling messages to the correct handler. Therefore it could be nice to adopt this behavior in free5gc: that would enable a better interoperability.
The exact description related to the handling of SCTP stream ids lies in the TS 38.412, section 7, which is not very explicit unfortunately...
I am running free5gc with the following env:

free5GC Version: v3.0.5
OS: Ubuntu 20.04
Kernel version: 5.4.0-62-generic
go version: go1.14.4

Hello, please upgrade free5gc to latest version v3.3.0, the stream id problem would resolved.


[stable/wordpress] Fix warning with ingress annotations

Signed-off-by: juan131<EMAIL_ADDRESS>Is this a new chart
No
What this PR does / why we need it:
This PR addresses a warning that occurs when overwriting the ingress.annotations parameter.
Which issue this PR fixes

fixes https://github.com/helm/charts/issues/18532

Checklist

[x] DCO signed
[x] Chart Version bumped
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

/ok-to-test
/lgtm

/ok-to-test
/lgtm

/ok-to-test
/lgtm


Making Layout Adapter's queue public

Making the backgroundLayoutQueue property in ReloadableViewLayoutAdapter public will help us get a reference of the underlying queue on which we can retrieve our Realm objects.
Fixes #104

Codecov Report

Merging #105 into master will increase coverage by 0.06%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #105      +/-   ##
==========================================
+ Coverage   92.56%   92.63%   +0.06%
==========================================
  Files          53       53
  Lines        3053     3053
==========================================
+ Hits         2826     2828       +2
+ Misses        227      225       -2

Impacted Files
Coverage Δ

LayoutKit/Views/ReloadableViewLayoutAdapter.swift
94.73% <100%> (+2.1%)
:white_check_mark:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 43b864d...03c2ea0. Read the comment docs.


New io

Adding prototype for NEW IO to main branch.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

141 of 187 (75.4%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.8%) to 61.055%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pynapple/io/misc.py
13
14
92.86%

pynapple/io/file.py
48
58
82.76%

pynapple/io/folder.py
79
114
69.3%

Totals

Change from base Build<PHONE_NUMBER>:
0.8%

Covered Lines:
1800

Relevant Lines:
2861

💛  - Coveralls


maven-metadata.xml file outdated

What happened?
Hi!
I am using reposilite as a mirror of my jfrog artifactory maven repo for performance reasons.
So I configured it as a mirror repo and I am caching the artifacts.
Every now and then the maven-metadata.xml file does not get updated. Let say of my artifact mygroup:foo I got version 1.2.3-4 in the repo and then I push the artifactory 1.2.3-5.
I can see in the UI the 1.2.3-5 artifact, but the maven-metadata.xml is not listing that version. The maven-metadata.xml in artifactory has the correct version. I know that artifactory is sometimes a bit slow to propagate changes, but the problem even happens after hours.
When I delete from reposilite the maven-metadata.xml and run on my project mvn -U versions:use-latest-versions reposilite grabs the correct file.
How does the maven-metadata.xml file gets updated?
Is reposilite checking it for updates each time run  mvn -U versions:use-latest-versions ?
Version I use: 3.1.0
My config:
{
  "frontend": {
    "id": "reposilite-repository",
    "title": "XXX",
    "description": "XXX",
    "organizationWebsite": "XXX",
    "organizationLogo": "XXX",
    "icpLicense": ""
  },
  "authentication": {
    "ldap": {
      "enabled": false,
      "hostname": "ldap.domain.com",
      "port": 389,
      "baseDn": "dc=company,dc=com",
      "searchUserDn": "cn=reposilite,ou=admins,dc=domain,dc=com",
      "searchUserPassword": "reposilite-admin-secret",
      "userAttribute": "cn",
      "userFilter": "(&(objectClass=person)(ou=Maven Users))",
      "userType": "PERSISTENT"
    }
  },
  "statistics": {
    "resolvedRequestsInterval": "MONTHLY"
  },
  "web": {
    "forwardedIp": "X-Forwarded-For"
  },
  "maven": {
    "repositories": [
      {
        "id": "releases",
        "visibility": "PUBLIC",
        "redeployment": false,
        "preserveSnapshots": false,
        "storageProvider": {
          "type": "fs",
          "quota": "90%",
          "mount": ""
        },
        "proxied": [
          {
            "reference": "https://repo1.maven.org/maven2/",
            "store": true,
            "allowedGroups": [],
            "connectTimeout": 3,
            "readTimeout": 15,
            "httpProxy": ""
          },
          {
            "reference": "https://jfrog url",
            "store": true,
            "allowedGroups": [],
            "connectTimeout": 3,
            "readTimeout": 15,
            "authorization": {
              "password": "XXX",
              "login": "XXX"
            },
            "httpProxy": ""
          }
        ]
      }
    ]
  }
}

Reposilite version
3.x
Relevant log output
No response

The intention behind caching is to provide a possibility to go fully offline/independent from mirrored repo at some point, so we're storing all files - even the metadata files. That's the main purpose of this feature, but it also has some drawbacks like the one you've just noticed.
I see the issue tho. It could be covered by some new option added to the caching policy that'd state that we need to prioritize metadata files over local content.

The intention behind caching is to provide a possibility to go fully offline/independent from mirrored repo at some point, so we're storing all files - even the metadata files. That's the main purpose of this feature, but it also has some drawbacks like the one you've just noticed.
I see the issue tho. It could be covered by some new option added to the caching policy that'd state that we need to prioritize metadata files over local content.

I had a bit of a deeper look at the calls maven does. I was hoping it sets the Cache-Control header a bit smart, but it always sets it to no-cache and in newer maven versions even to no-cache, no-store, no matter what file is being requested.  I was hoping to get no-cache, no-store only for the maven-metadata.xml.
Maybe something like this:
{
"pattern" : "**/maven-metadata.xml",
"cacheMode" : "check_upstream_ignore_failure"
}
So basically if a file matches, a call to upstream with the http header If-Modified-Since is being made. If upstream is not available, gracefully read the file from the local cache.
Other cache modes:

default, current behaviour
check_upstream - if upstream is not reachable, fail the request - no need to implement it at the moment imho

It'll be available in the next release:

Thank you soooo much!

I had a look at the changes.
I was also playing around locally a bit, but I only was able to start. I was doing a GET request to upstream with a If-Modified-Since header. I simply use the last-modifed timestamp from the local file. So I would still do a request, but I would only grab the file if it has changed.
I am curious if you thought about that approach?

I think it'd complicate the impl, and it doesn't really provide any extra value for users. In the end, you still need to make a request to an external source, so it'll take as much time as a request that just downloads the metadata file again.


Client generation for Action with optional bool parameter

Imagine this sample action:
public async Task<IActionResult> Get([FromQuery]string order = null, [FromQuery]bool IsOrder = true)
The generated client method looks like this (with generateOptionalParameters):
public async Task<Object> GetAsync(string order = null, bool? IsOrder)
{
    if (isOrder == null)
        throw new ArgumentNullException("IsOrder");

        ...
}

This looks weird to me. Why is the generated parameter not like the one from the action? Is this a limitation of reflection?
This way I have to specify a value for an otherwise optional parameter. And as a consumer I dont even know what the default value for the bool is here, if I dont bother.

Actually bool IsOrder = true is an optional parameter (if it is not provided/set then it is true). This is why the swagger spec specifies it as optional and thus the parameter is nullable in the generated client...

Yes thats exactly the point. Its an optional parameter and I would expect it to be nullable and not throw exceptions. But it actually is not nullable, because the generator also adds the null check at the beginning of the method which throws ArgumentNull.
The expected behavior is that GetAsync() without params just works.
The actual behavior is that GetAsync() throws ArgumentNullException for an optional parameter and you have to do GetAsync(isOrder = false/true). And then you have the problem that you dont know which one is the expected default.
The reason for the null check is the following that is generated below in the client:
urlBuilder_.Append("isOrder=").Append(System.Uri.EscapeDataString(System.Convert.ToString(isOrder.Value, System.Globalization.CultureInfo.InvariantCulture)));
isOrder.Value will throw NullReference if you actually null the bool?. The generator would have to null check isOrder and set true or false if it is null. It can only do that reliably if the generator actually know the default.
My solution would be to only append isOrder=%Value% if isOrder != null. Or even better the generated client should mirror the action and have bool isOrder = true as a parameter instead of bool? isOrder.

Yes, this seems wrong...

What do you think?
https://github.com/RSuter/NSwag/commit/202c1b8dd1acc63ca945508fb7d27868838f9c17

Looks good to me. Tested it with the ci build (https://ci.appveyor.com/project/rsuter/nswag-25x6o/build/2795/artifacts).


TypeError: Cannot read properties of undefined (reading 'open')

I'm stuck on using react-native-sqlite-storage, whenever I start initially open a new database as was mentioned in the documentation usage, I get this error:
TypeError: Cannot read properties of undefined (reading 'open').
this is my code so far.
import React, {useEffect} from 'react';
import {View, Text} from 'react-native';
import SQLite from 'react-native-sqlite-storage';
const App = () => {
try {
SQLite.openDatabase({name: 'UserDatabase', location: 'default'});
} catch (error) {
console.log(error);
}
return (
<View style={{flex: 1, justifyContent: 'center', alignItems: 'center'}}>
SQLite Database Example

);
};
export default App;
any solutions for this ?

Please write code as:
```js
<Your code here>
```
This will post it in a code block with javascript syntax highlighting and make it much easier to read
Additionally, when making react native issues, please provide which device type you're experiencing the issue on. I'm guessing Windows, and if so, have you found my pull request which fixes this?
Additionally, this repo is dead, and I think I might be the only person still answering questions here.

Do you know about any alternatives @MacKenzieHnC for sqlite and react native?


web_resources cleanup

/sandbox/code/github/threefoldtech/jumpscaleX_core/JumpscaleCore/servers/openresty/web_resources

All of the templates should be in the correct package if not already
All of the assets should be in the correct package if not already
All of moon files should be removed

PR
https://github.com/threefoldtech/jumpscaleX_core/pull/249

To verify:

start Wiki package and make sure that everything works as its default behavior.
start Chat package and make sure that everything works as its default behavior.

Verified
Both are working as per default behaviour.


val_loss

I have a new question. In my training results, the value of val_loss is very unstable, but the result of train_loss is good. What is the reason for this?
val_loss
0.121626744
0.064643869
1.067177767
1.446711094
1.281244414
0.085074004
0.033228467
0.07067455
0.057629818
0.058747965
1.917625544
0.041074573
0.15646584
1.15546266
1.469133962
0.040493928
1.874986998
1.004034303
0.048311408
0.100535154
1.64835466
0.054501295
0.055335191
0.10456412
0.276266118
0.068388779
0.715268846
0.098956134
2.583597354
0.538678182
1.748115192
0.060186028
1.108167116
0.309113808
0.101157197
0.124394018
0.066762745
0.055764281
0.460467963
2.378881313
0.066589679
0.471164338
0.078409711
0.065184287
0.086847927
0.101323177
0.069627192
1.949108887
0.56550861
1.750528685
1.873376575
1.489622217
0.994260068
0.066217561
0.065698464
0.072816557
0.073953711
0.071316366
0.421468448
0.85330223
0.076412463
1.056728009
0.092980409
0.074839294
0.63967285
1.866399809
1.322311701
0.07251732
0.076650151
0.075991224
0.592627899
0.178139341
0.874911083
0.086961034
2.873830932
0.082318357
0.086678351
0.09311628
0.110618592
0.797192226
0.08203448
0.144572049
0.083447114
0.103286757
0.089605071
0.136912736
0.149895869
0.079707029
0.091769812
0.987303428
0.093305247
0.089239203
1.865140941
1.418952992
0.174026518
0.094368358
0.095077354
0.629811309
0.090620203
1.349854706
train_loss
0.230814192
0.028987918
0.024291774
0.017069094
0.014445363
0.013398573
0.017434838
0.010788895
0.010943851
0.010186778
0.008584953
0.01008794
0.008166692
0.00812426
0.007191894
0.006891105
0.007163724
0.006250243
0.007437692
0.005759141
0.005480012
0.007539251
0.005302504
0.005195955
0.005868624
0.004928016
0.004689556
0.00476825
0.004551805
0.004410871
0.004312812
0.005318373
0.003946777
0.00389254
0.004088193
0.004916692
0.003619704
0.003698593
0.003596091
0.003551835
0.003599238
0.003506489
0.003349912
0.004076907
0.003196912
0.003090051
0.003097881
0.003223821
0.003074504
0.003073007
0.002930183
0.002931052
0.002878063
0.002818113
0.004682063
0.002902587
0.00261943
0.002597745
0.002628764
0.002631262
0.003391225
0.002469422
0.002454039
0.002499085
0.002512494
0.00248172
0.002464812
0.002398441
0.002394155
0.002346173
0.002301199
0.002282861
0.002268845
0.002215712
0.002189308
0.002250406
0.002511505
0.002021703
0.00206177
0.002084404
0.002078039
0.00203906
0.002020018
0.001995647
0.001981924
0.001943689
0.001929661
0.001958759
0.001993959
0.001822729
0.001834546
0.001916094
0.001810232
0.001773823
0.001764436
0.001750559
0.001739222
0.002303985
0.001640475
0.001577288

Unfortunately, I cannot tell you the exact reason for this because I don't have enough information, but seems like your model is overfitting. Do you use the same augmentation during validation as you use during training?

Question to cosmic-cortex
Dear cosmic-cortex,
First of all, many thanks for sharing this implementation of the u-net. It seems to be a great deal of work.
Similarly to<PHONE_NUMBER>1, I am also having problems with overtraining. The network seems no to generalize well.
I downloaded the "Kaggle Data Science Bowl 2018 nuclei detection challenge dataset". I used your program kaggle_dsb18_preprocessing.py" to prepare the images and the masks.  From the 670 files of the data set, I used 450 images (with their respective masks) to train the network and 220 images for the validation test. Please note that I did not separate the fluorescence, brightfield, and histopathological images. I used them all together for the training.
For the network I used a depth=6 and a width=32 and ran it for 100 epochs. I think I am using augmentation, as I left these two lines:
tf_train = JointTransform2D(crop=crop, p_flip=0.5, color_jitter_params=None, long_mask=True)
tf_val = JointTransform2D(crop=crop, p_flip=0.5, color_jitter_params=None, long_mask=True)

Do you have any suggestions/comments on what to do?
Many thanks in advance.

@alejandrodelac
Hi! I am going to be honest, the last time I trained a U-Net on this dataset was about three years ago, so I don't exactly remember what steps I took to make it generalize well.
If I remember correctly, these were the augmentation steps I used:

splitting up the images into 512 x 512 patches in advance
randomly cropping 256 x 256 patches
color_jitter_params=(0.1, 0.1, 0.1, 0.1)

Unfortunately, I don't remember the number of epochs at all. However, I used a learning rate scheduler and reduced the LR when the validation loss was plateauing.
Hope that helps!


Check JIRA APIs for Integration

Research on the feasibility of integrating jira for use cases defined.

JIRA INTEGRATION API
https://developer.atlassian.com/jiradev/jira-apis/jira-rest-apis/jira-rest-api-tutorials/jira-rest-api-example-create-issue

https://docs.atlassian.com/jira/REST/cloud/


⚠ Bofrost.es has degraded performance

In 2d8f07e, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1730 ms

Resolved: Bofrost.es performance has improved in 10e4a0f after 19 minutes.


Added Liatrio flavicon to dashboard

Added a Liatrio flavicon to the ldop dashboard.

flavicon??
lgtm

Updated name of favicon and matched new image name in index.html


Slimux breaks when g:slimux_tmux_path is unset

See https://github.com/epeli/slimux/commit/55a01a2f87dbec6db18f5199cdf5493aba5dca59#commitcomment-19102917 for details. An extraneous newline causes commands to be split up as follows:
/usr/bin/tmux
 -V

instead of
/usr/bin/tmux -V

and the former causes shell errors.

I'd be happy to file a PR later if you prefer.

@mganjoo thanks for the report, system() call to find vim has a newline, I'm stripping it in the commit above. Can you verify that it solves the issue on your end so we can close?

Seems to be working now; thanks!


Update how-to-manage-user-profile-info.yml

The following should be clearly stated for brevity:
"For users whose source of authority is Windows Server Active Directory, you must use Windows Server Active Directory to update their identity, contact info, or job info. After you complete your update, you must wait for the next synchronization cycle to complete before you'll see the changes. However, you are able to update their attributes directly in Entra ID so long as you are updating one of Entra ID attributes such as UsageLocation."

@shlipsey3
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

Hey @azarboon thanks for this suggestion! I like your revisions, but I'm double-checking on that new line you've proposed. Stay tuned!

@shlipsey3  thank you for suggestion. I just confirmed it. Kindly please sign off this PR.

@shlipsey3  just my 2 cents: could it be because you put UsageLocation in the quotation mark?

We use those ticks all the time - it must be something with the yml. Can you remove those and see if it builds?

#please-close

#please-open

@azarboon I'm going to try and do this on my end. This article was converted from markdown to YML recently as an experiment and I can't tell what's up. Stay tuned...

@azarboon Let's change it to just "Usage location" to match the UI. If you make that change it should go through. I'm afraid if I try to suggest another change GitHub will get grumpy again.
If that doesn't work, let me know how you want to proceed. I can do it on my end, but you won't get the contribution. Sorry the formatting broke it!

@shlipsey3 - the yml syntax is fixed so validation isn't broken. let us know how you'd like to proceed on this. thanks

@shlipsey3  I changed it to "Usage Location". Kindly please sign off.
Thanks for your concern to make sure that I get the credit; I appreciate it.

It wasn't reflecting that change right away - may have been a caching thing on my end. That's why I spun up a new one just in case. Glad it's resolved - thanks for your patience all!
#sign-off


Option to configure allowPrivilegeEscalation: false

Is your feature request related to a problem? Please describe.
For security reasons, we must be able to configure
allowPrivilegeEscalation: false
for container as securityContext .
https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
Describe the solution you'd like
Description how this can be configured in the operator.

@hektor1966 Thanks for the suggestion! Do you see any reason for making this configurable, or do you think this should be the default for all pods?

Thinking about it, I tend towards adding a securityContext and podSecurityContext to the components and the default config, so people can add whatever they deem appropriate in their situation. It would then be possible to say
defaults:
  podSecurityContext:
    allowPrivilegeEscalation: false
    readOnlyRootFilesystem: true
  securityContext:
    fsGroup: 1000
    runAsGroup: 1000
    runAsUser: 1000

or even set that for individual components.

Yeah, it should be configurable. It is unlikely, but there may be situations where it is necessary. Default should be False


publishing provider via api not working 404

Bug description 🐞
Hi @alfespa17 and thank you for the detailed documentation you added to publish a private provider https://github.com/AzBuilder/docs/blob/main/user-guide/private-registry/using-providers.md
I've tried it today but I'm getting a 404 error, not sure from where comes this error
user@MacBook-Pro-de-Test terrakube-helm-chart % curl -XPOST https://terrakube-api.awnen.com/organizations/140206a1-b498-4a04-840c-ed1e3c8cdf37/provider -H "Content-Type: application/vnd.api+json" -H "Authorization: Bearer xxxxxxx" -d '{
    "data": {
        "type": "provider",
        "attributes": {
          "name": "random",
          "description": "random provider"
        }
    }
}'
{"timestamp":"2024-08-30T14:23:30.391+00:00","status":404,"error":"Not Found","path":"/organizations/140206a1-b498-4a04-840c-ed1e3c8cdf37/provider"}

Steps to reproduce
Go to user settings -> create an api token and generate API TOKEN to call the api
Create an organization
Create provider inside organization
curl -XPOST https://terrakube-api.awnen.com/organizations/<PASTE ORGANISATION ID HERE>/provider -H "Content-Type: application/vnd.api+json" -H "Authorization: Bearer  <PASTE GENERATED API TOKEN>" -d '{
    "data": {
        "type": "provider",
        "attributes": {
          "name": "random",
          "description": "random provider"
        }
    }
}'

Expected behavior
return code status code 200 or 201maybe?
Example repository
No response
Anything else?
I tried to check in the @RestController classes in the api project to find the provider endpoint but couldn't find it? maybe it was moved somewhere else? or removed completely?

Hello @khaounen the correct path is
https://terrakube-api.awnen.com/api/v1/organizations/140206a1-b498-4a04-840c-ed1e3c8cdf37/provider

By the way you didnt find any RestController because for some part of the code we are using elide so we only define the database entity and the framework takes care of generating all the CRUD endpoints

Thank you again for your quick reply I'm getting "Unknow Collection Organization" in the response now,
Is this because of the organization ID I copied from the URL?
This is the the URL to access my org https://terrakube-ui.awnen.com/organizations/140206a1-b498-4a04-840c-ed1e3c8cdf37/workspaces
So I used 140206a1-b498-4a04-840c-ed1e3c8cdf37 as organization ID, isn't this correct?
curl -XPOST https://terrakube-api.awnen.com/api/v1/organizations/140206a1-b498-4a04-840c-ed1e3c8cdf37/provider -H "Content-Type: application/vnd.api+json" -H "Authorization: Bearer xxxxxx" -d '{
    "data": {
        "type": "provider",
        "attributes": {
          "name": "random",
          "description": "random provider"
        }
    }
}'
{"errors":[{"detail":"Unknown collection organizations"}]}

It is organization not organizations in the path

Oh my bad! its fixed but looks like the user I'm connecting with (member of TERRAKUBE_ADMIN) doesn't have the right to create the provider in the organization
{"errors":[{"detail":"CreatePermission Denied"}]}

Maybe another group needed for this?

TERRAKUBE_ADMIN

The TERRAKUBE_ADMIN group can only manage teams and create organization inside Terrakube,
If you want to use that team to manage workspace, providers, modules, etc you will have to add that team to the teams organization setting.
You can follow this:
https://docs.terrakube.io/user-guide/organizations/team-management

Ok great! thank you again, I'm closing my ticket as there is no bug from the api side, its more from the post I was doing, thank you again, I'll check the doc and give it a try later


Add an R Project style .exe

I like Rstudio's  Projects feature, but really only use one part of it. I like having a little .RProj file in a directory that I can click on. In R, this opens up Rstudio and sets the working directory to that folder. It also opens up any text files you had open last time.
It also loads the old workspace, though the Rstudio team has rightly suggested users turn off that option.
In reality, a .RProj file is just a yaml file, so this can't be too difficult to code up.
Anyways, this is just a feature I appreciate in RStudio that would be nice to have on your radar going forward.
Thanks

I'm betraying my ignorance here, clearly.
You are probably right. It's just a yaml file that RStudio tells the computer to associate with the RStudio application. Then it reads the yaml and sets everything up as needed.

If I understand you correctly you want something very similar to Atom's Projects, except for the fact that they're stored in your project dir instead of in some centralized place?

I believe so.
I've been thinking more about this, and it's clear that RStudio is using this tool to try and ease users into using R rather than excel. The .RProj is a tangible thing to click on the way an excel spreadsheet is, making the switch to scripting less daunting. Julia might not be trying to solve that problem, though.

If we leave apart the workspace-restoration feature (which is sometimes critized because it doesn't help reproducibility), this sounds like a feature which should be implemented purely in Atom, without Juno being involved at all?

It could probably be done as a new Atom package, which we could bundle with Julia if people like it.
This might also be related to having Juno-related config; I've frequently wanted to be able to say "use julia 0.6, use -O0" etc on a per-project basis, and that config could go in an executable-style file in principle.


Livereload doesnt reload the browser #62 (Duplicate)

I am duplicating this issue as there was no solution flagged: https://github.com/AveVlad/gulp-connect/issues/62
I am having an issue with the browser not reloading, the change is being picked-up and I can see it in the terminal - it just won't update the browser.
I am using the sample code for 'LiveReload': https://www.npmjs.org/package/gulp-connect#livereload

I had a similar issue. If' you're using HTTPS, you need to permanently trust the (unsigned) certificate that gulp-connect uses. Or you can use HTTP.
Hope this helps,
Alvin

in my case it sometimes stop working, windows restart helps


Integration tests

Not entirely sure that we need a full integration suite along with everything else.  If we start stumbling across bugs that might have been caught by it, then we'll reconsider.


Companion conversations + Leadership

Same exact issue as the vanilla storygate conversations. If you have the Leadership perk, the two new ones with Shattered Space will never play.

Details
xx084782 and xx12CCD2. The "WantsToTalk" actor value checks must be changed from ==1 to >=1.
Game Version
<IP_ADDRESS>
Language
English (EN)
New Game
Yes
Reproduction Steps
Bring Andreja to Dazra, or completed the Shattered Space quests and talk to companions.

Fix attached... sigh.
SFCP-SS_1180.zip

@Deebz96 Wait is that zip an early version of a community patch for Shattered Space? I wasn’t aware one was being made yet.

It’s only a fix for this bug. A separate shattered space plugin may come later.

@Deebz96 On, Thanks for the heads up.

Is there a way to get this attached fix on xbox, or will it eventually make its way there? Sorry, just an eager player who took the leadership perk like the night before shattered space launched without being aware of this issue, and ive already put in over a dozen hours since then before realizing this was an issue. Now I am waiting for a fix before beginning shattered space :(

Fix appears to work mid-game with Andreja in Dazra. Not checked in Shattered Space or with other companions.

I’d like to echo the request for making this Shattered Space dialogue patch available on Xbox.   Is this possible?   Or, if you plan an overall Shattered Space patch with this in it, be happy to wait.   Thoughts?
P.S. - Many thanks to the SFCP team for your great work!

Fixed officially.


Add explainshell integration

This adds a VS Code setting bash.explainshellEndpoint which is forwarded to the language server as an environment variable EXPLAINSHELL_ENDPOINT (when "" the feature is disabled, and once https://github.com/idank/explainshell/pull/125 is merged in, you'll be able to set this to "https://explainshell.com"). When enabled, HTTP requests will be sent to explainshell upon hover to show documentation for flags.
How to run this unfortunately my internet went down, so I can't push my Docker image for explainshell that makes this really easy. Instead, you have to check out my branch at https://github.com/sourcegraph/lsp-adapter/pull/84 and run:
docker build -t bash-explainshell -f dockerfiles/bash/Dockerfile .

Then wait ~30 minutes (it has to load 26 thousand man pages into mongo 😯). Then run it:
docker run --rm --name bash-explainshell -p 5000:5000 bash-explainshell

Then set this in your VS Code config:
    "bash.explainshellEndpoint": "http://localhost:5000",

Then launch the version of the extension on this branch through VS Code and you should see docs on hover like in the GIF above.
Resolves #42

Any idea why yarn run test errors out and says TypeError: document.getText is not a function? yarn run compile works fine, and there's no type error in VS Code.

@chrismwendt This is amazing 🎉 I have a very busy day today but I'll try to squeeze in a review - but this a awesome 👏

Yes, CI is ✅ @mads-hartmann Anything else?

@chrismwendt Merged! 😊 I'll cut a release today. Thanks a lot for the contribution

Sweet, the new language server is running on Sourcegraph.com now https://sourcegraph.com/github.com/creationix/nvm/-/blob/install.sh#L67:12

And you can get this functionality on GitHub (or any supported code host) with the Chrome extension (or other browsers) https://github.com/creationix/nvm/blob/HEAD/install.sh#L60


PlatformException (Unable to get uislider) under iOS 15

We use your great plugin and it seems to work under iOS 15. We've tested another plugins for setting / getting volumes too, but nothing work for iOS 15. Finally, a link in this issue helped us to find PerfectVolumeControl: https://github.com/yangming1009/volume_watcher/issues/14.
But there is still one bug if we set hideUI to true:
PerfectVolumeControl.hideUI = true;

In this case, if we try to set a volume, e.g. as
await PerfectVolumeControl.setVolume(1.0);

we get a PlatformException "Unable to get uislider":

If we set
PerfectVolumeControl.hideUI = false;

no exception is thrown. But we would like to hide the UI control.
Tested unter iOS 15. Looking forward for a fix. Thanks in advance!

If we look this code

it seems to be no subview with volume slider is available after hiding (removing).

Thank you for your proposal. There seems to be a problem with the code here. I will fix it as soon as possible and then release a new version. Thank you again.

@JiangJuHong  Any update on this?

Sorry, I just saw this comment. There is no further progress on this problem at present, and it may be solved within one month (work reason)

@JiangJuHong Any update on this?

Sorry, I just saw this comment. There is no further progress on this problem at present, and it may be solved within one month (work reason)

这个问题有进展吗？


How to view files that are in a docker container or image

In windows I can see WSL folders under Linux as \wsl.localhost\docker-desktop\ and \wsl.localhost\docker-desktop-data. I installed a few apps that run fine in docker but I want to view the files that run in background, for example "hello-world". How can I view the file that runs this. I want to see/inspect the code. And would it be possible to modify it?

Please keep in mind that the GitHub issue tracker is not intended as a general support forum,
but for reporting bugs and feature requests. For other type of questions, consider using one of;

the Discussione on the Moby repository
the Docker community Slack channel
the docker tags on StackOverflow
the Docker Support Forums - https://forums.docker.com

I'm closing this ticket because this is not a bug, but feel free to continue the conversation


[3.0] ui: don't show failed alert for repeated orchestration

A failed alert is shown whenever one of the nodes fails to bootstrap.
This is an optimization to only show this alert once for a specific
orchestration run. If the user closes the alert, it won't come back
unless a new orchestration happens.
bsc#1097752
Signed-off-by: Vítor Avelino<EMAIL_ADDRESS>(cherry picked from commit e943e073e813cdea58bf0943e1caba226cb60131)
Backoprt of https://github.com/kubic-project/velum/pull/589

How much would break if the column type was changed?

As far as I can tell MariaDB should not be mapping timezones at all. We control how we run MariaDB and we should not be setting any timezone in it. On top of that, ActiveRecord should be using UTC for all our usages (because we are not mapping them either), so I don't see a timezone shift in any part of the stack (we can ask for the customer timezone in the future and show events on the views to their local time, but that's up on the stack, MariaDB and ActiveRecord should be storing everything in plain UTC).
By default Rails creates created_at and updated_at as datetime instead of timestamp. I think it would be good if we could continue using Rails' defaults.

Not adding the awaiting-merge label until @dannysauer confirms that everything is fine regarding their objections.


[VS Code] Joining collaboration session: connect ENOENT /var/folders/kj/h3pj3_752zj62y7p1wh24zg00000gn/T/CoreFxPipe_48732610a87d461e80a7fb2f80897d4f

Error:
Joining collaboration session: connect ENOENT /var/folders/kj/h3pj3_752zj62y7p1wh24zg00000gn/T/CoreFxPipe_48732610a87d461e80a7fb2f80897d4f
Steps to Reproduce:

Version Data

extensionName
VSLS

extensionVersion
0.3.1013

protocolVersion
2.2

applicationName
VSCode

applicationVersion
1.29.1

platformName
MacOS

platformVersion
17.7.0

Hey @kyakumoto-ts, thanks for reporting. Could you attach logs for investigations? In VSCode you can open command palette and type Live Share: Export Logs, it will give you logs zip file. Thanks!


Update build comments

Pull Request Test Coverage Report for Build 112118

0 of 0   changed or added relevant lines in 0 files are covered.
9 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.1%) to 82.244%

Files with Coverage Reduction
New Missed Lines
%

libraries/botframework-streaming/src/webSocket/webSocketTransport.ts
2
80.65%

libraries/botframework-streaming/src/webSocket/webSocketServer.ts
7
66.67%

Totals

Change from base Build 111862:
-0.1%

Covered Lines:
9298

Relevant Lines:
10890

💛  - Coveralls


pythonPackages.oauthlib: 0.7.2 -> 2.0.0

Motivation for this change
Related to #19935. Split up commits because nox-review shows building problem with hypothesis and PyLTI. So, I've had to update this as well. Also, I've changed PyLTI to avoid duplication problem:
Found duplicated packages in closure for dependency 'pytest':
  pytest 2.9.2 (/nix/store/r2v8mbdn63q3jdh3339ghplza9fmi850-python2.7-pytest-2.9.2/lib/python2.7/site-packages)
  pytest 2.7.3 (/nix/store/pkaymk1w76xb6zf5l0cc8r3kbz24nrhw-python2.7-pytest-2.7.3/lib/python2.7/site-packages)

Things done

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

[x] NixOS
[ ] macOS
[ ] Linux

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

The changes require rebuilding of:
lrwxrwxrwx 1 igor users 68 Nov  6 16:17 result -> /nix/store/rn4sznvz095alfxy3gqp0dmwasfaapgn-python2.7-oauthlib-2.0.0
lrwxrwxrwx 1 igor users 77 Nov  6 16:17 result-10 -> /nix/store/8mkgbphq31pfipy48l486b2fjpprcyxj-python2.7-requests-oauthlib-0.4.1
lrwxrwxrwx 1 igor users 66 Nov  6 16:17 result-11 -> /nix/store/4kvcshfqb0r6i28ry25q8lghnz00k4v3-python2.7-turses-0.3.1
lrwxrwxrwx 1 igor users 73 Nov  6 16:17 result-12 -> /nix/store/cqaz9254h78cxm775vmsr0zky43ff9ij-python2.7-bitbucket-api-0.4.4
lrwxrwxrwx 1 igor users 66 Nov  6 16:17 result-2 -> /nix/store/8pj53xq59b48wv49sagbb9yl4fvajgzs-python3.5-tweepy-3.5.0
lrwxrwxrwx 1 igor users 68 Nov  6 16:17 result-3 -> /nix/store/2hbqdb6kd7ij470dikr1bl5fgb0z5zz3-python3.5-oauthlib-2.0.0
lrwxrwxrwx 1 igor users 66 Nov  6 16:17 result-4 -> /nix/store/9z0x9x6vn97w95213y95imh0dmxfan8z-python2.7-tweepy-3.5.0
lrwxrwxrwx 1 igor users 64 Nov  6 16:17 result-5 -> /nix/store/d5faxav5xqdm91wjn6g6a6fsbcjkqmf1-inginious-0.3a2.dev0
lrwxrwxrwx 1 igor users 65 Nov  6 16:17 result-6 -> /nix/store/j3bi2h2yjzbjrkxvy0cafg9y45mk5ssv-python2.7-PyLTI-0.4.1
lrwxrwxrwx 1 igor users 70 Nov  6 16:17 result-7 -> /nix/store/mz6qd30p725bbmb5001sgmll6nc350pz-python2.7-mezzanine-3.1.10
lrwxrwxrwx 1 igor users 77 Nov  6 16:17 result-8 -> /nix/store/z3dfnn78lm9dzzix8ir0h02bdn584if6-python3.5-requests-oauthlib-0.4.1
lrwxrwxrwx 1 igor users 58 Nov  6 16:17 result-9 -> /nix/store/z6rcmgpqh6vca3bpxsw19j8jhpdysyyl-keystone-8.0.0

Fixed with e39584c67d24f38c1b050a599d162eb3e764a9bf and d22432880b83367a6e7b901427e48f1b70551727


build!: upgrade ruflin/elastica to v8

BREAKING CHANGE:  JoliCode\Elastically\Transport\HttpClientTransport has been removed,
Closes https://github.com/jolicode/elastically/issues/186

I have green tests locally great job, I'm looking more deeply very soon, hand tight :pray:

Thank you so much @GaryPEGEOT for your help on this :pray: :+1:


Basic Node Telemetry

So Counterparty nodes don't talk to each other directly. This means that there's currently no way of knowing even the most basic telemetry for who's running what version, etc. which is important for managing things like upgrades and hotfixes. Bitcoin itself handles this through its peer-to-peer network.[1] Obviously all of this data is 100% anonymous and there'll be a flag to disable it entirely. Will be shared on a public dashboard.

Version / DB Version
Uptime
Platform (inc. Docker vs. simplenode vs fednode)
Network (mainnet/testnet/etc.)
Last block parsed
--force enabled
Block, ledger and message hashes

Could you clarify what is meant by:

--force enabled

Sorry, what I meant was that nodes should report if they're running with the --force CLI flag enabled (which would indicate that certain safety checks are being bypassed, etc.)

Understood

@adamkrellenstein just to be clear, are you cool with a handler at /telemetry from which a future dashboard can pull?  Or do you want it to push data to some telemetry backend at regular intervals?

I think we need to set up the push.

I think we'll also want to expose all of this info at some REST endpoint, however, and merge it with the get_running_info we have now:
adam@tang ~ > http POST https://rpc:rpc@api0.counterparty.io:4000/api/ jsonrpc="2.0" id=1 method="get_running_info"
HTTP/1.1 200 OK
Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
Content-Length: 890
access-control-allow-headers: DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization
access-control-allow-methods: GET, POST, OPTIONS
access-control-allow-origin: *
content-type: application/json
date: Wed, 03 Apr 2024 19:41:07 GMT
server: Werkzeug/3.0.1 Python/3.10.12
via: 1.1 google

{
    "id": "1",
    "jsonrpc": "2.0",
    "result": {
        "api_limit_rows": 1000,
        "bitcoin_block_count": 837583,
        "db_caught_up": true,
        "indexd_blocks_behind": 0,
        "indexd_caught_up": true,
        "last_block": {
            "block_hash": "00000000000000000002940a1691b138b690f23a86d8f32decdca46dd62e76c1",
            "block_index": 837583,
            "block_time":<PHONE_NUMBER>,
            "difficulty":<PHONE_NUMBER>0024.61,
            "ledger_hash": "e3f9cd46f2b2944903800d7257a92842497d3cf0a28a156fe2ca302cf15c928f",
            "messages_hash": "8bfd8a1d33fb3909498575e4721672c314215b5d0a85d1041c88c593e7841d94",
            "previous_block_hash": "00000000000000000002a0f8fffb94bf8e48816190cf99bfa1f7c97b8b690eaa",
            "txlist_hash": "2295a65d8e5f0efc10095e1f9e611fd3e9c627bce0216c61f8f5d89ae7d15040"
        },
        "last_message_index": 13611493,
        "running_regtest": false,
        "running_testcoin": false,
        "running_testnet": false,
        "server_ready": true,
        "version_major": 10,
        "version_minor": 0,
        "version_revision": 0
    }
}

And we should also expose this info for Sentry.

Okay, here is data I am collecting:
 {
      "version": "10.1.0",
      "addrindex_version": "0.4.6",
      "uptime": "472.56",
      "is_docker_process": false,
      "network": "MAINNET",
      "force_enabled": false,
      "last_block": {
        "block_index": 839529,
        "block_hash": "0000000000000000000330586ef1577def4246f5900bd8b6bc01ce562172b258",
        "block_time":<PHONE_NUMBER>,
        "previous_block_hash": "000000000000000000034158a91c1876f5fc2add1e69641e908956ac9de45b93",
        "difficulty":<PHONE_NUMBER>5171.02,
        "ledger_hash": "23ccfaa264719b760f4950d0ec7c07641129f4d43a979eeaa8fdd7950be336a9",
        "txlist_hash": "557213d08a66c89d84475387deca135bd164075b6e663741a917ca36f78630b6",
        "messages_hash": "fb8f1f4225a9aba71375d4c402d88bddf8390672735819d735847892995abe93"
      }
    }

In terms of merging with get_running_info, a lot of the fields are duplicative even if they are encoded slightly differently ( e.g. network="MAINNET" vs is_testnet=false, or encoding version as "version_major", "version_minor", "version-revision" vs just a single string.
Here is one possible shape that is non-breaking:

{
    "server_ready": true,
    "db_caught_up": true,
    "bitcoin_block_count": 839529,
    "last_block": {
      "block_index": 839529,
      "block_hash": "0000000000000000000330586ef1577def4246f5900bd8b6bc01ce562172b258",
      "block_time":<PHONE_NUMBER>,
      "previous_block_hash": "000000000000000000034158a91c1876f5fc2add1e69641e908956ac9de45b93",
      "difficulty":<PHONE_NUMBER>5171.02,
      "ledger_hash": "23ccfaa264719b760f4950d0ec7c07641129f4d43a979eeaa8fdd7950be336a9",
      "txlist_hash": "557213d08a66c89d84475387deca135bd164075b6e663741a917ca36f78630b6",
      "messages_hash": "fb8f1f4225a9aba71375d4c402d88bddf8390672735819d735847892995abe93"
    },
    "indexd_caught_up": true,
    "indexd_blocks_behind": 0,
    "last_message_index": 13650823,
    "api_limit_rows": 1000,
    "running_testnet": false,
    "running_regtest": false,
    "running_testcoin": false,
    "version_major": 10,
    "version_minor": 1,
    "version_revision": 0,
    # new fields
    "addrindexrs_version_major": 10,
    "addrindexrs_version_minor": 1,
    "addrindexrs_version_revision": 0,
    "uptime": "472.56",
    "is_docker_process": false,
     "force_enabled": false,
}

I think we should just take the opportunity to deprecate get_running_info as part of the API Redesign and keep it how it is but put it behind /api/v1/

thoughts @ouziel-slama ? anything we're missing?

yeah I agree! Apart from the bug fix I would say that we freeze the RPC API and focus on the v2 API.
Could we add mempool-enabled and checkdb-enabled?
I will add api-v1-enabled in the newapi branch!

I think let's leave out checkdb-enabled, since it's really just a startup thing.

Some of this was included in v10.1.1... how much? @mattmarcello

All it does is collect the telemetry attributes at a set interval and log them to local storage.  If you have sentry enabled it will also send some of those attributes to sentry when there is an exception ( e.g adressindexrs version )


Enable customization of number of rows for FuzzySelect

Hi!
In this PR, I've made a small but useful extension to FuzzySelect that enables the user to decide how many options will be displayed at one time, rather than the default of the terminal height minus 2.
Example code:
FuzzySelect::with_theme(&ColorfulTheme::default())
                .with_prompt("What is your guess?")
                .with_visible_term_rows(5_usize)
                .items(word_slice)
                .report(true)
                .default(0)
                .interact()?;

Here's an example of how it looks with visible_term_rows = 5:

I'm still somewhat new to Rust, let me know if there's any code style that can be improved.

@pksunkara I've addressed your feedback, mind giving this another glance?

Updated according to your feedback @pksunkara .


Splitting lines in string

The feature splitting lines in IntelliJ and the other text editors from JetBrains would be nice to have.
The feature is to split a string into two lines by pressing the return key.
https://www.jetbrains.com/idea/help/splitting-lines-with-string-literals.html

This is a good candidate for an extension, there might be one already.


OTC Framework bootstrapping agreement, 2024-08-21

OTC Framework bootstrapping agreement

Hi Frank,
Thank you for your interest in donating the OTC Framework to the Commonhaus Foundation. We appreciate your support and willingness to put this PR together.
As we are in a bootstrapping phase (about 12 months), and are focused on more established projects for now. Please consider re-applying once this phase is complete.
We hope you will continue to participate as a foundation member over the coming months. This foundation needs members as much as it needs projects to be successful.
Thank you for your understanding. We hope to see you around.


Fetcher stuck in "loading" state when using Await with Promise.all

What version of Remix are you using?
1.19.3
Are all your remix dependencies & dev-dependencies using the same version?

[X] Yes

Steps to Reproduce
Here's a reproduction on CodeSandbox: https://codesandbox.io/p/sandbox/remix-await-fetcher-bug-xg58yq?file=/app/routes/test-defer.tsx

Use <Await> with Promise.all to await multiple promises from deferred loader(s).
Submit a form with useFetcher.

import { defer } from "@remix-run/node";
import { Await, useFetcher, useLoaderData } from "@remix-run/react";
import { Suspense, useMemo } from "react";

function wait(timeMs: number) {
  return new Promise<void>((resolve) => setTimeout(resolve, timeMs));
}

export async function loader() {
  return defer({
    instant: "hi",
    deferred1: wait(1000).then(() => ({ foo: "bar" })),
    deferred2: wait(2000).then(() => ({ baz: "quux" })),
  });
}

export async function action() {
  await wait(1000);
  return null;
}

export default function TestDeferPage() {
  const data = useLoaderData<typeof loader>();
  const fetcher = useFetcher();

  const { deferred1, deferred2 } = data;
  const promises = useMemo(
    () => Promise.all([deferred1, deferred2]),
    [deferred1, deferred2]
  );

  return (

Instant data: {data.instant}

      <Suspense fallback="loading...">
        <Await resolve={promises}>
          {([data1, data2]) => (

foo: {data1.foo}

baz: {data2.baz}

          )}
        </Await>
      </Suspense>

Fetcher state: {fetcher.state}

      <fetcher.Form method="post">
        <button type="submit">submit</button>
      </fetcher.Form>

  );
}

Expected Behavior
The fetcher should go through the normal submitting/loading states, then eventually return to idle.
Actual Behavior

The fetcher gets stuck in the "loading" state.
The browser tab starts using lots of CPU.

Hm, I'm not sure what's going on here.  It's getting into a loop on a new Promise.all creation each render. However, deferred1/deferred2 should be stable across re-renders so the useMemo should work as expected and stabilize the  Promise.all.
This seems to check out as well if compare them across re-renders, but the useMemo still runs even though they are the same instance, and this produces a new Promise.all causing the loop.
if (typeof window !== "undefined") {
  if (window.promises == null) { window.promises = []; }
  if (window.count == null) { window.count = 0; }
  if (window.promises?.length > 1) {
    console.log(
      "calling useMemo, deps equal?",
      deferred1 === window.promises[window.promises.length - 1][0],
      deferred2 === window.promises[window.promises.length - 1][1]
    );
  }
}

const promises = useMemo(() => {
  console.log("inside useMemo - creating new promise via Promise.all()");
  if (typeof window !== "undefined") {
    window.promises.push([deferred1, deferred2]);
    if (window.count++ > 50) { throw new Error("Max iterations reached"); }
  }
  return Promise.all([deferred1, deferred2]);
}, [deferred1, deferred2]);

Output:

I'll dig into this a bit deeper, but in the meantime I would either move the Promise.all into the loader if you want them to display together, or you can avoid the Promise.all and put both Await's inside the same Suspense to achieve the same UI.
<Suspense fallback="loading...">
  <Await resolve={deferred1}>{(data1) =>
foo: {data1.foo}
}</Await>
  <Await resolve={deferred2}>{(data2) =>
baz: {data2.baz}
}</Await>
</Suspense>

@brophdawg11 thanks for looking into this!
We usually do use Promise.all only in loaders, when possible. In this case, we have three promises for deferred data in multiple loaders in nested routes, and a few of our pages need to combine this data to render a view.
I forgot to mention an important detail: I just encountered this bug when updating from Remix 1.16.1 to 1.19.3. Everything worked fine in 1.16.1.

@jmezzacappa  When I upgraded to remix1.19.3, I also encountered the same problem. Finally, I used Suspense for nesting.

@brophdawg11 this is still happening in v2.3.1

By removing Promise.all() it resolved my issue. I've just replaced resolve={Promise.all([promise1, promise2])} with resolve={[promise1, promise2]}
NOTE: I'm using remix 2.5.0

By removing Promise.all() it resolved my issue. I've just replaced resolve={Promise.all([promise1, promise2])} with resolve={[promise1, promise2]} and adding await within the defer() function
export const loader = async ({ params }: LoaderFunctionArgs) => {
  return defer({
    template: await templates(),
    items: await templateItems(),
    teams: await teams(),
  });
};

export default function TemplateDetail() {
  const { template, items, teams } = useLoaderData<typeof loader>()
  return (
    <>
      <Suspense fallback={'loading...'}>
        <Await resolve={[items, teams]}>
          <TemplateItemsList />
        </Await>
      </Suspense>
    </>
  );
}

NOTE: I'm using remix 2.5.0

🤔 If I'm understanding the code correctly, that loader won't send a response until after all of those promises are resolved, right? In that case, there's not really any need for defer, Suspense, or Await, as a simple json() response would perform similarly.
Unfortunately, that wouldn't be a viable workaround in our case.

As a temporary workaround, I threw this component together. Feels like the types could be simplified a bit, but I didn't bother refactoring once I got it working, as it's just a (hopefully) temporary solution.
import { Await } from '@remix-run/react'
import { type ComponentProps } from 'react'

type AwaitProps = Omit<ComponentProps<typeof Await>, 'children' | 'resolve'>

type AwaitAllRecursiveProps<TResolved, TPending, TAllValues> = {
	awaitProps: AwaitProps
	children: React.ReactNode | ((resolvedValues: TAllValues) => React.ReactNode)
	pendingValues: TPending
	resolvedValues: TResolved
}

type AllValues<
	TResolved extends readonly unknown[] | [],
	TPending extends readonly unknown[] | [],
> = [...TResolved, ...{ [K in keyof TPending]: Awaited<TPending[K]> }]

function AwaitAllRecursive<
	TResolved extends readonly unknown[] | [],
	TPending extends readonly unknown[] | [],
	TAllValues extends TResolved | readonly unknown[] | [] = AllValues<
		TResolved,
		TPending
	>,
>({
	awaitProps,
	children,
	pendingValues,
	resolvedValues,
}: AwaitAllRecursiveProps<TResolved, TPending, TAllValues>): JSX.Element {
	if (pendingValues.length === 0) {
		return (
			<>
				{typeof children === 'function'
					? children(resolvedValues as TAllValues)
					: children}
			</>
		)
	}

	const [pendingHead, ...pendingTail] = pendingValues

	return (
		<Await {...awaitProps} resolve={pendingHead}>
			{value => (
				<AwaitAllRecursive
					awaitProps={awaitProps}
					pendingValues={pendingTail}
					resolvedValues={[...resolvedValues, value]}
				>
					{children}
				</AwaitAllRecursive>
			)}
		</Await>
	)
}

type AwaitAllProps<T extends readonly unknown[] | []> = Omit<
	ComponentProps<typeof Await>,
	'resolve' | 'children'
> & {
	resolve: T
	children:
		| React.ReactNode
		| ((resolvedValues: {
				-readonly [K in keyof T]: Awaited<T[K]>
		  }) => React.ReactNode)
}

/**
 * Wrapper around Remix's {@link Await} component to handle multiple promises.
 *
 * This was created because the `Await` component tends to introduce strange
 * [bugs] when used with `Promise.all`, and the bugs vary depending on the Remix
 * version. For example, after upgrading from Remix 1.16.1 to 1.19.3, fetchers
 * would get stuck in the "loading" state when an `Await` component is used
 * somewhere else on the page with `Promise.all`.
 *
 * This component has the same API as Remix's `<Await>`, except the `resolve`
 * prop is an array of promises (similar to `Promise.all`).
 *
 * [bugs]: https://github.com/remix-run/remix/issues/7392
 *
 * @example
 *
 * // This component appears to work fine, but `useFetcher` gets buggy in
 * // other components.
 * function BadComponent() {
 *   const { deferred1, deferred2, deferred3 } = useLoaderData()
 *
 *   const allPromises = useMemo(
 *     () => Promise.all([deferred1, deferred2, deferred3]),
 *     [deferred1, deferred2, deferred3],
 *   )
 *
 *   return (
 *     <React.Suspense>
 *       <Await resolve={allPromises}>
 *         {([data1, data2, data3]) => (
 *
This breaks fetchers.

 *         )}
 *       </Await>
 *     </React.Suspense>
 *   )
 * }
 *
 * // To work around the issue reliably, `<Await>` can be nested.
 * function UglyComponent() {
 *   const { deferred1, deferred2, deferred3 } = useLoaderData()
 *   return (
 *     <React.Suspense>
 *       <Await resolve={deferred1}>
 *         {data1 => (
 *           <Await resolve={deferred2}>
 *             {data2 => (
 *               <Await resolve={deferred3}>
 *                 {data3 => (
 *
This is a very verbose workaround.

 *                 )}
 *               </Await>
 *             )}
 *           </Await>
 *         )}
 *       </Await>
 *     </React.Suspense>
 *   )
 * }
 *
 * // `<AwaitAll>` renders the nested `<Await>`s for us.
 * function NoNestedAwait() {
 *   const { deferred1, deferred2, deferred3 } = useLoaderData()
 *   return (
 *     <React.Suspense>
 *       <AwaitAll resolve={[deferred1, deferred2, deferred3]}>
 *         {([data1, data2, data3]) => (
 *
This does not break fetchers.

 *         )}
 *       </AwaitAll>
 *     </React.Suspense>
 *   )
 * }
 */
export default function AwaitAll<T extends readonly unknown[] | []>({
	resolve: pendingValues,
	children,
	...awaitProps
}: AwaitAllProps<T>): JSX.Element {
	return (
		<AwaitAllRecursive
			pendingValues={pendingValues}
			resolvedValues={[]}
			awaitProps={awaitProps}
		>
			{children}
		</AwaitAllRecursive>
	)
}

I'm going to close this out because it appears to just be how React 18 Suspense works and is resolved with the use hook in React 19.  Await will be updated to leverage use when React 19 is released.