Wrong detection of upload finish on 32bit PHP

Hi!
On 32bit PHP the maximum of an integer is<PHONE_NUMBER>.
In ContentRangeUploadHandler class on lines 93,94,95 intval() is used so bytesStart, bytesEnd and bytesTotal max value is<PHONE_NUMBER>. So after about 2GB the script thinks that the upload is finished.

Hi @Nerg4l , nice catch! I didn't realize this use case. After reading, the float value should handle bigger size. Do you agree? I can push the change today.

Just tested the code with floatval() and it works for me as expected. The problem with float is that it is platform-dependant and floatval() returns INF (infinite) constant when it gets a number which is bigger than the maximum.
So the script should throw an exception if floatval() returns INF.

@Nerg4l thank you for tests and direction, I've implemented the changes + added tests and works as expected. Updated to 1.0.4 version.

Sorry to be a downer... but there may be more tests needed to handle different php platforms. Specifically with floating point precision with "/" and "*" operators. If you're shifting to floats, i recommend switching to BCMath for the division/multiplication operations and upping the precision ini value in php.

Hi @ashbeats, not sure if follow correctly, but the uploader will send only int value. Float value should not be sent. We are using float only to overcome the 32 bit restriction. The values are float but without decimal points. Also getPercentageDone will always ceil the value.
I've added also OS X to travis to check the test calculations with int values.
I think it's not necessary to add BCMath as required dependency.
Best regards


Filtering bug in runs overview

To reproduce -- go to https://app.wandb.ai/yaroslavvb/nccl_bench?workspace=user-yaroslavvb and try to add Filter by name. The result is empty no matter what you put for filter value

Yep, definitely a bug in our backend filtering logic.  I'm tracking this internally for a fix.

Seems to be fixed


Add History::delete for FileBackedHistory

Add History::delete for FileBackedHistory
Adapt history to print id rather than just consecutive numbers
Add history delete <id> to demo

See also https://github.com/nushell/nushell/pull/11629

Trying this out. It looks like delete-item may be 1 off?
D:\reedline〉history
... others not listed
46      ls
47      ls -r
48      hello another very large option for hello word that will force one column
49      history
D:\reedline〉history delete-item 48                                                               01/31/2024 07:52:21 AM
D:\reedline〉history                                                                              01/31/2024 07:52:27 AM
... others not listed
45      ls
46      ls -r
47      hello another very large option for hello word that will force one column
48      history delete-item 48
49      history

Trying this out. It looks like delete-item may be 1 off? or some other entry was deleted. I'm noticing now that they're not the same numbers anymore.

Ids are not preserved with the file-based history.
If that is of importance, some kind of tombstone system would have to be established.

Right, i understand that the ids are not preserved but if it's counting from 1 to 50 they should always be the same numbers unless something was deleted from within right?

Right, i understand that the ids are not preserved but if it's counting from 1 to 50 they should always be the same numbers unless something was deleted from within right?

Yes, looking at your example again, it looks indeed like a one-off error.
Sigh, as they say:

There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.

diffing the two history outputs, when I said history delete-item 48 it looks like it deleted item 0.

@fdncred I had another look (with a different machine on a different OS) and it still just works for me...
First, I run cargo run --example demo
〉history
0       history
1       history
2       history delete-item 1
3       history delete-item 3
4       history
〉history delete-item 0
〉history
0       history
1       history delete-item 1
2       history delete-item 3
3       history
4       history delete-item 0
5       history

I can't seem to manage to get it into the broken state you had

Also, that just works:
〉history
0       history
1       history delete-item 1
2       history delete-item 3
3       history
4       history delete-item 0
5       history
6       history delete-item 2
7       history
8       history delete-item 2
9       history
〉history delete-item 2
〉history
0       history
1       history delete-item 1
2       history
3       history delete-item 0
4       history
5       history delete-item 2
6       history
7       history delete-item 2
8       history
9       history delete-item 2
10      history

Could you maybe try one more time? And double check that you run the correct command and have the correct branch checked out?

Sure, no worries.
history
0           let-env current_page = 0
1           alias pp = (let cmds = (help commands | range ($env.current_page - 10)..($env.current_page)); let-env current_page = ($env.current_page - 10); echo $cmds)
2           alias hh = (let cmds = (help commands | range ($env.current_page)..($env.current_page + 10));  echo $cmds)
3           alias nn = (let cmds = (help commands | range $env.current_page..($env.current_page + 10)); let-env current_page = ($env.current_page + 10); echo $cmds)
4       exit
5       pwd
...
44      history
45      ls
46      ls -r
47      hello another very large option for hello word that will force one column
48      history delete-item 48
49      history

i want to delete 47 which is that long one
D:\reedline〉history delete-item 47
D:\reedline〉history
0           alias pp = (let cmds = (help commands | range ($env.current_page - 10)..($env.current_page)); let-env current_page = ($env.current_page - 10); echo $cmds)
1           alias hh = (let cmds = (help commands | range ($env.current_page)..($env.current_page + 10));  echo $cmds)
2           alias nn = (let cmds = (help commands | range $env.current_page..($env.current_page + 10)); let-env current_page = ($env.current_page + 10); echo $cmds)
3       exit
4       pwd
5       exit
...
44      ls
45      ls -r
46      hello another very large option for hello word that will force one column
47      history
48      history delete-item 47
49      history

Notice that 47 is now 46 and 0 is different.
I'm testing on Windows. I wonder if that makes a difference due to line endings or something like that?

I just tested on WSL Ubuntu and it works there. Must be a Windows thing?

That worked. Here's my guess. My history is old so I had items in history with leading spaces. Leading spaces aren't permitted anymore. So, maybe we should trim the history items somewhere to prevent this from happening.

That worked. Here's my guess. My history is old so I had items in history with leading spaces. Leading spaces aren't permitted anymore. So, maybe we should trim the history items somewhere to prevent this from happening.

Good to hear that this fixed it. Would be good to have a reproducer though to make sure that this is indeed the reason.

I'm not really sure what it is. I can reproduce it every time with that history file I attached above.

That worked. Here's my guess. My history is old so I had items in history with leading spaces. Leading spaces aren't permitted anymore. So, maybe we should trim the history items somewhere to prevent this from happening.

Your guess is correct. I was able to reproduce the behavior with your history file and can confirm that the leading whitespace is to blame.
I also found another bug in my implementation, will convert this to a draft for now.

It should be fine now.
Here's what I changed:

rename history delete-item to history remove-item since that's how it will be called on the nushell side https://github.com/nushell/nushell/pull/11629
add option to overwrite the complete file (needed for the next two points)
trim entries with leading whitespace and trigger overwrite
overwrite when history items have been removed

I tested this PR this morning with this history.txt and couldn't get it to work. It just deleted item 0 off the history.
history.txt

I tested this PR this morning with this history.txt and couldn't get it to work. It just deleted item 0 off the history. history.txt

I just checked, and the problem is that your history file is at capacity (50).
That means that when you run history it gets appended to your history backend and the first entry is pruned, which changes the ids of all entries.
When you then try to delete an entry it deletes a different entry than you intended.
At this point, I see only these ways forward:

Refactoring the file based history backend altogether (just to be clear, I am not signing up for that :P)
Add logic, so that the history command will not be added to history (a bit hacky but would be fine by me)
Close this PR, but still merge https://github.com/nushell/nushell/pull/11629 even though only sqlite is supported (also fine by me)
Close both this PR and https://github.com/nushell/nushell/pull/11629 (my least favorite option)

That means that when you run history it gets appended to your history backend and the first entry is pruned, which changes the ids of all entries.
When you then try to delete an entry it deletes a different entry than you intended.

Seems like it's good that we caught this but bad because it means more changes are due.
I'm not really a fan of any option but the first one. Seems like this is close to being what we need but not quite. Sorry I found so many problems. It's not my intent to have continual criticisms of your PR. :(

That means that when you run history it gets appended to your history backend and the first entry is pruned, which changes the ids of all entries.
When you then try to delete an entry it deletes a different entry than you intended.

Seems like it's good that we caught this but bad because it means more changes are due.

I very much appreciate that you found these bugs.
For nushell this would have been much less obvious to debug.

I'm not really a fan of any option but the first one. Seems like this is close to being what we need but not quite.

I don't think it's super close. We would have to introduce the concept of explicit indexes. But just thinking about all the edge cases makes not want to go further into this direction. Especially since I don't care too much about the file backed history, and would much rather have nushell switch completely to sqlite :D

for what it's worth, i'd rather have nushell just be sqlite. i just think there would be outrage if that happened.

for what it's worth, i'd rather have nushell just be sqlite. i just think there would be outrage if that happened.

Just for context, I meant changing the default to sqlite, not removing the file-based backend (at least for now :P)
And accepting that not every feature, like deleting a specific entry, is also supported by the file-based backend

Anyway, my suggestion would be to merge https://github.com/nushell/nushell/pull/11629 and leave this PR open for now.
I assume https://github.com/nushell/reedline/pull/747 changes things too, and I'd hate if both PRs would bit-rot.
Agreed @fdncred?


style: fix eslint rule lines-between-class-members

Description of changes

fix eslint rule lines-between-class-members
CDK / CloudFormation Parameters Changed

N/A
Issue #, if available

N/A
Description of how you validated changes
N/A
Checklist

[x] PR description included
[x] yarn test passes

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

Merging #1681 (bce6864) into main (41219c3) will not change coverage.
The diff coverage is n/a.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@           Coverage Diff           @@
##             main    #1681   +/-   ##
=======================================
  Coverage   63.80%   63.80%
=======================================
  Files         370      370
  Lines       21772    21772
  Branches     5212     5212
=======================================
  Hits        13891    13891
  Misses       7159     7159
  Partials      722      722

Impacted Files
Coverage Δ

...ql-transformer/amplify-cli-feature-flag-adapter.ts
90.00% <ø> (ø)

...y-category-api/src/graphql-transformer/override.ts
98.27% <ø> (ø)

...ation/api-input-manager/appsync-api-input-state.ts
77.77% <ø> (ø)

...vider-utils/awscloudformation/apigw-input-state.ts
88.00% <ø> (ø)

...provider-utils/awscloudformation/base-api-stack.ts
87.35% <ø> (ø)

...formation/cdk-stack-builder/apigw-stack-builder.ts
63.00% <ø> (ø)

...rmation/cdk-stack-builder/apigw-stack-transform.ts
11.36% <ø> (ø)

...dformation/docker-compose/ecs-objects/container.ts
79.31% <ø> (ø)

...r-utils/awscloudformation/pipeline-with-awaiter.ts
83.33% <ø> (ø)

...-graphql-auth-transformer/src/accesscontrol/acm.ts
93.93% <ø> (ø)

... and 49 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Rolling back to 1.9 from 1.10 causes injector outage

Bug description
Hi,
We attempted to upgrade (in place control plane upgrade) from 1.9 to 1.10 today, but it failed due to https://github.com/istio/istio/issues/33115#issuecomment-856578303.
We rolled back the control plane to 1.9 which has broken sidecar injection, the error we get is:
Error: Internal error occurred: failed calling webhook "sidecar-injector.istio.io": Post https://istiod.istio-system.svc:443/inject?timeout=30s: x509: certificate signed by unknown authority

Upon inspection the clientConfig.caBundle is missing from the MutatingWebhookConfiguration
Decided to delete the istiod deplyoment as well as the MutatingWebhookConfiguration, once redeployed that caBundle is still not present.
In the istiod logs we're seeing:
{"level":"error","time":"2021-06-08T09:57:51.784697Z","scope":"ads","msg":"Failed to authenticate client from <IP_ADDRESS>:43184: Authenticator ClientCertAuthenticator: no verified chain is found; Authenticator KubeJWTAuthenticator: failed to validate the JWT from cluster \"Kubernetes\": the service account authentication returns an error: [invalid bearer token, Token has been invalidated]"}

We attempted to delete the service account secret istiod-service-account-token-ld8tz, and restart the deployment, no errors in the istiod logs now but still no caBundle.
Interestingly the ValidatingWebhookConfiguration has a caBundle, so we manually copied that onto the MutatingWebhookConfiguration and injection started working again.  I'm guessing this indicates there's some logic that's only checking one of these resources for caBundle, not both...
[ ] Docs
[x] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[x] User Experience
[x] Developer Infrastructure
[ ] Upgrade
Expected behavior
To be able to roll back the control plane.
Steps to reproduce the bug
1.9 -> 1.10 -> 1.9
Version (include the output of istioctl version --remote and kubectl version --short and helm version --short if you used Helm)
How was Istio installed?
Environment where the bug was observed (cloud vendor, OS, etc)
Additionally, please consider running istioctl bug-report and attach the generated cluster-state tarball to this issue.
Refer cluster state archive for more details.

Using the latest release-1.9, upgrading to 1.10.0, and downgrading back to 1.9, I find that the CA bundle is patched in as expected (on local kind setup).
The webhook patcher should patch all mutating webhooks with istio.io/rev=default. Could you possibly dump the full MutatingWebhookConfiguration here? And also check istiod logs for New webhook config added, patching MutatingWebhookConfiguration (should be seeing these near startup time)?

Morning folks!
I think there are two separate things going on here:

Some how, the caBundle got removed from the MutatingWebhookConfiguration (not sure how/why, still trying to replicate)
It wasn't added back

#2 is easy to replicate for me, both on 1.9.5 and 1.10.0.  Simply edit the MutatingWebhookConfiguration, remove caBundle, and restart istiod.  There is nothing in the logs at all relating to the mutating webhook, on the validating webhook, and the resource never gets patched.
The complete resource as you've requested @Monkeyanator currently looks like this:
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  creationTimestamp: "2021-06-08T10:08:24Z"
  generation: 3
  labels:
    app: istio
    ark: istio
    chart: istio-1.9.5
    heritage: Tiller
    release: istio
  managedFields:
  - apiVersion: admissionregistration.k8s.io/v1beta1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:labels:
          .: {}
          f:app: {}
          f:ark: {}
          f:chart: {}
          f:heritage: {}
          f:release: {}
      f:webhooks:
        .: {}
        k:{"name":"sidecar-injector.istio.io"}:
          .: {}
          f:admissionReviewVersions: {}
          f:clientConfig:
            .: {}
            f:service:
              .: {}
              f:name: {}
              f:namespace: {}
              f:path: {}
              f:port: {}
          f:failurePolicy: {}
          f:matchPolicy: {}
          f:name: {}
          f:namespaceSelector:
            .: {}
            f:matchExpressions: {}
          f:objectSelector: {}
          f:reinvocationPolicy: {}
          f:rules: {}
          f:sideEffects: {}
          f:timeoutSeconds: {}
    manager: Go-http-client
    operation: Update
    time: "2021-06-08T10:08:24Z"
  name: istio-sidecar-injector
  resourceVersion: "481206079"
  selfLink: /apis/admissionregistration.k8s.io/v1/mutatingwebhookconfigurations/istio-sidecar-injector
  uid: 0ef28f22-f241-4db7-ac87-eba350e078ed
webhooks:
- admissionReviewVersions:
  - v1beta1
  - v1
  clientConfig:
    service:
      name: istiod
      namespace: istio-system
      path: /inject
      port: 443
  failurePolicy: Fail
  matchPolicy: Exact
  name: sidecar-injector.istio.io
  namespaceSelector:
    matchExpressions:
    - key: name
      operator: NotIn
      values:
      - istio-system
    - key: istio-injection
      operator: NotIn
      values:
      - disabled
    - key: istio-env
      operator: DoesNotExist
    - key: istio.io/rev
      operator: DoesNotExist
  objectSelector: {}
  reinvocationPolicy: Never
  rules:
  - apiGroups:
    - ""
    apiVersions:
    - v1
    operations:
    - CREATE
    resources:
    - pods
    scope: '*'
  sideEffects: None
  timeoutSeconds: 30

So one thing you pointed out which was the istio.io/rev label, this is not present on our Webhook.  Remember that our cluster is long lived and has been upgraded since before revision labels existed, and also isn't deployed in the "standard" way... adding that revision label to the resource and the caBundle gets added again.
I'm guessing #1 is a symptom of the same thing (missing revision labels)


update fork

Could you please provide more details as to what changes you made. And please also try to rebase. There's a lot of commits here that have already been merged, it'd make it much easier to review.


svt-av1: 1.8.0 -> 1.9.0-rc1

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for svt-av1 is: AV1-compliant encoder/decoder library core
meta.homepage for svt-av1 is: https://gitlab.com/AOMediaCodec/SVT-AV1
meta.changelog for svt-av1 is: https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/v1.9.0-rc1/CHANGELOG.md
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.9.0-rc1 in filename of file in /nix/store/h63fda1znx7xzdhj50wizzc1g9x8j8j1-svt-av1-1.9.0-rc1

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

8223 total rebuild path(s)

8223 package rebuild(s)

First fifty rebuilds by attrpath
CHOWTapeModel
ChowKick
CuboCore.corepdf
CuboCore.coretoppings
EmptyEpsilon
Fabric
MIDIVisualizer
MMA
SDL2
SDL2_Pango
SDL2_gfx
SDL2_image
SDL2_image_2_0
SDL2_image_2_6
SDL2_mixer
SDL2_mixer_2_0
SDL2_net
SDL2_sound
SDL2_ttf
SDL_audiolib
SDL_compat
SDL_gpu
Sylk
_1oom
_20kly
_7kaa
_86Box
_90secondportraits
aaxtomp3
abbaye-des-morts
abracadabra
abuse
acltoolkit
acquire
activitywatch
ad-miner
adafruit-ampy
adapta-gtk-theme
adenum
adl
adriconf
aegisub
ahoviewer
aiodnsbrute
aitrack
ajour
akkoma
alass
alephone
alerta-server

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/h63fda1znx7xzdhj50wizzc1g9x8j8j1-svt-av1-1.9.0-rc1 \
  --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 svt-av1 https://github.com/r-ryantm/nixpkgs/archive/8d582589864682c32a493ae7e2579f27c2bf232d.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/8d582589864682c32a493ae7e2579f27c2bf232d#svt-av1

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/h63fda1znx7xzdhj50wizzc1g9x8j8j1-svt-av1-1.9.0-rc1
ls -la /nix/store/h63fda1znx7xzdhj50wizzc1g9x8j8j1-svt-av1-1.9.0-rc1/bin

Pre-merge build results
NixPkgs review skipped

Maintainer pings
cc @Madouura for testing.

This is an RC.
@ryantm, can the bot be taught to ignore those somehow?


Enhancement/docs clarification

Hey @renatobo!
First - I'd like to send massive thanks for such an awesome piece of work.
I'm joining the club with esp32 and BN220 setup.
In my case, some docs enhancements, which I'm proposing in my pull request, would help me a lot, while I was building my setup, so I thought that you may find them useful.
Thanks

Thanks for your contribution!
Pls give me a few days to review, I read a couple of things and I'd like to add even more instructions since we are touching it.
The U-Center and GPS configuration part is indeed one of the most annoying and complicated one: I have been entertaining the idea of configuring everything from this code directly w/out requiring U-Center at all.
Ciao
Renato

Thank you for patiently waiting and for the improved documentation.


coreutils-full: fix cross build

Motivation for this change
Fix cross build broken in https://github.com/NixOS/nixpkgs/pull/45720

@GrahamcOfBorg build pkgsCross.scaleway-c1.coreutils-full

@GrahamcOfBorg build pkgsCross.armv7l-hf-multiplatform.coreutils-full

Success on x86_64-linux (full log)
Attempted: pkgsCross.scaleway-c1.coreutils-full
Partial log (click to expand)
gzipping man pages under /nix/store/9ify27lkr9wamqlmrl548hm36afnbamr-coreutils-8.30-armv7l-unknown-linux-gnueabihf/share/man/
armv7l-unknown-linux-gnueabihf-strip is /nix/store/4rvcfng3ficml932m928w9mbfqhvn54z-armv7l-unknown-linux-gnueabihf-binutils-2.30/bin/armv7l-unknown-linux-gnueabihf-strip
stripping (with command armv7l-unknown-linux-gnueabihf-strip and flags -S) in /nix/store/9ify27lkr9wamqlmrl548hm36afnbamr-coreutils-8.30-armv7l-unknown-linux-gnueabihf/libexec  /nix/store/9ify27lkr9wamqlmrl548hm36afnbamr-coreutils-8.30-armv7l-unknown-linux-gnueabihf/bin
patching script interpreter paths in /nix/store/9ify27lkr9wamqlmrl548hm36afnbamr-coreutils-8.30-armv7l-unknown-linux-gnueabihf
checking for references to /build in /nix/store/9ify27lkr9wamqlmrl548hm36afnbamr-coreutils-8.30-armv7l-unknown-linux-gnueabihf...
shrinking RPATHs of ELF executables and libraries in /nix/store/kcidrkc17zm451ikyy47z5jm7lbm5bwb-coreutils-8.30-armv7l-unknown-linux-gnueabihf-info
armv7l-unknown-linux-gnueabihf-strip is /nix/store/4rvcfng3ficml932m928w9mbfqhvn54z-armv7l-unknown-linux-gnueabihf-binutils-2.30/bin/armv7l-unknown-linux-gnueabihf-strip
patching script interpreter paths in /nix/store/kcidrkc17zm451ikyy47z5jm7lbm5bwb-coreutils-8.30-armv7l-unknown-linux-gnueabihf-info
checking for references to /build in /nix/store/kcidrkc17zm451ikyy47z5jm7lbm5bwb-coreutils-8.30-armv7l-unknown-linux-gnueabihf-info...
/nix/store/9ify27lkr9wamqlmrl548hm36afnbamr-coreutils-8.30-armv7l-unknown-linux-gnueabihf

Success on x86_64-linux (full log)
Attempted: coreutils-full
Partial log (click to expand)
/nix/store/fs05bvnpxrq034hpy4y4f4ibcagciw7i-coreutils-8.30

Success on aarch64-linux (full log)
Attempted: pkgsCross.scaleway-c1.coreutils-full
Partial log (click to expand)
gzipping man pages under /nix/store/9l2w3mbwnbb93d7n4r93gxv9mg4dpz4f-coreutils-8.30-armv7l-unknown-linux-gnueabihf/share/man/
armv7l-unknown-linux-gnueabihf-strip is /nix/store/y4z5gyj70ik4bhimjvsqdvszrr28f18j-armv7l-unknown-linux-gnueabihf-binutils-2.30/bin/armv7l-unknown-linux-gnueabihf-strip
stripping (with command armv7l-unknown-linux-gnueabihf-strip and flags -S) in /nix/store/9l2w3mbwnbb93d7n4r93gxv9mg4dpz4f-coreutils-8.30-armv7l-unknown-linux-gnueabihf/libexec  /nix/store/9l2w3mbwnbb93d7n4r93gxv9mg4dpz4f-coreutils-8.30-armv7l-unknown-linux-gnueabihf/bin
patching script interpreter paths in /nix/store/9l2w3mbwnbb93d7n4r93gxv9mg4dpz4f-coreutils-8.30-armv7l-unknown-linux-gnueabihf
checking for references to /build in /nix/store/9l2w3mbwnbb93d7n4r93gxv9mg4dpz4f-coreutils-8.30-armv7l-unknown-linux-gnueabihf...
shrinking RPATHs of ELF executables and libraries in /nix/store/kib3ahkb51y0an3gyz3qnqv1yylki4gf-coreutils-8.30-armv7l-unknown-linux-gnueabihf-info
armv7l-unknown-linux-gnueabihf-strip is /nix/store/y4z5gyj70ik4bhimjvsqdvszrr28f18j-armv7l-unknown-linux-gnueabihf-binutils-2.30/bin/armv7l-unknown-linux-gnueabihf-strip
patching script interpreter paths in /nix/store/kib3ahkb51y0an3gyz3qnqv1yylki4gf-coreutils-8.30-armv7l-unknown-linux-gnueabihf-info
checking for references to /build in /nix/store/kib3ahkb51y0an3gyz3qnqv1yylki4gf-coreutils-8.30-armv7l-unknown-linux-gnueabihf-info...
/nix/store/9l2w3mbwnbb93d7n4r93gxv9mg4dpz4f-coreutils-8.30-armv7l-unknown-linux-gnueabihf

Success on aarch64-linux (full log)
Attempted: pkgsCross.armv7l-hf-multiplatform.coreutils-full
Partial log (click to expand)
gzipping man pages under /nix/store/nx7r7s6c392h9zwfk7kib1f9fp3c5lbv-coreutils-8.30-armv7l-unknown-linux-gnueabihf/share/man/
armv7l-unknown-linux-gnueabihf-strip is /nix/store/y4z5gyj70ik4bhimjvsqdvszrr28f18j-armv7l-unknown-linux-gnueabihf-binutils-2.30/bin/armv7l-unknown-linux-gnueabihf-strip
stripping (with command armv7l-unknown-linux-gnueabihf-strip and flags -S) in /nix/store/nx7r7s6c392h9zwfk7kib1f9fp3c5lbv-coreutils-8.30-armv7l-unknown-linux-gnueabihf/libexec  /nix/store/nx7r7s6c392h9zwfk7kib1f9fp3c5lbv-coreutils-8.30-armv7l-unknown-linux-gnueabihf/bin
patching script interpreter paths in /nix/store/nx7r7s6c392h9zwfk7kib1f9fp3c5lbv-coreutils-8.30-armv7l-unknown-linux-gnueabihf
checking for references to /build in /nix/store/nx7r7s6c392h9zwfk7kib1f9fp3c5lbv-coreutils-8.30-armv7l-unknown-linux-gnueabihf...
shrinking RPATHs of ELF executables and libraries in /nix/store/33v9i3lg3lqrbk4944cr32aichgpz5zi-coreutils-8.30-armv7l-unknown-linux-gnueabihf-info
armv7l-unknown-linux-gnueabihf-strip is /nix/store/y4z5gyj70ik4bhimjvsqdvszrr28f18j-armv7l-unknown-linux-gnueabihf-binutils-2.30/bin/armv7l-unknown-linux-gnueabihf-strip
patching script interpreter paths in /nix/store/33v9i3lg3lqrbk4944cr32aichgpz5zi-coreutils-8.30-armv7l-unknown-linux-gnueabihf-info
checking for references to /build in /nix/store/33v9i3lg3lqrbk4944cr32aichgpz5zi-coreutils-8.30-armv7l-unknown-linux-gnueabihf-info...
/nix/store/nx7r7s6c392h9zwfk7kib1f9fp3c5lbv-coreutils-8.30-armv7l-unknown-linux-gnueabihf

Success on aarch64-linux (full log)
Attempted: coreutils-full
Partial log (click to expand)
these paths will be fetched (2.63 MiB download, 13.18 MiB unpacked):
  /nix/store/ccqjc4p4v0x1ipszrpcwr6dlihlmg0kc-openssl-1.0.2p
  /nix/store/y3zpxgqx8hdwwak8m1s7h3q87kqx2cbi-coreutils-8.30
copying path '/nix/store/ccqjc4p4v0x1ipszrpcwr6dlihlmg0kc-openssl-1.0.2p' from 'https://cache.nixos.org'...
copying path '/nix/store/y3zpxgqx8hdwwak8m1s7h3q87kqx2cbi-coreutils-8.30' from 'https://cache.nixos.org'...
/nix/store/y3zpxgqx8hdwwak8m1s7h3q87kqx2cbi-coreutils-8.30

Success on x86_64-linux (full log)
Attempted: coreutils-full
Partial log (click to expand)
/nix/store/fs05bvnpxrq034hpy4y4f4ibcagciw7i-coreutils-8.30

@GrahamcOfBorg build pkgsCross.armv7l-hf-multiplatform.coreutils-full

This needs a backport right?

Success on aarch64-linux (full log)
Attempted: pkgsCross.armv7l-hf-multiplatform.coreutils-full
Partial log (click to expand)
gzipping man pages under /nix/store/nx7r7s6c392h9zwfk7kib1f9fp3c5lbv-coreutils-8.30-armv7l-unknown-linux-gnueabihf/share/man/
armv7l-unknown-linux-gnueabihf-strip is /nix/store/y4z5gyj70ik4bhimjvsqdvszrr28f18j-armv7l-unknown-linux-gnueabihf-binutils-2.30/bin/armv7l-unknown-linux-gnueabihf-strip
stripping (with command armv7l-unknown-linux-gnueabihf-strip and flags -S) in /nix/store/nx7r7s6c392h9zwfk7kib1f9fp3c5lbv-coreutils-8.30-armv7l-unknown-linux-gnueabihf/libexec  /nix/store/nx7r7s6c392h9zwfk7kib1f9fp3c5lbv-coreutils-8.30-armv7l-unknown-linux-gnueabihf/bin
patching script interpreter paths in /nix/store/nx7r7s6c392h9zwfk7kib1f9fp3c5lbv-coreutils-8.30-armv7l-unknown-linux-gnueabihf
checking for references to /build in /nix/store/nx7r7s6c392h9zwfk7kib1f9fp3c5lbv-coreutils-8.30-armv7l-unknown-linux-gnueabihf...
shrinking RPATHs of ELF executables and libraries in /nix/store/33v9i3lg3lqrbk4944cr32aichgpz5zi-coreutils-8.30-armv7l-unknown-linux-gnueabihf-info
armv7l-unknown-linux-gnueabihf-strip is /nix/store/y4z5gyj70ik4bhimjvsqdvszrr28f18j-armv7l-unknown-linux-gnueabihf-binutils-2.30/bin/armv7l-unknown-linux-gnueabihf-strip
patching script interpreter paths in /nix/store/33v9i3lg3lqrbk4944cr32aichgpz5zi-coreutils-8.30-armv7l-unknown-linux-gnueabihf-info
checking for references to /build in /nix/store/33v9i3lg3lqrbk4944cr32aichgpz5zi-coreutils-8.30-armv7l-unknown-linux-gnueabihf-info...
/nix/store/nx7r7s6c392h9zwfk7kib1f9fp3c5lbv-coreutils-8.30-armv7l-unknown-linux-gnueabihf

Maybe.
It is only for cross-compilation whole system closures which is broken on 18.09 in many places (this and cross-compilation systemd because of recent regressions, but some other (perlPackages) have never worked), so it might have no sense to backport this fix alone

Ok. Then maybe once the base is stable, somebody could create a pull request containing all fixes.


Is there a way to do a nested join?

I see you can join to a sub query, but is there a way to do a nested join?
For example, I'd like to create the following SQL
SELECT *
FROM
(
   table1 t1 join table2 t2 on (t1.id = t2.id)
) join table 3 t3 on (t1.id = t3.id)

I'm assuming that using the sub query, I would end up with something like:
SELECT *
FROM
(
  SELECT * FROM table1 t1 join table2 t2 on (t1.id = t2.id)
) join table 3 t3 on (t1.id = t3.id)

I'd much prefer doing it the first way if possible

I had a need to support nested joins on join blocks for a recent project, which is different than the example above. So for example:
SELECT *
FROM table1 t1
LEFT JOIN table2 t2
  INNER JOIN table3 t3 ON t2.id = t3.id
  ON t1.id = t2.id

I was able to create a basic implementation for doing so by extending the prototypes for join blocks to accept a string for a nested join. Is this something you would be interested in seeing a PR for?


Export of model to ONNX

Hello,
first of all thanks for sharing code for your amazing work.
In the paper but also in some issues you mention that the code was exported to ONNX in order to get the presented realtime factors.
Could you share the code which does so?
Thanks

Same as https://github.com/MasayaKawamura/MB-iSTFT-VITS/issues/8


”Groșuri”, ”Plai”, ”Reț”, ”Sălătruc” are listed in the drop-down menu

Description:
When user writes ”Groșuri”, ”Plai”, ”Reț”, ”Sălătruc” the locations appear in the drop-down menu next to the comune and the county witch is a part according to the law.
Precondition:
The website is up an running.

Step 1
Write in the search bar "Groșuri"

Expected results
The location appears in the drop-down menu as "Sat Groșuri, HUNEDOARA (Blăjeni)".

Step 2
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 3
Write in the search bar "Plai"

Expected results
The location appears in the drop-down menu as "Sat Plai, HUNEDOARA (Blăjeni)".

Step 4
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 5
Write in the search bar "Reț"

Expected results
The location appears in the drop-down menu as "Sat Reț, HUNEDOARA (Blăjeni)".

Step 6
Press "x" button.

Expected results
The location was deleted from the search bar.

Step 7
Write in the search bar "Sălătruc"

Expected results
The location appears in the drop-down menu as "Sat Sălătruc, HUNEDOARA (Blăjeni)".


refactor

Description
[Describe what this change achieves]
Issues Resolved
[List any issues this PR will resolve]
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Task :test:external-modules:test-delayed-aggs:publishNebulaPublicationToMavenLocal
Task :test:external-modules:test-delayed-aggs:publishToMavenLocal
Task :checkCompatibility
Compatible components: [https://github.com/opensearch-project/common-utils]

BUILD SUCCESSFUL in 10m 45s

> Task :test:external-modules:test-delayed-aggs:publishNebulaPublicationToMavenLocal
> Task :test:external-modules:test-delayed-aggs:publishToMavenLocal
> Task :checkCompatibility
Compatible components: [https://github.com/opensearch-project/common-utils]

BUILD SUCCESSFUL in 9m 45s


issuse when build  rocksdb

docker run --rm -it -v "$(pwd)":/home/rust/src messense/rust-musl-cross:x86_64-musl cargo build --release
process didn't exit successfully:/home/rust/src/target/release/build/librocksdb-sys-801fddabdbc09a61/build-script-build(exit status: 101)   --- stderr   /usr/include/stdint.h:26:10: fatal error: 'bits/libc-header-start.h' file not found   thread 'main' panicked at 'unable to generate rocksdb bindings: ClangDiagnostic("/usr/include/stdint.h:26:10: fatal error: 'bits/libc-header-start.h' file not found\n")', /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/librocksdb-sys-0.11.0+8.1.1/build.rs:40:10   note: run withRUST_BACKTRACE=1environment variable to display a backtrace warning: build failed, waiting for other jobs to finish...
but it success in
docker run --rm -it -v "$(pwd)":/home/rust/src messense/rust-musl-cross:aarch64-musl cargo build --release

Maybe you can try this: https://github.com/rust-rocksdb/rust-rocksdb/issues/174#issuecomment-409410115
Since the upstream issue isn't closed yet, I'm closing this as not planned and duplicate of #45.


Question more than issue : how check that the dataloader is used ?

Hi,
this is more a question rather than an issue.
I'm trying to check if the dataloader is used when calling the fieldresolver. As far as I see, it seems not, but I'm wondering why...
According to the examples you have provided in your repo, looking at the "Company" entity, there is only one FieldResolver. The others column are not "FieldResolved" because there is a @TypeOrmLoader decorator.
To make it clear, does it mean that a FieldResolver isn't required when the @TypeOrmLoader is set for the field?
This part is not that clear.
Thks
Rgds

To make it clear, does it mean that a FieldResolver isn't required when the @TypeOrmLoader is set for the field

@FieldResolver is not required in that case. More accurately, @FieldResolver is not required if @Field is defined by the entity according to type-graphql.

ok clear thank.
Another question is about "selfKey". It is clearly mentionned that it is not necessary if there isn't any @JoinColumn. What about the case where there is a @RelationId ? Necessary ? If yes, what is the benefit ?
BTW, very good job ;-).

Using selfKey is not necessary at any time, but may provide performance increase. The reason of a speed up is because of how TypeORM works. In order to get the value of @relationId properties for relations without @JoinColumn, extra queries would be issued internally. By using selfKey, it is no longer necessary to define @relationId properties for them. That is the main source of the benefit.

ok clear thanks. personnaly, I prefer keeping @RelationId in the table definition for better readibility, especially when sharing devs with others people..
FYI, Here is a POC I'm having done using your librairy. Runs peferctly well, even with deep nested queries !
import { ArgsType, Field, InputType, ObjectType, Resolver } from "type-graphql";
import { TypeormLoader } from "type-graphql-dataloader";
import {
	Column,
	Entity,
	EntityRepository,
	getConnection,
	ManyToOne,
	OneToMany,
	RelationId,
} from "typeorm";
import { MyBaseEntity } from "./Generics/BaseEntity";
import { BaseRepository } from "./Generics/Repository";
import { resolversFactory } from "./Generics/resolvers";

@ObjectType()
@Entity({
	name: "ref",
})
class Ref extends MyBaseEntity {
	@Field({ nullable: true })
	@Column({
		type: "character varying",
		length: 20,
		nullable: true,
	})
	val: string;

	@Field(() => [Records], { nullable: true })
	@OneToMany(() => Records, (rec) => rec.ref)
	@TypeormLoader(() => Records, (ref: Ref) => ref.recordId)
	record: Records[];
	@RelationId((ref: Ref) => ref.record)
	recordId: string[];

	@Field(() => [Records], { nullable: true })
	@OneToMany(() => Records, (rec) => rec.ref2)
	@TypeormLoader(() => Records, (ref: Ref) => ref.record2Id)
	record2: Records[];
	@RelationId((ref: Ref) => ref.record2)
	record2Id: string[];
}

@ArgsType()
@InputType()
class RefInputType extends MyBaseEntity {
	@Field({ nullable: true })
	val: string;

	@Field(() => [RecordsInputType], { nullable: true })
	record: Records[];

	@Field(() => [RecordsInputType], { nullable: true })
	record2: Records[];
}

@EntityRepository(Ref)
class RefRepo extends BaseRepository<Ref> {
	constructor() {
		super(getConnection(), Ref);
	}
}

const resolverRef = resolversFactory<Ref, RefInputType>(Ref, RefInputType);

@Resolver(Ref)
class RefResolver extends resolverRef {
	constructor() {
		super(getConnection());
	}
}

@ObjectType()
@Entity({
	name: "records",
})
class Records extends MyBaseEntity {
	@Field({ nullable: true })
	@Column({
		type: "character varying",
		length: 20,
		nullable: true,
	})
	recVal: string;

	@Field(() => Ref, { nullable: true })
	@ManyToOne(() => Ref, (ref) => ref.record)
	@TypeormLoader(() => Ref, (rec: Records) => rec.refId)
	ref: Ref;
	@RelationId((rec: Records) => rec.ref)
	refId: string;

	@Field(() => Ref, { nullable: true })
	@ManyToOne(() => Ref, (ref2) => ref2.record2)
	@TypeormLoader(() => Ref, (rec: Records) => rec.ref2Id)
	ref2: Ref;
	@RelationId((rec: Records) => rec.ref2)
	ref2Id: string;

	@Field(() => [SubRecords], { nullable: true })
	@OneToMany(() => SubRecords, (subrec) => subrec.record)
	@TypeormLoader(() => SubRecords, (rec: Records) => rec.subRecordId)
	subRecord: SubRecords[];
	@RelationId((rec: Records) => rec.subRecord)
	subRecordId: string[];
}

@ArgsType()
@InputType()
class RecordsInputType extends MyBaseEntity {
	@Field({ nullable: true })
	recVal: string;

	@Field(() => RefInputType, { nullable: true })
	ref: Ref;

	@Field(() => RefInputType, { nullable: true })
	ref2: Ref;

	@Field(() => [SubRecordsInputType], { nullable: true })
	subRecord: SubRecords[];
}

const resolverRecords = resolversFactory<Records, RecordsInputType>(
	Records,
	RecordsInputType
);

@Resolver(Records)
class RecordsResolver extends resolverRecords {
	constructor() {
		super(getConnection());
	}
}

@EntityRepository(Records)
class RecordsRepo extends BaseRepository<Records> {
	constructor() {
		super(getConnection(), Records);
	}
}

@ObjectType()
@Entity({
	name: "subrecords",
})
class SubRecords extends MyBaseEntity {
	@Field({ nullable: true })
	@Column({
		type: "character varying",
		length: 20,
		nullable: true,
	})
	subRecVal: string;

	@Field(() => Records, { nullable: true })
	@ManyToOne(() => Records, (rec) => rec.subRecord)
	@TypeormLoader(() => Records, (subRec: SubRecords) => subRec.recordId)
	record: Records;
	@RelationId((subRec: SubRecords) => subRec.record)
	recordId: string;
}

@ArgsType()
@InputType()
class SubRecordsInputType extends MyBaseEntity {
	@Field({ nullable: true })
	subRecVal: string;

	@Field(() => RecordsInputType, { nullable: true })
	record: Records;
}

@EntityRepository(SubRecords)
class SubRecordsRepo extends BaseRepository<SubRecords> {
	constructor() {
		super(getConnection(), SubRecords);
	}
}

const resolverSubRecords = resolversFactory<SubRecords, SubRecordsInputType>(
	SubRecords,
	SubRecordsInputType
);

@Resolver(SubRecords)
class SubRecordsResolver extends resolverSubRecords {
	constructor() {
		super(getConnection());
	}
}

const allTestEntities = [Ref, Records, SubRecords];

const allTestResolvers = [RefResolver, RecordsResolver, SubRecordsResolver];

export {
	allTestEntities,
	allTestResolvers,
	Ref,
	RefInputType,
	RefResolver,
	RefRepo,
	Records,
	RecordsInputType,
	RecordsResolver,
	RecordsRepo,
	SubRecords,
	SubRecordsInputType,
	SubRecordsResolver,
	SubRecordsRepo,
};


"Dămțeni, Dealu Aluniș, Roșioara, Târgu Gângulești, Valea Mare" are villages in "BERBEȘTI" city, "VALCEA" county

Description
When an user search a location, this appear in the drop-down menu
according to the law
Precondition
The website ( https://peviitor-ro.github.io/ui.orase/ ) is up an running.
Empty the search bar after every step

Steps 1
Write "Dămțeni"
Expected result
In the drop down menu you find "Sat Dămțeni, VALCEA (BERBEȘTI)"
Test Data
Dămțeni

Steps 2
Write "Dealu Aluniș"
Expected result
In the drop down menu you find "Sat Dealu Aluniș, VALCEA (BERBEȘTI)"
Test Data
Dealu Aluniș

Steps 3
Write "Roșioara"
Expected result
In the drop down menu you find "Sat Roșioara, VALCEA (BERBEȘTI)"
Test Data
Roșioara

Steps 4
Write "Târgu Gângulești"
Expected result
In the drop down menu you find "Sat Târgu Gângulești, VALCEA (BERBEȘTI)"
Test Data
Târgu Gângulești

Steps 5
Write "Valea Mare"
Expected result
In the drop down menu you find "Sat Valea Mare, VALCEA (BERBEȘTI)"
Test Data
Valea Mare


[Explore] Timepicker time range interval design

How to reproduce the bug

Go to explore view, click Date picker, choose Previous range type
Current month is Jan, previous month should include 12/31

Actual results

Environment
latest master
cc @junlincc @zuzana-vej @zhaoyongjie

i do see it previous calendar month include 12/31? am i misunderstanding the issue?
what's not clear to us yet is the setting for previous calendar week.(but we do have plan to address that issue by adding setting)

i do see it previous calendar month include 12/31? am i misunderstanding the issue?
what's not clear to us yet is the setting for previous calendar week.(but we do have plan to address that issue by adding setting)

2020-12-01 <= col < 2020-12-31 means include 12-01, not include 12-31.

2020-12-01 <= col < 2020-12-31 means include 12-01, not include 12-31.

looks like this is happening in all tine setting, and the default state
https://user-images.githubusercontent.com/67837651/103683191-ba792400-4f3e-11eb-877f-aaead2239279.mov

looks like this is happening in all tine setting, and the default state
https://user-images.githubusercontent.com/67837651/103683191-ba792400-4f3e-11eb-877f-aaead2239279.mov

for display, Previous month should display as 2020-12-01 <= col < 2021-01-01

for display, Previous month should display as 2020-12-01 <= col < 2021-01-01

what about changing the END operator to "≤"?

what about changing the END operator to "≤"?

acknowledging the severity of this regression as it is misleading users. my mad not catching it before we merged. Thanks for reporting! 🙏

acknowledging the severity of this regression as it is misleading users. my mad not catching it before we merged. Thanks for reporting! 🙏

i feel we should display 2020-12-01 <= col < 2021-01-01 not 2020-12-01 <= col <= 2021-12-31.
This will be consistent with all other time range display format, which means include begin, exclude end.

i feel we should display 2020-12-01 <= col < 2021-01-01 not 2020-12-01 <= col <= 2021-12-31.
This will be consistent with all other time range display format, which means include begin, exclude end.

im suggesting to make this change universal and i believe using "<" is a bug not by design
looking at the old time picker, it had a similar problem on pill display. but actually including both start and end dates in the query.

im suggesting to make this change universal and i believe using "<" is a bug not by design
looking at the old time picker, it had a similar problem on pill display. but actually including both start and end dates in the query.

@junlincc see SIP-15 as to why the start and end time range intervals are inclusive of and exclusive  of respectively.

@junlincc see SIP-15 as to why the start and end time range intervals are inclusive of and exclusive  of respectively.


Adding favicon

I have added the favicon of your designed picture from this issue #11
Let me know if I need to change or add something, and it would be great too if I get hacktoberfest-accepted label too, Thank you.

thanks a lot for ur help


Optimize 'getSourceFile' to only get the source file once.

In response to https://github.com/Microsoft/TypeScript/pull/10729#discussion_r77733954

👍


AbstractController->dispatchPostEvents expects Symfony File instead of FlysystemFile

Bug Report
Uploading a file returns Error:
"Oneup\UploaderBundle\Controller\AbstractController::dispatchPostEvents(): Argument #1 ($uploaded) must be of type Symfony\Component\HttpFoundation\File\File, Oneup\UploaderBundle\Uploader\File\FlysystemFile given, called in /var/www/html/vendor/oneup/uploader-bundle/src/Controller/AbstractController.php on line 128"

Q
A

Symfony
6.4.3

Oneup/UploaderBundle
5.0.0

Oneup/FlysystemBundle
4.11.2

Dropzone
6.0.0-beta.2

Summary
After setting up Oneup/UploaderBundle, Oneup/FlysystemBundle and Dropzone I tested out the upload and received an error.
It seems like Oneup\UploaderBundle\Uploader\Storage\FlysystemStorage->upload returns a Oneup\UploaderBundle\Uploader\File\FlysystemFile. And Oneup\UploaderBundle\Controller->dispatchPostEvents expects a Symfony\Component\HttpFoundation\File\File.
Either FlysystemFile needs to extend the Symfony File class. Or the parameter type in AbstractController->dispatchPostEvents should be changed to Oneup\UploaderBundle\Uploader\File\FileInterface.
How to reproduce
I believe it happens whenever you use Oneup/UploaderBundle v5.0.0 und try to upload a file.

Just hit the same bug, but with Uppy library.
Problem arised after: updating to Oneup/UploaderBundle 5.0.0.

Hello, @bytehead!
Yes, patch allowes upload to function as itended.
Thank you for speedy fix!

5.0.1 is out! Thanks again for reporting! 🙏

@bytehead Sorry for the late reply. Can confim, it works now with v5.0.1.
Thank you for the quick fix!  Thanks for the feedback.


add xk.svg

iso code does not exist. but  International Aid Transparency Initiative defined XK code
see http://iatistandard.org/201/codelists/Country/


chore: upgrade to rust-lightning 0.0.116 and bump rust-dlc

Note: all positions before this seem to be broken
fix #1084
fix #1472
I'm not sure what we should do regarding the breaking of existing positions. Any thoughts on this?

I'm not sure what we should do regarding the breaking of existing positions. Any thoughts on this?

Before releasing we could let all positions expire and not accept new positions. (I think we can configure that already today?)
Once all positions are closed we can release the new version.

I'm not sure what we should do regarding the breaking of existing positions. Any thoughts on this?

Before releasing we could let all positions expire and not accept new positions. (I think we can configure that already today?)
Once all positions are closed we can release the new version.

That's not ideal neither, we'd need to also force close all channels which have expired but not collaboratively closed.
Maybe we should look into how to make the db backwards compatible so that we can at least load things and let users collaborative close?

That's not ideal neither, we'd need to also force close all channels which have expired but not collaboratively closed.
Maybe we should look into how to make the db backwards compatible so that we can at least load things and let users collaborative close?

hmm.. fair, but for how long do you want to keep those expired positions?

@bonomat, @holzeis: Please have another look at this. There was a slightly tricky rebase in between which forced me to touch the collaborative revert functionality that was recently introduced.

@bonomat, @holzeis: Please have another look at this. There was a slightly tricky rebase in between which forced me to touch the collaborative revert functionality that was recently introduced.
I've tested this a few times locally:
* Open channel + position on 0.0.114.

* Upgrade app and coordinator to 0.0.116.

* Restart app and coordinator without hiccups.

* Collaboratively revert the open subchannel, with the money arriving back in the app's on-chain wallet.

I also did the same (except the last step, since it's impossible) for a channel without an open position.

Unfortunately I cannot confirm that this works for me :(

start coordinator/app/maker on 0c0a33a157db4ad873147badb12ffea40d28b1bb
trade with app 1 keep position open
trade with app 2 open and close position
upgrade all to this PR
--> can't start the coordiantor:

     Running `target/debug/coordinator`
2023-11-01 19:46:27  INFO coordinator::logger: Initialized logger
2023-11-01 19:46:27  INFO coordinator: Data-dir: "/Users/bonomat/src/github/itchysats/10101/data/coordinator/regtest"
2023-11-01 19:46:27 DEBUG coordinator::cli: Skipping node announcement on '<IP_ADDRESS>'.
2023-11-01 19:46:27  INFO coordinator::cli: Adding node announcement within local network <IP_ADDRESS>. Do not use for production!
2023-11-01 19:46:27  INFO ln_dlc_node::on_chain_wallet: Creating the wallet network=Regtest
2023-11-01 19:46:27  INFO ln_dlc_node::node::channel_manager: Found channel manager data on disk. Recovering from stored state
Error: Unknown required feature preventing decode

Unfortunately I cannot confirm that this works for me :(
1. start coordinator/app/maker on [0c0a33a](https://github.com/get10101/10101/commit/0c0a33a157db4ad873147badb12ffea40d28b1bb)

2. trade with app 1 keep position open

3. trade with app 2 open and close position

4. upgrade all to this PR

5. --> can't start the coordiantor:

     Running `target/debug/coordinator`
2023-11-01 19:46:27  INFO coordinator::logger: Initialized logger
2023-11-01 19:46:27  INFO coordinator: Data-dir: "/Users/bonomat/src/github/itchysats/10101/data/coordinator/regtest"
2023-11-01 19:46:27 DEBUG coordinator::cli: Skipping node announcement on '<IP_ADDRESS>'.
2023-11-01 19:46:27  INFO coordinator::cli: Adding node announcement within local network <IP_ADDRESS>. Do not use for production!
2023-11-01 19:46:27  INFO ln_dlc_node::on_chain_wallet: Creating the wallet network=Regtest
2023-11-01 19:46:27  INFO ln_dlc_node::node::channel_manager: Found channel manager data on disk. Recovering from stored state
Error: Unknown required feature preventing decode

Hmm, I haven't been able to reproduce your problem yet.

I can confirm that it's working for me 🚀

just wipe
start coordinator, maker
just fund
start app / create wallet
fund wallet with faucet
open position
stop coordinator
change to head of branch chore/upgrade-to-rust-lightning-116
start coordinator / restart maker
just gen ios run
close position 🎉

Unfortunately I have severe problems with this branch :(
Even if I just use this branch to do a restart roundtrip I get errors, e.g.

checkout this branch
start everything up on a new env
fund an open position through app
close coordinator
start coordinator

Get same error :(
2023-11-02 16:33:30  INFO coordinator::logger: Initialized logger
2023-11-02 16:33:30  INFO coordinator: Data-dir: "/Users/bonomat/src/github/itchysats/10101/data/coordinator/regtest"
2023-11-02 16:33:30 DEBUG coordinator::cli: Skipping node announcement on '<IP_ADDRESS>'.
2023-11-02 16:33:30  INFO coordinator::cli: Adding node announcement within local network <IP_ADDRESS>. Do not use for production!
2023-11-02 16:33:30  INFO ln_dlc_node::on_chain_wallet: Creating the wallet network=Regtest
2023-11-02 16:33:30  INFO ln_dlc_node::node::channel_manager: Found channel manager data on disk. Recovering from stored state
2023-11-02 16:33:30  INFO lightning::ln::channelmanager: Successfully loaded channel 1653c2e484433eb51a01a0550bd3a22032f6ffff08658b4311dd8c687eebb992 at update_id 0 against monitor at update id 0
Error: Unknown required feature preventing decode

I did a full wipe of all cached dependencies, data and docker and now I get a new error 😅
2023-11-02 18:40:46  INFO coordinator::logger: Initialized logger
2023-11-02 18:40:46  INFO coordinator: Data-dir: "/Users/bonomat/src/github/10101/10101/data/coordinator/regtest"
2023-11-02 18:40:46 DEBUG coordinator::cli: Skipping node announcement on '<IP_ADDRESS>'.
2023-11-02 18:40:46  INFO coordinator::cli: Adding node announcement within local network <IP_ADDRESS>. Do not use for production!
2023-11-02 18:40:46  INFO ln_dlc_node::on_chain_wallet: Creating the wallet network=Regtest
2023-11-02 18:40:47  INFO ln_dlc_node::node::channel_manager: Found channel manager data on disk. Recovering from stored state
2023-11-02 18:40:47  INFO lightning::ln::channelmanager: Successfully loaded channel 190c731887bfd7644d16ee22da3e486327d99cbae0488ad0e6cf2f2be55d1c5b at update_id 0 against monitor at update id 0
2023-11-02 18:40:47  INFO lightning::ln::channelmanager: Successfully loaded channel 84fa01f9fae2999302f145746559758b11c27a36467c5539ce49c2dd17013e40 at update_id 13 against monitor at update id 13
2023-11-02 18:40:47  INFO lightning::ln::channelmanager: Successfully loaded channel 1e41104c8dd12cfc1c396ddf95dfa20a516a6e0f9eebdbf156ab3df2b2f4331d at update_id 5 against monitor at update id 5
2023-11-02 18:40:47 ERROR coordinator: Aborting after panic in task info=panicked at 'We already checked for monitor presence when loading channels', /Users/bonomat/.cargo/git/checkouts/rust-lightning-bee3233422fa4387/b13daab/lightning/src/ln/channelmanager.rs:8879:22
   0: std::backtrace_rs::backtrace::libunwind::trace
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1: std::backtrace_rs::backtrace::trace_unsynchronized
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2: std::backtrace::Backtrace::create
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/backtrace.rs:332:13
   3: coordinator::main::{{closure}}::{{closure}}
             at ./coordinator/src/bin/coordinator.rs:59:29
   4: <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/alloc/src/boxed.rs:1987:9
   5: std::panicking::rust_panic_with_hook
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:695:13
   6: std::panicking::begin_panic_handler::{{closure}}
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:582:13
   7: std::sys_common::backtrace::__rust_end_short_backtrace
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/sys_common/backtrace.rs:150:18
   8: rust_begin_unwind
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:578:5
   9: core::panicking::panic_fmt
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/panicking.rs:67:14
  10: core::panicking::panic_display
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/panicking.rs:150:5
  11: core::panicking::panic_str
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/panicking.rs:134:5
  12: core::option::expect_failed
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/option.rs:2025:5
  13: core::option::Option<T>::expect
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/option.rs:913:21
  14: lightning::ln::channelmanager::<impl lightning::util::ser::ReadableArgs<lightning::ln::channelmanager::ChannelManagerReadArgs<M,T,ES,NS,SP,F,R,L>> for (bitcoin::hash_types::newtypes::BlockHash,lightning::ln::channelmanager::ChannelManager<M,T,ES,NS,SP,F,R,L>)>::read
             at /Users/bonomat/.cargo/git/checkouts/rust-lightning-bee3233422fa4387/b13daab/lightning/src/ln/channelmanager.rs:8878:19
  15: ln_dlc_node::node::channel_manager::build
             at ./crates/ln-dlc-node/src/node/channel_manager.rs:98:27
  16: ln_dlc_node::node::Node<S>::new
             at ./crates/ln-dlc-node/src/node/mod.rs:340:31
  17: coordinator::main::{{closure}}
             at ./coordinator/src/bin/coordinator.rs:106:25
  18: <tracing::instrument::Instrumented<T> as core::future::future::Future>::poll
             at /Users/bonomat/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tracing-0.1.37/src/instrument.rs:272:9
  19: tokio::runtime::park::CachedParkThread::block_on::{{closure}}
             at /Users/bonomat/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.2/src/runtime/park.rs:283:63
  20: tokio::runtime::coop::with_budget
             at /Users/bonomat/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.2/src/runtime/coop.rs:107:5
  21: tokio::runtime::coop::budget
             at /Users/bonomat/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.2/src/runtime/coop.rs:73:5
  22: tokio::runtime::park::CachedParkThread::block_on
             at /Users/bonomat/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.2/src/runtime/park.rs:283:31
  23: tokio::runtime::context::BlockingRegionGuard::block_on
             at /Users/bonomat/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.2/src/runtime/context.rs:315:13
  24: tokio::runtime::scheduler::multi_thread::MultiThread::block_on
             at /Users/bonomat/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.2/src/runtime/scheduler/multi_thread/mod.rs:66:9
  25: tokio::runtime::runtime::Runtime::block_on
             at /Users/bonomat/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.2/src/runtime/runtime.rs:304:45
  26: coordinator::main
             at ./coordinator/src/bin/coordinator.rs:320:5
  27: core::ops::function::FnOnce::call_once
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/ops/function.rs:250:5
  28: std::sys_common::backtrace::__rust_begin_short_backtrace
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/sys_common/backtrace.rs:134:18
  29: std::rt::lang_start::{{closure}}
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/rt.rs:166:18
  30: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/ops/function.rs:287:13
  31: std::panicking::try::do_call
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:485:40
  32: std::panicking::try
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:449:19
  33: std::panic::catch_unwind
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panic.rs:140:14
  34: std::rt::lang_start_internal::{{closure}}
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/rt.rs:148:48
  35: std::panicking::try::do_call
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:485:40
  36: std::panicking::try
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:449:19
  37: std::panic::catch_unwind
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panic.rs:140:14
  38: std::rt::lang_start_internal
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/rt.rs:148:20
  39: std::rt::lang_start
             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/rt.rs:165:17
  40: _main

[1]    90478 abort      cargo run --bin coordinator

error comes from here:
https://github.com/p2pderivatives/rust-lightning/blob/b13daab906b04efb50a2e467c0299ed6ea81b058/lightning/src/ln/channelmanager.rs#L8878-L8880

I did a full wipe of all cached dependencies, data and docker and now I get a new error 😅

2023-11-02 18:40:46  INFO coordinator::logger: Initialized logger

2023-11-02 18:40:46  INFO coordinator: Data-dir: "/Users/bonomat/src/github/10101/10101/data/coordinator/regtest"

2023-11-02 18:40:46 DEBUG coordinator::cli: Skipping node announcement on '<IP_ADDRESS>'.

2023-11-02 18:40:46  INFO coordinator::cli: Adding node announcement within local network <IP_ADDRESS>. Do not use for production!

2023-11-02 18:40:46  INFO ln_dlc_node::on_chain_wallet: Creating the wallet network=Regtest

2023-11-02 18:40:47  INFO ln_dlc_node::node::channel_manager: Found channel manager data on disk. Recovering from stored state

2023-11-02 18:40:47  INFO lightning::ln::channelmanager: Successfully loaded channel 190c731887bfd7644d16ee22da3e486327d99cbae0488ad0e6cf2f2be55d1c5b at update_id 0 against monitor at update id 0

2023-11-02 18:40:47  INFO lightning::ln::channelmanager: Successfully loaded channel 84fa01f9fae2999302f145746559758b11c27a36467c5539ce49c2dd17013e40 at update_id 13 against monitor at update id 13

2023-11-02 18:40:47  INFO lightning::ln::channelmanager: Successfully loaded channel 1e41104c8dd12cfc1c396ddf95dfa20a516a6e0f9eebdbf156ab3df2b2f4331d at update_id 5 against monitor at update id 5

2023-11-02 18:40:47 ERROR coordinator: Aborting after panic in task info=panicked at 'We already checked for monitor presence when loading channels', /Users/bonomat/.cargo/git/checkouts/rust-lightning-bee3233422fa4387/b13daab/lightning/src/ln/channelmanager.rs:8879:22

   0: std::backtrace_rs::backtrace::libunwind::trace

             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5

   1: std::backtrace_rs::backtrace::trace_unsynchronized

             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5

   2: std::backtrace::Backtrace::create

             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/backtrace.rs:332:13

   3: coordinator::main::{{closure}}::{{closure}}

             at ./coordinator/src/bin/coordinator.rs:59:29

   4: <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call

             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/alloc/src/boxed.rs:1987:9

   5: std::panicking::rust_panic_with_hook

             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:695:13

   6: std::panicking::begin_panic_handler::{{closure}}

             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:582:13

   7: std::sys_common::backtrace::__rust_end_short_backtrace

             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/sys_common/backtrace.rs:150:18

   8: rust_begin_unwind

             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:578:5

   9: core::panicking::panic_fmt

             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/panicking.rs:67:14

  10: core::panicking::panic_display

             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/panicking.rs:150:5

  11: core::panicking::panic_str

             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/panicking.rs:134:5

  12: core::option::expect_failed

             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/option.rs:2025:5

  13: core::option::Option<T>::expect

             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/option.rs:913:21

  14: lightning::ln::channelmanager::<impl lightning::util::ser::ReadableArgs<lightning::ln::channelmanager::ChannelManagerReadArgs<M,T,ES,NS,SP,F,R,L>> for (bitcoin::hash_types::newtypes::BlockHash,lightning::ln::channelmanager::ChannelManager<M,T,ES,NS,SP,F,R,L>)>::read

             at /Users/bonomat/.cargo/git/checkouts/rust-lightning-bee3233422fa4387/b13daab/lightning/src/ln/channelmanager.rs:8878:19

  15: ln_dlc_node::node::channel_manager::build

             at ./crates/ln-dlc-node/src/node/channel_manager.rs:98:27

  16: ln_dlc_node::node::Node<S>::new

             at ./crates/ln-dlc-node/src/node/mod.rs:340:31

  17: coordinator::main::{{closure}}

             at ./coordinator/src/bin/coordinator.rs:106:25

  18: <tracing::instrument::Instrumented<T> as core::future::future::Future>::poll

             at /Users/bonomat/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tracing-0.1.37/src/instrument.rs:272:9

  19: tokio::runtime::park::CachedParkThread::block_on::{{closure}}

             at /Users/bonomat/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.2/src/runtime/park.rs:283:63

  20: tokio::runtime::coop::with_budget

             at /Users/bonomat/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.2/src/runtime/coop.rs:107:5

  21: tokio::runtime::coop::budget

             at /Users/bonomat/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.2/src/runtime/coop.rs:73:5

  22: tokio::runtime::park::CachedParkThread::block_on

             at /Users/bonomat/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.2/src/runtime/park.rs:283:31

  23: tokio::runtime::context::BlockingRegionGuard::block_on

             at /Users/bonomat/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.2/src/runtime/context.rs:315:13

  24: tokio::runtime::scheduler::multi_thread::MultiThread::block_on

             at /Users/bonomat/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.2/src/runtime/scheduler/multi_thread/mod.rs:66:9

  25: tokio::runtime::runtime::Runtime::block_on

             at /Users/bonomat/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.28.2/src/runtime/runtime.rs:304:45

  26: coordinator::main

             at ./coordinator/src/bin/coordinator.rs:320:5

  27: core::ops::function::FnOnce::call_once

             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/ops/function.rs:250:5

  28: std::sys_common::backtrace::__rust_begin_short_backtrace

             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/sys_common/backtrace.rs:134:18

  29: std::rt::lang_start::{{closure}}

             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/rt.rs:166:18

  30: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once

             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/core/src/ops/function.rs:287:13

  31: std::panicking::try::do_call

             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:485:40

  32: std::panicking::try

             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:449:19

  33: std::panic::catch_unwind

             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panic.rs:140:14

  34: std::rt::lang_start_internal::{{closure}}

             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/rt.rs:148:48

  35: std::panicking::try::do_call

             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:485:40

  36: std::panicking::try

             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panicking.rs:449:19

  37: std::panic::catch_unwind

             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/panic.rs:140:14

  38: std::rt::lang_start_internal

             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/rt.rs:148:20

  39: std::rt::lang_start

             at /rustc/90c541806f23a127002de5b4038be731ba1458ca/library/std/src/rt.rs:165:17

  40: _main

[1]    90478 abort      cargo run --bin coordinator

error comes from here:
https://github.com/p2pderivatives/rust-lightning/blob/b13daab906b04efb50a2e467c0299ed6ea81b058/lightning/src/ln/channelmanager.rs#L8878-L8880

Did you check out the right commit? That's a problem that was solved with a later patch in our rust-lightning branch.

Mhm, thanks... I suspect I became the unsuspecting victim of cosmic radiation, which decided to play a little prank by flipping a few bits. This cosmic shenanigan led to the birth of a version control monster! This sneaky creature was a master at hide and seek and thwarted all my attempts to reset the git branch against the remote. But fear not, for after a good old-fashioned restart of my machine, I finally managed to outwit and defeat the cosmic trickster, and now we're on the path to world peace, one git commit at a time!

Mhm, thanks... I suspect I became the unsuspecting victim of cosmic radiation, which decided to play a little prank by flipping a few bits. This cosmic shenanigan led to the birth of a version control monster! This sneaky creature was a master at hide and seek and thwarted all my attempts to reset the git branch against the remote. But fear not, for after a good old-fashioned restart of my machine, I finally managed to outwit and defeat the cosmic trickster, and now we're on the path to world peace, one git commit at a time!

Hahaha, I knew we would get there eventually!


type 'int' is not a subtype of type 'double'

when dismissing giving this error - > type 'int' is not a subtype of type 'double'

I am getting the same when the device goes to portrait mode..
I am using ValueNotifier for miniplayer..
final ValueNotifier customValueNotifier =
ValueNotifier(MediaQuery.of(context).size.height);
Miniplayer(
controller: _videoController.miniPlayerController,
valueNotifier: customValueNotifier,
minHeight: _playerMinHeight,
Here is the call stack..
/flutter (10556): _ValueListenableBuilderState#7a816):
I/flutter (10556): type 'int' is not a subtype of type 'double'
I/flutter (10556):
I/flutter (10556): The relevant error-causing widget was:
I/flutter (10556):   Miniplayer
I/flutter (10556):
lib/…/views/home_view.dart:55
I/flutter (10556):
I/flutter (10556): When the exception was thrown, this was the stack:
I/flutter (10556): #0      borderDouble
package:miniplayer/src/utils.dart:24
I/flutter (10556): #1      _MiniplayerState.build.
package:miniplayer/miniplayer.dart:169
I/flutter (10556): #2      _ValueListenableBuilderState.build
package:flutter/…/widgets/value_listenable_builder.dart:187
I/flutter (10556): #3      StatefulElement.build
package:flutter/…/widgets/framework.dart:4691

Did you solve or? I solved, add github and add to protect from github url, like package

Is this package/repo is been maintained? Not seeing any response recently on any issues....

Did you solve or? I solved, add github and add to protect from github url, like package

Nope I didn't resolve it yet. How did you resolve ? Any plan to merge it with this package via PR ?

@toklive - https://github.com/Shahmirzali-Huseynov/miniplayer_for_araf
no, I'm not owner this package, there is the like above solved version.

add pubspecyaml
miniplayer:
git:
url: git://github.com/Shahmirzali-Huseynov/miniplayer_for_araf.git

like this

also you can add your repository and use it from there

Great thank you. I will do also I may send a PR with the change..

There are two branches here master and nullsafety , which one u used to make the modifications

I don't know unfortunately

I'll take a look this week!

I solved this problem..


Failed to show text document error using FileSystemProvider

VSCode Version: 1.39.2
OS Version: 10.14.6 (18G103)

Steps to Reproduce:

Create an extension with the default options
Add the code below
Run the extension
Open a file ending with "test"

A new text window correctly opens, however there is an error message:
rejected promise not handled within 1 second: Error: Failed to show text document myprovider:/Users/dnicolson/test, should show in editor #vs.editor.ICodeEditor:1,$model2
extensionHostProcess.js:787
stack trace: Error: Failed to show text document myprovider:/Users/dnicolson/test, should show in editor #vs.editor.ICodeEditor:1,$model2
	at t.ExtHostEditors.showTextDocument._proxy.$tryShowTextDocument.then.t (/Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/services/extensions/node/extensionHostProcess.js:615:78)

extension.ts

import * as vscode from 'vscode';
const util = require('util');

class MyFileSystemProvider implements vscode.FileSystemProvider {
	readFile(uri: vscode.Uri): Uint8Array {
		return new util.TextEncoder('utf-8').encode('Text content');
	}

	writeFile(uri: vscode.Uri, content: Uint8Array, options: { create: boolean; overwrite: boolean; }): void {}

	stat(uri: vscode.Uri): vscode.FileStat | Thenable<vscode.FileStat> {
		return ({ type: vscode.FileType.File }) as vscode.FileStat;
	}

	onDidChangeFile: vscode.Event<vscode.FileChangeEvent[]> = new vscode.EventEmitter<vscode.FileChangeEvent[]>().event;
	createDirectory(uri: vscode.Uri) { }
	delete(uri: vscode.Uri, options: { recursive: boolean; }) { }
	readDirectory(uri: vscode.Uri) { return []; }
	rename(oldUri: vscode.Uri, newUri: vscode.Uri, options: { overwrite: boolean; }) { }
	watch(uri: vscode.Uri, options: { recursive: boolean; excludes: string[]; }) { return new vscode.Disposable(() => { }); }
}

export function activate(context: vscode.ExtensionContext) {
	vscode.workspace.registerFileSystemProvider('myprovider', new MyFileSystemProvider(), {
		isCaseSensitive: process.platform === 'linux'
	});

	vscode.workspace.onDidOpenTextDocument(async document => {
		if (document.fileName.match(/test$/)) {
			const uri = vscode.Uri.file(document.fileName).with({scheme: 'myprovider'});
      const doc = await vscode.workspace.openTextDocument(uri);
      await vscode.window.showTextDocument(doc, { preview: false });
		}
	});
}

export function deactivate() {}

package.json
"activationEvents": [
	"onFileSystem:myprovider",
	"*"
]

Does this issue occur when all extensions are disabled?: Yes

Please try this again with a complete implementation of stat - the one showing above only sets the type and I believe we also use size and the times.

The error is still displayed after including the contents of fs.lstatSync(uri.path).

The error is still displayed after including the contents of fs.lstatSync(uri.path)

Can sure what that means. Can you update your sample with your changes?

I haven't updated the original but here are the complete methods of what I have attempted:
stat(uri: vscode.Uri): vscode.FileStat | Thenable<vscode.FileStat> {
    const stat = fs.lstatSync(uri.path);
    return ({ type: vscode.FileType.File, ...stat, name: 'test' }) as vscode.FileStat;
}

stat(uri: vscode.Uri): vscode.FileStat | Thenable<vscode.FileStat> {
    return ({ type: vscode.FileType.File, ctime: Date.now(), mtime: Date.now(), size: 0, name: 'test' }) as vscode.FileStat;
}

can you try with our sample provider: https://github.com/microsoft/vscode-extension-samples/blob/master/fsprovider-sample/src/fileSystemProvider.ts

I used the MemFS class and the same problem exists.
Files can be read without error but after adding .with({scheme: 'myprovider'}); the stat and readFile methods must be replaced.
Everything works despite the error.

I used the MemFS class and the same problem exists.

Files can be read without error but after adding .with({scheme: 'myprovider'}); the stat and readFile methods must be replaced.
Sorry, I don't understand what that means

I used all the methods from MemFS, the sample provider linked above.
The class works without error, but the scheme needs to be changed to create a virtual file system (myprovider:). After stat and readFile methods are updated the code works (with the aforementioned error).

I have tried your snippet and it works for me. I had to remove return new util.TextEncoder('utf-8').encode('Text content'); because I don't have the util-lib. Instead I have used Buffer.fromString('Text content') and when opening a test file I see the fake-file being opened.

It looks like the issue is fixed with the newly released version 1.40.


[Hyperion] Support Hibernate/Unhibernate feature for Hyperion App

Tech spec :
https://docs.google.com/document/d/1IYVCa2L9SSMzujiBsthfJZvyTI96_Lwd5CUmjEBaizw/edit


What's the point of -Force / -NoCache if it checks existing data anyway?

Using this command: nuget restore solutionname.sln -Force -NoCache
i keep getting "Assets file has not changed. Skipping assets file writing." I am attempting to restore my solution packages using this command to bypass the awfully tedious process of patching a multi project solution template to load my nuget references.

Dokumentdetails
⚠ Bearbeiten Sie diesen Abschnitt nicht. Er ist für die Verknüpfung von docs.microsoft.com zum GitHub-Artikel erforderlich.

ID: d63170c3-1894-8ead-b557-9937dae88172
Version Independent ID: 67968c11-0aa0-f835-357d-8690911eb011
Content: NuGet-CLI-Befehl
Content Source: docs/tools/cli-ref-restore.md
GitHub Login: @karann-msft
Microsoft Alias: karann

Hello, @taori
Your contribution is much appreciated. Our team can only answer feedback related to the documentation.
Please kindly log your product feedback by using the button "Give Product Feedback" at the bottom of the DOCS page.
If you have any feedback related to the documentation, please feel free to log it through this channel.
We truly appreciate your contribution to our articles.
Kind regards,
Microsoft DOCS International Team


feature: rewrite in typescript

At my company we are using typescript and want to use micro for more projects.
In this context I've used your package and like how simple it is and how it provides valuable semantics when used.
Though one problem came on, we are using typescript and this package is not.
As submitting a declaration file to the DefinitelyTyped repository involves the risk of loosing sync with the original codebase, I've decided against it and instead prepared this Pull Request.
The rewrite is backwards compatible and acts as a drop in replacement for the current JavaScript implementation.
To achieve this the typescript code gets transpiled into standards compliant ES2016 which is what the original code seems to use. In addition to that the typescript tool also generates a type declaration and places both in the dist directory, you can try this for yourself by running yarn build.
I've not changed the test cases, except renaming the file to .ts and adding type annotations where required.
I've tested the changes Not on my Machine (TM) but on Travis-CI
Happy Review and I would appreciate any feedback you can offer :)

I'll take a complete look in the end of the day (GMT-3)!
But what I saw at this moment, you did a great job!
Thank you!

@romuloalves Just wanted to ask if you have had time to review this?
For the next two weeks I'm going to be unable to make changes, if required.

@zetaron Sorry bro, the things wasn't how expected.
I'll try to review as soon as possible but I think everything is OK.

@zetaron
Published! https://www.npmjs.com/package/micro-post
Thank you SO MUCH ❤ and sorry for the delay!

@romuloalves thanks for the merge and publish 👍 also no offense taken due to the delay, I suppose this is a private project and therefore you are investing your own quality time which is huge.


Stellar relay

As what Torsten suggested , we're going to archive the stellar-experiments and move it to spacewalk.
This absolutely needs a review, and I probably have to plug a lot of todos everywhere.
(I've also incorporated the retry thing)
But this will now be my basis, for finishing issue 85.
Additional things to do:

add more unit tests
add the demo here, as an example.
update the readme file
cleanup the code
add more comments.

Should we maybe move it from the 'root' to the 'clients' folder instead? Since it is related to the client and plays along with the other directories we have in there (ie 'runtime', 'service', ..)


FIX-#3689: Add black and flake8 into development environment files

Signed-off-by: Andrew Li<EMAIL_ADDRESS>
What do these changes do?
Add black and flake8 into requirements-dev.txt

[x] commit message follows format outlined here
[ ] passes flake8 modin/ asv_bench/benchmarks scripts/doc_checker.py
[ ] passes black --check modin/ asv_bench/benchmarks scripts/doc_checker.py
[x] signed commit with git commit -s
[x] Resolves #3689
[ ] tests added and passing
[ ] module layout described at docs/development/architecture.rst is up-to-date
[ ] added (Issue Number: PR title (PR Number)) and github username to release notes for next major release

@orcahmlee the commit message for 39d61d1 is missing the FIX-#3689: piece. You can do a git commit --amend and edit the commit message to add it, then you will need to git push --force since it is modifying the commit message of an existing commit. Let me know if that doesn't make sense!

@orcahmlee the commit message for 39d61d1 is missing the FIX-#3689: piece. You can do a git commit --amend and edit the commit message to add it, then you will need to git push --force since it is modifying the commit message of an existing commit. Let me know if that doesn't make sense!

@devin-petersohn I saw the commitlint fail and already fixed it. Sorry about that, it is my first commit on this project.

To keep all environment files for development consistent we should also add black and flake8 (probably, flake8-print and flake8-no-implicit-concat too) in environment-dev.yml, requirements/env_omnisci.yml, requirements/requirements-no-engine.yml.

@YarShev Thanks for pointing out the conda environment yaml files should be updated too, already added it.

Sorry for the commitlint failing again. I changed the - FIX-#3689: piece to FIX-#3689:.

@orcahmlee, thank you for the changes! One more thing needs to be done prior the merge. Please add a release note under Dependencies clause and your GH nickname under Contributors clause in https://github.com/modin-project/modin/blob/master/docs/release_notes/release_notes-0.15.0.rst.

Thanks @YarShev , already done.


I'm procastinating a lot - add new game as webhook

this depends on https://github.com/usegalaxy-eu/infrastructure-playbook/pull/263

awesome!!! <3


Changelog?

Do y'all have a Changelog?

No, not yet. You can go through the commit history to get an idea of what happened, but not much has really changed since the initial release anyways.


Override history ID?

Is it possible to override the history_id of a history model, much in the same way you document overriding the history date?
I'm going to need to expose the history over URLs and I'd rather not expose incrementing auto-integers in URLs.

Fixed in #368


Support resize of viewport

This adds a brand new feature supporting resize of the viewport. It's an option that needs to be explicitly turned on, and one can choose whether height and/or width should be possible to change. We've used this feature ourself in production for a while, mostly locking resize to height, and it works well as far as we've seen. Although support on touch devices have not been tested.
Since an image is usually in the document flow, we feel it makes most sense to only allow dragging to resize on the bottom and right side of the image. This adds handles, similar to crop+resize in Photoshop and other image editors, at the bottom and right of the viewport. Clicking and dragging on the handles will update the viewport size dynamically. Size is limited to a minimum of 50px, and a maximum of the current height of the actual image.
I've added a demo of it on the official demo page. Since tests does not seem to be used much/up to date, I haven't added any new tests for this.
Any input is very welcome, and I hope we can make this fit in the main version of Croppie making it easier for us to keep our use up to date.

Thanks for the PR - there's been a lot of interest in this one.  I'm motivated to get it in the master branch, I just need to find time.  Possibly later this week.

Great! Yes, I think I commented on an earlier thread about this and said we'd be interested in helping out getting this in place. Sorry it's taken so long.
I conveniently pushed out this PR the day before going on a weeks holiday. But if you get the time to look more closely at it this week I'll be ready to make any changes starting Tuesday next week.

This is just awesome, and it works surprisingly well.  I wasn't sure how well a resizable viewport would work within croppie, but I'm impressed.
I'm not interested in holding this one up for feature creep, but I can see adding some additional options to this.

It'd be nice to have the handles on the top and bottom, left and right
I'd like the ability to not resize the boundary when I'm resizing the viewport.  I'm guessing there's a reason you did it for your use case so I don't think we should change it immediately, but I think it could be a bit more useful in general use cases.

That's really it.  I'm going to go ahead and get this one merged into master.  Super exciting.
If you'd like to work on the other options, that'd be great, but if not, no big deal.  Thanks a ton for helping out.

Awesome, glad you like the feature. Regarding your two feature suggestions, I don't think we have a particular need for those so I'm not sure how soon I'd be able to look into implementing that. But I have a couple questions about them to clarify the needs:

One of the reasons we didn't implement handles on the top and left is that our images are positioned in the document flow, as opposed to absolutely positioned as layers on top. That means even if you drag upwards or to the left, the image would still stay at the same top/left position and the opposite side would extend while you drag. Sure, the editor itself is absolutely positioned, but I think what you see in the editor (including position) should be the same as when you exit. So that doesn't sound very intuitive or pleasant to me. But maybe you have some thoughts on how that would behave?
Hm, so by not resizing the boundary, the boundary acts as a maximum size? Sounds fair to me as an option. We see the boundary more as an indication that you're in edit mode, where you can see where the image extends outside the crop. If that makes sense to you.

Anyway, thanks for merging this into master. And thanks for making a new release. We will make use of this new version in our product this week, and see if we come across any issues.


Fix case sensitivity & do LosAngeles justice.

Looks good.
Commit description:

Fix Issue #4.
Usernames now display in the same case as on MAL.
Moved getUser and getID functions to a new file.
LosAngeles now gets a history table (Long Live LosAngeles and hollywood!)
Optimized dig_records functionality
Server admin now need to edit one variable ($projectID) to deploy for own firebase project.
Changed instructions in README.md accordingly.

LET'S GOOOOOOOOO!


no response

hi,
thanks for the plugin
i have an esp connected to the lock, when he gets "X.X.X.X/OPEN" the appropriate the digital io goes to HIGH and vice versa.
when i connected your plugin the accessory shows me "no response"
any idea?
thanks

Hi, that's strange. Can you confirm whether "No Response" appears immediately after Homebridge startup or whether it happens when you try to change the state of the lock? It would also be helpful if you could attach a copy of your config.json (just the part for the lock) and an excerpt of your Homebridge logs when "No Response" appears - are there any errors?

thank you
thats the thing - my device does not send the 200 response,
could you maybe tell me which lines i need to mark out so it will be ok?

Really depends which device you're using. If you're using the Arduino IDE to program an ESP8266, you can take a look at one of my Node-MCU scripts here (lines 197 - 199).
Otherwise, just have a look for some guides specific to your device and see how they handle HTTP requests.
Best, Tom

hi,
what i meant was which lines do i need to markout from your code so that the 200 response will be indifferent. anyway - i am sending back a 200 response and the lock's status was still "no response".
the "no response" happens when i try to close the the lock.
my config was:
"accessory": "HTTPLock",
"name": "gate Lock",
"openURL": "http://XXX/on_gate",
"closeURL": "http://XXX/off_gate",
"autoLock": true,
"autoLockDelay": 3
at the end i figured it out with the help of your logs:
Jul 16 20:09:49 raspberrypi homebridge[504]: [7/16/2019, 8:09:49 PM] [gate Lock] Setting LockTargetState to 0
Jul 16 20:09:52 raspberrypi homebridge[504]: [7/16/2019, 8:09:52 PM] [gate Lock] Error setting LockTargetState: ETIMEDOUT
Jul 16 20:10:03 raspberrypi homebridge[504]: [7/16/2019, 8:10:03 PM] [gate Lock] Setting LockTargetState to 0
Jul 16 20:10:06 raspberrypi homebridge[504]: [7/16/2019, 8:10:06 PM] [gate Lock] Error setting LockTargetState: connect EHOSTUNREACH <IP_ADDRESS>:80
so i added a 8000 mil sec timeout and now the status is coherent.

The problem is that the plugin is not hearing back from your device. Note the two errors listed: ETIMEDOUT and EHOSTUNREACH. Both errors indicate that either your device is unreachable or it is not responding to the requests. The best course of action would be to check whether the device is reachable by pinging it. If it is reachable, then the problem is with the device and not the plugin i.e. the device is not returning the correct response.


Update shade_exceptions

Preserves the inner error message by appending it to the outer error message, as it is documented to do.

Thank you for contributing to openstack-infra/shade!
openstack-infra/shade uses Gerrit for code review.
If you have never contributed to OpenStack before make sure you have read the
getting started documentation:
http://docs.openstack.org/infra/manual/developers.html#getting-started
Otherwise please visit
http://docs.openstack.org/infra/manual/developers.html#development-workflow
and follow the instructions there to upload your change to Gerrit.


Add Initial CSV to Parquet Conversion, Documentation, and Workflows

These changes are intended to enable CellProfiler output CSV to Parquet initial functionality and lay the groundwork for other data transformations. The primary focus of this work may be implemented via convert within pycytominer_transform/convert.py. Examples are provided within the docstring and also within the docs/source/tutorial.md file. Converted files may be left as-is in terms of data content or concatenated with similar data when provided a nested folder structure of similarly named CSV's.
While developing changes I was inspired to add cloudpathlib capabilities due to the data shared by @bethac07 via #8 (thanks again!). I wanted to gather feedback with this PR before proceeding to validate solutions for #8 itself, and hope that the changes introduced here will help with this.
The design of work within convert.py is intended to provide the opportunity for multiple data format type ingest and export, using PyArrow tables as internal data structures and Prefect workflows to facilitate this work. Prefect may optionally be used to scale implementation through covert's task_runner argument, for example using prefect-dask's DaskTaskRunner. A minimal example of this usage with default settings is provided via testing, which I feel will be important for addressing #8 among others as we move forward.
I welcome and thank you for your input on this! Please don't hesitate to let me know if I may clarify or provide changes to improve things.
These changes help address #4 , #9 , #2 , #1 , #7 .

Thank you @gwaybio and @falquaddoomi for your helpful review + suggested changes! I have some in-flight work which I'll be committing here soon and will follow up once that's finished. In the meantime wanted to respond to the generalized questions/comments.
From @gwaybio :

It's great to see pycytominer-transform works directly with S3 links! It's possible I missed this, but do you have a real-data test using S3?

I have not included a real data test for S3. In general, cloudpathlib recommends using various monkeypatching which I think I should add in to accomodate these cases.

How difficult would it be to swap out input and output formats? Essentially, if we determine that AnnData is a better output format, would it be tough to switch (or at least add an option)?

It wouldn't be difficult to add input or output formats. I structured the code knowing that we'd have more and some of the code should be reusable here. Wondering aloud: maybe we always should expect to have multiple output types to accommodate different needs (maybe one format is better for exploration + teaching and another is better for pipelines, etc)?

Please rename the pull request. You're definitely adding an initial conversion functionality, but your also adding documentation and workflow components

Great point, I've renamed to better match up with the changes here.
From @falquaddoomi :

About the docs, first, they look great! That said, it'd be nice to see a README in the docs folder that'd describe what formats you expect people to be able to build, and any prereqs for building the ones you expect. For example, I was able to build the html target just fine, but latexpdf in addition to a LaTeX environment, of course, requires another tool, mermaid, to generate the diagrams.

Thanks, I'll improve things here by being more specific about the output for sphinx. In general I've only been using HTML and will outline things to this effect.

About testing, great to see that there are tests included! As I mentioned in the README comment, it would be nice to see some directions on how to run the tests there. I naively ran pytest in the project root and 4 out of 8 tests failed. Three of them failed due to greenlet not being installed. After installing greenlet, 3 tests are failing I assume due to missing data under the ./tests/data folder. It'd be good to either include the test data, or at least directions to the reader on how to obtain it before running the tests.

Great point, I'll add these details in. I'm not certain how greenlet escaped dependencies, whether in the lock file or otherwise, so I'll do some work here to make certain it gets added to avoid this challenge in the future. Thank you for your flexibility here and for doing the investigation to find the testing environment gap.

@gwaybio - again, thank you for your comments about an S3 test to cover cloudpathlib functionality within this PR. After some thought and investigation of tooling, I landed on adding a test with related fixtures which leverage moto to simulate interactions with S3-like data sources locally. I felt having a realistic and code-based test resource could provide additional testing opportunities for this repo later on. Openly, this covers mostly AWS or S3-like (such as Minio) testing, and not Azure or Google cloud storage options.
My rationale for adding a local simulation was in part inspired by Google's test sizing concepts from Software Engineering at Google, Chapter 11: Test Size. By that reference, the local testing simulation here I think would be "medium" instead of "large" test due to localhost-only calls. I'm interested in pursuing "large" (external call) tests as well and feel we need to address #12 in order to make sure these aren't too large.

Thank you @gwaybio! Responding to your questions:

Would it be a pain to change terminology? I think that specifying "compartment" rather than "target" would be more intuitive for the community.

Not a pain at all, I'll change the language to follow compartment instead of target. Thank you for bringing this up.

I could not confirm 100%, but is this code creating a single parquet file per compartment? What about merging compartments into a single parquet file? Is this going to be a future development?

This code currently focuses on creating a single parquet file per compartment. I wasn't certain when the PR was opened that merging functionality would be included here. Later discussions outside of this PR made it more clear that merging would be desired and I do plan to include the functionality (added #11 to make certain it is addressed). Would you like me to include merge functionality as part of this PR or would it be better to introduce it via a later PR?

I could also not confirm this 100%, but is this code only solving the CellProfiler .csv transform? i.e. the other common output files (e.g. .npz) will be supported in the future? I also imagine that these future enhancements will be a bit easier to add after setting the ground work in this PR?

This code does focus on only CellProfiler csv output transformation. I sought to make the work reusable for other conversion types where possible. I hope to address .npz and others in the future, subject to desired prioritization.

Sounds great! Thanks for your replies - they make sense to me!

Would you like me to include merge functionality as part of this PR or would it be better to introduce it via a later PR?

My vote would be a future PR - this one is already quite large!


Specify LICENSE

Can you clarify which license this code is under? For example, MIT? Preferably by adding a LICENSE file.

Have added MIT license. Thanks


Code Refactoring - cleaning actions (extra)

This branch should provide necessary code changes in order to get more robust core project.

I think it is enough to refactor - because I am getting bored and tired.
Also due to COVID-19 lock down at home - makes me drink a lot :dancers:
Ready to merge to release_v2.0 branch.