[SR-460] Provide XCTestCase a class to allow overriding setUp() and tearDown()

What is it?
This PR renames the XCTestCase protocol to XCTestCaseType and introduces a new XCTestCase class in its place which individual test cases may derive from. A relevant test case is also included (see below).
Motivation
Providing XCTestCase as just a protocol rather than a class is a great concept, however it presents an insurmountable barrier to achieving source-level compatibility with Darwin XCTest with respect to defining setUp() and tearDown() methods in test cases, because the override keyword is required when inheriting (Darwin XCTest) but is prohibited when just conforming to the protocol (Corelibs XCTest). With this patch, it becomes possible to write a test case utilizing setUp() and tearDown() which builds with both frameworks. Here is the example from SR-460:
import XCTest

class Test: XCTestCase {
    var allTests: [(String, () -> Void)] { return [("testExample", testExample)] }

    override func setUp() {
        super.setUp()
    }

    override func tearDown() {
        super.tearDown()
    }

    func testExample() {
        XCTAssertEqual(1, 1)
    }
}

Drawbacks
There is one significant caveat to this change: test cases deriving from the new XCTestCase class must still explicitly declare conformance to the XCTestCaseType protocol before they can be passed to XCTMain, which makes this a breaking change for current users of Corelibs XCTest. (The XCTestCase base class can't conform to XCTestCaseType without losing compile-time checking that individual test cases provide an allTests property for their own tests.) I see two reasonable approaches to this for cross-platform tests:

Conditionally redeclare XCTestCaseType on Apple platforms, and conform to the protocol in-line for each test case. This is essentially what swiftpm is currently doing (see here and here).
Add XCTestCaseType conformance in a separate source file (perhaps the main.swift entry point which contains the call to XCTMain). I can easily imagine running a script as a part of the build process which dynamically generates a source file adding this conformance to each test case class. Such a script could even be made to generate the allTests property implementation automatically as well.

Rejected Alternatives
I considered a couple of variants before settling on the current contents of this patch. Note that neither of these include the XCTestCaseType protocol:

Convert the XCTestCase protocol into a class which conforms to XCTestCaseProvider. In this version, the base XCTestCase class included an empty allTests definition. This was rejected both because it required individual test cases to mark their allTests definitions as override, and because there would be no compile-time checking that an overridden allTests was present at all.
Convert the XCTestCase protocol into a class which does not conform to XCTestCaseProvider. In this implementation, XCTMain remained unchanged, and accepted an array of XCTestCase classes. This fared poorly because it required a runtime check that individual test cases conform to XCTestCaseProvider, which felt like a missed opportunity to leverage the type system.

I look forward to getting feedback and iterating on this!
@mike-ferris-apple @eschaton @modocache

Oh man, thank you for this proposal. The other day I was trying to implement XCTestObservation in swift-corelibs-xctest, and realized that it doesn't really work unless we have XCTestCase instances, and those have XCTestRun attributes. I think this direction would open up a lot of possibilities.
A few questions:

In Darwin XCTest, a new test case instance is instantiated for each test run. How would you feel about doing so here as well?
Is there an equivalent to NS_REQUIRES_SUPER in Swift? It would be nice to remind users to call super.setUp() and super.tearDown().
It is a shame test cases must inferit/conform to two things: XCTestCase, XCTestCaseType is a lot of typing. Upon first glance your second "rejected alternative", of checking at runtime, seems like it has potential... I'll need to stew on this more.

I'm also very interested in what the core team thinks here.

I have been intending to make a similar change as well.
If we have XCTestCase as a base class, I am wondering what advantage we really get having the XCTestCase protocol (XCTestCaseType in your proposal), though, and even what benefit we’re really getting from XCTestCaseProvider. I had more or less planned to remove both the protocols in favor of implementing an XCTestCase base class.
For me, these changes were motivated by wanting to implement XCTestObservation (as Brian G. talks about below.)

On Jan 14, 2016, at 11:49 AM, Brian Gesiak<EMAIL_ADDRESS>wrote:
Oh man, thank you for this proposal. The other day I was trying to implement XCTestObservation in swift-corelibs-xctest, and realized that it doesn't really work unless we have XCTestCase instances, and those have XCTestRun attributes. I think this direction would open up a lot of possibilities.

In my change for this I had been avoiding introducing XCTestRun.

A few questions:
In Darwin XCTest, a new test case instance is instantiated for each test run. How would you feel about doing so here as well?

For XCTestObservation to be useful, we will need to do this. This will also most likely require that XCTMain change to take XCTestCase classes instead of instances. (And that will require some coordination of changes in the two main projects that are clients of XCTest… corelibs Foundation and the package manager).

Is there an equivalent to NS_REQUIRES_SUPER in Swift? It would be nice to remind users to call super.setUp() and super.tearDown().
It is a shame test cases must inferit/conform to two things: XCTestCase, XCTestCaseType is a lot of typing. Upon first glance your second "rejected alternative", of checking at runtime, seems like it has potential... I'll need to stew on this more.
I'm also very interested in what the core team thinks here.
—
Reply to this email directly or view it on GitHub https://github.com/apple/swift-corelibs-xctest/pull/40#issuecomment-171759090.

Mike

Cool. I had been trying to preserve the protocol to avoid locking things down too much, but it sounds like things are headed towards a place that requires a tighter interface. I've now pushed some modified commits which do away with the protocols as @mike-ferris-apple suggested. The original branch with the XCTestCaseType protocol is still available here for reference.
I have started prototyping some changes that would allow a new XCTestCase instance to be used for each test, but none of that is included in this PR.

When we take this pull request, we're going to need existing clients to update code, right? (At least they'll be adding the "override" on their allTests, and on setUp() and tearDown() if they have them.)
We're going to have to coordinate with the foundation and package manager projects to get patches for their tests to go in at the same time these changes go.
When we change the execution semantics to an instance per test, we will also need to make another source breaking change. I think it might be good to do that at the same time so we will hopefully not have to do another coordinated patch of foundation and package manager at that time.
I would recommend we change the signature of XCTMain() to be:
func XCTMain(testCaseClasses: [XCTestCase.Type])

In addition, I found it useful to change allTests into a dictionary when I was prototyping the change to the execution model as well:
public var allTests: [String: () -> Void]

How do you feel about making these changes pre-emotively as well to minimize the number of changes we're having to coordinate with the two major clients?

One additional detail about allTests  as a dictionary... this removes ordering from allTests. To replace that, I was sorting the tests by name. This makes it less practical to order tests specifically, but actually that's arguably a bad thing to do, especially if/when a test harness starts allowing executing subsets of test cases. Allowing ordering dependencies between test cases work against having suites that can be decomposed cleanly.

We can react quickly in Foundation once you make this change, so don't worry about that part (cc @phausler). @ddunbar probably should just have a heads up as well for the package manager.

I found it useful to change allTests into a dictionary

This forces all tests to have unique names. An interesting aspect of the current tuple-based API is that tests need not be uniquely named within a test case. I actually consider this to be a feature; XCTest/Xcode integration implicitly requires test selectors to be unique, which causes subtle problems when dynamically generating test methods. See: https://github.com/specta/specta/pull/83#issuecomment-45304370
I'm not against requiring each test method name to be unique within a test case, provided there's a benefit to doing so. What's the upside here?

The one problem with this is that the tests won't be portable to Darwin. Because there will be an override that isn't overriding anything.
I find it quite nice that I can copy/paste most tests across and run them against the Foundation that ships with Mac OS X.

Arg!  Good point. Note that part of the motivation here was to solve the opposite problem with setUp() and tearDown().
Not sure what to do here. If we keep that in the TestProvider protocol then all tests need to do the double inheritance (and actually that probably creates its own problems with the portability of tests).
One possibility would be to add allTests to XCTestCase in the overlay so it’s an override in Xcode as well.  I am not thrilled with that and would want to talk it through more here and with the rest of the Xcode XCTest folks as well…
Any other options?
Mike

On Jan 19, 2016, at 10:25 AM, Philippe Hausler<EMAIL_ADDRESS>wrote:
The one problem with this is that the tests won't be portable to Darwin. Because there will be an override that isn't overriding anything.
I find it quite nice that I can copy/paste most tests across and run them against the Foundation that ships with Mac OS X.
—
Reply to this email directly or view it on GitHub https://github.com/apple/swift-corelibs-xctest/pull/40#issuecomment-172942070.

Can setUp and tearDown come from inheritance and allTests come from protocol conformance?

We would probably then require an empty protocol of the same name on Darwin to avoid having clients #ifdef. That's not really that great either.

Perhaps there’s a better way to do this, but in order to prototype the execution model I wound up needing to instantiate an instance just to get the test list. Then as the tests are being run an instance has to be created to actually run each test case. The problem was that you need to use the closure from allTests for the instance that is going to run each test, so the initial instance gathered up the names and then passed each one into the instance that was going to run an individual test and it would look the closure up in allTests for that instance to get a block bound to the right self.  Having the dictionary allowed that lookup not to be linear.
It may be that there’s a cleverer way than I could think of to do this better.   If we can’t come up with a different approach, we could keep allTests as an array if we were willing to search it linearly, but that winds up being n-squared on the number of tests since we have to search once for each test.
Mike

On Jan 19, 2016, at 10:19 AM, Brian Gesiak<EMAIL_ADDRESS>wrote:
I found it useful to change allTests into a dictionary
This forces all tests to have unique names. An interesting aspect of the current tuple-based API is that tests need not be uniquely named within a test case. I actually consider this to be a feature; XCTest/Xcode integration implicitly requires test selectors to be unique, which causes subtle problems when dynamically generating test methods. See: specta/specta#83 (comment) https://github.com/specta/specta/pull/83#issuecomment-45304370
I'm not against requiring each test method name to be unique within a test case, provided there's a benefit to doing so. What's the upside here?
—
Reply to this email directly or view it on GitHub https://github.com/apple/swift-corelibs-xctest/pull/40#issuecomment-172939570.

Yeah, if we’re doing that, I’d rather add allTests to XCTestCase in Xcode… At least then people wouldn’t need to have two things in their inheritance list every time.
Mike

On Jan 19, 2016, at 10:38 AM, Tony Parker<EMAIL_ADDRESS>wrote:
We would probably then require an empty protocol of the same name on Darwin to avoid having clients #ifdef. That's not really that great either.
—
Reply to this email directly or view it on GitHub https://github.com/apple/swift-corelibs-xctest/pull/40#issuecomment-172945334.

in order to prototype the execution model I wound up needing to instantiate an instance just to get the test list

I believe this is why, in Apple XCTest, +[XCTestCase testInvocations] is a class method. That way, you don't need to instantiate a test case in order to gather its tests. Apple XCTest then uses the -[XCTestCase initWithInvocation:] initializer to instantiate the test case to run the test. Could we change allTests to a static var or func?

The problem was that you need to use the closure from allTests for the instance that is going to run each test, so the initial instance gathered up the names and then passed each one into the instance that was going to run an individual test and it would look the closure up in allTests for that instance to get a block bound to the right self.  Having the dictionary allowed that lookup not to be linear.

In my experience, the most time-expensive aspect of Apple XCTest was XPC communication between the XCTest driver, Xcode, and the XCTest host on the iOS/tvOS/watchOS device/simulator. My gut is to not worry too much about linear lookups until they demonstrate themselves to be a performance bottleneck--but that's just my two cents! :money_with_wings:

We would probably then require an empty protocol of the same name on Darwin to avoid having clients #ifdef. That's not really that great either.

Uh-oh, somebody better tell Joar. :wink:
I'm hesitant to advocate adding this API to Apple XCTest. Perhaps we could migrate away from +[XCTestCase testInvocations] to something that we could use here, but even then, I imagine any API churn on Apple XCTest will be an extremely hard sell.

On Jan 19, 2016, at 11:02 AM, Brian Gesiak<EMAIL_ADDRESS>wrote:
in order to prototype the execution model I wound up needing to instantiate an instance just to get the test list
I believe this is why, in Apple XCTest, +[XCTestCase testInvocations] is a class method. That way, you don't need to instantiate a test case in order to gather its tests. Apple XCTest then uses the -[XCTestCase initWithInvocation:] initializer to instantiate the test case to run the test. Could we change allTests to a static var or func?

NSInvocation has the -setTarget: method, though. In Swift, if you implement allTests as a class property it returns unbound test closures which changes the signature. And, not only that, but getting the typing right proved to be problematic…  You would want testClosure(self: XCTestCase.Type) but when you take a closure for a method on MyTestCaseSubclass you get a closure of type testClosure(self: MyTestCaseSubclass.Type) which is not compatible with the first signature.
Someone with more generic Swift-fu than I might be able to come up with a way around this…

The problem was that you need to use the closure from allTests for the instance that is going to run each test, so the initial instance gathered up the names and then passed each one into the instance that was going to run an individual test and it would look the closure up in allTests for that instance to get a block bound to the right self. Having the dictionary allowed that lookup not to be linear.
In my experience, the most time-expensive aspect of Apple XCTest was XPC communication between the XCTest driver, Xcode, and the XCTest host on the iOS/tvOS/watchOS device/simulator. My gut is to not worry too much about linear lookups until they demonstrate themselves to be a performance bottleneck--but that's just my two cents!
We would probably then require an empty protocol of the same name on Darwin to avoid having clients #ifdef. That's not really that great either.
Uh-oh, somebody better tell Joar https://twitter.com/joar_at_work.
I'm hesitant to advocate adding this API to Apple XCTest. Perhaps we could migrate away from +[XCTestCase testInvocations] to something that we could use here, but even then, I imagine any API churn on Apple XCTest will be an extremely hard sell.

I wouldn’t mind migrating Xcode’s XCTest toward something more swift-y than +testInvocations if we could figure out a good approach. Probably something more block-y. And potentially this could be staged in as a new primitive that is implemented in terms of +testInvocations to avoid disruption, but the first thing would be figuring out what we do want.
Mike

Thanks for the discussion around this guys. I completely agree that we should aim to consolidate the breaking changes required for these two features.
When I was hacking on the instance-per-test concept before (WIP here), I ran into precisely the same issues that @mike-ferris-apple describes. I still have a couple of other ideas to work around the generics-related issues when making allTests a class variable - probably involving a thunk/type eraser of some sort when calling into XCTMain. I'll update once (if?) I figure out a way to make it syntactically palatable.

Sorry for the slow turnaround on this.
After much wrangling with the type system, I have ended up with two approaches, either of which I would be happy to see merged. I've pushed my preferred option to this PR's branch, and the alternative one to another branch. Both branches include additional test cases covering the newly-introduced behaviors.
To recap, the requirements I was aiming to meet are:

Source code compatibility by allow test cases to override setUp() and tearDown(), including super calls, with same syntax as Xcode's XCTest
Source code compatibility by ensuring that the allTests property need not be marked as override
Behavioral compatibility by executing each test method with a new instance of its test case object

One set of changes is shared by the two branches. The two source code compatibility requirements demand that XCTestCase be a class which defines setUp() and tearDown(), but not allTests. However since the test runner requires access to all three of these, I have defined an XCTestCaseType protocol which unifies them. This does require test cases to declare an extra protocol conformance, however I know of no way around that. I additionally dropped XCTestCaseProvider as I failed to see any continued benefit to its existence as an independent protocol.
XCTMain's signature then becomes: @noreturn public func XCTMain(testCases: [XCTestCaseType.Type])
The two branches vary in their handling of the allTests property.

This current branch achieves the goal of turning allTests into a static property. It solves the generics-related challenges that @mike-ferris-apple described so clearly above by providing a generic adapter function which performs the type erasure necessary to keep allTests non-generic. Test cases' allTests declarations thus take the following form:
static var allTests: [(String, XCTestCaseType throws -> Void)] {
    return [
        ("test_passes", test(test_passes)),
    ]
}

In my opinion the only drawback to this approach is that it requires the use of this new test function when declaring allTests, however I feel that this is fairly minor, considering that this is in a block of code which is specific to Corelibs XCTest users anyway. (I also still think that we should investigate the feasibility of providing a build-time tool that would automatically generate a file adding allTests and XCTestCaseType conformances, but that's a separate issue.)

The other branch keeps allTests as an instance property, and is very similar to what I assume @mike-ferris-apple prototype (mentioned above) must have looked like. It suffers from the problem described above of requiring N+1 instantiations of the test case, and needing re-execute allTests on each test case instance and looking up tests by name within the returned collection. This branch keeps allTests as an array (with the associated extra lookup cost), however it would be trivial to change it to be a dictionary as previously described.

I'm looking forward to getting feedback on these branches. Note that in either case, documentation updates (particularly in the README) would still be required before any merge would be completed.

I wanted to at least reply as it may be a few days before I can look at these in detail.
Conceptually the notion of saying test(testMethod) in the allTests seems like a small price to pay. I’ll try to shop this idea around with some folks here who may not be following this discussion as closely including the foundation and package manager folks.
Thanks Brian!
Mike

On Jan 22, 2016, at 7:43 AM, Brian Croom<EMAIL_ADDRESS>wrote:
Sorry for the slow turnaround on this.
After much wrangling with the type system, I have ended up with two approaches, either of which I would be happy to see merged. I've pushed my preferred option to this PR's branch, and the alternative one to another branch https://github.com/briancroom/swift-corelibs-xctest/tree/new_instance_for_each_test. Both branches include additional test cases covering the newly-introduced behaviors.
To recap, the requirements I was aiming to meet are:
Source code compatibility by allow test cases to override setUp() and tearDown(), including super calls, with same syntax as Xcode's XCTest
Source code compatibility by ensuring that the allTests property need not be marked as override
Behavioral compatibility by executing each test method with a new instance of its test case object
One set of changes is shared by the two branches. The two source code compatibility requirements demand that XCTestCase be a class which defines setUp() and tearDown(), but not allTests. However since the test runner requires access to all three of these, I have defined an XCTestCaseType protocol which unifies them. This does require test cases to declare an extra protocol conformance, however I know of no way around that. I additionally dropped XCTestCaseProvider as I failed to see any continued benefit to its existence as an independent protocol.
XCTMain's signature then becomes: @noreturn public func XCTMain(testCases: [XCTestCaseType.Type])
The two branches vary in their handling of the allTests property.
This current branch achieves the goal of turning allTests into a static property. It solves the generics-related challenges that @mike-ferris-apple https://github.com/mike-ferris-apple described so clearly above by providing a generic adapter function which performs the type erasure necessary to keep allTests non-generic. Test cases' allTests declarations thus take the following form:
static var allTests: [(String, XCTestCaseType throws -> Void)] {
return [
("test_passes", test(test_passes)),
]
}
In my opinion the only drawback to this approach is that it requires the use of this new test function when declaring allTests, however I feel that this is fairly minor, considering that this is in a block of code which is specific to Corelibs XCTest users anyway. (I also still think that we should investigate the feasibility of providing a build-time tool that would automatically generate a file adding allTests and XCTestCaseType conformances, but that's a separate issue.)
The other branch https://github.com/briancroom/swift-corelibs-xctest/tree/new_instance_for_each_test keeps allTests as an instance property, and is very similar to what I assume @mike-ferris-apple https://github.com/mike-ferris-apple prototype (mentioned above) must have looked like. It suffers from the problem described above of requiring N+1 instantiations of the test case, and needing re-execute allTests on each test case instance and looking up tests by name within the returned collection. This branch keeps allTests as an array (with the associated extra lookup cost), however it would be trivial to change it to be a dictionary as previously described.
I'm looking forward to getting feedback on these branches. Note that in either case, documentation updates (particularly in the README) would still be required before any merge would be completed.
—
Reply to this email directly or view it on GitHub https://github.com/apple/swift-corelibs-xctest/pull/40#issuecomment-173956268.

Thanks for the note, Mike.
When you do get a chance to take a closer look, please consider whether these changes are compatible with preparing for the XCTestObservation work you mentioned in your first reply. I wasn't explicitly targeting that because I didn't fully understand the requirements you had in mind. But, for example, might it be necessary to make XCTestCaseType a class protocol?

Summarizing the changes that implementors have to make:

Update allTests to be static and have the new signature
Update the tuples in allTests to wrap the method name mention with test()
Update the XCTMain call site to add conformance to the XCTestCaseType protocol to each XCTestCase
Update XCTMain itself to pass types (replace the instantiation "()" with ".self" after each class name.

I think I get why all this is necessary, and I agree with @modocache that this seems pretty reasonable, especially considering that the long term goal would be that all this evaporates when we get a solution to automatic discovery.
I am not sure if the observer stuff will require anything more... The observer protocol API that we're in a position to implement are the methods that take an XCTestCase instance. Since invokeTest is implemented on the protocol, this would currently require some down casting... Not sure if there's a way around that?

What about this proposal wouldn't work if we removed the XCTestCaseType protocol and phrased everything in terms of XCTestCase, the class?
I know that we have the issue around allTests needing to override in corelibs but not in Xcode.  Is there anything else that could not be made to work with that approach?

@mike-ferris-apple As you mentioned, the primary concern with scrapping the protocol would be the 'override' keyword. If that issue were worked around by e.g. adding an allTests declaration in the Swift stdlib overlay, the only issue I can think of would be that we would lose compile-time verification that subclasses actually have overridden allTests with their own data. That is a fairly minor concern as it is simple to introduce a failure at runtime in that situation.

Hey @mike-ferris-apple, what do you think is the way forward here? Have you had a chance to talk to any of the folks working on Xcode XCTest about adding a placeholder allTests property on that side? Would you like me to go ahead and update this PR to remove XCTestCaseType again?

I am still trying to get some consensus around adding allTests to the overlay, but I think that would help bring the two versions a bit closer together and I do worry that if we don't make XCTestCase be the main player in terms of types that we'll have further hassles as we look at things like the observation protocol and possibly other APIs that we will likely want to see implemented.

OK, I think we have consensus that we'd rather go the route of adding allTests to Xcode's XCTest Swift overlay in order to be able to make XCTestCase the class be the base type that we're using throughout. Would you be willing to try that approach and revise the pull request?

Certainly! I've got the changes in-progress locally and just need to find a little more time to clean it up and update the documentation around how to use the allTests property and XCTMain for XCTest users.

Alright, I've rebased everything and updated it to do away with the `XCTestCaseType

I agree, I also think this could be merged as-is. I had two suggestions on how it could potentially be improved, but those could be addressed in a separate pull request.
Excellent work, @briancroom! :100:

Well..I've hit another snag in our plan when I was working on adding allTests to the XCTest overlay as discussed. Namely:

As far as I can tell, this marks a dead-end for the plan of allTests in the XCTest overlay. I do have one more idea for an alternative approach that I'm exploring, besides the previously-proposed solution involving the XCTestCaseType protocol.

I'm close to having another attempt ready for this (which doesn't require modifications to the Swift XCTest overlay!), but in the meantime I thought I'd point out this relevant proposal from @jrose-apple: https://github.com/apple/swift-evolution/pull/155

I talked to Jordan and it is unlikely that our particular aspect of this extension/overrie business will be resolved in the near future. It's possible that a solution is in sight for extensions in the same module as the base class (so far so good) but that it won't (yet) cover extensions on Obj-C classes (which is our case here). I'm interested to see your new attempt.

Yep. That's the right proposal, but it hasn't even gotten into formal review yet, and being accepted doesn't mean it'll get implemented promptly either.

@mike-ferris-apple @jrose-apple yup, for sure. I had just thought it was interesting timing that the proposal was posted so shortly after I encountered the issue here.
I've updated the branch with a New & Improved™ variant (past versions available here and here for reference) which checks most of the boxes of goals for this work, while simultaneously not requiring any changes to the XCTest overlay.
To summarize:

Removed protocol usage (no XCTestCaseProvider or XCTestCaseType)
XCTestCase is now a class, allowing setUp() and tearDown() to be overridden methods,
The allTests array on test cases becomes static, facilitating the instantiation of a new test case instance for each test invocation
Changed from the previous iteration is that the type erasure function is now used during the call to XCTMain instead of on the individual test methods in allTests.

This is an updated list of the changes that implementors have to make to work with the new interface:

Update allTests to be static and have the new signature (note that the signature now includes the name of the current test case subclass, so it isn't the exact same for all classes anymore)
Update the XCTMain call to reference test cases like: XCTMain([testCase(TestMe.allTests])

The one element of this that I'm not entirely satisfied with is that the allTests property is no longer specified by any class or protocol in the framework, so its name is just convention. OTOH this could be reasonably regarded as a good thing, although it opens the door for inconsistency. Nonetheless, I am overall very pleased with the state of this branch now.
Also, while testing this out to make sure it would work for existing clients, I went ahead and created branches on swift-corelibs-foundation and swift-package-manager that make them work with these changes. Assuming folks here are comfortable with this branch, I can go ahead and open PR's on the other projects anytime.
/cc @parkera @phausler @mxcl @ddunbar

Bravo! Fantastic work as always. :bouquet:

Update allTests to be static and have the new signature (note that the signature now includes the name of the current test case subclass, so it isn't the exact same for all classes anymore)

[...]
The one element of this that I'm not entirely satisfied with is that the allTests property is no longer specified by any class or protocol in the framework, so its name is just convention.

These points are also my primary concerns with this pull request. I think the proposed version of allTests makes using swift-corelibs-xctest more difficult. But it's also my understanding that we are continuing to pursue a solution in which allTests is automatically determined via reflection of some kind, and I'm willing to sacrifice ease of use in the meantime for the sake of API parity.
All in all, this looks like it should be merged to me! :+1:

@mike-ferris-apple I'd love to get your feedback on the latest round of changes here when you get a chance! If we decide this is the way to go, I'll happily rebase the swiftpm and Foundation PRs to keep internal breakage at a minimum 🙂

So looks like the trick now is that allTests is declared as a static and, as you say, "allTests" becomes convention. It could really be called anything as it is passed to XCTestMain as a block.
Needing to declare allTests with the repeated type in the signature is not ideal, but all things considered, this seems like an approach that actually gets us the most important stuff. We get the Xcode XCTest compatibility with respect to override keywords on things like setUp(). We get XCTestCase as a class and we get an instance per test method.
The downsides are all in the parts that are necessary only because we don't have automatic test discovery.
Did you say you already have pull requests for getting Foundation and swiftpm converted over to this?Go ahead and rebase them.
@parkera, @ddunbar, @mxcl: If you guys OK with these changes, we should coordinate a time to merge all 3 pull requests.

@mike-ferris-apple I'm trying to tackle the automatic discovery here: https://github.com/apple/swift-package-manager/pull/156 I see that with these changes I'd need to slightly modify the way test manifests are generated, so please let me know when that happens.
Honza

@czechboy0 interesting idea; I hadn't thought of using SwiftPM to find the test cases instead of building it into metadata in the runtime.

@mike-ferris-apple This seems reasonable to me. CC @phausler

the idea seems pretty solid as an approach. What would we need to do for swift-corelibs-foundation? How can one disable tests with this approach? or exclude them from certain platforms? So this means we can get rid of the main.swift in our test project and the allTests perhaps? If we can do that a big :+1:

@mike-ferris-apple I just opened https://github.com/apple/swift-package-manager/issues/158 and https://github.com/apple/swift-corelibs-foundation/issues/270 with the required changes for those projects. This should allow us to move forward with merging these changes in even before @czechboy0's (exciting!) work is ready to go.

@briancroom :+1: Only a small change will be required in the new test manifest generator once this gets merged.

OK. I checked with @mxcl and @parkera and got the go ahead.  Assuming all three of these patches can be cleanly merged in the morning, I will do it then.

@swift-ci please test

I just rebased them all now, so hopefully they will still be good to go then.

OK. In that case, let's go now.  All three have been merged.

Awesome! Thanks for doing the honors @mike-ferris-apple :tada:
I appreciate everyone that's been involved in the discussions around this over the past weeks and thanks for your patience through all the iterations :smile:


setWebhook discards url parameter?

https://github.com/edisonchee/slimbot/blob/e173be2e4a1fedec17a5e80dd52835c7279c8441/src/telegram.js#L56
You can see that url isn't propagated forward - which means the correct usage of setWebhook would be:
slimbot.setWebhook(null, {'url':MY_URL});
instead of
slimbot.setWebhook(MY_URL);
which actually deletes any webhooks that are set up.

Thanks @abl for the catch!


Python 3.6 Syntax highlighting of imports no longer works.

Does this issue occur when all extensions are disabled?: Yes

VS Code Version:  1.74.2
OS Version:  windows 10

Steps to Reproduce:

Open VScode with python 3.6.x as python interpreter

When using python 3.6 the highlighting of imports does not occur leaving them as white text strings. This also impacts all instances of imported elements.

This is also happening to me after updating on Ubuntu 18.04 LTS - I believe it's because the interpreter is not being discovered and set?

This appears to be an issue with the vscode-python. Please use the Python: Report issue command to report this issue.
cc: @karrtikr
Related: https://github.com/microsoft/vscode/issues/170592


Classes shouldn't be defined in method bodies

It's just a maze of unknown semantics and backend bugs. Specifically, quasar.api.Zip places a lot of definitions in a method body which should be lifted out. It will avoid the various warnings/errors related to this class which have been seen, such as "classfile missing, continuing with a stub" and this comment from build.sbt:
     // Try again once the new backend is more stable. Specifically, it would appear the Op class in Zip
     // causes problems when recompiling code in sbt without running `clean` in between.

This can be found at https://github.com/paulp/quasar/tree/zip-in-method-body and it should be all good to go, but I'm tied up with something else at the moment.

#1353.


iOS: Any plan to remove UIWebView and use WKWebView instead?

Hi,
Recently people has started receiving this warning when submitting apps that have references to UIWebView.

ITMS-90809: Deprecated API Usage - Apple will stop accepting submissions of apps that use UIWebView APIs.

Here's a Twitter thread from one Apple dev on the topic: https://twitter.com/NiklasMaerz/status/1167031874738434048
Although our app (which used this plugin) has not received the warning yet, but I find this plugin also uses UIWebView:
https://github.com/EddyVerbruggen/SocialSharing-PhoneGap-Plugin/blob/4740df80faabf38cccc7d66803769690205fc0d6/src/ios/SocialSharing.m#L37
So is there any plan to remove UIWebView reference and use WKWebView instead?
Thanks.

I've removed it in 5.6.0 so the iPadPopupCoordinates feature no longer works until someone makes it WKWebView compatible.

Nice. We must be on an old version as we still saw references. Will upgrade thank you. For this interested https://cordova.apache.org/howto/2020/03/18/wkwebviewonly.html


Error 404 in RoutingMiddleware

Hi there,
after the installation as per documentation, when using composer start I can see the proper Welcome page at localhost:8080.
However, when I use my local XAMPP Apache server and navigate to the installation public folder (e.g. http://localhost/slim4/public) I get a 404 error:
Error 404 (Not Found)
Message: Not found.
File: D:\Web\htdocs\slim4\vendor\slim\slim\Slim\Middleware\RoutingMiddleware.php, Line: 76

Any idea why that is?
Best regards,
George

The reason is that public/ should be the document root in Apache. So try to remove public from the url path.

That was it. Sorry for that. Could have tried that myself.
Thanks and best regards,
George


Add support for checking if Datadog integration is enabled

Context
The current implementation is most services today is to assume that a miss configured Datadog integration should be disabled. This works fine in local development environment, but causes issues in production like environments when the Datadog configuration is bad. With a bad configuration the service will start as normal, but no APM data or traces will be sendt. This is an implicit behaviour and it does not help our engineers.
Proposal
Implement an environment variable that if set to false disables the Datadog integration. If the environment variable is not set it should be assumed to be true.
isEnabled() can be implemented inside of StartDatadog() so that no code changes are required by consuming services.
If isEnabled() returns true we call config.Validate(), if there is a configuration error we return that and do not start Datadog.
This will allow us to remove Datadog configuration validation from services leaving less boilerplate code.

I agree with the proposal.
Discussion: How should the middleware interact with such an enabling/disabling?

Return a no-op middleware (e.g. no-op gRPC interceptor, or just return the original http.Client)
Always return a valid middleware/interceptor, and leave the enabled-checking to the caller.

I propose we go with option 1

@bendiknesbo I think a no-op on disabled, but fails on bad config for midlewares/interceptors as well.
I do not think service implementors should have to explicitly check if a config is valid or not. Keeping it an option as we have today is fine (for now).


Allocator::clone causes multiple vmaDestroyAllocator calls

Allocator::clone causes a double free because it allows the Allocator object to be dropped multiple times.
Example
let harness = TestHarness::new();
let x = harness.create_allocator();
let y = x.clone();

What happens

Allocator X gets cloned to Allocator Y, including its pointer to the underlying ffi Allocator self.internal.
Allocator Y gets dropped, its cloned pointer to self.internal is not null so it calls vmaDestroyAllocator on it.
Allocator X gets dropped, its own pointer to self.internal wasn't modified so it also calls vmaDestroyAllocator on it.

💥 Segfault!
Possible solutions

Remove the ability to clone Allocator
Use reference counting (?)

Removing Clone makes the most sense to me. The destroy method is the only one left that takes &mut self. Wrapping the Allocator in an Arc shouldn't pose any issue now if you still need to clone it.

For now wrapping it in an Arc is not the most optimal solution because some methods require a mutable reference, which would result in an unneeded Mutex. I have personally solved it by using std::mem::ManuallyDrop.

because some methods (map_memory, ..) require a mutable reference

That was recently changed. They all take &self now.

Oh, okay! I have been using the crates.io version of this crate, thank you for the clarification.


Adds ability to set 'EbsOptimized' and 'Monitoring' properties on EC2Instance

Description
Adds ability to set 'EbsOptimized' and 'Monitoring' properties (both boolean) on EC2Instance, as per CloudFormation docs:
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-instance.html#cfn-ec2-instance-ebsoptimized
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-instance.html#cfn-ec2-instance-monitoring

Whoa, only now realising this was opened 12 days ago. Sorry for the delay. Rapid7 has been having holiday parties recently so this was lost amongst that along with new feature support to support exporting to terraform (e.g. #270).

@jwark @SuperGeno These changes are available in the latest convection release v2.2.7. Thanks for your patience. 🎉

Also, not sure if you knew this but in the future if you're waiting on this type of change being merged/released properties can always be defined as any object that supports #to_json like so:
property 'EbsOptimized', true
property 'Monitoring', false

Thanks! Not a problem at all, we had just monkey-patched the class while waiting for the pull-request to be merged. ;)
Enjoy the rest of your holidays!


Operation state changes to unavailable

Describe the bug

The picture shows the operation state entity of my siemens dryer. The dryer finished yesterday evening at 17:37.
You can see, that the state changes three times at 02:59, 04:03 and 04:33 from "BSH.Common.EnumType.OperationState.Finished" to "unavailable"

This integration works fine for a long time and i didn't update the dryer firmware. So I think the problem comes with an update of HA or this integration.
The problem is, that the operation state entity is the trigger for an alexa speaker notity automation and my wife was not in use, that alexa says "info dryer is finished" three times in the middle of the night where we are sleeping :D
The event-log of my fritz-box shows no problems with the dryer wifi-connection. The dryer currently in Standby but still connected with my wifi
Update
Same problem this morning, till now 3 times (09:10, 09:13, 09:17). I've uploaded an debug-logfile

Debug log
home-assistant_home_connect_alt_2023-03-20T08-16-55.672Z.log

Your appliance is repeatedly connecting and disconnecting from the HC service. See all the "CONNECTION_CHANGED" events in the log. This is most likely a wifi issue. If you are sure it's not you can try to remove it from HC and then reconnect it. Since the integration is responding to events it is receiving as expected, there isn't really anything I can do with it on my end.

I checked the event-log of my fritzbox twice. I could see, that my dryer connects to the wifi, but I dont't see a wifi disconnect or something like that.
I'm wondering why everything worked fine for weeks without any problems?

I can say why it stopped working but the bottom line is that the HC API is reporting a DISCONNECT event followedby a CONNECT event. You can see in the log that these events are coming directly from HC and have nothing to do with the HA version or with the integration.
WiFi issues can have many forms, especially in a complex network with repeaters, but if you believe it isn't that then my only other suggestion is to try to disconnect the appliance from the HC service and then reconnect it.

Hi, maybe your are right! The event-log of my repeater show wifi-disconnections of my dryer
I will power-cycle all devices an try to reproduce the issue.

It seems to be truely a wifi-problem. No integration issue -> closed
I found a workaround thas works for me:


fix: issues starting angular app

Description
There are build issues and typescript version issues when running the Angular demo
Work Done

Updated to Angular 18
Added additional webpack config to fix build issues
Updated to the latest TypeScript where packages were using ^

Just add changeset entry for angular todo.


How to make log file last forever in the log table ?

How to make log file last forever in the log table ?

delete_records_older_than_days option only used when clean-command is executed. so if i never execute clean-command there is no log will be deleted forever. thanks :D

what if accidentally execute clean command?

@hakimihamdan88 in this case the entries are deleted. So the only thing you can do is to load a backup.

what if accidentally execute clean command?

use php artisan make:command XXX, then change the protected $signature = 'activitylog:clean' to over write the clean command


Some tests failed on fresh-installed npm-statistic

Problem tests:

npm-statistic FS has logs.txt
npm-statistic bash command show stats

Fixed.


telescope(?) issue in init.lua

Hi.
Adding this to init.lua, telescope preview doesn't works
      vim.keymap.set('n', '<leader>1', function()
        builtin.buffers { cwd = '' .. get_git_root() .. '/src/', prompt_title = 'Find src/ buffers', sort_mru = true, silent = true }
      end, { desc = 'Find src buffers' })

Am I using it correctly? Maybe a telescope issue?

You probably meant to use builtin.git_files instead of builtin.buffers ?

Is cwd a valid option for builtin.buffers?

Hmm, seems that cwd is a valid option for builtin.buffers, from my testing I think it needs to be an absolute path.
https://github.com/nvim-telescope/telescope.nvim/blob/master/doc/telescope.txt
builtin.buffers({opts})                          *telescope.builtin.buffers()*
    Lists open buffers in current neovim instance, opens selected buffer on
    `<cr>`
    Parameters: ~
        {opts} (table)  options to pass to the picker
    Options: ~
        {cwd}                   (string)    specify a working directory to
                                            filter buffers list by

@componhead is your issue that preview is not showing up, or you don't get a list of buffers at all?
For preview to show up the terminal needs to be at least 120 columns wide otherwise the preview is not shown. The min width can be configured, or the layout changed so that the preview is split in vertical.

The issue is that I cannot see the preview. Maybe the current asciinema can help:
https://asciinema.org/a/2K3fzdzAnyf5bC1gz8Uaw3CUG
thank you

Ok I see and can reproduce the issue, here's a snippet that I used to reproduce:
vim.keymap.set('n', '<leader>1', function()
  builtin.buffers { cwd = vim.fn.getcwd() .. '/lua/', prompt_title = 'Find lua/ buffers', sort_mru = true, silent = true }
end, { desc = 'Find lua buffers' })

So Telescope shows the list of buffers and opens a preview window but it's empty.
If I remove the cwd parameter then the preview works fine.
This is definitely a Telescope issue, nothing to do with kickstart so it would be best if you report the issue there:
https://github.com/nvim-telescope/telescope.nvim

Thank you for the feedback.


Add feature to have customized button layout from web-config

This update builds upon the display preview feature.
From the web-config, for preset button layouts parameters can be changed and also be previewed instantaneously.
This is how the added section looks like:

C++ sorry, unimplemented: non-trivial designated initializers not supported


Update Ruby versions on Travis CI

Closing in favor of https://github.com/sass/sassc-rails/pull/109


Regression report: RCov doesn't work again with 2.7.0

Hi, I've just scratched my head for about 15 minutes, debugging whatever came to my mind, then I'd landed at this issue.
https://github.com/rspec/rspec-core/issues/370
I'm running rcov with rspec and ci_reporter like this:
ruby -S rcov -Ispec:lib --rails --exclude /gems/,/Library/,/usr/,lib/tasks,.bundle,config,/lib/rspec/,/lib/rspec-,spec ./spec///_spec.rb ./spec//*_spec.rb -- --require /opt/ruby-enterprise/lib/ruby/gems/1.8/gems/ci_reporter-1.6.5/lib/ci/reporter/rake/rspec_loader --format CI::Reporter::RSpec
It seems it stopped working again... just blank output with rspec-(core|rails) 2.7.0.
Putting that require 'rspec/autorun' got it working again.

Thanks for pointing this out. Unfortunately, the way I had fixed #370 didn't work for every situation (rcov can be invoked in a few different ways) and caused trouble for some people where rspec/autorun was getting required when they didn't want it, so I had to back it out.
I need to add docs about this, so I'll leave this open until that's in place.
Your options right now requiring rspec/autorun as you did, or using rcov's own rake task, which will probably be your only option when we get to rspec-3.0.

Ouch, OK. Well... I'll have to look for some other way how to run rspec + rcov + ci_reporter in a single shot :)


Realms.World updates

Describe the feature you'd like to request
Short term website updates
Describe the solution you'd like to see
Home Page

Top navigation bar
-‘About’ - as well as ‘Tokenomics’ and ‘L3’, dropdown needs a link to info page - Cumberlord/Secretive to provide work on https://realms.world/info

‘Tokenomics’ Page

Add $ symbol to ‘$LORDS TOKENOMICS’ Title and
Add $ symbol to paragraph copy - ‘The $Lords token is the…’

‘Events’ Page

Remove/make 'past events' both of the current events

‘Games’ Page
Eternum:

Remove ‘Play’ button (until testing)
PAVED:
Update ‘Studio’ name to ‘Stolsi Labs’
Add more images - Cumberlord to provide
Loot Survivor:
Remove ‘Play’ button
Change status to ‘development’ (or something else that reflects current state)
zConquerer:
Update Studio name from ‘Zkorp’ to ‘zKorp’ (capitalisation)
Loot Underworld:
Remove ‘Play’ button
Mississippi:
Remove entire page and link (is now Kingdom & Lords)
Kingdom & Lords:
Change Title from ‘Kingdom-of-Lords’ to ‘Kingdom & Lords’
Change status to ‘development’
GenLoot:
Remove entirely (until further news?)
Arcane Assembler:
Remove entirely (until further news?)
 UPDATE AS GAMES GO LIVE.
ORDER:
PAVED
Pistols
zConquerer
Force Prime Heroes
Underdark
Eternum
Loot Survivor
Rising Revenant
Banners
Underworld
Kingdom & Lords
'Studio' Page

A few studios missing logos & images
Mid term: Let us know what format to supply images and optimal dimensions and we will create some consist images to make this page feel more polished

Additional information
Working doc: https://docs.google.com/document/d/1KGmDxdc-Y8kFIHlnIjHBR6SlbTQcrdTE3YjeWurqR7I/edit

@Cumberlord , I'd like to take on this issue. With my experience in TypeScript and React, I believe I can effectively address these updates.

I am already installing the repo

@RolandoDrRobot  is gonna be assisting me on this, he have already contributed to this project

Looking forward to your feedback!


Fix/previews

This PR adds the following:

Refactored demo
Demo with Preview plugin
Refactoring of the exposed props of

The new props setup allow for simpler front facing API of the  Component + fixes the issue where the plugin options could not be set in a typescript project such as preview.
type Props = {
  token: Config["token"],
  src: Config["src"],
  opts?: Omit<ConfigWith<any>, "token" | "src">
}

@Denpex I guess this changes the outwards facing API so we need to do a proper version bumb?


Indexer nodes dont ingest data from Kafka

Please provide a detailed title (e.g. "Broker crashes when using TopN query with Bound filter" instead of just "Broker crashes").
Affected Version
0.18.1
Description
Getting this error msg in logs:

o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
--
o.a.k.c.c.i.Fetcher   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Resetting offset for partition   server-metrics-0 to offset 257580.
o.a.k.c.c.KafkaConsumer   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Subscribed to partition(s):   server-metrics-0
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.k.c.c.i.Fetcher   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Resetting offset for partition   server-metrics-0 to offset 257565.
o.a.k.c.c.KafkaConsumer   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Subscribed to partition(s):   server-metrics-0
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.k.c.c.i.Fetcher   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Resetting offset for partition   server-metrics-0 to offset 257550.
o.a.k.c.c.KafkaConsumer   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Subscribed to partition(s):   server-metrics-0
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.k.c.c.i.Fetcher   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Resetting offset for partition   server-metrics-0 to offset 257535.
o.a.k.c.c.KafkaConsumer   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Subscribed to partition(s):   server-metrics-0
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.k.c.c.i.Fetcher   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Resetting offset for partition   server-metrics-0 to offset 257520.
o.a.k.c.c.KafkaConsumer   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Subscribed to partition(s):   server-metrics-0
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.k.c.c.i.Fetcher   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Resetting offset for partition   server-metrics-0 to offset 257505.
o.a.k.c.c.KafkaConsumer   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Subscribed to partition(s):   server-metrics-0
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.k.c.c.i.Fetcher   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Resetting offset for partition   server-metrics-0 to offset 257490.
o.a.k.c.c.KafkaConsumer   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Subscribed to partition(s):   server-metrics-0
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.k.c.c.i.Fetcher   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Resetting offset for partition   server-metrics-0 to offset 257475.
o.a.k.c.c.KafkaConsumer   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Subscribed to partition(s):   server-metrics-0
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.k.c.c.i.Fetcher   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Resetting offset for partition   server-metrics-0 to offset 257460.
o.a.k.c.c.KafkaConsumer   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Subscribed to partition(s):   server-metrics-0
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.k.c.c.i.Fetcher   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Resetting offset for partition   server-metrics-0 to offset 257445.
o.a.k.c.c.KafkaConsumer   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Subscribed to partition(s):   server-metrics-0
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.k.c.c.i.Fetcher   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Resetting offset for partition   server-metrics-0 to offset 257430.
o.a.k.c.c.KafkaConsumer   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Subscribed to partition(s):   server-metrics-0
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.k.c.c.i.Fetcher   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Resetting offset for partition   server-metrics-0 to offset 257415.
o.a.k.c.c.KafkaConsumer   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Subscribed to partition(s):   server-metrics-0
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.k.c.c.i.Fetcher   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Resetting offset for partition   server-metrics-0 to offset 257400.
o.a.k.c.c.KafkaConsumer   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Subscribed to partition(s):   server-metrics-0
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.k.c.c.i.Fetcher   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Resetting offset for partition   server-metrics-0 to offset 257385.
o.a.k.c.c.KafkaConsumer   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Subscribed to partition(s):   server-metrics-0
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.d.i.k.s.KafkaSupervisor   [KafkaSupervisor-server-minute-Reporting-0] Lag metric: Kafka partitions [0]   do not match task partitions []
o.a.k.c.c.i.Fetcher   [KafkaSupervisor-server-minute-Reporting-0] [Consumer clientId=consumer-5,   groupId=kafka-supervisor-ilpkgljk] Resetting offset for partition   server-metrics-0 to offset 257370.

```

@pdeva any resolution for this? I'm seeing a similar problem.


fix: remove debug output for local events

This line wasn't printing nicely during a local run. If we add this back in, it should be more intentional and useful for developers.

Codecov Report

Merging #226 (4d9fe8c) into develop (8d87e83) will increase coverage by 0.01%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop     #226      +/-   ##
===========================================
+ Coverage    54.82%   54.84%   +0.01%
===========================================
  Files           44       44
  Lines         4525     4524       -1
===========================================
  Hits          2481     2481
+ Misses        1899     1898       -1
  Partials       145      145

Flag
Coverage Δ

unittests
54.84% <ø> (+0.01%)
:arrow_up:

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

Impacted Files
Coverage Δ

pkg/plugins/events/dev/eventing.go
0.00% <ø> (ø)

Continue to review full report at Codecov.

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


add evilfactorylabs social

lgtm

Ran Plan for dir: . workspace: area13
Plan Error
running "/usr/bin/terraform plan -input=false -refresh -out \"/root/.atlantis/repos/evilfactorylabs/area13/6/area13/area13.tfplan\" -var-file /etc/atlantis/area13.tfvars" in "/root/.atlantis/repos/evilfactorylabs/area13/6/area13": exit status 1
╷
│ Error: No value for required variable
│
│   on variables.tf line 5:
│    5: variable "linode_token" {
│
│ The root module input variable "linode_token" is not set, and has no
│ default value. Use a -var or -var-file command line argument to provide a
│ value for this variable.
╵

Ran Plan for dir: . workspace: area13
Plan Error
Show Output
running "/usr/bin/terraform init -input=false" in "/root/.atlantis/repos/evilfactorylabs/area13/6/area13": exit status 1

Initializing Terraform Cloud...

Initializing provider plugins...
- Reusing previous version of linode/linode from the dependency lock file
- Reusing previous version of digitalocean/digitalocean from the dependency lock file
- Reusing previous version of namecheap/namecheap from the dependency lock file
- Using linode/linode v1.29.4 from the shared cache directory
- Using digitalocean/digitalocean v2.21.0 from the shared cache directory
- Using namecheap/namecheap v2.1.0 from the shared cache directory
╷
│ Error: Failed to install provider from shared cache
│
│ Error while importing linode/linode v1.29.4 from the shared cache
│ directory: the provider cache at .terraform/providers has a copy of
│ registry.terraform.io/linode/linode 1.29.4 that doesn't match any of the
│ checksums recorded in the dependency lock file.
╵

Ran Plan for dir: . workspace: area13
Plan Error
running "/usr/bin/terraform plan -input=false -refresh -out \"/root/.atlantis/repos/evilfactorylabs/area13/6/area13/area13.tfplan\" -var-file /etc/atlantis/area13.tfvars" in "/root/.atlantis/repos/evilfactorylabs/area13/6/area13": exit status 1
╷
│ Error: error getting default for "config_path": error loading default: $HOME is not defined
│
│   with provider["registry.terraform.io/linode/linode"],
│   on main.tf line 29, in provider "linode":
│   29: provider "linode" {
│
╵

the what

atlantis plan

Ran Plan for dir: . workspace: area13
Plan Error
running "/usr/bin/terraform init -input=false" in "/etc/atlantis/.atlantis/repos/evilfactorylabs/area13/6/area13": exit status 1

Initializing Terraform Cloud...
╷
│ Error: Required token could not be found
│
│ Run the following command to generate a token for app.terraform.io:
│     terraform login
╵

atlantis plan

Ran Plan for dir: . workspace: area13

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.

:arrow_forward: To apply this plan, comment:

atlantis apply -w area13

:put_litter_in_its_place: To delete this plan click here
:repeat: To plan this project again, comment:

atlantis plan -w area13

:fast_forward: To apply all unapplied plans from this pull request, comment:

atlantis apply

:put_litter_in_its_place: To delete all plans and locks for the PR, comment:

atlantis unlock

lgtm

Locks and plans deleted for the projects and workspaces modified in this pull request:

dir: . workspace: area13


github actions release workflow

Adds CI workflow to upload to pypi when a new release is created on GitHub.

Initial release succeeded:

https://github.com/related-sciences/nxontology/releases/tag/v0.1.0
https://github.com/related-sciences/nxontology/runs/1499734843
https://pypi.org/project/nxontology/0.1.0/

Will now switch API token to have repo scope.

@hammer let me know what PyPI user to add as a collaborator. When I try to add https://pypi.org/user/hammer/:

ErrorUser 'hammer' does not have a verified primary email address and cannot be added as a Maintainer for project

Try now? I just verified an email address for that account.


Avoid failing when LZFSE stores the uncompressed data.

When compression fails (for example, when the data is small or non
compressible), LZFSE falls back to storing the data uncompressed with
start/end of block magics and the length of the block, which adds an
additional 12 bytes to the output.

Me too, but PTAL at the origin. It's basically sizeof(uncompressed_block_header)  from lzfse_internal.h and sizeof another magic that marks the end of the block, but these are internal implementation details of the compressor.

I see. That 12 is ugly, but that's the right thing to do. Thanks!


works great. gui?

Is there a GUI coming or integrating with any atom terminal maybe?

I would recommend terminal plus but the newest version seems to be broken.


Cleanup

Added type hints and docstrings.
Removed extraneous code.
Refactored the layout of some modules.
Moved the tests.
Requires #25

We need to establish some tests (unit /  integration / benchmark) so that we can check these PRs aren't messing with the code.

All of the current tests assume data files. We need to make some similar tests with small data files we can host on the repo.

Codecov Report
Attention: 408 lines in your changes are missing coverage. Please review.

Comparison is base (c6d6c76) 0.34% compared to head (84ae21c) 0.32%.
Report is 3 commits behind head on main.

Files
Patch %
Lines

src/cats/cmd/_core.py
0.00%
61 Missing :warning:

src/cats/pawprint/_footprint.py
0.00%
55 Missing :warning:

src/cats/photometry/_base.py
0.00%
55 Missing :warning:

src/cats/proper_motions.py
0.00%
49 Missing :warning:

src/cats/photometry/_builtin/gaia.py
0.00%
41 Missing :warning:

src/cats/photometry/_builtin/desi.py
0.00%
38 Missing :warning:

src/cats/photometry/_builtin/ps1.py
0.00%
28 Missing :warning:

src/cats/data.py
0.00%
23 Missing :warning:

src/cats/pawprint/_core.py
0.00%
19 Missing :warning:

src/cats/photometry/_builtin/__init__.py
0.00%
9 Missing :warning:

... and 5 more

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff            @@
##            main     #24      +/-   ##
========================================
- Coverage   0.34%   0.32%   -0.03%
========================================
  Files          9      16       +7
  Lines        864     929      +65
========================================
  Hits           3       3
- Misses       861     926      +65

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

Suitable for squash merge!


Remove suscribe via RSS from _layouts/home.html

Hello.
I'm trying to remove the "suscribe via RSS" text below my blog posts.
What I've tried
Following instructions from other issues related to mine:

I copied _includes/footer.html from the minima repository
deleted feed-subscribe block, and place it in _includes/footer.html in my project.
deleted gem "jekyll-feed", "~> 0.12" from Gemfile
deleted jekyll-feed from plugins: in _config.yml

However, the message is still apearing just below my posts.
You can check it in the following image or just visiting my demo website

Inspecting the "suscribe via RSS" message in my website you can see this block:

subscribe via RSS

Checking _layouts/home.html in the minima repository, I cannot see the rss-suscribe block. So, my questions are:

How is it being rendered?
How can I remove it?

Thank you.

I encountered the same problem.

Hi, have you been able to find any solutions?


Collection item values were changed in loop even not using reference

Laravel Version: 5.3.31
PHP Version: 7.1.29
Database Driver & Version: MySQL 5.6.44

Description:
I just loop through a collection, find unique element by some attribute values then put it to second collection, change data in the second collection, but the original value of the first collection was changed even I did't pass by reference inside foreach.
Steps To Reproduce:
I loop through a collection like this:
$data = Collection(
['category' => 1, 'type' => 'sp', 'count' => 10],
['category' => 1, 'type' => 'sp', 'count' => 10],
['category' => 2, 'type' => 'sp', 'count' => 20],...
);

$list = collect(); // store unique items

foreach ($data as $item) {
	$key = $item->category . '_' . $item->type;
	$check_item = $list->get($key);
	if ($check_item == null) {
		$list->put($key, $item);
	} else {
		$check_item->count += $item->count; // this causes my problem
		$list->put($key, $check_item);
	}
}

Expected result:

$list:

Collection(
'1_sp' => ['category' => 1, 'type' => 'sp', 'count' => 20],
'2_sp' => ['category' => 2, 'type' => 'sp', 'count' => 20],
...);

$data: (as original)

 Collection(
['category' => 1, 'type' => 'sp', 'count' => 10],
['category' => 1, 'type' => 'sp', 'count' => 10],
['category' => 2, 'type' => 'sp', 'count' => 20],...
);

Actual result:

$list: same as expected result above.
$data: has been changed

 Collection(
['category' => 1, 'type' => 'sp', 'count' => 20],
['category' => 1, 'type' => 'sp', 'count' => 10],
['category' => 2, 'type' => 'sp', 'count' => 20],...
);

If I change
$list->put($key, $item);

to
$list->put($key, clone $item);

problem is solved.
If I repleace collection by php array, there is no problem.
Is this Laravel Collection bug or Collection function?

Hey there,
Unfortunately we don't support this version anymore. Please check out our support policy on which versions we are currently supporting. Can you please try to upgrade to the latest version and see if your problem persists? We'll help you out and re-open this issue if so.
Thanks!


Update ApplePayController.php

Description
fix a Notice: Undefined property. this notice block payment on development environment.
Tested scenarios
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT

on iPhone connected to Safari with web inspector
go to magento server with apple pay
add product to card and go to checkout
fill all required filed to get Payment method step.
Select Apple Pay method
Click to Continue button
On review step click Apple Pay logo
Should appear a popup with selecting credit card
use TouchId or Passcode to send a payment
See "Payment Not Completed"
See in Network Tab of Safari request to  /adyen/applePay/sendPayment/ with php Notice in output.

Hi @lykhouzov,
Thanks for the PR! Indeed a check to remove the notice. I will merge this one.
Regards,
Rik
Adyen

Hi @lykhouzov,
Can you do a PR to develop please then we can include to master on new release.
Regards,
Rik
Adyen

Hi, @rikterbeek
PR is changed.


Problems on Solving a Task

The Task
Chess is the oldest game, but it is still popular these days. For this task we will use only one chess piece – the Knight.
The knight moves to the nearest square, but not on the same row, column or diagonal. (This can be thought of as moving two squares horizontally, then one square vertically, or moving one square horizontally, then two squares vertically— i.e. in an "L" pattern.)
The knight game is played on a board with dimensions N x N and a lot of chess knights 0 <= K <= N2.
You will receive a board with K for knights and '0' for empty cells. Your task is to remove a minimum of the knights, so there will be no knights left that can attack another knight.
Input
•	On the first line, you will receive the N side of the board.
•	On the next N lines, you will receive strings with Ks and 0s.
Output
•	Print a single integer with the minimum number of knights that needs to be removed.
Test
input
8
0K0KKK00
0K00KKKK
00K0000K
KKKKKK0K
K0K0000K
KK00000K
00K0K000
000K00KK
output
12
my code is here: solution

I found the solution
char[,] squareMatrix = new char[squareMatrixSize, squareMatrixSize];

for (byte i = 0; i < squareMatrixSize; i++)
{
    char[] row = Console.ReadLine()!.ToCharArray();
    for (byte j = 0; j < squareMatrixSize; j++) squareMatrix[i, j] = row[j];
}

ushort knightsRemoved = 0;
for (int max = 8; max > 0; max--)
{
    for (int i = 0; i < squareMatrixSize; i++)
    {
        for (int j = 0; j < squareMatrixSize; j++)
        {
            byte endangered = 0;
            if (squareMatrix[i, j] == 'K')
            {
                string[] moves =
                {
                    $"{i + 2} {j + 1}", $"{i + 2} {j - 1}", $"{i - 2} {j + 1}", $"{i - 2} {j - 1}",
                    $"{i + 1} {j + 2}", $"{i + 1} {j - 2}", $"{i - 1} {j + 2}", $"{i - 1} {j - 2}"
                };

                foreach (string move in moves)
                {
                    int y = int.Parse(move.Split()[0]);
                    int x = int.Parse(move.Split()[1]);
                    if (y >= 0 && y < squareMatrixSize && x >= 0 && x < squareMatrixSize && squareMatrix[y, x] == 'K') endangered++;
                }
            }

            if (endangered == max)
            {
                squareMatrix[i, j] = '0';
                knightsRemoved++;
            }
        }
    }
}

Console.WriteLine(knightsRemoved);


Update github actions to no longer create PRs

What

No longer create PRs during release actions.
Update workflow to instead have some text where the PR creation was
Update release instructions to do this manually

Why
Due to a security issue we can no longer have github actions put up PRs:

https://aka.ms/opensource/actions-changes-230217
How Tested
n/a

T.T

T.T

My feeling is we should move this to ADO, but can be a good retro item


Use good serial driver for graceful shutdown in Bad Write tests.

Fixes #394
The bad serial driver was being used to destruct the Motor Driver which
was causing an obscure issue.
This took a while to debug. The flow of code was not obvious. I just
looked at the constructor and assumed that it was using MotorSerial
throughout

This looks like a good use case for https://docs.python.org/3/library/unittest.mock.html#unittest.mock.patch

This looks like a good use case for docs.python.org/3/library/unittest.mock.html#unittest.mock.patch

I've been unable to get this to work in this instance.


fix: handle functions while marshalling

Description
Closes #3101
In safe mode turned on, marshalling to vm was failing for the type function.
This PR adds support for it by marshalling it to string [Function (anonymous)].

Contribution Checklist:

[x] The pull request only addresses one issue or adds one feature.
[x] The pull request does not introduce any breaking changes
[x] I have added screenshots or gifs to help explain the change if applicable.
[x] I have read the contribution guidelines.
[x] Create an issue and link to the pull request.

Note: Keeping the PR small and focused helps make it easier to review and merge. If you have multiple changes you want to make, please consider submitting them as separate pull requests.
Publishing to New Package Managers
Please see here for more information.

Merged! Thanks @shishir-karanth !
This will be available in v1.29.0


[Errno 2] No such file or directory: 'cutoff.csv'

Hi, I'm trying to run this test case:
python3 -m cc_net --config config/test_segment.json
but encountered the following error:
Will run cc_net.mine.main with the following config: Config(config_name='base', dump='2019-09', output_dir=PosixPath('test_data2'), mined_dir='mined_by_segment', execution='debug', num_shards=4, min_shard=-1, num_segments_per_shard=1, metadata=None, min_len=300, hash_in_mem=1, lang_whitelist=['de', 'it', 'fr'], lang_blacklist=[], lang_threshold=0.5, keep_bucket=[], lm_dir=PosixPath('data/lm_sp'), cutoff=PosixPath('/Users/work/temp/RedPajama-Data/data_prep/cc/cc_net/cc_net/data/cutoff.csv'), lm_languages=None, mine_num_processes=0, target_size='32M', cleanup_after_regroup=False, task_parallelism=-1, pipeline=['dedup', 'lid', 'keep_lang', 'sp', 'lm', 'pp_bucket', 'minify', 'split_by_segment'], experiments=[], cache_dir=PosixPath('test_data/wet_cache'))
['dedup', 'lid', 'keep_lang', 'sp', 'lm', 'pp_bucket', 'minify', 'split_by_segment']
2023-04-27 11:41 INFO 39932:cc_net.jsonql - preparing [<cc_net.dedup.DuplicatesRemover object at 0x11b5b77c0>, Classifier(bin/lid.bin), <cc_net.jsonql.where object at 0x11b5b7a30>, <cc_net.perplexity.MultiSentencePiece object at 0x11b5b78e0>, <cc_net.perplexity.DocLM object at 0x11b5b7970>, <cc_net.perplexity.PerplexityBucket object at 0x11b5b7a60>, <cc_net.minify.Minifier object at 0x11b5b7be0>]
/Users/work/temp/RedPajama-Data/data_prep/cc/cc_net/cc_net/flat_hash_set.py:115: UserWarning: Module 'getpy' not found. Deduplication will take more RAM. Try `pip install cc_net[getpy]
  warnings.warn(
2023-04-27 11:41 INFO 39932:DuplicatesRemover - Loaded hashes from test_data2/hashes/2019-09/0000.bin (0.700GB total, took 0.02m)
2023-04-27 11:41 INFO 39932:DuplicatesRemover - Loaded 3_361_543 hashes from 1 files. (0.7GB total, took 0.02m)
2023-04-27 11:41 INFO 39932:Classifier - Loading bin/lid.bin
Warning : `load_model` does not return WordVectorModel or SupervisedModel any more, but a `FastText` object which is very similar.
2023-04-27 11:41 INFO 39932:MultiSentencePiece - Loading data/lm_sp/de.sp.model...
2023-04-27 11:41 INFO 39932:MultiSentencePiece - Loaded data/lm_sp/de.sp.model (took 0.0min)
2023-04-27 11:41 INFO 39932:MultiSentencePiece - Loading data/lm_sp/it.sp.model...
2023-04-27 11:41 INFO 39932:MultiSentencePiece - Loaded data/lm_sp/it.sp.model (took 0.0min)
2023-04-27 11:41 INFO 39932:MultiSentencePiece - Loading data/lm_sp/fr.sp.model...
2023-04-27 11:41 INFO 39932:MultiSentencePiece - Loaded data/lm_sp/fr.sp.model (took 0.0min)
2023-04-27 11:41 INFO 39932:DocLM - Loading data/lm_sp/de.arpa.bin...
2023-04-27 11:41 INFO 39932:DocLM - Loaded data/lm_sp/de.arpa.bin (took 0.0min)
2023-04-27 11:41 INFO 39932:DocLM - Loading data/lm_sp/it.arpa.bin...
2023-04-27 11:41 INFO 39932:DocLM - Loaded data/lm_sp/it.arpa.bin (took 0.0min)
2023-04-27 11:41 INFO 39932:DocLM - Loading data/lm_sp/fr.arpa.bin...
2023-04-27 11:41 INFO 39932:DocLM - Loaded data/lm_sp/fr.arpa.bin (took 0.0min)
Traceback (most recent call last):
  File "/Users/work/temp/RedPajama-Data/data_prep/cc/cc_net/cc_net/execution.py", line 142, in debug_executor
    message = function(*x)
  File "/Users/work/temp/RedPajama-Data/data_prep/cc/cc_net/cc_net/mine.py", line 439, in _mine_shard
    jsonql.run_pipes(
  File "/Users/work/temp/RedPajama-Data/data_prep/cc/cc_net/cc_net/jsonql.py", line 432, in run_pipes
    transform = stack.enter_context(compose(transformers))
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/contextlib.py", line 429, in enter_context
    result = _cm_type.__enter__(cm)
  File "/Users/work/temp/RedPajama-Data/data_prep/cc/cc_net/cc_net/jsonql.py", line 312, in __enter__
    self._prepare()
  File "/Users/work/temp/RedPajama-Data/data_prep/cc/cc_net/cc_net/jsonql.py", line 352, in _prepare
    t.__enter__()
  File "/Users/work/temp/RedPajama-Data/data_prep/cc/cc_net/cc_net/jsonql.py", line 312, in __enter__
    self._prepare()
  File "/Users/work/temp/RedPajama-Data/data_prep/cc/cc_net/cc_net/perplexity.py", line 267, in _prepare
    cutoffs = pd.read_csv(self.cutoff_csv, index_col=0)
  File "/Users/Library/Python/3.9/lib/python/site-packages/pandas/io/parsers/readers.py", line 912, in read_csv
    return _read(filepath_or_buffer, kwds)
  File "/Users/Library/Python/3.9/lib/python/site-packages/pandas/io/parsers/readers.py", line 577, in _read
    parser = TextFileReader(filepath_or_buffer, **kwds)
  File "/Users/Library/Python/3.9/lib/python/site-packages/pandas/io/parsers/readers.py", line 1407, in __init__
    self._engine = self._make_engine(f, self.engine)
  File "/Users/Library/Python/3.9/lib/python/site-packages/pandas/io/parsers/readers.py", line 1661, in _make_engine
    self.handles = get_handle(
  File "/Users/Library/Python/3.9/lib/python/site-packages/pandas/io/common.py", line 859, in get_handle
    handle = open(
FileNotFoundError: [Errno 2] No such file or directory: '/Users/work/RedPajama-Data/data_prep/cc/cc_net/cc_net/data/cutoff.csv'

Are there any possible reasons? Python3.9.6 on MacOS

here -> https://github.com/facebookresearch/cc_net/blob/main/cc_net/data/cutoff.csv

thanks!  but I still failed. here's another problem. I'm in trouble with setting mine_num_processes greater than 1, seems that a lambda function cannot be pickled:
Traceback (most recent call last):
  File "/Users/work/temp/RedPajama-Data/data_prep/cc/cc_net/cc_net/execution.py", line 142, in debug_executor
    message = function(*x)
  File "/Users/work/temp/RedPajama-Data/data_prep/cc/cc_net/cc_net/mine.py", line 439, in _mine_shard
    jsonql.run_pipes(
  File "/Users/work/temp/RedPajama-Data/data_prep/cc/cc_net/cc_net/jsonql.py", line 439, in run_pipes
    multiprocessing.Pool(
  File "/Users/miniconda3/envs/py38/lib/python3.8/multiprocessing/context.py", line 119, in Pool
    return Pool(processes, initializer, initargs, maxtasksperchild,
  File "/Users/miniconda3/envs/py38/lib/python3.8/multiprocessing/pool.py", line 212, in __init__
    self._repopulate_pool()
  File "/Users/miniconda3/envs/py38/lib/python3.8/multiprocessing/pool.py", line 303, in _repopulate_pool
    return self._repopulate_pool_static(self._ctx, self.Process,
  File "/Users/miniconda3/envs/py38/lib/python3.8/multiprocessing/pool.py", line 326, in _repopulate_pool_static
    w.start()
  File "/Users/miniconda3/envs/py38/lib/python3.8/multiprocessing/process.py", line 121, in start
    self._popen = self._Popen(self)
  File "/Users/miniconda3/envs/py38/lib/python3.8/multiprocessing/context.py", line 284, in _Popen
    return Popen(process_obj)
  File "/Users/miniconda3/envs/py38/lib/python3.8/multiprocessing/popen_spawn_posix.py", line 32, in __init__
    super().__init__(process_obj)
  File "/Users/miniconda3/envs/py38/lib/python3.8/multiprocessing/popen_fork.py", line 19, in __init__
    self._launch(process_obj)
  File "/Users/miniconda3/envs/py38/lib/python3.8/multiprocessing/popen_spawn_posix.py", line 47, in _launch
    reduction.dump(process_obj, fp)
  File "/Users/miniconda3/envs/py38/lib/python3.8/multiprocessing/reduction.py", line 60, in dump
    ForkingPickler(file, protocol).dump(obj)
AttributeError: Can't pickle local object '_mine_shard.<locals>.<lambda>'

Any suggestion will be helpful

Hi @Anery, this might be due to failed installation. Did the following steps run successfully for you (run from the cc directory)?
# Installation
cd `cc_net`
mkdir data

sudo apt-get update
sudo apt install build-essential cmake libboost-system-dev libboost-thread-dev libboost-program-options-dev libboost-test-dev libeigen3-dev zlib1g-dev libbz2-dev liblzma-dev
make install
make lang=en dl_lm

Thanks for your reply, I'm running on macos, some of the pkg are not installed. I'll try on Linux latter

It works well on Linux, I’ll close this issue. Thanks.


Partial Data Not Displayed After Selecting the "Review and submit" Button; Edit Button is Missing

If a user enters partial data for a report and then selects the "Review and submit" button, the partial data will not be displayed.   However, the partial data is stored in the database.  Furthermore, the "Edit" button is missing. This bug occurred after the last release (20 July).  If possible, please add to the current sprint.

Reference is item 61

duplicate of #87


Add actions-tagger

Added https://github.com/marketplace/actions/actions-tagger to the community action maven release to test if this will automate tagging to latest to hopefully resolve #28

Hi @berndruecker! :) I managed to debug this, made the changes you suggested, and figured out why the pre-commit was failing. I had to update the formatting on line 117 to allow for nested mappings by adding quotes. The pre-commit check passed now, so this should be okay to approve.
Once that's done, I can cut a new release and tag it with latest

ok


Move RCTRootShadowView creation to main thread

Please select one of the following

[ ] I am removing an existing difference between facebook/react-native and microsoft/react-native-macos :thumbsup:
[ ] I am cherry-picking a change from Facebook's react-native into microsoft/react-native-macos :thumbsup:
[x] I am making a fix / change for the macOS implementation of react-native
[ ] I am making a change required for Microsoft usage of react-native

Summary
Solves the same problem that #733 was supposed to solve (originally backed out by 70ddf46).
We've seen a deadlock on iOS with two threads, one main and one background, making simultaneous calls to +[RCTI18nUtil sharedInstance], with a background thread reaching the inside of the dispatch_once block (as seen here) first. It appears that playing around with NSUserDefaults on iOS (as done here) requires use of the main thread to "commit" changes to user defaults.
The solution is to move the initialization of RCTRootShadowView, which depends on our RCTI18n singleton as per this line, to the main thread, and do everything else on the UIManager queue.
This will later be brought upstream.
Changelog
[iOS] [Fixed] - Remove a deadlock involving RCTI18nUtil
Test Plan
The deadlock no longer occurs on iOS, and macOS appears unaffected.

do you know which commit actually regress it in .68 version?

for my own knowledge, RCTExecuteOnUIManagerQueue is not main thread?

should we add an asserts in RCTI18n to make sure some things are called in main thread?

The last time we had a deadlock in RCTI18nUtil, I made a change in both RN-macOS and RN Core to resolve it. The change ended up being incorrect, and I had to back it out. The actual fix was downstream in our internal codebase. I worry that that sequence of events may happen again here. Are we sure there isn't something we can change downstream instead of making the change here?

@harrieshin

do you know which commit actually regress it in .68 version?

Not sure. I haven't looked too deeply into it.

for my own knowledge, RCTExecuteOnUIManagerQueue is not main thread?

Correct. This is a separate thread.

should we add an asserts in RCTI18n to make sure some things are called in main thread?

I considered it, although I don't know if this will have any other adverse side effects, and I want to make sure that requiring main-thread initialization is indeed correct. If this ends up being the case, I'm happy to add an assert in.

The last time we had a deadlock in RCTI18nUtil, I made a change in both RN-macOS and RN Core to resolve it. The change ended up being incorrect, and I had to back it out. The actual fix was downstream in our internal codebase. I worry that that sequence of events may happen again here. Are we sure there isn't something we can change downstream instead of making the change here?

The point of this change is to bump up the initialization of our RCTI18nUtil instance to avoid deadlocks. I'd like to think that this change is more surgical than the previous one, but I understand your concern. I can test the scenario that caused the reversion to make sure that still works as intended though.


trying to install

[05:26:58] Starting 'typescript'...
[05:26:59] Starting 'sass'...
[05:26:59] Starting 'react'...
[05:27:00] gulp-notify: [Black Screen Watcher] React has been compiled.
[05:27:01] Finished 'react' after 1.87 s
/Users/rudix/Desktop/black-screen/node_modules/typescript/lib/typescript.js:35171
if (host.fileExists(fileName)) {
^
TypeError: undefined is not a function

I'm getting the same error

+1

This is a duplicate of #21

Fixed.


Use Case: Transaction Rollback

An ORM should show how to to transaction in a rolled-back state.
This should be validated after the operation.

I'm inclined to put the Commit and Rollback into the same use case. But we can talk about it more later.


restic init in existing bucket

Output of restic version
restic 0.9.5 compiled with go1.12.4 on linux/amd64
How did you run restic exactly?
export AWS_ACCESS_KEY_ID=
export AWS_SECRET_ACCESS_KEY=
export RESTIC_PASSWORD=
export RESTIC_REPOSITORY=
restic init
What backend/server/service did you use to store the repository?
CentOS (using Ansible)
Expected behavior
Creates initial structure without failing because bucket exists.
Actual behavior
"Fatal: create repository at s3:https://s3.amazonaws.com/xxxxxxx failed: client.BucketExists: Head https://xxxxxxx.s3.dualstack.region-1.amazonaws.com/: 301 response missing Location header"
Steps to reproduce the behavior
Create S3 Bucket,
add encryption,
add versioning,
set up lifecycle,
etc...
(prepare bucket as you want)
Keep bucket 100% empty.
Run restic init.
Do you have any idea what may have caused this?
Bucket already exists, restic doesn't seem to like that.
Do you have an idea how to solve the issue?
Allow us to init a repository on an empty bucket.

Besides searching for issues first, I'd recommend commenting on your issue:
"Closed as duplicate of #0000" and closing it. If it is not a duplicate, but just a 'dumb' question, answer and close the issue!
This way others searching for the issue in the same way you did, with similar thinking procedure are able to benefit from this.

I realized that the problem isn't that "BucketExists". That's just informational, apparently.
I see that giving the URL: https://s3.amazonaws.com/BUCKETNAME
Makes Restic assume it is on "us-east-1" region, but the bucket is in "us-west-2"...
So, giving the URL instead: https://s3-us-west-2.amazonaws.com/BUCKETNAME
Resolved the problem.
There's absolutely NOTHING in the error that says that...
The error says "create repository failed" and then right after says "BucketExists",
so the error is completely misleading.
But, seeing the "301 response missing Location header" eventually made me think that the error could be something else, and find the problem.

@nunoperalta and close the issue :) Have a great day!

I left it open in case it would be an opportunity for Restic to improve the mentioned error.


Expand tuples to multiple columns

It would be awesome if EF Core could expand a (anonymous or named) tuple into multiple columns, assuming the individual fields in the tuple are supported entity types, without needing a custom conversion or mapping property.
e.g.
class Foo {
    int Id {get; set;}
    (int, int) Bar {get; set;}
}

would result in a table [int Id | int Bar_1 | int Bar_2], while a named tuple, e.g.
class Foo {
    int Id {get; set;}
    (int LowerBits, int HigherBits) Bar {get; set;}
}

would result in a table [int Id | int LowerBits | int HigherBits].
Note that this can't (yet) be done via value converters, as there's (currently) no support for mapping one entity to multiple columns.

If/when implementing this, don't get in the way of providers which can map tuples natively (the idea is to map this to PostgreSQL composite types).

Triage: putting this on the backlog. It's a nice idea that could work with a value converter convention. This would only kick in if the provider doesn't natively support some mapping, so PostgreSQL should be fine. However, it will require #13947 to be implemented first.

@roji is there a way to do it with Npgsql currently, as EF Core doesn't support it yet? I have composite primary key (Id, Type) and want to generate next SQL:
SELECT *
FROM Table
WHERE (Id, Type) IN ((1, 1), (2, 1))

It is possible to generate IN clause for one column, using Contains method but I cannot figure out if it possible for columns within composite type. Maybe there is a workaround?

@dmitryshunkov I don't think that's supported at the moment (maybe @smitpatel knows something I don't).
We could make this expressible with the following, assuming blog has a composite key:
var blogs = ctx.Blogs.Where(b => new[]
{
    new Blog { Id = 1, Type = 1 },
    new Blog { Id = 2, Type = 1 }
}.Contains(b)).ToList();

However, please open a separate issue as this is unrelated with the current issue.

@roji - Is that valid Sql in postgre? If yes then possibly provider need to override SqlTranslator and put tuple as translated SqlExpression as it can be generated as literal. (Relational one returns null atm)

@roji, in my opinion, composite key shouldn't affect the possibility of building query with other columns in row constructor for subquery. Potential syntax could be something like this:
var blogs = ctx.Blogs
   .Where(p => (new[] { new { Id = 1, Type = 1, Title = "New" } })
      .Contains(new { p.Id, p.Type, p.Title }))
   .ToList();

to generate SQL:
SELECT *
FROM Blogs
WHERE (Id, Type, Title) IN ((1, 1, 'New'))

@smitpatel yeah, the following works in PostgreSQL, I guess it's yet another provider-specific feature :)
roji=# SELECT 1 WHERE (1, 2) IN ((1, 2), (3, 4));
 ?column?
----------
        1
(1 row)

roji=# SELECT 1 WHERE (1, 4) IN ((1, 2), (3, 4));
 ?column?
----------
(0 rows)

Re the syntax, sure that looks good. My proposal above is the "entity equality" version which seems like it could be useful as well.
Opened https://github.com/npgsql/Npgsql.EntityFrameworkCore.PostgreSQL/issues/898 to track.

Just wanted to post an inter-dependency for when this gets taken on: namely that nullable/optional tuples ought to be supported for this.
One of the core benefits of tuples is that they allow encapsulating multiple fields that belong together in a logical unit – thereby instead of modelling them as multiple independent nullable fields in the domain (ie: Field1:T1?, Field2:T2?), you can have a tuple that is nullable itself, but allows the fields to have nullability specified individually (ie: (Field1:T1, Field2:T2)?). For example: a price and its currency – should either neither be set or both be set, but never only one or the other.
Please allow nullable tuples to be modelled when this gets taken on.


Ant Design 5: Upgrade Divider component

Please refer to SIP-139 https://github.com/apache/superset/issues/29268.
The Divider component should be upgraded to Ant Design version 5.
Similar work has been completed here.
When upgrading the component to Ant Design 5, please ensure to include:

Proper RTL test coverage if not present yet.
A Storybook file (if not present) or all necessary changes.
Include all relevant component options in the Storybook.
Clean up unnecessary custom styles.

When opening a PR:

Name your PR refactor({Component}): Upgrade {component} to Ant Design 5
Add screenshots of BEFORE/AFTER in your PR.
Update the project tracker when your PR is merged.
Make sure you or a committer has labeled your PR with frontend:refactor:antd5.

🎉 Preset Bounty Available: $150 USD 🎉
To claim this bounty, please carefully follow the steps below.

📋 Steps to Participate

Review Guidelines:
Read through the Preset Bounty Program Contribution Guide for complete details on bounty requirements.

Show Your Interest:
Complete the Preset Bounty Program Survey and comment this issue to express your interest.

Join the Slack Channel:
After completing the survey, you’ll receive an invitation to the dedicated Apache Superset Slack channel.

Get Assigned:
To officially start, ensure a Bounty Program Manager has assigned you to this issue.

Submit Your Solution:
When ready, submit your solution with the Fixes #{issue_number} notation in your Pull Request description.

Claim Your Bounty:
Sign up at GitPay.me and submit your solution via: https://gitpay.me/#/task/1029

💡 Additional Notes

Only developers assigned by a Bounty Program Manager should start working on this issue to win the bounty.
Be sure to follow the guide closely to avoid any delays in payment. Please, allow a few days after your PR has been merged for the bounty to be released.

Good luck, and happy coding! 🎉