Let functions return "impl Iterator" to hide iterator structs

This slims down our public API a little by hiding the concrete type of iterator returned. This will hopefully make the API easier to understand.

Codecov Report

Merging #201 into master will not change coverage.
The diff coverage is 33.33%.

@@           Coverage Diff           @@
##           master     #201   +/-   ##
=======================================
  Coverage   92.44%   92.44%
=======================================
  Files           4        4
  Lines         397      397
=======================================
  Hits          367      367
  Misses         30       30

Impacted Files
Coverage Δ

src/lib.rs
89.53% <33.33%> (ø)

Continue to review full report at Codecov.

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


Implement install_rpm role for all related distros after new Algorand release would be available

For now package manager install for rpm-based systems works only in CentOS 7.x.
https://github.com/algorand/go-algorand/issues/1489#issuecomment-875033099
https://github.com/algorand/go-algorand/commit/01248d28f3ddccedd25888074f4334df6f23b774

All the RedHat-based distros may use a package manager since version 2.8.0 of the Algorand node.


fix: prefix not using global settings

Carbon prefix should be retrieved from the global settings not directly from Carbon.
Changelog
m packages/experimental/src/components/PageHeader/ButtonSetWithOverflow.js
m packages/experimental/src/components/PageHeader/TempComboButton.js

LGTM pending resolution of https://github.com/carbon-design-system/ibm-cloud-cognitive/pull/331/files#r574049066
Additionally, what's the position on using the 'ready to merge' label? If there are multiple reviews on a PR, this will still trigger if one has approved and the other is still pending.

I've tended to add 'ready to merge' when I am happy, but it probably should not merge if there are outstanding change requests or multiple reviews required.


Failed to connect to <IP_ADDRESS>:18333

Ubuntu 16.04
Tryning to run Zap for the first time.

The frontend remains on 0%.
8 lnd processes running without any cpu consume
.lnd/logs/testnet3/bitcoin/lnd.log displays these messages:

2018-02-16 09:30:45.123 [DBG] BTCN: Received addr (1000 addr) from <IP_ADDRESS>:18333 (outbound)
2018-02-16 09:30:45.728 [INF] LNWL: The wallet has been unlocked without a time limit
2018-02-16 09:30:45.729 [INF] LTND: LightningWallet opened
2018-02-16 09:30:45.775 [INF] LNWL: Started rescan from block<PHONE_NUMBER>33ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943 (height 0) for 1 address
2018-02-16 09:30:45.775 [INF] LNWL: Catching up block hashes to height 0, this might take a while
2018-02-16 09:30:45.833 [INF] LNWL: Done catching up block hashes
2018-02-16 09:30:45.834 [INF] LNWL: Finished rescan for 1 address (synced to block<PHONE_NUMBER>33ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943, height 0)
2018-02-16 09:30:45.846 [INF] RPCS: RPC server listening on <IP_ADDRESS>:10009
2018-02-16 09:30:45.846 [INF] LTND: Waiting for chain backend to finish sync, start_height=0
2018-02-16 09:30:45.846 [INF] RPCS: gRPC proxy started at <IP_ADDRESS>:8080
2018-02-16 09:30:47.014 [INF] CMGR: 50 addresses found from DNS seed testnet-seed.bitcoin.schildbach.de
2018-02-16 09:30:47.047 [DBG] CRTR: New graph topology client subscription, client 1
2018-02-16 09:30:49.041 [DBG] CMGR: Attempting to connect to <IP_ADDRESS>:18333 (reqid 2)
2018-02-16 09:30:49.041 [DBG] CMGR: Failed to connect to <IP_ADDRESS>:18333 (reqid 2): dial tcp <IP_ADDRESS>:18333: getsockopt: connection refused
2018-02-16 09:30:49.041 [DBG] CMGR: Retrying connection to <IP_ADDRESS>:18333 (reqid 2) in 10s

Failed to connect to <IP_ADDRESS>:18333 is not a bug, it is just checking for a full node that supports neutrino on your local machine.
Received addr (1000 addr) from <IP_ADDRESS>:18333 means you established a connection with <IP_ADDRESS>, which is my full node. I know recently there were some funky issues on testnet, I reset my node and things should be resolved. Are you still facing issues? Going to close this for now


Please consider fixing issues detected by repository checker

Notification from ioBroker Check and Service Bot
Dear adapter developer,
I'm the ioBroker Check and Service Bot. I'm an automated tool processing routine tasks for the ioBroker infrastructure. I have recently checked the repository for your adapter parcel for common errors and appropiate suggestions to keep this adapter up to date.
This check is based the current head revisions (master / main  branch) of the adapter repository
Please see the result of the check below.
ioBroker.parcel
   -
ERRORS:

[ ] :heavy_exclamation_mark: [E026] "{'engines': {'node'>='16'}}" is required at package.json, "{'engines':{'node'>='18'}}" is recommened
[ ] :heavy_exclamation_mark: [E162] js-controller 3.2.0 listed as dependency but 4.0.24 is required as minimum, 5.0.19 is recommended. Please update dependency at io-package.json.
[ ] :heavy_exclamation_mark: [E204] Version "0.2.8-beta.0" listed at common.news at io-package.json does not exist at NPM. Please remove from news section.
[ ] :heavy_exclamation_mark: [E851] .npmignore found but "files" is used at package.json. Please remove .npmignore.

WARNINGS:

[ ] :eyes: [W040] "keywords" within package.json should contain "ioBroker"
[ ] :eyes: [W105] Missing suggested translation into uk of "common.titleLang" in io-package.json.
[ ] :eyes: [W109] Missing suggested translation into uk of "common.desc" in io-package.json.
[ ] :eyes: [W115] "common.tier" is required in io-package.json. Please check https://github.com/ioBroker/ioBroker.docs/blob/master/docs/en/dev/objectsschema.md#adapter.
[ ] :eyes: [W145] Missing suggested translation into ru,pt,nl,fr,it,es,pl,uk,zh-cn of some "common.news" in io-package.json.
[ ] :eyes: [W181] "common.license" in io-package.json is deprecated. Please define object "common.licenseInformation"
[ ] :eyes: [W184] "common.main" is deprecated and ignored. Please remove from io-package.json. Use "main" at package.json instead.
[ ] :eyes: [W184] "common.materialize" is deprecated for admin >= 5 at io-package.json. Please use property "adminUI".
[ ] :eyes: [W184] "common.title" is deprecated and replaced by "common.titleLang". Please remove from io-package.json.
[ ] :eyes: [W202] Version of package.json (0.2.8-beta.0) doesn't match latest version on NPM (0.2.7)

SUGGESTIONS:

[ ] :pushpin: [S522] Please consider migrating to admin 5 UI (jsonConfig).

Please review issues reported and consider fixing them as soon as appropiate.
Errors reported by repository checker should be fixed as soon as possible. Some of them require a new release to be considered as fixed. Please note that errors reported by checker might be considered as blocking point for future updates at stable repository.
Warnings reported by repository checker should be reviewed. While some warnings can be ignored due to good reasons or a dedicated decision of the developer, most warnings should be fixed as soon as appropiate.
Suggestions reported by repository checker should be reviewed. Suggestions can be ignored due to a decision of the developer but they are reported as a hint to use a configuration which might get required in future or at least is used be most adapters. Suggestions are always optional to follow.
You may start a new check or force the creation of a new issue at any time by adding the following comment to this issue:
@iobroker-bot recheck
@iobroker-bot recreate
Please note that I (and the server at GitHub) have always plenty of work to do. So it may last up to 30 minutes until you see a reaction. I will drop a comment here as soon as I start processing.
Feel free to contact me (@iobroker-bot) if you have any questions or feel that an issue is incorrectly flagged.
And THANKS A LOT for maintaining this adapter from me and all users.
Let's work together for the best user experience.
your
ioBroker Check and Service Bot
@mcm1957 for evidence
Last update at Wed, 11 Sep 2024 04:28:09 GMT

Issue outdated due to RECREATE request. Follow up issue #83 has been created.
This issue will be closed.
your
ioBroker Check and Service Bot


Typos on https://nhsconnect.github.io/FHIR-NOO-API/development_security_jwt.html

"Consumer systems SHALL provided audit" should be "Consumer systems SHALL provide audit"
"In the interrim however" should be "In the interim however"

Corrections made. Legacy from CC.


Matrix-math example - no world named matrix-math in package

Following the matrix-math example in fa666b9c16e3f46ae4f77372add5f59443fe65eb, I receive the following error:
componentize-py --wit-path src/componentize-py-fa666b9/wit --world matrix-math componentize app -o matrix-math.wasm
Traceback (most recent call last):
  File "/usr/local/bin/componentize-py", line 8, in <module>
    sys.exit(script())
AssertionError: no world named `matrix-math` in package

I attempted to fully qualify the world using its package name, but that didn't help:
componentize-py --wit-path src/componentize-py-fa666b9/wit --world "componentize-py:init/matrix-math" componentize app -o matrix-math.wasm
Traceback (most recent call last):
  File "/usr/local/bin/componentize-py", line 8, in <module>
    sys.exit(script())
AssertionError: unknown package `componentize-py:init`

I'm running the example inside a python:3.10.14-slim container.

Thanks for reporting this, @k-mack.  I'm having trouble reproducing it, though.  Here's what I did:
docker run --rm -it --entrypoint bash python:3.10.14-slim
pip install componentize-py
apt-get update
apt-get install -y git curl
git clone https://github.com/bytecodealliance/componentize-py
cd componentize-py/examples/matrix-math/
curl -OL https://github.com/dicej/wasi-wheels/releases/download/v0.0.1/numpy-wasi.tar.gz
tar xf numpy-wasi.tar.gz
componentize-py -d ../../wit -w matrix-math componentize app -o matrix-math.wasm

That worked for me.  Would you mind sharing the exact commands you're using?

Interesting. Your sequence of commands worked for me. There are a couple of differences in what I'm doing, but I'm not sure what's erroneous about it.
Here's the Dockerfile I use to create the image:
# Dockerfile.wasm-component
FROM python:3.10.14-slim

WORKDIR /workspace

# Deps
RUN apt-get update && apt-get install -y curl xz-utils zip && \
    curl -LO https://github.com/bytecodealliance/wasmtime/releases/download/v19.0.2/wasmtime-v19.0.2-x86_64-linux.tar.xz && \
    tar --xz -xf wasmtime-v19.0.2-x86_64-linux.tar.xz && mv wasmtime-v19.0.2-x86_64-linux wasmtime && \
    pip install componentize-py==0.13.3 && \
    curl -OL https://github.com/dicej/wasi-wheels/releases/download/v0.0.1/numpy-wasi.tar.gz && \
    tar -xf numpy-wasi.tar.gz

# Componentize-py src
RUN curl -LO https://github.com/bytecodealliance/componentize-py/archive/fa666b9c16e3f46ae4f77372add5f59443fe65eb.zip && \
    unzip -d src fa666b9c16e3f46ae4f77372add5f59443fe65eb.zip && \
    mv src/componentize-py-fa666b9c16e3f46ae4f77372add5f59443fe65eb src/componentize-py-fa666b9 && \
    cp src/componentize-py-fa666b9/examples/matrix-math/app.py .

Build the image, run the container, and run componentize-py:
docker build -t componentize-py:test -f Dockerfile.wasm-component
docker run --rm -it componentize-py:test /bin/bash
componentize-py --wit-path src/componentize-py-fa666b9/wit --world matrix-math componentize app -o matrix-math.wasm

The matrix-math world is in the wit path:
cat src/componentize-py-fa666b9/wit/matrix-math.wit
world matrix-math {
  include<EMAIL_ADDRESS>
  export multiply: func(a: list<list<float64>>, b: list<list<float64>>) -> result<list<list<float64>>, string>;
}

Okay, I figured it out.  The problem is due to a combination of factors:

componentize-py uses the current working directory as the Python path (i.e. the directory under which to search for the application code and any of its dependencies)
When generating a component, it searches the Python path (and all its subdirectories) for componentize-py.toml files, and if it finds any it uses them to locate WIT files
The componentize-py source code contains a couple of componentize-py.toml files for testing, so when you unzip the source tree into a subdirectory of the current directory, it finds those files and tries to use them

You can avoid the above by removing the directory containing the test componentize-py.toml files, e.g. rm -r src/componentize-py-fa666b9/src/test prior to running the componentize subcommand.
There's currently a lot of implicit behavior in the componentize-py CLI, leading to subtle issues like this.  The motivation is to make it "do what you mean" most of the time, but sometimes it backfires.  I'm open to suggestions about how to improve it and make it less surprising, while still making it do the right thing with minimal input.

Thanks, @dicej! I'll have to play around with componentize-py.toml files to get a better feel for the tool, and I'll contribute back any suggestions I may have along the way. I was able to componentize some Python code, transpile it with jco, and run it in the browser, which feels pretty good. Thanks again for your quick help.


Release process

I'm adding a release process using goreleaser

[x] release taking VERSION from file as required by #3
[x] snapshot releases
[x] release binaries for linux, mac, windows (amd64 and arm64)
[x] automatic releases on VERSION file changes via GHA
[x] release docker image within the same release

Fixes #3

This is ready for review, I already did a release against this branch that will be on master once we merge this.
The release is based on the VERSION file and happened on GHA via this run https://github.com/seqeralabs/staticreg/actions/runs/10113904210/job/27971293225?pr=5.
At each PR we also build artifacts and publish them temporarly on the action so we can test them. See here for example.
For everyone's preview, the release of 0.1.0 created

A release page with all its artifacts for Windows, Linux, MacOS (x86 and arm64)
Published the multi arch container image: docker pull public.cr.seqera.io/seqeralabs/staticreg:0.1.0

Thanks for the review @alberto-miranda !


Getting The package<EMAIL_ADDRESS>does not satisfy its siblings' peerDependencies requirements!

Getting The package<EMAIL_ADDRESS>does not satisfy its siblings' peerDependencies requirements! while trying to install...

Hi, use https://github.com/morocarlo/ng2-my-datepicker


Depth anything in Python

Question
Amazing demo for the depth-anything!
I want to have a similar point cloud, but in Python, and wondering what's the logic behind your js implementation.
Specifically:

How do you set up the intrinsic matrix and backproject the depth map and color to the 3D space?
What is the difference between Xenova/depth-anything-small-hf and LiheYoung/depth-anything-small-hf?

Fortunately three.js handles all the complicated 3D scene management for me. All the logic can be found in the setupScene function here. If you want to achieve something similar, you can use the gradio 3D model component. You will need to convert the depth image to a glb trimesh (see example code here).
As stated in the README of Xenova/depth-anything-small-hf, it is the same as LiheYoung/depth-anything-small-hf, but with ONNX weights to be compatible with transformers.js (so it can run in the browser).


Tool Fails for FF when Multiple DTCs are Present

Tool fails FF when there is more than 1 DTC present, it appears the tool expected equal number of FF to DTCs. However this isn't required: 1971.1 (h)(4.3.3) - (4.3.3) Only one frame of data is required to be recorded. Manufacturers may choose to store additional frames provided that at least the required frame can be read by a scan tool meeting SAE J1978
18:16:50.1241 Destination Specific DM25 Request to Exhaust Emission Controller (61)
18:16:50.1276 18EA3DF9 [3] B7 FD 00 (TX)
18:16:50.5156 18FDB73D [131] 82 A9 F0 F0 01 14 02 00 00 00 00 00 07 00 00 00 3B 32 C7 3D 50 01 FD 00 50 23 8A 24 00 00 00 16 00 00 7D 7D 80 51 80 25 00 32 A0 42 BD B3 E0 E1 D2 F2 05 00 00 00 64 00 64 00 64 00 64 00 64 00 64 00 64 9B 24 D4 00 00 88 23 32 70 94 34 60 28 54 25 E8 27 00 00 00 00 DA 03 32 00 00 00 00 00 00 00 01 07 3A 02 00 0D 74 23 00 00 60 28 E8 27 35 03 00 00 00 00 00 00 1E 01 98 1E 04 FF FF 00 00 EF 03
DM25 from Exhaust Emission Controller (61):
Freeze Frames: [
Freeze Frame: {
DTC 520361:16 - Manufacturer Assignable SPN, Data Valid But Above Normal Operating Range - Moderately Severe Level - 1 times
SPN Data: 14 02 00 00 00 00 00 07 00 00 00 3B 32 C7 3D 50 01 FD 00 50 23 8A 24 00 00 00 16 00 00 7D 7D 80 51 80 25 00 32 A0 42 BD B3 E0 E1 D2 F2 05 00 00 00 64 00 64 00 64 00 64 00 64 00 64 00 64 9B 24 D4 00 00 88 23 32 70 94 34 60 28 54 25 E8 27 00 00 00 00 DA 03 32 00 00 00 00 00 00 00 01 07 3A 02 00 0D 74 23 00 00 60 28 E8 27 35 03 00 00 00 00 00 00 1E 01 98 1E 04 FF FF 00 00 EF 03
}
]
FAIL: <IP_ADDRESS>.b - Exhaust Emission Controller (61) did not reported DTC in Freeze Frame data which included the DTC provided by DM23 earlier in this part
From previous DM23:
18:16:43.7720 Destination Specific DM23 Request to Exhaust Emission Controller (61)
18:16:43.7751 18EA3DF9 [3] B5 FD 00 (TX)
18:16:43.8171 18FDB53D [10] 03 FF A9 F0 F0 01 A9 F0 E2 01
DM23 from Exhaust Emission Controller (61): MIL: off, RSL: off, AWL: off, PL: not supported
DTC 520361:16 - Manufacturer Assignable SPN, Data Valid But Above Normal Operating Range - Moderately Severe Level - 1 times
DTC 520361:2 - Manufacturer Assignable SPN, Data Erratic, Intermittent Or Incorrect - 1 times

The test procedure says implant 1 DTC and not 2.  (For both Fault A and Fault B)
Which DTC of the two provided in the DM23 is to be expected in the FF?
How is the tool supposed to know?
The tool will reliably find 1 DTC in a list of FFs.
SAE J1979-73 capabilities are the test subject not J1978 capabilities
Indeed 13 CCR 1971.1 (d) and (h) are bifurcated by J1979 and J1939.
Is it not possible to implant just one fault?

Future implant methods will elicit a single DTC in the future


Flutter-module->signin screen

@dragoonoid Would you like to work on this issue?

@dragoonoid Would you like to work on this issue?

yes i would like to add the auth part in flutter.

I'm assigning SignIn page to you. Although the proper authentication functionality is not required. You can still add it if you like. SignUp page is already assigned so no need to develop that. You are good to go. Don't forget to follow the README guidelines.

I'm assigning SignIn page to you. Although the proper authentication functionality is not required. You can still add it if you like. SignUp page is already assigned so no need to develop that. You are good to go. Don't forget to follow the README guidelines.

So i just have to implement the sign in screen? Not the signup and reset password one?

You can implement the reset password but not signup because it's already assigned.

You can implement the reset password but not signup because it's already assigned.

Ok,thanks.


Fixed

Now If Someone gives a wrong type to the write func An Error is raised

This PR was invalid. Correct PR has been made. Closing this PR.


v10.2.37 settings change: 5 game results per page

Current coverage is 95.46%

Merging #219 into master will not affect coverage as of a50a662

@@            master    #219   diff @@
======================================
  Files           26      26
  Stmts          375     375
  Branches         0       0
  Methods         83      83
======================================
  Hit            358     358
  Partial          0       0
  Missed          17      17

Review entire Coverage Diff as of a50a662

Powered by Codecov. Updated on successful CI builds.


[CSL-509] Add update-system part to block creation code

@gromak

@gromak
Well, actually, this part is less trivial than I expected. Some logic is needed here:

Find suitable proposal among local proposals. Suitable means that it should have positive votes from enough stake. Currently we will find it using linear search, but it can optimized by having some index. I will create an issue about this possible optimization.
We must check epoch in MemState of US, because it determines validity.
When we have more than one suitable proposal, we need some rules to pick one of them. I suppose it makes sense to let user set some rules. However, I suppose now it's not needed and we can pick random proposal. However, I will create an issue about it for future.


Add streaming API for tasks

- What I did
As documented in moby/moby#37997, if there are too many tasks, then attempting to list them all may cause the size of the response to exceed the gRPC max message size.
To avoid this case, introduct a ListTasksStream endpoint, which uses the gRPC streaming API to send tasks as a stream, avoiding exceeding the max message size.
- How I did it
Adds a new RPC to the ControlAPI server called ListTasksStream, which returns tasks as a stream instead of as one giant response.
- How to test it
Includes automated test.

Given that this changes the API; is this still a candidate for backporting to the 18.09 codebase? (maybe yes, maybe no, just leaving this here as I think of it now 😄 )

@thaJeztah: it actually doesn't change the public API of the docker engine. it changes the swarmkit API, but that API is more-or-less nonpublic, especially as far as the engine is concerned. you'll see in a bit, i'm running tests on the moby/moby branch right now before i push up that pull request.

@thaJeztah: it actually doesn't change the public API of the docker engine. it changes the swarmkit API, but that API is more-or-less nonpublic, especially as far as the engine is concerned. you'll see in a bit, i'm running tests on the moby/moby branch right now before i push up that pull request.

ping @dperny looks like this needs a rebase


Add gRPC api for pod start

ref #278 start api

@YaoZengzeng Pls rebase and complete the test as @resouer figured out.

LGTM


Clean up JS

Current coverage is 46.58%

Merging #307 into master will not affect coverage as of 1cdb73d

@@            master    #307   diff @@
======================================
  Files           89      89
  Stmts         3330    3330
  Branches       301     301
  Methods          0       0
======================================
  Hit           1551    1551
  Partial         27      27
  Missed        1752    1752

Review entire Coverage Diff

Powered by Codecov


Fixed broken 'spo list webhook add' tests

Fixed broken 'spo list webhook add' tests

Coverage remained the same at 100.0% when pulling 999813810a6ed14e5f7ee773bfb298ebd55bbbaf on waldekmastykarz:fix-tests into<PHONE_NUMBER>8c5e5d70cb505e8ad390921a7c474e on pnp:dev.

Merged manually.


Fix(LLMLingua): fix the force context ids and condition flag

fix the force context ids and condition flag.

fix #58 bug.


Coverage format documentation not explicitly stating 'end' meaning

I was reading https://github.com/gotwarlost/istanbul/blob/master/coverage.json.md#location-objects
and I noticed it doesn't mention whether the end has to be considered included or excluded from the range.
Can you please clarify?

I understand it's not


gps sync and gps rr should exit with failure if trying to sync or rr an already integrated patch

Don't know why people would do this. But we should protect against as we don't want to support any workflows on integrated patches other than gps pull to collapse them out of the stack.

I haven't heard anything about the need for this since the project start really. So I am closing the issue. If it becomes a need we can reopen.


Change rdfs:label to dct:description for representation of potenitally long texts

Problem statement
rdfs:label is used for potentially long texts where dct:description might be a better fit.
Note that there was a Dublin Core usage guideline for using rdfs:label in 2002, but was deprecated in 2008 in favor of rdf:value.
Example from Provenance Statement:
[] a dct:ProvenanceStatement ;
  rdfs:label """
    The raster data sets have been created out of the Noise Spatial Database,
    which in turn contains all versions delivered by the relevant countries
    (EU and EFTA) to Reportnet (CDR). The data from Reportnet is automatically
    incorporated into the database, with the exception of those data sets which
    require a manual review (due to problems with naming conventions or
    Coordinate Reference System). The data set covers any submission by the
    countries until 01/01/2019.
  """@en .

The places where rdfs:label mappings are used for potentially long texts:

Rights statement text
Provenance statement text
License text - to be removed in #113

Proposal
Change the mappings to dct:description.

Approved during the webinar.


UHF-3479: Installed read only role.

Waiting for updated Helfi TPR module and Helfi platform config module.

This was merged in Drupal core 9.3.0 update PR.


StackOverflowException with the file

Thrown exception when parse with html by URL:
https://otto-git.github.io/all-contact-data/bugurl.html

Hello @otto-git ,
The v1.11.46 has been released.
The parsing is slow, but it now works.
Best Regards,

Is this library useful to you? Please help us by becoming a sponsor to keep it alive and supported.

Thanks. It's working


runtime error: invalid memory address or nil pointer dereference

An error occurred in the Ingress controller when I added the Ingress configuration:
[root@k8s-master ~]# kubectl logs -f ingress-controller-5587c86b49-5kz82 -n cloud
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x104bf0f]

goroutine 131 [running]:
github.com/gxthrj/seven/apisix.(*Route).convert(0xc000457c80, 0x0, 0x0, 0x1f045f8, 0xc0002e2390, 0x0)
        /go/pkg/mod/github.com/gxthrj/seven@v0.1.9/apisix/route.go:152 +0x1cf
github.com/gxthrj/seven/apisix.ListRoute(0x0, 0x0, 0x15c0580, 0xc0004c1150, 0x8, 0x10, 0xc0004c1120)
        /go/pkg/mod/github.com/gxthrj/seven@v0.1.9/apisix/route.go:54 +0x3c2
github.com/gxthrj/seven/apisix.FindCurrentRoute(0xc00024dc00, 0x13, 0xc0004c1120, 0x0)
        /go/pkg/mod/github.com/gxthrj/seven@v0.1.9/apisix/route.go:22 +0xe5
github.com/gxthrj/seven/state.(*routeWorker).trigger(0xc000401e60, 0x13f2fe9, 0x7, 0x13f269c, 0x6, 0x1274d40, 0xc0000ba550, 0x0, 0x0)
        /go/pkg/mod/github.com/gxthrj/seven@v0.1.9/state/builder.go:92 +0x1dd
github.com/gxthrj/seven/state.(*routeWorker).start.func1(0xc000401e60)
        /go/pkg/mod/github.com/gxthrj/seven@v0.1.9/state/route_worker.go:21 +0x8a
created by github.com/gxthrj/seven/state.(*routeWorker).start
        /go/pkg/mod/github.com/gxthrj/seven@v0.1.9/state/route_worker.go:17 +0x6c

ingress configuration:
kubectl apply -f - <<EOF
apiVersion: apisix.apache.org/v1
kind: ApisixRoute
metadata:
  name: foo-bar

spec:
  rules:
  - host: foo.bar
    http:
      paths:
      - backend:
          serviceName: http-svc
          servicePort: 80
        path: /
EOF

K8S Service:   I think the service is all right
[root@k8s-master eplat-yamls]# kubectl get svc -o wide --show-labels
NAME           TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)                         AGE     SELECTOR        LABELS
apisix-gw-lb   NodePort    <IP_ADDRESS>   <none>        9080:31700/TCP,9443:30905/TCP   20h     app=apisix-gw   app=apisix-gw
http-svc       NodePort    <IP_ADDRESS>   <none>        80:31562/TCP                    93m     app=http-svc    app=http-svc
kubernetes     ClusterIP   <IP_ADDRESS>      <none>        443/TCP                         3d17h   <none>          component=apiserver,provider=kubernetes

[root@k8s-master eplat-yamls]# curl http://<IP_ADDRESS> -H Host:foo.bar

Hostname: http-svc-674f6fb5b5-gmh9m

Pod Information:
        node name:      k8s-node1
        pod name:       http-svc-674f6fb5b5-gmh9m
        pod namespace:  default
        pod IP: <IP_ADDRESS>

Server values:
        server_version=nginx: 1.13.3 - lua: 10008

Request Information:
        client_address=<IP_ADDRESS>
        method=GET
        real path=/
        query=
        request_version=1.1
        request_scheme=http
        request_uri=http://foo.bar:8080/

Request Headers:
        accept=*/*
        host=foo.bar
        user-agent=curl/7.29.0

Request Body:
        -no body in request-

**cloud.yaml: **

Maybe the cloud.yaml need modify, Because the etcd is a pod on the master node and must use https to connect it, It's possible the ingress controller not got data

Because the etcd is a pod on the master node ,so i  don't know the ETCD_SERVER_INTERNAL  what to put in here
apiVersion: v1
kind: ConfigMap
metadata:
  name: cloud-config
  namespace: cloud
data:
  ETCD_SERVER_INTERNAL: '["http://<IP_ADDRESS>:2379"]'
  SYSLOG_HOST: <IP_ADDRESS>
  APISIX_BASE_URL: "http://<IP_ADDRESS>:31700/apisix/admin/route/apisix/admin"
  ENV: "prod"

it seemed that your apisix has already defined routes before,and the desc is nil
two  solutions:

if the data is not important, you can remove all routes, and use CRD defined only;
2.or you can add desc field with CRD rules: host + path;

Duplicated with #14 .

Solved since #9 merged.


WebUI is broken when final result's type is tensor

Short summary about the issue/question:
"finalMetricData":[
            {
                "data":"{\"__instance_type__\":[\"torch\",\"Tensor\"],\"attributes\":{}}",
                "parameterId":"3",
                "sequence":0,
                "timestamp":1578029488459,
                "trialJobId":"t9wYQ",
                "type":"FINAL"
            }
        ],

Brief what process you are following:

How to reproduce it:

nni Environment:

nni version:
nni mode(local|pai|remote):
OS:
python version:
is conda or virtualenv used?:
is running in docker?:

need to update document(yes/no):
Anything else we need to know:

WebUI doesn't support the final result's type is tensor at present. Please return the final result type as {default: string} or {default: dict}.

WebUI doesn't support the final result's type is tensor at present. Please return the final result type as {default: string} or {default: dict}.
And the broken page by final tensor type we'll fix soon.

@lvybriage - any work left for this issue? may we close it now?


Add Geometry to a body within the GUI via scripting: share example

@aymanhab just brought this up in the dev meeting today. This would be a way to ease into model building.

Although this is marked as future release adding a Body via XML has become more challenging (@carmichaelong and others) so we need a way to add a Body, PhysicalOffestFrame, and Joint easily. One way to do that is via scripting.
I was able to use this to add to leg6fog9musc repeatedly without any issues or failures.
AddPhysicalOffsetFrame.py.txt
@aymanhab you might want to use it in testing and @jimmyDunne please use this as a basis for updating the "model editing" tutorial and feel free to change it to make it more user friendly.

Moving this to the 4.0 example so we have a way to track the update to the example.

Based on workshop plans, should we include this script in the distribution? @jenhicks @jimmyDunne @aseth1

Issue moved to opensim-org/opensim-core #2144 via ZenHub

Since the script should live with the GUI Scripts, I think the issue should reside here.


180 degrees partial panorama

Hi,
I need to show a 180 degrees panorama.
So I tried to use haov parameter (see below excerpt).
I would have expected that pan operation stop when reaching panorama image edges, but it continues showing black background. So I tried to use avoidShowingBackground parameter, but apparently without useful results (it continues to show black background, but apparently it zooms in the original image).
Is it possible to show partial panoramas with the pan stopping when reaching image edges?
thanks,
Alex
viewer = pannellum.viewer('panorama',{
"panorama": "sala3.jpg",
"vaov": 60,
"hfov": 50,
"haov": 180,
"avoidShowingBackground": true,
"maxHfov": 180,
"autoLoad": true,
"minPitch" : -10,
"maxPitch" : 10,
"multiResMinHfov" : true,
"maxHfov" : 70,
"horizonPitch" : 0,
"mouseZoom" : false,
//"showControls": false,
"hotSpotDebug": true,
"hotSpots": [

Problem solved setting:
"minYaw": -90,
"maxYaw": 90,


Trait properties aren't supported

trait MyTrait  {
    Long propertyA
}

class MyClass implements MyTrait {
    String propertyB;

    static search = {
      propertyA  index: 'yes' // property not found => not added to index
      propertyB  index: 'yes' // added to index
    }
}

```

Fixed in #25


v-memo doesn't work with v-for

Version
3.2.0-beta.7
Reproduction link
Vue SFC Playground
Steps to reproduce
click inc button
What is expected?
<Item />  should not re-render unless value of count is greater than 4, similar to div above
What is actually happening?
v-memo with v-for doesn't work at all and <Item /> re-renders each time count value is incremented.

What are you actually trying to achieve? Why would you use something that isn't used in the v-for in the v-memo. How are you checking that elements are updated in your current repro?

I don't use it in my project (yet) I was just testing this feature in the playground and noticed it doesn't work with v-for, that's it. Other example. Shouldn't it always render count: 0 within the list? basically act like v-once?
  <div v-for="(id, index) in 3" :key="id" v-memo="[true]">
   count: {{ count }}
  </div>

I don't think v-memo is supposed to work like v-once. Since you are passing :count="count", the component still needs to update. Take a look at this example without count, only the items changing are updating, while the rest (9998 elements) are not touched. I'm still confused though as using v-memo or not doesn't change the outcome...

your example is also broken
in my example memo value doesn't change (v-memo="[true]") so why is text updated when the count value changes? :/
from the docs:

If every value in the array was the same as last render, then updates for the entire sub-tree will be skipped. For example:

your example is also broken
from the docs:

The directive expects a fixed-length array of dependency values to compare for the memoization. If every value in the array was the same as last render, then updates for the entire sub-tree will be skipped

in my example memo value doesn't change (v-memo="[true]") so why is text updated when the count value changes? :/

you added count back 😆
I'm also confused, this seems like a bug

this seem to be a problem with iterating over a number
 v-for="(id, index) in 3"

if you iterate over array the v-memo seem to work
 v-for="(id, index) in items"

https://sfc.vuejs.org/#eyJBcHAudnVlIjoiPHRlbXBsYXRlPlxuICA8YnV0dG9uIEBjbGljaz1cImNvdW50KytcIj5cbiAgICBpbmMge3sgY291bnQgfX1cbiAgPC9idXR0b24+XG4gIFxuXG4gIFxuICA8SXRlbSBcbiAgICAgdi1mb3I9XCIoaWQsIGluZGV4KSBpbiBpdGVtc1wiIDpjb3VudD1cImNvdW50XCIgOmluZGV4PVwiaW5kZXhcIlxuICAgICA6a2V5PVwiaWRcIlxuICAgICB2LW1lbW89XCJbY291bnQgPCAzID8gdHJ1ZSA6IGNvdW50XVwiXG4gICAvPlxuICBcbjwvdGVtcGxhdGU+XG5cbjxzY3JpcHQgc2V0dXA+XG4gIGltcG9ydCB7IHJlZiB9IGZyb20gJ3Z1ZScgXG4gIGltcG9ydCBJdGVtIGZyb20gXCIuL0l0ZW0udnVlXCJcbiAgdmFyIGl0ZW1zID0gWzEsMiwzXVxuICBjb25zdCBjb3VudCA9IHJlZigwKVxuXG48L3NjcmlwdD4iLCJJdGVtLnZ1ZSI6Ijx0ZW1wbGF0ZT5cbjxwcmU+e3twcm9wc319PC9wcmU+XG48L3RlbXBsYXRlPlxuPHNjcmlwdCBzZXR1cD5cblxuICB2YXIgcHJvcHMgPSBkZWZpbmVQcm9wcyhbJ2NvdW50JywnaW5kZXgnXSlcbjwvc2NyaXB0PiJ9

oh good catch 😂

some what related issue  https://github.com/vuejs/vue-next/issues/4253


Adjust printing to take into account special DeclNames

Print DeclBaseNames using a new userFacingStr() method to prepare for
DeclBaseNames that are not backed by Identifiers
This includes the changes from #9975, #9976, #9977, #9978, #9978

Please test with following pull request:
apple/swift-lldb#206
@swift-ci Please test

@jrose-apple I renamed userFacingStr to userFacingName and took care of your other comments. Could you maybe another look through?
@swift-ci please test

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit -<PHONE_NUMBER>1cfef4d245b784f33f127e7aa2f6c6
Test requested by - @ahoppen

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit -<PHONE_NUMBER>1cfef4d245b784f33f127e7aa2f6c6
Test requested by - @ahoppen

@swift-ci Please test

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - ac44647744f7add5b65f828a337f8157aa9f4073
Test requested by - @ahoppen

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - ac44647744f7add5b65f828a337f8157aa9f4073
Test requested by - @ahoppen

@swift-ci Please test

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 638bf80a69ac98c7ee0d293d4591cb9d4efeb4a3
Test requested by - @ahoppen

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - 638bf80a69ac98c7ee0d293d4591cb9d4efeb4a3
Test requested by - @ahoppen

macOS failure seemed unrelated. Let's try again
@swift-ci Please test OS X Platform

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 949968a1828c8398c32925bb5e1fa86e2441d37c
Test requested by - @ahoppen

Unrelated failure seems to have been resolved in #10567
@swift-ci Please test OS X Platform


Perhaps there is an error. Invalid parameter.

I do not know for sure. But please check.
I have looked at this method (https://developers.navixy.com/backend-api/resources/field_service/employee/avatar/#upload). Contains required parameters (employee_id, file). After I looked at this method (https://developers.navixy.com/backend-api/resources/fleet/vehicle/avatar/#upload). This method updates the "Vehicle" avatar, but the required parameters (tag_id, file).
I also noticed that the documentation says "Uploads avatar image for specified vehicle.".

Thank you!


Stripping required spaces

#Input:
border-color: color(#111111 l(-5%)) color(#111111 l(-5%)) color(#111111 l(-15%));

#Output:
border-color: rgb(5, 5, 5)rgb(5, 5, 5)rgb(0, 0, 0);

I can repro this in the UI Next playground. I also see this with the webpack CSS Loader and minification disabled.

Can be fixed with postcss-value-parser. @studiosciences Can you send pr?

I'll take a look, but I'm not so sure this will fall within my area of expertise.

@TrySound I wrote a couple of tests and the parser and stringifier didn't have issues. It detected the space between the functions as a node and retained it when stringified. So I'm back to looking at this plugin.

@TrySound ah, I for some reason thought this was an issue with postcss-value-parser, rather than could be fixed by using it instead of balanced-match.
I'll try a quicker fix first. Using postcss-value-parser seems like a fix from someone else.

@studiosciences Which exactly issue?

Closed by #27


removing che-rest-api-sidecar

What does this PR do?
Removes Che Rest API sidecar
What issues does this PR fix or reference?
https://github.com/devfile/devworkspace-operator/issues/288
Is it tested? How?

This is an internal refactor. Ran unit tests

/ok-to-test

/test v5-devworkspaces-operator-e2e

/test v5-devworkspaces-operator-e2e


added IIFE support

Thanks for the PR!
I would be happy to merge once a few items are taken care of:

Add some tests cases to test/lib/rules/strict-newline.js. I think adding a case with a IIFE passing and one failing should be enough.
Run npm test and ensure it passes. The coverage report should also show 100% coverage.
Squash commits into one

If you have any questions I will be glad to answer.

Coverage remained the same at 100.0% when pulling 9f2a232deb840fc71ac9b64a752ebabcbc6a444c on arnochauveau:master into 2a9baf837c57629511c76560335320c34d22ef71 on MitMaro:master.

There you go!

Coverage remained the same at 100.0% when pulling 9f2a232deb840fc71ac9b64a752ebabcbc6a444c on arnochauveau:master into 2a9baf837c57629511c76560335320c34d22ef71 on MitMaro:master.

Looks good! I'll merge and publish later today. Thanks!

Published to NPM. Thanks again for the addition!


NLDI Moving to api.water.usgs.gov -- aggregator issue.

We'll use this issue to track things we find not working and spawn additional issues to work through them.

https://labs.waterdata.usgs.gov/api/nldi/linked-data/hydrolocation?f=json&coords=POINT(-89.276%2042.988) (works)
https://api.water.usgs.gov/nldi/linked-data/hydrolocation?f=json&coords=POINT(-89.276%2042.988) (403)

>   point <- sf::st_sfc(sf::st_point(x = c(-89.2158, 42.9561)), crs = 4326)
>   trace <- get_raindrop_trace(point, direction = "up")
https://api.water.usgs.gov/nldi/pygeoapi/processes/nldi-flowtrace/execution

{
  "inputs": [
    {
      "id": "lat",
      "type": "text/plain",
      "value": "42.9561"
    },
    {
      "id": "lon",
      "type": "text/plain",
      "value": "-89.2158"
    },
    {
      "id": "raindroptrace",
      "type": "text/plain",
      "value": "true"
    },
    {
      "id": "direction",
      "type": "text/plain",
      "value": "up"
    }
  ]
}
Request failed [403]. Retrying in 1.5 seconds...
Request failed [403]. Retrying in 1 seconds...
Error calling processing service.
 Original error:
Error in doTryCatch(return(expr), name, parentenv, handler): <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>

403 ERROR

The request could not be satisfied.

This distribution is not configured to allow the HTTP request method that was used for this request. The distribution supports only cachable requests.
We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.

If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.

Generated by cloudfront (CloudFront)
Request ID: I1GgEEYJAs3SKt1nWQG4_OpMjyaRoCGSwQDjfB6C2JtotxnFf-NpSg==

<ADDRESS>
</ADDRESS>

These issues seem to all have been resolved. Will close for now.


[W][api.connection:068]: <IP_ADDRESS>: Socket operation failed: BAD_INDICATOR errno=11

Hello,
i have a problem to transmit data from the ESP to the Iobroker.
I use a Nodemcu.
I get on the ESP the meassage [W][api.connection:068]: <IP_ADDRESS>: Socket operation failed: BAD_INDICATOR errno=11
And on the Iobroker `
| 2022-08-25 15:18:57.104 | warn | Client <IP_ADDRESS> Timeout, connection Lost, will reconnect automatically when device is available!
esphome.0 | 2022-08-25 15:18:52.124 | error | ESPHome client <IP_ADDRESS> Error: Bad format. Expected 0 at the begin
Versions:

Adapter version: 0.2.4
JS-Controller version: 4.0.23
Node version: v16.16.0
Operating system: bullseye

Thanks in Advance,
Armin

See: https://github.com/DrozmotiX/ioBroker.esphome/issues/155, https://github.com/DrozmotiX/ioBroker.esphome/issues/152


[WIP] inserted record can be returned from query

Fixes #572
Problem
When inserting records only one column can be returned via RETURNING clause. There are several use cases of database generated values besides IDs, for example timestamps.
Solution
Added returningRecord to QueryDsl including all relevant macro implementations.
Notes
The current implementation works with PostgreSQL, not tested with other DBs. This is my first contact with Macros, so please review carefully.
Unit tests and README update will be done in the next few days.
Checklist

[ ] Unit test all changes
[ ] Update README.md if applicable
[x] Add [WIP] to the pull request title if it's work in progress
[ ] Squash commits that aren't meaningful changes
[x] Run sbt scalariformFormat test:scalariformFormat to make sure that the source files are formatted

@getquill/maintainers

MySQL doesn't support INSERT INTO .. RETURNING, but is capable returning last inserted ID. Cassandra has no support for that, too. Didn't check the other DBs.
The question now is if we should restrict that feature to postgres only and how to implement that?

Thanks for the awesome work @rolandjohann. Most databases actualy don't support record returns at all. I think Postgres is the exception rather then the norm, so we have to add this case to each DB test. Since returning is not supported for anything other then ID in most databases, and quill does not intrinsically know what column is the ID, checking to see if a column is the right one is not possible. Checking to see if it's a whole record and appropriately failing however, should be.
What I suggest is that you add a Capabilities trait that parsing Parsing expects as a self-type (and that the database contexts implement) which has some simple key/value variables that indicate what each DB can and cannot do (e.g trait Capabilities { def insertReturn[T < InsertReturnCapability]:T = InsertReturnCapability.ReturnWholeRecord vs ReturnSingleField } ). Then we can do c.fail in Parsing that will break during the compile phase when things like a whole-record return are done in databases that do not support that.
Also, instead of having a separate .returningRecord call, could we just have .returning(r => r) and detect that the input and output of .returning is the same in the parser?

@deusaquilus great idea defining capabilities, I'll try to implement that.
Regarding the API I'm not sure either how to define it. In the first version the signature took the type explicitly .returningRecord[T]. The idea behind that is a little more complex:
Case class representation of "prototype" entities which are not existent in the DB yet and the DB adds several generated columns (id, created_at, etc.) are slightly misconcepted because case classes expect members to be defined which will be generated by the DB and thus are ignored at insert query submission. My current concept involves prototypes of entities:
case class Person(id: Long, name: String, age: int, createdAt: DateTime)
case class PersonPrototype(name: String, age: int)

With this DB facing domain model we can implement insert query by prototype and specify return type explicitly to complete entity:
class PersonRepository {
  def create(personPrototype: PersonPrototype): Future[Person] = {
    implicit val m = schemaMeta[PersonPrototype]("person")
    query[PersonPrototype].insert(lift(personPrototype)).returningRecord[Person]
  }
}

I see two possibilities:

io.getquill.dsl.QueryDsl.Insert#returning(r => r), e.g. io.getquill.dsl.QueryDsl.Insert#returning(identity) => this is explicit, IMHO a little to verbose
overloading io.getquill.dsl.QueryDsl.Insert#returning so we can return a column or an entity:

def returning[R](f: E => R): ActionReturning[E, R]
def returning[R]: ActionReturning[E, R]

This offers flexibility, but adds verbosity because we must specify return type explicitly even if it is the on of query[T].
What are your thoughts on this?

What I suggest is that you add a Capabilities trait that parsing Parsing expects as a self-type (and that the database contexts implement) which has some simple key/value variables that indicate what each DB can and cannot do (e.g trait Capabilities { def insertReturn[T < InsertReturnCapability]:T = InsertReturnCapability.ReturnWholeRecord vs ReturnSingleField } ). Then we can do c.fail in Parsing that will break during the compile phase when things like a whole-record return are done in databases that do not support that.

I tried a naive approach: My first thought was to define the additional method only for postgres contexts with an implicit class, so users can't use this feature on non postrges contexts and get errors at compile time. But the PoC implementation crashed at compilation:
Tree 'ctx.InsertOps[ctx.Insert[io.phenetic.quill.Person]]((ctx.unquote[(ctx.EntityQuery[io.phenetic.quill.Person], io.phenetic.quill.Person) => ctx.Insert[io.phenetic.quill.Person]](personInsertMeta.expand).apply((ctx.unquote[ctx.EntityQuery[io.phenetic.quill.Person]]({
[error]   final class $anon extends AnyRef with ctx.SchemaMeta[io.phenetic.quill.Person] {
[error]     def <init>(): <$anon: ctx.SchemaMeta[io.phenetic.quill.Person]> = {
[error]       $anon.super.<init>();
[error]       ()
[error]     };
[error]     private[this] val _entity: ctx.Quoted[ctx.EntityQuery[io.phenetic.quill.Person]]{def quoted: io.getquill.ast.Entity; def ast: io.getquill.ast.Entity; def id782076222(): Unit; val liftings: Object} = {
[error]       final class $anon extends AnyRef with ctx.Quoted[ctx.EntityQuery[io.phenetic.quill.Person]] {
[error]         def <init>(): <$anon: ctx.Quoted[ctx.EntityQuery[io.phenetic.quill.Person]]> = {
[error]           $anon.super.<init>();
[error]           ()
[error]         };
[error]         import scala.language.reflectiveCalls;
[error]         scala.collection.immutable.Nil.asInstanceOf[AnyRef{def size: Unit}].size;
[error]         @io.getquill.quotation.QuotedAst(io.getquill.ast.Entity.apply("Person", scala.collection.immutable.Nil)) def quoted: io.getquill.ast.Entity = $anon.this.ast;
[error]         override def ast: io.getquill.ast.Entity = io.getquill.ast.Entity.apply("Person", scala.collection.immutable.Nil);
[error]         def id782076222(): Unit = ();
[error]         private[this] val liftings: Object = new scala.AnyRef();
[error]         <stable> <accessor> def liftings: Object = $anon.this.liftings
[error]       };
[error]       new $anon()
[error]     };
[error]     def entity: ctx.Quoted[ctx.EntityQuery[io.phenetic.quill.Person]]{def quoted: io.getquill.ast.Entity; def ast: io.getquill.ast.Entity; def id782076222(): Unit; val liftings: Object} = $anon.this._entity
[error]   };
[error]   new $anon()
[error] }.entity): ctx.EntityQuery[io.phenetic.quill.Person]), (ctx.liftCaseClass[io.phenetic.quill.Person](Person.apply(0L, "Roland", 29)): io.phenetic.quill.Person)): ctx.Insert[io.phenetic.quill.Person]))' can't be parsed to 'Ast'
[error]     val insertQ = quote {
[error]                         ^

As I'm not familiar with macros, I can't guess if that approach even can work.

Yeah, defining this kind of functionality outside of the macro parser is very difficult.

@deusaquilus Need your help/assistance again. The DB contexts aren't directly within the same class hierarchy as Parsing. The "highest" super classes of Parsing are ActionMacro and QueryMacro, which aren't at the class hierarchy of Context and its implementations but are called at Context via macro.
Things I tried to get InsertReturnCapability into Parsing:

pass inset return capability via annotation from abstract method defined at Context

class ParserMacroSettings(insertReturn: InsertReturnCapability) extends StaticAnnotation

trait Capabilities {
  def insertReturn: InsertReturnCapability
}

trait Context[Idiom <: io.getquill.idiom.Idiom, Naming <: NamingStrategy] extends Capabilities {
  // for testing purposes to prevent having to implement that at all classes extending Context
  override def insertReturn: InsertReturnCapability = ReturnSingleField

  @ParserMacroSettings(insertReturn) def run[T](quoted: Quoted[ActionReturning[_, T]]): Result[RunActionReturningResult[T]] = macro ActionMacro.runActionReturning[T]
}

Now at macro I have the AST of annotation body with
c.macroApplication
      .children
      .head
      .symbol
      .annotations
      .find(_.tree.tpe <:< typeOf[ParserMacroSettings])

which obviously is just Select(This(TypeName("Context")), TermName("insertReturn")).

Evaluating code
c.eval(c.Expr[InsertReturnCapability](c.untypecheck(q"${c.prefix}.insertReturn"))), which leads to

java.lang.IllegalArgumentException: Could not find proxy for val ctx: io.phenetic.quill.MyDatabaseContext.type in List(value ctx, method main, object Application, package quill, package phenetic, package io, package <root>) (currentOwner= method wrapper )

So basically I'm stuck here

@deusaquilus I suggest finalizing this particular feature and do the restriction to postgres afterwards. In that step mysql capability can be handled, too: IMHO there the API should restrict to returning ID and even provide an API that's pointing to that fact returningId.

Hi @rolandjohann. I’m celebrating the Jewish holiday of Purim this week so
going to be occupied most of the time. I’ll try to have another look over
the weekend and address any issues.
On Wed, Mar 20, 2019 at 6:34 AM rolandjohann<EMAIL_ADDRESS>wrote:

@deusaquilus https://github.com/deusaquilus I suggest finalizing this
particular feature and do the restriction to postgres afterwards. In that
step mysql capability can be handled, too: IMHO there the API should
restrict to returning ID and even provide an API that's pointing to that
fact returningId.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/getquill/quill/pull/1383#issuecomment-474774349, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABTliBtLlnJEgfx-uXIZecewDPFPppeiks5vYg6ZgaJpZM4bsufa
.

Hi @deusaquilus thanks for the information

Sorry but I can't do this tonight. Banged my head on the codegen commit (#1396) and need to collapse now. Will have a look at this the coming day/evening.

Okay. The capabilities have to be read during compile-time as opposed to run-time so you cannot encode them into a value, you need to encode them into a type. You can then read that back out using .returnType from a method:
sealed trait InsertReturnCapability
trait ReturnSingleField extends InsertReturnCapability
trait ReturnMultipleField extends InsertReturnCapability
case object ReturnSingleField extends ReturnSingleField
case object ReturnMultipleField extends ReturnMultipleField

trait Context[Idiom <: io.getquill.idiom.Idiom, Naming <: NamingStrategy] {
  type InsertReturnCapabilityType <: InsertReturnCapability
  override def insertReturnCapability:InsertReturnCapabilityType
}

// Then in a paticular sub-context you do:
trait PostgresJdbcContext[Idiom <: io.getquill.idiom.Idiom, Naming <: NamingStrategy] {
  override type InsertReturnCapabilityType = ReturnMultipleField
  override def insertReturnCapability: ReturnMultipleField = ReturnMultipleField
}

Then in your macro code do this to check the actual return type that the context has.
val capabilityType =
  c.prefix.tree.tpe.members
    .filter(_.isMethod)
    .filter(_.name == TermName("myColor"))
    .head
    .asMethod
    .returnType

// check it like this:
if (capabilityType =:= ReturnMultipleField)
  doOneThing()
else
  doAnotherThing()

In the above code I didn't abstract out into a Capabilities trait but you should definitely try to do that:
trait ReturnMultipleCapability {
  override type InsertReturnCapabilityType = ReturnSingleField
  override def insertReturnCapability:ReturnSingleField
}
// and the same for ReturnSingleCapability
// Then you tack them both onto Context

This compile-time stuff is a little mind-bending sometimes. Thanks for the good work!
Can you try this out?

Thanks for sharing. I'll try that within the next few days

@ronaldjohann Any luck? I’m going to be away on vacation until next week so my connectivity will be limited

Yes, had some time today. I‘ll push the changes this evening.
Alexander Ioffe<EMAIL_ADDRESS>schrieb am So. 7. Apr. 2019 um
16:26:

@ronaldjohann Any luck? I’m going to be away on vacation until next week
so my connectivity will be limited
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/getquill/quill/pull/1383#issuecomment-480595040, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFddGgaMttlgGiYAy2__7dfFsvQUQ4A1ks5vegALgaJpZM4bsufa
.

@deusaquilus git it working, but I'm not happy with the current situation: MirrorContexts can be used with Postgres idiom but the capability is bound to Context, so we can't use this feature when mirroring.

As far as I can see we can use Idiom to check for returning capability - that seems to be far more complicated to implement

Shoot! You're right. I know this should be possible but I don't want to you wait any longer. Please PR the change without the capabilities-checking and file an issue that we need a capabilities-checking feature in the ___Dialect specifically to prevent other databases from making statements like ... returning * that they can't actually do. Please add a note to the documentation that this feature is only supported with Postgres and will cause an invalid query with other databases. I will approve the PR and try to work on capabilities in the coming weeks.

Okay. Here's how you do it from Dialect
sealed trait InsertReturnCapability
trait ReturnSingleField extends InsertReturnCapability
trait ReturnMultipleField extends InsertReturnCapability

trait Capabilities {
  type ReturnAfterInsert <: InsertReturnCapability
}
trait CanReturnRecordAfterInsert extends Capabilities {
   override type ReturnAfterInsert = ReturnMultipleField
}

trait PostgresDialect extends CanReturnRecordAfterInsert

Here's how you then check it in the macro:
// c.prefix.tree.tpe.typeArgs(0) should be the Dialect e.g. PostgresDialect
c.prefix.tree.tpe.typeArgs(0).members.find {
  case ts:TypeSymbol if (ts.asType.typeSignature =:= typeOf[ReturnMultipleField]) => true
  case _ => false
}

I haven't tried it outside of my mock example yet but going to do it. Want to give this a shot?

@deusaquilus thanks for sharing the solution, I'll try that (hopefully) at the weekend. Time's rare currently

@rolandjohann How is it going? Did this approach work?

@deusaquilus sorry for the delay. Yes, your approach work perfectly.
But having a quick look at the CI tests depicts plenty of failing tests because of non provided type when returning a single field. I tested the stuff as well by setting up a clean project with snapshot dependency on local published quill libs and there I have no problems at all. Even IntelliJ is very restrictive in hinting scala code and doesn't criticise about non provided types. Can it be that this is caused by some specific compiler flag?
BTW: If I remember correctly you asked for type specification when overloading...

@rolandjohann It looks like we need to do returningRecord after all. I opened #1455 to test this out. Aside from that though, is the work complete? I don't see anything with RETURNING in JdbcContext.

@deusaquilus as we tied the capability to io.getquill.PostgresDialect you didn't find it in JdbcContext. The check for the capability at the parser is Option based so I didn't define the capability elsewhere. Besides the naming (and the tests) this feature works. Tested it with AsyncMysqlContext, AysncPostgresContext and MirrorContext as well.
There I didn't face the issues that let the tests crash. Do you know what's the root cause of this?

@rolandjohann Are you sure there's nothing missing here? I just tried:
val q = quote {
  query[Person].insert(lift(Person("Joe", 123))).returningRecord
}
println(SqlQuery(SqlNormalize(q.ast)))

... and I got:
Exception in thread "main" java.lang.IllegalStateException: Query not properly normalized. Please open a bug report. Ast: 'querySchema("Person").insert(v => v.name -> ?, v => v.age -> ?).returningRecord'
	at io.getquill.util.Messages$.fail(Messages.scala:15)
	at io.getquill.context.sql.SqlQuery$.apply(SqlQuery.scala:78)
	at io.getquill.MySqlTest$.main(MySqlTest.scala:18)
	at io.getquill.MySqlTest.main(MySqlTest.scala)

Are you sure you didn't miss something? Are there supposed to be any changes to SqlQuery with this PR?

@rolandjohann I got this to compile the tests to work but it doesn't work with quill-jdbc. Could you please have a look at my above comment?

Okay. I managed to compile and test this change but I cannot release it because there are a couple of problems and open questions.
@rolandjohann Taking this functionality and bolting-on the Query decoder a brilliant 1st step but there a couple of other things that have to be done before the feature is complete.
Firstly, this needs to be more thoroughly tested. There are no quill-jdbc tests that do returning[T] yet this is the most essential thing to do. If you see my code above, the problem with this is that doing this: prepare(conn.prepareStatement(sql, Statement.RETURN_GENERATED_KEYS)) or this: prepare(conn.prepareStatement(sql, Array("*"))) is highly problematic because you don't have control over the order of the columns that come out of the returned ResultSet. In my tuple example above, the encoders are the following:
new Product(
          implicitly[Decoder[Long]](longDecoder).apply(0, row),
          implicitly[Decoder[String]](stringDecoder).apply(1, row),
          implicitly[Decoder[Long]](longDecoder).apply(2, row))
        )

Yet because the description field comes first in the query, the error Bad value for type long : test1 will occour as I have mentioned above.
In order to resolve this issue, we need to answer an essential question. The .returning API was only ever designed to return one column that is thereby passed into JDBC as is indicated in the original Returning AST element which has a single property AST field. The second that we want to extend this into more kinds of returns, there is a serious problem because the API returning(f: E => R) gives you the false impression that it can be an arbitrary R whereas the reality is far from that. In order to extend this API we essentially have two options for returning *.

Make prepare(conn.prepareStatement, ...) return all columns for the Insert[E] row-type and splice f into the final output for the result-set extractor. This is good because it would enable users to specify a nearly arbitrary f e.g. doing something like .returning(f => (fun(f.a), f.b + 1)) would be possible. The drawback of this is that we are forced to return every single column of Ewhich for large objects may be a serious problem. Also using, this approach, the encoder that needs to be used in the result-set extractor is not the encoder ofRbut rather the encoder ofEand thereturningExtractorinActionMacro` needs to be changed accordingly.

Allow only a subset of things that f can be. I think a sane subset would be a: a single field: f => f.id. A tuple of fields f => (f.a, and f.b) and a case class of fields f => C(f.a, f.b). This would mean that additional things need to happen in Parsing which would parse the single-field/tuple/case-class, figure out which fields .returning actually needs and then put these into the ReturningRecord AST (or possibly the Returning AST based on how we want to do it).

@rolandjohann @fwbrasil and @getquill/maintainers. I'd love to hear your thoughts on how this should be done.

It's interesting to note that actually, the reason why my query fails above is that the columns arrive in the result-set in the wrong order and break in the decoders. If we were to do decoding based on column name as opposed to position, this problem would not happen in the first place and this implementation would actually work!

I have a possible solution #3 which I like the most:
3. Take the f in returning(f: E => R) and run it through the parser so that you get some f_AST. Then call attach FunctionApply(Entity[E], f_AST) (just be sure to substitute the original Ident for the E in your insert query and replace that with whatever exists in f_AST using BetaReduction). Then do run this through the normalizer to get: SqlQuery(NormalizeSql(FunctionApply(Entity[E], f_AST))) which should give you a FlattenSqlQuery. Then take this fsq:FlattenSqlQuery.select, and run each one through the tokenizer (you should be able to just do fsq:FlattenSqlQuery.select.map(_.tokenize). This will give you the list of actual strings you need to put into to the columnArray in prepare(conn.prepareStatement, columnArray). That way, you should be able to do things like .returning(r => (r.a+1, r.b)) and even .returning(r => (someUDF(r.a), r.b)) and it will splice into the query as RETURNING someUDF(r.a, r.b)

Scratch that. Here's what I think it needs to look like:
object ExpandReturning {

  def apply(returning: Returning, idiom: SqlIdiom)(implicit naming: NamingStrategy): List[String] = {
    val Returning(_, alias, property) = returning

    // Ident("j"), Tuple(List(Property(Ident("j"), "name"), BinaryOperation(Property(Ident("j"), "age"), +, Constant(1))))
    // => Tuple(List(Constant("name"), BinaryOperation(Ident("age"), +, Constant(1))))
    val dePropertized =
      Transform(property) {
        case Property(`alias`, rest) => Ident(rest)
      }

    // Tuple(List(Constant("name"), BinaryOperation(Ident("age"), +, Constant(1))))
    // => List(Constant("name"), BinaryOperation(Ident("age"), +, Constant(1)))
    val deTuplified = dePropertized match {
      case Tuple(values) => values
      case CaseClass(values) => values.map(_._2)
      case other => List(other)
    }

    deTuplified
      .map(field => idiom.defaultTokenizer.token(field))
      .map(_.toString)
  }
}

I'm continuing this work in #1489. Bunch of stuff left to do but progress is being made.

@deusaquilus sorry for the disruption on this implementation. Unfortunately I have no time to contribute to this feature as I would like to.
My experiments and implementation used  INSERT INTO ... RETURNING * assuming the query use .returning[Foo] with Foo having fields in exact the same order as the table definition.
With your suggested solution, will it still be possible to have an API like .returning[Foo] to not have to implement row deserialization manually (.returning(r => Foo(r.id, r.name, ...)))?

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


You provided no sources for F-Droid issues

https://github.com/Wonderfall/wonderfall.github.io/blob/e05a5843124bf99d4518661a1a47258530acc8a7/content/posts/fdroid-issues.md?plain=1#L14
Despite your notice that "this article is sourced from official and trusted sources" I see no links to supposed sources to support numerous claims you've made. Could you add them, please?

The links are scattered throughout the article where they make sense, instead of putting everything at the bottom for no reason.


removed lodash dependancy and updated to ES6

removed lodash dependancy and updated to ES6, jus checking whether you are interested to merge or create a branch with this.

I would really like to see this merged.

I really would too, but I don't have the time to review 😭

Very nice! I'll try to have a look at it! The only thing I'm concerned about is the number of old pull requests that would need to be updated to ES6 in order to be merged. Perhaps that's only a good thing, tough. Thoughts?

I'm more inclined to keeping the ES6 version in a separate branch for now. @ja9adeesh are you willing to try to keep that branch in sync with the master branch?

Created the es6 branch based on this PR for maintaining the ES6 version.

@bostrom  it would be awesome if a separate npm package is created for ES6 so that users who want can use it directly.


replace involved argument for clock jump differences with 3 Lookup Args

How about merging the servers? That shouldn't be too difficult.

I agree: the engineering effort is pretty low, there's no real reason to separate the arguments, and it saves a few columns.

The next step is to merge the clients also.

I disagree: the red wedding should happen before we take a closer look at whether merging the clients is worth it.


Password Encryption

As a user or an organization, I should expect sensitive info like passwords to be encrypted.

Implemented in the VolunteerIndex API
Uses an encryption algorithm, in which the password hash and the salt are the only two things stored in the API.
At run time, the API can use the algorithm function along with the passed password and the saved salt. This result is then compared against the saved hash to see if they match. If it is a match, then the passwords must also match.


Do not run lock related tests for folder on ocis

Description
As per this comment https://github.com/owncloud/ocis/issues/1284#issuecomment-1238336767. Only locking to a single file is possible but locking a folder is not possible on ocis and there is no plan to implement that on ocis. we have a lots tests related to lock in expected to failure file related to this issue https://github.com/owncloud/ocis/issues/1284.
TODO-QA:

[x] Do not run folder-lock related tests on ocis
apiSuites to cover

[x] apiWebdavLocks https://github.com/owncloud/core/pull/40355
[x] apiWebdavLocks2 https://github.com/owncloud/core/pull/40356
[x] apiWebdavLocks3 https://github.com/owncloud/core/pull/40357
[x] apiWebdavLocksUnLock https://github.com/owncloud/core/pull/40358

[x] Remove folder lock related tests from ocis localTestAPI https://github.com/owncloud/ocis/pull/4546/

All the folder-lock related tests have been added tag and not run on ocis with above PR's. So closing this issue.


feat(pkg/catalog): Add routesFromRules func

This func allows one to get a list of trafficpolicy.HTTPRoute objects from a set of rules from an SMI Traffic Target resource. The larger change can be seen in #2035 where routesFromRules is named HTTPRoutesFromRules (renamed to allow for the function to later also return TCPRoutes from rules in the future).
There are no functional changes to the system in this PR. It is part of #2034 and a chunk of #2035.
Please answer the following questions with yes/no.

Does this change contain code from or inspired by another project? If so, did you notify the maintainers and provide attribution? No

Codecov Report

Merging #2036 (e51f7fa) into main (5c4b802) will increase coverage by 0.04%.
The diff coverage is 78.57%.

@@            Coverage Diff             @@
##             main    #2036      +/-   ##
==========================================
+ Coverage   56.32%   56.36%   +0.04%
==========================================
  Files         142      143       +1
  Lines        5767     5782      +15
==========================================
+ Hits         3248     3259      +11
- Misses       2516     2520       +4
  Partials        3        3

Impacted Files
Coverage Δ

pkg/catalog/routes.go
79.59% <78.57%> (-0.08%)
:arrow_down:

pkg/kubernetes/event_handlers.go
68.75% <0.00%> (ø)

pkg/kubernetes/types.go
0.00% <0.00%> (ø)

Continue to review full report at Codecov.

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


appdef: move builders to ws

### move builders from `IAppDefBuilder` to `IWorkspaceBuilder`
- [x] IDataTypesBuilder
- [x] IGDocsBuilder
- [x] ICDocsBuilder
- [x] IWDocsBuilder
- [x] IODocsBuilder
- [x] IObjectsBuilder
- [x] IViewsBuilder
- [x] ICommandsBuilder
- [x] IQueriesBuilder
- [x] IProjectorsBuilder
- [x] IJobsBuilder
- [ ] IRolesBuilder
- [ ] IACLBuilder
- [ ] IRatesBuilder
- [ ] ILimitsBuilder
- [ ] refactore `istructsmem/descr` package
- [ ] remove `AddType` from `IWorkspaceBuilder`
- [ ] —————— [other] ——————
- [ ] fix `parser` package
- [ ] fix tests

Problem
sys.Workspace should be filled from different go packages
Solution

IWorkspaceBuilder.AlterWorkspace(QName) IWorkspaceBuilder
? IWorkspaceBuilder.AddOrAlterWorkspace(QName) IWorkspaceBuilder

Technical problem
Specific interfaces for reading types (IWithCDoc, IWithCRecord, IWithCommand, etc.) are now implemented by both the application (IAppDef interface) and the workspace (IWorkspace interface). It is necessary to avoid writing two implementations.
It is possible to abandon the use of these specific interfaces altogether, leaving only the general interface IWithTypes. The typed search and typed range performed by these specific interfaces can be implemented by a set of procedures that receive IWithTypes members as arguments.


Custom Status Code

Sometimes developers need to handle responses based on their status code. Can you add routes to return common status codes like 401, 404?

DummyJSON supports this:
https://dummyjson.com/docs/http
fetch('https://dummyjson.com/http/404/Hello_Peter')
.then(res => res.json())
.then(console.log);


[bug]: v0.17.4-beta neutrino will not start if neutrino fails: node crashed

Background
My node does not start anymore. It has been running for years, but when I wanted to consolidate, the tx would not broadcast, so I did a reset-wallet-transactions.
Now the node does not start anymore.
Your environment

lnd: v0.17.4-beta
Linux srv70 6.2.16-3-pve #1 SMP PREEMPT_DYNAMIC PVE 6.2.16-3 (2023-06-17T05:58Z) x86_64 GNU/Linux
Neutrino backend

Steps to reproduce
Start node. It does not start.
Expected behaviour
Of course it should start.
Actual behaviour
    "version": "0.17.4-beta commit=v0.17.4-beta",
    "commit_hash": "8bba79222f439127e46ec3ff7ec7c650e0d88d56",
    "identity_pubkey": "*",
    "alias": "*",
    "color": "*",
    "num_pending_channels": 1,
    "num_active_channels": 0,
    "num_inactive_channels": 19,
    "num_peers": 0,
    "block_height": 836627,
    "block_hash": "00000000000000000001ba5d75c4c243b2a667f6522648f117ddc8353538ecf3",
    "best_header_timestamp": "1711610847",
    "synced_to_chain": false,
    "synced_to_graph": false,
    "testnet": false,
    "chains": [

Logs:
Mar 28 07:30:16 srv70 lnd[28422]: 2024-03-28 07:30:16.666 [INF] LTND: Channel backup proxy channel notifier starting
Mar 28 07:30:16 srv70 lnd[28422]: 2024-03-28 07:30:16.724 [INF] WTCL: (legacy) Using private watchtower *, offering policy (blob-type=10 max-updates=1024 reward-rate=0 sweep-fee-rate=2500)
Mar 28 07:30:16 srv70 lnd[28422]: 2024-03-28 07:30:16.972 [INF] WTCL: (anchor) Using private watchtower *, offering policy (blob-type=110 max-updates=1024 reward-rate=0 sweep-fee-rate=2500)
Mar 28 07:30:17 srv70 lnd[28422]: 2024-03-28 07:30:17.153 [ERR] BTCN: Unable to parse IP network for peer nzkxjwne6nqd4rllmvg25iiri46xuwtewj2h3mveb66xmax3sf2mj2ad.onion:8333: unsupported IP type
Mar 28 07:30:17 srv70 lnd[28422]: 2024-03-28 07:30:17.180 [INF] ATPL: Instantiating autopilot with active=true, max_channels=20, allocation=0.900000, min_chan_size=500000, max_chan_size=1000000, private=false, min_confs=8, conf_target=3
Mar 28 07:30:17 srv70 lnd[28422]: 2024-03-28 07:30:17.181 [INF] LTND: We're not running within systemd or the service type is not 'notify'
Mar 28 07:30:17 srv70 lnd[28422]: 2024-03-28 07:30:17.181 [INF] LTND: Waiting for chain backend to finish sync, start_height=836627
Mar 28 07:30:17 srv70 lnd[28422]: 2024-03-28 07:30:17.570 [DBG] LNWL: Chain backend synced to tip!
Mar 28 07:30:17 srv70 lnd[28422]: 2024-03-28 07:30:17.581 [INF] BTCN: Registering block subscription: id=2
Mar 28 07:30:20 srv70 lnd[28422]: 2024-03-28 07:30:20.103 [INF] LNWL: Started rescan from block<PHONE_NUMBER>00000000042cc6583a05cff3375f0507f833b877d0a039c7e37ad0 (height 794580) for 903 addresses
Mar 28 07:30:20 srv70 lnd[28422]: 2024-03-28 07:30:20.103 [INF] BTCN: Canceling block subscription: id=2
Mar 28 07:30:20 srv70 lnd[28422]: 2024-03-28 07:30:20.105 [DBG] LNWL: Adding new batch(0) of 1 queries to work queue
Mar 28 07:30:20 srv70 lnd[28422]: 2024-03-28 07:30:20.703 [ERR] BTCN: Unable to parse IP network for peer nzkxjwne6nqd4rllmvg25iiri46xuwtewj2h3mveb66xmax3sf2mj2ad.onion:8333: unsupported IP type
Mar 28 07:30:21 srv70 lnd[28422]: 2024-03-28 07:30:21.295 [ERR] BTCN: Unable to parse IP network for peer nzkxjwne6nqd4rllmvg25iiri46xuwtewj2h3mveb66xmax3sf2mj2ad.onion:8333: unsupported IP type
Mar 28 07:30:21 srv70 lnd[28422]: 2024-03-28 07:30:21.295 [DBG] LNWL: Starting worker for peer nzkxjwne6nqd4rllmvg25iiri46xuwtewj2h3mveb66xmax3sf2mj2ad.onion:8333
Mar 28 07:30:21 srv70 lnd[28422]: 2024-03-28 07:30:21.295 [INF] BTCN: New valid peer nzkxjwne6nqd4rllmvg25iiri46xuwtewj2h3mveb66xmax3sf2mj2ad.onion:8333 (outbound) (/Satoshi:24.0.1/)
Mar 28 07:30:22 srv70 lnd[28422]: 2024-03-28 07:30:22.809 [INF] BTCN: Fetching set of checkpointed cfheaders filters from height=836627, hash=c106735dd76048cb2140cfc558cc669e1b231f26f14114212364522bdfc6835b
Mar 28 07:30:22 srv70 lnd[28422]: 2024-03-28 07:30:22.809 [INF] BTCN: Starting to query for cfheaders from checkpoint_interval=836, checkpoints=836
Mar 28 07:30:22 srv70 lnd[28422]: 2024-03-28 07:30:22.809 [INF] BTCN: Fully caught up with cfheaders at height 836627, waiting at tip for new blocks
Mar 28 07:31:00 srv70 lnd[28422]: 2024-03-28 07:31:00.105 [DBG] LNWL: Adding new batch(1) of 1 queries to work queue
Mar 28 07:31:02 srv70 lnd[28422]: 2024-03-28 07:31:02.106 [WRN] LNWL: Query(1) from peer <IP_ADDRESS>:8333 failed, rescheduling: did not get response before timeout
Mar 28 07:31:06 srv70 lnd[28422]: 2024-03-28 07:31:06.107 [WRN] LNWL: Query(1) from peer nzkxjwne6nqd4rllmvg25iiri46xuwtewj2h3mveb66xmax3sf2mj2ad.onion:8333 failed and reached maximum number of retries, not rescheduling: did not get response before timeout
Mar 28 07:31:06 srv70 lnd[28422]: 2024-03-28 07:31:06.107 [DBG] LNWL: Canceled batch 1
Mar 28 07:32:04 srv70 lnd[28422]: 2024-03-28 07:32:04.591 [ERR] BTCN: Unable to parse IP network for peer 4oetytuvs7c5g3lr4ipg7qwvbj63ujfo3l3flgkacbw4wxha3yn3kdid.onion:8333: unsupported IP type
Mar 28 07:32:04 srv70 lnd[28422]: 2024-03-28 07:32:04.866 [ERR] BTCN: Unable to parse IP network for peer vxjefp74s6x664ck5blxahxp4ip6ndonpwbqrzyntqgscjtf35r2pwid.onion:8333: unsupported IP type
Mar 28 07:32:09 srv70 lnd[28422]: 2024-03-28 07:32:09.348 [DBG] LNWL: Peer arube62wpn2dl3kyfnm3yqtzmqisxwujj2e3hdic4nazero6f6lkr7id.onion:8333 for worker disconnected
Mar 28 07:32:09 srv70 lnd[28422]: 2024-03-28 07:32:09.348 [INF] BTCN: Lost peer arube62wpn2dl3kyfnm3yqtzmqisxwujj2e3hdic4nazero6f6lkr7id.onion:8333 (outbound)
Mar 28 07:32:13 srv70 lnd[28422]: 2024-03-28 07:32:13.384 [ERR] BTCN: Unable to parse IP network for peer 4oetytuvs7c5g3lr4ipg7qwvbj63ujfo3l3flgkacbw4wxha3yn3kdid.onion:8333: unsupported IP type
Mar 28 07:32:14 srv70 lnd[28422]: 2024-03-28 07:32:14.026 [ERR] BTCN: Unable to parse IP network for peer 4oetytuvs7c5g3lr4ipg7qwvbj63ujfo3l3flgkacbw4wxha3yn3kdid.onion:8333: unsupported IP type
Mar 28 07:32:14 srv70 lnd[28422]: 2024-03-28 07:32:14.026 [DBG] LNWL: Starting worker for peer 4oetytuvs7c5g3lr4ipg7qwvbj63ujfo3l3flgkacbw4wxha3yn3kdid.onion:8333
Mar 28 07:32:14 srv70 lnd[28422]: 2024-03-28 07:32:14.026 [INF] BTCN: New valid peer 4oetytuvs7c5g3lr4ipg7qwvbj63ujfo3l3flgkacbw4wxha3yn3kdid.onion:8333 (outbound) (/Satoshi:26.0.0/)
Mar 28 07:34:04 srv70 lnd[28422]: 2024-03-28 07:34:04.018 [ERR] BTCN: Unable to parse IP network for peer kikiuz7gab7hqtvjcaojyyghvxohp5tkzqyiwe2325or7yl7b6jajeyd.onion:8333: unsupported IP type
Mar 28 07:34:09 srv70 lnd[28422]: 2024-03-28 07:34:09.419 [WRN] BTCN: Banning peer <IP_ADDRESS>:8333: duration=48h0m0s, reason=peer was unable to serve compact filters
Mar 28 07:34:09 srv70 lnd[28422]: 2024-03-28 07:34:09.430 [INF] BTCN: Lost peer <IP_ADDRESS>:8333 (outbound)
Mar 28 07:34:09 srv70 lnd[28422]: 2024-03-28 07:34:09.430 [ERR] BTCN: Unable to parse IP network for peer c3oiub6givj6xgt6oxbrvp5t74gijhzjz63mvkemly6qzzi5wfcuodid.onion:8333: unsupported IP type
Mar 28 07:34:10 srv70 lnd[28422]: 2024-03-28 07:34:10.323 [ERR] BTCN: Unable to parse IP network for peer kikiuz7gab7hqtvjcaojyyghvxohp5tkzqyiwe2325or7yl7b6jajeyd.onion:8333: unsupported IP type
Mar 28 07:34:10 srv70 lnd[28422]: 2024-03-28 07:34:10.788 [ERR] BTCN: Unable to parse IP network for peer kikiuz7gab7hqtvjcaojyyghvxohp5tkzqyiwe2325or7yl7b6jajeyd.onion:8333: unsupported IP type
Mar 28 07:34:10 srv70 lnd[28422]: 2024-03-28 07:34:10.788 [INF] BTCN: New valid peer kikiuz7gab7hqtvjcaojyyghvxohp5tkzqyiwe2325or7yl7b6jajeyd.onion:8333 (outbound) (/Satoshi:26.0.0/)
Mar 28 07:34:10 srv70 lnd[28422]: 2024-03-28 07:34:10.788 [DBG] LNWL: Starting worker for peer kikiuz7gab7hqtvjcaojyyghvxohp5tkzqyiwe2325or7yl7b6jajeyd.onion:8333
Mar 28 07:34:13 srv70 lnd[28422]: 2024-03-28 07:34:13.370 [ERR] BTCN: Unable to parse IP network for peer c3oiub6givj6xgt6oxbrvp5t74gijhzjz63mvkemly6qzzi5wfcuodid.onion:8333: unsupported IP type
Mar 28 07:34:13 srv70 lnd[28422]: 2024-03-28 07:34:13.797 [ERR] BTCN: Unable to parse IP network for peer c3oiub6givj6xgt6oxbrvp5t74gijhzjz63mvkemly6qzzi5wfcuodid.onion:8333: unsupported IP type
Mar 28 07:34:13 srv70 lnd[28422]: 2024-03-28 07:34:13.797 [DBG] LNWL: Starting worker for peer c3oiub6givj6xgt6oxbrvp5t74gijhzjz63mvkemly6qzzi5wfcuodid.onion:8333
Mar 28 07:34:13 srv70 lnd[28422]: 2024-03-28 07:34:13.797 [INF] BTCN: New valid peer c3oiub6givj6xgt6oxbrvp5t74gijhzjz63mvkemly6qzzi5wfcuodid.onion:8333 (outbound) (/Satoshi:26.0.0/)

Might be related to #8593

Worried about Neutrino rescan ended with error: did not get response before timeout:
Mar 28 06:51:48 srv70 lnd[25047]: 2024-03-28 06:51:48.505 [DBG] LNWL: Adding new batch(2) of 1 queries to work queue
Mar 28 06:51:51 srv70 lnd[25047]: 2024-03-28 06:51:51.712 [DBG] LNWL: Adding new batch(3) of 1 queries to work queue
Mar 28 06:51:54 srv70 lnd[25047]: 2024-03-28 06:51:54.872 [DBG] LNWL: Adding new batch(4) of 1 queries to work queue
Mar 28 06:51:58 srv70 lnd[25047]: 2024-03-28 06:51:58.750 [DBG] LNWL: Adding new batch(5) of 1 queries to work queue
Mar 28 06:52:01 srv70 lnd[25047]: 2024-03-28 06:52:01.932 [DBG] LNWL: Adding new batch(6) of 1 queries to work queue
Mar 28 06:52:05 srv70 lnd[25047]: 2024-03-28 06:52:05.196 [DBG] LNWL: Adding new batch(7) of 1 queries to work queue
Mar 28 06:52:08 srv70 lnd[25047]: 2024-03-28 06:52:08.916 [DBG] LNWL: Adding new batch(8) of 1 queries to work queue
Mar 28 06:52:11 srv70 lnd[25047]: 2024-03-28 06:52:11.185 [DBG] LNWL: Adding new batch(9) of 1 queries to work queue
Mar 28 06:52:14 srv70 lnd[25047]: 2024-03-28 06:52:14.749 [DBG] LNWL: Adding new batch(10) of 1 queries to work queue
Mar 28 06:52:19 srv70 lnd[25047]: 2024-03-28 06:52:19.576 [DBG] LNWL: Adding new batch(11) of 1 queries to work queue
Mar 28 06:52:22 srv70 lnd[25047]: 2024-03-28 06:52:22.903 [DBG] LNWL: Marking transaction 4b88aa27d5cb78a9efa1d99e0d22296c00597101e5b040445b6913328040ea6e output 0 (0.00352909 BTC) spendable
Mar 28 06:52:22 srv70 lnd[25047]: 2024-03-28 06:52:22.903 [DBG] LNWL: Marked address bc1p0v5recc48c4l6eclwnff273pj4xl6rthymf4282glalgmvwrlthqkazcwv used
Mar 28 06:52:24 srv70 lnd[25047]: 2024-03-28 06:52:24.259 [DBG] LNWL: Adding new batch(12) of 1 queries to work queue
Mar 28 06:52:28 srv70 lnd[25047]: 2024-03-28 06:52:28.847 [DBG] LNWL: Adding new batch(13) of 1 queries to work queue
Mar 28 06:52:32 srv70 lnd[25047]: 2024-03-28 06:52:32.436 [DBG] LNWL: Peer <IP_ADDRESS>:8333 for worker disconnected, cancelling job 13
Mar 28 06:52:32 srv70 lnd[25047]: 2024-03-28 06:52:32.436 [INF] BTCN: Lost peer <IP_ADDRESS>:8333 (outbound)
Mar 28 06:52:32 srv70 lnd[25047]: 2024-03-28 06:52:32.436 [WRN] LNWL: Query(13) from peer <IP_ADDRESS>:8333 failed, rescheduling: peer disconnected
Mar 28 06:52:32 srv70 lnd[25047]: 2024-03-28 06:52:32.436 [INF] BTCN: Syncing to block height 836621 from peer <IP_ADDRESS>:8333
Mar 28 06:52:32 srv70 lnd[25047]: 2024-03-28 06:52:32.436 [INF] BTCN: Fetching set of headers from tip (height=836621) from peer <IP_ADDRESS>:8333
Mar 28 06:52:34 srv70 lnd[25047]: 2024-03-28 06:52:34.437 [WRN] LNWL: Query(13) from peer o4l6ihjktvg73rzkoiz3amxkszmpp5thfhr7otpvwqx72ii6tmuwqxyd.onion:8333 failed and reached maximum number of retries, not rescheduling: did not get response before timeout
Mar 28 06:52:34 srv70 lnd[25047]: 2024-03-28 06:52:34.437 [DBG] LNWL: Canceled batch 13
Mar 28 06:52:34 srv70 lnd[25047]: 2024-03-28 06:52:34.437 [ERR] LNWL: Neutrino rescan ended with error: did not get response before timeout
Mar 28 06:53:34 srv70 lnd[25047]: 2024-03-28 06:53:34.968 [ERR] BTCN: Unable to parse IP network for peer 3b436gve2otorhfzuslow3m62qulqtx5jd2nml6hfn5snzyc5a6z24yd.onion:8333: unsupported IP type
Mar 28 06:53:35 srv70 lnd[25047]: 2024-03-28 06:53:35.042 [DBG] LNWL: Starting worker for peer <IP_ADDRESS>:8333
Mar 28 06:53:35 srv70 lnd[25047]: 2024-03-28 06:53:35.042 [INF] BTCN: New valid peer <IP_ADDRESS>:8333 (outbound) (/Satoshi:0.21.1/)
Mar 28 06:53:35 srv70 lnd[25047]: 2024-03-28 06:53:35.162 [DBG] LNWL: Peer <IP_ADDRESS>:8333 for worker disconnected
Mar 28 06:53:35 srv70 lnd[25047]: 2024-03-28 06:53:35.162 [INF] BTCN: Lost peer <IP_ADDRESS>:8333 (outbound)
Mar 28 06:53:37 srv70 lnd[25047]: 2024-03-28 06:53:37.768 [ERR] BTCN: Unable to parse IP network for peer 3b436gve2otorhfzuslow3m62qulqtx5jd2nml6hfn5snzyc5a6z24yd.onion:8333: unsupported IP type
Mar 28 06:53:38 srv70 lnd[25047]: 2024-03-28 06:53:38.236 [ERR] BTCN: Unable to parse IP network for peer 3b436gve2otorhfzuslow3m62qulqtx5jd2nml6hfn5snzyc5a6z24yd.onion:8333: unsupported IP type
Mar 28 06:53:38 srv70 lnd[25047]: 2024-03-28 06:53:38.236 [DBG] LNWL: Starting worker for peer 3b436gve2otorhfzuslow3m62qulqtx5jd2nml6hfn5snzyc5a6z24yd.onion:8333
Mar 28 06:53:38 srv70 lnd[25047]: 2024-03-28 06:53:38.236 [INF] BTCN: New valid peer 3b436gve2otorhfzuslow3m62qulqtx5jd2nml6hfn5snzyc5a6z24yd.onion:8333 (outbound) (/Satoshi:26.0.0/)
Mar 28 06:53:49 srv70 lnd[25047]: 2024-03-28 06:53:49.114 [INF] BTCN: Processed 2 blocks in the last 2m14.21s (height 836622, 2024-03-28 06:53:47 +0000 UTC)
Mar 28 06:53:49 srv70 lnd[25047]: 2024-03-28 06:53:49.127 [INF] BTCN: Attempting to fetch set of un-checkpointed filters at height=836622, hash=00000000000000000002c9cc33b4049de628ecd550298901426d621e74e52c78
Mar 28 06:53:59 srv70 lnd[25047]: 2024-03-28 06:53:59.134 [INF] BTCN: Verified 2 filter headers in the last 2m24.23s (height 836622, 2024-03-28 06:53:47 +0000 UTC)
Mar 28 06:54:19 srv70 lnd[25047]: 2024-03-28 06:54:19.110 [DBG] LNWL: Starting worker for peer <IP_ADDRESS>:8333
Mar 28 06:54:19 srv70 lnd[25047]: 2024-03-28 06:54:19.110 [INF] BTCN: New valid peer <IP_ADDRESS>:8333 (outbound) (/Satoshi:26.0.0/)
Mar 28 06:54:32 srv70 lnd[25047]: 2024-03-28 06:54:32.499 [WRN] BTCN: Banning peer <IP_ADDRESS>:8333: duration=48h0m0s, reason=peer was unable to serve compact filters
Mar 28 06:54:32 srv70 lnd[25047]: 2024-03-28 06:54:32.506 [INF] BTCN: Lost peer <IP_ADDRESS>:8333 (outbound)
Mar 28 06:55:33 srv70 lnd[25047]: 2024-03-28 06:55:33.117 [DBG] LNWL: Peer 3b436gve2otorhfzuslow3m62qulqtx5jd2nml6hfn5snzyc5a6z24yd.onion:8333 for worker disconnected
Mar 28 06:55:33 srv70 lnd[25047]: 2024-03-28 06:55:33.117 [INF] BTCN: Lost peer 3b436gve2otorhfzuslow3m62qulqtx5jd2nml6hfn5snzyc5a6z24yd.onion:8333 (outbound)
Mar 28 06:55:33 srv70 lnd[25047]: 2024-03-28 06:55:33.121 [ERR] BTCN: Unable to parse IP network for peer 37h2vi25ooxlm6e2pqfeplshisqvh57a6oybeqo6ppqyzqwxbvihqfyd.onion:8333: unsupported IP type
Mar 28 06:55:35 srv70 lnd[25047]: 2024-03-28 06:55:35.216 [ERR] BTCN: Unable to parse IP network for peer zcc4wsaenndkzqdp4xsfzn6ilsdhwzpqiswumdc22dv5ejejec3o7qyd.onion:8333: unsupported IP type
Mar 28 06:55:37 srv70 lnd[25047]: 2024-03-28 06:55:37.599 [ERR] BTCN: Unable to parse IP network for peer zcc4wsaenndkzqdp4xsfzn6ilsdhwzpqiswumdc22dv5ejejec3o7qyd.onion:8333: unsupported IP type
Mar 28 06:55:39 srv70 lnd[25047]: 2024-03-28 06:55:39.797 [ERR] BTCN: Unable to parse IP network for peer zcc4wsaenndkzqdp4xsfzn6ilsdhwzpqiswumdc22dv5ejejec3o7qyd.onion:8333: unsupported IP type
Mar 28 06:55:39 srv70 lnd[25047]: 2024-03-28 06:55:39.797 [DBG] LNWL: Starting worker for peer zcc4wsaenndkzqdp4xsfzn6ilsdhwzpqiswumdc22dv5ejejec3o7qyd.onion:8333
Mar 28 06:55:39 srv70 lnd[25047]: 2024-03-28 06:55:39.797 [INF] BTCN: New valid peer zcc4wsaenndkzqdp4xsfzn6ilsdhwzpqiswumdc22dv5ejejec3o7qyd.onion:8333 (outbound) (/Satoshi:26.0.0/)
Mar 28 06:57:02 srv70 lnd[25047]: 2024-03-28 06:57:02.871 [DBG] LNWL: Starting worker for peer <IP_ADDRESS>:8333
Mar 28 06:57:02 srv70 lnd[25047]: 2024-03-28 06:57:02.871 [INF] BTCN: New valid peer <IP_ADDRESS>:8333 (outbound) (/Satoshi:26.0.0/)
Mar 28 06:57:33 srv70 lnd[25047]: 2024-03-28 06:57:33.496 [DBG] LNWL: Starting worker for peer <IP_ADDRESS>:8333
Mar 28 06:57:33 srv70 lnd[25047]: 2024-03-28 06:57:33.496 [INF] BTCN: New valid peer <IP_ADDRESS>:8333 (outbound) (/Satoshi:25.1.0/)
Mar 28 06:59:05 srv70 lnd[25047]: 2024-03-28 06:59:05.588 [WRN] BTCN: Peer o4l6ihjktvg73rzkoiz3amxkszmpp5thfhr7otpvwqx72ii6tmuwqxyd.onion:8333 (outbound) no answer for 5m0s -- disconnecting
Mar 28 06:59:05 srv70 lnd[25047]: 2024-03-28 06:59:05.588 [DBG] LNWL: Peer o4l6ihjktvg73rzkoiz3amxkszmpp5thfhr7otpvwqx72ii6tmuwqxyd.onion:8333 for worker disconnected
Mar 28 06:59:05 srv70 lnd[25047]: 2024-03-28 06:59:05.588 [INF] BTCN: Lost peer o4l6ihjktvg73rzkoiz3amxkszmpp5thfhr7otpvwqx72ii6tmuwqxyd.onion:8333 (outbound)
Mar 28 06:59:05 srv70 lnd[25047]: 2024-03-28 06:59:05.596 [ERR] BTCN: Unable to parse IP network for peer ryisgvwcqtgsmouuccsbqeudcajikco7wjv6vdoe3tlnqpz4evxgzzyd.onion:8333: unsupported IP type
Mar 28 06:59:53 srv70 lnd[25047]: 2024-03-28 06:59:53.649 [ERR] BTCN: Unable to parse IP network for peer qjuj2zrhiairofltopfwremuzm76jeiivvag5kwb7mxvcb5q7fadgqyd.onion:8333: unsupported IP type

I have fixed this by doing this:

Downgrade to .3
Set neutrino.connect=x.x.x.x:8333 (my own bitcoind node IP)
Restart and let it sit there

It has now started again! Should I close this issue? It might be a .4 regression...?

Now running .4 and it seems OK.

Hello @AbelLykens I have the same issue, my neutrino node doesn't start and give me the same error that you are showed here. What can I do. I have updated to v0.18.1 beta, my previous version was 0.14 beta but this stop to start I did the update but continued the same, it doesn't start. Please help me!

Hi @Praexor , for me it was changing to 0.17.3 that worked. Seeing as we are now on 0.18.x, I am not sure what you should do...  Maybe go to 0.17.3 for a bit?
Coming from 0.14, that's quite a big step...


Improve docker image/digest support

Fix #871
Fix #872

This PR guts the custom docker image/digest logic and replaces it with GGCR. This allows us to have a robust docker validation logic.
Test
To test this pull request, you can run the following commands:
sources:
  tag:
    kind: dockerimage
    spec:
      image: ghcr.io/updatecli/updatecli
  digest:
    kind: dockerdigest
    spec:
      image: ghcr.io/updatecli/updatecli
      tag: v0.34.0

./dist/updatecli_darwin_arm64/updatecli diff --config config.yaml

+++++++++++
+ PREPARE +
+++++++++++

Loading Pipeline "config.yaml"

SCM repository retrieved: 0

++++++++++++++++++
+ AUTO DISCOVERY +
++++++++++++++++++

++++++++++++
+ PIPELINE +
++++++++++++

###############
# CONFIG.YAML #
###############

SOURCES
=======

digest
------
✔ Docker Image Tag ghcr.io/updatecli/updatecli:v0.34.0 resolved to digest ghcr.io/updatecli/updatecli@sha256:779abc2c7a46c0cc0d568bac6e6d8b81c9b3255bb025a5f421d0911a82e3d4c5

tag
---
Searching for version matching pattern "latest"
✔ Docker Image Tag "v0.34.0" found matching pattern "latest"

=============================

REPORTS:

- CONFIG.YAML:
	Source:
		✔ [digest]  (kind: dockerdigest)
		✔ [tag]  (kind: dockerimage)

Run Summary
===========
Pipeline(s) run:
  * Changed:	0
  * Failed:	0
  * Skipped:	1
  * Succeeded:	0
  * Total:	1

Additional Information
Tradeoff

Potential improvement

Nice work, I don't realize how far you went. Indeed I need some e2e tests for different registries like ghcr.io dockerhub and quay

I did some initial testing and I didn't find any regression, I need to find some ways to test with other registries than dockerhub or ghcr.io

I confirm that your code fallback to the docker configuration file to retrieve credentials.
I don't have permission to push on your local branch, so I'll probably move forward with your pullrequest and the e2e tests that I have locally

The only 'regression' might be the registry for how dockerhub is resolved. It will be resolved to index.docker.io

The only 'regression' might be the registry for how dockerhub is resolved. It will be resolved to index.docker.io

Which I don't think is a problem at all. If I recall correctly that URL was needed for the previous code which is now replaced by GGCR

@olblak fixed the failing registry test and rebased. Should be all good to go now.