feat: add forceFetchOnMount flag

So in v3, is this just going to become refetchOnMount: false and the new default is to only refetch when it's stale?

I'm not 100% sure on the naming but this was my reasoning so far:

fetchOnMount: could be confusing because if set to false it would still fetch if a query has not been fetched yet or when the query is stale.
refetchOnMount: could be confusing because if set to false it would still refetch if a query is stale.
forceFetchOnMount: if set to false it will not force a fetch. Think this one is the least ambiguous, but it's not the prettiest name.

At least in v3 (because it would be a breaking change), and coming from https://github.com/tannerlinsley/react-query/pull/789, I would like to consolidate into a single option called refetchOnMount that defaults to false. This way, it's very clear when a query is refetched by default:

when the query is stale and an "interaction" event happens like mounting, window focus, network online

Thoughts?

Sounds like a plan! Think ‘forceFetchOnMount’ is a little bit less ambiguous, but ‘refetchOnMount’ definitely looks nicer and with some documentation it should be clear enough on what it does.

Do you want to implement that here and we can close #789?

Version 3 might take a while, maybe get this one in and then rename the property to refetchOnMount in v3?

Yep. I'm good with that. Add one more, delete 3 later ;)

:tada: This PR is included in version 2.15.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


a potential alternative to dnscrypt -- dnsmasq + Tor DNS

https://github.com/drduh/OS-X-Security-and-Privacy-Guide/blob/master/README.md#dnsmasq
Instead of utilizing dnscrypt, which can be hard to depend upon due to the limited number of servers and the fact that a hostile network could easily block the list of servers, consider utilizing Tor DNS in the dnsmasq config as the upstream server. The first lookup will be relatively slow, but cached for future lookups (until TTL expiration).
server=<IP_ADDRESS>#9053

How do you run Tor to utilize that port? I've tried both Tor Browser and Tor from Homebrew - neither listened on port 9053. Feel free to PR your recommendation.

DNSPort is the torrc config option if you don't want dnsmasq. You can set it to 53, but you would need to run as root (not recommended), or authorize the low port using something like setcap equivalent on osx.
However, you can also specify dnsmasq to forward the query from dnsmasq port 53 to <IP_ADDRESS>:9053, where tor is listening.

there is also HTTPS DNS, which is new from Google. I implemented a client but it is not ready for release yet. This would encrypt all DNS queries over HTTPS with TLS.
https://developers.google.com/speed/public-dns/docs/dns-over-https

Yes, I understand the DNSPort directive, but my question is how are you running Tor to use that configuration? Through Tor Browser, Homebrew Tor, built from source, or some other way?

Both homebrew tor and tor source work fine, yeah. It's a UDP port. You may have only looked at TCP? Just do you know though, tor only supports a limited number of DNS record types. It doesn't support PTR, MX, etc. So just be aware of that until I release my Google HTTPS DNS protector...

Giving this more thought, I think the use case is too esoteric for most folks; routing DNS over the Tor network is more a more specialized recommendation which I don't think will appeal to most readers. If you feel really compelled, please send a PR with detailed instructions for setting it up, otherwise I'll close this ticket since I don't plan on making this change myself.


Not enough vram available, falling back to CPU only, AMD 16 GB VRAM

I use an iGPU with ROCm and it worked great until like yesterday when i recompiled my Docker Image with the newest ollama version. since then I get "not enough vram available, falling back to CPU only" GPU seems to be detected.
time=xxx level=INFO source=gpu.go:311 msg="Discovered GPU libraries: [/opt/rocm/lib/librocm_smi64.so.6.0.60000 /opt/rocm-6.0.0/lib/librocm_smi64.so.6.0.60000]"
time=xxx level=INFO source=gpu.go:109 msg="Radeon GPU detected"
time=xxx level=INFO source=cpu_common.go:11 msg="CPU has AVX2"
[GIN] xxx | 200 |    4.592477ms |   <IP_ADDRESS> | GET      "/api/tags"
time=xxx level=INFO source=cpu_common.go:11 msg="CPU has AVX2"
time=xxx level=INFO source=cpu_common.go:11 msg="CPU has AVX2"
time=xxx level=INFO source=llm.go:111 msg="not enough vram available, falling back to CPU only"

@user82622 How did you install ollama for AMD? I cannot get it to work at all

I was compiling the Docker Container with ROCm and Ollama based on this https://github.com/prawilny/ollama-rocm-docker
On 18 February 2024 13:59:37 CET, Sinan @.***> wrote:

@user82622 How did you install ollama for AMD? I cannot get it to work at all
--
Reply to this email directly or view it on GitHub:
https://github.com/ollama/ollama/issues/2566#issuecomment-1951318975
You are receiving this because you were mentioned.
Message ID: @.***>

Also getting not enough vram available, falling back to CPU only on a 6GB VRAM:
...
time=2024-02-25T01:59:04.497Z level=INFO source=gpu.go:94 msg="Detecting GPU type"
time=2024-02-25T01:59:04.497Z level=INFO source=gpu.go:265 msg="Searching for GPU management library libnvidia-ml.so"
time=2024-02-25T01:59:04.502Z level=INFO source=gpu.go:311 msg="Discovered GPU libraries: [/usr/lib/x86_64-linux-gnu/libnvidia-ml.so.525.105.17]"
time=2024-02-25T01:59:04.507Z level=INFO source=gpu.go:99 msg="Nvidia GPU detected"
time=2024-02-25T01:59:04.507Z level=INFO source=cpu_common.go:11 msg="CPU has AVX2"
time=2024-02-25T01:59:04.512Z level=INFO source=gpu.go:146 msg="CUDA Compute Capability detected: 7.5"
time=2024-02-25T01:59:07.702Z level=INFO source=cpu_common.go:11 msg="CPU has AVX2"
time=2024-02-25T01:59:07.702Z level=INFO source=gpu.go:146 msg="CUDA Compute Capability detected: 7.5"
time=2024-02-25T01:59:07.702Z level=INFO source=cpu_common.go:11 msg="CPU has AVX2"
time=2024-02-25T01:59:07.703Z level=INFO source=gpu.go:146 msg="CUDA Compute Capability detected: 7.5"
time=2024-02-25T01:59:07.703Z level=INFO source=llm.go:111 msg="not enough vram available, falling back to CPU only"
time=2024-02-25T01:59:07.703Z level=INFO source=cpu_common.go:11 msg="CPU has AVX2"
loading library /tmp/ollama1014444645/cpu_avx2/libext_server.so
time=2024-02-25T01:59:07.705Z level=INFO source=dyn_ext_server.go:90 msg="Loading Dynamic llm server: /tmp/ollama1014444645/cpu_avx2/libext_server.so"
...

When running:
ollama run llama2-uncensored

I ran into the same issue while running a set of tests using ollama version is 0.1.25.
Note each test loads a different LLM and this is reproduceable but only happens after large number of tests like 50 or more.
The configuration is windows 11 with wsl2 on ubuntu 22.04 using RTX 4070 TI.
After this error the system does not recover until after restart ollama server.
time=2024-02-24T22:54:20.311-08:00 level=INFO source=dyn_ext_server.go:156 msg="Starting llama main loop"
[GIN] 2024/02/24 - 22:54:38 | 200 | 21.560724222s |       <IP_ADDRESS> | POST     "/api/generate"
time=2024-02-24T22:54:38.515-08:00 level=INFO source=routes.go:78 msg="changing loaded model"
time=2024-02-24T22:54:38.607-08:00 level=INFO source=cpu_common.go:11 msg="CPU has AVX2"
time=2024-02-24T22:54:38.607-08:00 level=INFO source=gpu.go:146 msg="CUDA Compute Capability detected: 8.9"
time=2024-02-24T22:54:38.607-08:00 level=INFO source=cpu_common.go:11 msg="CPU has AVX2"
time=2024-02-24T22:54:38.607-08:00 level=INFO source=gpu.go:146 msg="CUDA Compute Capability detected: 8.9"
time=2024-02-24T22:54:38.607-08:00 level=INFO source=llm.go:111 msg="not enough vram available, falling back to CPU only"
time=2024-02-24T22:54:38.607-08:00 level=INFO source=cpu_common.go:11 msg="CPU has AVX2"
loading library /tmp/ollama3199692928/cpu_avx2/libext_server.so

Reproduce this issue on ubuntu 22.04.1 with RTX 4070 TI
uname -a
Linux kenneth-MS-7E06 6.5.0-21-generic #21~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Feb  9 13:32:52 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
kenneth@kenneth-MS-7E06:~$ ollama --version
ollama version is 0.1.27
Feb 29 12:32:11 kenneth-MS-7E06 ollama[1774]: time=2024-02-29T12:32:11.704-08:00 level=INFO source=llm.go:111 msg="not enough vram available, falling back to CPU only"

I am getting a similar error on M1 Pro chip. I am running 0.1.29 version which installed via homebrew.
time=2024-03-17T22:03:50.073+11:00 level=INFO source=llm.go:76 msg="not enough vram available, setting num_gpu=0"

AMD Integrated GPUs are not yet supported.  We're tracking that support with #2637
A few folks have chimed in with memory allocation topics.  We're working on improvements to our memory prediction which should help us better utilize the available memory in a future release.

How are you all able to change vRAM in you BIOS?  I'm running an HP and I don't have any options to do so.
Running Fedora 40
AMD Ryzen™ 7 5800U with Radeon™ Graphics × 16


Instructions for building on windows

Any chance you could update what is required to build this on windows?
Attempting to build with visual studio and getting a plethora of reference errors.. Thanks!

I added some instructions, hope this helps. Let me know if something is unclear.

If I don't apply the patch.patch file and include the meson.build file then I see an a.out file but running it does nothing, no output, just a return to the shell prompt.

@johnblommers you are talking about linux, the instructions are for windows

Yes I'm on Linux with hopes to try your flight sim one day soon. For now let me stand down and observe developments.

Got it working on windows - thank you for the instructions!


Optimize decode

Adds a baseline only to illustrate decode performance

dammit, should have started from master; FML


Expose Additional JMeter Result Saver Properties in the DSL

Reason for change: The naming pattern used by the JMeter ResponseFileSaver listener is a little bit weird when running on its default settings. This change exposes the variables that allow you to make file naming explicit as additional properties that can be set after construction.

Can you share in what scenarios you would usually disable such features and example test plan?

Sadly I cannot share an example test plan I don't think as my usage of this DSL involves a lot of custom work.
Scenario when this would be used: Using data being produced in one sampler in a later sampler. When doing this the additional control granted by changing these variables is extremely useful. Especially the numbering suffix as it was found to act a little strangely when combined with loops.


Homebrige can't run

I got a problem with the plugin.. can some one help me ? :/
[05/10/2021, 22:26:41] Plugin 'homebridge-loxone-connect' tried to register with an incorrect plugin identifier: 'homebridge-loxoneWs'. Please report this to the developer!
[05/10/2021, 22:26:41] Registering platform 'homebridge-loxone-connect.LoxoneWs'
[05/10/2021, 22:26:41] ---
[05/10/2021, 22:26:41] Loading 3 platforms...
[05/10/2021, 22:26:41] [Config] Initializing config platform...
[05/10/2021, 22:26:41] [Config] Running in Service Mode
[05/10/2021, 22:26:41] [google-smarthome] Initializing google-smarthome platform...
[05/10/2021, 22:26:41] [google-smarthome] Initializing child bridge 0E:21:D7:BB:CA:2F
[05/10/2021, 22:26:41] [LoxoneWs] Initializing LoxoneWs platform...
[05/10/2021, 22:26:41] [LoxoneWs] Getting Loxone configuration.
[05/10/2021, 22:26:41] [LoxoneWs] Platform - Waiting 8 seconds until initial state is retrieved via WebSocket.
[05/10/2021, 22:26:41] [LoxoneWs] WS: connect
[05/10/2021, 22:26:41] [HB Supervisor] Homebridge Process Ended. Code: null, Signal: SIGBUS
[05/10/2021, 22:26:46] [HB Supervisor] Restarting Homebridge...
[05/10/2021, 22:26:46] [HB Supervisor] Starting Homebridge with extra flags: -I -D
[05/10/2021, 22:26:46] [HB Supervisor] Started Homebridge v1.3.4 with PID: 10460
Initializing HAP-NodeJS v0.9.4...
[05/10/2021, 22:26:50] Loaded config.json with 0 accessories and 3 platforms.
[05/10/2021, 22:26:51] Loaded 0 cached accessories from cachedAccessories.
[05/10/2021, 22:26:51] ---
[05/10/2021, 22:26:56] Loaded plugin<EMAIL_ADDRESS>[05/10/2021, 22:26:56] Registering platform 'homebridge-config-ui-x.config'
[05/10/2021, 22:26:56] ---
[05/10/2021, 22:26:56] Loaded plugin<EMAIL_ADDRESS>[05/10/2021, 22:26:56] Registering platform 'homebridge-gsh.google-smarthome'
[05/10/2021, 22:26:56] ---
[05/10/2021, 22:26:57] Loaded plugin<EMAIL_ADDRESS>homebridge API version: 2.7
[05/10/2021, 22:26:57] Plugin 'homebridge-loxone-connect' tried to register with an incorrect plugin identifier: 'homebridge-loxoneWs'. Please report this to the developer!
[05/10/2021, 22:26:57] Registering platform 'homebridge-loxone-connect.LoxoneWs'
[05/10/2021, 22:26:57] ---
[05/10/2021, 22:26:57] Loading 3 platforms...
[05/10/2021, 22:26:57] [Config] Initializing config platform...
[05/10/2021, 22:26:58] [Config] Running in Service Mode
[05/10/2021, 22:26:58] [google-smarthome] Initializing google-smarthome platform...
[05/10/2021, 22:26:58] [google-smarthome] Initializing child bridge 0E:21:D7:BB:CA:2F
[05/10/2021, 22:26:58] [LoxoneWs] Initializing LoxoneWs platform...
[05/10/2021, 22:26:58] [LoxoneWs] Getting Loxone configuration.
[05/10/2021, 22:26:58] [LoxoneWs] Platform - Waiting 8 seconds until initial state is retrieved via WebSocket.
[05/10/2021, 22:26:58] [LoxoneWs] WS: connect
[05/10/2021, 22:26:58] [HB Supervisor] Homebridge Process Ended. Code: null, Signal: SIGBUS

I have the same issue.
When I try to set up the plugin to connect to the loxone miniserver I get the following errors in the log:
[12/5/2021, 9:57:37 PM] [LoxoneWs] WS: connect
Websocket Connection closed:  1000 normally closed
[12/5/2021, 9:57:39 PM] [LoxoneWs] WS: connect
WebSocket error:  Socket Error: undefined ERR_STREAM_WRITE_AFTER_END 1006
[12/5/2021, 9:57:39 PM] [LoxoneWs] WS: connection error, reconnecting...Error [ERR_STREAM_WRITE_AFTER_END]: write after end
Websocket Connection closed:  1006 Socket Error: undefined ERR_STREAM_WRITE_AFTER_END
[12/5/2021, 9:57:42 PM] [LoxoneWs] WS: connect
WebSocket error:  Socket Error: undefined ERR_STREAM_WRITE_AFTER_END 1006
[12/5/2021, 9:57:42 PM] [LoxoneWs] WS: connection error, reconnecting...Error [ERR_STREAM_WRITE_AFTER_END]: write after end
Websocket Connection closed:  1006 Socket Error: undefined ERR_STREAM_WRITE_AFTER_END

Until the following message shows up in the logs:
homebridge    | Websocket Connection closed:  1006 Socket Error: undefined ERR_STREAM_WRITE_AFTER_END
homebridge    | Websocket Connection closed:  4003 Forbidden - IP <IP_ADDRESS> temporarily blocked, too many failed login attempts (108)
homebridge    | Websocket Connection closed:  4003 Forbidden - IP <IP_ADDRESS> temporarily blocked, too many failed login attempts (108)
homebridge    | Websocket Connection closed:  4003 Forbidden - IP <IP_ADDRESS> temporarily blocked, too many failed login attempts (108)
homebridge    | Websocket Connection closed:  4003 Forbidden - IP <IP_ADDRESS> temporarily blocked, too many failed login attempts (108)

Homebridge is running in a docker(-compose) container in the same subnet as the loxone miniserver.
I was able to successfully login at the web-interface of the loxone mini-server with the credentials I have entered in the config file.
My miniserver is running on version <IP_ADDRESS>

Are you using a custom user or the root from loxone? Try using the root account, i’m looking in to this but it seems that i get the same error when using a self made user account inside loxone

Can you test if the problem still occurs with the latest version of this plugin?

Can you test if the problem still occurs with the latest version of this plugin?

The plugin works after a few days.  and works fine with the new update :)

Sorry for the delay in responding.
The issue has been resolved for me as well.
Thank you for the update.


Reacting to Razor changes - TagHelperOutput is writing to TextWriter instead of string.

https://github.com/aspnet/Razor/issues/296

/cc: @NTaylorMullen @dougbu

:watch:

:watch:

Updated. I have used .Append() instead of .SetContent() in ValidationSummary, Form and Select TagHelpers because of unit tests which needs them. Should this be the case for other tag helpers also? I think all the tag helpers should only Append() to content because they can be nested and should not overwrite the Content/PreContent/PostContent written by the parent. What do you guys think?

@sornaks should do Append when we used to do += and SetContent when we used to do =. Don't want to change that behavior

:watch: few more things, it's close

:watch:

Updated..

:shipit: once @dougbu is happy.

:shipit: do not hold up submission for ToString -> GetContent nits (unless that's a 10 min. change)

Checked in. Thanks guys! https://github.com/aspnet/Mvc/commit/284eb9ac6a4f69f80f2c767a6d35f40dbd091131


Use native Promise instead of setTimeout as it is not vulnerable to throttling

FF and Chrome are throttling setTimeout to 1000ms in inactive tabs:
https://bugzilla.mozilla.org/show_bug.cgi?id=633421
https://bugs.chromium.org/p/chromium/issues/detail?id=66078
I've encountered a problem with flaky test and after a while of debugging it turned out to be a problem with Yaku using setTimeout. Debug log statements happened in exact 1 second time distance, while they were called one after each other.
The reason for this was special behavior of Chrome on OSX, where setTimeout is clamped for a window that is not on the top.
The solution is to use native Promise if possible as this is closer to node nextTick.
Quick jsfiddle to play with this: https://jsfiddle.net/0npx5v5r/

Coverage remained the same at 100.0% when pulling e9dd61744bcf097d48e39549e5b50ec281673eba on gtanczyk:master into cc7bc0dcf817c7f5390eabd540dff1ebf689ce18 on ysmood:master.

That is a great idea, thanks!

By the way in the doc section https://github.com/ysmood/yaku#yakunexttick, I mentioned that you could use mature third party lib such as https://github.com/medikoo/next-tick, it might be better than your workaround.

I published the v0.18.3, please check it out.

It works as expected :+1:
My only concern are any sort of unit tests - anything that relied on sinon and fake timers in particular.
I think I will also contribute this idea to medikoo/next-tick, because using MutationObserver to resolve a promise does not sound good. :-1:

I added a test for it, but it's a very simple one, you can also check the code in 4fc271d.

using MutationObserver to resolve a promise does not sound good

If you dig into it, you will find out it's a good workaround and performance well on most of the browsers. For old browsers, I use https://github.com/YuzuJS/setImmediate.


Update minifi-java-agent-quick-start.md

Add clarity around configuration with json vs yaml

Summary
NIFI-00000
Tracking
Please complete the following tracking steps prior to pull request creation.
Issue Tracking

[ ] Apache NiFi Jira issue created

Pull Request Tracking

[ ] Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
[ ] Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

[ ] Pull Request based on current revision of the main branch
[ ] Pull Request refers to a feature branch with one commit containing changes

Verification
Please indicate the verification steps performed prior to pull request creation.
Build

[ ] Build completed using mvn clean install -P contrib-check

[ ] JDK 21

Licensing

[ ] New dependencies are compatible with the Apache License 2.0 according to the License Policy
[ ] New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

[ ] Documentation formatting appears as expected in rendered files

Thanks for the documentation improvements @wrender.
For tracking purposes, all changes need an associated Apache NiFi Jira issue, as listed in the pull request checklist.
You can request an account using the following link:
https://selfserve.apache.org/jira-account.html
After creating a Jira issue, simply update the pull request title with the Jira issue number.
If you have any questions, feel free to ask!


Added Flappy Bird Game

🛠 Fixes Issue (Number)
Closes #1601
👨💻 Changes proposed and Brief Description

Gameplay Mechanics: Improved for smoother experience.
Collision Detection: Enhanced for accuracy.
Code Organization: Optimized for better readability.
Performance: Boosted for seamless play.
Movement: Made bird and pipes move smoother.
Scoreboard: Implemented to track and display scores.
Scoring Mechanism: Adjusted for accurate updates.
Responsiveness: Improved overall responsiveness.
File Structure: Added Flappy Bird game folder (120).
Assets: Included a screenshot in the assets folder.
Integration: Updated game link in 30DaysOfJavaScript\script.js.
Website: Added game link to the website with a description.

✅ Check List (Check all the applicable boxes)

[X] My code doesn't break any part of the project
[X] This PR does not contain plagiarized content.
[X] My Addition/Changes works properly and matches the overall repo pattern.
[X] The title of my pull request is a short description of the requested changes.

📷 Screenshots
https://github.com/swapnilsparsh/30DaysOfJavaScript/assets/146121869/94eab1db-aef9-415d-9725-f0a3d34df818

@swapnilsparsh, I have made the changes you suggested. Please review the PR.


Catch JSON exceptions rather than crashing

Goal
We've previously made changes to wrap NSJSONSerialization to catch unexpected exceptions while encoding/decoding, but there is still an alternative path that hasn't been handled.
Design
Replicate the technique from BSGJSONSerialization in BSG_KSJSONCodec (wrap top-level APIs in try/catch blocks)
Changeset
BSG_KSJSONCodec has been modified such that the top-level APIs are guarded with try/catch blocks that log any errors.
Testing
Created a test app that exhausts memory in a region that uses the JSON serialization and observed the error messages prior to it crashing elsewhere from OOM.

Is there a way to have automated test coverage of this?

I'm not sure... So far the only exceptions I've managed are alloc exceptions during OOM situations. Other kinds of exceptions would require a bug in the codec.


Getting id from VNA

Some branches use qt-widgets, my branch use qml.
Think about common style-guide (for example: https://wiki.qt.io/Coding_Conventions)

@pradlol, @jpost1, @xorknown: Исправил.


Decide on a database

I'm suggesting we use SQL as 3rd years are familiar with it and can assist with 2nd years. As for how we deploy it, we can't actually implement this until we finish #1. I imagine we use MariaDB which is an open-source drop-in replacement for MySQL.

Here's the Docker image for MariaDB
https://hub.docker.com/_/mariadb
I think we should add npm scripts as shortcuts to setup and control this test database. Something like:

npm run dev_db:create --status=job_status.csv --data=auto_queue.csv - Creates db container and loads provided test data
npm run dev_db:start - Starts db container
npm run dev_db:stop - Stops db container


Kindle Highlights button does not appear in Settings pane

Browse to read.amazon.com.
Click "Show notes and marks" button in the Kindle web toolbar.
Kindle web page displays book highlights in a simulated modal dialog (KindleWebReader.pdf), unlike the way it appears in the Roam Highlighter demo.
Open Roam Highlighter Settings.
Kindle Highlights button does not appear in the Settings pane (RoamHighlighterSettings.pdf).

I love Roam Highlighter! Thanks!

From Ivo on Aug 19th
I don't see anymore the Kindle Highlight button

@lwrogersjr it is kind of "touchy" but you need to go directly to https://read.amazon.com/notebook
An important note, which I think was potentially Ivo's issue, is that if you are not currently logged in to Amazon and it asks you to login when you go to https://read.amazon.com/notebook then it appears it takes you to a bit of a different URL which Roam highlighter does not recognize and therefore doesn't show the Kindle extract options / buttons.
The solution is to simply click the link again in Roam Highlighter settings and then you should be good to go! See screenshot and GIF below for more details.
@lwrogersjr  please confirm it is working as expected so I can close the issue. Thanks!

Just opened a new Issue #63 to account for the issue of Roam Highlighter not recognizing the link Amazon takes you to after initial login.

Yes, Kindle Highlights works great for https://read.amazon.com/notebook.
Thanks!

Hi,
It seems there is an issue for non-US amazon accounts though. For instance in France, the URL is https://lire.amazon.fr/notebook ("lire" means "read", you get it)
I don't see the Kindle Highlights button, I guess that it is because that URL is not recognized.
Unfortunately I don't have access to my books if I log to read.amazon.com (probably to book copyright restrictions in other countries)
Any hint on how to solve it?
(thanks for the great extension, I'm using it a lot!)

Hi,
It seems there is an issue for non-US amazon accounts though. For instance in France, the URL is https://lire.amazon.fr/notebook ("lire" means "read", you get it)
I don't see the Kindle Highlights button, I guess that it is because that URL is not recognized.
Unfortunately I don't have access to my books if I log to read.amazon.com (probably to book copyright restrictions in other countries)
Any hint on how to solve it?
(thanks for the great extension, I'm using it a lot!)

@clement-moulin-frier I will be tracking this now in Issue #63 as others have reported similar issues.


Aqara motion sensors take very long to switch back to "no motion" can i adjust this? (Question not issue)

I just bought a Conbee 2 and installed Deconz/Phoscon. When migrating my sensors from the aqara hub to deconz i noticed a very big change in the reporting of the motions sensors. It takes roughly 2 minutes of no motion before state can be switched back. I am completely new to deconz/conbee, so to make a long story short "is there a way i can adjust this?"

homebridge-hue just forwards the status from deCONZ.  I don't have this device myself, but it's been discussed extensively in the deCONZ repository, see e.g. https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1671.

Thank you for the information will look in to it.


Unify std::os::raw::c_void and libc::c_void via libcore

Unify std::os::raw::c_void and libc::c_void by making them both re-exports of a definition in libcore.
HTML view

CC @rust-lang/libs

Nice RFC, thanks. Thumbs up. All those issues mentioned were tangentially blocked on making c_void and extern type or similar, but I think that change is orthogonal to where exactly we decide to put it. They also seemed blocked on the misunderstanding that we would have to maybe also move some other ctypes (e.g. c_int) to libcore or somewhere else, which isn't true either.

This RFC proposes core::ffi rather than core::os::raw on the basis that C-compatible types are misplaced in std::os::raw. std::os is documented as “OS-specific functionality”, but everything currently available under std::os::raw is about interoperabily with C rather than operating system functionality. (Although the exact definition of c_char, c_long, and c_ulong does vary based on the target operating system.) FFI stands for Foreign Function Interface and is about calling or being called from functions in other languages such as C. So the ffi module seems more appropriate than os for C types, and it already exists in std.

I don't personally want to bikeshed this, I think core::ffi for c_void is a fine location.
My understanding was that the reason these types where in ::os was that they size, alignment, etc. is OS / platform dependent. For example, c_int can be 32 or 64 bits (or something else), depending on the OS flavor you use.
That is, moving these types to core would make core platform dependent, but as I understood it, core should be platform independent.
The problem that extern type was trying to solve is that of making core platform dependent if we move c_void there. I think that's a problem worth solving, but since I haven't heard any arguments that suggest that moving only c_void to core would lead to any headaches, I think we could just do that later.

That is, moving these types to core would make core platform dependent, but as I understood it, core should be platform independent.

This is debatable, but let’s not open this subtopic in this thread since it only applies to integer C types, not c_void. This RFC does not propose anything for types other than c_void, specifically to avoid this question.

The unresolved questions about moving ctypes in std::os to std::ffi or similar, I'd just leave them open as to be resolved by some other RFC.

I agree, I’ve tweaked that paragraph to explicitly propose that.

trait VoidPointerExt {…}
impl VoidPointerExt for *mut std::os::raw::c_void {…}
impl VoidPointerExt for *mut libc::c_void {…}

With the two c_void types being unified, the two impls would overlap and fail to compile.
Hopefully such breakage is rare enough that we can manage it.

Afaict, this is the only way currently to make a function accept either type, so I doubt it is uncommon.
I presume that this is intended to be released as a minor version bump to libc...  is there a migration plan for this?  Some intermediate way to rewrite such code which is compatible with both old and new libc?
I doubt the semver trick can be used for something this big!

Is making a function accept either type useful? To the point that it’s worth going through the trouble of defining a public trait in your API? Compared to adding as _ at some of the call sites.
The libc crate is currently in version 0.2.x. I’m hoping we can get away with implementing this RFC in another  0.2.y version and won’t have to make a version that Cargo considers incompatible such as 0.3.0 or 1.0.0. In this case, you can have a dependency like libc = "0.2.45" and there won’t be a need to support older 0.2.x libc.
Moving the ecosystem from 0.1 to 0.2 was a huge pain, I’m not proposing we go through that again.
If you want to keep supporting older Rust versions and accept both types there, then I suppose you’d need a build script like the one proposed in the RFC for lib.

Is making a function accept either type useful?

That idiom is "fair" and works correctly, so I don't think the answer to this question matters at all.
This change can and will break crates that are not broken (this change is not a bug fix). So for me the question that matters is: How many crates does it break?
If it breaks hundreds of crates, we can't do this without doing a libc 0.3 release. If it breaks < 10 crates, I'd be ok with it, but others might not.
Anyways, for all I know, this change breaks no crates. We would need to do a crater run to figure this out.

I think the question of whether it is useful matters in trying to guess how common it is. But Crater is probably a better way to settle that.

Re extern type I'm concerned that we can break libc again but not core. If we do unstable DynSized, we can put ?DynSized on ptr::null and friends allowing them to be used with c_void. Hopefully that wouldn't be committing to too much.

Even if we fix up ptr::null somehow, there’s still other generic code (including outside of the standard library) that will stop accepting c_void if we change it from Sized to !Sized.

it's true. For libc that's just a matter of 0.3, for std::os::raw::c_void that's more worrisome. Maybe the std stuff should be deprecated, effectively solving the duplication problem, and then we do something about libc later?

A crater run is possible, we recently did one for lazy-static. If someone could prepare a PR for libc with the required changes I can look into running crater on it.

Oh awesome! How should libc be prepared? Would a git branch suffice? Or something on crates.io?

Git branch is sufficient, I believe.

Ok! I've uploaded a branch to https://github.com/alexcrichton/libc/tree/c-void

Okay I think I've started a crater run in check-only mode, we'll see how it goes. Generally speaking should have results in ~24-36 hours.

This has sat for a bit now and has been debated quite a bit in the past. This has also been cc'd in a large number of locations for some good visibility, so that makes me comfortable to propose FCP here! I think that this is a solid step forward in the FFI story for the standard library and definitely one we should take. While we may want to be more ambitious in the future this is at least a good starting point.
@rfcbot fcp merge

Right now it is implicitly understood we'll never be able to make c_void an truly unsized type: libc could take the major version bump but core cannot change. I think this is bad and yet more short-term thinking, but I'm probably the minority here. At least let's have this drawback spelled out explicitly rather than shoved under the rug.

In the past, “solving” c_void has been blocked on fixing the type, and any comprensive solutions for solving the C ABI have been blocked on fixing c_void first. This RFC solves neither: it just moves c_void without changing the type, and it doesn't create a comprehensive solution for all ABI types. The idea of this RFC was most definitely considered in #1783. What has changed in people's thinking such that this RFC is now considered good enough for merging?

I think it would be a shame if we stabilized c_void in its new location with a suboptimal type, but maintaining the std/libc incompatibility seems like a much bigger issue. This RFC seems good enough to me.

We could use the same configure-script-style-heck to just optionally depend on the std one.

Since crater has shown that libc can easily switch to re-exporting c_void from std why can't we just make libc re-export c_void from std when the appropriate feature is enabled? That way we get a unified c_void while being able to punt entirely on the issue of a suboptimal c_void in core.

@jethrogb I think “has been blocked” is one interpretation of those discussions. Some have expressed a preference for changing the definition of c_void to a new kind of type whose layout is truely unknown, instead of the current two-variant enum. This kind of type has since been implemented in Nightly as e.g. extern { type c_void; }. However it’s not clear that people realized at the time that this would be a breaking change: extern types are !Sized and std::ptr::null::<T>() requires T: Sized.
As to https://github.com/rust-lang/rfcs/pull/1783, it proposed moving all c_* types, and as mentioned in the RFC there were concerns with having operating-system-dependant APIs in libcore (which this RFC doesn’t propose), or with having a whole new crate for such a small API.

I think it would be a shame if we stabilized c_void in its new location with a suboptimal type,

Note that std::os::raw::c_void is already stable, all that this RFC is proposing is making it also available at a new location.
If/when we add a new better improved equivalent to C’s void*, regardless of its location I think it would be better to give it a name other than c_void to avoid confusion, so this RFC is also not preventing that.

@retep998 as discussed before it's a breaking change to do that due to libc having a feature to enable std. That means that if the use_std feature is disabled and a crate tries to pass a c_void to something that takes a std::os::raw::c_void it will get a type error.
The purpose of this RFC is to solve the problem once and for all with c_void rather than applying continual band-aids. With only one definition of c_void and everyone reexporting it then it should be impossible to have conflicting types.

@alexcrichton no it could be done with some build.rs hack unconditionally as this PR does it.
The actual "once and for all" solution would be making it an extern type once the temporary issues blocking use of these with ptr::null are worked out. I'd guess that would be 2 years. Can we really do something else just until then??

@Ericson2314 what @retep998 is proposing is not changing core at all, meaning that when libc is in #![no_std] mode it has nothing to reexport, forcing it to define its own version. That then clashes with std's version, meaning there's two types.

But why would someone use libc in #![no_std] mode with std at the same time? Surely they'd enable the std feature of the libc crate if they want libc::c_void to be compatible with std::os::raw::c_void?

But why would someone use libc in #![no_std] mode with std at the same time? Surely they'd enable the std feature of the libc crate if they want libc::c_void to be compatible with std::os::raw::c_void?

@retep998 a crate A can depend on libc in a no_std crate, and some other crate B that requires std can depend on crate A.
If crate A does not re-export libc's use_std feature, then you end up there.

@gnzlbg In the case where crate B is using c_void from crate A and expects it to be compatible with c_void from std and crate A refuses to provide any way to enable the use_std feature of libc, then crate B can depend on libc itself just so it can enable the use_std feature. As far as I know, there is no way for a crate to be unable to tell libc to enable the use_std feature when it needs c_void compatibility.

@gnzlbg This, incidentally, is a great example of why we have std features rather than no-std features.

@alexcrichton Also, for what it's worth, I hope in those same ~2 years (while extern type incubates) for stdlib-aware Cargo to be prioritized so we can drop all builds.rs hacks and have std and user code depend on the same libc, with its c_void. Ideal semantics DynSized + Referent<Meta=()> (or whatever it ends up being called) + ideal dependency order is my goal.

@Ericson2314 this is getting off-topic but, as we’ve discussed multiple times already, even with std-aware Cargo the libc crate used by std would still be a separate crate from libc from crates.io that everyone can use in their [dependencies], and the former copy of libc should still not be exposed to users.

Huzzah! This RFC has been merged!
Tracking issue: https://github.com/rust-lang/rust/issues/53856

@Ericson2314 I sometimes wait with merging RFCs when new arguments are made that haven't been addressed during FCP; but itseemed to me that the libs team was aware of the new concerns and made different trade-offs.
I recommend that you continue this conversation on the tracking issue over at  https://github.com/rust-lang/rust/issues/53856. If new significant concerns arise in the tracking issue, then the libs team can still decide to not go through with the RFC as planned.

I commented there.
On a meta level, I still feel like it's constantly an uphill battle to maintain the principle of small libraries with well-delineated purposes, as all mixes of prioritization and rushes (the former which I am much more sympathetic with) instead lead to things constantly being dumped in core. Already, I'm at the point where I feel the std/core division is irreparable, and core should become a std reexport, and a new facade over all-new crates below. But even if that flies, I worry that by the time things like alloc polymorphic and std-aware Cargo get to the front of the queue, it will be death by a thousand cuts over the accumulated decisions made without really considering possibilities. Hopefully its just a few more months until the 2018 edition is up, and then those get to the front of the queue, and not too much gets in the way between now and then.

When we soon have c_void in core it will be available to everyone, even #[no_std] crates that don't even depend on libc. As such I guess we could remove c_void from libc when we do the breaking libc bump discussed in https://github.com/rust-lang/libc/issues/547? Having it defined in fewer places should reduce confusion and make code more consistent.


area(worker/response): add support for redirect() method

Fixes #55

This PR adds support for the redirect of responses and adds two new methods.

The Response::redirect(url) method that takes in an URL and redirects with a default status code of 302

Response::redirect("https://github.com")

The Response::redirect_with_status_code(url, status_code) method that redirects with a custom status code

Response::redirect_with_status_code("https://github.com", 308)

The relevant FFI binding can be found here:
https://github.com/cloudflare/workers-rs/blob/1bc536dcf1d397a0dc3087a021a28d60c9c85d66/worker-sys/src/response.rs#L88-L94

[x] The PR has been tested in a playground project generated by wrangler
[x] Code has been linted
[x] Doc strings have been added

@DarthBenro008 that's great, thank you for taking this on! Couple of things...

Since the redirect method in the runtime expects an absolute URL (as far as I can tell relative paths won't work.. e.g. /admin/logout), I think we should consider changing the Rust helper method on Response to accept a url::Url param rather than the impl Into<String>. This way the Rust type system with enforce the requirement that the input to the method is a valid URL.  What do you think?

if you think we should accept relative paths (since this is more of a "framework" afterall..) then we'd need to do some Request inspection and find the URL host & scheme to reconstruct the new URL.

Since we already have a with_status method on Response, I am wondering if we should omit the redirect_with_status_code option... I totally see it being helpful for common redirects though, so I am a bit torn. The single method call is definitely less verbose than:

Response::redirect("https://cloudflare.com").map(|resp| resp.with_status(302))

Which requires the user to know to map the Result<Response, E> (which would need to be tested, I don't see why it wouldn't work, but you never know until you test 😉 )

If we leave _redirect_with_status_code, let's rename it redirect_with_status, but also return Err if the status code is outside the 300-399 range, since that is invalid and the runtime might already throw an error. There is some example code in here that might help you tackle this.

Thank you again for this PR, and sorry for the slow response.. I got some computer time on vacation, but heading back to relaxation for a bit 😆
cc/ @caass, @ocsfrank, @ObsidianMinor, @jyn514 or @jspspike who may have some additional input/thoughts on the above.

@nilslice Thanks for the detailed insights!

I completely agree that the helper method should take in an url::Url to enforce valid redirects, the boon in doing this is that the Implementation of url::Url already splits and has helper methods to gain host, relative paths, etc that would make life easier in this case

I had thought of this, but then I realised that implementing redirect_with_status_code would be more aligned with the JS functions one would typically find in a Browser, hence I thought to implement the same, in case we use the map | resp | there is a possibility that the user can provide any status_code they want (other than in the range of 3XX). I think the Result<Response, E> should be only used when they are creating an empty response (Response::empty()) for their custom needs (like a manual override). What do you think about this?

Sure! I'll add the range check so that we only support 3XX based custom codes 😃

There are only a fixed number of possible redirect status codes, right? If you want to allow choosing between them, we could have an enum of possible redirect codes, which wouldn't allow passing anything outside the 300-399 range by accident.
Hmm, I suppose that doesn't allow you to use redirect codes that are between 300-399 but not standardized. I don't know how common that is in practice - I think requiring you to use with_status for those might be an ok tradeoff.

If we leave _redirect_with_status_code, let's rename it redirect_with_status, but also return Err if the status code is outside the 300-399 range, since that is invalid and the runtime might already throw an error. There is some example code in here that might help you tackle this.

Why check it twice? If the runtime is already checking the status I don't think we need to check it a second time; especially since Workers are perf-sensitive.

@jyn514 for the same reason "Response::error is a footgun" 😆
Is there a difference or are you just asking questions?

@nilslice I didn't realize it was validated by the runtime - my understanding is that Response::error really would have worked for any status before, the method name just would have been odd. If it's checked by the runtime I don't know that it needs an explicit Result.

Yea, if we handle this range check elsewhere we should be consistent where applicable. The runtime just throws and exception which could be avoided if someone cares, though there isn't a whole lot to do.
I'm not concerned about perf here.

What I would suggest is, let's create one single function Response::redirect(url: url::Url, status_code: Option<Set of Redirect Codes>)
If the status_code is None we automatically wrap them with a 302. If the user wants to pass a status code, they would be only able to pass redirect codes that's specified by the Enum
How does this sound? @nilslice @jyn514

@DarthBenro008 hmm, why make it optional? I think it's useful to make the developer choose whether it's a permanent or temporary redirect; and that way there's only one way to specify the redirect instead of two.

@DarthBenro008 why don't we start with redirect_with_status which takes the url::Url and a u16 and does the range check for valid status codes.
Then we can consider adding the base redirect method later, which by default will add a 302 status code.
This way we get your PR merged without so much deliberation and can revisit this later on 🙂

@nilslice @jyn514 , I realised if we are expecting the user to provide url::Url we probably need to re-export the create so that it's consistent for the user to use the same url::Url as worker-rs. Should i include the same in this PR?

Implemented the suggested changes, I have not included specific enums for redirect code, but a range of 3xx to be consistent with the MDN Web Docs :smiley:

Hi @DarthBenro008 -
Thank you! Re-exporting the url::Url is a great idea. Please feel free to do so.

@nilslice , I have re-exported url::Url!

@caass @nilslice , Have amended the requested changes!


Update README with newest setup instructions

Went through the setup instructions with @camallen and updated a couple of things.
Review checklist

[ ] First, the most important one: is this PR small enough that you can actually review it? Feel free to just reject a branch if the changes are hard to review due to the length of the diff.
[ ] If there are any migrations, will they the previous version of the app work correctly after they've been run (e.g. the don't remove columns still known about by ActiveRecord).
[ ] If anything changed with regards to the public API, are those changes also documented in the apiary.apib file?
[ ] Are all the changes covered by tests? Think about any possible edge cases that might be left untested.

thanks @rogerhutchings 👍


Feature request: Allow upload of a picture with the real amp settings

Besides the YT video demoing the amp, It would be great to have either a picture or a link to one showing the settings used to capture the amp.
If that's not possible (storing images, etc), then a basic input for knobs position would be ok. Something like: channel, gain, volume, treble, mid, bass
Cheers!

Similar to https://github.com/scottcorgan/tonehunt/issues/245


fix(databases): GSheets and Clickhouse DBs are not allowed to upload files

SUMMARY
Our users are getting an Internal Server Error 500 when trying to upload files to GSheets databases, that's because such databases don't support file upload nor the Clickhouse ones thus we need to stop showing such options to the users and prevent that existing ones get displayed in the upload form.
Additionally,  schemas allowed field is dependent on having file upload enabled but doesn't appear that way, so we are rendering it only when user checks the Allow file upload checkbox and placing it underneath the file upload checkbox.
Wording changes:

Update field name to : "Allow file uploads to database" instead of "Allow data upload" and remove the tooltip
On the Schemas Allowed field, we should update "CSV Upload" text to be "File Upload" and "CSVs" to "files", including in the hint text

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
Before:

After:

TESTING INSTRUCTIONS

When selecting a DB type, if GSheet or Clickhouse is selected the Allow data upload checkbox is not displayed in the form
Enabled the file upload menu only if there is any exiting DB with allow_file_upload flag set to true and that is not GSheets nor Clickhouse
When the form to file upload files is opened, the Database dropdown must not contain any GSheets nor Clickhouse DB.

ADDITIONAL INFORMATION

[X] Has associated issue: https://github.com/apache/superset/issues/19247
[ ] Required feature flags:
[X] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

/testenv up

/testenv up


[BugFix] fix mistakenly pushed-down subfield to child

For sql like
select t.c1, t.c2.s1 from
(
select array_map(x -> (x + t.v1), t.a1) c1, t.st1 c2 from (select pc0.a1, sc0.* from pc0 join sc0) t
) t join pc0

When we try push the array_map expr to a child , the child must output all these used cols in the expr. The array_map used cols from both table pc0 and sc0, pushing it to any child is wrong. We should keep it above the join operator.
What type of PR is this:

[x] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Does this PR entail a change in behavior?

[ ] Yes, this PR will result in a change in behavior.
[x] No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

[ ] Interface/UI changes: syntax, type conversion, expression evaluation, display information
[ ] Parameter changes: default values, similar parameters but with different default values
[ ] Policy changes: use new policy to replace old one, functionality automatically enabled
[ ] Feature removed
[ ] Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

[x] I have added test cases for my bug fix or my new feature
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto-backported to the target branch

[x] 3.1
[ ] 3.0
[ ] 2.5
[ ] 2.4

[FE PR Coverage Check]
:heart_eyes: pass : 20 / 20 (100.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/optimizer/validate/InputDependenciesChecker.java
17
17
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/rule/tree/prunesubfield/PushDownSubfieldRule.java
2
2
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/RowOutputInfo.java
1
1
100.00%
[]

[FE PR Coverage Check]
:heart_eyes: pass : 20 / 20 (100.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/optimizer/validate/InputDependenciesChecker.java
17
17
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/rule/tree/prunesubfield/PushDownSubfieldRule.java
2
2
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/RowOutputInfo.java
1
1
100.00%
[]

[FE Incremental Coverage Report]
:heart_eyes: pass : 24 / 24 (100.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/optimizer/validate/InputDependenciesChecker.java
17
17
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/operator/scalar/LambdaFunctionOperator.java
4
4
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/rule/tree/prunesubfield/PushDownSubfieldRule.java
2
2
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/RowOutputInfo.java
1
1
100.00%
[]

[FE Incremental Coverage Report]
:heart_eyes: pass : 24 / 24 (100.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/optimizer/validate/InputDependenciesChecker.java
17
17
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/operator/scalar/LambdaFunctionOperator.java
4
4
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/rule/tree/prunesubfield/PushDownSubfieldRule.java
2
2
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/RowOutputInfo.java
1
1
100.00%
[]

[FE Incremental Coverage Report]
:heart_eyes: pass : 24 / 24 (100.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/optimizer/validate/InputDependenciesChecker.java
17
17
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/operator/scalar/LambdaFunctionOperator.java
4
4
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/rule/tree/prunesubfield/PushDownSubfieldRule.java
2
2
100.00%
[]

:large_blue_circle:
com/starrocks/sql/optimizer/RowOutputInfo.java
1
1
100.00%
[]

[BE Incremental Coverage Report]
:heart_eyes: pass : 0 / 0 (0%)

@Mergifyio backport branch-3.1


chore(deps): upgrade jenkins-x/terraform-aws-eks-jx to version 4.0.0

from: https://github.com/jenkins-x/terraform-aws-eks-jx

/retest


Revert condition formatting changes

This partially reverts commit 3eba78f45e7d61364efd11d73334641c17305b4c.
This reverts commit 3533ace946aaf8cc64ae4be9ead3221c35975884.
The changes to the condition message formatting were not really helpful,
since the condition summary gets translated to a TransitioningMessage,
which does not always make sense when it shows up in the UI.
https://github.com/rancher/rancher/issues/32165

cc @ibuildthecloud


Create a proper Version type

Closes https://github.com/wellcometrust/platform/issues/3766
Preliminary refactoring for https://github.com/wellcometrust/platform/issues/3770

oops robert got there first


NullPointerException -> isAssignableFrom [Class loading]

This bug might be a followup of the resolved issue 728
Environment:

Java 8
dynamically loaded Plugin with different Classloader
Plugin loaded by Spigot Server

Error
(I've included more Infos from the error log that might be useful)
[17:16:37] [Server thread/INFO]: [TestPlugin] Loading TestPlugin v2
[17:16:40] [Server thread/INFO]: [Driver] Direct driver instance<PHONE_NUMBER> created for server address localhost:7687
[17:16:44] [Server thread/INFO]: [org.neo4j.ogm.metadata.DomainInfo] Starting Post-processing phase
[17:16:44] [Server thread/INFO]: [org.neo4j.ogm.metadata.DomainInfo] Building byLabel lookup maps
[17:16:44] [Server thread/INFO]: [org.neo4j.ogm.metadata.DomainInfo] Building interface class map for 0 classes
[17:16:44] [Server thread/INFO]: [org.neo4j.ogm.metadata.DomainInfo] Post-processing complete
[17:16:44] [Server thread/WARN]: java.lang.NullPointerException
[17:16:44] [Server thread/WARN]: 	at java.lang.Class.isAssignableFrom(Native Method)
[17:16:44] [Server thread/WARN]: 	at org.neo4j.ogm.driver.TypeSystem.lambda$supportsAsNativeType$0(TypeSystem.java:43)
[17:16:44] [Server thread/WARN]: 	at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174)
[17:16:44] [Server thread/WARN]: 	at java.util.HashMap$KeySpliterator.tryAdvance(HashMap.java:1577)
[17:16:44] [Server thread/WARN]: 	at java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:126)
[17:16:44] [Server thread/WARN]: 	at java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:499)
[17:16:44] [Server thread/WARN]: 	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:486)
[17:16:44] [Server thread/WARN]: 	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
[17:16:44] [Server thread/WARN]: 	at java.util.stream.FindOps$FindOp.evaluateSequential(FindOps.java:152)
[17:16:44] [Server thread/WARN]: 	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
[17:16:44] [Server thread/WARN]: 	at java.util.stream.ReferencePipeline.findAny(ReferencePipeline.java:536)
[17:16:44] [Server thread/WARN]: 	at org.neo4j.ogm.driver.TypeSystem.supportsAsNativeType(TypeSystem.java:43)
[17:16:44] [Server thread/WARN]: 	at org.neo4j.ogm.drivers.bolt.types.BoltNativeTypes.supportsAsNativeType(BoltNativeTypes.java:129)
[17:16:44] [Server thread/WARN]: 	at org.neo4j.ogm.metadata.FieldInfo.<init>(FieldInfo.java:100)
[17:16:44] [Server thread/WARN]: 	at org.neo4j.ogm.metadata.FieldsInfo.<init>(FieldsInfo.java:67)
[17:16:44] [Server thread/WARN]: 	at org.neo4j.ogm.metadata.ClassInfo.<init>(ClassInfo.java:131)
[17:16:44] [Server thread/WARN]: 	at org.neo4j.ogm.metadata.ClassInfo.<init>(ClassInfo.java:111)
[17:16:44] [Server thread/WARN]: 	at org.neo4j.ogm.metadata.DomainInfo.lambda$addClass$1(DomainInfo.java:119)
[17:16:44] [Server thread/WARN]: 	at java.util.HashMap.computeIfAbsent(HashMap.java:1127)
[17:16:44] [Server thread/WARN]: 	at org.neo4j.ogm.metadata.DomainInfo.addClass(DomainInfo.java:119)
[17:16:44] [Server thread/WARN]: 	at org.neo4j.ogm.metadata.DomainInfo.create(DomainInfo.java:91)
[17:16:44] [Server thread/WARN]: 	at org.neo4j.ogm.metadata.MetaData.<init>(MetaData.java:57)
[17:16:44] [Server thread/WARN]: 	at org.neo4j.ogm.session.SessionFactory.<init>(SessionFactory.java:114)
[17:16:44] [Server thread/WARN]: 	at org.neo4j.ogm.session.SessionFactory.<init>(SessionFactory.java:100)
[17:16:44] [Server thread/WARN]: 	at org.neo4j.ogm.session.SessionFactory.<init>(SessionFactory.java:89)
[17:16:44] [Server thread/WARN]: 	at at.pl4yingnight.testplugin.database.Neo4j.conntect(Neo4j.java:27)
[17:16:44] [Server thread/WARN]: 	at at.pl4yingnight.testplugin.TestPlugin.onLoad(TestPlugin.java:34)
[17:16:44] [Server thread/WARN]: 	at org.bukkit.craftbukkit.v1_14_R1.CraftServer.loadPlugins(CraftServer.java:360)
[17:16:44] [Server thread/WARN]: 	at net.minecraft.server.v1_14_R1.DedicatedServer.init(DedicatedServer.java:226)
[17:16:44] [Server thread/WARN]: 	at net.minecraft.server.v1_14_R1.MinecraftServer.run(MinecraftServer.java:876)
[17:16:44] [Server thread/WARN]: 	at java.lang.Thread.run(Thread.java:748)
[17:16:44] [Server thread/INFO]: [TestPlugin] Loaded

From what I can tell it might have sth to do with casting and checking if it is the correct interface / class.
Dependencies
<!-- Neo4j -->
		<dependency>
			<groupId>org.neo4j</groupId>
			<artifactId>neo4j-ogm-core</artifactId>
			<version>3.2.5</version>
		</dependency>
		<dependency>
			<groupId>org.neo4j</groupId>
			<artifactId>neo4j-ogm-bolt-driver</artifactId>
			<version>3.2.5</version>
			<scope>runtime</scope>
		</dependency>
		<dependency>
			<groupId>org.neo4j</groupId>
			<artifactId>neo4j-ogm-bolt-native-types</artifactId>
			<version>3.2.5</version>
			<scope>runtime</scope>
		</dependency>

Reproduction
Contrary to last time I have no clue whats wrong this time, so it could also be my fault.
The Reproduction Code is in the same Location as last time: spigot-neo4j
Thank you in advance,
LG Pl4yingNight

Thanks again for the report. Please have a look at #743. I needed to rollback the solution to #728.
Basically what we have now is a configurable solution.
I have some remarks to your code.
OGM is a class mapping library. That is: It is more than a connection to Neo4j! It also maps database structure to Java objects, much like hibernate! Maybe you're better of not to use it but our plain driver (see https://github.com/neo4j/neo4j-java-driver).
In case you want to keep using it (and finding interesting bugs):

Please make sure you add at least one package to scan! This is super important, otherwise the root package, including all of Minecraft will be scanned
Don't keep the Session around, open as needed.
For your system configure the precedence of the class loader:

import org.neo4j.ogm.config.Configuration;

@Plugin(name = "TestPlugin", version = "2")
@Author(value = "Pl4yingNight")
@ApiVersion(Target.v1_13)
public class TestPlugin extends JavaPlugin {

	static {
		Configuration.CLASS_LOADER_PRECEDENCE.set(Configuration.ClassLoaderPrecedence.OGM_CLASS_LOADER);
	}
}

I have attached a working example based on your code.
TestPlugin.zip
Release will be out this week.

Thank you for fixing one of these specific bugs yet again and adding working example.
I'm well aware of what the OGM model is for and I use it because the Plugin I am developing is somewhat a carrier library for other dependent plugins and with that in mind I can't bother all the later users with just using the plain DB driver.
Since you are interested on what I am developing here.... as soon as I'm done with it I will let you know... (it will be available through maven)

Awesome, thank you for your feedback!
I mean, that usage is really interesting. Both from the domain and from the environment. Your issues helps.
The remark regarding usage was just to clear things up :) At times we find OGM in places where a plain driver would be a preferred solution.
Maybe it's a good idea to fail fast, if your plugin detects that no package has been configured. We tried to make OGM not to fall apart, but if you scan rt.jar or similar there are a gazillion things that might go wrong.


Service Broker HTTP requests are only logged at debug level

Issue
Interactions with service brokers are only logged at debug levels
Context
When a service broker is responding incorrectly, it is useful to be able to tell where in the Cloud Controller the requests to it originated from. This would help platform operators understand why a service or binding is in a certain state and the overall error rates of various brokers.
As service brokers represent fairly complex external systems that the platform operators may not have access to, being able to report what the Cloud Controller was trying to do is helpful when diagnosing integration issues with brokers. Debug logging is unfortunately far too noisy to be enabled the whole time so we would prefer this to be logged at either a different level or be able to enable debug logging specifically for service brokers.
Steps to Reproduce
Enable info logging in CC - see no logs about service broker interactions
Enable debug logging in CC - see logs about requests and responses with service brokers
Possible Fix
Raising this issue mostly to discuss approaches. As I see it there are a few different options we might take:

Change existing service broker client debug logging to info (affects all users)
Add additional (less rich) info level logging to the service broker client (affects all users)
Add a config option to include debug level logs specifically for the service broker client
Add a config option to log additional (less rich) info level logging in service broker client

Happy to contribute but would be good to get a steer on best direction given there is existing logging behaviour for the service broker client

Hey Andy!
@sethboyles and I looked into this and found the place where you would make this change here  We tested this locally and were able to see those logs, once concern we have is the headers being logged (which they are currently in debug).  We are seeing X-Broker-Api-Orginating-Identity followed by a token logged, this might not be a problem but we are unsure.
Seth and I like option 2, because then you wouldn't need to log the whole request body (which seems very noisy), we like the idea of adding info lines to the service-broker http client to capture request/response from the Service Broker.

That's really useful thanks @JenGoldstrich! I've raised https://github.com/cloudfoundry/cloud_controller_ng/pull/2293 which adds method, URL and the vcap request id (via the Steno context) and the response status which should hopefully be enough debugging information.


feat: proof-of-concept nano-contract integration

[!WARNING]
This PR was created only to showcase the integration with nano-contract. The code is not production ready. It should not be merged.

Acceptance Criteria

chore: link wallet-lib from branch feat/nano-wallet-integration
chore: add blueprints constants
chore: update @hathor/wallet-lib to v1.0.2
feat: add NanoContractSelector and NanoContractBlueprint
feat: polish information presentation of blueprint on NanoContractBlueprint
feat: add NanoContractInitialize component
chore: update @hathor/wallet-lib to v1.0.2-nanosdk.0

Security Checklist

[ ] Make sure you do not include new dependencies in the project unless strictly necessary and do not include dev-dependencies as production ones. More dependencies increase the possibility of one of them being hijacked and affecting us.

I'm closing this PR because it should not be merged.


Add Beok TOL47 wifi thermostat to supported devices

https://www.beok-controls.com/Content/upload/PDF/2021837153/TOL47-Heating-Thermostat-Manual.pdf

I'll fix up the hvac_action and hvac_mode later

Thank you,
i finished at now.
feel free to use it or modify. Thanks for the revision and help (it was my first activity on github)
name: Beok TOL47 thermostat
primary_entity:
entity: climate
dps:
- id: 1
type: boolean
name: hvac_mode
mapping:
- dps_val: true
value: "heat"
- dps_val: false
value: "off"
- id: 2
type: integer
name: temperature
mapping:
- scale: 10
step: 5
- id: 3
type: integer
name: current_temperature
mapping:
- scale: 10
- id: 4
type: string
name: preset_mode
mapping:
- dps_val: "cold"
value: Manual
- dps_val: "hot"
value: Program
- dps_val: "wind"
value: Temporary
- id: 5
type: string
name: hvac_action
mapping:
- dps_val: "0"
icon: "mdi:radiator-disabled"
constraint: hvac_mode
conditions:
- dps_val: true
value: idle
- dps_val: false
value: off
- dps_val: "1"
value: heating
icon: "mdi:radiator"
Regards, Zoli

Sorry, it seems I did not quite wait long enough.  Was there anything else you changed  besides the hvac_mode and hvac_action I suggested above?

@kekkutya Do you know what this sound switch is useful for? I have the same device and always wonder if this could be used for something smart.

 I guess one smart thing you could do is turn it off at night and on again in the morning with automations.

seems logical, but my device does not make sound at any position of the switch
@make-all: may you check issue #289 by escoand pls.? Seems some incompatibility with awatto wt100, when add a new device.

A fix for #289 was pushed about an hour ago.  There was a syntax error in the config for Avatto WT100, which was not picked up by unit tests.

seems logical, but my device does not make sound at any position of the switch

That's why I was asking...

This thermostat seems to share a lot in common with the Avatto WT100.  There may be a wider range by the same OEM manufacturer, with slight differences in spec.  It is possible that the beep hardware was left off the Beok TOL47, even though it is still exposed in the firmware.  It was mentioned in the Avatto manual that I read, and the original config came from the iot.tuya.com info for this device I suppose.  Does the official app expose this switch?  Maybe it is best moved to an attribute on the climate entity where it can still be observed, but the switch removed to prevent confusion.

Does the official app expose this switch?

Yes. As i see, the app screens exactly the same for both devices. And Beok's (not implemented yet) dp31 boolean is the "Reset" like in Avatto.


Page is not helpful

[Enter feedback here]
Why does this warning occur?
Show example producing the error and how to remedy it.
The page does not explain to beginners.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: a2c07441-073c-a4c5-a627-5fe0bf702fad
Version Independent ID: 8854362d-1527-3ede-70b6-a801aff1f1e3
Content: Compiler Warning (level 1) C4251
Content Source: docs/error-messages/compiler-warnings/compiler-warning-level-1-c4251.md
Product: visual-cpp
Technology: cpp-diagnostics
GitHub Login: @TylerMSFT
Microsoft Alias: twhitney

Hi, I have updated the example and the explanation. It should be live by Monday afternoon.
Take care.


Add OPEN_PAGES_MENU event

Fixes

Fixes #1077 by @dhruvkb
Description

Adds an analytics event for the opening of the pages menu. This is a quite simple one to implement.
While trying to push this I also noticed that after the merging of #2271, some of the generated translation files fail eslint:
openverse/frontend/src/locales/de.json
  171:29  error  Irregular whitespace not allowed  no-irregular-whitespace
  236:29  error  Irregular whitespace not allowed  no-irregular-whitespace
  472:29  error  Irregular whitespace not allowed  no-irregular-whitespace
  706:29  error  Irregular whitespace not allowed  no-irregular-whitespace

openverse/frontend/src/locales/fr.json
   68:28   error  Irregular whitespace not allowed  no-irregular-whitespace
   68:108  error  Irregular whitespace not allowed  no-irregular-whitespace
   68:112  error  Irregular whitespace not allowed  no-irregular-whitespace
   68:135  error  Irregular whitespace not allowed  no-irregular-whitespace
   68:143  error  Irregular whitespace not allowed  no-irregular-whitespace
   68:148  error  Irregular whitespace not allowed  no-irregular-whitespace
   68:156  error  Irregular whitespace not allowed  no-irregular-whitespace
   68:161  error  Irregular whitespace not allowed  no-irregular-whitespace
   68:173  error  Irregular whitespace not allowed  no-irregular-whitespace
   71:32   error  Irregular whitespace not allowed  no-irregular-whitespace
   92:39   error  Irregular whitespace not allowed  no-irregular-whitespace
  182:48   error  Irregular whitespace not allowed  no-irregular-whitespace
  182:56   error  Irregular whitespace not allowed  no-irregular-whitespace

openverse/frontend/src/locales/lv.json
  11:24  error  Irregular whitespace not allowed  no-irregular-whitespace

openverse/frontend/src/locales/ru.json
  321:230  error  Irregular whitespace not allowed  no-irregular-whitespace

I don't think we want to lint those files at all, so I've added them to the root .eslintignore. Does that seem right @obulat?
Testing Instructions

Run the frontend locally, reduce the viewport width to display the pages menu toggle, and activate the toggle. Observe the event in the browser console logs.
Checklist

[x] My pull request has a descriptive title (not a vague title likeUpdate index.md).
[x] My pull request targets the default branch of the repository (main) or a parent feature branch.
[x] My commit messages follow best practices.
[x] My code follows the established code style of the repository.
[x] I added or updated tests for the changes I made (if applicable).
[x] I added or updated documentation (if applicable).
[x] I tried running the project locally and verified that there are no visible errors.
[x] I ran the DAG documentation generator (if applicable).

Developer Certificate of Origin

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

@zackkrida, because of this issue I learned that some languages use NBSP (non-breaking space) between words and punctuation marks (more context in GlotPress: https://github.com/GlotPress/GlotPress/issues/801). Since json locale files are gitignored anyways, it seems appropriate to ignore them from linting, too.

Drafting while I add a unit test.

@obulat and @dhruvkb this is ready for review. I've added a test spec for the internal header with a unit test for this event.


Making messages more customizable

We are already able to customize the dictionary of messages simplelogin flashes. However, there is no easy way to:

Toggle messages on and off
Customize the categories of the flashes

Toggling could be useful if the user has implemented a custom login checker function, or if the user doesn't want to flash these messages. Custom categories could be useful for projects structured with different categories.
For example, if I have a project that uses:
'success'
'alert'
'info'
'warning'
and I try to use flask_simplelogin, the categories:
'danger'
'primary'
etc, could break an existing project structure.
I suggest something along the lines of:
show_messages = True

that can be configured just like the message dictionary.
Then, all flashes could be place inside an if statement, like this:
if show_messages:
      flash(self.messages['someKey'], 'someCategory')

I'm not quite as sure how custom categories would work. Parts of the source code went over my head.
For all I know, this could already be possible. If so, I'd suggest some updates to the README to clarify.
If not, maybe a nested dictionary could be used?
messages = {
'login-success', {'message':'someMessage', 'category':'someCategory'},
}

I don't know, I'm still a beginner, but I'd love to hear your thoughts on this, and to contribute where I can.

I do think it's a great idea and I'm willing to support anyone in developing this.
I have two minor comments, though:

I think that aligned with every other simple (one value) customization we have, I would encourage a setting SIMPLELOGIN_SHOW_MESSAGE instead of using an argument in the SimpleLogin(show_messages=False).
Regarding the messages, I'd go for a namedtuple instead of a dictionary, that is to say

messages = {
    'login-success': Message('someCategory', 'someMessage')
}

instead of:
messages = {
    'login-success', {'message':'someMessage', 'category':'someCategory'},
}

Just thinking out loud: maybe the same message argument could be used to turn the feature on/off.

SimpleLogin(app), implying messages = None, uses the defaults, which if show messages as defined in the package
SimpleLogin(app, messages=messages) uses the customized messages passed
SimpleLogin(app, messages=False) turns off the messaging feature

messages value/type
On/Off
Message texts

None
On
Default

dict
On
Customized

False
Off
N/A

I like that idea. That's a lot clearer and simpler way of doing it. My only concern is with access_denied and auth_error. I didn't realize those were return statements, I assumed the were all flash()
I guess it would make the most sense just the leave them as is, but it seems inconsistent, and harder to explain that way.
Once I've written some code, how do I share it with you? Is that what a pull request is for? Or is that only when everything is finished? Obviously I can't commit to a new branch, right?

Once I've written some code, how do I share it with you? Is that what a pull request is for?

Yes, that is what pull requests are for 🤘

Or is that only when everything is finished?

You can open a PR (pull request) as a draft (or work in progress), that is great for a more interactive cycle of feedback and development.

Obviously I can't commit to a new branch, right?

Actually that's the best strategy to create a pull request! I'll try to summarize the steps:

Fork this repository in your account
Clone your fork locally
Create a new branch for you to work on this features
Get started, yay
Commit progress to this new branch
Push changes to your remote repository (still in the feature branch)
At this point you can go back to GitHub page and open the PR
Also, once you open the PR, every commit pushed to that featured branch will be automatically included in the opened PR

Closed by #18


Pinball

Description
Dependencies

Bump doxygen to 1.10.0
Bump doxygen-awesome-css to v2.3.1

Instructions

Simplify Windows setup instructions
Improve Linux setup instructions
Fix various doxygen comments (remove disp)

Utils

Move fp_math.c from Magtoid Pocket to utils
Add fixed poitn vector and functions
Reworked geometry.c, added more collision checks

Build

Fix clang-format in the makefile for some systems
Clean up CMakeLists.txt

Mode

Add pinball mode (just a physics demo for now)

Test Instructions
lol, not yet
Ticket Links
negatory ghost rider
Readiness Checklist

[x] I have run make format to format the changes
[ ] I have compiled the firmware and the changes have no warnings
[ ] I have compiled the emulator and the changes have no warnings
[ ] I have run make cppcheck and checked that cppcheck_result.txt has no warnings for the changes
[x] I have added doxygen comments to any code used by more than one Swadge mode. This includes /*! \file comments with Design Philosophy, Usage, and Example sections for new headers.
[x] I have run make docs and checked that doxy_warnings.txt has no warnings for the new code

Yes, haha. It's missing a lot. I just wanted to play around with physics
and collisions and how many objects an ESP can handle in real time.
On Mon, Mar 4, 2024 at 1:19 PM Dylan Whichard @.***>
wrote:

@.**** approved this pull request.
In main/modes/pinball/mode_pinball.c
https://github.com/AEFeinstein/Super-2024-Swadge-FW/pull/208#discussion_r1511575923
:

// Free font

freeFont(&pinball->ibm_vga8);
// Free the rest of the state
free(pinball);
+}

+/**

@brief Run the pinball main loop

@param elapsedUs The number of microseconds since this function was last called

*/
+static void pinMainLoop(int64_t elapsedUs)
+{
// Make a local copy for speed
pinball_t* p = pinball;

You can't exit the mode since it never checks the button queue, but I
assume "add controls" is pretty high on the todo list
—
Reply to this email directly, view it on GitHub
https://github.com/AEFeinstein/Super-2024-Swadge-FW/pull/208#pullrequestreview-1914987234,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABYODGBYM57OIHY57WO4U3YWS3M3AVCNFSM6AAAAABEDKMGSOVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTSMJUHE4DOMRTGQ
.
You are receiving this because you authored the thread.Message ID:
@.***>


Performing an edit might result in an error when the data source is being updated by an Obervable

Performing an edit might sometimes result in an error when the data source is being updated by an Obervable.
Please see the attach error log.
smart-table-edit-error.txt

This seems to be an issue when the smart table is used together with Observables. I believe the best solution would be to allow for the smart table not to perform the edit operation on the data source. The updates can in this case be done by the Observable instead.
I've created a pull request to add this functionality.
Integration with rxjs and Observables now seems to be working correctly.


Quantum - Downloading a folder does nothing and errors in console

Closing, is same as https://github.com/threefoldtech/twin_aydo/issues/395


Sort badge display alphabetically (or consistently)

Would think it'd be less messy if they are always ordered alphabetically or in a consistent order.
E.g.:

"Verified" always ranked first

other ideas tbd

Are you thinking the display of them when listed, or when actually in the name, or both?

Actually in the name (more important), or both! Looks nicer that way imo


lumen + laravel-mongodb Unsupported driver [mongodb]

withFacades();

// $app->withEloquent();

/*
|--------------------------------------------------------------------------
| Register Container Bindings
|--------------------------------------------------------------------------
|
| Now we will register a few bindings in the service container. We will
| register the exception handler and the console kernel. You may add
| your own bindings here if you like or you can make another file.
|
*/

$app->singleton(
    Illuminate\Contracts\Debug\ExceptionHandler::class,
    App\Exceptions\Handler::class
);

$app->singleton(
    Illuminate\Contracts\Console\Kernel::class,
    App\Console\Kernel::class
);

/*
|--------------------------------------------------------------------------
| Register Middleware
|--------------------------------------------------------------------------
|
| Next, we will register the middleware with the application. These can
| be global middleware that run before and after each request into a
| route or middleware that'll be assigned to some specific routes.
|
*/

// $app->middleware([
//     // Illuminate\Cookie\Middleware\EncryptCookies::class,
//     // Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
//     // Illuminate\Session\Middleware\StartSession::class,
//     // Illuminate\View\Middleware\ShareErrorsFromSession::class,
//     // Laravel\Lumen\Http\Middleware\VerifyCsrfToken::class,
// ]);

// $app->routeMiddleware([

// ]);

/*
|--------------------------------------------------------------------------
| Register Service Providers
|--------------------------------------------------------------------------
|
| Here we will register all of the application's service providers which
| are used to bind services into the container. Service providers are
| totally optional, so you are not required to uncomment this line.
|
*/

// $app->register(App\Providers\AppServiceProvider::class);
// $app->register(App\Providers\EventServiceProvider::class);
$app->register(Jenssegers\Mongodb\MongodbServiceProvider::class);

$app->withEloquent();

/*
|--------------------------------------------------------------------------
| Load The Application Routes
|--------------------------------------------------------------------------
|
| Next we will include the routes file so that they can all be added to
| the application. This will provide all of the URLs the application
| can respond to, as well as the controllers that may handle them.
|
*/

$app->group(['namespace' => 'App\Http\Controllers'], function ($app) {
    require __DIR__.'/../app/Http/routes.php';
});

return $app;

?>
According to the operation of the document, but the error!
Unsupported driver [mongodb]

BUT:  DB::collection("")->find(); can perform？
why ?

@cnhttpd see #470


Great!

Thanks for your appreciation. We've completed a development version of the tutorial, so feel free to try it outs.


"layout": "raw" should render all unstyled elements, except

fixes https://github.com/shuding/nextra/issues/620
closes https://github.com/shuding/nextra/pull/628
before (table should be unstyled, not needed margin-top for p/blockquote/table)

after

@shuding I guess links should be also unstyled, only change that internal links should be replaced by NextLink

@shuding https://nextra-theme-docs-5c0l74glt.vercel.sh/docs/raw-layout
try to click on two links ;)
the first one will be replaced as he was written as [link](/docs)
the second will not be replaced as he wrote as docs

The links work well!


[WIP] Expose container projects in the service model

Expose container projects in the service model, so that they can be tagged in Automate.

Closing PR as requirement is fulfilled by https://github.com/ManageIQ/manageiq/pull/12863.


Namespace dogstastd

Rebase of https://github.com/DataDog/dogstatsd-ruby/pull/21.

Thanks for the review @yannmh ! Addressed both of your comments.


Cleanup documentation to render correctly in the readthedocs.org

See http://lxd-test.readthedocs.io/en/latest/ for a sample render of this branch

Looks good except for the broken link in README


vscodium

Hi,
I was wondering if I could ask you to publish the extention for vscodim, at https://open-vsx.org
Thanks in advance.

Hi,
For sure you can ask ;)
Good question. No reasons not to do it.
I'm currently very busy so you may has to wait a bit...
It should not be very time consuming so i will look a that some day.
Best.

Thanks

Ok, I'm more than late on this one but it's done.
Best.


Password required, inability to bypass

Describe the bug
A clear and concise description of what the bug is.
Integration requires password
To Reproduce
Steps to reproduce the behavior. Pleaee provide the error from the log if possible.
go to HA, attempt to add a new camera (or have one autodiscovered by HA and attempt to adopt device without a password
Expected behavior
A clear and concise description of what you expected to happen.
Ability to adopt a camera without a password as the default state does not assign a password.
Screenshots
If applicable, add screenshots to help explain your problem.
If you need more explanation, ill attach screen shotes.
Environment:
Please provide useful information about your environment, like:

Reolink NVR/camera model
NVR/camera firmware version

ANY reolink adoptable by Home Assistant
Additional context
Add any other context about the problem here.
We have had issues with people who had physical access to the cameras would factory reset them, knocking them out of config. so, we just adopt them all with factory settings and catch them in the act now.

At this stage it is not possible to communicate with a uninitialized camera since the HTTP(S) port of a unintialized camera is in most cases closed so the API that the Reolink integration uses will not be available.
See this part of the documentation: https://www.home-assistant.io/integrations/reolink/#1-initializing-and-configuring-camera-credentials
If you appreciate the reolink integration and want to support its development, please consider sponsering the upstream library or purchase Reolink products through this affiliate link.


Adapt samples to sync API and require pre-allocated output buffers

Fixed #57

@huningxin, I've verified all the samples with your PR locally, PTAL, thanks!

@huningxin, thanks for your comments! Fixed in new commits, PTAL again, thanks!


Change defaults in header

As discussed in #41, some fields have more reasonable default values than the ones we currently have. Are there any other fields that we should look into? (qform_code/sform_code?)

pixdim: [1.;8]
srow_x: [1, 0, 0, 0]
srow_y: [0, 1, 0, 0]
srow_z: [0, 0, 1, 0]

I have rebased this branch and included the suggested changes. It seems that the writer does behave differently based on whether the header states "sform_code = 2, qform_code = 1" or "sform_code = 2, qform_code = 0".

LGTM. Good job.

I think it's high time we had a release. I'll work on it later today.


schedge mascot is unclear

!

mascot pun remains hidden

Mascot pun will be delayed until Q3 of 2024 due to engineering constraints.

sounds like a you problem


affected/package: genetic bug in 1.18 beta

What version of Go are you using (go version)?

$ go version
1.18beta

Does this issue reproduce with the latest release?
...
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
windows11

What did you do?

this not ok :
https://go.dev/play/p/Lwe42hNUKje?v=gotip
What did you expect to see?
run ok, because both types are string alias
What did you see instead?
./prog.go:21:21: type s1 of m does not match inferred type s2 for P

I think this is working as designed. By declaring:
func min[P constraints.Ordered](x, y P) P {

you're saying that both x and y must be the same type P (whatever P turns out to be). And they're not. m is of type s1, and n is of type s2, and those are distinct types.

see above, closing as working as intended


Not working on safari browser to detect ios devices

Important Note
Before creating an issue, please note:
mobile-detect is just a kind of "satellite"-project. It uses the RegEx patterns of
Mobile-Detect and generates JavaScript source code
based on the code of its "mother"-project.
Missing patterns for particular devices cannot be added in mobile-detect.js,
instead you have to create an issue in Mobile-Detect.
Please provide the User-Agent string, the manufacturer and the type of device (phone, tablet, tv, bot, ...).
I won't replicate your issue to Mobile-Detect!
It doesn't make any sense to change generated code. I hope you understand.
Issue
[ ] I've read above note and I'm quite sure I have a real issue with mobile-detect.js
... you can delete above note and just describe your issue ...

@uditbh reading notices sometimes can solve problems and avoid unnecessary work. This kind of "contribution" is counter-productive.


ZEPPELIN-401 Improve autoscroll

Addresses https://issues.apache.org/jira/browse/ZEPPELIN-401
This PR improves autoscroll behavior when using keyboard navigation (up/down key)

When cursor closes to edge of top/bottom of notebook, autoscroll triggers
Autoscroll will scroll notebook to position cursor to the middle of browser window
When last paragraph is executed, a new paragraph is inserted after. now notebook autoscrolls to newly inserted paragraph.

Ready to merge

I will take a look at this PR too then

Awesome, makes everything smoother.
One bug I found though, Is that the cursor cannot move to a paragraph where the output is hidden.

@corneadoug Thanks for testing. pushed a commit to address the bug.

Good For Merge

Merge if there're no more discussions

Thanks for the bug fix.
I noticed that it works great when there is no horizontal scrolling. However, when there is output of paragraphs which extends beyond horizontal screen, it scrolls the window horizontally as well.

@gauravkumar37 Thanks for sharing a problem. I have created a fix https://github.com/apache/incubator-zeppelin/pull/419


[BUG] Failed to inspect the backup backing image information if NFS backup target URL with options

Describe the bug
If the backup target URL is assigned with options like nfs://longhorn-test-nfs-svc.default:/opt/backupstore?nfsOptions=soft,timeo=330,retrans=3
it will fail to get the backup backing image information with the inspect API.

time="2024-10-24T02:19:22Z" level=error msg="Error inspecting backup config" func="controller.(*BackupBackingImageCo
ntroller).reconcile" file="backup_backing_image_controller.go:322" backupbackingimage=parrot001 controller=longhorn-
backup-backing-image error="failed to get backup backing image config nfs://longhorn-test-nfs-svc.default:/opt/backu
pstore?nfsOptions=soft,timeo=330,retrans=3?backingImage=parrot001: failed to execute: /var/lib/longhorn/engine-binar
ies/longhornio-longhorn-engine-master-head/longhorn [/var/lib/longhorn/engine-binaries/longhornio-longhorn-engine-ma
ster-head/longhorn backup inspect-backing-image nfs://longhorn-test-nfs-svc.default:/opt/backupstore?nfsOptions=soft
,timeo=330,retrans=3?backingImage=parrot001], output , stderr warning: GOCOVERDIR not set, no coverage data emitted\
ntime=\"2024-10-24T02:19:22Z\" level=fatal msg=\"Failed to run inspect-backing-image command\" func=cmd.BackupCmd.In
spectBackingImageCmd.func6 file=\"backup_backing_image.go:62\" error=\"invalid backing image name parsed: \"\n: exit
 status 1" node=rancher80-worker2

NAME        BACKINGIMAGE   SIZE      BACKUPCREATEDAT   STATE       LASTSYNCEDAT
parrot001   parrot001      1161728                     Completed   <no value>

To Reproduce

Set up the backup target URL to nfs://[nfs-server]:[path]?nfsOptions=soft,timeo=330,retrans=3
Backup a backing image to this backup target
The backup backing image information will never be synchronized.
The backup backing image can not be deleted.

Expected behavior

The backup backing image information will be synchronized.
The backup backing image can be deleted.

Support bundle for troubleshooting

Environment

Longhorn version: master-head, 1.7.x, 1.6.x
Impacted volume (PV):
Installation method (e.g. Rancher Catalog App/Helm/Kubectl): Kubectl
Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version: v1.30.1+k3s1

Number of control plane nodes in the cluster: 1
Number of worker nodes in the cluster: 2

Node config

OS type and version: ubuntu 2204
Kernel version: 5.15.0-91-generic
CPU per node: 4
Memory per node: 4096
Disk type (e.g. SSD/NVMe/HDD): SSD
Network bandwidth between the nodes (Gbps): 1G

Underlying Infrastructure (e.g. on AWS/GCE, EKS/GKE, VMWare/KVM, Baremetal): KVM
Number of Longhorn volumes in the cluster: 1

Additional context

Workaround and Mitigation

Temporarily change the backup target URL to the one without the NFS options as
nfs://longhorn-test-nfs-svc.default:/opt/backupstore?nfsOptions=soft,timeo=330,retrans=3
to
nfs://longhorn-test-nfs-svc.default:/opt/backupstore

Great catch!

cc @james-munson @ChanYiLin

Verification passed on master-head (longhorn-manager 1925819) following the test plan.
The issue can be reproduced in v1.7.1.
$ kubectl get backupbackingimages.longhorn.io -n longhorn-system
NAME     BACKINGIMAGE   SIZE      BACKUPCREATEDAT   STATE       LASTSYNCEDAT
test                    0                                       <no value>
test-1   test-1         1161728                     Completed   <no value>

$ kubectl logs longhorn-manager-29gnf -c longhorn-manager -n longhorn-system | grep "Error inspecting backup config"
time="2024-11-04T02:52:30Z" level=error msg="Error inspecting backup config" func="controller.(*BackupBackingImageController).reconcile" file="backup_backing_image_controller.go:318" backupbackingimage=test controller=longhorn-backup-backing-image error="failed to get backup backing image config nfs://longhorn-test-nfs-svc.default:/opt/backupstore?nfsOptions=soft,timeo=330,retrans=3?backingImage=test: failed to execute: /var/lib/longhorn/engine-binaries/longhornio-longhorn-engine-v1.7.1/longhorn [/var/lib/longhorn/engine-binaries/longhornio-longhorn-engine-v1.7.1/longhorn backup inspect-backing-image nfs://longhorn-test-nfs-svc.default:/opt/backupstore?nfsOptions=soft,timeo=330,retrans=3?backingImage=test], output , stderr time=\"2024-11-04T02:52:30Z\" level=fatal msg=\"Failed to run inspect-backing-image command\" func=cmd.BackupCmd.InspectBackingImageCmd.func6 file=\"backup_backing_image.go:62\" error=\"invalid backing image name parsed: \"\n: exit status 1" node=ip-10-0-1-127

And it's fixed in master-head:
$ kubectl get backupbackingimages.longhorn.io -n longhorn-system
NAME     BACKINGIMAGE   SIZE      BACKUPCREATEDAT        STATE       LASTSYNCEDAT
test     test           1161728   2024-11-04T02:46:05Z   Completed   2024-11-04T03:05:58Z
test-1   test-1         1161728   2024-11-04T02:53:56Z   Completed   2024-11-04T03:05:58Z
test-2   test-2         1161728   2024-11-04T03:07:12Z   Completed   2024-11-04T03:07:14Z

$ kubectl logs -l app=longhorn-manager -c longhorn-manager -n longhorn-system | grep "Error inspecting backup config"
# Empty