Is Measurements.jl compatible with Optim.jl and ForwardDiff.jl, or am I facing a gotcha?

Forgive me for etiquette and formatting issues, this is my first real github issue post. Further, if this wasn't the appropriate place to post problems like this, please let me know.
What I'm trying to do
I'm trying to optimize a function that has error associated with it.
I'm aware there is not a meaningful way to propagate error through the optimization process out-of-the-box, as we're guessing with a pure number, but my strategy would be to optimize twice: Once for the actual value, and a second time to arrive at the same error as the target variable. I'm running into some very strange issues when trying to accomplish the former, however, and cannot tell if it is due to my being new to Julia, or something fundamental to one of the packages involved.
Tl,dr: For all intents and purposes, right now I'm just trying to optimize a pure number, where Measurement.jl types might be fed in as well. I don't care if errors aren't propagated correctly in this case, I just want this to happen without errors i.e., I want ForwardDiff and Measurement types to play nice.
The nature of the problem (context)
The code in question right now is a struct capable of solving one of the three following variables, given the other two: P, V, and T.
e.g., if P and T are specified, V is solvable
If V and T are specified, then solving P is an analytical problem (and thus does not need Optim.jl), right now Measurements works wonderfully in this case.
If P and T are specified, we need to guess V until we minimize the loss function: (P_calculated - P_given)^2. This is done with Optim.jl and using automatic differentiation. I've also tried using finite differencing. This is where Measurements.jl (or something else) seems to fail.
Errors and information
When feeding a function into Optim.jl where any variable involved is a Measurement type, the following type of ambiguity errors occur with simple arithmetic methods:
ERROR: LoadError: MethodError: /(::Measurement{Float64}, ::ForwardDiff.Dual{ForwardDiff.Tag{Main.PengRobinson.var"#2#3"{SVector{2, Main.PengRobinson.PengRobinsonChemical{Float64, Float64, Float64, Float64, Float64}}, SVector{2, Float64}, SMatrix{2, 2, Float64, 4}, Float64, Measurement{Float64}}, Float64}, Float64, 1}) is ambiguous. Candidates:
  /(x::AbstractFloat, y::ForwardDiff.Dual{Ty, V, N} where {V, N}) where Ty in ForwardDiff at C:\Users\Will\.julia\packages\ForwardDiff\sqhTO\src\dual.jl:140
  /(x::Real, y::ForwardDiff.Dual{Ty, V, N} where {V, N}) where Ty in ForwardDiff at C:\Users\Will\.julia\packages\ForwardDiff\sqhTO\src\dual.jl:140
  /(a::Measurement{T}, b::Real) where T<:AbstractFloat in Measurements at C:\Users\Will\.julia\packages\Measurements\PVbNf\src\math.jl:250
Possible fix, define
  /(::Measurement{T}, ::ForwardDiff.Dual{Ty, V, N} where {V, N}) where {T<:AbstractFloat, Ty}

If we instead forego automatic differentiation, and have Optim.jl try to use a function containing any measurement type with finite differencing, we arrive at
ERROR: LoadError: MethodError: no method matching Float64(::Measurement{Float64})
Closest candidates are:
  (::Type{T})(::Real, ::RoundingMode) where T<:AbstractFloat at rounding.jl:200
  (::Type{T})(::T) where T<:Number at boot.jl:760
  (::Type{T})(::AbstractChar) where T<:Union{AbstractChar, Number} at char.jl:50
  ...

And this last error seems to be something that is more my fault than anything else. However, it isn't traced back to my own code, but rather something in Optim.jl. The full stack trace for this is below:
Stacktrace:
  [1] convert(#unused#::Type{Float64}, x::Measurement{Float64})
    @ Base .\number.jl:7
  [2] setindex!(A::Vector{Float64}, x::Measurement{Float64}, i1::Int64)
    @ Base .\array.jl:839
  [3] finite_difference_gradient!(df::Vector{Float64}, f::Main.PengRobinson.var"#2#3"{SVector{2, Main.PengRobinson.PengRobinsonChemical{Float64, Float64, Float64, Float64, Float64}}, SVector{2, Float64}, SMatrix{2, 2, Float64, 4}, Float64, Measurement{Float64}}, x::Vector{Float64}, cache::FiniteDiff.GradientCache{Nothing, Nothing, Nothing, Vector{Float64}, Val{:central}(), Float64, Val{true}()}; relstep::Float64, absstep::Float64, dir::Bool)
    @ FiniteDiff ~\.julia\packages\FiniteDiff\blirf\src\gradients.jl:277
  [4] finite_difference_gradient!(df::Vector{Float64}, f::Function, x::Vector{Float64}, cache::FiniteDiff.GradientCache{Nothing, Nothing, Nothing, Vector{Float64}, Val{:central}(), Float64, Val{true}()})
    @ FiniteDiff ~\.julia\packages\FiniteDiff\blirf\src\gradients.jl:224
  [5] (::NLSolversBase.var"#g!#44"{Main.PengRobinson.var"#2#3"{SVector{2, Main.PengRobinson.PengRobinsonChemical{Float64, Float64, Float64, Float64, Float64}}, SVector{2, Float64}, SMatrix{2, 2, Float64, 4}, Float64, Measurement{Float64}}, FiniteDiff.GradientCache{Nothing, Nothing, Nothing, Vector{Float64}, Val{:central}(), Float64, Val{true}()}})(storage::Vector{Float64}, x::Vector{Float64})
    @ NLSolversBase ~\.julia\packages\NLSolversBase\geyh3\src\objective_types\twicedifferentiable.jl:113
  [6] (::NLSolversBase.var"#fg!#45"{Main.PengRobinson.var"#2#3"{SVector{2, Main.PengRobinson.PengRobinsonChemical{Float64, Float64, Float64, Float64, Float64}}, SVector{2, Float64}, SMatrix{2, 2, Float64, 4}, Float64, Measurement{Float64}}})(storage::Vector{Float64}, x::Vector{Float64})
    @ NLSolversBase ~\.julia\packages\NLSolversBase\geyh3\src\objective_types\twicedifferentiable.jl:117
  [7] value_gradient!!(obj::TwiceDifferentiable{Float64, Vector{Float64}, Matrix{Float64}, Vector{Float64}}, x::Vector{Float64})
    @ NLSolversBase ~\.julia\packages\NLSolversBase\geyh3\src\interface.jl:82
  [8] initial_state(method::Newton{LineSearches.InitialStatic{Float64}, LineSearches.HagerZhang{Float64, Base.RefValue{Bool}}}, options::Optim.Options{Float64, Nothing}, d::TwiceDifferentiable{Float64, Vector{Float64}, Matrix{Float64}, Vector{Float64}}, initial_x::Vector{Float64})
    @ Optim ~\.julia\packages\Optim\uwNqi\src\multivariate\solvers\second_order\newton.jl:45
  [9] optimize
    @ ~\.julia\packages\Optim\uwNqi\src\multivariate\optimize\optimize.jl:35 [inlined]
 [10] #optimize#87
    @ ~\.julia\packages\Optim\uwNqi\src\multivariate\optimize\interface.jl:142 [inlined]
 [11] optimize(f::Function, initial_x::Vector{Float64}, method::Newton{LineSearches.InitialStatic{Float64}, LineSearches.HagerZhang{Float64, Base.RefValue{Bool}}}, options::Optim.Options{Float64, Nothing}) (repeats 2 times)
    @ Optim ~\.julia\packages\Optim\uwNqi\src\multivariate\optimize\interface.jl:141
 [12] Main.PengRobinson.PengRobinsonState(components::Vector{Main.PengRobinson.PengRobinsonChemical{Float64, Float64, Float64, Float64, Float64}}, mole_fractions::Vector{Float64}, kijmatrix::Matrix{Float64}; p::Float64, v::Nothing, t::Measurement{Float64}, minimal_calculations::Bool)
    @ Main.PengRobinson c:\git\julia-polymer-membranes\PolymerMembranes.jl\StaticPengRobinson.jl:75
 [13] top-level scope
    @ c:\git\julia-polymer-membranes\PolymerMembranes.jl\test.jl:26
in expression starting at c:\git\julia-polymer-membranes\PolymerMembranes.jl\test.jl:26

I was going to provide a minimum working example but it turned out to be a bit too hefty to post here, if this issue is truly a potential compatibility problem with Measurements and someone needs to reproduce this easily, please run test.jl in this repo and be sure to add the measurement syntactic sugar somewhere to cause the error (otherwise it will work!) in one of the constructor methods.

I'm aware of some issues with Optim.jl, but due to a bug in that package: https://github.com/JuliaNLSolvers/Optim.jl/issues/823. I believe Measurements.jl can't work with ForwardDiff because of the limitations of the latter package.
In the end, I don't think there is anything I can do here

Can't believe I missed that post in the Optim page! Thanks for pointing this out! It's helpful as it tells me that this is a fundamental bug and not something I'm doing incorrectly when feeding it in.
For anyone else struggling with this: I'm attempting the following workaround (as long as your main case allows for analytical solutions that work with Measurements.jl)

Define a second constructor for using Measurement types with
Strip all Measurement types to only their values via measurement.val
Optimize the value normally (no measurement types)
Define a new optimizer for the uncertainty component only (now that you've solved the actual value)
a. The optimized function should only take in the uncertainty, the value should be static now.
Use a black box optimizer to solve the uncertainty. I'm going to attempt this with BlackBoxOptim.jl
Reconstruct the solved Measurement with the solved value and uncertainty

@giordano A few of us from the Humans of Julia discord noticed that the line #92 in Measurements.jl is the culprit in the ForwardDiff dual numbers. Do you know about this?
measurement(val::Real, err::Real) = measurement(promote(float(val), float(err))...)

When using autodiff=true in Optim.jl, the following loop occurs
ERROR: LoadError: StackOverflowError:
Stacktrace:
 [1] measurement(val::ForwardDiff.Dual{ForwardDiff.Tag{Main.PengRobinson.PRVolumeSolver.var"#target_function#1"{StaticArrays.SVector{2, Main.PengRobinson.PengRobinsonChemical{Float64, Float64, Float64, Float64, Float64}}, StaticArrays.SVector{2, Measurement{Float64}}, StaticArrays.SMatrix{2, 2, Float64, 4}, Float64, Float64, Measurement{Float64}}, Float64}, Float64, 1}, err::ForwardDiff.Dual{ForwardDiff.Tag{Main.PengRobinson.PRVolumeSolver.var"#target_function#1"{StaticArrays.SVector{2, Main.PengRobinson.PengRobinsonChemical{Float64, Float64, Float64, Float64, Float64}}, StaticArrays.SVector{2, Measurement{Float64}}, StaticArrays.SMatrix{2, 2, Float64, 4}, Float64, Float64, Measurement{Float64}}, Float64}, Float64, 1}) (repeats 79984 times)
   @ Measurements ~\.julia\dev\Measurements\src\Measurements.jl:92
in expression starting at c:\git\julia-polymer-membranes\PolymerMembranes.jl\test.jl:30

In the case that you use Optim.jl's finite differencing, the issue doesn't occur, so it seems the issue is that line calling itself until the Stack Overflow Error happens. If you want to know more about what I was doing / talk to us over at HoJ, I'm more than happy to explain it!

That's not the problem, the culprit is FortwardDiff being unable to deal with anything more specific than Real, the StackOverflow you see it's only of symptom of their limitation.  Quoting from the documentation of ForwardDiff

The target function must be written generically enough to accept numbers of type T<:Real as input (or arrays of these numbers). The function doesn't require a specific type signature, as long as the type signature is generic enough to avoid breaking this rule. This also means that any storage assigned used within the function must be generic as well (see this comment for an example).

But Measurement <: AbstractFloat and I'm not going to change the subtyping.

That's completely understandable, and thanks for the quick responses!
So far, it seems that using Optim.jl while breaking the components into uncertainties and values and solving them independently works well, do you have any advice about how I might go about splitting a measurement object into this without running into issues?
Applying the same technique to other optimization libraries like BlackBoxOptim.jl, which (shouldn't) do any autodiff-like things with the functions creates very strange results. There, the same stackoverflow issue happens without even doing anything other than just using Measurements in the same code. Here's a tiny (ish) example done on Julia 1.6.0.
using BlackBoxOptim
# using Measurements  # uncomment this after confirming it runs correctly
function solve_volume_uncertainty_bbox(p_uncertainty, v_value, t)
    function target_function(volume_uncertainty_guess_l_mol)
        resulting_pressure = 4
        return (resulting_pressure - p_uncertainty)^2
    end
    res = bboptimize(target_function; SearchRange=(0.0, 10.0), NumDimensions=1, Method=:de_rand_1_bin)
    return best_candidate(res)[1]
end

bbox = solve_volume_uncertainty_bbox(0.1, 20.08405, 273.15)
println(bbox)

It may also just be something that happens on my machine. I'm hoping that this might prove useful to you in some way, because I'm super excited that this library exists. In my field, errors are basically unseen in most literature (I'm planning on citing your library in mine as well, once I get my underlying calculations working!), as its too lengthy to do the analytical calculations by hand. The ultimate version of this would be to somehow generally extend it to optimization as well as direct or, for the lack of a better word: analytical as opposed to iterative, solutions are only a subset of the calculations done.

That's extremely bizarre, but since Measurements isn't directly involved apart from loading it (and thus adding a new datastructure) my guess is that BlackBoxOptim is doing something fishy with type-inference (looking also at the output, it goes crazy when inferring the type of some containers).  I'd report them this issue (and we'd be up to three packages not working correctly out-of-the-box because of their limitations :slightly_smiling_face:)

BTW, in https://github.com/JuliaNLSolvers/Optim.jl/issues/823 I had some suggestions about how to fix Optim.jl (those are genuinely issues in the package, unrelated to Measurements.jl).  If you're interested in using Optim.jl together with Measurements.jl I'd recommend you to comment on that issue to make the maintainer aware that there is interest in getting it fixed :slightly_smiling_face:

For the record, BlackBoxOptim seems to go haywire because of this log(::Real, ::Measurement) method
https://github.com/JuliaPhysics/Measurements.jl/blob/e71f5203ee70fd66057d349855b604db126d4a55/src/math.jl#L619-L622
but frankly I don't see how that would be relevant since it isn't called at all in your example.

Thanks @giordano! This is extremely helpful, how did you track down the BlackBoxOptim.jl issue to those lines? I was never quite able to narrow it down further than things happening in my own code. This was mainly because the stackoverflow error caused by importing Measurements was just a whole bunch of spam in the terminal, followed by the correct answer (Measurements propagated through correctly!) Is this what it showed up to you as? Or did you get a formal exception followed by the process exiting early?
I'll send it over to them and see if they'd be willing to work on it! Ideally we'd have at least one optimization library that works without tomfoolery in Measurements. BlackBoxOptim would be a nice one! They have the BorgMOEA algorithm implemented which can handle multiple objective functions, and would be perfect for optimizing both the value and uncertainty in a single optimization process.

Binary search: I commented half of the code of Measurements.jl until I couldn't trigger the error, then repeat :slightly_smiling_face:

Whelp, I'm adding that to my bag of tricks. Thanks again!

ok, im trying to make optim work with measurements, and the main show problem comes on the use of the @sprintf macro for printing


Styling for "error" in editor does not have enough contrast [Dark mode]

This seems to only affect Dark mode, as Light mode has its own set of values. Currently, text in the editor which is marked as an error, is very difficult to read, due to low contrast between the highlight colour, and the underlying text colour. The highlight colour is bound to the variable --colour-cm-error, which currently is set to #f2777a and looks like this:

I would suggest changing the hex value to something like #b15255 which would result in this:

This new value feels very similar at a glance, but is far more readable (in my opinion)

Deployed, thanks


Feature: ipympl for plots pane

Could ipympl be used instead of pngs for the plotting pane.
It is an interactive matplotlib backend https://github.com/matplotlib/ipympl

Hey @esillekens, thanks for reporting. Unfortunately, that's not possible because the Plots pane only works with the Inline Matplotlib backend.
However, we're planning to create another pane that will display web content that results from running code. And when that's in place, the output of ipympl will be displayed on it.


Add ability to navigate through open wooden doors.

Hi,
This little PR adds the ability to navigate through open wooden doors.  If this is acceptable we were also looking at how the bot could open a door that is closed.
Kind regards,
Nic
Co-Authored-By: Erik Veld<EMAIL_ADDRESS>

To open a closed door, simply call bot.activateBlock(block) on the door. This would be done as the bot is traveling along the path, so you wouldn't need to calculate this at pathfinding time.

To open a closed door, simply call bot.activateBlock(block) on the door. This would be done as the bot is traveling along the path, so you wouldn't need to calculate this at pathfinding time.

Would be nice to have an option to toggle it since some servers prevent interacting with doors.

To open a closed door, simply call bot.activateBlock(block) on the door. This would be done as the bot is traveling along the path, so you wouldn't need to calculate this at pathfinding time.

Would be nice to have an option to toggle it since some servers prevent interacting with doors.

That's true, yes. The same way we have canDig, for example. I agree.

Hey sorry, will get onto some updates this week, just been a little busy.

@nicholasjackson What's the status of this PR ? Are you going to continue ?

@nicholasjackson What's the status of this PR ? Are you going to continue ?

@nicholasjackson Reopen if you want to work on this again.

@nicholasjackson Reopen if you want to work on this again.

Is this going to be implemented some time?

So sorry about this, I have not had time to move recently. I will pick this back up in the near future, implementing the comments from this PR and raise a new one.

any updates on this? @nicholasjackson (no rush btw)

it's still not fixed and the bot is still not opening the doors and still breaking the wall xDDD

Guys, that's super confusing issue is still actual


Feature/efs caching

Context

Changes proposed in this pull request

Guidance to review

Link to JIRA ticket

Things to check

[ ] I have added any new ENV vars in all deployed environments and updated the .env.example and .env.test files in the repo

@lcardno10, is this one mergeable?


Typo

Property initializers provide make it clear which value is setting which property

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

ID: c36588d0-6bdf-1740-220c-10b20bb88730
Version Independent ID: 587ed47f-f532-e018-9b0d-6ee76afd20e4
Content: What's new in C# 9.0 - C# Guide
Content Source: docs/csharp/whats-new/csharp-9.md
Product: dotnet-csharp
Technology: csharp-whats-new
GitHub Login: @BillWagner
Microsoft Alias: wiwagn

Thanks @daveyostcom I just opened #20575 to fix this.
When you find these, it might save both of us time to submit the PR yourself. You can click the edit button (it looks like a pencil) to edit the content in your browser.

Fixed in #20564


A measure of uncertainty for multioutput regression

I often need to perform active learning in the context of multioutput regression. I thus need a measure of uncertainty for my regressor. However, MapieRegressor is not compatible with MultiOutputRegressor
Describe the solution you'd like
I would like to be able to predict either valid prediction intervals for each output (thus, PIs with formal coverage for each variable marginally, but not jointly), or even better, valid prediction regions (thus, hyperrectangles with formal coverage for all variables jointly), but I don't know if the latter case is covered by conformal prediction. The implementation should be compatible with MultiOutputRegressor. In other words, I'm looking for a MultiOutputMapieRegression where estimator can accept an instance of the MultiOutputRegressor class.

Hey @AndreaPi,
Thank you for the issue raised. This is indeed something we have thought about, #97 #431. Our roadmap is quite busy at the moment, but we will have a half year review soon.
Are there any papers you've identified that could be implemented into MAPIE that describe the solution you want?
Thank you!

Hi @LacombeLouis,
thanks for the answer! Regarding papers, I'm not a big expert on this topic, but these are two papers that seem quite relevant to me:
https://proceedings.mlr.press/v162/angelopoulos22a/angelopoulos22a.pdf
https://arxiv.org/abs/2110.00816
https://arxiv.org/abs/2101.12002
Alternatively, I wonder if you're in contact with Ryan Tibshirani? He didn't cover multioutput regression in his course this year https://www.stat.berkeley.edu/~ryantibs/statlearn-s24/ but I'm sure either he or Yaniv Romano may have tips on this. Finally, I may ask Anastasios Angelopoulos, though I guess he'll point me back to his paper above.


Creating a New Play List. Usability

OS: Windows 10 Home
GPMDP Version: V4.6.1.
Issue Descriptions:  It is not obvious way to create a new PlayList
Steps to Reproduce:

Open the application "GooglePlayMusicdesktopPlayer"
Log-in
Go to the Music Library-Play Lists
Try to find way how to create a NEW PlayList

Expected result:  I see a HUGE button '+' or 'Create', or 'New playlist', or 'Add playlist'
Actual result: 1) I can create a new playlist just pushing the right mouse button on the icon of ' auto play list'. in this case we have opportunity to create a new playlist this way "Add playlist to Playlist --- New playlist" 2) Push the button 'three points' near the song, in this case the way of creating is "Add to playlist---new playlist" and the last one 3) there is a button 'open the Playlist drawer' in the upper right corner of the page - there you can create and edit all playlists, BUT it is to small and not evident


Cmake should download (and version) the deps

Motivation
The build of this tool should not depend on its dependencies to be in a specific path (eg., ../).
The way it's done now it forces a user to know in advance what are the dependencies to download in advance, and where to put them.
We want to improve this experience IMHO :)
Furthermore, this is needed to be able to build a more self-contained CI pipeline.
Feature
The dependencies should be downloaded and versioned from the pdig CMake, without assumptions on their position on the file system.
Something like what we did for Falco itself.
Look here.
Additional context
I refer to this line.

/assign

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle rotten

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

@poiana: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@poiana: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.


run php cs fixer on app folder

The result is pretty rubbish, too many meaningless changes that to not have major impact on code readability.


Ability to configure workbench.action.toggleEditorWidths screen percentage

I used to use a plugin in Atom called Heypane that automatically resized editor groups so that the focused group occupied a certain screen percentage. Using workbench.action.toggleEditorWidths, VSCode already has the logic for this implemented it seems. Clicking, or navigating by hotkey, between groups after toggling that setting will auto-resize the focused group to take up most of the screen
The problem is, I can't tweak what screen percentage the focused group occupies. I'd like to be able to set the focus to 55-65% as opposed to the ~90% it currently is, as that allows most code in the periphery to still be visible while a little extra width/height is available for what's in focus.

+1 This has been requested many times over the years because it's so useful.
My use case: I would like to set an editor group to 0% width, to "collapse" it. I often have two or three groups open, and even at minimum width they are too wide - I want them out of the way.


[ExternalNode] CRD for support bundle

CRD  for support bundle.
Signed-off-by: wenyingd<EMAIL_ADDRESS>

I deleted the original code branch by mistake, and this PR is closed. So I create a new one https://github.com/antrea-io/antrea/pull/4150 for the same purpose.


Add RouterOS Script

Description

Currently, RouterOS Script is identified as the Rascal programming language, because they share the extension .rsc.
The languages look pretty dissimilar, so the samples I provided should be enough to distinguish them without a heuristic.
Checklist:

[x] I am adding a new language.

[x] The extension of the new language is used in hundreds of repositories on GitHub.com.

Search results for each extension:

https://github.com/search?q=extension%3Arsc+interface+NOT+nothack&type=Code

[x] I have included a real-world usage sample for all extensions added in this PR:

Sample source(s):

BackupAndUpdate.rsc -> Taken from a GitHub repo with MIT License
config.rsc -> Written by me for this contribution
console-dump.rsc -> Default configuration dump from my Mikrotik router
vlans.rsc -> Taken from the Mikrotik Wiki

Sample license(s):

[x] I have included a syntax highlighting grammar: URL to grammar repo, MIT License
[x] I have updated the heuristics to distinguish my language from others using the same extension.

The languages look pretty dissimilar, so the samples I provided should be enough to distinguish them without a heuristic.

Please let me know if a heuristic is needed!

Please let me know if a heuristic is needed!

Yes, it looks like we're going to need one as the classifier test is failing because it's detecting one of the Rascal files as RouterOS:
592 Rascal/Rascal.rsc BAD (RouterOS Script)

Yes, it looks like we're going to need one as the classifier test is failing because it's detecting one of the Rascal files as RouterOS:

Added a heuristic here https://github.com/github/linguist/pull/5945/commits/3150ab6e720a3bfa482a991298f048428d6a029f

@lildude I'm a little confused where to go from here... I tried improving the heuristic, but the classifier kept misclassifying Rascal.rsc. That prompted me to dig into the Ruby code (I do not know Ruby 😅), and I learned that the classifier doesn't use the heuristics, because they are separate strategies.
So that failure in the action can't be improved by changing the heuristic. Should I instead add more samples?

I learned that the classifier doesn't use the heuristics, because they are separate strategies.

🤔 It does... sort of. It ignores them here:
https://github.com/github/linguist/blob/f3da780afabd10e392901c0940b2a7af1d4b314e/script/cross-validation#L51-L61
But now I look closer, I see it'll only ignore these if there's a final conclusive language, which you've not added for .rsc, which isn't a problem.
I've just checked your heuristics and the Rascal one is waaay too liberal. It matches your samples/RouterOS Script/BackupAndUpdate.rsc RouterOS sample 🤭 hence the failing tests.
Now I look at it more closely, samples/Rascal/Rascal.rsc isn't even written in Rascal; it's a syntax definition of the language so includes tokens not even used in the language, hence the misclassification. I'm going to remove that and push a few more real Rascal samples to this PR and remove the heuristics.

Thanks for the help!


User datasets: Update text on the "New upload" tab

Discussed in User datasets meeting on July 12th and we want to

Update all required fields to have an asterisk at the end of the label (so Name*, Summary*, Upload File* while Description has no asterisk and is not required). I would also recommend removing the colon from the end of every label, but that hasn't been discussed
Update the text in the Summary field from "brief summary of the data set contents" to "brief summary of the data set in 1-2 sentences"
Update the text in the Description field from "brief description of the data set contents" to "optional longer description of the data set including background, study objectives, methodology, etc."
Add text at the bottom of the page (see MicrobiomeDB's page as an example) saying "File must be a .csv or tab-delimited .txt file"

Confirm that the above changes have been made.


"unable to fetch Best of JavaScript data"

Hello Felix @shiftgeist
Thank you for reaching us, could you let me know when that error happens?
It may been a temporary network issue.

It happend shotly bevore I created this issue.
Was a temporary issue most likely.


Update Project to ensure all targets build and test

The commit log should be pretty clear.
I was first alerted to the possibility of an issue when trying to checkout this module with carthage to try to update ELAnalytics which depends on it.
The output was:
 ✘  ~/dev/ELJSBridge   master ●  carthage update --no-use-binaries
*** Fetching ELLog
*** Fetching ELFoundation
*** Checking out ELFoundation at "v2.0.0"
*** Checking out ELLog at "v3.0.0"
*** xcodebuild output can be found in /var/folders/06/tf7sh6w14wn09ngqwp65lf9h0v9rz6/T/carthage-xcodebuild.PkUlMp.log
*** Building scheme "ELFoundation_osx" in ELFoundation.xcodeproj
** CLEAN FAILED **

The following build commands failed:
        Check dependencies
(1 failure)
** BUILD FAILED **

The following build commands failed:
        Check dependencies
(1 failure)
warning: no umbrella header found for target 'ELFoundation_osx', module map will not be generated
warning: no umbrella header found for target 'ELFoundation_osx', module map will not be generated
A shell task (/usr/bin/xcrun xcodebuild -project /Users/vn00ujn/dev/ELJSBridge/Carthage/Checkouts/ELFoundation/ELFoundation.xcodeproj -scheme ELFoundation_osx -configuration Release ONLY_ACTIVE_ARCH=NO CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES clean build) failed with exit code 65:
** CLEAN FAILED **

The following build commands failed:
        Check dependencies
(1 failure)
** BUILD FAILED **

The following build commands failed:
        Check dependencies
(1 failure)

There were a small number of changes required.

Legacy Swift version was not specified. (As we probably will not go back to swift 2.3, I've set this at the project level to NO to track the latest swift version.  (this should fix the above problem)
Added The macOS Test target, to the macOS build target.

And the Tests for macOS Should be configured to run under the macOS Scheme.

And finally there were files that were not found in the compile step for the macOS Tests target. I re-added them.

Looks like some of my changes are the same as in #17 Let me know if I need to re-integrate or rebase my changes here. (also not sure why #17 is trying to use swift 2.3. I'm thinking some of the changes there are a bit old.)

Looks like the object association test is failing.
Test Suite 'All tests' failed at 2016-12-09 00:02:51.223.
	 Executed 17 tests, with 1 failure (0 unexpected) in 0.202 (0.319) seconds
Failing tests:
	-[ELFoundationTests testObjectAssociation()]

I saw this fail a few times in my own testing I can't seems to reliably reproduce it. (I initially thought that the cast on the object retrieval line should be as String instead of as String! but that does not seem to reliable fix it either. I've also seen this test fail under the mac_os_x Test suite too. So it should not be anything platform dependent. I'd look into this more but... ObjC runtime hackery is not really my specialty.
Let me know if I can help any more.

Looks like #17 had branched off of the v1.1.x branch which has diverged from master to maintain a version compatible with Swift 2.3 . No need for you to rebase or re-integrate since since I updated #17 to base off of v1.1.x and merged it.
The testObjectAssociation test has been failing for awhile. I believe it started after migrating to Xcode 8/iOS 10. I can't reproduce it consistently and I believe the test passes when run on my local machine but seems to fail on Travis CI.
I'll go ahead and merge since this test has already been failing and none of your changes are related to it. I also opened issue #19 to track the broken test so we can address it later.


Exception when running with load_keys

Hello,
I'm very interested in your approach and am digging into the implementation details. However, when I try to run the executable I get an exception.
libc++abi: terminating due to uncaught exception of type lbcrypto::OpenFHEException: /Users/dangerginger/code/openfhe-development/src/core/include/lattice/hal/default/dcrtpoly-impl.h:l.698:DropLastElement(): DropLastElement: Removing last element of DCRTPoly renders it invalid.

I have followed the instructions on the README with the commands:
./LowMemoryFHEResNet20 generate_keys 1
./LowMemoryFHEResNet20 load_keys 1

I've gotten the same results on macOS and Ubuntu linux. In both cases I was using the openfhe-development repo. I will try running this in the debugger, but any insight into why this might be happening? This error seems to indicate the multiplicative depth has been exceeded, but I'm not sure about that.
Thanks and I appreciate any hints.

Hello, thank you for the question!
Could you please try to:

Use OpenFHE v1.0.4
OR
Set parameters.SetSecurityLevel(SecurityLevel::HEStd_NotSet); and change line 123 of FHEController.cpp to uint32_t levelsUsedBeforeBootstrap = get_relu_depth(relu_deg) + 4;

Notice that the latter does not ensure $\lambda = 128$ security bits

Hello, you can refer to https://github.com/narger-ef/LowMemoryFHEResNet20/issues/9 for more details.

I am closing the issue, feel free to open if you still have issues


New Ideas/Inspirations from Windows mobile UWP built into Windows 10

Perhaps this subreddit will explain what I am trying to convey.
https://www.reddit.com/r/Windows10/comments/69qbqj/trick_to_open_uwp_file_explorer_on_windows_10/

@bingeitall please explain more in detail what you want so others can get to work on it ☺

It is an idea to add those simple buttons for cut/copy and paste commands as well as a sort option.
The link provided tells you how to access the inbuilt UWP file explorer which is more or less Windows mobile file explorer but it could prove to provide some design ideas.

Ok, thanks for the information.

Work on exposing these commands is on the roadmap. I'll keep you posted.


Feature req: Add back "live" option for theme_id

Is your feature request related to a problem? Please describe.
I've got a client who knows some basic HTML and sometimes he makes some changes through Shopify admin ("Edit code"). He always duplicates the theme before doing so in order to be able to quickly publish the backup/duplicate theme if he messes things up.
Now this process of publishing backup/duplicate theme obviously changes the theme_id of live theme.
I really liked the feature of being able to write theme_id: 'live' (actually I would just comment out this line in config and it would use live theme when no theme_id was selected.
Today I noticed these changes and I'm hesitant to upgrade my themekit version:
https://github.com/Shopify/themekit/commit/9079a7a651e46d2a435ef68ac0ba7f18ce7eb92f#diff-2db8f261e1d717489d4af55327c6e926R54-R57
I'm stuck on ThemeKit 1.0.3 darwin/amd64 right now.
How can I have theme kit interact with live theme without me having to know the live theme theme_id?
Thanks!

We wanted to move away from anything that makes it easier to interact with the live theme because a lot of people found them dangerous. You could use theme get --list to list the themes and both the theme IDs are in there as well as the live theme is indicated in that list as well.
This is an example output from my own store.
➜  can-i-buy-a-feeling.myshopify.com theme get --list
Available theme versions:
  [80819355670][live] mynewtheme
  [81037754390] mynewtheme
  [105994886] Brooklyn

Wouldn't you agree that that's, at least for my use-case, worse experience than what I have right now?
This is a dealbreaker for me actually and I'll have to postpone upgrading the themekit for as long as possible.
I think keeping "live" wouldn't make it "dangerous". I mean, if it did, perhaps it's dangerous for that developer to have any access to the theme. It literally says it's live theme.
I like the simplicity and putting some guards in place, but in this case, I see this more of a move in "this is for your own good" direction than a truly enhancing DX feature.

I understand how important this is to you but there are several things that are a bit to easy to do that could take out a shop and cause long periods of downtime. For some merchants this has been disastrous. There are other issues like the ability to overwrite the settings so easily. This all still points back to the live theme because overwriting the settings by accident can cause extreme downtime as well but just annoyance on a development theme.
Ultimately DX includes both what you are enabling developers to do as well as what problems you are helping developers avoid. If you end up causing an outage after explicitly querying and using the theme ID and the --allow-live flag, then this can no longer be the fault of the tool.

Man, making any theme changes by uploading and overwriting a file by file
is...do I even have to comment on why this is bad in so many ways in 2020?
Fixing the problem at its core would be much better way forward.
I think the state of theme development tools is a total disaster. First you
deprecate slate, now you're cutting down on features. Well, thanks for
providing an alternative configuration option I can use to go around...
Feel free to close this issue. It's clear that we don't agree. Have a good
day.
On Tue, Sep 1, 2020, 22:06 Tim Anema<EMAIL_ADDRESS>wrote:

I understand how important this is to you but there are several things
that are a bit to easy to do that could take out a shop and cause long
periods of downtime. For some merchants this has been disastrous. There are
other issues like the ability to overwrite the settings so easily. This all
still points back to the live theme because overwriting the settings by
accident can cause extreme downtime as well but just annoyance on a
development theme.
Ultimately DX includes both what you are enabling developers to do as well
as what problems you are helping developers avoid. If you end up causing an
outage after explicitly querying and using the theme ID and the
--allow-live flag, then this can no longer be the fault of the tool.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Shopify/themekit/issues/769#issuecomment-685102491,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAQO3IMPMWCI2CFCJ3PGH3SDVH27ANCNFSM4QRNLXHQ
.


fuse: Report fuse.Attr.Blocks correctly

What does this PR change? What problem does it solve?
Fixes #4239.
Checklist

[x] I have read the contribution guidelines.
[x] I have enabled maintainer edits.
[x] I have added tests for all code changes.
[ ] I have added documentation for relevant changes (in the manual).
[x] There's a new file in changelog/unreleased/ that describes the changes for our users (see template).
[x] I have run gofmt on the code in all commits.
[x] All commit messages are formatted in the same style as the other commits in the repo.
[x] I'm done! This pull request is ready for review.

Test failure is lock refreshing on Windows, so unrelated.


Replacement for Gorilla/MUX package

🚀 Feature Request
The maintainer of the gorilla/mux package is retiring and looking for a new maintainer. Thus EdgeX should look into replacing or decoupling from the package or taking on some maintenance if appropriate.
Relevant Package [REQUIRED]

 This feature request is for...
Affected package = gorilla/mux
ALL of the EdgeX microservices have a dependency on it
Description [REQUIRED]
Please see here: https://github.com/gorilla/mux/issues/659
Describe the solution you'd like
I'm not sure if this has been discussed in the project Slack channel as I can't access it anymore. But I didn't see an issue or PR about it and I wanted to be sure the project was aware.
Describe alternatives you've considered
 Have you considered any alternative solutions or workarounds?
No. This is in the interest of raising a flag. If you're already aware and planning an approach, feel free to close.

thanks, @tsconn23 , we didn't notice that. I will bring this topic to the working group meeting.

Possible replacements, taken from https://github.com/MadAppGang/httplog

alice
chi
echo
gin
goji
gorilla mux
httprouter
mojito
negroni
native net/http

Good morning. I have had a chance to test most of those HTTP routes.
First of I down recommend using a native HTTP router in production. I was excellent at the start of Golang life. But right now we have better alternatives.
I the context of this project I definitely recommend to use Echo. It has a good balance of performance and usability. Good customization and flexibility.
Gin is more popular, has a bigger community, and has a big list of middleware.  But unfortunately, it has architecture and error-handling problems. The last argument is the source of many problems.
So, Echo is best in this case.

I just noticed that the Gorilla project has become active again since last month; see https://github.com/gorilla/mux/commit/7456b4e9ae7b67e27ffaa2e497941e77d39bc884
There are no new releases yet, but looks like they have found a new maintainer.

@jumpingliu please add this to the Core WG agenda, and we will discuss whether we should revert the recent changes.

@cloudxxx8 ok, added


Right aligning numbers

Aligns numbers to the right. Solves #323
I haven't rebased as I have no idea how to do that. This is my first PR

Motivation
Changes

[ ] Ensured that you have rebased your branch with this repo's latest master branch.
[x] Ensured that relevant issues are linked, if this PR resolves any outstanding.
[x] Added a screenshot for all UI changes (you can drag the file into this edit box and it will be uploaded).
[x] Ensured that changes to auto-generated files have not been committed; in particular, *.html, *.csv, *.xml and *.json files.

I have no idea what I've just done.
Sorry - I'm relatively new to Github and tried to rebase

We decided to revert this change. Thanks for trying to fix it!

I think the original commit here is still good.  Right-aligning numerical columns is usually a pretty standard practice.  Just want to make sure that the git rebase issues aren't fogging the good work done here.
https://github.com/alex/nyt-2020-election-scraper/pull/326/commits/0db4e3ea28195246ac7aa2da330d4b38bfae6cd4

I cleaned this up and merged in #363.


Add release script for Contributions Building Block.

Description
This PR adds a release script for Contributions Building Block.
Fixes #675
Review Time Estimate
Please give your idea of how soon this pull request needs to be reviewed by selecting one of the options below. This can be based on the criticality of the issue at hand and/or other relevant factors.

[x] Immediately
[ ] Within a week
[ ] When possible

Type of changes
Please select a relevant option:

[ ] Bug fix (non-breaking change which fixes an issue).
[ ] New feature (non-breaking change which adds functionality).
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected).
[x] Other (any another change that does not fall in one of the above categories.)

Checklist:
Please select all applicable options:

[ ] I have signed the Rokwire Contributor License Agreement (CLA). (Any contributor who is not an employee of the University of Illinois whose official duties include contributing to the Rokwire software, or who is not paid by the Rokwire project, needs to sign the CLA before their contribution can be accepted.)
[x] I have updated the CHANGELOG.
[x] I have read the Contributor Guidelines.
[x] I have performed a self-review of my own code.
[ ] I have commented my code, particularly in hard-to-understand areas.
[ ] My change requires updating the documentation.
[ ] I have made necessary changes to the documentation.
[ ] I have added tests related to my changes.
[ ] My changes generate no new warnings.
[ ] New and existing unit tests pass locally with my changes.
[ ] Any dependent changes have been merged and published in downstream modules.

@ywkim312, are all of these needed? Could you please double-check?

Yes I believe so. Some of them are needed in contribution, some of them are for Catalog

@ywkim312, are all of these needed? Could you please double-check?

Yes I believe so. Some of them are needed in contribution, some of them are for Catalog

Okay. Just to clarify, this Dockerfile is only for the Contributions BB. I think we are not using GitHub Client ID and password. Anyway, we can update this later as it looks like event config.py will need updating.

Hi @ywkim312, if this PR is ready to be merged, please go ahead. Thanks.


Various Issues upon mass Transporting Identified

Spent a few hours doing this manually as intended. From Gen 1 -> Gen 3 -> Gen 4
This was done from English Yellow to English Leaf Green Transferred then to English Heart Gold.
The Leaf Green Save did have other Mystery Gift events active prior to transportation.
I've attached all the save files below.
GB Transported Saves.zip
Note: Some Pokemon have HMs requiring you to delete them via Move Deleter. I forgot to do this in the Leaf Green Save File so you may need to delete them if you plan on replicating this transport from Gen 3 -> Gen 4
Issues Observed:

Pokemon May Transfer with a Blank Nickname (e.g. Bulbasaur)
Pokemon May be unable to be transported from Gen 1 to Gen 3 at the initial attempt
Pokemon May Transfer with with extra characters in Nickname (e.g. Butterfree)
Pokemon May Transfer with empty Original Trainer Name (e.g. Pidgeot)
Pokemon May Transfer with an extra Space in front of the Original Trainer Name (e.g Pidgey)
Pokemon May Transfer with an extra Character in front of the Original Trainer Name (e.g Charmeleon)
Pokemon May have Invalid Encounter Type after Transferred to Gen 4 (e.g. Rhydon)
Pokemon May have PID + Correlation not match for the Encounter Type after Transfer to Gen 4
Safari Zone Encounter Pokemon does not have correct Pokeball Type (e.g. Kangaskhan, Exeggcute)

Issues 1-6 appeared appears prominently in the first batch of Pokemon I attempted to send. Afterwards, its occurrence was much less. This issued seemed to occur at the final 20 Pokemon, but after cancelling the transfer and trying again the issue disappeared. This didn't seem to be the case for the first 20 Pokemon transferred.
The Pokemon left behind due to being unable to transfer at the first attempt are still in the post-transferred Yellow Save File.
Issue 4 occurs in NPC traded Pokemon like Jynx and Farfetch'd where the rest of the Pokemon in the Box didn't have this issue.
Issue 9 does not have all Pokemon from Safari Zone labeled as Safari encounters, some of them may be have egg like Dratini so they avoid this issue.
Some Pokemon are completely legal, some have very apparent legality issues, and other have nuanced legality issues (incorrect Encounter Type)
My suggestion is to have all breedable Pokemon have Egg Encounter type to solve the Encounter Type (assuming you follow the proper egg generation) to normalize the Encounter Types, potentially making Issues 8-9 easier to solve. This would also solve the Safari Ball issue since all Pokemon bred in Gen 3 have Pokeball by default.

Hi there!! Sorry for the late response, but I believe most the issues you encountered were caused by a bug I just found the fix to! I pushed a release yet, but the details can be found at the end of this issue thread:
https://github.com/GearsProgress/Poke_Transporter_GB/issues/9
Thank you for providing your save files as well! As such, I was able to confirm my theory by finding that your Pidgeot has a Special EV of 2302, which becomes 0x08FE in hex (with 0xFE being the problem byte). Obviously not your fault, but it backs up the theory that your issues should be solved with the upcoming bug fix!
As far as the Safari Ball part goes- I am definitely planning on changing that in the near future as well. My goal is to get the translation work done first, but it will be changed sometime soon as well!!


Jobs getting stuck in processing

Describe the issue
If an exception is thrown in the dequeue function, the jobs are stuck in processing, and they never complete.
Vapor version
4.106.0
Operating system and version
macOS 14.7
Swift version
SPM - Swift 6.0.0
Steps to reproduce

Create a job and throw an exception in the dequeue handler.

Outcome
Jobs are getting stuck in processing in the DB.
Additional notes
No response

Thanks for refiling this! I'll see what I can come up with for a fix as soon as I can, probably this coming weekend.


Extract audio from audio.onet.pl

Checklist

[X] I'm reporting a site feature request
[X] I've verified that I'm running yt-dlp version 2022.05.18 (update instructions) or later (specify commit)
[X] I've checked that all provided URLs are playable in a browser with the same IP and same login details
[X] I've searched the bugtracker for similar issues including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue
[X] I've read about sharing account credentials and I'm willing to share it if required

Region
No response
Example URLs
onet.pl video extraction works.
audio.onet.pl extraction fails (debug log below).
Description
Currently onet.pl extracto only extracts video. It fails for audio (podcast) extraction.
Verbose log
[debug] Command-line config: ['-vU', 'https://audio.onet.pl/show/autoswiatwstereo/samochd-kontra-rower-czy-mona-to-jako-pogodzi']
[debug] Encodings: locale UTF-8, fs utf-8, pref UTF-8, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version 2022.05.18 [b14d52355]
[debug] Python version 3.10.4 (CPython 64bit) - macOS-12.3.1-x86_64-i386-64bit
[debug] Checking exe version: ffprobe -bsfs
[debug] Checking exe version: ffmpeg -bsfs
[debug] exe versions: ffmpeg 5.0.1 (setts), ffprobe 5.0.1, rtmpdump 2.4
[debug] Optional libraries: Cryptodome-3.14.1, brotli-1.0.9, certifi-2021.10.08, mutagen-1.45.1, sqlite3-2.6.0, websockets-10.3
[debug] Proxy map: {}
Latest version: 2022.05.18, Current version: 2022.05.18
yt-dlp is up to date (2022.05.18)
[debug] [onet.pl] Extracting URL: https://audio.onet.pl/show/autoswiatwstereo/samochd-kontra-rower-czy-mona-to-jako-pogodzi
[onet.pl] samochd: Downloading webpage
ERROR: [onet.pl] samochd: Unable to extract pulsembed url; please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U
  File "/usr/local/Cellar/yt-dlp/2022.5.18/libexec/lib/python3.10/site-packages/yt_dlp/extractor/common.py", line 642, in extract
    ie_result = self._real_extract(url)
  File "/usr/local/Cellar/yt-dlp/2022.5.18/libexec/lib/python3.10/site-packages/yt_dlp/extractor/onet.py", line 252, in _real_extract
    pulsembed_url = self._search_regex(
  File "/usr/local/Cellar/yt-dlp/2022.5.18/libexec/lib/python3.10/site-packages/yt_dlp/extractor/common.py", line 1226, in _search_regex
    raise RegexNotFoundError('Unable to extract %s' % _name)

Checklist

[x]  I'm reporting a site feature request
[x]  I've verified that I'm running yt-dlp version 2022.05.18 (update instructions) or later (specify commit)
[x]  I've checked that all provided URLs are playable in a browser with the same IP and same login details
[x]  I've searched the bugtracker for similar issues including closed ones. DO NOT post duplicates
[x]  I've read the guidelines for opening an issue
[x]  I've read about sharing account credentials and I'm willing to share it if required

Region
No response
Example URLs
onet.pl video extraction works.
audio.onet.pl extraction fails (debug log below).
Description
Currently onet.pl extracto only extracts video. It fails for audio (podcast) extraction.
Verbose log
[debug] Command-line config: ['-vU', 'https://audio.onet.pl/show/autoswiatwstereo/samochd-kontra-rower-czy-mona-to-jako-pogodzi']
[debug] Encodings: locale UTF-8, fs utf-8, pref UTF-8, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version 2022.05.18 [b14d52355]
[debug] Python version 3.10.4 (CPython 64bit) - macOS-12.3.1-x86_64-i386-64bit
[debug] Checking exe version: ffprobe -bsfs
[debug] Checking exe version: ffmpeg -bsfs
[debug] exe versions: ffmpeg 5.0.1 (setts), ffprobe 5.0.1, rtmpdump 2.4
[debug] Optional libraries: Cryptodome-3.14.1, brotli-1.0.9, certifi-2021.10.08, mutagen-1.45.1, sqlite3-2.6.0, websockets-10.3
[debug] Proxy map: {}
Latest version: 2022.05.18, Current version: 2022.05.18
yt-dlp is up to date (2022.05.18)
[debug] [onet.pl] Extracting URL: https://audio.onet.pl/show/autoswiatwstereo/samochd-kontra-rower-czy-mona-to-jako-pogodzi
[onet.pl] samochd: Downloading webpage
ERROR: [onet.pl] samochd: Unable to extract pulsembed url; please report this issue on  https://github.com/yt-dlp/yt-dlp/issues?q= , filling out the appropriate issue template. Confirm you are on the latest version using  yt-dlp -U
  File "/usr/local/Cellar/yt-dlp/2022.5.18/libexec/lib/python3.10/site-packages/yt_dlp/extractor/common.py", line 642, in extract
    ie_result = self._real_extract(url)
  File "/usr/local/Cellar/yt-dlp/2022.5.18/libexec/lib/python3.10/site-packages/yt_dlp/extractor/onet.py", line 252, in _real_extract
    pulsembed_url = self._search_regex(
  File "/usr/local/Cellar/yt-dlp/2022.5.18/libexec/lib/python3.10/site-packages/yt_dlp/extractor/common.py", line 1226, in _search_regex
    raise RegexNotFoundError('Unable to extract %s' % _name)

try again with yt-dlp --force-generic-extractor "https://audio.onet.pl/show/autoswiatwstereo/samochd-kontra-rower-czy-mona-to-jako-pogodzi"


Half Of The Scripts Does Not Work Due To Renaming [Decaying Winter]

Some of the scripts such as "KillAll" and "GetRemoteKey" in Decaying Winter does not work due to links in them being renamed/reorganized.
What should happen: Scripts should work.
OS: Windows
Game: Decaying Winter
Exploit: Krnl (Both Beta and Normal version)

Some of the scripts such as "KillAll" and "GetRemoteKey" in Decaying Winter does not work due to links in them being renamed/reorganized.
What should happen: Scripts should work.
OS: Windows
Game: Decaying Winter
Exploit: Krnl (Both Beta and Normal version)

Unfortunately, the majority of scripts in this repository are not maintained. I recommend to fork and make the appropriate changes and then you can make a pull request if you wish


Code health: update every call of initializing TermControl with settings

In #8602, we started passing a child of the TerminalSettings to the control upon tab initialization, we need to make sure that we are doing this for every call of initializing a new TermControl (we initially forgot to do this for controls initialized during pane split, which led to #9276).

I'd rather us use this bug for making it so we don't have so many places. Like, "Unify TerminalControl creation in TerminalApp to reduce duplication and regression risk"


Resolve Doctrine Target Entities to known Classes only

Hi there!
This is a follow up on my work at https://github.com/rectorphp/rector-src/pull/2319 . It changes DoctrineTargetEntityStringToClassConstantRector to resolve known classes only.

Hi @dritter , thanks :+1:


Misspelling of Volume?

Should Volumne here be Volume?

Yes, feel free to push a PR with a fix.
On Mon, Aug 8, 2016 at 11:29 AM, Chet Nieter<EMAIL_ADDRESS>wrote:

Should Volumne here
https://github.com/Kitware/HPCCloud/blob/master/src/panels/run/RunEC2.js#L197-L199
be Volume?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Kitware/HPCCloud/issues/481, or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-7jXgvidFceGWFvdWjH6xxZaWT6cmRks5qd0tLgaJpZM4JfKcI
.

Assuming tests pass should I go ahead merge the PR.

Let @TristanWright take a look first.
On Mon, Aug 8, 2016 at 11:36 AM, Chet Nieter<EMAIL_ADDRESS>wrote:

Assuming tests pass should I go ahead merge the PR.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Kitware/HPCCloud/issues/481#issuecomment-238276020,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA-7jXnNKjFL68NQ38Z3mX7C1vSevj_3ks5qd0zkgaJpZM4JfKcI
.

Fixed by #482


Adjust typings and socket-specs to time additions to getHost messages

see https://github.com/ioBroker/ioBroker.js-controller/pull/1610#issuecomment-1002081910

Any news here?


[RESOLVED] Interface eth0(): High error rate (>2 for 5m)

Problem started at 15:45:29 on 2023.08.11
Problem name: Interface eth0(): High error rate (>2 for 5m)
Host: S100-Primario
Severity: Warning
Operational data: errors in: 1, errors out: 0
Original problem ID: 35292
Event details in Zabbix: http://<IP_ADDRESS>/tr_events.php?triggerid=23483&eventid=35292

Problem has been resolved in 3m 0s at 15:48:29 on 2023.08.11
Problem name: Interface eth0(): High error rate (>2 for 5m)
Host: S100-Primario
Severity: Warning
Original problem ID: 35292


Adding ubi8/nodejs-12 image as supported

Adding ubi8/nodejs-12 image as supported because there is latest image difference between 4.5 and 4.6 cluster. More details are in issue https://github.com/openshift/odo/issues/4016 . There is also one pr on odo https://github.com/openshift/odo/pull/4070.

ping @kadel

ping @kadel

test are failing. can you check why?

@prietyc123 Can you please include https://github.com/openshift/odo-init-image/pull/64 changes so that we can verify and push it in a single go. thanks

@amitkrout

@prietyc123 Can you please include #64 changes so that we can verify and push it in a single go. thanks

Why not continue in the original PR? This PR is addressing different issue.

The test won't pass until https://github.com/openshift/odo/pull/4070 gets merged, https://github.com/openshift/odo/pull/4070 won't pass until this one is merged and a new init image is released.
The next steps:

merging this PR, as it is a tiny one line change, that should be safe
releasing init image (cc: @mohammedzee1000)
updating https://github.com/openshift/odo/pull/4070 to use newly released image
once tests on https://github.com/openshift/odo/pull/4070 are green, merge it

/approve
/lgtm
/title Adding ubi8/nodejs-12 image as supported


Remove Google.AndroidStudio 2<IP_ADDRESS>

Conflicts with 2<IP_ADDRESS>. There can only be one manifest per DisplayVersion 2023.1.
cf. https://github.com/microsoft/winget-pkgs/issues/108921

[ ] Have you signed the Contributor License Agreement?
[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] This PR only modifies one (1) manifest
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.6 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

@treysis - Sorry I wasn't keeping track.  That'll probably be faster I believe


Added function for setting terminal title to tscreen

May need testing, but should be safe to merge as is.

As long as all terminals have the same control sequences to set the title, this should be fine. I'm not sure how good for setting the title back after setting it. I was looking here for a possible solution but it seems like it doesn't work for most terminals so this solution is fine.
SetTitle should be a method of tScreen (which you have done which is good), but it should also be a method of the screen interface so that it can actually be called as screen.SetTitle(...). This also means that the windows screen needs to satisfy the interface so it also needs a SetTitle method (you can just make it an empty stub though unless you know how to change the title on windows as well).


Related Papers

Is the code implemented following which paper or not?
Could u provide me with some related academic sources which guide the code writing?

same questions here, I see good performance on these networks, can you help to name some architectures that you're using in your network, for example, which net you use in cifar10? is there any papers related to it. Thanks!


azure-cli-2.0.66-1.el7.x86_64.rpm has an unknown GPG key

az feedback auto-generates most of the information requested below, as of CLI version 2.0.66

Describe the bug
The package azure-cli-2.0.66-1.el7.x86_64.rpm is signed with a different GPG key than the one provided at https://packages.microsoft.com/keys/microsoft.asc
To Reproduce
Using any RPM-based Linux OS (here, Fedora 29):
sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc
sudo sh -c 'echo -e "[azure-cli]\nname=Azure CLI\nbaseurl=https://packages.microsoft.com/yumrepos/azure-cli\nenabled=1\ngpgcheck=1\ngpgkey=https://packages.microsoft.com/keys/microsoft.asc" > /etc/yum.repos.d/azure-cli.repo'
sudo yum install azure-cli
Expected behavior
RPM is upgraded or installed with the current version
Environment summary
Fedora 29, fully updated
Additional context
Actual received output:
warning: /var/cache/dnf/azure-cli-da5926ebd44c506b/packages/azure-cli-2.0.66-1.el7.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 513b22cc: NOKEY
Azure CLI                                       1.5 kB/s | 983  B     00:00
Importing GPG key 0xBE1229CF:
Userid     : "Microsoft (Release signing<EMAIL_ADDRESS>Fingerprint: BC52 8686 B50D 79E3 39D3 721C EB3E 94AD BE12 29CF
From       : https://packages.microsoft.com/keys/microsoft.asc
Is this ok [y/N]: y
Key imported successfully
Import of key(s) didn't help, wrong key(s)?
Public key for azure-cli-2.0.66-1.el7.x86_64.rpm is not installed. Failing package is: azure-cli-2.0.66-1.el7.x86_64
GPG Keys are configured as: https://packages.microsoft.com/keys/microsoft.asc
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: GPG check FAILED

This is at least 3rd time it happens, this process needs to be improved as it blocks other system updates.

We had updated our release pipeline to specifically check for this and block if things were unsigned. I believe we tried a new process this time where the signing was supposed to have occurred automatically in the pipeline. Not sure if the verification steps were altered. cc/ @marstr @yugangw-msft.

Until this is fixed to the root, folks that are affected can work around it by setting gpgcheck=0

@S3v3nL34fKl0v3r careful there, that can open the door to a big security hole, as we are talking a very sensible package :)

It's true! My docker images currently aren't used in production, but I still need az to work... So i'm just going to hang out on this ticket until i can change it back. ;)

Howdy folks,
Sorry for the inconvenience. As a team, we've been focused on automating our release pipeline. This was the first release where we had introduced an automated job to sign the RPM package. Despite our best efforts to make sure everything was working, clearly something didn't go quite right and we're still getting to the bottom of it. Once we understand the root cause, we'll update this issue with an understanding.
In the short-term we're falling back to the old release process for RPM, and will have signed bits out before end of business today. In the meantime, to avoid security concerns regarding using unsigned bits, please use your package manager to downgrade to 2.0.65. If it is helpful, here is some Red Hat guidance on this practice: https://access.redhat.com/solutions/29617

UPDATE:
I have a copy of the 2.0.66 RPM in hand, which I have confirmed is signed with the following key: be1229cf. Furthermore, I have submitted it to the official Microsoft repository at https://packages.microsoft.com. Once their ingestion process is complete, the signed bits will be what is available to your package manager.
RCA:
This looks to have been a pretty simple problem: In our release pipeline, we signed with the incorrect key, a testing key, which didn't get updated when we moved to the production copy of the pipeline. The script that we use checks to make sure that there is a signature, but not that it's the production key. In order to ensure that this doesn't happen again, we'll be updating our release pipeline to check that that the correct key was used.

UPDATE 2:
Replacing the existing RPM with a signed one is causing dnf and yum to complain about mismatching checksums. Even running the suggested metadata cleans will not solve the problem. An attempt to fix this by renaming the RPM to azure-cli-2.0.66-2.el7.x86_64.rpm and resubmitting did not solve the problem
To fix this, I'm building a new RPM with the release tag 3.el7 from the azure-cli.spec file iteself, and will get that copy signed and uploaded.

Just to reiterate the work around, I've confirmed that the following commands are working:
Enterprise Linux 7:
yum install azure-cli-2.0.65

Fedora:
dnf install azure-cli-2.0.65

UPDATE 3:
azure-cli-2.0.66-3.el7.x86_64.rpm was succesffuly built and extracted from a container on my Fedora 29 machine. The build was taken from commit d536d7d69c41815d4fe8449d79de55d039167014. It has been submitted to be signed.

UPDATE 4:
Incident resolved. I'm now able to successfully run sudo dnf upgrade azure-cli from my machine which previously had 2.0.65 installed, and in container environments running Centos 7 and Fedora 30, I'm able to run dnf install azure-cli, and have it pulled down and install the correct signed RPM.

@marstr THANKS!!!!


Test parent directory of .netrc file is writable before using it

https://ci.swift.org/job/swift-PR-source-compat-suite-debug/4058/
$ sandbox-exec -f /Users/buildnode/jenkins/workspace-private/swift-source-compat-suite-sandbox/sandbox_package.sb /Users/buildnode/jenkins/workspace-private/swift-PR-source-compat-suite-debug/build/compat_macos/install/toolchain/usr/bin/swift package --disable-sandbox -C /Users/buildnode/jenkins/workspace/swift-PR-source-compat-suite-debug/swift-source-compat-suite/project_cache/GRDB.swift clean
warning: '--chdir/-C' option is deprecated; use '--package-path' instead
warning: Failed to load .netrc file at /Users/buildnode/.netrc. Error: unreadableFile(<AbsolutePath:"/Users/buildnode/.netrc">)
error: other(1)

Not sure if the other(1) error is .netrc related. Trying to see if
this code change will fix it.

@swift-ci please smoke test

@swift-ci please smoke test

Added https://github.com/apple/swift-package-manager/pull/4075/commits/4f03f1b433feb7dc7781ddbaad377df66379e852, which I think is the real fix, so please review again.


docs: add missing import

Overview
add missing import in https://qwik.dev/docs/deployments/static/

What is it?

[ ] Feature / enhancement
[ ] Bug
[x] Docs / tests / types / typos

Description
add missing import in https://qwik.dev/docs/deployments/static/
Use cases and why

N/A
Checklist:

[x] My code follows the developer guidelines of this project
[x] I have performed a self-review of my own code
[x] I have made corresponding changes to the documentation
[x] Added new tests to cover the fix / functionality (no test needed)

I think it's better to split this part into a new "Manual Installation" section, something like this. wdyt? I can help updating all the deployment docs.
https://github.com/QwikDev/qwik/blob/c1ad095143d7522da4b89eec299ee8140f9152fb/packages/docs/src/routes/docs/deployments/static/index.mdx?plain=1#L21-L28
If it's not recommended to do manual installation, then it's better to remove the code from the docs, something like https://qwik.dev/docs/deployments/firebase/

@krisantuswanandi can you make another PR to split it up


matIndex not available in Closest Hit Shader

The matIndex buffer does not seem to be available in the .rchit shader.
Following the tutorial at section 12: https://nvpro-samples.github.io/vk_raytracing_tutorial/#simplematerials

Noticed one just has to add the following to the raytrace.rchit shader file:
layout (binding = 4, set = 1, scalar) buffer MatIndex { int i[]; } matIndex[];
Of course it makes sense but maybe add it to the tutorial as the set = 1 was important for me,
(cannot just copy paste from the rasterizers fragment shader) otherwise the program would crash as it cannot bind the descriptor set to the shader (in my case).
Also, not that severe but the naming should be consistent across the rasterizer fragment shader and the raytracing hit-shader: In the rasterizer version the array is defined as matIdx but in the closest-hit-shader it is matIndex, because at section 12 of the tutorial we access the array using:
int               matIdx = matIndex[objId].i[gl_PrimitiveID];

Thank you, Michael, this will be fixed in the next release.
Note that there is a new version of the tutorial, based on the 'soon to be officially released' VK_KHR_ray_tracing.
https://nvpro-samples.github.io/vk_raytracing_tutorial_KHR/


SPSearch Queries Returning Empty Result Lists ("General Transient Error")

Starting 2-3 days ago, search queries via cocoalibspotify started returning empty sets of track, album, artist, and playlist results for valid searches.  When debugging, I can see an error flag called "General Transient Error" in the SPSearch object.  When searches do return valid results (only 25-30% of the time during bad streaks), the error property is nil.
Luckily, these errors do not cause my app to crash.  However, I am receiving complaints from my many users about the issue, and it annoys me particularly because the cocoalibspotify's functionality is supposed to be maintained "for a reasonable amount of time after [the new] SDK exits beta status."
Attached is a screenshot showing the detail of the loaded SPSearch object which has failed to provide the track, album, artist, or playlist information that was promised by the count variables.  Thanks in advance to anyone who can help!

For the record, this version of my application has been working pretty much bug-free for several months, so I don't think the problem is on my end.  It must be server-side.

For clarification:  Issue is not continuous, but is still happening intermittently as my users continue to report it and I catch it occurring myself occasionally.  First known occurrence was Feb 2, and last reported occurrence was earlier today (Feb 9), so the issue has been persistent, if intermittent.
Again, no problem like this has been observed or reported during the previous two years of my app's existence.

@iKenndac , is there any light you can shed on this situation?  Searches are still failing fairly frequently (but inconsistently) with the "General Transient Error."
I know that Spotify has shifted completely away from cocoalibspotify, but there are still legitimate existing applications (and users) that depend on their functionality.  Any additional information or help leading to a resolution would be greatly appreciated.
Thanks!

It appears that after 2½ weeks, this issue has resolved, and searches are working once again.


Rendering problems on Chrome - overlapping characters and not readable letters in default view

PDF file: 0939bfa0-731d-48ca-8c0b-ea110cdcf143.pdf
Configuration:

Web browser and its version:
Works fine on: Firefox - 97.0.2 (64 bity)
Problem noticed on: Chrome 99.0.4844.51 (and lower)
Operating system: Windows
PDF.js version: latest (currently v2.13.216)

Steps to reproduce the problem:

Try to open attached PDF in Chrome (and in Firefox)
Check the "footer" - telephone, bankgiro and other words are not fully visible on Chrome

What is the expected behavior? (add screenshot)

What went wrong? (add screenshot)

Problem was not spotted in version 2.7.570
One extra finding done recently - problem occurs on some subset of PDF's and they are coming from one "provider" - ABBY FineReader Engine 12

One of my clients has the same issue on Windows 11 Pro. Issue happens in Chrome as well as in electron (chromium). Seems specific to that computer. Reproduceable there, but not on other computers.

We use an older version of pdf.js to render pdf resume's and we are seeing the same issue on Chromium browsers intermittently. What information would be useful to narrow down this issue?

Some of our customers are using current DELL XPS 13 notebooks with Iris Graphics. They encounter the same issue with Chromium-based browsers. If you disable the hardware acceleration in Chrome the issue is gone. With Intel UHD we do not encounter any issues. No issues with AMD and NVIDIA.

Same problem here. We couldn't find a way to reproduce it yet. But we verified it affects most of our users on the PDF.js version 2.10.377, and it doesn't affects users on version 2.8.335.

Some of our clients see the same thing. It seems to be an issue with the TextLayer. The text there is supposed to be transparent but somehow it is not. If you hide the text layer the problem is gone. We have not been able to reproduce the issue so it is hard for us to debug.

I have the same issue and refreshing the page/canvas changes the missing fragments. The workaround I have, is to disable "Accelerated 2D canvas" in Chrome. You can check Here

is there any acknowledgement of issue from the maintainers? We are having the same issue. Any idea when this might be fixed?

This document looks just fine in Firefox, which is the primary development target for the PDF.js library.
Hence it's not clear that it's necessarily an actionable bug here, and it may very well be a browser-bug (in Google Chrome).

@Snuffleupagus it is a bit strange as it is actually working on PDF.js 2.7.570 and stops working on same browser version but on PDF.js 2.13.216. In our case there are multiple versions of PDF.js between but maybe others observed from what version to what they upgraded when they observed the issue.

It is entirely possible that we started doing something that trips Chrome, especially given what @Rstyl3 mentioned regarding the problem disappearing when disabling hardware acceleration in Chrome.

This document looks just fine in Firefox, which is the primary development target for the PDF.js library. Hence it's not clear that it's necessarily an actionable bug here, and it may very well be a browser-bug (in Google Chrome).

By primary dev target, do you mean only dev target? The Chrome extension hasn't been updated in three years.

I'm having the same issue on Edge v106.0.1370.42 when having the setting Use hardware acceleration when available. enabled. Disabling that setting solves the issue, but then I have no hardware acceleration in Edge... 😕
I'm running on a Dell XPS15 9510.
Edge is using the Intel(R) UHD Graphics GPU when this happens.
If I force MS Edge to use my other GPU, NVIDIA GeForce RTX 3050 Ti, the PDF looks good. The downside of using this GPU is that Power Consumption increases...
But anyway, I got two workarounds with their own downsides:

Disable Hardware Acceleration in Edge
Force Edge to use another GPU (if available)

But I hope that the root cause of this this will be solved.

Hi, is there any update available to this pdf/browser bug?

As @Snuffleupagus said in https://github.com/mozilla/pdf.js/issues/14641#issuecomment-1154338428, our main focus is Firefox so there are almost no chance we spend some time on this issue.
But, you can either:

file a bug on Chrome bug tracker
or if you're sure it's a pdf.js issue or something we can easily workaround, then find someone to work on it and make a pull request.

Considering the comment https://github.com/mozilla/pdf.js/issues/14641#issuecomment-1144783843, it's very likely a Chrome issue.
FYI, I tested this pdf in Chrome and Safari on mac 13.0 and the rendering is ok. I tested on Windows 11, and the rendering is ok in Chrome on hdpi screen but it's far from perfect on a non-hdpi screen.
So really if the issue is because of a mix of Chrome, gpu and screen, as far as I can tell we won't fix this issue here.

Out of curiosity, did you open the pdf in Acrobat ??
Because if you did, you'd have seen the result is worst in Acrobat compared to Chrome.
The main reason is that there is only an image rendered in this pdf, and it has the property Interpolate set to false (see <IP_ADDRESS> Image Interpolation) .
And few months ago we fixed a bug about that:
https://github.com/mozilla/pdf.js/pull/13991
But in Firefox, image smoothing is enabled when the image is downscaled:
https://searchfox.org/mozilla-central/rev/3c194fa1d6f339036d2ec9516bd310c6ad612859/dom/canvas/CanvasRenderingContext2D.cpp#4933
Anyway, pdf.js is still a free product, some contributors work for it for free and on their spare time. So don't hesitate to help us in using git bisect or whatever tool in order to pinpoint a potential culprit and then we can discuss the opportunity to improve (or not) the way to render things.
And if you don't have the answers you want or you aren't happy with our answers, I'm sorry about that, but you can contribute to this project or pay some people to help, instead of just waiting and pinging us...

@calixteman - yes I opened it in Acrobat, and the view is better than in Chrome + PDF.js, I usually use FoxIt which is even better on preview.
I know I can contribute and this is not about it, I know that this is free product so I don't expect support more than help from other who know this product better, and what more - your answer was super great and finally brought some light to this topic.
Now I think if I understand it correctly - the Firefox overrides anyway the image rendered by PDF.js and adds/switches image smoothing. Conclusion is that I can now pass this information to PDF providers to switch the "interpolate" flag and than the problem should is gone.
Thank you much @calixteman for this, now you can even close it as "working as design".

In Acrobat, there is a pref to enable image smoothing which isn't enabled by default (I just discovered it today).

Firstly, thanks for all the detail in the responses on this thread, it's been very helpful!
I had a couple of questions in regards to:
#15659 Now I think if I understand it correctly - the Firefox overrides anyway the image rendered by PDF.js and adds/switches image smoothing. Conclusion is that I can now pass this information to PDF providers to switch the "interpolate" flag and than the problem should is gone.

Would image smoothing be in reference to imageSmoothingEnabled on the canvas context?
When you mention the interpolate flag, wouldn't this just be for image based PDFs? I was a bit confused as the PDF posted in the OP was pretty much all text

Any other information anyone has too would be much appreciated as this is an issue I'm struggling to replicate. Only seems to be users on Dell laptops (not all of them, and not always Iris Graphics). Randomly had one on a Lenovo report the same thing too

@joshpotterton-pagesuite from my recent experience - PDF which we use is text based, with "interpolate" flag changed the smoothing is visible as on any zoom in and zoom out the gaps in letters are filled better.
In general I think nowadays this flag in standard should be set to true :) I think most of computers are able to handle documents fast enough with smoothing - but this is not a scope here.

I bought a Dell XPS laptop with an Iris Graphics card to fix this, and I was finally able to reproduce the error consistently.
I think it has nothing to do with image interpolation.
The problem is in the canvas text rendering, and I reproduced it on all pdf.js 3 and 2 versions (3.0.279 - 2.0.943). It happens on all Chromium-based browsers with hardware acceleration enabled (it's the default).
The problem is on the ctx.fillText calls on canvas.js, and it happens on the first page render only. Re-rendering the page fixes the issue, and adding a delay on each ctx.fillText fixes it too, so it's probably some kind of race condition on the initialization.
I'm still working on a definitive solution, but a workaround is to add { willReadFrequently: true } on all getContext calls both in pdf.js and pdf.worker.js to disable hardware acceleration on the Canvas. I didn't notice any significant performance impact.

As we already said it: it's an issue in Chrome...
I don't really understand why you guys want us to fix it when, really, it isn't our fault.
So please, file a bug on Chrome bug tracker and add a link here in order to be able to follow it.
@albertbal, if you add a return at the first line of showText then you'll see that the pdf is still rendered: so really what you see on your screen is an image (I'm talking of course about the pdf in https://github.com/mozilla/pdf.js/issues/14641#issue-1161427541).
And if you look in the pdf you'll see some 3 Tr which mean that the text rendering mode is set to 3 which means that the text is invisible.
But, afaik, hardware acceleration implies that the drawing is done on the gpu, which really should be faster that rendering on the cpu. One problem we have in pdf.js is that we're drawing letters one by one (because we don't want to let the canvas doing the layout of the strings) and possibly it induces a slowdown which causes moving data from the gpu to the cpu and then something is wrong.
In Firefox, willReadFrequently has no effect, but in the future it could be plugged in order to be able to disable to hardware acceleration.

I understand, and it's clearly not your fault. I'm not asking you to fix it, I'm trying to do it by myself.
I wasn't able to reproduce it with just a canvas without pdf.js yet. So it's difficult to fill a bug elsewhere.
In any case, this is affecting a lot of users, and I wanted to add some more info here because it's where it can help the most people at the moment.
Thank you for the explanation about the interpolation, I get it now. I was not trying with that PDF. It happens to any PDF with text. The compressed.tracemonkey-pldi-09.pdf for example:

Yes, willReadFrequently should slow it down, but it doesn't seem to have so much impact. I know it's not a solution you could add to the library, but it's a quick fix for anyone who needs it.

Going off what @albertbal mentioned in re: to willReadFrequently: true, if I add this to all the getContext('2d')'s in the pdf.js code it seems to be a workaround on v1.9.426 but interestingly not v2.14.305 or v3.0.279. I'll try out some other versions and try to track down why this might be
Not sure why that'd be the case right now, but figured it's worth sharing in case anyone has any extra info

Thank you for your attention to this matter, and that it is not a pdf.js issue, and I do see that a chrome bug has been submitted for this at https://bugs.chromium.org/p/chromium/issues/detail?id=1382692

@albertbal got it right! I can confirm that using willReadFrequently: true in all the getContext('2d') calls across the library code fixes the issue by forcing software rendering. I've tested this with the latest 3.x version. Please note that it's important to modify all the calls to getContext, since I assume that some rendering is done in the worker and then just copied to the main canvas as an image.

I was pretty excited about this fix as my work uses PDFJS extensively and we were considering turning it off.  This 'fix' worked ... for many document but strangely not all of them.  Not sure yet how to characterize the differences as I haven't gone through them deeply but there are so many weird PDFs in the world.  So this helps, but isn't a complete fix afaik at this moment.

For these PDFs that still render incorrectly, does disabling "Accelerated 2D canvas" in chrome://flags help?
If by chance the PDFs are suitable to be shared can you attach an example PDF?

@hrvojelabtiva Yes!  Your first suggestion does work for those PDFs that still show the problem.  However, I need a JS solution as we can't easily ask customers (many very non-technical) to follow this.  Which, I believe, there is not.

Per MDN official docs:

@whughes98144, since you verified that turning off Accelerated 2D canvas in chrome fixes this problem - there are only two explanations possible:

Chrome/Edge fails to respect the flag in full (MDN states if has full support from version 99)
You have failed to to modify all the calls to getContext in the pdf.js source

Hi all! I commented in the other thread as well, but figured I'd pasta here too:
I am a QA tester for a webapp that uses react-pdf/pdf.js to render PDFs and we had a few customer reports about this issue with Chrome/Edge as well. I was originally unable to reproduce the issue until the company sent me a specific laptop...
From all the testing and investigation I've done, the issue seems to be tied to having the following four things:

App rendering PDFs using react-pdf/pdf.js
Chromium browser
Intel Iris Xe Graphics GPU (or similar integrated laptop GPU)
Specific PDF fonts (as the issue is not reproducible with all PDFs)

I have two different Windows ThinkPad laptops; one with a nVidia GPU and the other with the Intel Iris. I can only reproduce the issue on the Iris book, not the nVidia one. This goes in line with our clients' system specs, as well.
There are other integrated GPUs that will also see the issue but the Iris seems to be the most common. I could provide some other affected cards if needed, though.
If anyone needs me to test potential fixes on my affected device, I am more than happy to as long as it does not impede on any enterprise security protocols; the machine I have for testing is from work. Let me know, I hope narrowing it down to certain GPUs helps!

@callabr1 since I do believe this is a purely a Chromium bug (not pdf.js), what would be most useful is to create a minimal example of this without using pdf.js and submit that to the Chromium team along with the hardware details. There is already an open issue for this. Here's a naive attempt, but one ingredient that is surely missing is the "problematic" font.

@callabr1 - thanks for trying, as I said, my example was very naive and simple, and there's probably more to this - specifically isolating how pdf.js renders these fonts and recreating a minimal example off of that. But this is more than I have time for at the moment.

You can try to play with: https://github.com/Rob--W/canvas-interceptor
in plugging it in the various places where we create a canvas and then you should be able create a minimal piece of code.

@callabr1 since I do believe this is a purely a Chromium bug (not pdf.js), what would be most useful is to create a minimal example of this without using pdf.js and submit that to the Chromium team along with the hardware details. There is already an open issue for this. Here's a naive attempt, but one ingredient that is surely missing is the "problematic" font.

Try this: https://jsfiddle.net/rdgfx6zh/1/ Using roboto font

Hello @1Jesper1 thanks for the suggestion

Try this: https://jsfiddle.net/3kt6v82s/1/ Using roboto font

I tried, no dice - the text looks fine on the affected device. I tried changing the sentences displayed, the font size, and all variants of Roboto (bold, italic, MT). I'll keep playing around on jsfiddle but so far been unable to repro it there.

Thank you for your attention to this matter, and that it is not a pdf.js issue, and I do see that a chrome bug has been submitted for this at https://bugs.chromium.org/p/chromium/issues/detail?id=1382692

What makes you think that the linked chromium bug is associated to this? Looks like that it is related to sometimes hiding text completely because text rendering bounds go to 0. The issue reported here seems to be more related to not rendering well pdf files where the content is raster image.

Thank you for your attention to this matter, and that it is not a pdf.js issue, and I do see that a chrome bug has been submitted for this at https://bugs.chromium.org/p/chromium/issues/detail?id=1382692

What makes you think that the linked chromium bug is associated to this? Looks like that it is related to sometimes hiding text completely because text rendering bounds go to 0. The issue reported here seems to be more related to not rendering well pdf files where the content is raster image.

Looks like a different problem indeed, maybe we should report a new bug to Chrome?

Thank you for your attention to this matter, and that it is not a pdf.js issue, and I do see that a chrome bug has been submitted for this at https://bugs.chromium.org/p/chromium/issues/detail?id=1382692

What makes you think that the linked chromium bug is associated to this? Looks like that it is related to sometimes hiding text completely because text rendering bounds go to 0. The issue reported here seems to be more related to not rendering well pdf files where the content is raster image.

Looks like a different problem indeed, maybe we should report a new bug to Chrome?

I was about to enter a bug in Chromium as I don't see anything exactly like it, only similar (like the aforementioned zoom bug). However I realize when submitting there it'll automatically log my PC specs, and I left the affected device at home today 🙃 I will log a new issue in 4-5 hours, when I get home from office.
@stenvala I'll link the new Chromium issue tonight after I enter it, but for now it seems the most information and tracking can be done in related issue https://github.com/wojtekmaj/react-pdf/issues/1010 which is still open and has an attached MR which somewhat fixes the issue (some text was fixed, but PDFs with images seem to render badly still).

@callabr1 Did you file a new Chromium issue?

@callabr1 Did you file a new Chromium issue?

Yes I did, sorry I didn't enter it until I was back from holiday but it's here:
https://bugs.chromium.org/p/chromium/issues/detail?id=1404710
I'm trying to get a screen cast for them now, but my work disabled all the recording options on my device (they are locked to admin rights) - trying to get that sorted out to give a full video now :)

A new Chromium commit from today seems to fix the issue, at least on my XPS with an Iris Xe Graphics that has the same problems with the latest stable Chrome version whereas the latest Canary build works (with hardware acceleration enabled! ).

I still have the glitches on the canary version that introduces that commit (111.0.5530.0) too.
This suggests it is a different issue

Maybe someone out there will find this useful...
I've discovered a naive "workaround" until Chrome fixes the issue, in our PDF viewer code I called the PDFPageProxy.render multiple times which seems to make the document look correct.
// 5 is arbitrary, 2 works but 5 is just to be sure.
// The higher the number the slower the render (page stays white longer), 5 isn't noticable.
for (let i = 0; i < 5; i++) {
        await page.proxy.render({ canvasContext: ctx, viewport }).promise;
 }

I came to this conclusion because I noticed when zooming in and out the document somehow fixes itself. Tested triggering auto zoom-in-out but that didn't consistently work. Then I tried to do that multiple times but no luck either - Finally tried this and seems to work out fine.

Thank you. It worked in my case!!

@devalberg Thank you. It worked in my case!!

I'm not sure where you put that code, can you help me please?
Thanks in advance.-

@devalberg Thank you. It worked in my case!!

I'm not sure where you put that code, can you help me please?
Thanks in advance.-

@pluengom It's easy. You don't have to put the same code, in my case it didn't work('await' expressions are only allowed within async functions and at the top levels of modules.). But as @devalberg said, you have to call render of pdf page multiple times. In my case it looks so:
Before fix:
var renderTask = page.render(renderContext); renderTask.promise.then(function () { ... });
After fix:
var renderTask = page.render(renderContext); renderTask.promise.then(function () {     renderTask = page.render(renderContext);     renderTask.promise.then(function () {         ...     }); });

@devalberg Thank you. It worked in my case!!

I'm not sure where you put that code, can you help me please?
Thanks in advance.-

@pluengom It's easy. You don't have to put the same code, in my case it didn't work('await' expressions are only allowed within async functions and at the top levels of modules.). But as @devalberg said, you have to call render of pdf page multiple times. In my case it looks so: Before fix: var renderTask = page.render(renderContext); renderTask.promise.then(function () { ... });
After fix: var renderTask = page.render(renderContext); renderTask.promise.then(function () {  renderTask = page.render(renderContext);  renderTask.promise.then(function () {  ...  }); });

Many thanks for the answer.
It worked perfectly.

I don't know exactly how, but PDFPageView view class does work like a charm and fixes text distortion completely. I've adapted it instead of my previous solution and now it looks perfect!
Solution with rerendering a page N times doesn't solve the problem completely. After few iterations page looks better, but still distorted in many places.

@ma

I don't know exactly how, but PDFPageView view class does work like a charm and fixes text distortion completely. I've adapted it instead of my previous solution and now it looks perfect!
Solution with rerendering a page N times doesn't solve the problem completely. After few iterations page looks better, but still distorted in many places.
Took an example from there: https://github.com/mozilla/pdf.js/blob/master/examples/components/simpleviewer.js

@maybephilipp
Can you provide more details on how you fixed the text distortion? I am using 2.16.105 version of pdf.js.
Thanks in advance

Can you provide more details on how you fixed the text distortion? I am using 2.16.105 version of pdf.js. I am facing the rendering issue with chromium browsers on certain windows machines only.
Thanks in advance

@suryaprythvi Here is a adapted version of our React code. Sorry if some syntax or vars will not work. General idea of implementation is present.
import * as pdfJS from 'pdfjs-dist'
import * as pdfJSWeb from 'pdfjs-dist/web/pdf_viewer'
import 'pdfjs-dist/web/pdf_viewer.css'

const eventBus = new pdfJSWeb.EventBus();

const loadedDoc = await pdfJS.getDocument({
  url: activePdf.url,
}).promise

const page = await doc.getPage(pageNum)

const origViewport = page.getViewport({ scale: 1 })
const scale = wrapperSize.width / origViewport.width

const viewport = page.getViewport({ scale })

const pageView = new pdfJSWeb.PDFPageView({
  container: canvas,
  id: pageNum,
  scale: 1,
  defaultViewport: viewport,
  eventBus,
})

pageView.setPdfPage(page)

pageView.draw()

Hi @Snuffleupagus and @calixteman,
I believe there are two separate bugs being discussed within this ticket. In the PDF posted initially by @PawelW13i the text is blurry and does not look smooth. The PDF in this comment has chunks of letters missing and is unreadable in some places.
I have a PDF where I can reproduce the initial issue reported. The issue with chunks of letters missing I cannot reproduce on my ARM Mac using Chrome. I believe I cannot reproduce this because I do not have one of the specified graphics cards mentioned on the chromium bug.
I am working on a fix for the initial issue. I am able to fix the blurriness by forcing img/imgData.interpolate to be true on the following two lines in canvas.js

https://github.com/mozilla/pdf.js/blob/master/src/display/canvas.js#L1344
https://github.com/mozilla/pdf.js/blob/master/src/display/canvas.js#L2994

I can achieve this by adding an enableInterpolation option to defaultOption and accessing that option in canvas.js.
Does this sound right to you all? Would you be open to a PR that adds enableInterpolation as an option that consumers could toggle?
Thanks!

Would you be open to a PR that adds enableInterpolation as an option that consumers could toggle?

Sorry, but I'm not at all excited about that unfortunately. Please keep in mind that all options have a maintenance/support burden, and none of this applies to Firefox (which is primary development target for this library).
Note that this is a bug (or possibly multiple bugs) specific to a particular combination of one browser (i.e. Google Chrome), certain graphics card, and hardware acceleration being enabled; hence it doesn't seem entirely reasonable that we should have to "work-around" that here.


peep: 0.1.4-post.2021-08-17 -> 0.1.6

Description of changes
Update peep to the newest version. Release notes can be found at https://github.com/ryochack/peep/releases/tag/v0.1.6
Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[X] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[X] Fits CONTRIBUTING.md.

After some more testing, the latest release seems to be behaving oddly (it appears to be losing a large fraction of its input), while the previous 0.1.4 version doesn't show this behavior. I'm going to close this PR and try to follow up with the author.