Multiple builds required

Describe the bug
Multiple builds are required before my main css file is generated (usually 2, sometimes 3). Sometimes it doesn't even get generated at all unless I delete all the generated .css files first.
I use SASS, all my .sass files are in a Razor Class Library, I have a general file, under Styles/app.sass, compiled into wwwroot/app.css of the same assembly, and other files are coupled to components for css isolation.
In my main project it's actually broken CSS isolation, I have no idea how to fix it.
To Reproduce
Steps to reproduce the behavior:

Create a simple Blazor Server App
Add a RCL to the solution and reference it from the Blazor project
Move the razor components to the RCL project (keep App.razor and Routes.razor in Blazor project)
Add a reference to AspNetCore.SassCompiler from the RCL project (using ReferenceOutputAssembly="false")
Add necessary references:

Router: <Router AppAssembly="typeof(Program).Assembly" AdditionalAssemblies="@( new[] { typeof( MainLayout ).Assembly } )"> (MainLayout.razor lives in the RCL project)
Program.cs: app.MapRazorComponents< App >().AddInteractiveServerRenderMode().AddAdditionalAssemblies( typeof( MainLayout ).Assembly );

Add sasscompiler.json to the RCL project with the following content:

{
  "ScopedCssFolders": ["."],
  "Source": "Styles",
  "Target": "wwwroot",
  "Configurations": {
    "Debug": {
      "Arguments": "--style=expanded"
    }
  }
}

Expected behavior
When building, the file wwwroot/app.css should be generated (in the RCL project), and it's never generated on first build. Once it's built a couple of times, the file appears, once it's there, it doesn't always get updated unless I delete it and all other generated css files.
Desktop (please complete the following information):

OS: macOS Sonoma 14.6.1
IDE: Rider 2024.2.5

BlazorSass.zip
Here's a brand new solution where the bug occurs. I will try to get hold of another computer to test there.

BlazorSass.zip
Here's a brand new solution where the bug occurs. I will try to get hold of another computer to test there.

I have tested this same solution on another computer (Windows PC, Rider and Visual Studio) and the exact same thing happens.

Hi @sebdesalvador ,
Thanks for providing the solution that reproduces the problem you're seeing.
I've taken a look at it and noticed that in the sasscompiler.json you added "ScopedCssFolders": ["."], is there a specific reason for this?
The issue is that because you added that setting, the first time it compiles the sass files it sees the Styles folder as a scoped css folder, so it compiles the Styles/app.sass file to Styles/app.css. The second time the sass files are compiled, Styles/app.css is already up to date, so then it will compile Styles/app.sass to wwwroot/css/app.css. This has to do with the order we pass the arguments to the sass compiler.
If you remove the setting for the ScopedCssFolders from the sasscompiler.json, it will include some default directories but not the Styles folder, meaning it will correctly compile the files in the Styles folder to the wwwroot/css folder.


Write a message trying to make it clear the intention of this track

This PR adds the notice message discussed in #196.

@rchavarria Thanks again for doing this!  Seems like the track is gaining momentum.

 That would be awesome!


Bugfix- findChessboardCorners causes crash (Issue# 5145)

findChessboardCorners causes crash due to out-of-bounds memory corruption. Refer to issue #5145 for detail.

findChessboardCorners causes crash due to out-of-bounds memory corruption. Refer to issue #5145 for detail.

Do I have to do any to merge the change to Itseez:master?
Thanks.

@robertxwu Thanks!
I can confirm crash fix for test image/code from the issue.
Could you please squash commits into one (intermediate changes in git history are not necessary):
git checkout Bugfix_Issue#-5145
git rebase -i HEAD~4  # (`p` for first commit and `s`/`f` for another)
git push -f <your_github_remote> Bugfix_Issue#-5145

See #5396


Poor randomisation function?

Loving the bot so far, but recently discovered that it's prone to 'streaks', batches of consecutive numbers or results within 1 of each other. I rolled 100dX a few times and every batch of rolls had 5+ such streaks, such as 100d20 resulting in +10+8+10+7+10+10+10+9+10+10+10 and later in the same batch +17+17+17+18+17. Far from impossible but it's statistically unlikely for this to happen more than once per 100dX batch of rolls. A pattern is clearly visible, which kind of defeats the point of randomization. I would recommend creating a more robust and varied seed function from which to derive numbers.
salty af on account of critically fumbling three times in a row due to this.
Thanks for considering this issue.

Thanks for the heads up.
The seed is /dev/urandom, according to the docs (https://github.com/rust-lang-nursery/rand). It should be good enough.
What I might be missing is reusing a generator instance instead of just spamming a static function.
I'll see if I can reproduce this.

So I did a small test
  let mut longest_streak = 0;
  let mut streak = 0;
  let mut prev = 0;
  for _ in 0..99 {
    let r = roll (10);
    if r == prev {streak += 1; if streak > longest_streak {longest_streak = streak}} else {prev = r; streak = 0}}
  println! ("longest_streak: {}", longest_streak);
  assert! (longest_streak < 3, "largest_streak: {}", longest_streak);

and I can't I reproduce the phenomena. The number of streaks I encounter looks normal to me, I don't see a bias.
Cursory examination of the logs doesn't give anything either.

Now, it's not a crime if the random number generator produces the same number now and then. Such streaks stand out to our perception but they are in no way a proof of poor randomness.
I would like to, but I didn't have the time to go over the tests in https://www.random.org/analysis/ (I have, in fact, downloaded and compiled the NIST test suite, but it's command line interface is lacking in user-friendliness and can't be used without digging further into the sources and/or the paper).
On a side note I'd like to mention "A Basic Introduction to Probability" section in the Angry's article.
And a funny scene from "Rosencrantz and Guildenstern Are Dead", a  film by Tom Stoppard.

To quote Angry: "In essence, probability about determining the chance of a given outcome of an event. But that probability doesn’t erase the fact that the event is random. You might have a 95% chance of hitting the goblin on your next attack roll, but that doesn’t mean you can’t roll a 1. And it might be very unlikely, but you can roll three 1s in a row.
You can design a system wherein the players will succeed on 80% of their actions, but any given action might succeed and it might fail and any player might get a run of really bad or really good luck. The outcomes are still random.
When an individual player talks about probabilities, they usually want to know the chance of getting a specific outcome. What’s the chance I’ll roll a 15 for my Strength score if I roll 3d6? If I roll 4d6? What’s the chance I’ll get a 10 or above? What are the chances I’ll manage to kill this goblin this round? And the problem with those questions is that they are talking about a SINGLE EVENT."

FYI, https://www.reddit.com/r/rust/comments/87qy40/history_of_the_rand_crate/

https://en.wikipedia.org/wiki/Clustering_illusion

“Finally, psychologists have demonstrated that humans have a very poor intuitive understanding of randomness. We struggle to comprehend the fact that HHHHH is just as likely an outcome of five coin tosses as HTHTT. This seems to be the source of a whole range of biases impacting our decision-making.” - https://www.menimagerie.com/manuscripts/2018/6/9/viii-bayes-and-brains


When editing profiles, the 'defaults' that are shown are not the original/correct ones

This is what I get when editing a heat-pump profile for instance:

This was more of a database issue. The technology-keys in the couple-table were bad for Heat pumps. I've fixed it by manually changing the 4 rows in the database.


Make Flask example follow PEP8

Current Flask example does not follow the PEP8 newline rules.

Double newlines aren't really used in lots of places; see the most popular Python question on StackOverflow. Feel free to reply if I'm missing something.


Replace SScript with ToprakScript

/Users/runner/work/FNF-PsychEngine/FNF-PsychEngine/.haxelib/SScript618/git/src/hscriptBase/Expr.hx:47: characters 61-62 : Unexpected ) Can you fix for MacOS build?

/Users/runner/work/FNF-PsychEngine/FNF-PsychEngine/.haxelib/SScript618/git/src/hscriptBase/Expr.hx:47: characters 61-62 : Unexpected ) Can you fix for MacOS build?

source/states/PlayState.hx:289: characters 20-21 : Unexpected . Weird error. I wonder why LOL


fix agent extension shadow jar, backport smoke tests to java 8

snyk already got updated here  😸  https://github.com/newrelic/newrelic-jfr-core/pull/163/commits/4a275db531ff99e0ec0affd3a1b2eb115ffafd23


remove log dependency

Currently, Mio depends on log. In rust-lang/log#552, the log maintainers aim to increase log's MSRV to 1.60. This MSRV increase would impact Mio, which in turn, would impact Tokio. As of 1.25, Tokio supports Rust 1.49 with the intent of supporting it until March 2024.
Mio mostly uses the log dependency for debugging/tracing. Removing the log dependency has minimal impact and is the easiest way to resolve the MSRV issue. Additionally, this is another step towards minimizing Tokio's dependencies.

I have no idea why FreeBSD CI is failing.

I'm very much against this. I use the logs to debug problems.

Are you OK with making it a dev dependency?

Though, I don't think there is a great way to check if dev dependencies are available conditionally.
@Thomasdezeeuw What do you propose? Tokio cannot depend either directly or transitively on any crates that break its MSRV policy.

No as users need to enable it when the have a problem, if we have it in the tests only it's pretty useless.

Though, I don't think there is a great way to check if dev dependencies are available conditionally.
@Thomasdezeeuw What do you propose? Tokio cannot depend either directly or transitively on any crates that break its MSRV policy.

That's nearly even crate. A MSRV policy just doesn't work, we need something better like e.g. 6 months support of released rust versions, but that's a large story.

Another option is to gate it by a --cfg flag. Then, downstream users can enable it if they want.

That's nearly every crate. A MSRV policy just doesn't work, we need something better like e.g. 6 months support of released rust versions, but that's a large story.

Perhaps, but for a library like Tokio, I consider the ability to have toolchain stability valuable. We have an LTS/MSRV policy today that we need to try to maintain.

It might make sense for mio to define its own diagnostics APIs that we can plug log or tracing or Big Corp's Bespoke Logging into.
That way we could minimize the amount of code mio itself depends on, and let you tailor those diagnostics very specifically to mio's needs.

It might make sense for mio to define its own diagnostics APIs that we can plug log or tracing or Big Corp's Bespoke Logging into.
That way we could minimize the amount of code mio itself depends on, and let you tailor those diagnostics very specifically to mio's needs.

Isn't that the point of the log crate? It's only a facade and not a concrete implementation because of this right?

@Thomasdezeeuw You're totally right, and we try hard to make it as broadly compatible and opinion-free as possible. But it's still an outside artifact. If you need strict control over some property of your system that a dependency isn't satisfying then you're pretty much stuck taking responsibility for implementing it yourself.

I'm not sure if it will work but can Tokio (v1.25) add a direct dependency on log setting the version to =0.4.17, I think that will not allow upgrading beyond v0.4.17. It's an annoying limitation for people who don't care about the MSRV, but it might resolve the issue at least.

I don’t believe that would work. Given a dependency tree, finding the idea set of versions that satisfies it is an NP complete problem. To run dependency resolution in a reasonable time, cargo will opt to duplicate dependencies.
In this case, depending on how it traverses the dep tree, it could end up with two versions of log. Besides still having the MSRV issue, multiple versions of log could cause other problems for users because log uses static variables to store the specific logger.

I might be misremembering, but I don't think cargo allows for multiple versions of the same crate in the dependency tree within the same "semver series" (e.g. having both a copy of 0.4.1 and 0.4.3 of the same crate, while 0.4.3 and 0.3.0 is fine).

On the subject of MSRV, I think your interpretation of the MSRV policy for mio is excessively stringent here.
As long as mio doesn't depend on log >= 0.4.18 (which forces the use of Rust 1.60), it is possible to use mio in a project built with Rust 1.49—it's the responsibility of the project owner to pin transitive dependencies to an acceptable range.
Removing log (or, even worse, forcing the entire ecosystem to hold back by pinning it) is unnecessary in my opinion.

Tokio maintains LTS branches to support users that prefer toolchain stability (i.e., they would instead update occasionally vs. constantly). In case of a security fix or a major bug fix, we will backport these fixes to the LTS branches. This way, more conservative users can get the fixes without the risk of disruption from regressions introduced by more significant changes.
In the event of a security or significant bug in a transitive dependency, we also need Tokio users to be able to get those fixes. For example, if a security issue is discovered and fixed in log, Tokio users on an LTS branch need to be able to get that patch. If log has since raised its MSRV, we are stuck.
Additionally, I would like Tokio's LTS branch CI to be green. When we backport fixes to LTS branches, I would like the process to be as smooth as possible. We don't currently check in Cargo.lock files in, and I would rather not have to do so in the future (for the same reason, it is not recommended for libraries to check in Cargo.lock files to git).

Removing log (or, even worse, forcing the entire ecosystem to hold back by pinning it) is unnecessary, in my opinion.

I agree that forcing the entire ecosystem to a pinned version of log would not be ideal. Given the points above, I see two ways forward. a) log sticks with a more conservative MSRV, or b) Tokio removes log from its dependency tree. I am not here to dictate what crates outside of tokio-rs do, so I'm currently leaning toward option b.

In the event of a security or significant bug in a transitive dependency, we also need Tokio users to be able to get those fixes. For example, if a security issue is discovered and fixed in log, Tokio users on an LTS branch need to be able to get that patch. If log has since raised its MSRV, we are stuck.

Having log behind a feature flag seems to be enough to handle this scenario?

A potential alternative solution would be to replace the log dependency in mio with tracing, allowing us to continue emitting the same diagnostics. tracing is part of the tokio-rs org, and its MSRV will always be compatible with tokio's MSRV (I'm willing to commit to this guarantee as a maintainer). tracing has an optional, default-off log dependency, which upstream mio users can still enable if they want to collect log diagnostics, but it does not include non-MSRV-compliant crates in its dependency tree by default.

I don't really want to switch to the tracing crate as the log crate is sufficient for our purposes, furthermore that would be a breaking change as the logs won't appear if you don't have a tracing implementation/logger set up (assuming they don't enable the log feature on the tracing crate).

I agree that forcing the entire ecosystem to a pinned version of log would not be ideal. Given the points above, I see two ways forward. a) log sticks with a more conservative MSRV, or b) Tokio removes log from its dependency tree. I am not here to dictate what crates outside of tokio-rs do, so I'm currently leaning toward option b.

I don't think it's fair to the ecosystem to hold back the log crate because some users require support for a very old rust version, so I'd say a is unreasonable.
That leaves option b... but I don't want to remove it for non-Tokio TLS users as the logs allow you to quickly debug issues.
Maybe Tokio TLS version can use mio-tls version that uses an older MSRV that removes the log dependency. The problem there is that if people report a problem with this version they'll need to do some kind of logging or system call tracing on their own.

Maybe Tokio TLS version can use mio-tls version that uses an older MSRV that removes the log dependency. The problem there is that if people report a problem with this version they'll need to do some kind of logging or system call tracing on their own.

Do you mean maintaining a fork of mio named mio-lts that removes the log dependency?
When it comes to debugging problems, could we rely on tools like strace and other OS level tooling for getting data? What sort of data do you hope to get on top of what OS-level tooling can provide?

@Thomasdezeeuw how hard would it be to add a feature to use tracing instead of log?
By default mio would still use and depend on log, and if tracing is enabled, it would use and depend on that instead.

@Thomasdezeeuw how hard would it be to add a feature to use tracing instead of log?
By default mio would still use and depend on log, and if tracing is enabled, it would use and depend on that instead.

tracing has a feature "log" which brings in log as a dependency and emit log events instead.
So maybe mio could actually switch to tracing, add a new feature "log" that is enabled by default for backwards compatibility.
Crates like tokio can disable default features so that it is not affected by the msrv bump.

Yes, just another branch in this repo that Tokio TLS versions can depend on.

If we go that route, I would most likely lean towards pulling Mio into Tokio itself instead of adding a separate crate.

Has the possibility of having it be an ordinary optional dependency been discussed anywhere?

Not yet.

Has the possibility of having it be an ordinary optional dependency been discussed anywhere?

Is the concern there just that applications that are already deployed would need to be rebuilt in order to get diagnostics when they misbehave? A feature gate seems like the path-of-least-surprise to me though.

We could make the log dependency optional and enable it by default. Then Tokio versions that support MSRV < 1.60 can disable it.

@carllerche what do you think of @Darksonn's idea?

We could make the log dependency optional and enable it by default. Then Tokio versions that support MSRV < 1.60 can disable it.

Closed in favor of #1673


This package does not do what it says

In an environment where I delete Object.prototype.__proto__, this package returns true. It should return false. This is because the package description says (emphasis added):

Does this environment have the ability to get or set the [[Prototype]] of an object with __proto__?

However the package only tests that the environment has the ability to declare the [[Prototype]] of an object with __proto__. It does not test that getting or setting through __proto__ works.
The behaviour the package is testing has also bene uncontroversial for many years and is part of the main 262 spec. Only the getter behaviour is controversial - it is part of annex B and is thus not implemented everywhere (Deno does not implement this feature by default and has a flag to turn it on, while Node has it enabled by default with a flag to disable).

Indeed, the description isn’t accurate.
(it’s worth noting that any web-compatible runtime would be required to implement it, and deno claims to be one)

Ah, that's just the repo description - the package description (the source of truth) is Does this environment have the ability to set the [[Prototype]] of an object on creation with `__proto__`? which is precisely correct.


Random crashes while playing any game.

Hyprland Version
 System/Version info
Hyprland, built from branch main at commit 965a2e5b213eee595808bc7bff28e7df59442720 dirty (hooksystem: attempt allocating pages in linear order).
Date: Fri Apr 5 18:16:09 2024
Tag: v0.38.0-42-g965a2e5b, commits: 4375

flags: (if any)

System Information:
System name: Linux
Node name: TechnoBeceT-Arch
Release: 6.8.5-zen1-1-zen
Version: #1 ZEN SMP PREEMPT_DYNAMIC Thu, 11 Apr 2024 01:47:18 +0000

GPU information:
03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 31 [Radeon RX 7900 XT/7900 XTX/7900M] [1002:744c] (rev c8) (prog-if 00 [VGA controller])
6d:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Raphael [1002:164e] (rev c1) (prog-if 00 [VGA controller])

os-release: NAME="Garuda Linux"
PRETTY_NAME="Garuda Linux"
ID=garuda
ID_LIKE=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://garudalinux.org/"
DOCUMENTATION_URL="https://wiki.garudalinux.org/"
SUPPORT_URL="https://forum.garudalinux.org/"
BUG_REPORT_URL="https://gitlab.com/groups/garuda-linux/"
PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
LOGO=garudalinux

plugins:

Bug or Regression?
Bug
Description
Hi, i'm getting random crashes while gaming, this happens while only gaming and game itself doesnt matter.
For now which games are cause crash,
Red Dead Redemption 2
Hunt Showdown
Dragon's Dogma 2
Apex Legends
How to reproduce
It just happens while gaming, sometimes in 10 min sometimes after hours. I can't say exact method to reproduce.
Crash reports, logs, images, videos
--------------------------------------------
   Hyprland Crash Report
--------------------------------------------
Well this is awkward.

Hyprland received signal 6 (Aborted)

Version: 965a2e5b213eee595808bc7bff28e7df59442720
Tag: v0.38.0-42-g965a2e5b

System info:
	System name: Linux
	Node name: TechnoBeceT-Arch
	Release: 6.8.2-zen2-1-zen
	Version: #1 ZEN SMP PREEMPT_DYNAMIC Thu, 28 Mar 2024 17:06:20 +0000

GPU:
	03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 31 [Radeon RX 7900 XT/7900 XTX/7900M] [1002:744c] (rev c8) (prog-if 00 [VGA controller])
6d:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Raphael [1002:164e] (rev c1) (prog-if 00 [VGA controller])

os-release:
	NAME="Garuda Linux"
	PRETTY_NAME="Garuda Linux"
	ID=garuda
	ID_LIKE=arch
	BUILD_ID=rolling
	ANSI_COLOR="38;2;23;147;209"
	HOME_URL="https://garudalinux.org/"
	DOCUMENTATION_URL="https://wiki.garudalinux.org/"
	SUPPORT_URL="https://forum.garudalinux.org/"
	BUG_REPORT_URL="https://gitlab.com/groups/garuda-linux/"
	PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
	LOGO=garudalinux

Backtrace:
	#0 | Hyprland(_Z12getBacktracev+0x6a) [0x5cc4d39fabea]
		getBacktrace()
		??:?
	#1 | Hyprland(_ZN13CrashReporter18createAndSaveCrashEi+0x6b9) [0x5cc4d39ab659]
		CrashReporter::createAndSaveCrash(int)
		??:?
	#2 | Hyprland(_Z25handleUnrecoverableSignali+0x50) [0x5cc4d393b470]
		handleUnrecoverableSignal(int)
		??:?
	#3 | /usr/lib/libc.so.6(+0x3c770) [0x73610a45a770]
		??
		??:0
	#4 | /usr/lib/libc.so.6(+0x8d32c) [0x73610a4ab32c]
		handleUserSignal(int)
		??:?
	#5 | /usr/lib/libc.so.6(gsignal+0x18) [0x73610a45a6c8]
		??
		??:0
	#6 | Hyprland(_ZN15CHyprOpenGLImpl5beginEP8CMonitorRK7CRegionP12CFramebufferSt8optionalIS2_E+0x190) [0x5cc4d3a7a610]
		CHyprOpenGLImpl::begin(CMonitor*, CRegion const&, CFramebuffer*, std::optional<CRegion>)
		??:?
	#7 | Hyprland(_ZN13CHyprRenderer11beginRenderEP8CMonitorR7CRegion11eRenderModeP10wlr_bufferP12CFramebuffer+0xe0) [0x5cc4d3a983c0]
		CHyprRenderer::beginRender(CMonitor*, CRegion&, eRenderMode, wlr_buffer*, CFramebuffer*)
		??:?
	#8 | Hyprland(_ZN13CHyprRenderer13renderMonitorEP8CMonitor+0x4db) [0x5cc4d3a8c6fb]
		CHyprRenderer::renderMonitor(CMonitor*)
		??:?
	#9 | Hyprland(_Z13handleWrappedP11wl_listenerPv+0x5b) [0x5cc4d3a0437b]
		handleWrapped(wl_listener*, void*)
		??:?
	#10 | /usr/lib/libwayland-server.so.0(wl_signal_emit_mutable+0x7e) [0x73610af2f01e]
		??
		??:0
	#11 | /usr/lib/libwlroots.so.13032(+0x359b9) [0x73610af709b9]
		??
		??:0
	#12 | /usr/lib/libdrm.so.2(drmHandleEvent+0x127) [0x73610af1c907]
		??
		??:0
	#13 | /usr/lib/libwlroots.so.13032(+0x2f16e) [0x73610af6a16e]
		??
		??:0
	#14 | /usr/lib/libwayland-server.so.0(wl_event_loop_dispatch+0xa2) [0x73610af30ae2]
		??
		??:0
	#15 | /usr/lib/libwayland-server.so.0(wl_display_run+0x27) [0x73610af312d7]
		??
		??:0
	#16 | Hyprland(main+0x799) [0x5cc4d3920c79]
		main
		??:?
	#17 | /usr/lib/libc.so.6(+0x25cd0) [0x73610a443cd0]
		??
		??:0
	#18 | /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x73610a443d8a]
		??
		??:0
	#19 | Hyprland(_start+0x25) [0x5cc4d3938735]
		_start
		??:?

Log tail:
[LOG] Callback 5cc4d8188088 -> 5cc4d8188080, XWayland Window removed.
[LOG] Cleanup: destroyed a window
[LOG] New mouse constraint at 5cc4d818bdb0
[LOG] Registered signal for owner 5cc4d7fb4f00: 5cc4d818be70 -> 5cc4d7fb4fc8 (owner: CConstraint)
[LOG] Registered signal for owner 5cc4d7fb4f00: 5cc4d818be80 -> 5cc4d7fb4f60 (owner: CConstraint)
[LOG] cursorImage request: surface 0
[LOG] Callback 5cc4d65998f8 -> 5cc4d65998f0, CWLSurface removed.
[LOG] Callback 5cc4d6599960 -> 5cc4d6599958, CWLSurface removed.
[LOG] CWLSurface 5cc4d6599888 called destroy()
[LOG] Callback 5cc4d7fb4ff0 -> 5cc4d7fb4fe8, CConstraint removed.
[LOG] Callback 5cc4d7fb4f88 -> 5cc4d7fb4f80, CConstraint removed.
[LOG] cursorImage request: surface 5cc4d8181630
[LOG] Registered signal for owner 5cc4d6599888: 5cc4d8181948 -> 5cc4d65998d0 (owner: CWLSurface)
[LOG] Registered signal for owner 5cc4d6599888: 5cc4d8181908 -> 5cc4d6599938 (owner: CWLSurface)
[LOG] CWLSurface 5cc4d6599888 called init()
[LOG] cursorImage request: surface 5cc4d818b760
[LOG] Callback 5cc4d65998f8 -> 5cc4d65998f0, CWLSurface removed.
[LOG] Callback 5cc4d6599960 -> 5cc4d6599958, CWLSurface removed.
[LOG] CWLSurface 5cc4d6599888 called destroy()
[LOG] Registered signal for owner 5cc4d6599888: 5cc4d818ba78 -> 5cc4d65998d0 (owner: CWLSurface)
[LOG] Registered signal for owner 5cc4d6599888: 5cc4d818ba38 -> 5cc4d6599938 (owner: CWLSurface)
[LOG] CWLSurface 5cc4d6599888 called init()
[LOG] cursorImage request: surface 5cc4d818ace0
[LOG] Callback 5cc4d65998f8 -> 5cc4d65998f0, CWLSurface removed.
[LOG] Callback 5cc4d6599960 -> 5cc4d6599958, CWLSurface removed.
[LOG] CWLSurface 5cc4d6599888 called destroy()
[LOG] Registered signal for owner 5cc4d6599888: 5cc4d818aff8 -> 5cc4d65998d0 (owner: CWLSurface)
[LOG] Registered signal for owner 5cc4d6599888: 5cc4d818afb8 -> 5cc4d6599938 (owner: CWLSurface)
[LOG] CWLSurface 5cc4d6599888 called init()
[LOG] cursorImage request: surface 5cc4d8188320
[LOG] Callback 5cc4d65998f8 -> 5cc4d65998f0, CWLSurface removed.
[LOG] Callback 5cc4d6599960 -> 5cc4d6599958, CWLSurface removed.
[LOG] CWLSurface 5cc4d6599888 called destroy()
[LOG] Registered signal for owner 5cc4d6599888: 5cc4d8188638 -> 5cc4d65998d0 (owner: CWLSurface)
[LOG] Registered signal for owner 5cc4d6599888: 5cc4d81885f8 -> 5cc4d6599938 (owner: CWLSurface)
[LOG] CWLSurface 5cc4d6599888 called init()
[LOG] cursorImage request: surface 5cc4d818cba0
[LOG] Callback 5cc4d65998f8 -> 5cc4d65998f0, CWLSurface removed.
[LOG] Callback 5cc4d6599960 -> 5cc4d6599958, CWLSurface removed.
[LOG] CWLSurface 5cc4d6599888 called destroy()
[LOG] Registered signal for owner 5cc4d6599888: 5cc4d818ceb8 -> 5cc4d65998d0 (owner: CWLSurface)
[LOG] Registered signal for owner 5cc4d6599888: 5cc4d818ce78 -> 5cc4d6599938 (owner: CWLSurface)
[LOG] CWLSurface 5cc4d6599888 called init()
[LOG] cursorImage request: surface 5cc4d818da60
[LOG] Callback 5cc4d65998f8 -> 5cc4d65998f0, CWLSurface removed.
[LOG] Callback 5cc4d6599960 -> 5cc4d6599958, CWLSurface removed.
[LOG] CWLSurface 5cc4d6599888 called destroy()
[LOG] Registered signal for owner 5cc4d6599888: 5cc4d818dd78 -> 5cc4d65998d0 (owner: CWLSurface)
[LOG] Registered signal for owner 5cc4d6599888: 5cc4d818dd38 -> 5cc4d6599938 (owner: CWLSurface)
[LOG] CWLSurface 5cc4d6599888 called init()
[LOG] New mouse constraint at 5cc4d817ef60
[LOG] Registered signal for owner 5cc4d8189040: 5cc4d817f020 -> 5cc4d8189108 (owner: CConstraint)
[LOG] Registered signal for owner 5cc4d8189040: 5cc4d817f030 -> 5cc4d81890a0 (owner: CConstraint)
[LOG] cursorImage request: surface 0
[LOG] Callback 5cc4d65998f8 -> 5cc4d65998f0, CWLSurface removed.
[LOG] Callback 5cc4d6599960 -> 5cc4d6599958, CWLSurface removed.
[LOG] CWLSurface 5cc4d6599888 called destroy()
[CRITICAL]
==========================================================================================
ASSERTION FAILED!

Aborting, glGetGraphicsResetStatus returned GL_INNOCENT_CONTEXT_RESET. Cannot continue until proper GPU reset handling is implemented.

at: line 258 in OpenGL.cpp

--------------------------------------------
   Hyprland Crash Report
--------------------------------------------
I tried so hard, and got so far...

Hyprland received signal 6 (Aborted)

Version: fcd9d77b642c0cd45cae61cf10ed1924f2e7945b
Tag: v0.37.1-81-gfcd9d77b

System info:
	System name: Linux
	Node name: TechnoBeceT-Arch
	Release: 6.8.2-zen2-1-zen
	Version: #1 ZEN SMP PREEMPT_DYNAMIC Thu, 28 Mar 2024 17:06:20 +0000

GPU:
	03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 31 [Radeon RX 7900 XT/7900 XTX/7900M] [1002:744c] (rev c8) (prog-if 00 [VGA controller])
6d:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Raphael [1002:164e] (rev c1) (prog-if 00 [VGA controller])

os-release:
	NAME="Garuda Linux"
	PRETTY_NAME="Garuda Linux"
	ID=garuda
	ID_LIKE=arch
	BUILD_ID=rolling
	ANSI_COLOR="38;2;23;147;209"
	HOME_URL="https://garudalinux.org/"
	DOCUMENTATION_URL="https://wiki.garudalinux.org/"
	SUPPORT_URL="https://forum.garudalinux.org/"
	BUG_REPORT_URL="https://gitlab.com/groups/garuda-linux/"
	PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
	LOGO=garudalinux

Backtrace:
	#0 | Hyprland(_Z12getBacktracev+0x6a) [0x63b7c38c187a]
		getBacktrace()
		??:?
	#1 | Hyprland(_ZN13CrashReporter18createAndSaveCrashEi+0x6b9) [0x63b7c3874889]
		CrashReporter::createAndSaveCrash(int)
		??:?
	#2 | Hyprland(_Z25handleUnrecoverableSignali+0x50) [0x63b7c3806100]
		handleUnrecoverableSignal(int)
		??:?
	#3 | /usr/lib/libc.so.6(+0x3c770) [0x7ca0e236e770]
		??
		??:0
	#4 | /usr/lib/libc.so.6(+0x8d32c) [0x7ca0e23bf32c]
		CCompositor::initAllSignals()
		??:?
	#5 | /usr/lib/libc.so.6(gsignal+0x18) [0x7ca0e236e6c8]
		??
		??:0
	#6 | Hyprland(_ZN15CHyprOpenGLImpl5beginEP8CMonitorRK7CRegionP12CFramebufferSt8optionalIS2_E+0x190) [0x63b7c39400b0]
		CHyprOpenGLImpl::begin(CMonitor*, CRegion const&, CFramebuffer*, std::optional<CRegion>)
		??:?
	#7 | Hyprland(_ZN13CHyprRenderer11beginRenderEP8CMonitorR7CRegion11eRenderModeP10wlr_bufferP12CFramebuffer+0xe0) [0x63b7c395cd80]
		CHyprRenderer::beginRender(CMonitor*, CRegion&, eRenderMode, wlr_buffer*, CFramebuffer*)
		??:?
	#8 | Hyprland(_ZN13CHyprRenderer13renderMonitorEP8CMonitor+0x4db) [0x63b7c395231b]
		CHyprRenderer::renderMonitor(CMonitor*)
		??:?
	#9 | Hyprland(_Z13handleWrappedP11wl_listenerPv+0x5b) [0x63b7c38ca09b]
		handleWrapped(wl_listener*, void*)
		??:?
	#10 | /usr/lib/libwayland-server.so.0(wl_signal_emit_mutable+0x7e) [0x7ca0e2df201e]
		??
		??:0
	#11 | /usr/lib/libwlroots.so.13032(+0x359b9) [0x7ca0e2e339b9]
		??
		??:0
	#12 | /usr/lib/libdrm.so.2(drmHandleEvent+0x127) [0x7ca0e2ddf907]
		??
		??:0
	#13 | /usr/lib/libwlroots.so.13032(+0x2f16e) [0x7ca0e2e2d16e]
		??
		??:0
	#14 | /usr/lib/libwayland-server.so.0(wl_event_loop_dispatch+0xa2) [0x7ca0e2df3ae2]
		??
		??:0
	#15 | /usr/lib/libwayland-server.so.0(wl_display_run+0x27) [0x7ca0e2df42d7]
		??
		??:0
	#16 | Hyprland(main+0x799) [0x63b7c37ec8d9]
		main
		??:?
	#17 | /usr/lib/libc.so.6(+0x25cd0) [0x7ca0e2357cd0]
		??
		??:0
	#18 | /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7ca0e2357d8a]
		??
		??:0
	#19 | Hyprland(_start+0x25) [0x63b7c3803155]
		_start
		??:?

Log tail:
[LOG] Window rule noblur -> .* matched [Window 63b7c6739cc0: title: "Volume Control"]
[LOG] Window rule opacity 0.9 0.9 -> class:.* matched [Window 63b7c6739cc0: title: "Volume Control"]
[LOG] Callback 63b7c58f2098 -> 63b7c58f2090, CSubsurface Head removed.
[LOG] Callback 63b7c6732638 -> 63b7c6732630, CSubsurface removed.
[LOG] Callback 63b7c67325d0 -> 63b7c67325c8, CSubsurface removed.
[LOG] Callback 63b7c6732568 -> 63b7c6732560, CSubsurface removed.
[LOG] Callback 63b7c67327c0 -> 63b7c67327b8, CWLSurface removed.
[LOG] Callback 63b7c6732828 -> 63b7c6732820, CWLSurface removed.
[LOG] CWLSurface 63b7c6732750 called destroy()
[LOG] Callback 63b7c6732708 -> 63b7c6732700, CSubsurface removed.
[LOG] Callback 63b7c67326a0 -> 63b7c6732698, CSubsurface removed.
[LOG] Callback 63b7c439fad8 -> 63b7c439fad0, CPopup Head removed.
[LOG] [Window 63b7c6776400: title: "~", class: ] destroyed, queueing.
[LOG] Callback 63b7c6776c90 -> 63b7c6776c88, CWLSurface removed.
[LOG] Callback 63b7c6776cf8 -> 63b7c6776cf0, CWLSurface removed.
[LOG] CWLSurface 63b7c6776c20 called destroy()
[LOG] Callback 63b7c6776428 -> 63b7c6776420, XDG Window removed.
[LOG] Callback 63b7c6776490 -> 63b7c6776488, XDG Window removed.
[LOG] Callback 63b7c6776560 -> 63b7c6776558, XDG Window removed.
[ERR] onWindowRemovedTiling node null?
[LOG] cursorImage request: surface 63b7c5216470
[LOG] Registered signal for owner 63b7c4d6b320: 63b7c5216788 -> 63b7c4d6b368 (owner: CWLSurface)
[LOG] Registered signal for owner 63b7c4d6b320: 63b7c5216748 -> 63b7c4d6b3d0 (owner: CWLSurface)
[LOG] CWLSurface 63b7c4d6b320 called init()
[LOG] Cleanup: destroyed a window
[LOG] Keybind triggered, calling dispatcher (64, , 51)
[LOG] Executing ~/.config/ags/scripts/hyprland/workspace_action.sh workspace 3
[LOG] Process Created with pid 63714
[LOG] Searching for matching rules for pavucontrol (title: Volume Control)
[LOG] Window rule noblur -> .* matched [Window 63b7c6739cc0: title: "Volume Control"]
[LOG] Window rule opacity 0.9 0.9 -> class:.* matched [Window 63b7c6739cc0: title: "Volume Control"]
[LOG] Set keyboard focus to surface 63b7c439ed90, with [Window 63b7c5915050: title: "Dragon's Dogma 2"]
[LOG] Searching for matching rules for steam_app_2054970 (title: Dragon's Dogma 2)
[LOG] Window rule noblur -> .* matched [Window 63b7c5915050: title: "Dragon's Dogma 2"]
[LOG] Window rule opacity 0.9 0.9 -> class:.* matched [Window 63b7c5915050: title: "Dragon's Dogma 2"]
[LOG] Window rule opacity 1 1 -> fullscreen:1 matched [Window 63b7c5915050: title: "Dragon's Dogma 2"]
[LOG] Window rule rounding 0 -> fullscreen:1 matched [Window 63b7c5915050: title: "Dragon's Dogma 2"]
[LOG] Hyprctl: dispatcher workspace : 3
[LOG] cursorImage request: surface 63b7c56fc3c0
[LOG] Callback 63b7c4d6b390 -> 63b7c4d6b388, CWLSurface removed.
[LOG] Callback 63b7c4d6b3f8 -> 63b7c4d6b3f0, CWLSurface removed.
[LOG] CWLSurface 63b7c4d6b320 called destroy()
[LOG] Registered signal for owner 63b7c4d6b320: 63b7c56fc6d8 -> 63b7c4d6b368 (owner: CWLSurface)
[LOG] Registered signal for owner 63b7c4d6b320: 63b7c56fc698 -> 63b7c4d6b3d0 (owner: CWLSurface)
[LOG] CWLSurface 63b7c4d6b320 called init()
[LOG] cursorImage request: surface 63b7c5216470
[LOG] cursorImage request: surface 63b7c56fc3c0
[LOG] cursorImage request: surface 0
[LOG] Callback 63b7c4d6b390 -> 63b7c4d6b388, CWLSurface removed.
[LOG] Callback 63b7c4d6b3f8 -> 63b7c4d6b3f0, CWLSurface removed.
[LOG] CWLSurface 63b7c4d6b320 called destroy()
[LOG] New mouse constraint at 63b7c4f5c600
[LOG] Registered signal for owner 63b7c584d940: 63b7c4f5c6c0 -> 63b7c584da08 (owner: CConstraint)
[LOG] Registered signal for owner 63b7c584d940: 63b7c4f5c6d0 -> 63b7c584d9a0 (owner: CConstraint)
[LOG] cursorImage request: surface 0
[LOG] cursorImage request: surface 0
[CRITICAL]
==========================================================================================
ASSERTION FAILED!

Aborting, glGetGraphicsResetStatus returned GL_INNOCENT_CONTEXT_RESET. Cannot continue until proper GPU reset handling is implemented.

at: line 258 in OpenGL.cpp

--------------------------------------------
   Hyprland Crash Report
--------------------------------------------
Sorry, didn't mean to...

Hyprland received signal 6 (Aborted)

Version: fcd9d77b642c0cd45cae61cf10ed1924f2e7945b
Tag: v0.37.1-81-gfcd9d77b

System info:
	System name: Linux
	Node name: TechnoBeceT-Arch
	Release: 6.8.2-zen2-1-zen
	Version: #1 ZEN SMP PREEMPT_DYNAMIC Thu, 28 Mar 2024 17:06:20 +0000

GPU:
	03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 31 [Radeon RX 7900 XT/7900 XTX/7900M] [1002:744c] (rev c8) (prog-if 00 [VGA controller])
6d:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Raphael [1002:164e] (rev c1) (prog-if 00 [VGA controller])

os-release:
	NAME="Garuda Linux"
	PRETTY_NAME="Garuda Linux"
	ID=garuda
	ID_LIKE=arch
	BUILD_ID=rolling
	ANSI_COLOR="38;2;23;147;209"
	HOME_URL="https://garudalinux.org/"
	DOCUMENTATION_URL="https://wiki.garudalinux.org/"
	SUPPORT_URL="https://forum.garudalinux.org/"
	BUG_REPORT_URL="https://gitlab.com/groups/garuda-linux/"
	PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
	LOGO=garudalinux

Backtrace:
	#0 | Hyprland(_Z12getBacktracev+0x6a) [0x631dbc81b87a]
		getBacktrace()
		??:?
	#1 | Hyprland(_ZN13CrashReporter18createAndSaveCrashEi+0x6b9) [0x631dbc7ce889]
		CrashReporter::createAndSaveCrash(int)
		??:?
	#2 | Hyprland(_Z25handleUnrecoverableSignali+0x50) [0x631dbc760100]
		handleUnrecoverableSignal(int)
		??:?
	#3 | /usr/lib/libc.so.6(+0x3c770) [0x71389276e770]
		??
		??:0
	#4 | /usr/lib/libc.so.6(+0x8d32c) [0x7138927bf32c]
		CCompositor::initAllSignals()
		??:?
	#5 | /usr/lib/libc.so.6(gsignal+0x18) [0x71389276e6c8]
		??
		??:0
	#6 | Hyprland(_ZN15CHyprOpenGLImpl5beginEP8CMonitorRK7CRegionP12CFramebufferSt8optionalIS2_E+0x190) [0x631dbc89a0b0]
		CHyprOpenGLImpl::begin(CMonitor*, CRegion const&, CFramebuffer*, std::optional<CRegion>)
		??:?
	#7 | Hyprland(_ZN13CHyprRenderer11beginRenderEP8CMonitorR7CRegion11eRenderModeP10wlr_bufferP12CFramebuffer+0xe0) [0x631dbc8b6d80]
		CHyprRenderer::beginRender(CMonitor*, CRegion&, eRenderMode, wlr_buffer*, CFramebuffer*)
		??:?
	#8 | Hyprland(_ZN13CHyprRenderer13renderMonitorEP8CMonitor+0x4db) [0x631dbc8ac31b]
		CHyprRenderer::renderMonitor(CMonitor*)
		??:?
	#9 | Hyprland(_Z13handleWrappedP11wl_listenerPv+0x5b) [0x631dbc82409b]
		handleWrapped(wl_listener*, void*)
		??:?
	#10 | /usr/lib/libwayland-server.so.0(wl_signal_emit_mutable+0x7e) [0x71389324301e]
		??
		??:0
	#11 | /usr/lib/libwlroots.so.13032(+0x359b9) [0x7138932849b9]
		??
		??:0
	#12 | /usr/lib/libdrm.so.2(drmHandleEvent+0x127) [0x713893230907]
		??
		??:0
	#13 | /usr/lib/libwlroots.so.13032(+0x2f16e) [0x71389327e16e]
		??
		??:0
	#14 | /usr/lib/libwayland-server.so.0(wl_event_loop_dispatch+0xa2) [0x713893244ae2]
		??
		??:0
	#15 | /usr/lib/libwayland-server.so.0(wl_display_run+0x27) [0x7138932452d7]
		??
		??:0
	#16 | Hyprland(main+0x799) [0x631dbc7468d9]
		main
		??:?
	#17 | /usr/lib/libc.so.6(+0x25cd0) [0x713892757cd0]
		??
		??:0
	#18 | /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x713892757d8a]
		??
		??:0
	#19 | Hyprland(_start+0x25) [0x631dbc75d155]
		_start
		??:?

Log tail:
[LOG] Window rule opacity 0.9 0.9 -> class:.* matched [Window 631dc0a4fa00: title: "Red Dead Redemption 2"]
[LOG] Window rule opacity 1 1 -> fullscreen:1 matched [Window 631dc0a4fa00: title: "Red Dead Redemption 2"]
[LOG] Window rule rounding 0 -> fullscreen:1 matched [Window 631dc0a4fa00: title: "Red Dead Redemption 2"]
[LOG] Callback 631dc0bf3aa0 -> 631dc0bf3a98, CWLSurface removed.
[LOG] Callback 631dc0bf3b08 -> 631dc0bf3b00, CWLSurface removed.
[LOG] CWLSurface 631dc0bf3a30 called destroy()
[LOG] Callback 631dc0bf32a0 -> 631dc0bf3298, XWayland Window removed.
[LOG] Callback 631dc0bf3238 -> 631dc0bf3230, XWayland Window removed.
[LOG] Destroyed 631dc0be8280 tearing hint
[LOG] Callback 631dc0b18778 -> 631dc0b18770, TearingController removed.
[LOG] Callback 631dc0b18710 -> 631dc0b18708, TearingController removed.
[LOG] [Window 631dc0bf3210: title: "notificationtoasts_7_desktop", class: ] destroyed, queueing.
[LOG] XWayland class raw: steam
[LOG] Callback 631dc0bf3370 -> 631dc0bf3368, XWayland Window removed.
[LOG] Callback 631dc0bf3718 -> 631dc0bf3710, XWayland Window removed.
[LOG] Callback 631dc0bf38b8 -> 631dc0bf38b0, XWayland Window removed.
[LOG] Callback 631dc0bf3920 -> 631dc0bf3918, XWayland Window removed.
[LOG] Callback 631dc0bf3988 -> 631dc0bf3980, XWayland Window removed.
[LOG] Unmapped [Window 631dc0bf3210: title: "notificationtoasts_7_desktop"] removed instantly
[LOG] Cleanup: destroyed a window
[LOG] New LayerSurface has no preferred monitor. Assigning Monitor DP-1
[LOG] Registered signal for owner 631dc0bf6a30: 631dc0bf6918 -> 631dc0bf6e68 (owner: layerSurface)
[LOG] Registered signal for owner 631dc0bf6a30: 631dc0bb1408 -> 631dc0bf6d30 (owner: layerSurface)
[LOG] Registered signal for owner 631dc0bf6a30: 631dc0bf6928 -> 631dc0bf6d98 (owner: layerSurface)
[LOG] Registered signal for owner 631dc0bf6a30: 631dc0bf6938 -> 631dc0bf6e00 (owner: layerSurface)
[LOG] Registered signal for owner 631dbfba29c0: 631dc0bb1418 -> 631dbfba2b40 (owner: CPopup Head)
[LOG] LayerSurface 631dc0bb1340 (namespace notifications layer 2) created on monitor DP-1
[ERR] BUG THIS: No CWLSurface for surface in damageSurface!!!
[WARN] Orphaned wlr_surface 631dc0bf6640 in setPreferredScaleForSurface
[WARN] Orphaned wlr_surface 631dc0bf6640 in setPreferredTransformForSurface
[ERR] BUG THIS: No CWLSurface for surface in damageSurface!!!
[WARN] Orphaned wlr_surface 631dc0bf6640 in setPreferredScaleForSurface
[WARN] Orphaned wlr_surface 631dc0bf6640 in setPreferredTransformForSurface
[LOG] LayerSurface 631dc0bb1340 mapped
[LOG] Registered signal for owner 631dc0bf6c10: 631dc0bf6958 -> 631dc0bf6c58 (owner: CWLSurface)
[LOG] Registered signal for owner 631dc0bf6c10: 631dc0bf6918 -> 631dc0bf6cc0 (owner: CWLSurface)
[LOG] CWLSurface 631dc0bf6c10 called init()
[LOG] Searching for matching rules for teams-for-linux (title: )
[LOG] Window rule noblur -> .* matched [Window 631dbfbba9b0: title: ""]
[LOG] Window rule opacity 0.9 0.9 -> class:.* matched [Window 631dbfbba9b0: title: ""]
[LOG] Window 631dbfbba9b0 set title to
[LOG] Searching for matching rules for teams-for-linux (title: (1) Chat | Microsoft Teams)
[LOG] Window rule noblur -> .* matched [Window 631dbfbba9b0: title: "(1) Chat | Microsoft Teams"]
[LOG] Window rule opacity 0.9 0.9 -> class:.* matched [Window 631dbfbba9b0: title: "(1) Chat | Microsoft Teams"]
[LOG] Window 631dbfbba9b0 set title to (1) Chat | Microsoft Teams
[LOG] Keybind triggered, calling dispatcher (64, , 50)
[LOG] Executing ~/.config/ags/scripts/hyprland/workspace_action.sh workspace 2
[ERR] Listener<PHONE_NUMBER>39952 timed out and was killed by Watchdog!!!
[LOG] Keybind triggered, calling dispatcher (64, , 49)
[LOG] Executing ~/.config/ags/scripts/hyprland/workspace_action.sh workspace 1
[LOG] Process Created with pid 62473
[CRITICAL]
==========================================================================================
ASSERTION FAILED!

Aborting, glGetGraphicsResetStatus returned GL_INNOCENT_CONTEXT_RESET. Cannot continue until proper GPU reset handling is implemented.

at: line 258 in OpenGL.cpp

This is a kernel/driver issue. Possibly games could be doing something wrong too

https://github.com/hyprwm/Hyprland/issues/4690#issuecomment-1942082396
Similar issue here, kernel isn't LTS so possible issue with your drivers. Doubt there is an issue with all of those games independently.

Yeah, on first i thought its game related but because of its happening every game, probably kernel/driver issue. Hopefully i can find the real reason behind this and fix it.

good luck!


UI Improvements to the project setup flow

Alert component stylized to better match our designs

Improved details on project setup

Added background to our project setup view

Improved styling of setup elements

[ ] New feature

[ ] Documentation update

[X] Bug fix

[ ] Refactor

[ ] Release

[ ] Other

Duplicate stale PR


Provide a way to set the number of attempts to decide whether to warn or not when DNS query failed

I occasionally see the following warning
DNS query failed; retrying in {} ms (attempts so far: 1)
This warning is important when we make DNS query for the first time.
However, considering retrying,  I guess that it is not so important when making DNS query due to TTL expiration.
How about setting the number of attempts to decide whether outputting the warning for queries due to TTL expiration?

It is a good suggestion. Many people may not be interested in warning messages for retrying expired records.
However, I'm not sure it is a general solution for various cases. Some users may want to warn about certain exceptions for the first time.
What do you think of adding an event listener for DNS records?
interface DnsQuestionListener {
    void onSuccess(@Nullable List<DnsRecord> oldRecords, List<DnsRecord> newRecords);

    // Default implementation of this would warn for all failures.
    void onFailure(@Nullable List<DnsRecord> oldRecords, Throwable cause, int attemptsSoFar);
}

It seems better.

I'm going to work on this feature.


fix: dont render unmarshal for property with const

Description

There seems to be a bug introduced in https://github.com/asyncapi/modelina/pull/1717/files. Properties that have const set are read-only, and can't be set when unmarshaling. If this is not fixed, then the TS compiler fails on the generated code.
Related Issue

Checklist

[x] The code follows the project's coding standards and is properly linted (npm run lint).
[x] Tests have been added or updated to cover the changes.
[x] Documentation has been updated to reflect the changes.
[x] All tests pass successfully locally.(npm run test).

Additional Notes

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.003%) to 92.326%

Totals

Change from base Build<PHONE_NUMBER>:
0.003%

Covered Lines:
5993

Relevant Lines:
6324

💛  - Coveralls

/rtm


at-avx: Wrong result when using indices and views

I either get wrong results or segfaults when using indices and @avx with views.
julia> using LoopVectorization

julia> function foo_avx!(data_out::AbstractArray{<:Any, 3},
                         matrix1::AbstractMatrix,
                         matrix2::AbstractMatrix,
                         data_in::AbstractArray{<:Any, 3},
                         tmp1=zeros(eltype(data_out), size(data_out, 1), size(matrix1, 1), size(data_in, 3)))

           @avx for j in indices((tmp1, data_in), (3, 3)), i in indices((tmp1, matrix1), (2, 1)), v in indices((tmp1, data_in), (1, 1))
               res = zero(eltype(tmp1))
               for ii in indices((data_in, matrix1), (2, 2))
                   res += matrix1[i, ii] * data_in[v, ii, j]
               end
               tmp1[v, i, j] = res
           end

           @avx for j in indices((data_out, matrix2), (3, 1)), i in indices((data_out, tmp1), (2, 2)), v in indices((data_out, tmp1), (1, 1))
               res = zero(eltype(data_out))
               for jj in indices((tmp1, matrix2), (3, 2))
                   res += matrix2[j, jj] * tmp1[v, i, jj]
               end
               data_out[v, i, j] = res
           end

           return nothing
       end

julia> function foo!(data_out::AbstractArray{<:Any, 3},
                     matrix1::AbstractMatrix,
                     matrix2::AbstractMatrix,
                     data_in::AbstractArray{<:Any, 3},
                     tmp1=zeros(eltype(data_out), size(data_out, 1), size(matrix1, 1), size(data_in, 3)))

           for j in indices((tmp1, data_in), (3, 3)), i in indices((tmp1, matrix1), (2, 1)), v in indices((tmp1, data_in), (1, 1))
               res = zero(eltype(tmp1))
               for ii in indices((data_in, matrix1), (2, 2))
                   res += matrix1[i, ii] * data_in[v, ii, j]
               end
               tmp1[v, i, j] = res
           end

           for j in indices((data_out, matrix2), (3, 1)), i in indices((data_out, tmp1), (2, 2)), v in indices((data_out, tmp1), (1, 1))
               res = zero(eltype(data_out))
               for jj in indices((tmp1, matrix2), (3, 2))
                   res += matrix2[j, jj] * tmp1[v, i, jj]
               end
               data_out[v, i, j] = res
           end

           return nothing
       end

julia> begin
           # Wrong result or segfault
           data_out_large = zeros(4, 4, 4, 4, 4, 4)
           data_out       = view(data_out_large, 1, 1, :, :, :, 1)
           data_out_avx_large = similar(data_out_large)
           data_out_avx       = view(data_out_avx_large, 1, 1, :, :, :, 1)
           matrix1 = randn(4, 4)
           matrix2 = randn(4, 4)
           data_in_large = randn(4, 4, 4, 4, 100)
           data_in = view(data_in_large, :, 1, :, :, 1)

           foo!(data_out, matrix1, matrix2, data_in)
           foo_avx!(data_out_avx, matrix1, matrix2, data_in)
           sum(abs, data_out - data_out_avx)
       end
79.36773785035257

julia> using Pkg; Pkg.status(["LoopVectorization", "VectorizationBase"], mode=PKGMODE_MANIFEST)
      Status `~/.julia/environments/v1.6/Manifest.toml`
  [bdcacae8] LoopVectorization v0.12.19
  [3d5dd08c] VectorizationBase v0.20.3

Everything seems to be fine when data_in = view(data_in_large, :, :, 1, :, 1) or data_in = view(data_in_large, :, :, :, 1, 1). Additionally, everything seems to be fine for v in indices(data_in, 1) or v in indices(tmp1, 1) in the first loop.
Is this a wrong usage of @avx (since the strides are not the same)? If so, is there an alternative to using views that works with foo_avx! above or another implementation of foo_avx! that has (at least) the same performance for contiguous arrays?

Is this a wrong usage of @avx (since the strides are not the same)?

No, there should be checks for that. This is a bug.

Fixed with the latest VectorizationBase.

Thanks a lot for the quick fix (again!) 👍 That's really great, as always.


Data conversion support is needed

I need to save an instance of Big (big.js, a library for working with decimals) to db and then restore it. But I don't want to perform conversion manually all the time. It would be great if I would be able to define a Decimal scalar along with a logic on how to parse and serialise values to allow such a conversion to be done automatically by Prisma2.
As @matthewmueller said, something like this in prisma's schema file could work:
amount Int @js.big

For reference: https://prisma.slack.com/archives/CKQTGR6T0/p1562294563302800


Add instrunctions to specify why and how to implement mutating webhook to schedule on Windows nodes

What type of PR is this?

New feature/enhancement

What this PR does / why we need it:

We need this PR to specify why and how to implement a webhook to schedule on Windows nodes. People running the tests will encounter issues if a webhook is not implemented before running tests. If not done, it will result in false positives or false negatives whereby a test fails or passes because it was incorrectly scheduled. The webhook image and its associated components have been repurposed from the HyperV tests. It makes sense to reuse the same webhook rather than creating our own since they solve the same problem. Also checked in with Mark regarding this and he mentioned its all good.

Changes included in this PR are

Update the README with motivation on why webhook is necesary prerequisite
Add manifest files and scripts for someone to easily setup a Windows node selector mutating webhook

Which issue(s) this PR fixes:

Resolves https://github.com/kubernetes-sigs/windows-operational-readiness/issues/95 by providing intrunctions on the motivation and how to implement a webhook
Resolves https://github.com/kubernetes-sigs/windows-operational-readiness/issues/69 since EKS has an implicit requirement to provide a node selector otherwise the pod will not get an IP

Future enhancements:
Right now the YAML files need to be manually updated. This could be enhanced by using a tool like Kustomize or Helm
Testing:
Testedby running the instrunctions provided and successfully deployed the webhook and saw logs demonstrating that the pod was successfully mutated with the node selector as expected. Sample logs as follows.
2023-10-24T06:27:48Z	INFO	webhook	Pod  is being mutated
2023-10-24T06:27:48Z	DEBUG	controller-runtime.webhook.webhooks	wrote response	{"webhook": "/mutate-v1-pod", "code": 200, "reason": "", "UID": "1f7f8777-676c-416a-9937-6f1b43cc9fc8", "allowed": true}
2023-10-24T06:29:00Z	DEBUG	controller-runtime.webhook.webhooks	received request	{"webhook": "/mutate-v1-pod", "UID": "b6adabd0-24fe-4b65-aa36-ca08c2df487a", "kind": "/v1, Kind=Pod", "resource": {"group":"","version":"v1","resource":"pods"}}

@pramitagautam @jayunit100 I added instrunctions for anyone to get started on implementing a webhook to ensure pods are scheduled on Windows. Will wait for a review for a couple of days and will merge later there is no feedback.

Thanks just saw

Yes, this is a good start for iterating. thanks tatenda.
/lgtm
/approve


InputDecoration.suffixIconColor not working

The color selected with suffixIconColor is not being rendered.
Steps to Reproduce

Add the code sample inside a Flutter app

Expected results:
Color is applied
Actual results:
The icon renders with a default blue color

Code sample
     TextFormField(
              cursorColor: const Color.fromRGBO(95, 46, 226, 1),
              decoration: const InputDecoration(
                suffixIcon: Icon(Icons.remove_red_eye_outlined),
                suffixIconColor: Color.fromRGBO(95, 46, 226, 1),
                iconColor: Color.fromRGBO(95, 46, 226, 1),
                filled: true,
                fillColor: Color.fromARGB(93, 255, 238, 251),
                labelText: "Password",
                labelStyle: TextStyle(
                    color: Color.fromRGBO(95, 46, 226, 1),
                    fontFamily: "Gordita"),
              ),
              validator: (value) {
                if (value == null || value.isEmpty) {
                  return 'Please enter some text';
                }
                return null;
              },
            ),

Logs

Hello @nilgaar. While I can reproduce this issue in stable, it seems to be fixed in beta and master channels. Since this is fixed, I am closing this issue. Thank you


Swich block builder in sequencer with circuit-powered version

Do not merge until the current end-to-end is working. Let's switch one thing at a time!

Already included in #152


Implement wheres/joins into relation query building

https://github.com/matthewwolfe/active-record/commit/ec32b7239c5412b0b308be4e89a497fcbdb9c40b


Unhandled Exception: HandshakeException: Connection terminated during handshake

Flutter Verison 3.3.2
I have 2 Android devices and 2 iPhone devices, and actually 1 device is in use. (I use one that don`t need Wifi)
On Android device, http.get works fine. In IOS, I build through a Mac, but whenever I try to http.get, the following error appears. (The funny thing is that sometimes communication happens. Once in 30 times, once in a while. I don't know why)
Unhandled Exception: HandshakeException: Connection terminated during handshake
my site url is "https://my-site.net/v1/some"
as you can see the above domain site has "https" and I made this with "GCP Cloud Run"
So it is very secured website (When I click the SSL mark on the website, it shows Google Trust Services LLC)
But because of the above error, I  can`t publish the app now. Every devices work fine on LOCALHOST
Seriously I need a help

Hi @yeahse
The goal of this Github repo is not to give assistance on personal code or the whole package/plugin project,
but to improve flutter reporting bugs or feature requests.
If you encounter behavior that you believe could be a bug, please provide a completed and minimal reproducible code sample that represents the problem. Also, please provide the output of flutter doctor -v as well.
It will be better if you fill out all the information indicated in the template so that we can address this issue properly.
Instead, if you think that the issue might depend on your implementation, please see flutter's community for resources and ask questions like this. You may also get some help if you post it on Stack Overflow and flutterhelp.
Thank you!

Hi @yeahse The goal of this Github repo is not to give assistance on personal code or the whole package/plugin project, but to improve flutter reporting bugs or feature requests.
If you encounter behavior that you believe could be a bug, please provide a completed and minimal reproducible code sample that represents the problem. Also, please provide the output of flutter doctor -v as well. It will be better if you fill out all the information indicated in the template so that we can address this issue properly.
Instead, if you think that the issue might depend on your implementation, please see flutter's community for resources and ask questions like this. You may also get some help if you post it on Stack Overflow and flutterhelp.
Thank you!

I added the code http.get part

@yeahse Your site above is not available, can you provide a completed and minimal reproducible code sample so that we may verify this? And please provide affected iOS device information as well. Thank you!

@yeahse Your site above is not available, can you provide a completed and minimal reproducible code sample so that we may verify this? And please provide affected iOS device information as well. Thank you!

You can test it with "snailo.net" in IOS then you will be not able to http.get  in any way. and this comment will be deleted I can`t share this domain for longtime and please do not write about this url in future comments

@yeahse When opening that site, I can see it's returned Status Code: 404 from Network tab (Chrome's Developer Tools). It seems your site issue rather than Flutter itself. Please re-check with the site maintainer/team for this.
Also, for the issue to be workable, it needs to be reproducible with a completed and minimal reproducible code sample, and issue information needs to be public so that others can see the issue and give the support as well.
Thank you!

@yeahse When opening that site, I can see it's returned Status Code: 404 from Network tab (Chrome's Developer Tools). It seems your site issue rather than Flutter itself. Please re-check with the site maintainer/team for this.
Also, for the issue to be workable, it needs to be reproducible with a completed and minimal reproducible code sample, and issue information needs to be public so that others can see the issue and give the support as well.
Thank you!

No that is not a problem that is normal. I didn`t set route on representive url. The problem is . http.get(Uri.parse(mysite)) is not working at all because of above exception

@yeahse When opening that site, I can see it's returned Status Code: 404 from Network tab (Chrome's Developer Tools). It seems your site issue rather than Flutter itself. Please re-check with the site maintainer/team for this.
Also, for the issue to be workable, it needs to be reproducible with a completed and minimal reproducible code sample, and issue information needs to be public so that others can see the issue and give the support as well.
Thank you!

No that is not a problem that is normal. I didn`t set route on representive url. (I only set in deepside mysite/v1/someapi) The problem is . http.get(Uri.parse(mysite)) is not working at all because of above exception. And my web server is made with Cloud Run and my domain is set with Google Domains.

@yeahse In this case, the setting at the site was unclear so we could investigate the issue.
Also, this issue is related to http plugin. Please open the issue in that repository for better support.
Closing, as this isn't an issue with Flutter itself. If you disagree, please write in the comments and I will reopen it. Thank you!


Downloading soundcloud tracks incorrectly.

Please follow the guide below

You will be asked some questions and requested to provide some information, please read them carefully and answer honestly
Put an x into all the boxes [ ] relevant to your issue (like that [x])
Use Preview tab to see how your issue will actually look like

Make sure you are using the latest version: run youtube-dl --version and ensure your version is 2016.06.02. If it's not read this FAQ entry and update. Issues with outdated version will be rejected.

[x ] I've verified and I assure that I'm running youtube-dl 2016.06.02

Before submitting an issue make sure you have:

[x ] At least skimmed through README and most notably FAQ and BUGS sections
[x ] Searched the bugtracker for similar issues including closed ones

What is the purpose of your issue?

[x ] Bug report (encountered problems with youtube-dl)
[ ] Site support request (request for adding support for a new site)
[ ] Feature request (request for a new functionality)
[ ] Question
[ ] Other

When using youtube-dl to download soundcloud tracks, I notice that youtube-dl is messing up the entire track. It either downloads only half the song, or adds onto the song (downloading the real song then adding another half to the song)
Example: I do this to download a persons tracks and it messes up the song length and the song. As an example, I looked at the song "Gwallaboy" that was downloaded, but the song had half of it repearted at the end of its self  for some reason (picture attached) A song once 2:20 minutes, which was downloaded as 3:21
cd /files/anthony/Music/LoudLord/tracks
youtube-dl https://soundcloud.com/loudlordbitch/tracks --embed-thumbnail -o "%(title)s.%(ext)s" -f mp3 --prefer-ffmpeg --verbose -i

https://soundcloud.com/loudlordbitch/loud-lord-gwallaboy-kush-krazy-coming-soon
Another example is this song:
https://soundcloud.com/loudlordbitch/loud-lord-sky-high
It only downloaded half the song. (picture attached) A song that was 1:51, but downloaded as 1:19.

All mentioned URLs downloaded exactly same as on the web for me thus I'm almost sure it's not youtube-dl who mess things.
Start with reading new issue template and providing all the requested. Then removing all *.part files and redownloading.


[BUG] Blueprints not working

Bug report
Thanks for this repo but the Blueprints I’ve tried all show me this error.

Additional information

used Hardware:

ESP32
EspHoMaTriXv2 version: latest master code from 7 May 2023

To Reproduce
Steps to reproduce the behavior:
Expected behavior
A clear and concise description of what you expected to happen.
Configuration
(optional) The YAML you used in epshome without any password

Screenshots
If applicable, add screenshots to help explain your problem.
Logs
(optional) Add relevant logs which could help tackle the problem.

Services calls
(optional) The YAML of your service calls

I will investigate

Hi, please try this version: https://github.com/lubeda/EspHoMaTriXv2/blob/develop/copy2esphome/EHMTX_easy_state.yaml

Yes this works thank you. I think the issue is with all the other blueprints also.

I will check, but not today.

No problem thanks for sorting this.


🐞 Bug

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug
Navbar isn,t responsive for all pixel
Steps To Reproduce
go to simulator inspect and see
Expected Behavior
it should be responsive for all pixel
Screenshots

Device Information [optional]
- OS:
- Browser:
- version:

Additional context
No response
Are you working on this issue?
Yes

Hey, Can I work on this issue ?

@riteshsinghh-coder can you share more context, for me the responsiveness here is not much issue 🤔


Add Cartridge struct with implementation of some utilities

In the current situation we are reading all the info about the ROM in the main. It can be possible to add a cartridge struct in order to manage all the related behavior. More info here.

I'll take this issue


Defer order/casting einsum parameters to NumPy implementation

This is one of requirements to fix #4898, together with https://github.com/cupy/cupy/pull/2249 and NumPy _implementation attribute from https://github.com/numpy/numpy/pull/13627.
Thanks @mrocklin for the guidelines on deferring non-Dask specific kwargs to the backend library (NumPy, CuPy, etc.).
A test for this already exists https://github.com/dask/dask/blob/4d3a48ee6d5e2b63fef1b0e6740b6478261cdaea/dask/array/tests/test_cupy.py#L60
cc @jakirkham

I'm +1 on this approach.  In general I think that we should leave kwarg checking to blockwise when it tries out the function on a small sample.

I'm +1 on this approach. In general I think that we should leave kwarg checking to blockwise when it tries out the function on a small sample.

Me too, this will make things much simpler for __array_function__ going further.

Thanks for putting this together Peter. Looks great! 😄

It seems this causes test_einsum_invalid_args to fail.

Thanks @jakirkham for pointing it out, indeed I had not seen it failed. I'll work on it.

Just a quick update on this: the issue is a bit more complex than I first predicted, blockwise_meta is shadowing exceptions from function calls to other libraries (in this case, np.einsum), so I'm working on a fix for that.

Right, so we may or may not want to raise a TypeError on failed calls on meta.  This is a complex question.
Fortunately we've already been doing this in Dask Dataframe for a year or two now, so we have some information on how what happens.  In general we get lots of user bug reports on malformed meta.  We try functions on tiny sample functions and they fail, and users get pretty frustrated.  Most of them don't understand things well enough to understand how to fix their problem.  In Dask Dataframe we kind of have to maintain meta in order to operate effectively (we need column names and dtypes more than we do in Dask Array), so we're sort of stuck with having to explain to people, over and over, that they need to provide proper metadata.  This is, as you can imagine, super-frustrating for all involved.
In the Dask array case we might want to be a bit more lenient.  It seems like there is a spectrum of strictness that we could use:

Not strict: default back to a dtype transform, or even just return the meta of the first input array
Warn: Raise a warning that things didn't work out great, inform them how to remove the warning, and probably point to a longer doc page on the topic.  However continue on with the not strict approach and give them a possibly malformed dask array.
Raise: Same as above, but we raise and don't allow them to continue.

I actually realized one thing on the error here, the test currently is:
     with pytest.raises(TypeError):
         da.einsum('a', *da_inputs, foo=1, bar=2)

and Dask raises the exception. However, we're now deferring the exception to the compute library (NumPy, CuPy), so what we really need to do is to add .compute() at the end, rather than making blockwise_meta raise the exception. I guess that makes sense, what do you think @jakirkham, @mrocklin ?

In fact, here's one other existing test:
def test_average_raises():
    d_a = da.arange(11, chunks=2)

    with pytest.raises(TypeError):
        da.average(d_a, weights=[1, 2, 3])

    with pytest.warns(RuntimeWarning):
        da.average(d_a, weights=da.zeros_like(d_a)).compute()

in this case, Dask raises a TypeError, but NumPy raises a RuntimeWarning, which is what I think we should expect for the einsum case failing in this PR too.

I actually realized one thing on the error here, the test currently is:
     with pytest.raises(TypeError):
         da.einsum('a', *da_inputs, foo=1, bar=2)

and Dask raises the exception. However, we're now deferring the exception to the compute library (NumPy, CuPy), so what we really need to do is to add .compute() at the end, rather than making blockwise_meta raise the exception. I guess that makes sense, what do you think @jakirkham, @mrocklin ?
I think that it's still good to catch errors at graph construction time rather than compute time if we can.  Obviously, this isn't always possible, but I think that we can do it in the case of bad keywords.
I recommend that we make a function like this, and use it whenever we try to get meta from calling a user provided function:
def compute_meta(func, *args, **kwargs):
    bad_keywords = set(inspect.signature(func).parameters) - set(kwargs)
    if bad_keywords:
        raise TypeError("Unexpected keywords to %s function: %s" % (funcname(func), bad_keywords)

    args = [getattr(arg, "_meta", arg) for arg in args]
    kwargs = {k: getattr(v, "_meta", v) for k, v in kwargs.items()}

    try:
        meta = func(*args, **kwargs)
    except Exception:
        meta = ...

    return meta

@mrocklin we can definitely do that too for this particular case. But this will clearly not be the case for all exceptions, and I think the more we move towards __array_function__, it's likely that we're going to push more of such errors to the compute task itself. Are we ok with that?

@mrocklin we can definitely do that too for this particular case. But this will clearly not be the case for all exceptions, and I think the more we move towards array_function, it's likely that we're going to push more of such errors to the compute task itself. Are we ok with that?

To a certain extent I think that it's necessary.  People will provide functions that strongly expect certain things that won't be true of meta.  I recommend that we also include the following test.
def test_permissible_meta_calculations():
    def f(x):
        assert x.shape == (10, 10)
        return x + 1

    x = da.ones((30, 30), chunks=(10, 10))
    y = x.map_blocks(f)

    assert_eq(y, np.ones((30, 30)) + 1)

Once again, this is a nice solution, except it has a lot of caveats. I've attempted to work on your suggestion @mrocklin, but it's not so simple. Again we fall on the shadowing of exceptions that I've mentioned before, but another issue comes from functions that take **kwargs instead of the actual named parameters, where we can't test for a bad signature.
I think we should then move conservatively (from the _meta perspective), just like we are doing in https://github.com/dask/dask/pull/4938, and for now let this fail during compute. Do you have any objection here?
I will raise a few issues (and perhaps some [WIP] PRs) with a few ideas I have attempted that fix some issues, but not all of them, and then we can build upon those ideas.

Yes, I agree that if the function has **kwargs then the keyword check should just pass.
I think it's suboptimal to fail on compute but probably necessary some of the time.  I'm curious what we did before.
In [1]: import dask; dask.__version__
Out[1]: '1.2.2'

In [2]: import dask.array as da

In [3]: x = da.ones((30, 30), chunks=(10, 10))

In [4]: def f(x):
   ...:     assert x.shape == (10, 10)
   ...:     return x + 1
   ...:

In [5]: x.map_blocks(f)
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-5-5f8635e7db98> in <module>
----> 1 x.map_blocks(f)

~/workspace/dask/dask/array/core.py in map_blocks(self, func, *args, **kwargs)
   1637     @wraps(map_blocks)
   1638     def map_blocks(self, func, *args, **kwargs):
-> 1639         return map_blocks(func, self, *args, **kwargs)
   1640
   1641     def map_overlap(self, func, depth, boundary=None, trim=True, **kwargs):

~/workspace/dask/dask/array/core.py in map_blocks(func, *args, **kwargs)
    493
    494     if dtype is None:
--> 495         dtype = apply_infer_dtype(func, args, original_kwargs, 'map_blocks')
    496
    497     if drop_axis:

~/workspace/dask/dask/array/core.py in apply_infer_dtype(func, args, kwargs, funcname, suggest_dtype, nout)
    282         msg = None
    283     if msg is not None:
--> 284         raise ValueError(msg)
    285     return o.dtype if nout is None else tuple(e.dtype for e in o)
    286

ValueError: `dtype` inference failed in `map_blocks`.

Please specify the dtype explicitly using the `dtype` kwarg.

Original error is below:
------------------------
AssertionError()

Traceback:
---------
  File "/Users/mrocklin/workspace/dask/dask/array/core.py", line 267, in apply_infer_dtype
    o = func(*args, **kwargs)
  File "<ipython-input-4-014b0f39d8bc>", line 2, in f
    assert x.shape == (10, 10)

Hrm, so it looks like what I'm proposing is a relaxation of our previous policy, where we were more strict.  It still feels correct to me to loosen things here, mostly because I don't trust users to understand and provide a meta array as much as I trust them to understand and provide a dtype.
Lets cc @jcrist and @shoyer to get their thoughts here.  What should we do in the following situation where our attempt to run a user defined function fails on a _meta chunk.  Should we err, warn, pass?  Discussion above.
def test_permissible_meta_calculations():
    def f(x):
        assert x.shape == (10, 10)
        return x + 1

    x = da.ones((30, 30), chunks=(10, 10))
    y = x.map_blocks(f)

    assert_eq(y, np.ones((30, 30)) + 1)

Right now, blockwise_meta ignores a lot of TypeErrors (by catching Exception) and defaults to constructing dask.array with the dtype, so that's the major problem when we let TypeError pass. I do think we should increase coverage of possible cases here, but I also think that will take time and we'll break more user code in the short term, so that's why I'm proposing a short-term solution for this PR and continue the discussion on how we increase the _meta coverage for this situation.

If you'd like a strict mode so that it's easier for developers to detect issues we would always add a strict mode relatively easily and control it with configuration

Yes, I agree with that, mainly because I don't think we will fix appropriately all issues we get on the tests in a timely manner. I will raise various issues tomorrow for that and the things I mentioned before.
So for now my question is: are you ok if we just call .compute() for the failing test here as a short-term solution and we continue with a more detailed conversation on the new issues?

So for now my question is: are you ok if we just call .compute() for the failing test here as a short-term solution and we continue with a more detailed conversation on the new issues?

For this test in particular I think that we should not call compute.  I think that we should implement the inspect solution.  That's something I think we can do in any case.  I'm happy to push a commit like this if you prefer.

What do you mean with the "inspect solution"?

Ah, nevermind, I understand now. But this is what I'm saying: we have to allow TypeErrors to pass, and with that we have lots of other errors, not just the kwargs error.

I think that short term we should keep the except TypeError in the code.  I think that we should check for keyword arguments, which will make the current failing test pass (and improve user experience I think).  I think that this would be a good incremental change while we figure out what to do next.  If there are other failing tests that would result from this approach I'm not aware of them (there appears to be only one at the moment, and I think we can fix it quickly), but would not be surprised if there are other things going on with cupy or whatnot that I'm not aware of.
(also, I'm shutting down for the night, so may not repond until much later)

That's what I'm saying: we fix that one test, yes, but dozens of others fail, not because of argument, but because we now let TypeError pass and they raise TypeErrors for various different reasons, and this is what except Exception: is doing when it falls back to dtype.
Long story short: we fix this one issue and raise dozens of others. So I stand by my proposal: use compute for now until we can solve the dozens of other errors, which will require some time and perhaps a more consistent approach to operating on the 0-length meta arrays in blockwise_meta.

  I think that this will be faster than prose communication.

Do it.

Ah, I see now.  We're using a custom chunk_einsum function that has **kwargs, so my suggestion of using the inspect module doesn't suffice to detect the failure early.

Yup. Sorry, this was my mistake, we've talked offline on how we could fix this case for einsum, but I should have pointed it out here as well.

Yes, so I now agree with you that, given that we're using **kwargs in einsum, we should probably call .compute in the test.  This is a bit of a regression in usability, but it seems like the right choice to me at the moment.

@mrocklin we can definitely undo that in the future, but we have to improve _meta exception handling before.

Thanks @pentschev !  Sorry for getting in the way here for a while :)

I've created #4951 and #4952 summarizing the discussion we had here, that would hopefully help us improve _meta.

Would it make sense to still raise TypeError if unrecognized keyword arguments that NumPy doesn't know how to handle are used?
e.g.,
if not kwargs.keys() <= {'casting', order'}:
    raise TypeError

We still don't have to pass them on to np.einsum() unless they were explicitly provided.
Xarray has a unit-test that verifies that the errors get raised for invalid keyword arguments (https://github.com/pydata/xarray/issues/3009). We could just remove the test, but it seems like a reasonable thing to keep around.

@shoyer https://github.com/dask/dask/pull/4954/files#diff-3598e11c3b3a16881fecff61abdf1f4cR97 will solve that.

It's worth noting that np.einsum itself doesn't note which arguments it takes in its signature, but only takes a generic **kwargs. This makes it hard for us to inspect and check validity of arguments at this level.
In [1]: import numpy as np

In [2]: import inspect

In [3]: inspect.getfullargspec(np.einsum)
Out[3]: FullArgSpec(args=[], varargs='operands', varkw='kwargs', defaults=None, kwonlyargs=[], kwonlydefaults=None, annotations={})

It would be better if NumPy's einsum explicitly listed keyword arguments it would accept so we could inspect it and stay current. Explicit checking on our end will inevitably go stale if the allowed keyword arguments change in the future.

As @pentschev mentions above, this is being resolved in https://github.com/dask/dask/pull/4954
Please excuse our churn here.
@shoyer so far I think that we'll be able to make the next Dask release fully backwards compatible from an Xarray perspective.

NumPy is saving Python 2 incompatible changes for 1.18 (the next release
after this one). But eventually they'll be able to use real keyword
arguments for einsum
On Mon, Jun 17, 2019 at 7:20 PM Matthew Rocklin<EMAIL_ADDRESS>wrote:

As @pentschev https://github.com/pentschev mentions above, this is
being resolved in #4954 https://github.com/dask/dask/pull/4954
Please excuse our churn here.
@shoyer https://github.com/shoyer so far I think that we'll be able to
make the next Dask release fully backwards compatible from an Xarray
perspective.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask/pull/4914?email_source=notifications&email_token=AAJJFVX2IYMKV25J54RP5WDP262TBA5CNFSM4HW6746KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODX3WK2A#issuecomment-502752616,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJJFVVHTBYES6ARBXJSLFTP262TBANCNFSM4HW6746A
.


CosmosDB VS code Driver connection issue

Reproduce:
Install CosmosDB extension - Sign in Azure Account - create a account via IDE (MongoDB API)
After creation error appears: Failed to connect to server (ERR connection refused)
Further when cannot create a database (via IDE using the extenion) - this throws error:
Cannot resolve tree item for element 1//subscriptions/xxx-7e1e-4430-9cf6-xxx/resourceGroups/xxxxx/providers/Microsoft.DocumentDB/databaseAccounts/xxx/xxx

@Leon-Africa ,

Does this consistently reproduce?
Was the account actually created ? After creation, does the account show up in the portal?
Was the 1// string appear as is, or did you modify it?

@PrashanthCorp

Yes
Account is not showing up in the portal when created from IDE
Copied string directly from the portal (What I did was created the DB via portal first (seeing that it was not working to create via IDE)- then refresh in IDE so the newly created DB can show - however I still get the connection error)

@Leon-Africa I'm having trouble understanding how to reproduce this, and it sounds like there are multiple issues here. Starting with the first, it sounds like you're having trouble creating a MongoDB account, correct?  What error are you getting?


hand bone not generating

Like the title says, the hand ik bone is not generating for some reason, there are no errors or anything, its just isnt there.
The rest of the rig works well.

Could you elaborate on what you mean? It seems like the hand bone is being generated from my testing:

If you have a particular model file causing this issue, that'd be helpful as well.

Hi, could you elaborate on what you mean? It seems like the hand bone is being generated from my testing:

If you have a particular model file causing this issue, that'd be helpful as well.

im so dumb omg, the bone was so small that i didnt saw it, it works yeah haha, anyway thanks for the reply


[AE-158]  Add Arduino_UnifiedStorage to repositories.txt

The Linter has identified one WARNING which we will ignore. See: https://github.com/arduino/library-registry/pull/3289#issuecomment-1705111284

The rule for library name length (LP010) has increased from 16 to 32. Once https://github.com/arduino/arduino-lint/pull/511 is part of the arduino linter release, this warning will be eliminated.


FR: trigger "battle" vs "selfbattle"

I expected "trigger battle" as an admin to trigger a fully randomized battle, but it triggers a battle with me involved. Perhaps that behavior should be "trigger selfbattle" or something while "trigger battle" follows the regular battle trigger logic like teambattle?

Fixed in passing via 73426c51527e58b53c254c725c0ee3bdf698e413.


Munge just4fun

Description
adds ability to change the preferred codec via SDP munging
Purpose
More fun with SDP munging
I think this is the point where i want more tests as described in https://github.com/webrtc/adapter/issues/232 ...

LGTM


Migration from astro repo

Some changes made in the astro repo were deleted in the main repo before being migrated. These are those changes.

Thanks, @JuanM04!


Uncaught Error: Value is null

Lightweight Charts Version: 3.1.3
I am using your chart for the cryptocurrency trade application in Vue project
but no matter what I get this error below is a sample code
There is no duplicated or null data.
import {createChart} from "lightweight-charts";
export default {
data() {
return {
                chartProperties: {
                  width: 700,
                  height: 300,
                  timeScale: {
                     timeVisible: true,
                     secondsVisible: false
                },
                layout: {
                    //backgroundColor: '#262C49', //Dark Theme
                    //textColor: '#80859E',
                    fontSize: 12,
                    fontFamily: 'irsans ,Calibri'
                }
            },
            chartData: [],
            candleSeries: null,
}
}
mounted() {

let cdata = [
{
close: 22750.76
high: 22759.53
low: 22750.25
open: 22752.8
time:<PHONE_NUMBER>
},
....
];

this.chartElement = document.getElementById('chart');
this.chartProperties.width = this.chartElement.offsetWidth;
this.chart = createChart(this.chartElement, this.chartProperties);
this.candleSeries = this.chart.addCandlestickSeries();

this.candleSeries.setData(cdata);

Actual behavior:
The chart is drawn with no candlestick

and repeated error of   Uncaught Error: Value is null

Can you try with the latest version?
Can you provide jsfiddle repro?

Update to latest version nothing change
jsfiddle : https://jsfiddle.net/miladganjali/cmu5htpb/8/

https://api.huobi.pro/market/history/kline?period=1min&symbol=btcusdt
data should be ordered by time in asc order, not in desc.

Thank u
I am closing the issue
I never see that in one million years it cost me 4  days thanks again.

https://api.huobi.pro/market/history/kline?period=1min&symbol=btcusdt
data should be ordered by time in asc order, not in desc.

I use this data but too the error has been occred.

https://api.huobi.pro/market/history/kline?period=1min&symbol=btcusdt
data should be ordered by time in asc order, not in desc.

I use this data but too the error has been occurred.

that was an error u should make data  ASC order in time

@miladganjali thanks, I have solve it.
const sortedData = data.sort((a, b) => a.time - b.time);

Even if my data is sorted it is giving me error

Even if my data is sorted it is giving me error

maybe this link and comments in answer can help you


Install instructions do not work for Arduino IDE

Using the Arduino IDE I followed the instructions in the README but there are some issues:

The Button2 library is not in the Arduino library manager, you have to download manually.
Then the compile fails with the following errors:

C:\src\arduino\TTGO-T-Display\TTGO-T-Display.ino: In function 'void button_init()':

TTGO-T-Display:50:30: error: no matching function for call to 'Button2::Button2()'

     pBtns = new Button2 [args];

                              ^

In file included from C:\src\arduino\TTGO-T-Display\TTGO-T-Display.ino:5:0:

C:\src\arduino\libraries\LennartHennigs-Button2-4105e70\src/Button2.h:55:5: note: candidate: Button2::Button2(byte, byte, unsigned int)

     Button2(byte attachTo, byte buttonMode = INPUT_PULLUP, unsigned int debounceTimeout = DEBOUNCE_MS);

     ^

C:\src\arduino\libraries\LennartHennigs-Button2-4105e70\src/Button2.h:55:5: note:   candidate expects 3 arguments, 0 provided

C:\src\arduino\libraries\LennartHennigs-Button2-4105e70\src/Button2.h:29:7: note: candidate: constexpr Button2::Button2(const Button2&)

 class Button2 {

       ^

C:\src\arduino\libraries\LennartHennigs-Button2-4105e70\src/Button2.h:29:7: note:   candidate expects 1 argument, 0 provided

C:\src\arduino\libraries\LennartHennigs-Button2-4105e70\src/Button2.h:29:7: note: candidate: constexpr Button2::Button2(Button2&&)

C:\src\arduino\libraries\LennartHennigs-Button2-4105e70\src/Button2.h:29:7: note:   candidate expects 1 argument, 0 provided

C:\src\arduino\TTGO-T-Display\TTGO-T-Display.ino: In lambda function:

TTGO-T-Display:62:26: error: 'TFT_DISPOFF' was not declared in this scope

         tft.writecommand(TFT_DISPOFF);

                          ^

TTGO-T-Display:63:26: error: 'TFT_SLPIN' was not declared in this scope

         tft.writecommand(TFT_SLPIN);

                          ^

Multiple libraries were found for "WiFi.h"
 Used: C:\Users\myuser\Documents\ArduinoData\packages\esp32\hardware\esp32\1.0.2\libraries\WiFi
 Not used: C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_<IP_ADDRESS>_x86__mdqgnx93n4wtt\libraries\WiFi
exit status 1
no matching function for call to 'Button2::Button2()'

The Button2 issue was fixed by using the lewishxe version - the link in that repo points to the original which doesn't work.

Now, the remaining error is:
Build options changed, rebuilding all
C:\src\arduino\TTGO-T-Display\TTGO-T-Display.ino: In lambda function:

TTGO-T-Display:62:26: error: 'TFT_DISPOFF' was not declared in this scope

         tft.writecommand(TFT_DISPOFF);

                          ^

TTGO-T-Display:63:26: error: 'TFT_SLPIN' was not declared in this scope

         tft.writecommand(TFT_SLPIN);

                          ^

Multiple libraries were found for "WiFi.h"
 Used: C:\Users\myuser\Documents\ArduinoData\packages\esp32\hardware\esp32\1.0.2\libraries\WiFi
 Not used: C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_<IP_ADDRESS>_x86__mdqgnx93n4wtt\libraries\WiFi
exit status 1
'TFT_DISPOFF' was not declared in this scope

OK, so I'm guessing that the reason it isn't working is that you have referenced a FORK of the actual library instead of the library itself. That fork is 96 commits behind the original!
Why on earth would you do that?
At least make it clear in the README that is what you have done.

Yes, the referenced TFT_eSPI is the branch that I modified after the fork. I should describe it clearly in the readme. Thank you for your reminder.

It would be a good idea to rebase from the original Bodmer repo. They have renamed the driver, so this patch works against the 1.4.11 release from that repo for the TTGO X Display. Although I'm not sure why it needs to be set as 240 width when it clearly isnt...
1.4.11-TTGO-T-Display.txt

Am I missing something? With all due respect, I can't see why this fork is needed at all? Why not PR any improvements back to the original rather than confusing people?

@lilphil/@lewisxhe why do we need another fork? Much better to update the original (it has now been updated and should work just fine) than confuse people with another fork that gets out-of-date.

Okay, I am super confused here and have been working on this for hours.  Am I supposed to use the linked forks or the original? Neither work for me. The original just gives me errors and linked forks display nothing but the serial monitor shows me that it is working as expected. Also, why are there instructions about moving and modifying files. Shouldn't those details be taken care of in the fork? I don't know how I did it but I once had a display that read "Voltage :4.70" with a small rectangle next to it that seemed to be a shrunk down version of what it used to display on the entire screen what I first purchased it. Also, the pretty graphical TTGO display does not show. Help please.

Check this video on how to install it https://youtu.be/qj9dN-Ginxc

Works! Thanks.

The library used has been synchronized to the main branch

I'm having problems using this repository with the TTGO T-Display module. I've followed the instructions in the ReadMe file, installed the latest versions of the master branch for both TFT_eSPI and Button2 libraries. I've downloaded this repo's files. I've moved the TTGO_T_Display.h file into the User_Setups folder, and referenced it in the User_Setup_Select.h file. I've made sure the bmp.h file is in the correct folder to build and push the files to the device. However, when the code runs it is only updating about 1/3 of the screen, and the text horizontal, not vertical. Something seems to be wrong in the current files and I'm not sure what I need to change to get it working again. Help would be greatly appreciated!

For others that might still be having problems with the screen: If it looks like only 1/3 of the screen is being used, be sure to comment out the default "#include <User_Setup.h>" line of text in the User_Setup_Select.h file that you add the "#include <User_Setups/TTGO_T_Display.h>" line to. Keeping both lines will cause the screen settings to be incorrect. This was not shown in the youtube video linked by FixxCZ, but solved the problem for me.

https://github.com/Mystereon/TTGO-T-DISPLAY-LIFE-/tree/master

Just worked through the instructions making sure to follow the video and @spradlinb 's suggestion and the image displayed on the screen is half the TTGO image and half the multicolored screen. Here's an image of how it looks

Any thoughts?

In
_https://github.com/Bodmer/TFT_eSPI/blob/master/User_Setup.h_ must
ILI9341_DRIVER be commented out.
// Only define one driver, the other ones must be commented out
#define ILI9341_DRIVER

iCompiles and upload for me (I trashed the original WiFi library), but nothing on screen, the sketch doesn't even start, and I get this in the Serial monitor :
**Rebooting...
ets Jun  8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:956
load:0x40078000,len:0
load:0x40078000,len:13076
entry 0x40078a58
assertion "false && "item should have been present in cache"" failed: file "/Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/nvs_flash/src/nvs_item_hash_list.cpp", line 85, function: void nvs::HashList::erase(size_t)
abort() was called at PC 0x400d8f3b on core 0
Backtrace: 0x400884bc:0x3ffcd750 0x400885bb:0x3ffcd770 0x400d8f3b:0x3ffcd790 0x400dd78c:0x3ffcd7c0 0x400dde42:0x3ffcd7e0 0x400de171:0x3ffcd830 0x400dd23c:0x3ffcd890 0x400dcd96:0x3ffcd8e0 0x400dce2f:0x3ffcd900 0x400dce7a:0x3ffcd920 0x400d4ca8:0x3ffcd940 0x4010ff47:0x3ffcd960 0x400da60a:0x3ffcd990
Rebooting...**
and again and again
Actually, it looks similar to the heap problems I 've found on other forums that make the ESP crash in special WiFi cases, but in my case I don't even see  the first print statement in setup().
Any idea what could be wrong ? I updated my ESP32 files to 1.0.4 but it doesn't change anything

Using the Arduino IDE I followed the instructions in the README but there are some issues:

The Button2 library is not in the Arduino library manager, you have to download manually.
Then the compile fails with the following errors:

C:\src\arduino\TTGO-T-Display\TTGO-T-Display.ino: In function 'void button_init()':

TTGO-T-Display:50:30: error: no matching function for call to 'Button2::Button2()'

     pBtns = new Button2 [args];

                              ^

In file included from C:\src\arduino\TTGO-T-Display\TTGO-T-Display.ino:5:0:

C:\src\arduino\libraries\LennartHennigs-Button2-4105e70\src/Button2.h:55:5: note: candidate: Button2::Button2(byte, byte, unsigned int)

     Button2(byte attachTo, byte buttonMode = INPUT_PULLUP, unsigned int debounceTimeout = DEBOUNCE_MS);

     ^

C:\src\arduino\libraries\LennartHennigs-Button2-4105e70\src/Button2.h:55:5: note:   candidate expects 3 arguments, 0 provided

C:\src\arduino\libraries\LennartHennigs-Button2-4105e70\src/Button2.h:29:7: note: candidate: constexpr Button2::Button2(const Button2&)

 class Button2 {

       ^

C:\src\arduino\libraries\LennartHennigs-Button2-4105e70\src/Button2.h:29:7: note:   candidate expects 1 argument, 0 provided

C:\src\arduino\libraries\LennartHennigs-Button2-4105e70\src/Button2.h:29:7: note: candidate: constexpr Button2::Button2(Button2&&)

C:\src\arduino\libraries\LennartHennigs-Button2-4105e70\src/Button2.h:29:7: note:   candidate expects 1 argument, 0 provided

C:\src\arduino\TTGO-T-Display\TTGO-T-Display.ino: In lambda function:

TTGO-T-Display:62:26: error: 'TFT_DISPOFF' was not declared in this scope

         tft.writecommand(TFT_DISPOFF);

                          ^

TTGO-T-Display:63:26: error: 'TFT_SLPIN' was not declared in this scope

         tft.writecommand(TFT_SLPIN);

                          ^

Multiple libraries were found for "WiFi.h"
 Used: C:\Users\myuser\Documents\ArduinoData\packages\esp32\hardware\esp32\1.0.2\libraries\WiFi
 Not used: C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_<IP_ADDRESS>_x86__mdqgnx93n4wtt\libraries\WiFi
exit status 1
no matching function for call to 'Button2::Button2()'

did you have any errors such this one
Compilation error: bmp.h: No such file or directory
if it is a library i can find it anywhere


xcdatamodeld not handled properly

Not sure if it's a liftoff issue or a CocoaPods/Xcodeproj one, but if I add a xcdatamodeld file to my template, it gets added as a regular file (PBXFileReference) in the generated Xcode project, instead of a special entry for xcdatamodeld files (isa = XCVersionGroup & versionGroupType = wrapper.xcdatamodel).
As a result, Xcode does not recognize it as an actual CoreData model.
Removing the xcdatamodeld reference from the Xcode project and adding it again manually solves the problem.

Steps to reproduce

Create a Model.xcdatamodeld file using Xcode
Save it in ~/liftoff/templates/Model.xcdatamodeld
Add an entry for it in your ~/.liftoffrc file
Generate a new project using liftoff command line

Actual Result
The Model.xcdatamodel is present in the Project Navigator but when selecting it, it does not recognize it as an CoreData model and the data model does not get displayed in the main editor, because it has been added as a PBXFileReference.
Expected Result
The Model.xcdatamodel should have been added as a XCVersionGroup entry with versionGroupType = wrapper.xcdatamodel so that Xcode recognizes it and display its content when selected in the Project Navigator.

$ liftoff --version
Version: 1.4.1
$ xcproj --version
0.1.2

@AliSoftware @gfontenot @Ashton-W Submitted a PR for this in CocoaPods/Xcodeproj#291 - tests are failing but I'm not familiar enough with Ruby tests to dig in. Bottom line xcodeproj is fine if your datamodel lives in your project root, otherwise it fails to create the children and current version since path.exists? fails

Should be fixed in Xcodeproj version 1.3.3 and higher.


Fishing

Description
Task: Adds fishing
Feature: #544
The majority of the map feels empty or useless to gameplay, and as such to make more use of the map fishing will be added. This will force the player to use the beaches to catch fish for quests or food whilst providing a stable source of food for the early game (while they wait for plants to grow). Since this only forces the player to the water we will also be making lava fishing, this will allow the player to catch special fish that will heal / feed the player an increased amount in comparison to other foods. This will hopefully force the player to expand their horizons and explore more of the map.
Milestones
List of steps that need to be completed for this task.

[x] Step 1 (Oct. 17) - Create fishing rod item
[ ] Step 2 (Oct. 17) - Create fishing quests
[ ] Step 3 (Oct. 17) - Create fishing animations and tool art
[ ] Step 4 (Oct. 17) - Create fishing mechanics
[ ] Step 5 (Oct. 17) - Create documentation on fishing
[x] Step 6 (Oct. 17) - Create two types (at least) of fish items that differ depending on if it is water or lava
[ ] Step 7 (Oct. 17) - Create tests for the fishing rod

Completion Deadline: Oct.17
Documentation
Member

Jackson Trenerry @JTrenerry

Tool / item sprites are done, only art to do is animating the cast of the rod

Fish eating is done

Just waiting on art in game / to be triggered correctly

Since this was done pre quick might make more fosh


Cannot use this plugin in markdown file.

It is wonderful work. But, I meet a problem. I can use the snips in tex file but not in md file. I pin the branch to "markdown" use packer plugin manager and I add the "markdown" to the ft configuration of this plugin. But I still can not trigger any snips which I can in tex file.

Duplicate of #5

Duplicate of #5