Suspected flaky failure of "shrink for GovernorMockEnvironment" QuickCheck property

I strongly suspect that this CI failure is not the PR's fault.
https://ci.iog.io/build/5987622/nixlog/1 from https://github.com/IntersectMBO/ouroboros-network/pull/5009 at commit b7cba340ea793cdd132de9f4c15412fbc58a2d85
      shrink for GovernorMockEnvironment:                                       FAIL (58.23s)
        *** Failed! Falsified (after 47 tests and 311 shrinks):
        ShrinkCarefully (GovernorMockEnvironment {peerGraph = PeerGraph [], localRootPeers = fromGroups [], publicRootPeers = PublicRootPeers {getPublicConfigPeers = fromList [], getBootstrapPeers = fromList [], getLedgerPeers = fromList [], getBigLedgerPeers = fromList []}, targets = Script ((ConsensusModePeerTargets {deadlineTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 0, targetNumberOfEstablishedBigLedgerPeers = 0, targetNumberOfActiveBigLedgerPeers = 0}, syncTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 10, targetNumberOfEstablishedBigLedgerPeers = 1, targetNumberOfActiveBigLedgerPeers = 1}},NoDelay) :| [(ConsensusModePeerTargets {deadlineTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 0, targetNumberOfEstablishedBigLedgerPeers = 0, targetNumberOfActiveBigLedgerPeers = 0}, syncTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 18, targetNumberOfEstablishedBigLedgerPeers = 9, targetNumberOfActiveBigLedgerPeers = 9}},NoDelay),(ConsensusModePeerTargets {deadlineTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 0, targetNumberOfEstablishedBigLedgerPeers = 0, targetNumberOfActiveBigLedgerPeers = 0}, syncTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 28, targetNumberOfEstablishedBigLedgerPeers = 28, targetNumberOfActiveBigLedgerPeers = 14}},NoDelay),(ConsensusModePeerTargets {deadlineTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 0, targetNumberOfEstablishedBigLedgerPeers = 0, targetNumberOfActiveBigLedgerPeers = 0}, syncTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 10, targetNumberOfEstablishedBigLedgerPeers = 1, targetNumberOfActiveBigLedgerPeers = 1}},NoDelay),(ConsensusModePeerTargets {deadlineTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 0, targetNumberOfEstablishedBigLedgerPeers = 0, targetNumberOfActiveBigLedgerPeers = 0}, syncTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 308, targetNumberOfEstablishedBigLedgerPeers = 308, targetNumberOfActiveBigLedgerPeers = 72}},NoDelay),(ConsensusModePeerTargets {deadlineTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 0, targetNumberOfEstablishedBigLedgerPeers = 0, targetNumberOfActiveBigLedgerPeers = 0}, syncTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 38, targetNumberOfEstablishedBigLedgerPeers = 36, targetNumberOfActiveBigLedgerPeers = 36}},NoDelay),(ConsensusModePeerTargets {deadlineTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 0, targetNumberOfEstablishedBigLedgerPeers = 0, targetNumberOfActiveBigLedgerPeers = 0}, syncTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 110, targetNumberOfEstablishedBigLedgerPeers = 55, targetNumberOfActiveBigLedgerPeers = 49}},NoDelay),(ConsensusModePeerTargets {deadlineTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 0, targetNumberOfEstablishedBigLedgerPeers = 0, targetNumberOfActiveBigLedgerPeers = 0}, syncTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 96, targetNumberOfEstablishedBigLedgerPeers = 96, targetNumberOfActiveBigLedgerPeers = 48}},NoDelay),(ConsensusModePeerTargets {deadlineTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 0, targetNumberOfEstablishedBigLedgerPeers = 0, targetNumberOfActiveBigLedgerPeers = 0}, syncTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 10, targetNumberOfEstablishedBigLedgerPeers = 5, targetNumberOfActiveBigLedgerPeers = 3}},NoDelay),(ConsensusModePeerTargets {deadlineTargets = PeerSelectionTargets {targetNumberOfRootPeers = 11, targetNumberOfKnownPeers = 21, targetNumberOfEstablishedPeers = 10, targetNumberOfActivePeers = 8, targetNumberOfKnownBigLedgerPeers = 353, targetNumberOfEstablishedBigLedgerPeers = 81, targetNumberOfActiveBigLedgerPeers = 47}, syncTargets = PeerSelectionTargets {targetNumberOfRootPeers = 88, targetNumberOfKnownPeers = 630, targetNumberOfEstablishedPeers = 162, targetNumberOfActivePeers = 84, targetNumberOfKnownBigLedgerPeers = 1001, targetNumberOfEstablishedBigLedgerPeers = 1001, targetNumberOfActiveBigLedgerPeers = 56}},NoDelay)]), pickKnownPeersForPeerShare = Script (PickFirst :| []), pickColdPeersToPromote = Script (PickFirst :| []), pickWarmPeersToPromote = Script (PickFirst :| []), pickHotPeersToDemote = Script (PickFirst :| []), pickWarmPeersToDemote = Script (PickFirst :| []), pickColdPeersToForget = Script (PickFirst :| []), pickInboundPeers = Script (PickFirst :| []), peerSharingFlag = PeerSharingDisabled, useBootstrapPeers = Script ((DontUseBootstrapPeers,NoDelay) :| []), consensusMode = PraosMode, useLedgerPeers = Script ((UseLedgerPeers (After (SlotNo 108)),NoDelay) :| []), ledgerStateJudgement = Script ((TooOld,ShortDelay) :| [])})
        shrink result invalid:
        GovernorMockEnvironment {peerGraph = PeerGraph [], localRootPeers = fromGroups [], publicRootPeers = PublicRootPeers {getPublicConfigPeers = fromList [], getBootstrapPeers = fromList [], getLedgerPeers = fromList [], getBigLedgerPeers = fromList []}, targets = Script ((ConsensusModePeerTargets {deadlineTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 0, targetNumberOfEstablishedBigLedgerPeers = 0, targetNumberOfActiveBigLedgerPeers = 0}, syncTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 10, targetNumberOfEstablishedBigLedgerPeers = 1, targetNumberOfActiveBigLedgerPeers = 1}},NoDelay) :| [(ConsensusModePeerTargets {deadlineTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 0, targetNumberOfEstablishedBigLedgerPeers = 0, targetNumberOfActiveBigLedgerPeers = 0}, syncTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 18, targetNumberOfEstablishedBigLedgerPeers = 9, targetNumberOfActiveBigLedgerPeers = 9}},NoDelay),(ConsensusModePeerTargets {deadlineTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 0, targetNumberOfEstablishedBigLedgerPeers = 0, targetNumberOfActiveBigLedgerPeers = 0}, syncTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 28, targetNumberOfEstablishedBigLedgerPeers = 28, targetNumberOfActiveBigLedgerPeers = 14}},NoDelay),(ConsensusModePeerTargets {deadlineTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 0, targetNumberOfEstablishedBigLedgerPeers = 0, targetNumberOfActiveBigLedgerPeers = 0}, syncTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 10, targetNumberOfEstablishedBigLedgerPeers = 1, targetNumberOfActiveBigLedgerPeers = 1}},NoDelay),(ConsensusModePeerTargets {deadlineTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 0, targetNumberOfEstablishedBigLedgerPeers = 0, targetNumberOfActiveBigLedgerPeers = 0}, syncTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 308, targetNumberOfEstablishedBigLedgerPeers = 308, targetNumberOfActiveBigLedgerPeers = 72}},NoDelay),(ConsensusModePeerTargets {deadlineTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 0, targetNumberOfEstablishedBigLedgerPeers = 0, targetNumberOfActiveBigLedgerPeers = 0}, syncTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 38, targetNumberOfEstablishedBigLedgerPeers = 36, targetNumberOfActiveBigLedgerPeers = 36}},NoDelay),(ConsensusModePeerTargets {deadlineTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 0, targetNumberOfEstablishedBigLedgerPeers = 0, targetNumberOfActiveBigLedgerPeers = 0}, syncTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 110, targetNumberOfEstablishedBigLedgerPeers = 55, targetNumberOfActiveBigLedgerPeers = 49}},NoDelay),(ConsensusModePeerTargets {deadlineTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 0, targetNumberOfEstablishedBigLedgerPeers = 0, targetNumberOfActiveBigLedgerPeers = 0}, syncTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 96, targetNumberOfEstablishedBigLedgerPeers = 96, targetNumberOfActiveBigLedgerPeers = 48}},NoDelay),(ConsensusModePeerTargets {deadlineTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 0, targetNumberOfEstablishedBigLedgerPeers = 0, targetNumberOfActiveBigLedgerPeers = 0}, syncTargets = PeerSelectionTargets {targetNumberOfRootPeers = 0, targetNumberOfKnownPeers = 0, targetNumberOfEstablishedPeers = 0, targetNumberOfActivePeers = 0, targetNumberOfKnownBigLedgerPeers = 10, targetNumberOfEstablishedBigLedgerPeers = 5, targetNumberOfActiveBigLedgerPeers = 3}},NoDelay),(ConsensusModePeerTargets {deadlineTargets = PeerSelectionTargets {targetNumberOfRootPeers = 11, targetNumberOfKnownPeers = 21, targetNumberOfEstablishedPeers = 10, targetNumberOfActivePeers = 8, targetNumberOfKnownBigLedgerPeers = 353, targetNumberOfEstablishedBigLedgerPeers = 81, targetNumberOfActiveBigLedgerPeers = 47}, syncTargets = PeerSelectionTargets {targetNumberOfRootPeers = 88, targetNumberOfKnownPeers = 630, targetNumberOfEstablishedPeers = 162, targetNumberOfActivePeers = 84, targetNumberOfKnownBigLedgerPeers = 1001, targetNumberOfEstablishedBigLedgerPeers = 1001, targetNumberOfActiveBigLedgerPeers = 56}},NoDelay)]), pickKnownPeersForPeerShare = Script (PickFirst :| []), pickColdPeersToPromote = Script (PickFirst :| []), pickWarmPeersToPromote = Script (PickFirst :| []), pickHotPeersToDemote = Script (PickFirst :| []), pickWarmPeersToDemote = Script (PickFirst :| []), pickColdPeersToForget = Script (PickFirst :| []), pickInboundPeers = Script (PickFirst :| []), peerSharingFlag = PeerSharingDisabled, useBootstrapPeers = Script ((DontUseBootstrapPeers,NoDelay) :| []), consensusMode = PraosMode, useLedgerPeers = Script ((UseLedgerPeers (After (SlotNo 108)),NoDelay) :| []), ledgerStateJudgement = Script ((TooOld,NoDelay) :| [])}
        failed peer selection targets sanity check
        Use --quickcheck-replay="(SMGen<PHONE_NUMBER>3043389638<PHONE_NUMBER>956386167,16)" to reproduce.
        Use -p '/shrink for GovernorMockEnvironment/' to rerun this test only.```

FYI @coot as you requested during our call just now


[Window Management] send window to next desktop

Extension
https://www.raycast.com/extensions/window-management
Description
please add the feature to move the current window to next/previous desktop
like Amethyst
Who will benefit from this feature?
people who using multi monition with multi desktop
Anything else?
No response

This is already possible but you'll need to have an external monitor connected - it's called Next Desktop and Previous Desktop

no, i mean Next Virtual Desktop(Ctrl+1, Ctrl+2...etc) , but now next "monitor"


Update lync-server-2013-configure-lync-server-2013-to-work-with-unifi…

…ed-messaging-on-microsoft-exchange-server.md
Attempting a workaround for nested alerts.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

server-2013/lync-server-2013-configure-lync-server-2013-to-work-with-unified-messaging-on-microsoft-exchange-server.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


A "Multiple Models Targeting the Same Database" sample would be helpful

As currently written, the information on supporting multiple models within a single database is quite limited. A sample showing the "how" in more detail would be appreciated, along with any applicable commentary on the "why".
For example, in our case we want/need to support a "plug-in" style architecture for a core product to better support independent development of functionality associated with related products. The multiple models, same database option is likely to be the one that will cause least problems for our customers.
Other options we are considering include:

A separate database instance for each optional module. This would introduce a potential additional point of failure for each add-in as the majority will be pulling information from at least two DB contexts - specifically the core context and their own. It also introduces more complexity for the end-customer as they (or their IT department) would need to understand which instances are in use for which product module(s).

A single all-encompassing context containing the superset of both core and optional modules. This option raises multiple concerns. a) The data store will contain empty tables for modules that are not in use. b) If a schema change is necessary, it would only be possible to accomplish by updating all active add-in modules to compatible versions at the same time even if the change was only needed for a single add-in.

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

ID: 002d162b-8595-ad48-7ef8-2cd10194a3b4
Version Independent ID: a29d6e0c-f9eb-86d9-f82e-0e9fc41b5a0d
Content: Code First Migrations - EF6
Content Source: entity-framework/ef6/modeling/code-first/migrations/index.md
Product: entity-framework
GitHub Login: @divega
Microsoft Alias: divega

Duplicate of #750


Better style for range mode if start, end date are the same

On range mode, when start and end date are the same.
Make the box become a circle (it will be styled as startRange now).

Coverage increased (+0.04%) to 88.538% when pulling b26726352af485689ecf0322cf0ac5144e89657d on othree:range-start-same-as-end into 123141718b1b7081dbed86a2343ba6746b147b18 on chmln:master.

This has been incorporated for a while now.
Thank you for the effort regardless :+1:


pillar/hypervisor: fix discrepancy in setupSpec

kvm and xen sent an empty list of ioBundles to setupSpec, so that it failed to lookup devices with aa.LookupIoBundleAny(adapter.Name)
turns out, we can just not call this piece of code in the case of kvm and xen - only when using it directly from containerd; then we also include the proper ioBundles

Required to be backported (so labeled with "stable" or/and labeled with "fix")?

@christoph-zededa could you describe what was the issue observed with the current master?

Please rebase on the latest master. There were changes in the code close to changed here. I wanna be sure all together it's fine.

@OhmSpectator
I also moved it into oci.go as everything else.

Required to be backported (so labeled with "stable" or/and labeled with "fix")?

53d3ee8239b7afc0e0a6d03fe0974438addd2fe5 is in no stable branch yet, so no need to backport it.


How use Transfer Learning on keras 2.0.2

I want use keras develop a Face Recognition project, I think maybe need Transfer Learning and have some way can use Transfer Learning on keras 2.0.2
thank you

Francois Chollet has written a blog post about transfer learning: https://blog.keras.io/building-powerful-image-classification-models-using-very-little-data.html. You may need to do some modifications because of API changes in Keras 2.0.
The Keras docs have some code examples how to use the models included in the release:
https://keras.io/applications


Please reopen #12532

Type: Feature
Enter Task Name: HelmDeploy@0
Issue Description
Please reopen the following issue: #12532

@bada09089 Would it help if we add an input for failOnNonZeroExitCode? You can set it to false when using helm diff --detailed-exitcode, and the task won't fail in case of non zero exits codes.

Hi @shigupt202 , thanks for your response.
This would definitely be an option and would help a lot. Unfortunately, in case of an error we would then not directly see that the "Helm diff" task failed. Would it maybe be possible to do that but only with exit code 2? Because other exit codes than 0 and 2 would still mean that something went wrong.
0 = Succeeded with empty diff (no changes)
1 = Error
2 = Succeeded with non-empty diff (changes present)

@bada09089 I agree it's not the most appropriate solution. Actually, I'm sceptical about adding the explicit handling for exit code in the task because helm diff is not a supported command in HelmDeploy task currently like upgrade and package.
Could you use the command line as a work around for this scenario, while we talk things out with the PM's and come up with a proper solution for this?

Hi @shigupt202 , we will stick to our current process until there is a solution for it. Lots of thanks and we look forward to hearing from you again.

@bada09089 Thanks for your inputs. Unfortunately, we cannot handle an exit-code specifically within the task especially since helm diff is a plugin. Taking an array of status codes which are exempted from failure seems like a doable solution but again, it is very specific to the helm diff scenario. We will wait and see if more customers require this and add it accordingly.


WIP: Fix pandas unittests

Please complete the following checklist:

[x] I have read the guidelines in CONTRIBUTING.md.

[ ] I have documented all public-facing changes in CHANGELOG.md.

[ ] This pull request includes code, documentation, or other content derived from external source(s). If this is the case, ensure the external source's license is compatible with scikit-bio's license. Include the license in the licenses directory and add a comment in the code giving proper attribution. Ensure any other requirements set forth by the license and/or author are satisfied. It is your responsibility to disclose code, documentation, or other content derived from external source(s). If you have questions about whether something can be included in the project or how to give proper attribution, include those questions in your pull request and a reviewer will assist you.

[x] This pull request does not include code, documentation, or other content derived from external source(s).

Note: REVIEWING.md may also be helpful to see some of the things code reviewers will be verifying when reviewing your pull request.
Addresses
https://github.com/biocore/scikit-bio/issues/1511

Heads up that your commits from #1527 are included in this PR

I'm really confused how the order of the data changed, what happened to cause these failures? There could be something very seriously wrong with TabularMSA potentially.

Closing in favor of #1535


Yoga does not render MKMapView properly

I've been trying to render an instance of MKMapView but failed to do so.
Here is a code that works without using Yoga
import UIKit
import MapKit

class ViewController: UIViewController {

    override func viewDidLoad() {
        super.viewDidLoad()
        let m = MKMapView()
        m.frame.size = CGSize(width: self.view.frame.size.width, height: 100)
        self.view.addSubview(m)
    }

}

which renders the following view

but when I try to render a same map view using Yoga with the following code
import UIKit
import MapKit

class ViewController: UIViewController {

    override func viewDidLoad() {
        super.viewDidLoad()
        let m = MKMapView()

        self.view.yg_usesYoga = true
        self.view.yg_setWidth(self.view.bounds.size.width)
        self.view.yg_setHeight(self.view.bounds.size.height)

        m.yg_usesYoga = true
        m.yg_setWidth(self.view.bounds.size.width)
        m.yg_setHeight(100)

        self.view.addSubview(m)
        self.view.yg_applyLayout()
    }

}

I get this

Which is basically a "white" map

Is the "legal" text part of MKMapView?

Yes it is.

Yes ok. This is an issue I found last week. MKMapView is a composite view which is not correctly handled in the YogKit implementation. MKMapView should be treated as a leaf node in the Yoga node tree but due to it being marked with usesYoga and it having children it does not get treated that way and this bug happens. For no you can fix this by not marking the map as using yoga and just setting a frame on it directly. UIButton and similar views have the same issue.

OK thanks for the quick response. I'll try that. I haven't experienced this issue with UIButton though. Is there anything I can do to help fixing this bug? Not very familiar for Yoga's implementation but maybe you can point me to piece of code that might be causing this issue.

I discussed this with a colleague the other day. We didn't come up with a solution we were super happy with which is why I didn't make any change. The only solution we came up with is to have a property called yg_isLeaf which can be set on certain views. This is the line of code which would check for yg_isLeaf https://github.com/facebook/yoga/blob/master/YogaKit/UIView%2BYoga.m#L283

@emilsjolander If you want I can add private method like
- (BOOL)yg_isLeaf {
  NSNumber * isLeaf = objc_getAssociatedObject(self, &kYGIsLeafAssociatedObjectKey);
  return [isLeaf boolValue] || ![view yg_usesYoga] || view.subviews.count == 0;
}

and then make a category for MKMapView that sets the associated object to @YES.
Not the cleanest solution but it should work. What do you think?

This is not scaleable. I think a better solution is to just add a prop to
the existing category and then you can create your own subclasses or
categories which set that prop.
On Mon, 19 Dec 2016 at 13:13, Guido Marucci Blas<EMAIL_ADDRESS>wrote:

@emilsjolander https://github.com/emilsjolander If you want I can add
private method like

(BOOL)yg_isLeaf {
NSNumber * isLeaf = objc_getAssociatedObject(self, &kYGIsLeafAssociatedObjectKey);
return [isLeaf boolValue] || ![view yg_usesYoga] || view.subviews.count == 0;
}

and then make a category for MKMapView that sets the associated object to
@YES.
Not the cleanest solution but it should work. What do you think?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook/yoga/issues/290#issuecomment-267961056, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABdIpML81ahoAWFk5Fk-GXG1KRlUSsZ8ks5rJoMDgaJpZM4LQXNT
.

You mean use the same mechanism as how, for example, yg_setWidth is implemented? Add a yg_setIsLeaf and then make a category in MKMapView which always return YES?.
If that is the case I wonder if category extension have a well defined "method order". By this I mean if a category method defined on a subclass has precedence over the same category method defined on a super class. I would bet that this is undefined behavior.

@guidomb I think you could add a category method which is -(instancetype)initForYoga which calls that setter. Or your category could swizzle the implementation of -(BOOL)isLeaf on MKMapView

Before I find the best way to do such thing I need to understand this change a little better because I've made a quick hack to check if this would actually fix the issue and I am getting a crash. I've changed the line you pointed before to
static void YGAttachNodesFromViewHierachy(UIView *view) {
  YGNodeRef node = [view ygNode];

  // Only leaf nodes should have a measure function
  if ([view isKindOfClass:[MKMapView class]] || ![view yg_usesYoga] || view.subviews.count == 0) {
    YGNodeSetMeasureFunc(node, YGMeasureView);
    YGRemoveAllChildren(node);
  } else {
    YGNodeSetMeasureFunc(node, NULL);

 // ... the remaining of the function's code
}

which successfully forces YGAttachNodesFromViewHierachy to call YGNodeSetMeasureFunc for the map view by adding [view isKindOfClass:[MKMapView class]] to if expression. The problem is that this generates a crash in https://github.com/facebook/yoga/blob/master/YogaKit/UIView%2BYoga.m#L360
The crash being
2016-12-19 10:38:43.728 Portal[25806:11779390] *** Terminating app due to uncaught exception 'CALayerInvalidGeometry', reason: 'CALayer position contains NaN: [nan nan]'
*** First throw call stack:
(
	0   CoreFoundation                      0x000000010634034b __exceptionPreprocess + 171
	1   libobjc.A.dylib                     0x0000000105da121e objc_exception_throw + 48
	2   CoreFoundation                      0x00000001063a9265 +[NSException raise:format:] + 197
	3   QuartzCore                          0x000000010d1b12da _ZN2CA5Layer12set_positionERKNS_4Vec2IdEEb + 152
	4   QuartzCore                          0x000000010d1b144f -[CALayer setPosition:] + 44
	5   QuartzCore                          0x000000010d1b1aba -[CALayer setFrame:] + 650
	6   UIKit                               0x0000000106baf694 -[UIView(Geometry) setFrame:] + 854
	7   Portal                              0x00000001056cf981 YGApplyLayoutToViewHierarchy + 945
	8   Portal                              0x00000001056cfb06 YGApplyLayoutToViewHierarchy + 1334
	9   Portal                              0x00000001056cfb06 YGApplyLayoutToViewHierarchy + 1334
	10  Portal                              0x00000001056cfb06 YGApplyLayoutToViewHierarchy + 1334
	11  Portal                              0x00000001056cfb06 YGApplyLayoutToViewHierarchy + 1334
	12  Portal                              0x00000001056cf5ca -[UIView(Yoga) yg_applyLayout] + 122
	13  Portal                              0x00000001056de673 _TFV6Portal16YogaLayoutEngine6layoutfT4viewCSo6UIView4withVS_6Layout6insideS1__T_ + 4019
	14  Portal                              0x00000001056e3599 _TTWV6Portal16YogaLayoutEngineS_12LayoutEngineS_FS1_6layoutfT4viewCSo6UIView4withVS_6Layout6insideS2__T_ + 2473
	15  Portal                              0x00000001056f2c95 _TFV6Portal13UIKitRenderer6renderu1_R0_S_9Componentxzw0_14PropertiesType_zw0_16CustomStyleSheetrfT8viewNodeq0__T_ + 3653
	16  Portal                              0x00000001056e941b _TFC6Portal14ViewController11viewDidLoadfT_T_ + 13067
	17  Portal                              0x00000001056e99e2 _TToFC6Portal14ViewController11viewDidLoadfT_T_ + 34
	18  UIKit                               0x0000000106cabc99 -[UIViewController loadViewIfRequired] + 1258
	19  UIKit                               0x0000000106cac0cc -[UIViewController view] + 27
	20  UIKit                               0x0000000106b75c51 -[UIWindow addRootViewControllerViewIfPossible] + 71
	21  UIKit                               0x0000000106b763a2 -[UIWindow _setHidden:forced:] + 293
	22  UIKit                               0x0000000106b89cb5 -[UIWindow makeKeyAndVisible] + 42
	23  UIKit                               0x0000000106b02c89 -[UIApplication _callInitializationDelegatesForMainScene:transitionContext:] + 4818
	24  UIKit                               0x0000000106b08de9 -[UIApplication _runWithMainScene:transitionContext:completion:] + 1731
	25  UIKit                               0x0000000106b05f69 -[UIApplication workspaceDidEndTransaction:] + 188
	26  FrontBoardServices                  0x000000010f41b723 __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ + 24
	27  FrontBoardServices                  0x000000010f41b59c -[FBSSerialQueue _performNext] + 189
	28  FrontBoardServices                  0x000000010f41b925 -[FBSSerialQueue _performNextFromRunLoopSource] + 45
	29  CoreFoundation                      0x00000001062e5311 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
	30  CoreFoundation                      0x00000001062ca59c __CFRunLoopDoSources0 + 556
	31  CoreFoundation                      0x00000001062c9a86 __CFRunLoopRun + 918
	32  CoreFoundation                      0x00000001062c9494 CFRunLoopRunSpecific + 420
	33  UIKit                               0x0000000106b047e6 -[UIApplication _run] + 434
	34  UIKit                               0x0000000106b0a964 UIApplicationMain + 159
	35  Portal                              0x00000001056eaa7f main + 111
	36  libdyld.dylib                       0x0000000109d7c68d start + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
(lldb)

You also need to update https://github.com/facebook/yoga/blob/master/YogaKit/UIView%2BYoga.m#L371

@emilsjolander Oops! sorry didn't see that. You were right it worked! Now the maps renders correctly. I'll prepare a PR. Thanks a lot helping me!

I've created https://github.com/facebook/yoga/pull/291 we can continue the discussion there.

@guidomb Thanks for using YogaKit! I'm Dustin, and I'm one of the main creators of YogaKit. I ran into this bug a few days and have been working on a fix internally at FB.
The TL:DR; is that I'm landing a fix this morning. It will sync with this repo shortly after.
As you correctly spotted, add YogaKit properties to a composite views removes it use of the MeasureFunc which usually results in crashes, and a destroyed layout.
Before we would determine a leaf like so:
const BOOL isLeaf = ![view yg_usesYoga] || view.subviews.count == 0;

This would be incorrect for composite views (like MKMapView) because it contains subviews, but, we only want the yoga properties to affect the view as a whole.
So here's my solution:
- (BOOL)yg_isLeaf {
  NSAssert([NSThread isMainThread], @"We are accessing subviews....");
  if ([self yg_usesYoga]) {
      for (UIView *subview in self.subviews) {
          if ([subview yg_usesYoga] && [subview yg_includeInLayout]) {
              return NO;
          }
      }
  }

  return YES;
}

Now, when we check to see if something is a leaf, it can have subviews, as long as none of them use yoga! :)

@dshahidehpour Cool! Thanks for sharing this! Looking forward for this fix!

The fix for this landed in 835bb1c. I'm going to close this, but feel free to open if something else arises!


introduce correction_status.csv to skip manual data corrections

@metaodi @jb3-2 what do you think about this change?

@maekke I'd rather have a clean time series than having another file to ignore some entries. But I don't have strong feelings about this issue, so if you are okay with it, Iet's do it.

@metaodi in principle I am agreeing that the time series should be fixed... But NW (and I guess this applies to BS too) states explicit "-2 Fälle aufgrund Systembereinigung".
I just dislike the current situation, that the CSV Validation prints an error every hour...

I totally understand that. In the past I used to remove the obvious wrong values (that were too high and therefore trigger the error) and ignore the values of these days in the scraper (search for "TODO" in the code base and you will find many of those cases). That way at least all the "hacks" are in the same place instead of a new CSV.

I agree with both of you :-)
Yes, BS also had some "Systembereinigungen", thus the time series is clean as it is.
@maekke Thanks for your solution, let's do it!


Java: Fix #6028

Description
Fixes: https://github.com/microsoft/semantic-kernel/issues/6028
Contribution Checklist

[X] The code builds clean without any errors or warnings
[X] The PR follows the SK Contribution Guidelines and the pre-submission formatting script raises no violations
[X] All unit tests pass, and I have added new tests where possible
[X] I didn't break anyone :smile:

@microsoft-github-policy-service agree

@microsoft-github-policy-service agree

@st4sik looks good, thanks


script: Fix release version iteration

This includes the addition of a script unit test suite :smile:.

This is failing in CI with jq: command not found. I am going to close this and open a new PR with the actual fix from this PR.


(chainer error) attributeerror: int object  has no attribute  eval

when I try to implement the code on my ubuntu  16.04( code link is https://github.com/hillbig/binary_net);
I get the error when I run the : python train_mnist.py
it says
attributeerror: int object  has no attribute  eval
(by the way, I installed the chainer just do : pip install chainer)
thank anyone can help!

Thank you for reporting! Could you paste the stack trace?

thank you for your reply, I have attached the  error report as a file
;
I did a few try; I noticed chainer had an update to v2.0 last year; I am wondering maybe it has removed some functions in your code, that it why it failed; but I am not sure;
looking forward to your reply :）

The code you mentioned (https://github.com/hillbig/binary_net) seems to be written for Chainer v1, and as you wrote, v1 to v2 was a big step and has many backward-incompatible changes (that's not the case in v3 and succeeding releases, though).
For this error, it seems this line is the cause.
You should rewrite this line
if n_in.eval() == 3:

as
if type_check.eval(n_in) == 3:

.
FYI, there's a mention about this particular change in the v1 to v2 upgrade guide.

Surely, as v1 to v2 is a big change, there must be several things to fix.
I'll close this issue for now, but please feel free to open an issue if you encounter a problem that is not covered in the upgrade guides.

Thank you so much, I have successfully fixed all errors
niboshi<EMAIL_ADDRESS>于 2018年4月15日周日 下午7:03写道：

Surely, as v1 to v2 is a big change, there must be several things to fix.
I'll close this issue for now, but please feel free to open an issue if
you encounter a problem that is not covered in the upgrade guides
https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.chainer.org_en_stable_upgrade.html&d=DwMFaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=30rPHAnnadvXKmM3Pnrm8w&m=Ad3WUIdGmJRT_d6CHCDzPrxjhA2-WbCwowoRjnNuIxQ&s=jeOwWhoEryZwP9l43i_JW5Ut0qRE9gxbWmpQJ3IJagk&e=
.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_chainer_chainer_issues_4594-23issuecomment-2D381459555&d=DwMFaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=30rPHAnnadvXKmM3Pnrm8w&m=Ad3WUIdGmJRT_d6CHCDzPrxjhA2-WbCwowoRjnNuIxQ&s=CBEd1FMD028oubqerV0XwnzDbgSSykuBzhRqRsN-nUg&e=,
or mute the thread
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AioLTGbtP03AfVNCFT76b38msk67UF-2DYks5to-5FvygaJpZM4TND2r&d=DwMFaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=30rPHAnnadvXKmM3Pnrm8w&m=Ad3WUIdGmJRT_d6CHCDzPrxjhA2-WbCwowoRjnNuIxQ&s=yHcvZK0mQC-SzO5GR52wtO1UnFeJr24NBBWW2oNp59I&e=
.

Glad to hear that!


Antivirus detection message

Hi,
I am using BouncyCastle.Crypto.dll for encryption. After I deployed my application to production server, encounter an Antivirus detection message.
Risk: SONAR.Heuristic.159

Please help me, Is it fine to use this dll?

What does the DLL have to do with ot.exe?
In any case, we've never had a report that the original DLL triggers an antivirus detection before. You should confirm that you have an unmodified version of our software by downloading from http://www.bouncycastle.org/csharp/index.html, where there is a sha256 checksum provided. Alternatively, you could build the DLL yourself from the provided source code.

ot.exe is my application. It use your dll for encryption/decryption. Downloaded the dll from the above mentioned URL.


Update bootstrap to select between GRCh37/38

Latest CCDS is based on GRCh38

Links:

https://s3.eu-central-1.amazonaws.com/chanjo/ccds.15.grch37p13.bed.zip
https://s3.eu-central-1.amazonaws.com/chanjo/ccds.18.grch38p2.bed.zip

Yes, I fumbled for a while with chanjo init and chanjo db setup thinking that I can get the directory ready to work with, but it turns out that chanjo bootstrap does all the work. I don't know when to use the two previous command then. And also I found that chanjo is currently support only GRCH37. It is may be worth to point that out in the documentation or FAQ. Last but not least, it seems that chanjo developer intends to generate the bed file from CCDS by them self and publish it with chanjo. This is both a good thing and a limiting factor. For example, I don't see a plan to support other organisms of user choices.

Okay, maybe I got it after peeking into the code further :)
If I work with GRCh37, I run chanjo bootstrap directly and ignore init, db setup and link commands.
If I work with other genomes, or bed files, I have to through the set of initialization commands, namely init, db setup, link before I can do calculate and other query commands.
I will keep the previous comment to show what a normal user may encounter.


go-jet: init at 2.9.0

Description of changes
go-jet: Type safe SQL builder with code generation and automatic query result data mapping

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

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

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

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

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

[x] Fits CONTRIBUTING.md.

My apologies for clubbing the packages in one branch. I needed them together for a project, and initially did not know how to use the nix files directly in the nix shell.
In the next couple of days i will split them into their own dedicated PR.
In the meantime,I will convert this PR into a draft.


Update pubsub client with latest surface changes.

Pubsub now is compatible with GAX 0.0.9
More details about the surface change:
https://github.com/googleapis/gax-java/commit/e27c1e5d4d64273ff291c781e3ec60862b9ebb8f
https://github.com/googleapis/gax-java/commit/5509053ba1425405348244e7ea86fedd150851ef

Changes Unknown when pulling 3bf78a14953452f038efbbb5ef366f86072190a4 on shinfan:pubsub-alpha into ** on GoogleCloudPlatform:pubsub-alpha**.

Changes Unknown when pulling 5ca8341b76ee492505eece8414cffc7b395c23a0 on shinfan:pubsub-alpha into ** on GoogleCloudPlatform:pubsub-alpha**.

Changes Unknown when pulling 1e67a151f175bac6406dfe264c9dc8af5d922476 on shinfan:pubsub-alpha into ** on GoogleCloudPlatform:pubsub-alpha**.

Looks much better. Some future comments/suggestions. Feel free to merge.


Inaccurate Num.div documentation

Is this wrong? https://github.com/rtfeldman/roc/blob/e0014e8865ff91d7297eff0c2a0d08c2eb804c3d/compiler/builtins/docs/Num.roc#L1042
I see the following:
» Num.div

<function> : Float a, Float a -> Result (Float a) [ DivByZero ]*

»

This has been resolved! REPL now shows:
» Num.div

<function> : Float a, Float a -> Float a

»


UINavigationController Edge Swiping causes InputView to no longer move up with keyboard

Repro steps

On UINavigationController, pan about 20 pixels, and pan back without fully popping the slack view controller
InputView no longer moves up with the keyboard after being tapped.

iOS8.x
This bug also happens if you Push another view controller onto the stack from SLKViewController, and then come back to SLKViewController.

nevermind that only happens if I remove the keyboardWillShow event


move static varables from key_keeper and listener mod to data-vessel

move more static variables from key_keeper mod to data_vessel
move static variables from listener mod to data_vessel
share vessel instance between start_service and stop_service
return none if key has not update or not able to fetech from data_vessel.

It looks like this branch needs rebasing since #59 was squashed when it was merged and this appears to be based on the branch that got squashed. Git should drop empty commits by default, so a simple git rebase main from this branch should do the right thing.


analysis: Introduce Vulkan XML parser

This adds a parser for Vulkan XML registries, namely vk.xml and video.xml. It doesn't have a 100% coverage of all possible attributes, and doesn't aim to do so, though it can be easily expanded when necessary. Any additional attributes that are not extracted will simply be ignored. It doesn't try to process the XML in any way at all, even for simple things such as parsing a number.
TODO

[x] Fix CI
[x] Add support for unions
[x] Add support for external types

These are types either from C itself, or from another Vulkan library, which are referenced in this XML file.
Identified by not having a "category" attribute.

[ ] Improve the documentation

It is not immediately obvious which Rust struct corresponds to which specific parts of the XML. Maybe each struct should be accompanied by example XML data it can represent in order to make it easier to recognize.

@Friz64
Yet another wonderful PR! Thank you!

Trying to get back into working on this. Sorry for the silence. Life is hard.

I wonder if this crate should be renamed to parser or if you intend it to also contain the analysis stage (e.g. linking everything together) within it? (Probably doesn't make much sense to only have a purpose-built parser crate for Ash)

The intention was for this crate to contain the analysis stage, yes.

The next layer on top of this should take care of all remaining parsing.
For this, I was reading back on the conversation in #662, and the conclusion we seemingly came to for C parsing was to use a parsing library, not on the whole spec at once, but on small chunks, lifted from the XML. One idea was to leverage the lang-c library I had used in erupt for this, but after some testing I learned that it is not really fit for that purpose.
Today, I again searched for other C parsing libraries we could use, and one stuck out to me: tree-sitter-c. Tree-sitter is an parsing library written in C, with well-written and official Rust bindings. In terms of C libraries, it is pretty harmless with all its code included in the crate, so compiling it as part of the generator should not be an issue, even on Windows. tree-sitter-c is the official C grammar for it. I did some quick experiments throwing various code snippets at it, and it seems to be pretty much exactly what we are looking for. It was developed for use within code editors, so it does not require its input to be run through an pre-processor. It also doesn't require any context for parsing. This means that even something like uint8_t pipelineIdentifier[VK_UUID_SIZE], where lang-c would have previously errored out because it doesn't know what VK_UUID_SIZE is supposed to be exactly, parses successfully. The downside of this on the other hand is that is only produces an Concrete Syntax Tree, not a more higher-lever Abstract Syntax Tree, but this is enough for our purposes.

This means that even something like uint8_t pipelineIdentifier[VK_UUID_SIZE], where lang-c would have previously errored out because it doesn't know what VK_UUID_SIZE is supposed to be exactly,

Sorry if this was discussed before (I couldn't easily find this specific point brought up), but:
<member><type>uint8_t</type>                <name>pipelineIdentifier</name>[<enum>VK_UUID_SIZE</enum>]</member>

The actual XML has <type>, <name> and <enum>, fully disambiguating the identifiers used in the declaration.
Even without the <enum> on VK_UUID_SIZE, the syntax is unambiguously Type · "[" Expr "]".
(if you'll excuse my shorthand - · would be like the "declaration focus" or "declaree", trivial here but more important for e.g. pointer-to-array/function, where the type syntax turns inside-out with parenthesization - e.g. X (Z ·) Y => (X Y) Z ·, where X/Y/Z are any tokens, if you could parenthesize types in C, or if you use a C++ noop type alias to emulate it etc.)

If there are counter-examples to that idea, I'd love to see them, because it's the direction I would've went in, for my own coincidental vk.xml parsing needs (before I remembered this effort might end up being a reusable way to generate ash-compatible automation - in theory even vk-layer-for-rust's Python scripts could potentially be fully replaced by something based on it, but that's out of scope for me for now).
I'm really tempted to try to at least categorize the shapes of child nodes (and text between them), which are currently flattened in this PR's StructureMember's c_declaration field - I'll post an update if I get there.
(disclaimer: back in the C11 days, I wrote a C declaration parser/compiler on top of someone else's yacc grammar, so the quirks of the syntax, like order independence of specifiers and the inside-out mode when the "declaree" is parenthesized, are "burned-in", making custom C parsers more appealing than they should be - my only hope is Khronos having been sensible enough, really)

Looks like custom parsing was 100% viable. By far most of the effort was spent making it powerful enough to handle the 11 function pointer typedefs with basically no special-casing (if vk.xml ever gets wild enough to have the C equivalent of fn() -> fn() -> fn() -> fn(), maybe with bonus extra pointers and arrays as well, my parser should be ready for it).
Outside of that, the only 2D array is in VkTransformMatrixKHR, and everything else is T*, const T*, T[N], and the occassional spicy const T[N] (thanks to function parameter decay, which I explicitly model in CType).

my PR (against this PR's branch): https://github.com/Friz64/ash/pull/1
example dump output (see PR's second commit): https://gist.github.com/eddyb/5ae0247468892ea7dd2a136ed3afa869

Finally dug enough into the old generator to see how the C parsing works there: https://github.com/ash-rs/ash/blob/92084df65f52aa15b704279fb6d8d26a3ee71809/generator/src/lib.rs#L86-L272
I would agree with anyone who would want to replace that, and here's my first impressions:

using nom is comparable to my code on the parsing side, but feels clunkier for lexing
it doesn't separate lexing and parsing which probably makes it more annoying than it needs to be
it special-cases a lot of declarator patterns (various combinations of maybe-const pointers and/or arrays) like I first theorized, but then I moved away from that very quickly due to combinatorial explosion
I am increasingly confused by vk-parse: it seems to also contain some ad-hoc C parsing (oh dear), but I guess it's not enough for the old ash generator?

should my more robust cdecl parser be upstreamed to vk-parse?
is this ash analysis crate work meant to be a replacement for vk-parse?

With some of these aspects I feel a bit out of my depth, especially when it comes to "what other efforts are out there and am I at risk of duplicating work?", but nothing else I've seen so far seems principled enough (at most there's a lot of reliance on the limited set of possible patterns which is somewhat reasonable I suppose).

Finally dug enough into the old generator to see how the C parsing works there:
[..]
* I am increasingly confused by vk-parse: it seems to also contain some ad-hoc C parsing (oh dear), but I guess it's not enough for the old ash generator?

We use both. vk-parse creates vkxml constructs that represent parsed C in some "unmanageable" way, and a bit of nom-fu was added to parse out things (like simple C const expressions) that we could not get through vkxml. As a general code, a lot of this has been hacked together out of dire need, with a focus on generated code, not on generator internals. That's why things are so messy, and why a new generator needs to be written that takes all our ideas into account from the get-go.
With this approach from @Friz64 we should no longer need to rely on vk-parse (even though it is still maintained. The 7-year-old unmaintained vkxml is entirely out of the question, of course).

A little warning: this PR sat stale since June 2023, and right as activity is picking back up now, I'll be away from computers all of February. I hope no-one is affected by my absence and feel free to keep working/discussing on a generator rewrite, but it'll have to do without my input for a while 👍

It doesn't try to process the XML in any way at all, even for simple things such as parsing a number.

This is not really true anymore with https://github.com/Friz64/ash/pull/1. Other than that, I've come around to saying simple parsing doesn't hurt.

I've added support for the tracing crate. Here's a snip from the output when running via RUST_LOG=trace:
...
2024-03-13T21:00:30.028385Z TRACE xml{path=generator/Vulkan-Headers/registry/vk.xml}:type{node="<type name='VkColorSpaceKHR' category='enum'>"}: analysis::xml: encountered node
2024-03-13T21:00:30.028388Z TRACE xml{path=generator/Vulkan-Headers/registry/vk.xml}:type{node="<type name='VkCompositeAlphaFlagBitsKHR' category='enum'>"}: analysis::xml: encountered node
2024-03-13T21:00:30.028392Z TRACE xml{path=generator/Vulkan-Headers/registry/vk.xml}:type{node="<type name='VkDisplayPlaneAlphaFlagBitsKHR' category='enum'>"}: analysis::xml: encountered node
2024-03-13T21:00:30.028395Z TRACE xml{path=generator/Vulkan-Headers/registry/vk.xml}:type{node="<type name='VkPresentModeKHR' category='enum'>"}: analysis::xml: encountered node
2024-03-13T21:00:30.028399Z TRACE xml{path=generator/Vulkan-Headers/registry/vk.xml}:type{node="<type name='VkSurfaceTransformFlagBitsKHR' category='enum'>"}: analysis::xml: encountered node
2024-03-13T21:00:30.028403Z TRACE xml{path=generator/Vulkan-Headers/registry/vk.xml}:type{node="<type name='VkDebugReportFlagBitsEXT' category='enum'>"}: analysis::xml: encountered node
2024-03-13T21:00:30.028406Z TRACE xml{path=generator/Vulkan-Headers/registry/vk.xml}:type{node="<type name='VkDebugReportObjectTypeEXT' category='enum'>"}: analysis::xml: encountered node
...

I tried playing around with this and it's pretty good already, much nicer to use then vk-parse / vkxml. I'm using it for a small codgen task that would live outside of ash.
Two small bits of feedback

Extremely easy to use!
On Analysis, the xml field should be pub
This work would be quite a bit more powerful if it would handle also all the "C" parsing from the vk.xml files, right now I'm just moving / copying code over into my project from the old ash generator (things like converting uint32_t to u32, converting pointers and arrays etc). It's nice that the c_declaration exists, but it would be even nicer if a rust_declarations field also existed.

Hey, thanks for taking a look! It's good to have feedback from real world use cases.

On Analysis, the xml field should be pub

This PR didn't really try to expose a proper public API (although maybe it should have?). Either way, I want to point you to #867, which actually does so. I've gone ahead and rebased it for you.

This work would be quite a bit more powerful if it would handle also all the "C" parsing from the vk.xml files, right now I'm just moving / copying code over into my project from the old ash generator (things like converting uint32_t to u32, converting pointers and arrays etc). It's nice that the c_declaration exists, but it would be even nicer if a rust_declarations field also existed.

C parsing is what https://github.com/Friz64/ash/pull/1 aims to accomplish. I recall that it's in a usable state already, just not 100% finished.
This PR is currently marked as draft because the intention is that it gets merged into here first.


Username completion

I updated the username completion functionality to mimic twitch chat.

Reduce characters necessary to search for users from 3 to 2
Remove @ sign requirement to search for users
User can force a search using the tab key

I see an issue with no longer requiring the '@' to mention people.
Would name suggestions be popping up when people are just typing normal words? For example, typing "the" would most likely pop up some suggestions in a big chat.

To use username completion without the @ sign, the user is forced to press the Tab key. Also, to cancel the username popup, the user should press Esc. Without pressing Esc, shouldShow doesn’t get set to false and the suggestion box keeps appearing. I think that wasn’t clear in my notes.


[RFC] Make the behavior of calling range primitives clear

Based on this post, many core devs were in agreement that one basic rule of ranges is that many calls to front without a call to popFront should all yield the same value. Some ranges break this rule.
This PR formalizes this rule as to make it crystal clear that these violations are bugs that must be fixed:
Calling front multiple times without calling popFront yields the same result for each call.

Ping @schveiguy @jmdavis

LGTM.

I'm flagging @andralex on this, since it's an additional design constraint to a core piece of the library.

@wilzbach fixed

although I'm aware Andrei disagrees

Where have you seen that? If he disagrees, we probably should just close this now and move on, because it won't happen.

what does "yield the same result" mean

It means that when I call front, I get the same result until I call popFront, whereby I then get the next element in the range when I call front. Essentially, the requirement is that the range doesn't move until I call popFront.
How this is achieved is not relevant or necessary to specify. You can re-calculate, you can use a cache, you can have whatever side effects you need to do, you can do whatever you want. Just make sure that the range's front stays the same.

Perhaps I should change the wording to
"r.front called multiple times, without calling any other range primitive, yields the same result for every call"
as calling the set version of front will change the value of front.

as calling the set version of front will change the value of front.

Actually, your rewording still doesn't imply that calling set version of front is verboten.
Another strawman: "front should return or refer to the same element until popFront is called". Note that empty shouldn't advance the range either.

Will users actually expect front on the passed-in range to be called multiple times – what if it does have side effects?

Yes, they should. If it has side effects, that is up to the range author whether it's important. The range API isn't concerned with side effects, and neither should the user of the range be concerned.

What if front is expensive?

range.cache if you want.

Should you better make a local copy if you need front three times per element, or is that the user's responsibility, for maximum flexibility? Three hundred times? Three million?

I don't think generic code should care. Performance of getting the front element is not technically part of the range definition, but I think everyone will expect the same performance as an array, where front is pretty cheap. If you find your peformance is lacking, then profile and optimize. If this means you make a copy, then you make a copy.
Even with an array, continually indexing the first element is going to cost more than making a copy to go in a register, I've made improvements to code by doing just that.

And by "generators" I include everything that might be problematic based on the updated range API proposed in this PR, such as front that changes its value every time, etc., front doing too much work every time it's called, etc..

Yes, a generator can be turned into a range quite easily. But I think we don't need a new concept to do that. A generator is really just a delegate (the "empty" method is mostly useless).

@quickfur opApply iterables can be translated in a very similar fashion.

With opApply you need fibers, though. Otherwise you couldn't implement the range primitives with the required semantics.

The author of which range?

The author of the range that is creating the side effects.

What you are saying here is that the range API is a leaky abstraction by design.

Leaky how? I can write code that has side effects anywhere, no design can stop that. Unless you want to make all ranges pure?

For example, if I grant you that people will expect front to be cheap – doesn't this mean that map should cache its result?

map should not concern itself with preventing unexpected behavior from someone who creates such a range. Indeed, I have shown how to create an unexpected range with map as shown on the forum post linked from this PR that has nothing to do with caching.
The thing is, caching does not affect the API, just the performance. And premature optimization is not usually desired. It has its own effects (for example, if the underlying data changes through other means, the cached copy is no longer valid). If you want to cache with map, use  map!(...).cache. It's not hard to cache on demand.

On the other hand...

I think it's more important to identify the aspects of performance/behavior in the documentation of the higher-order range. Do whatever the minimum is to get it to be a valid range, then allow the user to build on top of that if necessary.
The reality is, as long as we create algorithms that use arbitrary function calls to build the data, we cannot be certain that any range construction has well-behaved semantics. There is a certain degree of responsibility that the function author has to assume, map (and the compiler) can only do so much.

@klickverbot It seems your reasoning comes down to -- can we force algorithms (either by mechanical verification or convention) to require calling front a certain number of times? The answer is no. Any range author and/or function author for range-using code can call front as many times as they want. Does this mean ranges can't have side effects? I don't think it does. But the side effects are the responsibility of the caller, not the algorithm that's calling front N times. Yes, it means that if you are using a function that creates those side effects via calls to front/popFront/empty, then you have to examine the code to see what exactly is going to happen. In essence, you are relying on an implementation detail for correct code.
To put it another way -- I don't think it's invalid to have map!someFunction if someFunction causes side effects (and that's OK with you). But map is perfectly within its right to change the number of calls to front for any reason, so the user should beware of that.
I don't think we need a specific note on map, just a general rule concerning callable parameters and side effects.

Walter agrees with the essence of the rule<EMAIL_ADDRESS>

Added Walter's rules and make the docs a little clearer.

Since we're all here, the rules currently allow r.empty to return things other than bool. Is this intended?

Is this intended?

Not sure. I would guess no, given the fairly recent decision that length should always return size_t, I would assume a uniform return for empty as well.

Since we're all here, the rules currently allow r.empty to return things other than bool. Is this intended?

I also think that it makes sense to agree on  bool :+1:
Btw how about requiring empty

to be side-effect free (could we even enforce const?)
not returning by reference

Ping @schveiguy @klickverbot @quickfur
Walter has signed off on this? What else needs to be done here?

@klickverbot Fixed your comment

You could add somewhere in the description of empty that it's considered to not mutate the range even if not const-qualified.
You may want to clarify that if the range returns front by value and the value returned by front contains mutable references, a call to popFront might change the value referred to by those references. This essentially is a narrow way to allow byLine to work.

I approve this after nits. The larger changes may be part of this or of subsequent PRs. Generally I support work on improving range formalization.
One thought that came up in a chat with @klickverbot: if a range returns front by ref it's assumed to do negligible extra work. If it returns by value, it's assumed to do arbitrary work as long as it is constant in the length of the range. This encodes today's common practice and allows people to decide whether they want to cache front or not by using introspection.

You may want to clarify that if the range returns front by value and the value returned by front contains mutable references, a call to popFront might change the value referred to by those references. This essentially is a narrow way to allow byLine to work.

Let's leave the transient range discussion for another day, as there is still a lot of disagreement on that. Did you see the discussion on the NG btw?

The wording should make clear that this applies in a "logical" sense, though. As I pointed out earlier, some ranges will have to actually do the work (fetching the next element) in empty – which is fine, as long as empty looks idempotent to the user.

Wouldn't that be a job for popFront? I guess I don't understand your use case.

In this case, you might not even know whether the range is empty until you have actually received the next element.

So in that case you would have to cache the next element once you've pulled from your "stream" (for lack of a better term) and then move it into the front position once popFront is called?
Ok, I think I understand now. Technically empty is mutating the range in this case. How about
r.empty must not mutate the value of r.front or otherwise change the sequence of values of the range.

@quickfur fixed

@quickfur Sorry, missed that. Fixed.

Thanks!  LGTM once @andralex 's comments are addressed.

@quickfur I left some notes on @andralex's comments, I disagree in some areas. If you agree with him could you clarify your position?

Performance of getting the front element is not technically part of the range definition, but I think everyone will expect the same performance as an array, where front is pretty cheap.

I think that it's pretty clear that all of the range primitives should be O(1) with regards to the number of elements in the range. Exactly what that amounts to in terms of how expensive the operations end up being within O(1) is very much implementation-dependent and not really a concern of the range API IMHO, though it should be expected that empty and front may be called multiple times per call to popFront, and so they should be relatively cheap to call. The primary concern is O(1) though.

Since we're all here, the rules currently allow r.empty to return things other than bool. Is this intended?

I don't see any reason to allow empty to return anything other than bool.
And as for concerns about what returning the same resultmeans, if we want to specify it more concretely, I think that the requirement should be that the same result means equality. There's too much useful code that does stuff like allocate - e.g. range.map!(a => to!string(a))() - for it to make any sense to require that the result be exactly the same object. I'm not sure that we need to be more specific than saying that the result needs to be the same though.
Overall, I think that this looks good.

I think that it's pretty clear that all of the range primitives should be O(1) with regards to the number of elements in the range.

Should this be added too? Something like,
"Phobos calls range primitives with the assumption that they are O(1) with respect to the number of elements in the range. Therefore, it's best practice to restrict the range primitives you do provide to those that are O(1). For example, it's not a good idea to implement a singly linked list as a bidirectional range, as the back and popBack attributes would be O(n), and they would be called many times in Phobos code if they are present."

I don't see any reason to allow empty to return anything other than bool.

I will clarify this.

I think O(1) requirement should not be specified. I think what's important is to know that algorithms will not consider calls to front or empty to be expensive, and may call them more than once for each iteration. If you construct a range with an expensive front, it's on you to worry about the performance of some algorithm that doesn't expect it. But I don't think we need to go as far as saying that's not a valid range.
BTW, typically "sub-linear" is acceptable for fast operations. O(lg(n)) should be sufficient.

I think it's clear that any generic algorithm that takes arbitrary code as parameter (e.g. a lambda, a range whose range API implementation comes from the user) will have a complexity that's keyed on the complexity of the provided code/implementation.
E.g., myRange.sort() is stated to be O(n log n), but it should be clear that what it actually means is n log n composed with the complexity of the range primitives. If popFront is O(n) then the actual complexity is not O(n log n) but O(n^2 log n).
Similarly, myrange.map!lambda supposedly has .front that is O(1), but the actual complexity will be O(lambda).
But it seems unreasonably onerous to require the docs to specify the complexity as "O(f(n) log f(n)) where f(n) is the complexity of parameter X"; we usually assume that range primitives, lambdas, etc., are "cheap" in the sense that we can make the possibly-not-so-accurate assumption that they are O(1) and still derive an overall big-O complexity that gives a good idea of the actual complexity.  If the user breaks the O(1) assumption, it's their own problem to deal with the resulting change in complexity; Phobos should simply state that the given big-O complexities are based on the assumption that certain things are O(1), so if your range doesn't obey that, then you're on your own to figure out what the actual complexity will be. I don't think we should outright reject such a range as a non-range.

@JackStouffer  I didn't say I agreed with everything @andralex said, just that, being the official "head honcho" of Phobos, his comments do need to be addressed one way or another (either concede with him and implement what he proposed, or win the argument and get his agreement on doing it another way) before we merge.
And for the record, I agree that we should use "if and only if" instead of "iff", even though personally I actually prefer the latter. For public-facing docs using the full phrase doesn't hurt and can only help reduce the likelihood of alienating would-be readers who may or may not know what "iff" means. It's not as though people who understand "iff" wouldn't understand "if and only if", so there is no harm in catering to the wider audience.

Actually, upon reflection, popFront can't be required to be O(1) because of stuff like binary trees, though I don't see how it makes any sense for empty or front to not be O(1). Regardless, the key thing with regards to performance is that algorithms assume that the range primitives are cheap enough that they basically don't factor into Big-O considerations - particularly front and empty. Probably the most important aspect of that is simply that folks should be aware that it's perfectly legit for an algorithm to call empty and front multiple times per call to popFront, and algorithms are going to assume that those calls are cheap. But ultimately that's an issue of performance and not correctness. So, I don't know if we want to say anything about that or not.
Regardless, it's certainly not the case that a range that has ridiculously expensive range operations isn't a range. It's just a horribly performing one that will violate the complexity assumptions made by any generic, range-based algorithm. It will work perfectly soundly with them but with performance that is worse than those algorithms are supposed to have.

Performance is an important part of the range elevator pitch, and complexity is mentioned elsewhere in Phobos. I think I should add a small note, outside of the rules section, about Phobos' assumptions about complexity so it's clear.

@jmdavis In principle, I agree. Creating a range with expensive front or empty is generally unwise, and I think it's safe for Phobos docs to state that O(1) is assumed for these primitives, and that if this isn't actually true, then generic algorithms may not obey the big-O complexity specified in the docs.  If the user wants to do it anyway, they just have to live with the consequences.

Addressed comments

@klickverbot Done
I think this is ready to merge


Retire the Core_A folder and use a single Core folder for all processor core headers.

Separate folders for different architecture profiles (A-profile, R-profile and M-profile)
Top-level compiler headers will exist in the Core folder (no separate Compiler folder is needed). ** The cmsis_compiler.h header will continue to figure out which compiler toolchain is being used. ** Compiler headers specific to each architecture profiles can reside within the new architecture profile folders. ** The second-level files like cmsis_gcc.h are named cmsis_gcc_a.h, cmsis_gcc_r.h and cmsis_gcc_m.h to avoid having multiple files with the same name

In my opinion we should delete the core_armv8xxx.h core header files.
These are the only header files representing an architecture and not a dedicated core. The files were added because no specific ARM v8-M device was available when Arm v-M support was added.

Hello @JonatanAntoni and @GuentherMartin
thank you for the feedback. I have updated the Pull-Request according to your input.

@JonatanAntoni  Is there anything I can do regarding the validation errors?

@JonatanAntoni Is there anything I can do regarding the validation errors?

No, unfortunately, to run the tests we need the license key which I stored in a repository secret. For security reasons a PR from a fork doesn't get access to these. Hence, we cannot execute the tests.


Is there a conflict between angular 1.3 and angular-translate 2.5.2

Hi friends

Sorry I just want to ask is there anything conflicts with angular 1.3

This is the code of Version 2.5.2. We can see Ctrl1 Of Watchers: 3
http://jsfiddle.net/lovedota/f4neo3rq/

This is the code of Version 2.2.0 We can see Ctrl1 Of Watchers: 1
http://jsfiddle.net/lovedota/bq7jpm3w/

Is it a bug about performance here ? Please help !

Hi, I think it is better if you open this issue at angular-translate, they should be able to help you


Fix spacing

Before

After

@jaebradley Any thoughts?

It's better to put the margin in the parent container
#atomify {
  display: inline-block;
+  margin-left: 1em;
}

@Gatix But there are two images, default is margin right of 10px.

Yes. Because if you remove the margin on the left, then it will be clipping the marquee

That's what #29 is for

@jacktuck IMHO 1.5em maybe looks like too much spacing?
1.5em

0.5em

@jacktuck the previous comment and commit was my fault - I didn't see you delete the margin-right. With only the margin-left: 1.5em it looks pretty good.


Broken Connection

For some reason, I have followed tutorials and even used the sample code with my tracking ID, but I am unable to see any data in the google analytics portal. The result in the sample shows valid =  true. Aside from that I have NO IDEA how to debug and see even if I am hitting the google analytics successfully.This is the tracking ID I am using for testing UA-102555648-1.

Same problem.  Calling CreateTracker results in this being sent to the output window:
Exception thrown at 0x74BCB802 (KernelBase.dll) in GoogleAnalytics.Sample.Native.exe: 0x00000005: Access is denied.
Exception thrown at 0x74BCB802 (KernelBase.dll) in GoogleAnalytics.Sample.Native.exe: 0x000006D9: There are no more endpoints available from the endpoint mapper.

Update:  Make sure IsDebug is set to false.  That was my problem. Thanks MS!


[HOTFIX] remove this useless assignment

Be sure to do all of the following checklist to help us incorporate
your contribution quickly and easily:

[x] Any interfaces changed? NO

[x] Any backward compatibility impacted? NO

[x] Document update required? NO

[x] Testing done YES
Please provide details on
- Whether new unit test cases have been added or why no new tests are required?
- How it is tested? Please attach test report.
- Is it a performance related change? Please attach the performance test report.
- Any additional information to help reviewers in testing this change.

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

status was already assigned value false

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder2.1/1910/

Build Success with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:8080/job/carbondataprbuilder2.3/10164/

Build Success with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder1/2121/

hi, @jackylk, I think this may be part of code style as we talk about in wechat group. So need someone control
the code clean progress

Build Success with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:8080/job/ApacheCarbonPRBuilder2.1/1957/

@jackylk , to avoid conflict, I should close this PR and create a new PR when #2878 finished.


[RFC]: improve README examples of stats/base/dists/erlang namespace

Description
This RFC proposes to improve the README examples of the stats/base/dists/erlang namespace package. Currently, namespace package READMEs only include minimal examples which are not particularly informative and do not showcase namespace functionality.
Historically, namespace examples were not given much effort due to the rapidly changing nature of the project; however, now that development and organization has settled, it would be good to revisit these packages and add proper examples to better communicate to users how to use namespace contents.
For those wanting to contribute to this issue, you can use the following steps:

Browse through the contents of the stats/base/dists/erlang namespace and identify interesting functions and packages to showcase.
Update the example code block in the "Examples" section of the README for the stats/base/dists/erlang namespace and open a PR.
When updating the README, examples should follow existing project conventions (e.g., ES5).
Examples may require functionality from other packages to help make examples more interesting.

Related Issues
None.
Questions
No.
Other
No.
Checklist

[X] I have read and understood the Code of Conduct.
[X] Searched for existing issues and pull requests.
[X] The issue name begins with RFC:.

@Planeshifter  i want to work on this

@Planeshifter I will resolve this kindly assign

Just assigned this to @Deepakchowdavarapu since he requested working on this first.


Proposals not loading in bitocracy page

Going to load a proposal in the Bitocracy page https://bitocracy.sovryn.app/ by clicking the 'View Proposal' button on any of the current proposals results in endless loading.
Multiple users have already tried clearing cache, refreshing browser, differnet browsers etc.

https://bitocracy.sovryn.app/proposals is also not loading anything, it may be related


Differentiable AnyArrayBuffer

@marcrasi Please see https://github.com/borglab/SwiftFusion/pull/150/commits/74d6335676913842ec59589f6bf677b21a6aeb40 and https://github.com/borglab/SwiftFusion/pull/150/commits/f753af08f6cd95a7b341a6adaca07b3677998681
both of which suppress the crash.


upload 1.5.0 sdist to pypi

Also consider using https://docs.pypi.org/trusted-publishers/ to enable strongly trusted automatic pushing from a github actions pipeline.

Done


Made the modification #1047

Added the algorithm "Count Inversion"
Fixes : #1047
Please merge the pull request and label me
@pankaj-bind

Please merge my pull request


Intellisense randomly stops working out of nowher

OS/device including version:
Linux Mint 21.3, Godot 4.3
Issue description:
Frequently now, the intellisense for Godot randomly fails and shuts down, making it so no errors are reported, documentation becomes unavailable and the colour-coded types are gone.
Log:
Using dotnet configured on PATH
Dotnet path: /usr/lib/dotnet/dotnet
Activating C# + C# Dev Kit...
waiting for named pipe information from server...
[stdout] {"pipeName":"/tmp/3c06f875.sock"}
received named pipe information from server
attempting to connect client to server...
client has connected to server
[Info  - 15:54:34] [Program] Language server initialized
[Info  - 15:54:41] [WorkspaceProjectFactoryService] Project /home/whitecat/Documents/Godot/Puzzle/Puzzle.csproj loaded by C# Dev Kit
[Error - 16:02:16] [LanguageServerHost] System.ArgumentException: '<Documentf0db74e0-ba1e-46be-a66b-359bdd57bbc8>' is not part of the workspace.
   at Microsoft.CodeAnalysis.Workspace.<>c.<OnDocumentClosedEx>b__213_0(Solution oldSolution, ValueTuple`4 data) in /_/src/Workspaces/Core/Portable/Workspace/Workspace_Editor.cs:line 662
   at Microsoft.CodeAnalysis.Workspace.SetCurrentSolutionAsync[TData](Boolean useAsync, TData data, Func`3 transformation, Boolean mayRaiseEvents, Action`3 onBeforeUpdate, Action`3 onAfterUpdate, CancellationToken cancellationToken) in /_/src/Workspaces/Core/Portable/Workspace/Workspace.cs:line 511
   at Roslyn.Utilities.ValueTaskExtensions.VerifyCompleted[T](ValueTask`1 task, String message) in /_/src/Workspaces/SharedUtilitiesAndExtensions/Compiler/Core/Utilities/ValueTaskExtensions.cs:line 21
   at Microsoft.CodeAnalysis.Workspace.SetCurrentSolution[TData](TData data, Func`3 transformation, Boolean mayRaiseEvents, Action`3 onBeforeUpdate, Action`3 onAfterUpdate) in /_/src/Workspaces/Core/Portable/Workspace/Workspace.cs:line 472
   at Microsoft.CodeAnalysis.Workspace.OnDocumentClosedEx(DocumentId documentId, TextLoader reloader, Boolean requireDocumentPresentAndOpen) in /_/src/Workspaces/Core/Portable/Workspace/Workspace_Editor.cs:line 650
   at Microsoft.CodeAnalysis.PdbSourceDocument.PdbSourceDocumentMetadataAsSourceFileProvider.TryRemoveDocumentFromWorkspace(MetadataAsSourceWorkspace workspace, String filePath) in /_/src/Features/Core/Portable/PdbSourceDocument/PdbSourceDocumentMetadataAsSourceFileProvider.cs:line 385
   at Microsoft.CodeAnalysis.MetadataAsSource.MetadataAsSourceFileService.TryRemoveDocumentFromWorkspace(String filePath) in /_/src/Features/Core/Portable/MetadataAsSource/MetadataAsSourceFileService.cs:line 203
   at Microsoft.CodeAnalysis.LanguageServer.LspMiscellaneousFilesWorkspace.TryRemoveMiscellaneousDocument(Uri uri, Boolean removeFromMetadataWorkspace) in /_/src/LanguageServer/Protocol/Workspaces/LspMiscellaneousFilesWorkspace.cs:line 80
   at Microsoft.CodeAnalysis.LanguageServer.LspWorkspaceManager.StopTrackingAsync(Uri uri, CancellationToken cancellationToken) in /_/src/LanguageServer/Protocol/Workspaces/LspWorkspaceManager.cs:line 199
   at Microsoft.CodeAnalysis.LanguageServer.Handler.DocumentChanges.DidCloseHandler.HandleNotificationAsync(DidCloseTextDocumentParams request, RequestContext context, CancellationToken cancellationToken) in /_/src/LanguageServer/Protocol/Handler/DocumentChanges/DidCloseHandler.cs:line 36
   at Microsoft.CommonLanguageServerProtocol.Framework.QueueItem`1.StartRequestAsync[TRequest,TResponse](TRequest request, TRequestContext context, IMethodHandler handler, String language, CancellationToken cancellationToken) in /_/src/LanguageServer/Microsoft.CommonLanguageServerProtocol.Framework/QueueItem.cs:line 199
[Error - 16:02:16] [LanguageServerHost] System.ArgumentException: '<Documentf0db74e0-ba1e-46be-a66b-359bdd57bbc8>' is not part of the workspace.
   at Microsoft.CodeAnalysis.Workspace.<>c.<OnDocumentClosedEx>b__213_0(Solution oldSolution, ValueTuple`4 data) in /_/src/Workspaces/Core/Portable/Workspace/Workspace_Editor.cs:line 662
   at Microsoft.CodeAnalysis.Workspace.SetCurrentSolutionAsync[TData](Boolean useAsync, TData data, Func`3 transformation, Boolean mayRaiseEvents, Action`3 onBeforeUpdate, Action`3 onAfterUpdate, CancellationToken cancellationToken) in /_/src/Workspaces/Core/Portable/Workspace/Workspace.cs:line 511
   at Roslyn.Utilities.ValueTaskExtensions.VerifyCompleted[T](ValueTask`1 task, String message) in /_/src/Workspaces/SharedUtilitiesAndExtensions/Compiler/Core/Utilities/ValueTaskExtensions.cs:line 21
   at Microsoft.CodeAnalysis.Workspace.SetCurrentSolution[TData](TData data, Func`3 transformation, Boolean mayRaiseEvents, Action`3 onBeforeUpdate, Action`3 onAfterUpdate) in /_/src/Workspaces/Core/Portable/Workspace/Workspace.cs:line 472
   at Microsoft.CodeAnalysis.Workspace.OnDocumentClosedEx(DocumentId documentId, TextLoader reloader, Boolean requireDocumentPresentAndOpen) in /_/src/Workspaces/Core/Portable/Workspace/Workspace_Editor.cs:line 650
   at Microsoft.CodeAnalysis.PdbSourceDocument.PdbSourceDocumentMetadataAsSourceFileProvider.TryRemoveDocumentFromWorkspace(MetadataAsSourceWorkspace workspace, String filePath) in /_/src/Features/Core/Portable/PdbSourceDocument/PdbSourceDocumentMetadataAsSourceFileProvider.cs:line 385
   at Microsoft.CodeAnalysis.MetadataAsSource.MetadataAsSourceFileService.TryRemoveDocumentFromWorkspace(String filePath) in /_/src/Features/Core/Portable/MetadataAsSource/MetadataAsSourceFileService.cs:line 203
   at Microsoft.CodeAnalysis.LanguageServer.LspMiscellaneousFilesWorkspace.TryRemoveMiscellaneousDocument(Uri uri, Boolean removeFromMetadataWorkspace) in /_/src/LanguageServer/Protocol/Workspaces/LspMiscellaneousFilesWorkspace.cs:line 80
   at Microsoft.CodeAnalysis.LanguageServer.LspWorkspaceManager.StopTrackingAsync(Uri uri, CancellationToken cancellationToken) in /_/src/LanguageServer/Protocol/Workspaces/LspWorkspaceManager.cs:line 199
   at Microsoft.CodeAnalysis.LanguageServer.Handler.DocumentChanges.DidCloseHandler.HandleNotificationAsync(DidCloseTextDocumentParams request, RequestContext context, CancellationToken cancellationToken) in /_/src/LanguageServer/Protocol/Handler/DocumentChanges/DidCloseHandler.cs:line 36
   at Microsoft.CommonLanguageServerProtocol.Framework.QueueItem`1.StartRequestAsync[TRequest,TResponse](TRequest request, TRequestContext context, IMethodHandler handler, String language, CancellationToken cancellationToken) in /_/src/LanguageServer/Microsoft.CommonLanguageServerProtocol.Framework/QueueItem.cs:line 199
   at Microsoft.CommonLanguageServerProtocol.Framework.QueueItem`1.StartRequestAsync[TRequest,TResponse](TRequest request, TRequestContext context, IMethodHandler handler, String language, CancellationToken cancellationToken) in /_/src/LanguageServer/Microsoft.CommonLanguageServerProtocol.Framework/QueueItem.cs:line 241
   at Microsoft.CodeAnalysis.LanguageServer.RoslynRequestExecutionQueue.WrapStartRequestTaskAsync(Task nonMutatingRequestTask, Boolean rethrowExceptions) in /_/src/LanguageServer/Protocol/RoslynRequestExecutionQueue.cs:line 40
   at Microsoft.CommonLanguageServerProtocol.Framework.RequestExecutionQueue`1.ProcessQueueCoreAsync[TRequest,TResponse](IQueueItem`1 work, IMethodHandler handler, RequestHandlerMetadata metadata, ConcurrentDictionary`2 concurrentlyExecutingTasks, CancellationTokenSource currentWorkCts, CancellationToken cancellationToken) in /_/src/LanguageServer/Microsoft.CommonLanguageServerProtocol.Framework/RequestExecutionQueue.cs:line 349
   at Microsoft.CommonLanguageServerProtocol.Framework.RequestExecutionQueue`1.InvokeProcessCoreAsync(IQueueItem`1 work, RequestHandlerMetadata metadata, IMethodHandler handler, MethodInfo methodInfo, ConcurrentDictionary`2 concurrentlyExecutingTasks, CancellationTokenSource currentWorkCts, CancellationToken cancellationToken) in /_/src/LanguageServer/Microsoft.CommonLanguageServerProtocol.Framework/RequestExecutionQueue.cs:line 302
   at Microsoft.CommonLanguageServerProtocol.Framework.RequestExecutionQueue`1.ProcessQueueAsync() in /_/src/LanguageServer/Microsoft.CommonLanguageServerProtocol.Framework/RequestExecutionQueue.cs:line 254
[Info  - 16:02:16] Error processing queue, shutting down
[Error - 16:02:16] Request textDocument/diagnostic failed.
  Message: Server was requested to shut down.
  Code: -32000
[object Object]
[Error - 16:02:16] Document pull failed for text document file:///home/whitecat/Documents/Godot/Puzzle/scripts/elements/FloorButton.cs
  Message: Server was requested to shut down.
  Code: -32000
[object Object]
[Error - 16:02:16] Request textDocument/diagnostic failed.
  Message: Server was requested to shut down.
  Code: -32000
[object Object]
[Error - 16:02:16] Document pull failed for text document file:///home/whitecat/Documents/Godot/Puzzle/scripts/elements/LaserCatcher.cs
  Message: Server was requested to shut down.
  Code: -32000
[object Object]
[Error - 16:02:16] Request textDocument/diagnostic failed.
  Message: Server was requested to shut down.
  Code: -32000
[object Object]
[Error - 16:02:16] Document pull failed for text document file:///home/whitecat/Documents/Godot/Puzzle/scripts/areas/TriggerSubtitle.cs
  Message: Server was requested to shut down.
  Code: -32000
[object Object]
[Error - 16:02:16] Request textDocument/diagnostic failed.
  Message: Server was requested to shut down.
  Code: -32000
[object Object]
[Error - 16:02:16] Document pull failed for text document file:///home/whitecat/Documents/Godot/Puzzle/scripts/elements/LaserCatcher.cs
  Message: Server was requested to shut down.
  Code: -32000
[object Object]
[Error - 16:02:16] Request textDocument/diagnostic failed.
  Message: Server was requested to shut down.
  Code: -32000
[object Object]
[Error - 16:02:16] Document pull failed for text document file:///home/whitecat/Documents/Godot/Puzzle/scripts/elements/FloorButton.cs
  Message: Server was requested to shut down.
  Code: -32000
[object Object]
[Error - 16:02:16] Request textDocument/diagnostic failed.
  Message: Server was requested to shut down.
  Code: -32000
[object Object]
[Error - 16:02:16] Document pull failed for text document file:///home/whitecat/Documents/Godot/Puzzle/scripts/elements/FloorButton.cs
  Message: Server was requested to shut down.
  Code: -32000
[object Object]
[Error - 16:02:16] Request textDocument/diagnostic failed.
  Message: Server was requested to shut down.
  Code: -32000
[object Object]
[Error - 16:02:16] Document pull failed for text document file:///home/whitecat/Documents/Godot/Puzzle/scripts/elements/LaserCatcher.cs
  Message: Server was requested to shut down.
  Code: -32000
[object Object]
[Error - 16:02:16] Request textDocument/diagnostic failed.
  Message: Server was requested to shut down.
  Code: -32000
[object Object]
[Error - 16:02:16] Document pull failed for text document file:///home/whitecat/Documents/Godot/Puzzle/scripts/areas/TriggerSubtitle.cs
  Message: Server was requested to shut down.
  Code: -32000
[object Object]
[Info  - 16:02:16] Connection to server got closed. Server will restart.
true
Using dotnet configured on PATH
Dotnet path: /usr/lib/dotnet/dotnet
Activating C# + C# Dev Kit...
waiting for named pipe information from server...
[stdout] fail: Microsoft.CodeAnalysis.LanguageServer.ExportProviderBuilder[0]
      /home/whitecat/.vscode/extensions/ms-dotnettools.csharp-2.46.32-linux-x64/.xamlTools/Microsoft.VisualStudio.DesignTools.CodeAnalysis.dll with assembly name Microsoft.VisualStudio.DesignTools.CodeAnalysis, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a conflicts with extension loaded from /home/whitecat/.vscode/extensions/ms-dotnettools.csharp-2.46.32-linux-x64/.xamlTools
fail: Microsoft.CodeAnalysis.LanguageServer.ExportProviderBuilder[0]
      /home/whitecat/.vscode/extensions/ms-dotnettools.csharp-2.46.32-linux-x64/.xamlTools/Microsoft.VisualStudio.DesignTools.CodeAnalysis.Diagnostics.dll with assembly name Microsoft.VisualStudio.DesignTools.CodeAnalysis.Diagnostics, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a conflicts with extension loaded from /home/whitecat/.vscode/extensions/ms-dotnettools.csharp-2.46.32-linux-x64/.xamlTools
[stdout] {"pipeName":"/tmp/c8bddea7.sock"}
received named pipe information from server
attempting to connect client to server...
client has connected to server
[Info  - 16:02:17] [Program] Language server initialized

This extension only supports Godot 3, and IntelliSense is not provided by this extension anyway. That's provided by Microsoft's C# extension so issues with IntelliSense should be reported there.


Read supported/released/EOL versions from api

We maintain a list of releases in get.opensuse.org / https://github.com/openSUSE/get-o-o
Json including product names, versions (15.5, 15.6, 16.0), state (Alpha, Beta, RC, Stable,  EOL) can be accessed here
https://get.opensuse.org/api/v0/distributions.json
I think the only requirement here is that we shall not need to add  extra dependencies to Leap Micro

This is already implemented.


18

closes #18

@rultor merge

@rultor merge

@l3r8yj Done! FYI, the full log is here (took me 1min)


Add version command to pypodman

pypodman does not currently support the version command.  We want to
have as close to the same functionality between podman and pypodman,
so adding this command.
Signed-off-by: Daniel J Walsh<EMAIL_ADDRESS>

@jwhonce @baude PTAL

/approve

I'm not sure where, but git looks to be complaining about some whitespace errors.
GIT_CHECK_EXCLUDE="./vendor" /go/bin/git-validation -v -run DCO,short-subject,dangling-whitespace -range 921ccac10c47e0865ec5e4ba00ebb69a03d89473..HEAD
 * b4cbca21 "Add version command to pypodman" ... FAIL
  - FAIL - has whitespace errors. See `git show --check b4cbca21cb0609ca5446c1320e49a705d53d6f3f`.
  - PASS - has a valid DCO
  - PASS - commit subject is 72 characters or less! *yay*

LGTM, but would like a head nod from @jwhonce

@TomSweeneyRedHat Validate found another issue and the whitespace problem was the new program ended in a blank line.

@TomSweeneyRedHat or @jwhonce could you /lgtm this?

@giuseppe @vrothberg @mheon @baude Could someone enter /lgtm

/lgtm


Implement support for selecting basic keep_alive times for Ollama

Pull Request Type

[x] ✨ feat
[ ] 🐛 fix
[ ] ♻ refactor
[ ] 💄 style
[ ] 🔨 chore
[ ] 📝 docs

Relevant Issues

resolves #1902
What is in this change?

Additional Information

Developer Validations

[x] I ran yarn lint from the root of the repo & committed changes
[x] Relevant documentation has been updated
[x] I have tested my code functionality
[x] Docker build succeeds locally

Wow, this is quick work. Thanks very much for implementing, @timothycarambat !

will be in the next desktop update if you are on that client 👍


Remove legacy components

There are many legacy components that have been deprecated over the years. Remove these entirely for 8.0

Done


Upgrading Next from 12 to 13

What is the purpose of the change
It is a continuation of PR https://github.com/osmosis-labs/osmosis-frontend/pull/2232, on the previous branch I had made a mistake with the rebase and I didn't want to mess up the comment history

@DavideSegullo I just noticed that after the upgrade images are way bigger than in prod
Before:

After:

@DavideSegullo I just noticed that after the upgrade images are bigger than in prod
Before:

After:

I'll give a look

@DavideSegullo I just noticed that after the upgrade images are bigger than in prod
Before:

After:

I fixed this one, now I see if there are others, some I had already fixed, it happens because they changed the behavior of "next/image"

Approved the deploy. Let's make sure to have QA take a look before merging

@DavideSegullo if you rebase and fix the conflicts, I can approve the deploys and we can hopefully get this merged this week! A huge help!

Done


Post Message To Page's Wall

Hello, i try to post message to page's wall.
based on https://developers.facebook.com/docs/graph-api/reference/v2.3/page/feed
But always get error (#200) Insufficient permission to post to target on behalf of the viewer"
This is my post code
Facebook::object('{page_id}/feed')->with($status_update)->post()
if i change with
Facebook::object('me/feed')->with($status_update)->post()
it's working well, but it post to my wall
And this is my default scope config
'default_scope' => ['manage_pages','email','public_profile','user_friends','publish_actions','publish_pages'],
Anyone can explain why? Is there something i missing?

The access token you're using to publish the post must be a valid user or page access token with the proper permissions.
Has the page you're trying to post to been published yet or is it still private? Have you tried to post to the page using the Graph API Explorer?

Yes, i had post using Graph API Explorer and it's working well, the message appear on page's wall.
how to test the token, to make sure the token is valid?

how to test the token, to make sure the token is valid?

You can debug the token by using the /debug_token endpoint.

Hello, my website can posting to page's wall after i call user account object
Facebook::object('me/accounts')->get();
(https://developers.facebook.com/docs/facebook-login/access-tokens#pagetokens) and use access_token from response that API/function
Thanks for your help :)

Ah yes - that would be a page access token. Glad you figured it out! :)


Update collect-logs to include Microsoft SQL example

Purpose of this pull request
This pull request...
Select the type of change

[x] Minor Changes - Typos, formatting, slight revisions
[ ] Update Content - Revisions, updating sections
[ ] New Content - New features, sections, pages, tutorials
[ ] Site and Tools - .clabot, version updates, maintenance, dependencies, new packages for the site (Docusaurus, Gatsby, React, etc.)

Ticket (if applicable)

@itsthepo, if you remove "Open Source Collection Team" as a reviewer, I can go ahead and merge the PR.

@jpipkin1 I can't seem to remove them

@itsthepo, I'll go ahead and push through the merge without review from the "Open Source Collection Team".


remove GodotObject protocol

It doesn't seem like the GodotObject protocol has any reason to exist. This patch removes it.

The protocol has no requirements.

There is exactly one directly conforming type: Object. All descendants of Object inherit the conformance, but any constraint requiring GodotObject conformance could be rewritten to instead require Object inheritance.

There are three functions with GodotObject constraints:

VariantStorable.makeOrUnwrap
Variant.asObject
lookupObject

All test cases pass if I change these constraints to require Object inheritance instead of GodotObject conformance.

apparently all test cases do NOT pass ha ha