Method to get the violation of each constraint given a sampleset

Something like cqm.violations() -> Mapping[Hashable, float]. Can be done now with
violations = {}
for label, constraint in cqm.constraints.items():
    violations[label] = constraint.lhs.energy(sampleset) - constraint.rhs

When we solve a satisfiability problem, we can we will have objective or energy = 0, and there is no distinction between different solutions. It would be nice to be able to easily assess which solution violates less.
I think there should be two functions. cqm.violations() and cqm.constraint_energies() or something like that.
Here is the difference.
for ==, the violation is the absolute of energy (or square of)
for <=, the violation is zero, if energy <= 0, otherwise, it's equal.

The latter seems like the right "default" definition. We could potentially combine them into one method with something like
class CQM:
    ...
    def iter_violations(self, clip=True) -> Iterator[Tuple[Hashable, float]]:
        if clip:
            yield from ((label, max(en, 0)) for label, en in self.iter_violations(clip=False))
        else:
            for label, constraint in cqm.constraints.items():
                yield label, constraint.lhs.energy(sampleset) - constraint.rhs

    def violations(self, clip=True) -> Dict[Hashable, float]:
        return dict(self.iter_violations(clip=clip))

Trying that again:
class CQM:
    ...
    def iter_violations(self) -> Iterator[Tuple[Hashable, float]]:
        for label, constraint in cqm.constraints.items():
            if constraint.sense is Sense.Le:
                yield label, constraint.lhs.energy(sampleset) - constraint.rhs
            elif constraint.sense is Sense.Ge:
                yield label, -min(constraint.lhs.energy(sampleset) - constraint.rhs)
            elif constraint.sense is Sense.Eq:
                yield label, abs(constraint.lhs.energy(sampleset) - constraint.rhs)
            else:
                raise RuntimeError("unexpected Sense")

    def violations(self) -> Dict[Hashable, float]:
        return dict(self.iter_violations(clip=clip))

Maybe I misunderstood the clip argument or maybe that's the wrong argument. I was expecting to see negative values for equality constraint when clip=False
import itertools
cqm = dimod.ConstrainedQuadraticModel()
x = dimod.Binary('x')
y = dimod.Binary('y')
z = dimod.Binary('z')
cqm.set_objective(-x-y-z)
cqm.add_constraint(x + y + z <= 2, label='c1')
cqm.add_constraint(x + y + z == 2, label='c2')

for values in itertools.product([0, 1], repeat=3):
    sol = {k: v for k, v in zip(cqm.variables, values)}
    print(sol, cqm.violations(sol),
          cqm.violations(sol, clip=False))

This produces:
{'x': 0, 'y': 0, 'z': 0} {'c1': 0.0, 'c2': 2.0} {'c1': -2.0, 'c2': 2.0}
{'x': 0, 'y': 0, 'z': 1} {'c1': 0.0, 'c2': 1.0} {'c1': -1.0, 'c2': 1.0}
{'x': 0, 'y': 1, 'z': 0} {'c1': 0.0, 'c2': 1.0} {'c1': -1.0, 'c2': 1.0}
{'x': 0, 'y': 1, 'z': 1} {'c1': 0.0, 'c2': 0.0} {'c1': 0.0, 'c2': 0.0}
{'x': 1, 'y': 0, 'z': 0} {'c1': 0.0, 'c2': 1.0} {'c1': -1.0, 'c2': 1.0}
{'x': 1, 'y': 0, 'z': 1} {'c1': 0.0, 'c2': 0.0} {'c1': 0.0, 'c2': 0.0}
{'x': 1, 'y': 1, 'z': 0} {'c1': 0.0, 'c2': 0.0} {'c1': 0.0, 'c2': 0.0}
{'x': 1, 'y': 1, 'z': 1} {'c1': 1.0, 'c2': 1.0} {'c1': 1.0, 'c2': 1.0}

I like to be able to say that x+y+z - 2 (regardless of == or <=) has a current value/energy/evaluation of -2 or -1, or 0, etc. The violation is correct (the abs(value) for equality and value if value >= 0 for inequality).

I am confused why there would be negative values for equality constraints? This value is returning the "violation" of the constraint, and if the lhs != the rhs, then the violation is positive.
If you just want lhs - rhs, then we also should not swap the sign on the >=. Otherwise we are not being consistent in what we mean by violation.

To expand, there are two self-consistent ways we can encode this information:

Always return the lhs - rhs. So
a) 1 <= 5 -> -4
b)  1 >= 5 -> -4
c)  1 == 5 -> -4
Treat "the amount of feasibility" as negative and the "amount of infeasibility" as positive
a) 1 <= 5 -> -4 since it's satified
b)  1 >= 5 -> 4 since it's violated
c)  1 == 5 -> 4 since it's violated

If we want to do (1) then IMO we should make a separate method cqm.iter_lhs_minus_rhs() or the like, if we want (2) then I would implement it as I have in #975 . We can also have both :shrug:

The issue with the second suggestion is that it hides the direction of infeasibility for equality constraints.
My suggestion

Maybe we need a second method that isn't called "violation" and it simply returns the raw lhs-rhs (understood as the left of <= or ==)
remove clip, because that's not what I had in mind (or keep it if you think would be useful in other situations)

I am resistant to reinterpreting the >= as <= as the default behavior. I understand why that may be convenient in some cases but IMO that's exactly the kind of special case that causes lots of user confusion.
I suppose an ugly, but explicit way would be
(a) cqm.violations(..., signed_equality=True). Terrible keyword name but you get the point.
(b) cqm.lhs_minus_rhs(..., reinterpret_ge=True). Again bad name, but you get the idea.


Fixed grouped column Header that were not adjusting based on hidden child columns

The grouped header columns are not adjusting width if child columns update their show property.  This is because the Headers are basing their width on the sum of the child columns, but not factoring in the show property.
You can see an example below.  I added a button to toggle the fix on and off.
https://codesandbox.io/s/react-table-v7-sandbox-2qyr4

I don't see a difference when clicking the fix on or off. Maybe make sure your sandbox is up to date?
Also, would it be better to just update the measuring to not use the hidden columns, instead of affecting anything using the flattenColumns function?

Yea my sandbox has been edited since, I thought I forked it since making some changes.
You're absolutely right about leaving the flattenColumns util alone.  I was able to just add a filter before calculating the sum inside useFlexLayout
Heres an updated sandbox: https://codesandbox.io/s/react-table-v7-sandbox-zw2xi


Feature/statistic

Merge Statistic and this branch is testing 👍

Our main branch is 'master'.
'elements-0.14.1' is the elements main branch and is outdated.
But we don't want to merge this to master, just a separate branch called 'stats' or something.


[Extensions] Enable extensions to provide job index names and job types to Job Scheduler after JS is bootstraped by PluginsService

@joshpalis thanks for the issue. Could help us understand the sequence of events and what are we solving with this proposal?

Closed as this has been handled by : https://github.com/opensearch-project/opensearch-sdk-java/issues/274


Fix the invalid spirv generation for matrix cast

Spirv doesn't have instruction to do the float cast for the matrix type. So we have to convert the matrix row by row, and then construct them to a new matrix.
Update the unit test to make sure the cast won't miss any elements.
Also update the workflow to validate the spirv generation.

Were you able to reproduce the validation error locally without upgrading the vulkan sdk version?

This PR will close #4589.

sdk

Yes, I can. And now the issue is gone with this change.

I rebase on TOT and remove the windows-selfhosted.yml.


data model

closes https://github.com/inveniosoftware/invenio-rdm-records/issues/221
closes https://github.com/inveniosoftware/invenio-rdm-records/issues/218
As discussed IRL with @lnielsen it also makes vocabularies id lower case.

Why additional description does not have "description" as required? -> jsonschema needs to be flexible to allow drafts to validate. Hard validation is done via marshmallow.
And why additional titles do not have "type" as required? -> DataCite does not...
Should type also not be required in additional description? -> DataCite does...
Before we had "main title" as type, which I assume now we can remove? -> Yes, removed 🔥

Coverage decreased (-0.05%) to 86.047% when pulling 68ecc30bac4c292d6f9b6ff84488289d928c71e8 on ppanero:datamdodel into 664d45b6a69370b991c11e2a26ddc97d117e9ede on inveniosoftware:master.


⚠ Bofrost.lu has degraded performance

In 91b74ba, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1448 ms

Resolved: Bofrost.lu performance has improved in 940768f after 24 minutes.


Can not record for [Cloud Speech Streaming gRPC Objective-C]

ProductName:	Mac OS X
ProductVersion:	10.12.6
BuildVersion:	16G29
pod --version 1.3.1

Problem | Feature
I copied the relevant information to my new project, and the successful use of pod install, and then the project can compile.
But I can not record the sound.
I add NSLog  to
- (void) processSampleData: (NSData *) data {      NSLog (@ "data:% @", data) ;     ..... }
but I Get all 0x00
I inserted
AVAudioSession * audioSession = [AVAudioSession sharedInstance]; [audioSession setCategory: AVAudioSessionCategoryPlayAndRecord withOptions: AVAudioSessionCategoryOptionAllowBluetooth error: nil]; [audioSession setActive: YES error: nil];
until before
audioData = [[NSMutableData alloc] init]; [AudioController.sharedInstance prepareWithSampleRate: SAMPLE_RATE]; [SpeechRecognitionService.sharedInstance setSampleRate: SAMPLE_RATE]; [AudioController.sharedInstance start];
--

I have the same problem. Wan't to use the streaming audio with bluetooth but recording is not working. Any update / solution for this problem?


https

@dschenkelman Please reopen if required with more details.

Sorry. Created this in the wrong repo. Thanks for closing @anraghun


improve stability of test and reducing Duration of Integration Tests Run

Proposed Changes

Adding squashfsOSImage for machine boot
Removed the extra fields in machine definitions
Readjusted the timeouts
Used ordered flag

Fixes https://github.com/ironcore-dev/libvirt-provider/issues/242

check pls this PR https://github.com/ironcore-dev/libvirt-provider/pull/222/files and move DeferCleanup they are in some files on wrong place and they don't have to be running in some cases.

@so-sahu  Is there a reason for enforcing the ordered execution?

I observed some unexpected behavior, particularly when listing machines with labels. Instead of returning one machine, it returned two. It seems that one test is affecting another. Even @lukas016 has observed such strange behavior.
To address this, I'm using ordered execution.

our test aren't written for parallel run

Re-writing of tests in progress: https://github.com/ironcore-dev/libvirt-provider/pull/345


Overflow issue in bit set

I'm merging your recent commits to my branch and found this:

You could use something like this, perhaps:

Indeed. Thank you for your report.
It is fixed in master.


Text Extractor Turkish letters problem

Microsoft PowerToys version
0.73.0
Installation method
Microsoft Store
Running as admin
No
Area(s) with issue?
TextExtractor
Steps to reproduce
inclusion of turkish letters
✔ Expected Behavior
No response
❌ Actual Behavior
text extractor does not detect the Turkish letters pelase
Other Software
No response

Please provide sample images so I can reproduce this issue and bug report details.
/bugreport


Log Monitors behavior fix

Current behavior for log monitors:
• Missing data group alerts auto-resolve (via expiry) after 7 days.
• Critical and warning ones also auto-resolve after 7 days of missing data.
Current behavior for metrics monitors:
• Missing data alerts auto-resolve (via expiry) after 1 day.
• Critical and warning ones auto-resolve after "query time range" + some delta. So if query time range is 15 mins, it can be anywhere between 15 to 20 mins depending on the scenario.
My recommendation:
• Logs missing data alerts should auto-resolve after 1 day (via expiry) - same as metrics ones: needs code changes.
• Logs critical and warning continue to remain in triggered state as long as alert condition continues to match.
• We should document the current behavior. cc <@UK8GRBSQZ> to verify logs one and <@UMYT715GR> for metrics one. Since this is a little complex, please provide the exact content.
Slack Message

Related ticket: https://sumologic.atlassian.net/browse/SUMO-208482

@kimsauce, I'm closing this issue because you resolved it with SUMO-208482.


sha/keccak1600.c: add couple of soft asserts.

Are those function intended to remain internal or are they going to be accessible publically?

If the caller has restrictions on the input parameter ranges they should not be implemented as an assert ever ...

Are those function intended to remain internal or are they going to be accessible publically?

Define "publicly". They won't be exported from shared library, no. But they will be visible in libcrypto.a.

If the caller has restrictions on the input parameter ranges they should not be implemented as an assert ever ...

I want to remind that this is soft assert, i.e. one that is compiled as no-op in production build. Such asserts serve dual purpose: a) kind of documentation; b) when code is integrated into EVP it serves as development-time safety net to catch malformed EVP_MD.

Are those function intended to remain internal or are they going to be accessible publically?

Define "publicly". They won't be exported from shared library, no. But they will be visible in libcrypto.a.

I'm thinking "publically" as an interface that we publically declare, i.e. that are (or will be) declared in a header file in include/openssl/.
The point is that if r is a value we control, i.e. that we have a layer above the functions in this file (I imagine in EVP or in an engine) where the value of r has been checked, then I'm fine with this change.  If it's a value that we just pass uncontrolled from the calling application, then I'm with @t-j-h.
So in essence, are those asserts checking our screwups, or the calling application's?

The point is that if r is a value we control

Yes, r is the value that we will have full control over. asserts are meant to catch internals screw-up during building real SHA-3/SHAKE upon this primitive.

Cool.  I've no issues with this then.

a) kind of documentation;

If you need to know the reason for why I decided to add asserts is that for a fresh eye it's actually not obvious that inner loops are valid. Yes, commentary discusses possible values for r, but I felt that explicit reminder (in form of soft assert) is appropriate. One can view it as "all the values discussed in commentary are actually divisible by 8, didn't you notice?"


Undefined attribute in MessageValue.Field

In some cases, creating the printable representation of MessageValue fails due to an undefined attribute __last in Field:
<[AttributeError("'Field' object has no attribute '_Field__last'") raised in repr()] MessageValue object at 0x7fc772733f10>

Warning: Undefined array key "messageValue" in C:\xampp\htdocs\PHP\internship project\chatbot_db.php on line 17


Porting Electron-Forge from mac to window produces errors using Make

I keep getting these errors when trying to make appx. This is the app I was originally working on on mac and everything worked. So I tried to port it over to windows made sure electron and electron-forge was all installed globally and begin configuring and running and this is what I keep getting. Not sure if its my config or what.
- Making for target: appx - On platform: win32 - For arch: x64
An unhandled exception has occurred inside Forge:
ENOENT: no such file or directory, stat 'C:\Elec\App\out\make\appx\x64\logs\conversion.log'
Error: ENOENT: no such file or directory, stat 'C:\Elec\App\out\make\appx\x64\logs\conversion.log'
    at Error (native)
    at Object.fs.statSync (fs.js:987:18)
    at Tail.watch (C:\Users\prof\AppData\Roaming\npm\node_modules\electron-forge\node_modules\electron-windows-store\lib\vendor\tail.js:88:20)
    at new Tail (C:\Users\prof\AppData\Roaming\npm\node_modules\electron-forge\node_modules\electron-windows-store\lib\vendor\tail.js:79:14)
    at Timeout.setTimeout (C:\Users\prof\AppData\Roaming\npm\node_modules\electron-forge\node_modules\electron-windows-store\lib\convert.js:63:16)
    at ontimeout (timers.js:365:14)
    at tryOnTimeout (timers.js:237:5)
    at Timer.listOnTimeout (timers.js:207:5)

Windows store config:
  "windowsStoreConfig": {
        "containerVirtualization": true,
        "platform":"appx",
        "packageName": "App",
        "publisher": "CN=Myappid",
        "windowsKit": "C:\\Program Files (x86)\\Windows Kits\\10\\bin\\x64",
        "desktopConverter": "./DesktopAppConverter",
        "expandedBaseImage": "./DesktopAppConverter/BaseImage-14352",
        "flatten": true,
        "icon":"src/assets/icons/win/icon.ico",
        "packageVersion": "<IP_ADDRESS>",
        "packageDisplayName": "App",
        "packageDescription": "My App",
        "packageExecutable": "app/App.exe"
      }

This log looks like it is being made by electron-windows-store but we might have to make a directory that we aren't making in time.  Not too familiar with this particular maker, I'll look into over the weekend if i can or someone more familiar with this might know.
/cc @paulcbetts @felixrieseberg

Okay I see. Should I just use electron-windows-store directly in the mean time, or will it cause problems with my forge app?

@AhadCove You don't need the desktop converter, just :fire: these lines:
        "containerVirtualization": true,
        "windowsKit": "C:\\Program Files (x86)\\Windows Kits\\10\\bin\\x64",
        "desktopConverter": "./DesktopAppConverter",
        "expandedBaseImage": "./DesktopAppConverter/BaseImage-14352",
        "flatten": true,

@paulcbetts I just tried those lines and ran into the same error

@AhadCove to be clear, you tried removing those lines?

Oh no I tried using them lol, sorry I mis read it

I erased those lines and am still receiving the same error. Should I try erasing my node modules or something since it was a copied over app from Mac?

@AhadCove You definitely 100% can't copy over node_modules across platforms and have it work, blow away node_modules and npm install again

Okay yeah I was thinking that may be the problem will try that now.
It looks like it's getting stuck in the temp directory somehow
An unhandled error has occurred inside Forge:
An error occured while making for target: appx
C:\Program Files (x86)\Windows Kits\10\bin\x64\makeappx.exe exited with code: 1
Error: C:\Program Files (x86)\Windows Kits\10\bin\x64\makeappx.exe exited with code: 1
    at ChildProcess.child.on (C:\Users\prof\AppData\Roaming\npm\node_modules\electron-forge\node_modules\electron-windows-store\lib\utils.js:72:23)

Yeah, reinstalled all new node modules and ran into the same thing
An unhandled error has occurred inside Forge:
An error occured while making for target: appx
C:\Program Files (x86)\Windows Kits\10\bin\x64\makeappx.exe exited with code: 1
Error: C:\Program Files (x86)\Windows Kits\10\bin\x64\makeappx.exe exited with code: 1
    at ChildProcess.child.on (C:\Users\prof\AppData\Roaming\npm\node_modules\electron-forge\node_modules\electron-windows-store\lib\utils.js:72:23)
    at emitTwo (events.js:106:13)
    at ChildProcess.emit (events.js:191:7)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:215:12)

Heres my current config
"platform":"appx",
        "packageName": "App",
        "publisher": "CN=my app id",
        "packageVersion": "<IP_ADDRESS>",
        "packageDisplayName": "App",
        "packageDescription": "A great app",
        "packageExecutable": "app/App.exe"

Usually makeappx will also print some other stuff, what's it say? Also, try setting:
$env:DEBUG="*,-babel"

Well That's the full error log that was printed.
Do I put $env:DEBUG="*,-babel" in the cli or the config?

oh and at the end of the error it also says this, Not sure if this is what you are asking about:
npm ERR! Windows_NT 10.0.14393
npm ERR! argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "run" "forgeWin"
npm ERR! node v6.9.4
npm ERR! npm  v3.10.10
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>forgeWin: `electron-forge make appx`
npm ERR! Exit status 1

@AhadCove You should set the DEBUG environment variable to the value, *,-babel

I looked under my environments folder at environment.ts and looked in my package.json and can't figure out where to put that line at

@AhadCove What shell are you using? You should just set it by-hand

Atom

Yeah, sorry. I cannot find this anywhere or any info how to change it online

Look up how to set environment variables in Atom, when you execute commands.

If you can't find the way to do this, I suggest asking in the Atom forum or their Slack instance.

As far as I can see from this issue thread it progressed something like this

Copied node_moduels folder from one platform to another (this will almost never work)
Getting an exception in electron-windows-store of which there will be an understandable error somewhere in the log.
Failed to set the DEBUG environment variable (a cursory google search google explain how to set environment variables on windows)

To me this appears to be mostly user mis-configuration, closing out until an actual issue surfaces.

but @MarshallOfSound I said I already reinstalled node_modules and got the same results. It wasn't that that was the problem because all the packaging and making works other than appx.

Also before I merged my project with forge windows store config was working that's why I came to this thread to ask because I don't know what is causing these errors after merging.

The only thing that I am still asking around and trying to find out is how to set the environment variables.

To set an env var on windows
set VAR_NAME=value

# so for debug
set DEBUG=electron*

Thank you, but I still don't understand where this goes. Is it my main.js, my package.json, my envionment.ts?

@AhadCove You run it.. In command prompt?

Okay I ran the two commands in cmd and re ran electron-forge make appx with these configs:
  "windowsStoreConfig": {
        "platform":"appx",
        "packageName": "App",
        "publisher": "CN=myid",
        "packageVersion": "<IP_ADDRESS>",
        "packageDisplayName": "App",
        "packageDescription": "Cool App",
        "packageExecutable": "app/App.exe"
      }

using debug = electron i get back:
Creating appx package...
  electron-windows-store Using makeappx.exe in: C:\Program Files (x86)\Windows Kits\10\bin\x64\makeappx.exe +0ms
  electron-windows-store Using pre-appx folder in: C:\Coding\App\out\make\appx\x64\pre-appx +0ms
  electron-windows-store Using following destination: C:\Coding\App\out\make\appx\x64\App.appx +0ms
  electron-windows-store Using parameters: ["pack","/d","C:\\Coding\\App\\out\\make\\appx\\x64\\pre-appx","/p","C:\\Coding\\App\\out\\make\\appx\\x64\\App.appx","/o"] +0ms
Microsoft (R) MakeAppx Tool
Copyright (C) 2013 Microsoft.  All rights reserved.

The path (/p) parameter is: "C:\Coding\App\out\make\appx\x64\App.appx"
The content directory (/d) parameter is: "C:\Coding\App\out\make\appx\x64\pre-appx"
Enumerating files from directory "C:\Coding\App\out\make\appx\x64\pre-appx"
Packing 79 file(s) in "C:\Coding\App\out\make\appx\x64\pre-appx" (content directory) to "C:\Coding\App\out\make\appx\x64\App.appx" (output file name).
Using "C:\Coding\App\out\make\appx\x64\pre-appx\appxmanifest.xml" as the manifest for the package.
MakeAppx : error: Error info: error C00CEE26: App manifest validation error: The app manifest XML must be valid: Line 8, Column 28, Reason: An attribute value must not contain '<'.

MakeAppx : error: Package creation failed.
MakeAppx : error: 0x80080204 - The specified package format is not valid: The package manifest is not valid.

× Making for target: appx - On platform: win32 - For arch: x64

An unhandled error has occurred inside Forge:
An error occured while making for target: appx
C:\Program Files (x86)\Windows Kits\10\bin\x64\makeappx.exe exited with code: 1
Error: C:\Program Files (x86)\Windows Kits\10\bin\x64\makeappx.exe exited with code: 1
    at ChildProcess.child.on (C:\Users\bk\AppData\Roaming\npm\node_modules\electron-forge\node_modules\electron-windows-store\lib\utils.js:72:23)
    at emitTwo (events.js:106:13)
    at ChildProcess.emit (events.js:191:7)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:215:12)

npm ERR! Windows_NT 10.0.14393
npm ERR! argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "run" "forgeWin"
npm ERR! node v6.9.4
npm ERR! npm  v3.10.10
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>forgeWin: `electron-forge make appx`
npm ERR! Exit status 1

I mean, the error is right there 😄

MakeAppx : error: Error info: error C00CEE26: App manifest validation error: The app manifest XML must be valid: Line 8, Column 28, Reason: An attribute value must not contain '<'.

It finally worked. Thank you so much! Sorry for asking so many questions. Now lets hope the windows store accepts it lol.
It ended up being my author name had my email surrounded in <> is the reason why it was not working. Thanks again everyone!

I actually have another question that does not have anything to do with any of this, should I open a new one or ask it here? It has to do with caching issues


Latest development build Beta2 can not change menu

Experienced an odd issue on the latest dev build. Where I could not click on any other menu. Reloading the UI via the View menu fixed the issue.

Fixed in https://github.com/EvanPurkhiser/prolink-tools/commit/67c9f4d5d53b136f8ffba5d36fd17d0c626067e1


[dashboard compatibility] New buffer left when opening a new buffer with dashboard open

👋🏼
If I open nvim it start dashboard and then I open a file into a buffer. There's now two buffers open, one with the file and one that is new. This is not how fzf.vim work - it should only have the buffer with the file open.
Using the following setup:
    use {
        'ibhagwan/fzf-lua',
        event = 'VimEnter',
        requires = {'ibhagwan/nvim-fzf', 'kyazdani42/nvim-web-devicons'}
    }

https://user-images.githubusercontent.com/2284724/126908581-e99c787e-0c61-4bef-8937-e1d4f48a401c.mp4

I found the crux of the issue, seems that dashboard-nvim has hard coded compatibility with both Telescope and vim-clap, take a look at dashboard.vim#L41, autocmd User TelescopeFindPre,ClapOnEnter call dashboard#close_preview() which closes the dashboard preview when telescope or vim-clap user events are signaled.
Obviously this doesn't happen with fzf-lua, I'm trying to figure out if I can solve it without having to PR dashboard with a custom event, just as a test I tried hijacking the event and send TelescopeFindPre but it doesn't seem to solve the issue.
The issue is probably in dashboard, even without opening a file the simple action of opening fzf-lua leaves an empty buffer in dashboard, I'll do some more digging see if I can work around it.

Ok, so unfortunately the isn't what I describe in the previous comment, that issue relates to dashboard's preview window (not sure what that is but I can guess).
I'm not sure why but after existing fzf-lua and reentering dashboard again, dashboard generates another [No Name] buffer, you can see that if you run fzf-lua.buffers() you'll see the newly created buffer is number #3 (which is a new buffer, fzf-luz will open at buffer #2 on a new instance).
This issue is better suited for dashboard, I would have tried to solve it and PR dashboard but it has too much vimscript to my liking :-)

@ibhagwan I just find it strange that it works properly for fzf.vim.

@ibhagwan I just find it strange that it works properly for fzf.vim.

I’m with you on that, I really have no clue why it does that, only that it creates a new buffer that isn’t generated by fzf-lua, I thought perhaps specific buffer options used for the created floating window in fzf-lua but I am running pretty much the same buffer and window options as Telescope so I’m as puzzled as you. All I know with high certainty is the new buffer isn’t created by fzf-lua.
I have a strong feeling this is also related to the previous issue we had of the floating window that isn’t closed properly when dashboard is used, I fixed it by force closing the window but I’m still unsure why it happened.
Sorry I can’t be of more help.

I commented on your dashboard issue #92, will leave this issue open until we get to the bottom of it, either here or in dashboard, I might give it another go when I have time later.

I just applied another fix for nvim-fzf, I'm still convinced this is an issue with some autocmd in dashboard but somehow changing the order of first closing the window and then deleting the buffer (rather than wiping the buffer and the checking if the window is still open), solved the issue.
If you're still using my fork of nvim-fzf just update and it should be solved, lmk if otherwise?

Just FYI, turns out this bug also exists or existed with Telescope too, dashboard issue #88.


AttributeError: 'Dataset' object has no attribute 'value'

Running pytorch_conv3L_dvsgestures_args.py always returns an error：
Traceback (most recent call last):
File ".\pytorch_conv3L_dvsgestures_args.py", line 206, in
n_test, input_tests, labels1h_tests = generate_test(gen_test, n_test=1 if args.valid else 100, offset = args.test_offset)
File ".\pytorch_conv3L_dvsgestures_args.py", line 183, in generate_test
input_test, labels_test = gen_test.next(offset=offset)
File "D:\python38\lib\site-packages\dcll-0.0.1-py3.8.egg\dcll\load_dvsgestures_sparse.py", line 68, in next
dat,lab = next_1ofeach(
File "D:\python38\lib\site-packages\dcll-0.0.1-py3.8.egg\dcll\load_dvsgestures_sparse.py", line 197, in next_1ofeach
batch_1of_each = {k:range(len(v['labels'].value)) for k,v in hdf5_group.items()}
File "D:\python38\lib\site-packages\dcll-0.0.1-py3.8.egg\dcll\load_dvsgestures_sparse.py", line 197, in
batch_1of_each = {k:range(len(v['labels'].value)) for k,v in hdf5_group.items()}
AttributeError: 'Dataset' object has no attribute 'value'

Solved: The new version of h5py module, if you want to implement the dataset.value method, directly dataset[()]

I have the same problem, but I don't know how to modify it.

I have the same problem, but I don't know how to modify it.Do I need to modify the value of the code?

Find the h5py's  dataset.py file in youir venv  directory.
$ find . -name "dataset.py"
./lib/python3.9/site-packages/torch/utils/data/dataset.py
./lib/python3.9/site-packages/pyarrow/dataset.py
./lib/python3.9/site-packages/h5py/_hl/dataset.py

find may return several filepathes, but we know the h5pys is the root cause. Open the h5py's dataset then add 3 lines in Dataset  class.
@property
def value(self):
    return self[()]

😄


WIP: FrequencyBandImageFilter accepts lambdas for filtering frequencies

This filter is not thoroughly tested yet. It should enable custom filtering via the functor, e.g. implementing Butterworth algorithm.

Should FrequencyBandImageFilter be derived from the UnaryGeneratorFilter?

@phcerdan Do not confuse UnaryGenerator filter which is pretty new, and UnaryFunctor filter which is very old.

@phcerdan If backwards compatibility is not a major issue, we could refactor the filter as you propose. What do others think? @thewtex @hjmjohnson @blowekamp

+1 for separating the FrequencyBandImageFilter into a "Frequency Generator Filter" base class and a "Box Functor". They could come together into the current class similar to the "AddImageFilter" combines the BinaryGeneratorImageFilter and the AddFunctor.

I think the only module using it (heaviliy) is ITKIsotropicWavelets, and I can fix that when needed. Also, to avoid breakage of backwards compatibility, we can create the functor, and then create a FrequencyBandImageFilter just plugging together the base class and the new boxFunctor.

Looks like I agree with @blowekamp :smile:

I don't think the frequency classes have been in a final release, so there should not be backwards compatibility concerns. :new:

Great! Let me verify that this works as intended, then I can polish it per suggestions.

By the way, BandPassFunctor should be a better name.

A better name for what is now known as BoxFunctor, or for what is now known as FrequencyBandImageFilter?

A better name for BoxFunctor.
And maybe we can add FrequencyBandPassImageFilter. I like that name but could be misleading because it works as well as a FrequencyBandBlockImageFilter depending on options...

Thanks all.  This is good work.

With the new GitHub workflow hopefully it is easier to manage topic branches. Please separate the nice documentation improvement in itkUnaryGeneratorFilter into separate commit to help keep a clear history.

This is working as expected. I will refactor this patch to separate the box functor into its own class and add additional Butterworth functor.

In the end I did not add Butterworth filter here, but as its implementation is short it can be defined in appropriately adjusted form by the user.

I think this is ready for merging. Can you re-review please?

Looks good!
Does this class of filters support streaming? If not then EnlargeOutputRequestedRegion should be overloaded to make the output the largest possible.

@blowekamp why should the OutputRequestedRegion be enlarged?

The default behavior of the ITK pipeline (e.g. ImageToImageFilter) is to have the requested region of the output be copied to the inputs. This enables streaming for basic filters like the unary functors etc.. This filter operates with frequency space, I believe an output pixel needs more information than just the corresponding input pixel.
One way to disable streaming is to overload EnlargeOutputRequestedRegion to set the produced region to always be the largest possible region. By default the output region gets copied to the input. This is done when the filter only works on the whole image.
Other options depend on if and how the filter can stream.

This filter is templated over the frequency iterator. The iterator uses the meta-information to know the frequency of the currently iterated pixel. And a reference to this iterator is passed to the functor, so it can access the frequency etc. Which means that this filter should probably be able to stream. I haven't tested that, though.

This filter is templated over the frequency iterator. The iterator uses the meta-information to know the frequency of the currently iterated pixel. And a reference to this iterator is passed to the functor, so it can access the frequency etc. Which means that this filter should probably be able to stream. I haven't tested that, though.

If the filter only has part of the input, then the boundary conditions would likely cause difference frequencies to be processes by the iterator.
It may be that the filter can produce an arbitrary output but needs the full input. In that case the GenerateInputRequestedRegion should be overloaded to set the input's requested region to the largest possible.

This is essentially a per-pixel filter. The only complication is that the iterator "knows" the frequency/index of the pixel, which is used as a criteria for modifying the value. I don't think the input's region needs to be expanded.

Ok, I got how the iterator operate now. Thanks!

For me, it helps to think that the input and output images are already in the frequency domain. The only role of the frequency iterators is to avoid the change of the algorithms depending on the Fourier transform or frequency layout.
So the developer thinks directly in frequencies, instead of what indices correspond to what frequencies.

@thewtex I fixed that with the latest push. All checks are now passing.

Sorry, I was unplugged on the weekend, sorry for not answering on time. But I would have approved,  scalarFrequency is a way better name than the old w. Thanks @dzenanz


Shelley: choose the right initial nonce

Fix this TODO:
https://github.com/input-output-hk/ouroboros-network/blob/eec4a136bb51d882ab4cf4de552f1ce978459f56/ouroboros-consensus-shelley/src/Ouroboros/Consensus/Shelley/Node.hs#L209

I think the easiest thing to do for this is to seed the nonce with some randomness we can insert in ShelleyGenesis. Then people who know more about crypto can decide how much we care about that randomness.

Nonces in question: https://github.com/input-output-hk/ouroboros-network/pull/2147/files#diff-d2f1c2d3ca7a404a7f9608acbec24fabR275

@JaredCorduan With all these discussions about nonces, I don't know what the final decisions were :confused:. Let me go over the places in consensus where we currently pick a nonce so we can check whether we make the right choice.
A fresh Shelley chain
When starting a Shelley chain from scratch, like in the F&F testnet, we call initialShelleyState in consensus with SL.NeutralNonce as the initNonce argument here: https://github.com/input-output-hk/ouroboros-network/blob/c1f65da121805cd3903915ab0ccad576554d3c68/ouroboros-consensus-shelley/src/Ouroboros/Consensus/Shelley/Node.hs#L175-L186
Looking at initialShelleyState, this means we use that SL.NeutralNonce argument for the following nonces: "Current epoch nonce", "Evolving nonce", and "Candidate nonce". The fourth and final nonce, "Prev epoch hash nonce", is hard-coded in initialShelleyState to be NeutralNonce.
Is this correct? The alternative is to create a nonce from the hash of the Shelley genesis config file and pass that to initialShelleyState.
The Byron-to-Shelley hard fork
When transitioning from Byron to Shelley, we have to translate the Byron protocol state to the Shelley protocol state (PrtclState). This happens here: https://github.com/input-output-hk/ouroboros-network/blob/c1f65da121805cd3903915ab0ccad576554d3c68/ouroboros-consensus-cardano/src/Ouroboros/Consensus/Cardano/CanHardFork.hs#L446-L460
At the moment, we use the NeutralNonce for all four nonces.
Is this correct? The alternative is again to create a nonce from the hash of the Shelley genesis config file and use that for all four nonces, or just the first three (so not the "Prev epoch hash nonce"). Note that we don't have access to the last Byron hash as we don't track it in the PBftState. Access to the hash of the Shelley genesis config file is possible, as it is something static that we can store in our config data types.

Thank you for such a clear and organized question @mrBliss !
We can do the same thing for both a fresh Shelley chain and a chain from Byron. We should set "Current epoch nonce", "Evolving nonce", and "Candidate nonce" to the same value X, and the "Prev epoch hash nonce" to the NeutralNonce. I think we should set X to the hash of the Shelley genesis config file (I am confirming this with the cryptographers now, and will let you know).
For a bit of explanation:
At the start of an epoch, the "Current epoch nonce", "Evolving nonce", and "Candidate nonce" will always be the same value (equal to each other, not the same value between epochs :) ). The "Prev epoch hash nonce" does not matter at the start of the epoch, we just store this value so that when a new epoch begins we can use the hash of the last block in the previous epoch to create the next Current epoch nonce. In other words, the "Prev epoch hash nonce" will just be immediately overridden on the next block. So NeutralNonce is great.

Thank you for such a clear and organized question @mrBliss !
We can do the same thing for both a fresh Shelley chain and a chain from Byron. We should set "Current epoch nonce", "Evolving nonce", and "Candidate nonce" to the same value X, and the "Prev epoch hash nonce" to the NeutralNonce. I think we should set X to the hash of the Shelley genesis config file (I am confirming this with the cryptographers now, and will let you know).

Thank you for the clear answer! I'll start implementing this now (I can backtrack if the cryptographers disagree).

For a bit of explanation:
At the start of an epoch, the "Current epoch nonce", "Evolving nonce", and "Candidate nonce" will always be the same value (equal to each other, not the same value between epochs :) ). The "Prev epoch hash nonce" does not matter at the start of the epoch, we just store this value so that when a new epoch begins we can use the hash of the last block in the previous epoch to create the next Current epoch nonce. In other words, the "Prev epoch hash nonce" will just be immediately overridden on the next block. So NeutralNonce is great.

I see. The last part I remembered. Crystal clear now :+1:

I'm not sure if this is already supported by the above discussion, but the tests should be able to twiddle the initial Shelley nonce independently for the sake of statistical testing and similar. So it'd be good to parameterize the initial nonce selection at least out to the interface that testing should use.

I'm still awaiting a decision on how to compute the genesis hash in https://github.com/input-output-hk/cardano-ledger-specs/pull/1558#issuecomment-645213133.
However, I can already parameterise the code (ConsensusConfig for TPraos) over the initial nonce (prep for #2235). After a decision about the computation of the genesis hash is made, it will then just be a matter of passing the right nonce to the ConsensusConfig.

Quoting from https://github.com/input-output-hk/cardano-ledger-specs/issues/1531#issuecomment-648751584:

I had a discussion with @nc6 and we decided that it's best to just use the Nonce type directly for this, both in cardano-ledger-specs (to avoid confusion as Genesis(Config)Hash would not be related to the existing GenesisHash and genesis in any way) and in ouroboros-consensus (we just need a Nonce for entropy, we also don't care where it comes from). Only in cardano-node, where they have to provide that Nonce to consensus (via ProtocolInfo, is the choice made to use the hash of the Shelley genesis JSON file.


wrong link for pixel vision 8

Currently pixel vision 8 links to www.pixelvision8.com while it should link to https://pixelvision8.github.io/Website/

Updated, thanks!


[feature request] Quake style dropdown terminal

This is supported in terminals like CMDer and iTerm. Would be great to se this terminal support this feauture.

This is actually possible. Set Docking to Top and use the Toggle Window hotkey.

Additional question, is "smooth" drop-down implemented?

No, but feel free to open an issue for that


Fix issue of attachments with non latin names publishing (#446)

Please pay attention that this fix will cause of attachments re-uploading for all users of the plugin.

Regarding failing IT test publish_sameAttachmentsPublishedMultipleTimes_publishProcessDoesNotFail
My investigation results:
It fails with confluencepublisher/confluence-publisher-it:6.0.5 Don't know why. Manual uploading via browser preserve attachment name.

At the same time this test doesnt fail on my image qwazer/atlassian-sdk-confluence:latest based on confluence 7.20.3

Hi @qwazer, thank you for the adjustments, Regarding the failing test: I debugged locally and noticed that the charset of the multipart request for uploading the attachment data is not set explicitly to UTF-8. Doing so in HttpRequestFactory after line 340 (multipartEntityBuilder.setCharset(UTF_8);) fixes the issue locally with Confluence 6.0.5
Do you have the chance to adjust the code and push the changes to check if the build succeeds? Thank you!
Regarding the test: I would prefer if you could upload the attachment with non-ascii title in a separate test in the same class (e.g. publish_attachmentWithNonAsciiCharactersInTitle_uploadsAttachmentWithCorrectName()) instead of mixing it into an existing test. If you now see the test failure in the build, you get no hint on the test name level hat the failing test is related to the non-ascii attachment. Is this ok for you? Thank you!

Hi @cstettler . Fixed. In case of accepting the pull requests don't forget to squash commits =)

Thank you for your contribution @qwazer!


REST API Renderer

As we discussed early in issue #9 (I cannot reopen it), we have one thing left:
To render fields in the frontend SPA we need to access the field list from the Render like this:
public function renderStep(WizardStep $step, AbstractWizard $wizard, array $data = [] ): Response | Responsable | Renderable
    {
        return new JsonResponse([
            'wizard' => $wizard->summary(),
            'step' => $step,
            'fields' => $step->getFields(),
            'formData' => $data,
        ]);
    }

As you see we call a custom function getFields(). We only need this because the fields() function is protected.
Is there any chance to change that to public ?
https://github.com/laravel-arcanist/arcanist/blob/ecb3f51c5b63222f1c40d700218f09699f5b6f14/src/WizardStep.php#L91-94
I opened a PR (#17) to change it.

Thanks for the contribution. This change is part of the 0.5.0 release.


add gcc on archlinux

proof of concept here
closes https://github.com/pkgxdev/pantry/pull/4443

Released as v2.0.2


[fix][broker] Only send AuthChallenge when client supports it

Motivation
While reviewing the ServerCnx, I noticed the broker and client compatibility could have a missing edge case. In this case, the concept of multi-stage authentication was introduced with version 14 of the protocol by https://github.com/apache/pulsar/pull/3677. However, we send an AuthChallenge to the client without verifying it has a sufficient protocol version to support such a challenge.
This change is unlikely to fix any real issues because the AuthChallenge was introduced a while ago. However, I think we should add this logic to further support our claim that any version of the client can connect to any version of the broker.
Another reason we might choose not to merge this PR is that it's possible https://github.com/apache/pulsar/pull/3677 introduced mutual authentication in the client and the proxy at the same time, so this case isn't possible. My main response is that the protocol is an open spec, so we should use our versioning system to ensure that there isn't even a third party client library that receives protocol messages it is unable to handle.
Modifications

When an old client tries to connect using an authentication provider that generates an auth challenge, send an AuthenticationError and close the connection for both broker and proxy.
Only send the AuthChallenge that is triggered by authentication refresh when the client knows how to handle the AuthChallenge protocol message. This is arguably covered by the FeatureFlag, but given what our protocol versioning means, I think we should cover this unlikely edge case.

Verifying this change
Includes a test for ServerCnx and I created an issue for https://github.com/apache/pulsar/issues/19624 the proxy.
Does this pull request potentially affect one of the following parts:
This enforces the existing protocol.
Documentation

[x] doc-not-needed

This is part of the protocol spec.
Matching PR in forked repository
PR in forked repository: https://github.com/michaeljmarshall/pulsar/pull/32

I did not modify the ProxyClientCnx or the DirectProxyHandler logic because in both cases, the proxy only ever sends an AuthChallenge when the broker sends initiates one. Because we send the broker the minimum version of the proxy and the client, the proxy will not get this message unless running with an older version of the broker.
However, I think this is an edge case that this PR should cover, so I'll follow up with another commit tomorrow.

Since we will start the RC version of 3.0.0 on 2023-04-11, I will change the label/milestone of PR who have not been merged.

The PR of type feature is deferred to 3.1.0
The PR of type fix is deferred to 3.0.1

So drag this PR to 3.0.1


Allow building sdist and wheel with different files

Poetry has an include setting in pyproject.toml that allows specifying additional files to be included in the distribution (e.g. tests, docs, config files). This works, but it seems what you specify here will be included in both the source distribution and the wheel.
A common practice is to put stuff like tests into the source distribution only, but not into the wheel. You can achieve this with distutils by putting this additional stuff into MANIFEST.in which will be used only for the source distribution. I currently see no way to achieve the same with poetry. Can this be added as a feature? Or am I overlooking something?

Like I said in #1109, I plan on making the packages section of the pyproject.toml file support specifying the format for which the package should be included (no format meaning all of them).
[tool.poetry]
# ...
packages = [
    { include = "my_package" },
    { include = "tests", format = "sdist" },
]

This has been added in #1133


Rationalize solutions/mitigations throughout

Have a master list of solutions
Have a way to merge solutions in a non conflicting way
Move away from wiki fully
Each solution should have its type "quick mitigation" or "troubleshooting" so that UI can display it properly

Started working on this.
for 1), we have a master list of solutions but there is missing type field which suggests "Quick solution" or "Deeper Investigation"
for 2), I am still thinking that we can start with merging all solutions and then start resolving the conflicts when they are reported. Probably a UI play to make them sound non-conflicting. Open for thoughts
for 3), You mean solutions in github, right? Wiki should still be there. No?

is covered as part of 1)


Set readiness status for managed features

Signed-off-by: Masudur Rahman<EMAIL_ADDRESS>

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: masudur-rahman:x: kodiakhq[bot]You have signed the CLA already but the status is still pending? Let us recheck it.


Fix split barriers leaking during disjoint layout processing

Summary
This commit fixes an issue in the disjoint layout processing caused by a shared reference from the input dag to a layout pass to the internal transformations the layout processing performs. As part of the disjoint layout processing the input dag needs to be split into smaller dags for each connected component in the circuit. To enable this any barriers present in the circuit need to be split up prior to analyzing the connected components in the dag. A multiqubit barrier doesn't represent a real connectivity requirement so they need to be split prior to analysis to ensure they don't factor into the connected component computation. To faciliate not losing the semantic meaning of the barrier for the layout analysis of each connected component, the barrier split is done by first taking an n-qubit barrier and converting it into n parallel 1q barriers with a uuid label applied to it. Then after we split the circuit into the separate connected components the uuid is used to identify any components of the same barrier and combine them together.
There were two issues with this approach the first is that the splitting of the barriers was done on the input dag without copying first. This causes the input dag to be modified and because in most cases it's a shared instance which would leak out the barrier splitting if the input dag was returned verbatim from the pass, which in most cases it would be. This issue is fixed by ensuring that we re-combine any split barriers after we've split the dag into it's connected components. The second issue is the uuid label assignment would overwrite any existing labels on barriers. While setting labels on barriers is uncommon for users to do (but still completely valid) this is causing a bigger issues since #10323 because the transpiler is assigning labels to barriers it creates internally so they can be removed before the circuit is returned. This is also fixed in this commit by appending a uuid to the existing label instead of overwriting it, so we're able to restore the original label when we recombine barriers.
Details and comments
Fixes #11649

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

-1 of 12 (91.67%)  changed or added relevant lines in 1 file are covered.
6 unchanged lines in 2 files lost coverage.
Overall coverage increased (+0.02%) to 89.56%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit/transpiler/passes/layout/disjoint_utils.py
11
12
91.67%

Files with Coverage Reduction
New Missed Lines
%

qiskit/transpiler/passes/layout/disjoint_utils.py
1
96.83%

crates/qasm2/src/lex.rs
5
92.19%

Totals

Change from base Build<PHONE_NUMBER>:
0.02%

Covered Lines:
59598

Relevant Lines:
66545

💛  - Coveralls

I'm on the fence of whether this should be in the changelog and release note or not. The specific bug of leaking UUID labels is only on main for 1.0.0. On 0.45.x we still leaked the split barriers into the output, but the labels were stripped, while weird it was valid and wouldn't cause any issues. The barriers generated during transpile was expected in qiskit < 1.0.0 because we hadn't introduced https://github.com/Qiskit/qiskit/pull/10323 yet.


⚠ ClamAV has degraded performance

In e04e883, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 222 ms

Resolved: ClamAV performance has improved in 33a8488.


Fix to Bloom Open Graph Metadata preview

Issue : https://github.com/chaynHQ/bloom-frontend/issues/946
What changes did you make?
Fixed the OpenGraphmetadata component to get meta tags in the DOM

Hi @anmol-fzr , Thanks for your contribution! Did you have a screen shot to show this worked? Thanks!

Hi @anmol-fzr , Thanks for your work. It's finally loading the text which is great. I deployed your branch but I don't think the image is rendering. Could you have a quick look and see if you can debug!

@eleanorreem
You can use this chrome extension to check Social Share Preview

Okay brilliant. Thanks @anmol-fzr. Thats a great tip!

@kyleecodes Fixed the aspect-ratio issue for the og:image meta tag at PR https://github.com/chaynHQ/bloom-frontend/pull/998


2023 python version bump

drop support for python 3.7

add support for python 3.12

bumps version of more-itertools

note: the latest version of more-itertools does not support 3.12 yet, but dev does. This is not suitable for publishing until a more-itertools update is produced

look for updates here: https://pypi.org/project/more-itertools/10.1.0/

supported as of 10.2.0


Fibonacci Formula

Fibonacci Formula program in Java.
Fixes #93

Please merge this PR under Hacktoberfest Label!

@aniket-24  closing the pr you have already done 3 pr , only 2 pr per day, contribute to other repo-https://github.com/avinash201199/Hacktoberfest-Guide


feat: add richest wallets page

:tada: This PR is included in version 1.7.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


fix: M3-1799 Unable to unshare an IP address.

Description
It was found users were unable to "unshare" an IP address. This was a result of services validation not allowing an empty array to be sent in lieu of an array of IP address.
Type of Change

fix

If the any above types of change apply to this pull request, please ensure to include one of the listed keywords in the pull request title.
Note to Reviewers
Linode -> Networking -> Networking Actions -> IP Sharing.
Share and IP from another Linode, then remove, reload, verify.
💥

Coverage remained the same at 32.176% when pulling de754ef0f87165ac1310d779e64b161232ffbde4 on rjstires:M3-1799 into 1f29fb872a0ec8c8a493cb84056a04a39507d600 on linode:develop.

No error handling exists when you

Enable network blocking
Remove IP Address
Submit the form

It might be out of scope of this PR, but I think this might as well be part of it

one more thing - we need to clear the success state on the .catch, so that the notice properly displays the error.
To solve for the following scenario

Successfully share an IP
Turn on request blocking
Remove an IP and save
Success message lingers and no error appears


feat: oonifindings service

Create oonifindings service with clickhouse support
Closes #814

I'll be rebasing this and pushing a new diff since we want to separate the pytest plugin work from the service


Support for CloudFormation Condition

Any change we can add support for CFN condition?
Something like...
lambdaAtEdge:
  - distribution: WebsiteDistribution
    eventType: origin-response
    condition: isDev
...
Conditions:
    isDev: {"Fn::Equals" : ["${self:custom.vars.STAGE}", "dev"]}

so that when the function is created it will place that condition on the Association and the function itself.
I'm happy to put a PR in if that sounds good.

Hmmm. I struggle to see why someone would want to deploy one stage differently - especially without the function or its association - than other stages. But, that's probably my OCD - I want absolute parity between dev, qa, prd. I'd like to hear more about your usecase.
All that said, I'm not fundamentally against adding this support if you wanted to submit a PR and have some easy-to-understand usecase. In your PR don't forget to update the docs (README) accordingly.

@jthomerson Well the question is larger. Why would anyone want to use CFN conditions at all?
The reason we use them is to do things like

Add a WAF to the CDN in dev only
Not add a Lambda@Edge for dev (since dev doesn't even use a CDN)

Some of our applications are 99% frontend JS, HTML, CSS hosted statically. so 99% of what needs to be tested is the visual site itself. We sometimes use a CDN in prod for these to handle the URL rewrites for the routes.
Since provisioning a CDN takes 30mins+ we decided to go with Speed over Parity. We can deploy a site without a CDN in 2mins. This makes deploying feat-* branch tests VERY fast.
The parity comes later in the pipe before prod.

Thanks for the clear explanation. Looking forward to the PR

Any news?


[HUDI-1860] Add INSERT_OVERWRITE and INSERT_OVERWRITE_TABLE support to DeltaStreamer

What is the purpose of the pull request
Add INSERT_OVERWRITE and INSERT_OVERWRITE_TABLE support to DeltaStreamer
Brief change log

Added support for INSERT_OVERWRITE in HoodieDeltaStreamer.
add new method insertOverwrite in AbstractHoodieWriteClient.
provide implementation to the added method in HoodieJavaWriteClient and SparkRDDWriteClient which overwrites the abstract class AbstractHoodieWriteClient.

Verify this pull request
This change added tests and can be verified as follows:

Added unit tests for insertOverwrite
Added unit tests for insertOverwriteTable

Committer checklist

[x] Has a corresponding JIRA in PR title & commit

[x] Commit message is descriptive of the change

[x] CI is green

[x] Necessary doc changes done or have another open PR

[x] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

Update :-  Working on writing the tests for insert_overwrite .

Codecov Report

Merging #3184 (14ddcc5) into master (039aeb6) will decrease coverage by 43.09%.
The diff coverage is 0.00%.

@@             Coverage Diff              @@
##             master   #3184       +/-   ##
============================================
- Coverage     46.16%   3.07%   -43.10%
+ Complexity     5370      82     -5288
============================================
  Files           921     280      -641
  Lines         39953   10877    -29076
  Branches       4288    1106     -3182
============================================
- Hits          18444     334    -18110
+ Misses        19630   10517     -9113
+ Partials       1879      26     -1853

Flag
Coverage Δ

hudicli
?

hudiclient
0.00% <ø> (-30.47%)
:arrow_down:

hudicommon
?

hudiflink
?

hudihadoopmr
?

hudisparkdatasource
?

hudisync
5.38% <ø> (-48.67%)
:arrow_down:

huditimelineservice
?

hudiutilities
9.45% <0.00%> (-48.99%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

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

@hudi-bot run azure

@codope
I have added the tests for both INSER_OVERWRITE and INSERT_OVERWRITE_TABLE .
please review ^

@codope please let me know when you have reviewed again
@nsivabalan can then make a final pass to land.

@hudi-bot run travis
@hudi-bot run azure

@vinothchandar
please review

Can you fix "How did you verify the Pull Request" section in the desc.

thanks, I guess it would be easier w/ writeClient test, but w/ delta streamer it might be hard to get this done. Anyways, will land this in.

@nsivabalan
FYI ,
Two follow up tickets I have started working

created tasks for delete_partition support in deltaStreamer
https://issues.apache.org/jira/browse/HUDI-2189
will write the test for the writeClient
https://issues.apache.org/jira/browse/HUDI-2188

Hey, can you confirm you rebased it w/ upstream master correctly? I see lot of commit msgs while trying to squash and merge?

Hey, can you confirm you rebased it w/ upstream master correctly? I see lot of commit msgs while trying to squash and merge?

@nsivabalan rebased it correctly there are only changes related to intended changes in the pr.


update for laravel 11

This PR updates dependencies for Laravel 11 and php 8.3 and contextually the GH Action that runs the tests

Closing this in favour of #58 of course :)


CMake cannot find "Eigen3"

OS: Windows 10
Compiler: Anaconda
Python Version: 3.9.7
Even though the raisim installation folder is set by CMAKE_PREFIX_PATH, CMAKE cannot find the Eign3 library, so the installation does not proceed. I am getting the following error, is there any solution?
CMake Error at CMakeLists.txt:28 (find_package):
Could not find a package configuration file provided by "Eigen3" with any
of the following names:
Eigen3Config.cmake
eigen3-config.cmake

Add the installation prefix of "Eigen3" to CMAKE_PREFIX_PATH or set
"Eigen3_DIR" to a directory containing one of the above files.  If "Eigen3"
provides a separate development package or SDK, be sure it has been
installed.

I pushed a fix. can you pull and try again?

After applying the fix you posted, the error code changed to:
CMake Error at CMakeLists.txt:71 (find_package):
Could not find a package configuration file provided by "raisim" with any
of the following names:
raisimConfig.cmake
raisim-config.cmake

Add the installation prefix of "raisim" to CMAKE_PREFIX_PATH or set
"raisim_DIR" to a directory containing one of the above files.  If "raisim"
provides a separate development package or SDK, be sure it has been
installed.

if you are using windows, pull raisim again. Then pass in the "raisimLib/raisim/win32" path to CMAKE_PREFIX_PATH. I'll talk about it in class as well


Add Latitude and Longitude type

Latitude degree
Longitude degree

Could also be merged into a float tuple

What do you think about geopy for that @yezz123 ? It seems like a reasonable lib for doing that, or should we keep it simpler by coding it ouselves ?

best to keep it simple if possible, see #74.

Thanks @samuelcolvin, I'll check that.

To give some more meat on the bone here:

Latitude is Northing from -90.0 to 90.0 degree.
Longitude is Easting from -180.0 to 180.0 degree. Definitions from 0.0 to 360.0 degree have to be normalized to -180. to 180 degree.

Latitude degree

Longitude degree

Could also be merged into a float tuple

If precision is important, I'd recommend using Decimal instead of float.
This speaks to the concern:
https://docs.python.org/3/tutorial/floatingpoint.html
With the example:
>>> 0.1
0.1000000000000000055511151231257827021181583404541015625

A float is absolutely sufficient, there is no need to go to Decimals
See https://xkcd.com/2170/


Update writing-a-blog-post.md

General editing and added editorial guidelines around structuring posts and content ideas.

This started off as more of a step-by-step guide (https://docs.google.com/document/d/13GO3bg1BwBm4skkf4Kat1JcLLOP1c_OJt6OA1MD5eW8/edit#) but morphed into more of a blog post itself. Open to changing it back if it works better!


Server crashing after adding just your mod.

Forge 2709
Issue.txt
Let me know if you need anything else.

Could you provide a full version of the crash report?

I have the same problem.
crash-2018-06-22_01.49.56-server.txt
attached the crash report

@Jack-0-Spades I will look into it. Thanks!

Why Close

@OldManCraft A fix has been uploaded but is still under review.

Could you let us know when the fix is live?

The fix is out
Tom

On Jun 23, 2018, at 2:41 PM, Jack-0-Spades<EMAIL_ADDRESS>wrote:
Could you let us know when the fix is live?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Thanks


Add a facility to skip running some test suites

Add a facility to skip running some test suites. The skipped test suites are built, but not executed. This is implemented for both make and cmake.
The intended goal is to configure CI jobs to skip the timing test suite when we know that the machine where it would be executed is overloaded and tends to fail these tests.
I noticed that one test suite was missing from cmake so I fixed that.
This is a rebase of #2244 which was on top of 2.14 and had been approved but has merge conflicts now.
Backports: #2255, #2256. This PR or a backport needs to be merged in every branch that we want to run the CI on.

This PR can be merged with mbedtls-2.16 and development and a PR exists for mbedtls-2.7 so removing the label for 'needs: backports'.
This PR has also been reviewed, approved and is passing CI, so marking as 'ready for merge'.


Implementing Prefetch for a given Queue using AsyncConsumer

Hi there, it's been quite fun to work with your library. Currently, I started wondering if it's possible to use prefetch for a queue that uses basic_consume.
I've tried something along the lines:
       my_channel.basic_qos(
            BasicQosArguments::new(
                0,0,false
            )
        );
        my_channel.channel
            .basic_consume(callback, args)
            .await
            .unwrap();

For this do I need to implement the Blocking consumer instead?
Kind regards,
Dave.

There is no such concept as a "queue prefetch" in the protocol. There is one per consumer but the recommendation from the RabbitMQ team is to use separate channels and the standard prefetch.
At least unless you need a lot of consumers (almost no one ever does).

Please use Discussions for questions, they are no longer a new and unknown GitHub feature.


Osi grpc comm

Feature Request
Adding new module osi_grpc_communication_module.
Description

The module provides a standardized interface to connect CARLA with third party tools.
Module uses the gRPC (google remote procedure call) to send the groundtruth measurement data of the host_vehicle and the non_player_agents (vehicles) with OSI standardization (Open Simulation Interface) at every frame in the episode.
All the proto_to_python generated files are present with the module. they can be readily used for the compilation and working.
the origional .proto files are also present for the manipulaiton and advancement.
osi_grpc.proto is used to generate the .py version of the request with protoc and a special gRPC plugin

Where has this been tested?
Platform(s):
Windows 10 x64
Python version(s):
Python 3.6
Unreal Engine version(s):
UE 4.18.3
- CARLA version(s):
0.8.4

This change is

PythonClient/osi_grpc_communication_module.py, line 36 at r1 (raw file):
Previously, nsubiron (Néstor Subirón) wrote…
Unused variables are commonly named _ in Python, I believe that silences the pylint warning. --> for _ in range(...):
Thought, in this particular case you don't event need the loop as number_of_episodes = 1.

i specifically made number_of_episodes =1 so that if required, only a small change is needed to be made otherwise everything is written.. no need to make changes in the code. for the simplest simulation it could be set to 1

PythonClient/osi_grpc_communication_module.py, line 73 at r1 (raw file):
Previously, nsubiron (Néstor Subirón) wrote…
map_name was introduced in 0.8.3, not yet available in the stable 0.8.2.

ok.. but as i have used carla 0.8.4 and mentioned also in the description. would that be affected in anyway?

PythonClient/test_server.py, line 1 at r1 (raw file):
Previously, nsubiron (Néstor Subirón) wrote…
What's the purpose of this script? some small documentation would be nice. Also, if it's just for testing consider adding it to the "test" folder.

i will fix it.. and This test_server.py is for testing the osi_grpc_communication_module.py to check the groundtruth data from carla at runtime.. i can move it to the "test" folder also..

PythonClient/proto/osi_grpc.proto, line 1 at r1 (raw file):
Previously, nsubiron (Néstor Subirón) wrote…
I think this file fits better in the "Proto" folder with "carla_server.proto" and built with our scripts.

if i move it to the "Proto" folder... do i have to make some configuration changes or will it be automatically built with your scripts?

PythonClient/test_server.py, line 1 at r1 (raw file):
Previously, mshaheerm wrote…
i will fix it.. and This test_server.py is for testing the osi_grpc_communication_module.py to check the groundtruth data from carla at runtime.. i can move it to the "test" folder also..

the from concurrent import futures is required to create the grpc server.

PythonClient/osi_grpc_communication_module.py, line 73 at r1 (raw file):
Previously, mshaheerm wrote…
ok.. but as i have used carla 0.8.4 and mentioned also in the description. would that be affected in anyway?

fixed.. will commit the changes.  with all of the others you requested.

a discussion (no related file):
Previously, nsubiron (Néstor Subirón) wrote…
Some short document showing how to use it would be nice.

So providing the licence within the folder osi3 is enough? no need to remove the protos and generated?

PythonClient/proto/osi_grpc.proto, line 1 at r1 (raw file):
Previously, nsubiron (Néstor Subirón) wrote…
It needs to be added to Protoc.sh and Protoc.bat, then it will be integrated in our build system.

ok.. i ll do it..

i have made all the requested changes please have a look at it.


【1.1.15】matrix report update

What is the purpose of the change
Matrix reporting information optimization
Related issues/PRs
Related issues: #4888
Brief change log

Define the core abstraction and interfaces of the EngineConn Factory;
Define the core abstraction and interfaces of Executor Manager.

Checklist

[x] I have read the Contributing Guidelines on pull requests.
[ ] I have explained the need for this PR and the problem it solves
[ ] I have explained the changes or the new features added to this PR
[ ] I have added tests corresponding to this change
[ ] I have updated the documentation to reflect this change
[ ] I have verified that this change is backward compatible (If not, please discuss on the Linkis mailing list first)
[ ] If this is a code change: I have written unit tests to fully verify the new behavior.

这个方案调整为状态判断的优化

Johannwang completed this requirement

Johannwang completed this requirement, so I closed it


Add tensor->indarray

@jeremy-lc thanks for pointing this out, I should have performed a better review before the merge.
@ghosthamlet the shape fn from core.matrix does not seem to fit your fn.  There is also a shape ND4J class but your fn doesn't perform any checking to make sure its an INDArray being passed to shape.  I am going to revert the merge until you can supply the shape fn and associated tests for tensor->indarray. Thanks

@FeLungs sorry for the trouble. Fixed it and added test #11


update postgres instance auth during builds

Confession: I haven't used Travis at all in my deployment of Lemur, but I've noticed that we frequently get errors like this for the python3.7-postgresql-12-bionic builds:
psql: error: FATAL:  Peer authentication failed for user "postgres"
The command "psql -c "create database lemur;" -U postgres" failed and exited with 2 during .

It seems to only affect Postgres 12?
I have no idea if this suggested fix will work or not, but I figured I could make a PR to see what happens when we try changing local Postgres auth to trusted mode 🤷

It seems to have worked in this build. I'm not sure how we would go about testing, though, since the build errors seem to be happen sporadically.


Add differential fuzzing against wasmi (a Wasm interpreter).

This PR adds a new fuzz target, differential_wasmi, that runs a
Cranelift-based Wasm backend alongside a simple third-party Wasm
interpeter crate (wasmi).  The fuzzing runs the first function in a
given module to completion on each side, and then diffs the return value
and linear memory contents.
This strategy should provide end-to-end coverage including both the Wasm
translation to CLIF (which has seen some subtle and scary bugs at
times), the lowering from CLIF to VCode, the register allocation, and
the final code emission.

Updated, thanks!
It turns out that wasmi doesn't canonicalize NaNs (paritytech/wasmi#19) so I've disabled fuzzing of modules with FP ops for now. If it seems worthwhile, we can add a Config option to wasm-smith for that too, but fuzzing seems to be getting coverage pretty efficiently right now as I watch it run.
This fails the "publish" check because it's using a crate-source patch in the root Cargo.toml for wasm-smith; @fitzgen, would you mind publishing a new version to crates.io?

This fails the "publish" check because it's using a crate-source patch in the root Cargo.toml for wasm-smith; @fitzgen, would you mind publishing a new version to crates.io?

Sure thing.

Done!

Thanks! Updated.
I also just added an experimental_x64 feature flag to the fuzz crate so that we can fuzz the new backend.


Update README.md for Issue #17

Thanks @ChienKaiMa , looks good!
I will merge this on Monday, we are updating all files with an update for 0.40 and I don't want to change anything during the code freeze.
@TomerGoldfriend , @orsa-classiq - FYI regarding PR's during the code freeze

Hi @ChienKaiMa - merged successfully! Thanks for raising this 🙌


Mapper: Support nested types with conversion

Support serialization and deserialization of collections with conversion

Fixed the issue around method names:, ie:ConvertIEnumerableToDbType.


Support for OSX Catalina

Hello.
Could you add support for Mac OS Catalina ?

@andreifilip123 I will add support as soon as the stable version of Catalina is officially released. I will keep this issue open until I do so.

@andreifilip123 I just wanted to let you know that I have upgraded my Mac, and have started work on adding Catalina support to Play Song. You can download the Beta version on my catalina branch:
https://github.com/caleb531/play-song/blob/catalina/Play Song - Catalina (Alfred 4).alfredworkflow

I'll wait for the Alfred 3 workflow. Thanks tho :)

@andreifilip123 Sorry to say, but the Catalina version of the workflow will only support Alfred 4. However, if you'd like, I can show you what changes you'd need to make to get your Alfred 3 version  of the workflow functional.
If you can export the Play Song workflow you currently have installed, and send it to me, I can send you back a custom version which supports Catalina.

Play Song.zip

Thanks 👍

@andreifilip123 Alright, give this a shot. All the necessary code changes have been made, though I wasn't able to test it since I don't have Alfred 3 installed any longer.
Play Song.alfredworkflow.zip
Please let me know how this works for you.

It doesn't seem to work. I can't import this. Thanks for the effort.

@andreifilip123 Don't fret, I've given it another try—the import should be functional now. Please try the below version.
PlaySong.alfredworkflow.zip

It works !!
Thanks a lot, man ! 👍 Really appreciate your efforts with this workflow. Thanks !

Thanks for the Catalina update @caleb531  👏!


iconSize ignored when using startIconUrl

...same applies to other options, same applies to endIconUrl.
To reproduce, create a new L.GPX with the option iconSize: [330, 500] - the markers now should be huge.
The problem seems to be that
        icon: options.marker_options.startIcon || new L.GPXTrackIcon({iconUrl: options.marker_options.startIconUrl})

only takes into consideration the Url, but not the other default parameters. I could fix it by replacing it with this:
        icon: options.marker_options.startIcon || new L.GPXTrackIcon(
          this._merge_objs(
            options.marker_options,
            {iconUrl: options.marker_options.startIconUrl})
        )

(but I am not sure if this is the right way to do. Also for endIcon it needs to be adapted as well)

Are you sure you're passing iconSize in the right place? I just tried to reproduce your issue and the icon size is correctly applied when used along startIconUrl.
Note that the iconSize needs to be passed under marker_options in the options object:
        new L.GPX(url, {
          async: true,
          marker_options: {
            startIconUrl: 'pin-icon-start.png',
            endIconUrl:   'pin-icon-end.png',
            shadowUrl:    'pin-shadow.png',
            iconSize:     [16, 22],
          },
        }).on('loaded', function(e) {
          // ...
        });

Feel free to re-open if that still doesn't do it.


Tabs are created in the activity but should be handled in the bar class

Just for the clarification, are you suggesting to handle the creation of ETabs in the EngorgioBottomBar class itself. And pass the icons,color and title of the tab to the BottomBar class itself? Could you please elaborate what positive effect would applying such a change would bring.

Positive effects are mostly that you encapsulate the creation of tabs, so any change in the tab model itself wouldn't affect users of the library since you'll be handling the creation internally.
Not saying your approach is bad, just that it isn't very scalable. I suggest you keep this approach for extensibility if wanted, but also create a method which internally creates tabs and adds them to an internally handled tabs array.


Duplicate warnings when multiple target frameworks

If you have multiple target frameworks, you will have duplicate warnings
Is there a way to prevent this?
Thanks for your work

This is caused by VS. I once read it was supposed to be fixed in VS2022 but I still see it.

Ops, yes, I'm using vs2019
Thanks for the replay


gradle 3.5.3 -> 3.6.1

Signed-off-by: Manuel Stahl<EMAIL_ADDRESS>Pull Request Checklist

[x] Changes has been tested on an Android device or Android emulator with API 16
[ ] UI change has been tested on both light and dark themes
[x] Pull request is based on the develop branch
[x] Pull request updates CHANGES.rst
[ ] Pull request includes screenshots or videos if containing UI changes
[x] Pull request includes a sign off

See also https://github.com/matrix-org/matrix-android-sdk/pull/532


az webapp config appsettings set fails with error No module named 'decorator'

This is autogenerated. Please review and update as needed.
Describe the bug
Command Name
az webapp config appsettings set
Errors:
No module named 'decorator'
Traceback (most recent call last):
python3/dist-packages/fabric/connection.py, ln 5, in <module>
    from invoke.vendor.six import StringIO
ModuleNotFoundError: No module named 'invoke.vendor.six'

...

python3/dist-packages/fabric/connection.py, ln 10, in <module>
    from decorator import decorator
ModuleNotFoundError: No module named 'decorator'

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az webapp config appsettings set --name {} --resource-group {} --settings {} {}

Expected Behavior
Environment Summary
Linux-5.4.0-113-generic-x86_64-with-glibc2.29
Python 3.8.10
Shell: bash

azure-cli 2.0.81

Extensions:
azure-devops 0.17.0

Additional Context

route to CXP team

@UQRakesh
Thanks for the feedback! We are currently investigating and will update you shortly.

Hello @UQRakesh Could you please try one more time and do let us know if the issue still persists?

We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.
Please also do visit Microsoft Q&A the home for technical questions and answers at Microsoft.


Cookbook breaks in Chef < 13 because of apt cookbook dependency

Expected Behavior
Cookbook should run on Chef version 12 and lower.
Current Behavior
Compiling Cookbooks...

================================================================================
Recipe Compile Error in /var/chef/cache/cookbooks/altmetric-sensu/recipes/client.rb
================================================================================

NoMethodError
-------------
No resource or method named `apt_preference' for `Chef::Recipe "_linux"'

Cookbook Trace:
---------------
  /var/chef/cache/cookbooks/sensu/recipes/_linux.rb:35:in `from_file'
  /var/chef/cache/cookbooks/sensu/recipes/default.rb:34:in `from_file'
  /var/chef/cache/cookbooks/altmetric-sensu/recipes/client.rb:10:in `from_file'

Relevant File Content:
----------------------
/var/chef/cache/cookbooks/sensu/recipes/_linux.rb:

 28:      key node['sensu']['apt_key_url']
 29:      distribution node["sensu"]["apt_repo_codename"] || node["lsb"]["codename"]
 30:      components node["sensu"]["use_unstable_repo"] ? ["unstable"] : ["main"]
 31:      action :add
 32:      only_if { node["sensu"]["add_repo"] }
 33:    end
 34:
 35>>   apt_preference "sensu" do
 36:      pin "version #{node['sensu']['version']}"
 37:      pin_priority "700"
 38:    end
 39:
 40:    package_options = '--force-yes -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confnew"'
 41:
 42:    package "sensu" do
 43:      version node["sensu"]["version"]
 44:      options package_options

System Info:
------------
chef_version=12.21.31

Possible Solution
Problematic because Chef doesn't support multiple version constraints, but ideally apt dependency needs to be pinned to < 7.0 where they have removed the apt_preference method completely and became Chef 13.3 exclusive.
Steps to Reproduce (for bugs)
Run the sensu default recipe on any Chef install < 13.3
Context
Breaks cookbook functionality completely.
Your Environment
System Info:
------------
chef_version=12.21.31
platform=ubuntu
platform_version=16.04
ruby=ruby 2.3.5p376 (2017-09-14 revision 59905) [x86_64-linux]
program_name=chef-client worker: ppid=23768;start=15:29:56;
executable=/opt/chef/bin/chef-client

Chef 12 is officially end of life at this point since Chef 14 shipped. You're going to see a large part of the Chef ecosystem begin to drop support for Chef 12. If you still want to continue to use it you'll need to pin apt on your own. It's pretty easy to do this either in your environment or in a wrapper cookbook, but that's really outside the scope of this cookbook. Pinning here would just break users of currently supported Chef releases who wanted to pull down the latest cookbooks.

That's fair enough, but the Readme should be in any case updated to reflect that this cookbook doesn't support Chef 12 anymore and is Chef 13+. We've pinned the apt cookbook for now and we're in the process of moving to 14 anyway, but this was still a pretty sudden break.

Updating your metadata.rb to reflect this dependency would be a start. The master branch still says chef_version '>= 12.14'.
Also, despite pinning an older version of this cookbook (4.0.6), presumably before you dropped support for Chef 12, I still ran into this issue. It only worked when I manually pinned all of my dependencies to known good versions.
If you're saying that NO versions of this cookbook work on Chef 12 any more, that's one thing, but if older versions are still supposed to work on 12 and they're not that's still an issue. Suddenly breaking and then telling people to pin their apt cookbook manually is pretty crappy. You should be responsible for pinning the right versions of your dependencies in your metadata.rb for each cookbook version. And >= is not good enough.

@tas50 this should work on chef 12.14 from what I recall in #608 is that not the case? If not then we need to either update the metadata or revert.

Confirmed that apt_preference did not exist before 13.3 here so the question is rollback or update it and say we support chef 13.3 >=.

If you're saying that NO versions of this cookbook work on Chef 12 any more, that's one thing, but if older versions are still supposed to work on 12 and they're not that's still an issue. Suddenly breaking and then telling people to pin their apt cookbook manually is pretty crappy. You should be responsible for pinning the right versions of your dependencies in your metadata.rb for each cookbook version. And >= is not good enough.

I wholeheartedly agree and had I known at the time that we need at least chef 13.3 I would have pushed back on the changes. What's done is done and there is no sense crying over spilled milk, I am very conflicted on the best course of action at this point is. As the intent of the PR was to bring the community back up to speed with changes and chef 12 is EOL (will never receive another update) and the change was made in a major release (indicating breaking changes which were properly called out in the CHANGELOG) I don't think we should revert it. I think we should update the chef metadata.rb to indicate the versions we support and I agree that we should have pinned the apt cookbook (as well as many others) to at least a major version using pessimistic version constraints. Not using >= comes with its fair share of problems as well (such as not supporting new major versions of chef-client or cookbooks before we have had time to test it) so no matter what someone is affected by the choices we make as far as pinning versions. If someone would like to submit a PR to fix this up it would be greatly appreciated otherwise I can submit a fix this week. If there is enough disagreement on this being the right path forward what we could do is add the requirement for apt back in and would allow us to work with any chef 13.x (not forcing 13.3+ which has everything but apt_preferences) but I guess if you have already upgraded from 12 -> 13 an upgrade to >= 13.3 will not be too painful so I am not sure if that really helps anyone out but is an option to soften the impact.

As I have not heard anyone stating that we should roll back I have created the above PR to fix this. after it has been reviewed and merged I will release and link to it here.

released: https://supermarket.chef.io/cookbooks/sensu/versions/5.1.2

what are the changes need to upgrade chef 12 to chef14 . could you please give me the how can i check the modifications manually,

@ajaydevops2019 its not quite a straightforward answer as it depends on what cookbooks you are using but here are some good materials to help you get started:

https://docs.chef.io/upgrade_client.html
https://docs.chef.io/release_notes.html
https://blog.chef.io/2017/03/29/upgrading-chef-client-13
https://blog.chef.io/2018/02/16/preparing-for-chef-14-and-chef-12-end-of-life

hi
What are the changes needed for upgrade chef14
On Sat, 16 Feb 2019, 10:55 pm Ben Abrams<EMAIL_ADDRESS>wrote:

@ajaydevops2019 https://github.com/ajaydevops2019 its not quite a
straightforward answer as it depends on what cookbooks you are using but
here are some good materials to help you get started:

https://docs.chef.io/upgrade_client.html
https://docs.chef.io/release_notes.html
https://blog.chef.io/2017/03/29/upgrading-chef-client-13

https://blog.chef.io/2018/02/16/preparing-for-chef-14-and-chef-12-end-of-life
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sensu/sensu-chef/issues/605#issuecomment-464364907,
or mute the thread
https://github.com/notifications/unsubscribe-auth/As14SnNrb2mgAzKYOTPgw9nnzLlpG0VUks5vOD8fgaJpZM4TMl3d
.

@ajaydevops2019 I am not sure what to say, since I don't have access to your codebase I have no idea what you need to do. I linked you to generic resources to help you determine that for yourself. If that is not enough I suggest your company engage in some chef professional services or hire a contractor to assist your team. In the meantime you can pin the version of your cookbook to 4.4.0 as this was the last version of this cookbook to support chef 12. As chef dropped 12.x support on April 30, 2018 it is highly unlikely that we will release any further 4.x changes, the only changes I might see us backporting are any security issues with the chef code itself.


yarn dev get error with window is not defined

Bug report
window is not defined
ReferenceError: window is not defined

Describe the bug
Every time that I try to build my application I have this error.
Basically, the code is complaining about it:
const isLocalhost = Boolean(
  **window**.location.hostname === 'localhost' ||
    // [::1] is the IPv6 localhost address.
    **window**.location.hostname === '[::1]' ||
    // <IP_ADDRESS>/8 is considered localhost for IPv4.
    **window**.location.hostname.match(
      /^127(?:\.(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){3}$/
    )
);

I know that if is not in the browser, we do not have DOM. But anyway. I didn't create this project. I was running this project with my normal REACT application, and Now I'm converting to Next.JS
Before, was working?
Yes.
Expected behavior
Run NextJS

i think this wiki FAQ section can help you -> I use a library which throws window is undefined

@ozipi ... I had seen this post before. But unfortunately do not solve my issue.
I know the reason, but I wasnt expect this error.
If you create a Next front zero, for instance, you do not need need of this: serverWorker file, for instance.
so I expect that Next.Js can handle this file or give me another suggestion to work around, what I should do with this file.

Sounds like you have code in the global scope, which causes issues on it's own even in the app that you currently have. The solution would be to move it to componentDidMount or useEffect.
https://twitter.com/timneutkens/status/1124969466037776385


Merge separated leaderboards

Currently, each leaderboard is stored in its own table. It's simpler to store them in one table with the region being the primary key.

Turns out it's not that simple to implement. I saved my failed attempt locally, closing this issue for now


Added a ButtonComponent

Description
Since we have a HudButtonComponent I'm adding this one for consistency.
If you haven't used the HudButtonComponent it is simply two PositionComponents, one that shows when the button is pressed and one that shows otherwise.
https://user-images.githubusercontent.com/744771/143618565-4e4df42a-4fed-4248-9a6d-770151386d66.mp4
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] My PR includes unit or integration tests for all changed/updated/fixed behaviors and are passing (See Contributor Guide).
[x] My PR does not decrease the code coverage, or I have a very special case and explained on the PR description why this PR decreases the coverage.
[x] I updated/added relevant documentation (doc comments with ///) and updated/added examples in doc/examples.
[x] I have formatted my code with flutter format and the flutter analyze does not report any problems.
[x] I read and followed the Flame Style Guide.
[x] I have added a description of the change under [next] in CHANGELOG.md.
[x] I removed the Draft status, by clicking on the Ready for review button in this PR.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require Flame users to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md).
[x] No, this is not a breaking change.

Related Issues
Replace this paragraph with a list of issues related to this PR from the issue database. Indicate, which of these issues are resolved or fixed by this PR.

I'm a bit confused on whats the difference then between ButtonComp and HudButtonComp? maybe something to explain on their docs in case people find the wrong one

HudButtonComponent is a hud and its position will be static to the margin that you have set, or if you set a position it will be calculate the margin and use that if the screen resizes. Which is how all HudMarginComponents work.
Meanwhile ButtonComponent is just a normal PositionComponent, and same with SpriteButtonComponent.


LINK-1817 | Add phone number field for signup

Description
Add phone number field to each signup
Allow to set phone number as mandatory field in registration settings
Validate that phone number is not empty if phone number is set as mandatory field
Issues

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (5be6c00) 99.73% compared to head (2767c8b) 99.73%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #302   +/-   ##
=======================================
  Coverage   99.73%   99.73%
=======================================
  Files         595      595
  Lines        9796     9797    +1
  Branches     2161     2162    +1
=======================================
+ Hits         9770     9771    +1
  Misses         23       23
  Partials        3        3

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


font size of sidenote numbers is mismatched between main text and sidenote

The sidenote numbers are bigger than the corresponding number in the main text.  The sidenote font size is 1.1rem, and the number in the main text is 1.0rem.

This can be fixed by adding font-size: 1rem to the .sidenote:before rule.

Thanks for reporting this—good catch. A pull request fixing it would be welcome. Please see the contribution guidelines. I'm heading on vacation so it won't get merged for some weeks.