[TF] TensorGroup and TensorArrayProtocol conformance derivation

This is work-in-progress to resolve TF-259. I want to open this PR to track progress and also to let you guys notify me of any formatting or other conventions I may be violating.
The derivation for TensorGroup is only missing the initializer currently, but this should be easy to add after I'm done with the TensorArrayProtocol derivation. My main issue currently is that even though I have added the _unpackTensorHandles derivation, the compiler does not seem to use it and keeps throwing conformance errors when that one is missing. UPDATE: I figured this out.
Once that is resolved I will add the TensorGroup initializer as it's very similar to the derivation of _unpackTensorHandles.
EDIT: Also, why was there a default implementation for _unknownShapeList? I removed it because this prevents the type checker from deriving it.

Nice! It's awesome that you are pushing this through!

Also, why was there a default implementation for _unknownShapeList? I removed it because this prevents the type checker from deriving it.

The default implementation exists because the requirement does not need to be derived, and it actually should not be a customization at all (it's always default-implementable). What should be removed is the protocol requirement, not the default implementation.

@rxwei Thanks! So, would it be ok if I replace the declaration in the TensorGroup protocol with the following?
static var _unknownShapeList: [TensorShape?] {
  return Array(repeating: nil, count: _typeList.count)
}

Also, what is that method used for? Do you always assume unknown shape information when dealing with TensorGroups?

An even better question is, why not have _shapeList: [TensorShape], where you get the static shape information of the tensors in the group (i.e., through the shape attribute -- if that's supported in S4TF).

So, would it be ok if I replace the declaration in the TensorGroup protocol with the following?

No, functions in Swift protocols cannot have a body. Default implementations are implemented using protocol extensions, exactly like how _unknownShapeList is implemented today. You should just remove the protocol requirement _unknownShapeList instead.

An even better question is, why not have _shapeList: [TensorShape], where you get the static shape information of the tensors in the group (i.e., through the shape attribute -- if that's supported in S4TF).

That isn't what _unknownShapeList is used for. It's literally used as an array of nils to represent known a list of unknown shapes to be passed into dataset ops. It would be less ideal and inefficient to use the shape property on tensors, because that would bypass the TF runtime unnecessarily while shapes can be inferred through those ops. All we need is to pass a list of nils as a placeholder that also indicates the cardinality of the tensor group.

@dan-zheng @rxwei I think the implementation is complete now. I also made the following couple changes:

Removed the _unknownShapeList protocol requirement as @rxwei suggested and added back the default implementation in a TensorGroup extension.
Removed TensorPair entirely and just added the following just above the dataset zip operation:

/// A 2-tuple-like struct that conforms to TensorGroup that represents the
/// result type of a zip operation between two datasets.
public struct ZippedTensors<T: TensorGroup, U: TensorGroup> : TensorGroup {
  public var first: T
  public var second: U
}

That's the only place where it was used and given the automatic derivation I don't think it's an important enough component to have it's own file. I don't know your conventions though and could revert back if you want.
The code is not super nice and I was wondering what your formatting conventions are. I noticed that the C++ codebase uses various styles so I wasn't sure which you prefer. Also, I haven't added tests yet, but I plan to do so soon. However, I'm not sure how to test the initializer and the unpacking function. Is there an example of other tests I could use?

Great. The additional changes you described above make sense to me. Can you confirm that this is passing all existing TensorFlow and TensorFlowRuntime tests on your machine locally?

I'm currently compiling. I'll let you know when I'm able to run them. I was using incremental builds using ninja swift so far, and that was great, but when I tried running the tests, the build script decided to recompile pretty much everything. Is there a way to also run tests through ninja?

I am getting a weird error. So for this piece code in the stdlib, conformance is not derived while compiling:
/// A 2-tuple-like struct that conforms to TensorGroup that represents the
/// result type of a zip operation between two datasets.
public struct ZippedTensors<T : TensorGroup, U : TensorGroup> : TensorGroup {
  public var first: T
  public var second: U
}

// TODO(SR-9156): This does not work in graph mode.
@inlinable @inline(__always)
public func zip<T : TensorGroup, U : TensorGroup>(
  _ dataset1: Dataset<T>, _ dataset2: Dataset<U>
) -> Dataset<ZippedTensors<T, U>> {
  let handle: VariantHandle = #tfop(
     "ZipDataset", ZippedTensors(dataset1._handle, dataset2._handle),
     output_types$dtype: ZippedTensors<T, U>._typeList,
     output_shapes: ZippedTensors<T, U>._unknownShapeList)
  return Dataset(_handle: handle)
}

However, when I try to compile the following separately, using the freshly compiled swiftc, everything works fine:
public struct TensorPair2<T : TensorGroup, U : TensorGroup> : TensorGroup {
  public var first: T
  public var second: U
}

let test = TensorPair2(
  first: TensorPair2(
    first: Tensor<Int32>([[0, 3], [4, 5]]),
    second: Tensor<Bool>([true, false])),
  second: Tensor<Float32>([0.0, 0.5]))

print(type(of: test)._typeList)

Do you know why this may be happening? Which Swift compiler does the build script use to compile the stdlib?

I can actually verify that if I move ZippedTensors and the zip function outside of stdlib and compile separately, then everything works fine. However, if I leave them in the stdlib, then I get a compiler error saying that ZippedTensors does not conform to TensorGroup. Why does that happen?

I think this may be due to compiling the struct for which the compiler needs to derive conformance, together with the actual TensorGroup protocol. I'm not sure what to do to resolve this.

Could you share the exact error you got when compiling stdlib?

If I include the following:
/// A 2-tuple-like struct that conforms to TensorGroup that represents the
/// result type of a zip operation between two datasets.
public struct ZippedTensors<T : TensorGroup, U : TensorGroup> : TensorGroup {
  public var first: T
  public var second: U

  public init(_ first: T, _ second: U) {
    self.first = first
    self.second = second
  }
}

// TODO(SR-9156): This does not work in graph mode.
@inlinable @inline(__always)
public func zip<T : TensorGroup, U : TensorGroup>(
  _ dataset1: Dataset<T>, _ dataset2: Dataset<U>
) -> Dataset<ZippedTensors<T, U>> {
  let handle: VariantHandle = #tfop(
     "ZipDataset", ZippedTensors(dataset1._handle, dataset2._handle),
     output_types$dtype: ZippedTensors<T, U>._typeList,
     output_shapes: ZippedTensors<T, U>._unknownShapeList)
  return Dataset(_handle: handle)
}

I get this error:
swift-source/swift/stdlib/public/TensorFlow/Dataset.swift:192:15: error: type 'ZippedTensors<T, U>' does not conform to protocol 'TensorGroup'
public struct ZippedTensors<T : TensorGroup, U : TensorGroup> : TensorGroup {
              ^
swift-source/swift/stdlib/public/TensorFlow/Dataset.swift:192:15: error: type 'ZippedTensors<T, U>' does not conform to protocol 'TensorArrayProtocol'
public struct ZippedTensors<T : TensorGroup, U : TensorGroup> : TensorGroup {
              ^
swift-source/swift/stdlib/public/TensorFlow/TensorGroup.swift:41:14: note: protocol requires property '_typeList' with type '[TensorDataType]'; do you want to add a stub?
  static var _typeList: [TensorDataType] { get }
             ^
swift-source/swift/stdlib/public/TensorFlow/TensorGroup.swift:45:3: note: protocol requires initializer 'init(_owning:)' with type '(_owning: UnsafePointer<CTensorHandle>?)' (aka '(_owning: Optional<UnsafePointer<OpaquePointer>>)'); do you want to add a stub?
  init(_owning tensorHandles: UnsafePointer<CTensorHandle>?)
  ^
swift-source/swift/stdlib/public/TensorFlow/TensorGroup.swift:29:8: note: protocol requires function '_unpackTensorHandles(into:)' with type '(UnsafeMutablePointer<CTensorHandle>?) -> ()' (aka '(Optional<UnsafeMutablePointer<OpaquePointer>>) -> ()'); do you want to add a stub?
  func _unpackTensorHandles(into address: UnsafeMutablePointer<CTensorHandle>?)
       ^
swift-source/swift/stdlib/public/TensorFlow/Dataset.swift:209:26: error: type 'ZippedTensors<T, U>' has no member '_typeList'
     output_types$dtype: ZippedTensors<T, U>._typeList,
                         ^~~~~~~~~~~~~~~~~~~
swift-source/swift/stdlib/public/TensorFlow/TensorGroup.swift:41:14: note: did you mean '_typeList'?
  static var _typeList: [TensorDataType] { get }
             ^

But if I move that code outside of stdlib and compile it independently, it compiles fine.

I tried to trace this down and I believe that TensorGroup is not considered a known protocol by the compiler when the compilation of ZippedTensors is triggered. Could this be because it hasn't been compiled yet? And is there a way to avoid this by maybe having the compiler first compile TensorGroup and treat it as a known protocol?

I can now verify this because I also tried adding the following hacky tweak at Line 53 of DerivedConformances.cpp:
  // Only known protocols can be derived.
  auto knownProtocol = Protocol->getKnownProtocolKind();
  if (Protocol->getNameStr().contains("TensorGroup")) {
    knownProtocol = KnownProtocolKind::TensorGroup;
    Protocol->setKnownProtocolKind(KnownProtocolKind::TensorGroup);
  }
  if (Protocol->getNameStr().contains("TensorArrayProtocol")) {
    knownProtocol = KnownProtocolKind::TensorArrayProtocol;
    Protocol->setKnownProtocolKind(KnownProtocolKind::TensorArrayProtocol);
  }
  if (!knownProtocol)
    return false;

When I do that, stdlib compiles fine.

I wonder what happens if you move TensorGroup.swift above Dataset.swift in stdlib/public/TensorFlow/CMakeLists.txt?

I'll try that, but looking at the actual invocation to swiftc, all the swift source file names are dumped in a text file in alphabetical order and then that's passed to swiftc. Also, I noticed that the Swift compiler only sets the known protocol flags after loading the standard library (according to my understanding). Thus, there may be no known protocols while combining the standard library.

@dan-zheng I just tried that and can confirm it doesn't work. :/

I digged a bit and discovered the file KnownStdlibTypes.def. I added TensorArrayProtocol and TensorGroup there as protocol declarations and I'm testing this now.

Never-mind that didn't work.

I found the fix for the "no known protocol found" error:
--- a/lib/AST/ASTContext.cpp
+++ b/lib/AST/ASTContext.cpp
@@ -1002,6 +1002,7 @@ ProtocolDecl *ASTContext::getProtocol(KnownProtocolKind kind) const {
   for (auto result : results) {
     if (auto protocol = dyn_cast<ProtocolDecl>(result)) {
       getImpl().KnownProtocols[index] = protocol;
+      protocol->setKnownProtocolKind(kind);
       return protocol;
     }
   }

ASTContext::getProtocol looks up known protocols, but doesn't set the known protocol kind bit in the protocol. This led to the unexpected behavior (known protocol initially found, but not found later by derived conformances).
With this change, the stdlib compiles on my WIP branch. Feel free to cherry-pick the changes - all that's left is to add tests. 🙂

That's a great find! Thanks a lot Dan! I'll verify that the existing tensorflow tests pass fine and try to add a couple for the derivation later today.

I incorporated Dan's changes and also made the dataset handle and initializer public so that users can add support for new datasets using raw TF ops from outside stdlib.

I added some tests for TensorGroup and can verify that they pass. Also, all existing tests pass, except for DatasetAsGlobalVar and IteratorAsGlobalVar, which fail with the following error:
Fatal error: GetNext() failed because the iterator has not been initialized. Ensure that you have run the initializer operation for this iterator before getting the next element.

This does not seem to be relevant to the TensorGroup conformance derivation though.

@rxwei @dan-zheng I merged upstream changes and now all existing tests for this PR pass on my local machine.

I just got back from traveling and was wondering what the status of this issue is. Is there something remaining that I need to do?

I believe this should be ready to be merged. All tests pass on my machine. Could we also run them on the CI server?

The implementation LGTM. I can trigger tests for you when those comments get addressed. Thanks!

Thanks Richard! The comments have now been addressed!

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@eaplatanios: could you please address the CI test failures? They look like:
/home/swiftci/jenkins/workspace/swift-PR-TensorFlow-Linux/swift/test/TensorFlowRuntime/tensor_array_protocol.swift:57:66: error: instance member 'initialize' cannot be used on type 'UnsafeMutableBufferPointer<CTensorHandle>' (aka 'UnsafeMutableBufferPointer<OpaquePointer>'); did you mean to use a value of this type instead?
  let expectedBuffer = UnsafeMutableBufferPointer<CTensorHandle>.initialize(
                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^

@dan-zheng Sorry I didn't run the tests after the last formatting edits. Fixed now and. checked that the tests pass on my machine.

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow

I'm not sure what's wrong with Linux CPU tests. Perhaps there's a segfault somewhere.

I have seen these tests failing on my machine too before but wasn’t sure why. I believe I mentioned it in an earlier comment in this thread. I can look into it tomorrow, but I remember I didn’t manage to figure it out before, although I didn’t spend too much time on it.

@rxwei Not sure which tests fail on the CI server. When I click on the failed test suites, the log shows all of them as having succeeded.

@rxwei Not sure which tests fail on the CI server. When I click on the failed test suites, the log shows all of them as having succeeded.

Yes, that's weird. Two tests crashed despite printing All tests passed.
Failing Tests (2):
    Swift(linux-x86_64) :: TensorFlowRuntime/dataset_global.swift
    Swift(linux-x86_64) :: TensorFlowRuntime/dataset_api.swift

Retriggering CI to see if it's reproducible.

@swift-ci Please test tensorflow

@dan-zheng @rxwei I noticed something interesting about the failing tests. If I try to run the tests using lit test-macosx-x86_64/TensorFlowRuntime/dataset_api.swift -sv,  for example, then I see Unsupported Tests : 1 and no failures. However, when I run all tests together using ./utils/build-script --preset=tensorflow_test, I get the failures. Is there a way to just run the failing tests without having to rerun everything? Also, this behavior seems unexpected anyway so maybe there is something wrong.

I tried to dig into this a bit more. It seems as if tests like DatasetAPI.SingleValueManualIterator_CPU are run twice.  Ensure that you have run the initializer operation for this iterator before getting the next element.: file /Users/eaplatanios/Development/GitHub/swift-source/swift/stdlib/public/TensorFlow/CompilerRuntime.swift, line 2035. Not sure why this happens.
The output looks like this:
Command Output (stdout):
--
[ RUN      ] DatasetAPI.SingleValueManualIterator_CPU
[       OK ] DatasetAPI.SingleValueManualIterator_CPU
[ RUN      ] DatasetAPI.DatasetIteration_CPU
[       OK ] DatasetAPI.DatasetIteration_CPU
[ RUN      ] DatasetAPI.SingleValueTransformations_CPU
[       OK ] DatasetAPI.SingleValueTransformations_CPU
[ RUN      ] DatasetAPI.SingleValueHOFs_CPU
[       OK ] DatasetAPI.SingleValueHOFs_CPU
[ RUN      ] DatasetAPI.MapToDifferentType_CPU
[       OK ] DatasetAPI.MapToDifferentType_CPU
[ RUN      ] DatasetAPI.SingleValueBatched_CPU
[       OK ] DatasetAPI.SingleValueBatched_CPU
[ RUN      ] DatasetAPI.DoubleValueDatasetIteration_CPU
[       OK ] DatasetAPI.DoubleValueDatasetIteration_CPU
DatasetAPI: All tests passed
[ RUN      ] DatasetAPI.SingleValueManualIterator_CPU
stderr>>> Fatal error: GetNext() failed because the iterator has not been initialized. Ensure that you have run the initializer operation for this iterator before getting the next element.: file /Users/eaplatanios/Development/GitHub/swift-source/swift/stdlib/public/TensorFlow/CompilerRuntime.swift, line 2035
stderr>>> CRASHED: SIGILL
the test crashed unexpectedly
[     FAIL ] DatasetAPI.SingleValueManualIterator_CPU
[ RUN      ] DatasetAPI.DatasetIteration_CPU
stderr>>> Fatal error: GetNext() failed because the iterator has not been initialized. Ensure that you have run the initializer operation for this iterator before getting the next element.: file /Users/eaplatanios/Development/GitHub/swift-source/swift/stdlib/public/TensorFlow/CompilerRuntime.swift, line 2035
stderr>>> CRASHED: SIGILL
the test crashed unexpectedly
[     FAIL ] DatasetAPI.DatasetIteration_CPU
[ RUN      ] DatasetAPI.SingleValueTransformations_CPU
stderr>>> Fatal error: GetNext() failed because the iterator has not been initialized. Ensure that you have run the initializer operation for this iterator before getting the next element.: file /Users/eaplatanios/Development/GitHub/swift-source/swift/stdlib/public/TensorFlow/CompilerRuntime.swift, line 2035
stderr>>> CRASHED: SIGILL
the test crashed unexpectedly
[     FAIL ] DatasetAPI.SingleValueTransformations_CPU
[ RUN      ] DatasetAPI.SingleValueBatched_CPU
stderr>>> Fatal error: GetNext() failed because the iterator has not been initialized. Ensure that you have run the initializer operation for this iterator before getting the next element.: file /Users/eaplatanios/Development/GitHub/swift-source/swift/stdlib/public/TensorFlow/CompilerRuntime.swift, line 2035
stderr>>> CRASHED: SIGILL
the test crashed unexpectedly
[     FAIL ] DatasetAPI.SingleValueBatched_CPU
DatasetAPI: Some tests failed, aborting

TensorFlowRuntime tests require special flags to lit.
lit test-macosx-x86_64/TensorFlowRuntime/tensor_autodiff_runtime.swift --param swift_tensorflow_path=../../../../swift-tf-source/tensorflow/bazel-bin/tensorflow --param swift_test_mode=optimize -sv

@rxwei so I found that adding this parameter --param swift_test_mode=optimize makes the tests run and fail. Without it they don't even run. Why is that?

I'm wondering if the -O compilation mode is removing the #tfop("MakeIterator", _handle, resource) as Void call in Dataset.makeIterator(), which is placed there for its side-effects.

@marcrasi implemented the eager dataset code path and agreed to take a look.

I'll quickly explain what "--param swift_test_mode=optimize" does, and then I'll take a look at the failure.
It makes the compiler run with -O, as you have guessed. Here's where it does that.
It also enables tests that have a line saying // REQUIRES: swift_test_mode_optimize. So that's why the test doesn't run when you don't specify it. (A lot of the TF tests uses to depend on -O. I think recent developments may have made them run without -O, but looks like we haven't gotten around to removing // REQUIRES: swift_test_mode_optimize from a lot of places yet).
The CI tests run all the tests once without optimize, and then once again with optimize.

Thanks for the explanation @marcrasi ! I wasn't aware of the // REQUIRES: swift_test_mode_optimize flag.
I noticed that if I remove the // REQUIRES: swift_test_mode_optimize from dataset_api.swift the tests now run (as expected), but still fail with the same errors, which would suggest that the compiler -O flag is not the issue.

I noticed that if I remove the // REQUIRES: swift_test_mode_optimize from dataset_api.swift the tests now run (as expected), but still fail with the same errors, which would suggest that the compiler -O flag is not the issue.

Good to know, thanks!
Sorry, I haven't had time to actually look at the failure yet. I think I'll have some time in the next few hours.

Note that there are two RUN lines in the tests. The first one runs in "eager" mode and the second runs in "graph program extraction" mode. It fails on "graph program extraction" mode.
GPE is related to const-evaluation, and the comment above static var _unknownShapeList: [TensorShape?] { get } in TensorGroup.swift says something about const-evaluation. So I decided to try adding that line back. It fixed the tests!
If the problem was indeed a problem with const-evaluation, I would have expected the failure message to be something about "expression not constant evaluable". Maybe there is some recent bug in GPE causing it to do weird things when expressions are not const evaluable?
@eaplatanios is this enough information for you to continue?

It is likely that there's logic that requires _unknownShapeList to be a protocol requirement in addition to having a default implementation in a protocol extension.

@marcrasi Thanks a lot! That's very informative and useful. So, the question now is: should I just add the protocol requirement back and then we try to merge this PR? Or should I also look into why removing it results in these errors?

Feel free to add the requirement back!

Yeah, if the _unknownShapeList requirement is compatible with your changes in this PR, adding it back without worrying about why it's necessary sounds good to me.

Related note: If this is related to constant evaluation, I suggest you try making _unknownShapeList be @inlinable first.

Thanks! I added back the protocol requirement because making the static property in the extension @inlinable did not work (it resulted in the same errors). I also renamed ZippedTensors to Zip2Tensor as per Richard's comment, to match the Zip2Sequence convention.
I believe this should be ready to merge. Could we run the tests on the CI again to make sure everything is fine now?

Thanks!

I also renamed ZippedTensors to Zip2Tensor as per Richard's comment, to match the Zip2Sequence convention.

Nit: My suggestion was actually Zip2Tensors because I think it isn't really a Tensor but a high dimensional array of pairs. What do you think? Is there a more accurate name for this?

Oh right. I guess if we want to be consistent we could also go with Zip2TensorGroup. It's a bit long but I don't imagine it being frequently spelled out in users' code.

Done! Should hopefully pass all tests now. :)

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow Linux

@swift-ci please test tensorflow Linux CPU

Thanks Anthony. Congrats on getting this done!

Thanks Anthony. Congrats on getting this done!Thanks Anthony. Congrats on getting this done!

Thanks Richard! And thanks everyone for the helpful pointers and patience. :)


Pull Ceibo from npm instead of Bower

Thanks for taking care of https://github.com/san650/ceibo/issues/7 earlier! This PR switches ember-cli-page-object to use the Ceibo package you published to npm, and gets rid of the extra blueprint and documentation around Bower usage.

@dfreeman Thanks for contributing!

@dfreeman this fix is also included on v1.12.0, cheers and thanks!


Fetching for collection for KSM chain while on BSX

Seems singleton instance might cause some issues but seems this is not the case as don't have opened another window as it is the only one point to kodadot
Mind set correct address 2 after connected to basilisk.
Seems this is the culprit of many issues we have there.

you can replicate it

open incognito
open console
https://beta.kodadot.xyz/bsx/explore/?tab=GALLERY&page=1
check logs

I know @Jarsen136 might be great for investigation 😄
I've also raised the amount as it's becoming a bit culprit of other issues.
hints

vuex-persist
https://github.com/kodadot/nft-gallery/blob/main/store/index.ts#L33
https://github.com/kodadot/nft-gallery/blob/main/store/identity.ts#L112
https://github.com/kodadot/nft-gallery/blob/main/store/chain.ts

Seems somewhere internally it connects to Kusama for the very first time.
This time it played well, but usually, it goes in a different order.
Check network and WS network tab in incognito for first time

Seems there is a desync of operations once first time client connects to the default endpoint and first initial requests comes afterwards once already client is reporting connected to BSX
https://github.com/kodadot/packages/blob/99d6be9c0ad2dc62000c67945a4e3ebfcaf4c15e/vuex-options/src/defaults/endpoints.ts#L84

The suggestion is to remove vuex-persist
We might loose permanent settings

@vikiival any updates? 😄

@vikiival any updates? 😄

Yup,
polishing tests https://github.com/kodadot/packages/tree/brand-new-sub-api


[BSE-227] Support time unit without quotation mark

Move DATEDIFF/TIMEDIFF/DATEADD/TIMEADD to calcite

Close this PR because everything can be done in Bodo repo


zsh: segmentation fault  dependency-graph TestDependency.xcodeproj

What happened?
Test with my xcodeproj failed. below is the error log
`zsh: segmentation fault`  dependency-graph TestDependency.xcodeproj

dependency-graph version: 1.2.0, installed by brew
Project Document Format Xcode 14.0
Xcode Version 15.0 (15A240d)
arch i386
uname -m x86_64
What are the steps to reproduce?
Create a new test project test for it.
What is the expected behavior?
show the result as the document mentioned.

Getting similar issue but on M2 max MacBook with Xcode 15.0.1

I have run it successfully on M1 MackBook with xcode 15 now. But it only show the target dependencies, if it can also parser the  linked libraries, frameworks in the buildPhase order by configuration, that would be even more perfect.

I'm also seeing a Segmentation fault: 11 error running on a M1 MacBook Pro running on Ventura (13.6). It happens with both an Xcode project and a Package.swift file.

Same issue here.

Same problem.
Xcode 15.0.1
Sonoma 14.1.2
M1 Pro

Same. M1 Max, Sonoma 14.2, and Xcode 15.0.1

I am working with Xcode 15 running on Sonoma 14.0. Getting the same issue.

I second it on 2024 :)


@typescript-eslint/no-unsafe-return rule (and only that rule) won't clear itself after code is fixed

Issue Type: Bug
Sometimes I will fix some code but be left with a stale @typescript-eslint/no-unsafe-return ESLint error that won't go away until I close and re-open the workspace window. This now happens several times per day. If I close the code file, the error disappears from my Problems pane, but if I re-open the file the error comes back. Closing and re-opening the workspace makes it go away, until the next time it happens later in the day.
The problem does not repro when running ESLint from the command line from my project's working directory, which is one of two directories listed in my workspace's ESLint eslint.workingDirectories setting.
What's weird is that it's just this one rule that has this behavior.  Here's some example code where I'm seeing it right now:
        const notFoundResult: NotFoundResult = { type: 'not found' };
        return notFoundResult;
        ^^^^^  Unsafe return of an `any` typed value.eslint@typescript-eslint/no-unsafe-return

In the code above, NotFoundResult is a type imported from another folder. If I hang the mouse over the type name, it correctly shows the type.

Whenever this happens, it always shows up immediatly after I fix other real errors with nearby code. When I fix the other errors, this one sticks around and won't go away.
When manually copy the type declaration from the other file into this one, the error also goes away.  When I remove the manual declaration, the error comes back.
The only thing that's maybe unusual about the imported type is that it comes from a directory outside my working directory in another project's working directory that contains shared code between my projects. The import looks like this:
import { NotFoundResult, RedirectResult } from '@hshared/results';

How can I help diagnose this?  It's intermittent and goes away upon reload, I've not been able to come up with a way to build a sample repo that reliably causes the problem.
FWIW, this is a relatively recent problem that started showing up sometime in the last 2 weeks for me, but admittedly I took a long break to work on other stuff before coming back to this project, so it could have happened any time in the last year or so. I don't believe I've seen this problem in my other TS projects.
Extension version: 2.1.23
VS Code version: Code 1.59.1 (3866c3553be8b268c8a7f8c0482c0c0177aa8bfa, 2021-08-19T11:53:52.479Z)
OS version: Darwin x64 20.6.0
Restricted Mode: No

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz (8 x 2800)

GPU Status
2d_canvas: enabledgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
7, 6, 5

Memory (System)
16.00GB (0.10GB free)

Process Argv
--crash-reporter-id fc815e00-6664-4e31-9edb-1a84fa91e72d

Screen Reader
no

VM
0%

A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383cf:30185419
pythonvspyt602:30300191
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstes627:30244334
pythonvspyt639:30300192
pythontb:30283811
pythonvspyt551:30345470
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
pythondataviewer:30285071
pythonvsuse255:30340121
vscod805cf:30301675
pythonvspyt200:30340761
vscextlangct:30333562
binariesv615:30325510
vsccppwt:30329788
pythonvssor306:30344512
bridge0708:30335490
pygetstartedc2:30351386
vstre464cf:30350173
bridge0723:30353136
vsdyn321cf:30354108

Update: it goes away when I use the Restart ESLint Server command.
Also, there are no messages in the ESLint output channel that show up when this happens.

I was able to repro this again over the last two days. I'm starting to see a pattern in the reproes:

First repro: I just finished merging a PR so I switched back to the main branch (which changed a bunch of files) and then did a git pull origin that changed the files back to what they were previously. The code hadn't changed at all, but I was left with some of these unsafe-any lint errors that automatically fixed themselves when restarting VSCode.
Second repro: I just refactored an operation that previously took a single object and now takes an array. So I renamed some types to pluralize their names (using Rename Symbol, aka F2) and then renamed one code file. When I renamed the code file, I started seeing an "Unsafe assignment of an any value - eslint@typescript-eslint/no-unsafe-assignment" error inside the file that had been renamed when referring to valid code using the renamed, plural name. I saw the same behavior as noted in the OP, where IntelliSense knows that the code is valid but ESLint does not.

What both of these reproes have in common is that they happen immediately after file system changes:

Multiple files changed almost simultaneously
OR
Files being added, removed, or renamed

This made me wonder if the problem is a race condition between file-change notifications and the extension's internal state of the types involved.
I'll continue to observe to try to refine the pattern of these failures.

@justingrant  When this happens can you please check what ESLint in the terminal reports. I am pretty sure that this might be releated to typescript-eslint plugin and not necessarily to the ESLint extension.

When this happens can you please check what ESLint in the terminal reports. I am pretty sure that this might be releated to typescript-eslint plugin and not necessarily to the ESLint extension.

When filing this issue I did exactly that, but the command-line ESLint returned no errors. That's why I filed this issue here instead of with typescript-eslint. From the OP:

The problem does not repro when running ESLint from the command line from my project's working directory, which is one of two directories listed in my workspace's ESLint eslint.workingDirectories setting.

One thing I didn't try was to run ESLint from other directories (e.g. my workspace root). Next time the problem reproes, I'll try that too.
If there's any other diagnostic info I should collect when the problem reproes next, let me know and I'll collect it.

You can enable eslint.debug: true. This prints a lot of debug info to the ESLint output channel.

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!
@justingrant please ping if you have additional info and I will reopen.

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!
@justingrant please ping if you have additional info and I will reopen.

Hello!
It happens all the time on our project too and we got a lot of them.
We must restart ESLint Server inside vscode very often to make them disappear.
I think it is a problem of refresh after the contents of the node-modules change: we use personal NodeJs libraries, and when we modify their code, we have to rebuild our micro-services depending on them to update these libraries transpiled code inside the node-modules of our micro-services. Probably Eslint become unstables at this moment.
The VsCode integrated Typescript features have the same kind of problem: underlining in red some parts of the code for no reason.
Regards.

This sounds like a inter file dependency (a change in A makes an error on B go away or appear).
ESLint (the npm module) has no support for this since it assumes it always validates from scratch. This is nothing that can be done on type because it is by far to expensive (performance wise, battery life, ...)
What I did add for the next version of the extension is to re-lint files on focus change. I addition there is no an action to re-lint all files without restarting the server.
The new version will come out beginning of April.

This sounds like a inter file dependency (a change in A makes an error on B go away or appear).
ESLint (the npm module) has no support for this since it assumes it always validates from scratch. This is nothing that can be done on type because it is by far to expensive (performance wise, battery life, ...)
What I did add for the next version of the extension is to re-lint files on focus change. I addition there is no an action to re-lint all files without restarting the server.
The new version will come out beginning of April.

Thank you for your explanation. I understand it is not easy to manage efficiently refreshing with this kind of tool. :/
Regards.


Extendable page builders

Maybe implement an API to enable 3rd party page builders.
For example:

https://giuseppegurgone.com/xm/
isomorphic uland/uhtml?

Duplicate of https://github.com/bcomnes/siteup/issues/28


create session: property name must be is_development, not development…

…_mode

I see I'm not the first to submit this, but this PR contains the changes to .cpp and .h files for both engine versions.

Closing this PR as I have incorporated the work into this PR: https://github.com/LootLocker/unreal-server-sdk/pull/12


add driver

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.6%) to 70.974%

Totals

Change from base Build<PHONE_NUMBER>:
-0.6%

Covered Lines:
3842

Relevant Lines:
5184

💛  - Coveralls


ValueError: mutable default <class 'discord.utils._MissingSentinel'> for field name is not allowed: use default_factory

When trying to run Vulkan, following error message appears: ValueError: mutable default <class 'discord.utils._MissingSentinel'> for field name is not allowed: use default_factory.
Full log:
Traceback (most recent call last):
  File "/home/nikitaka/Documents/Vulkan-master/Vulkan-master/main.py", line 1, in <module>
    from Music.VulkanInitializer import VulkanInitializer
  File "/home/nikitaka/Documents/Vulkan-master/Vulkan-master/Music/VulkanInitializer.py", line 5, in <module>
    from Music.VulkanBot import VulkanBot
  File "/home/nikitaka/Documents/Vulkan-master/Vulkan-master/Music/VulkanBot.py", line 3, in <module>
    from discord.ext.commands.errors import CommandNotFound, MissingRequiredArgument
  File "/home/nikitaka/.local/lib/python3.11/site-packages/discord/ext/commands/__init__.py", line 18, in <module>
    from .flags import *
  File "/home/nikitaka/.local/lib/python3.11/site-packages/discord/ext/commands/flags.py", line 57, in <module>
    @dataclass
     ^^^^^^^^^
  File "/usr/lib64/python3.11/dataclasses.py", line 1220, in dataclass
    return wrap(cls)
           ^^^^^^^^^
  File "/usr/lib64/python3.11/dataclasses.py", line 1210, in wrap
    return _process_class(cls, init, repr, eq, order, unsafe_hash,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.11/dataclasses.py", line 958, in _process_class
    cls_fields.append(_get_field(cls, name, type, kw_only))
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.11/dataclasses.py", line 815, in _get_field
    raise ValueError(f'mutable default {type(f.default)} for field '
ValueError: mutable default <class 'discord.utils._MissingSentinel'> for field name is not allowed: use default_factory

I think it's not a problem with the bot itself, but with the discord.py package
P.S. I did pip install -r requirements.txt

Hello!
Like you said, the problem occurs in the discord.py library, i can't help with that. You can go to their github and report this issue.
Issue of pycord: https://github.com/Pycord-Development/pycord/issues


Upadated validations.py python script.

Fixed the behavior of validate_user function in validation.py.
Closes: #1
Fixes #<issue_number_goes_here>

It's a good idea to open an issue first for discussion.

[x] Tests pass
[x] Appropriate changes to README are included in PR

@marga-google

@googlebot I signed it!


One-liner: gave the status-bar squirrel icon cursor:pointer

The squirrel icon in the status bar should probably use the pointer cursor on hover since it is clickable and opens a new tab. The tooltip is the only indication that the icon is a link, I think this is a slight improvement.

Thanks for taking the time to add this! I've actually been in the (very, very slow) process of removing most uses of cursor: pointer from Atom though however, as it makes the app feel less native and more like a webapp running in a window. Though things may have changed since then – what do you think @simurai?

Interesting. It's a good point that cursor effects like pointers make the app feel less native. I do think that it's important to indicate some sort of interactivity to the user though. For a while I know I double-clicked the squirrel because it didn't appear to be a normal link. Can't say exactly why, but that was my default response.
If you have been removing the cursor:pointers in favour of underline or obvious-looking buttons then maybe this icon should have an alternate hover effect? Even darkening it 10% on hover might be an improvement.

I was going to purpose a similar change in the settings-view package: https://github.com/atom/settings-view/commit/7a6cc95cb49f9703cbbcba7b91fa405285b1214e
But I'll hold off on that for now.

How about:

Merge this PR now. Since some other items currently show a pointer.
At some point maybe replace it with another hover effect. Depending how https://github.com/atom/atom/pull/7698 pans out.

https://github.com/atom/atom/pull/7698 should also be easier if https://github.com/atom/atom/pull/11875 gets merged. Then we "own" all components and can introduce it first there. And then step by step start to update packages.

Ok, to be in line with https://github.com/atom/settings-view/pull/799, I'll take "Merge this PR now." back. 😉
Since there is no text to underline, have the :shipit: icon change color? Or maybe opacity: .6;

Changing color makes sense. I don't have an in depth knowledge of how the base styling works though, can you foresee any problems with changing color or opacity on hover? I think darken(@background-color-info, 10%) or something could look good.

Yeah, there isn't some kind of convention.
Here with lighten(@background-color-info, 15%):

I think I like lighten more. Opacity seems a little strange to me as a hover change. It's unusual for an item to go from opaque to transparent on hover, normally it's the other way around.

I think I like lighten more.

Sure. 👍  Let's do that.. (at least for now until there is a convention)

Alright, there you go, thanks for working through this with me 😃

🚢  Thanks @justo


[Technical Task] Bringing the pagination into the same style (admin page)

Brief overview
We have 2 different options in the admin page sections. It is necessary to investigate them for productivity and, based on the results of the investigation, bring the pagination in the admin part of the website into the same manner (style) (the appearance option in the second picture is more preferable).

In the “Команда” section we have additional filtering by quantity which doesn’t even work. After researching the results, either remove it or make it work (you can even add it to pagination in all sections).

Expected result
Pagination in the entire administrative part of the website is brought to the same manner (style) and works as best as possible from a performance point of view.

The pagination is the same style on the admin page


[CI/CD] Run slow workflows only if fast workflows pass

Workflow issues
I plan to create a master workflow file as the only workflow that runs on pull request, which manages other workflows to run in waves so that slow workflows don't start if fast ones fail in seconds
Platform
all
Anything else?
No response

Getting back to this ticket. The plan:

For starters, create a new callable workflow that use built-in Powershell scripting to execute a Github CLI call for workflow statuses and filter that to the status of the associated spellcheck action.
If that fails, fail this yaml.
Insert a call to this new yaml as a job on all heavy duty on-PR runs; fail instantly if this fails.

Initial YAML created

https://github.com/project-chip/connectedhomeip/actions/runs/8897889850/job/24433825293?pr=33241 Found a way to access "restyled" and other non-workflow checks that gh run list does not see. Seems to error out and there's not an easy way to parse this output, so I will be working on putting this in a Python script.


Zulip queue workers don't restart when underlying code changes in development

The Zulip queue workers are the only remaining part of the Zulip development environment that you have to kill and restart run-dev.py for changes to; it seems worth fixing this.
The process probably involves adding a listener similar to those used by django's runserver.py to tools/run-dev-queue-processors.

This was fixed via #1120.


FR: ToString() method that uses the largest metric prefix whose value is greater than or equal to 1, using the binary values instead of decimal values.

ToString() method that uses the largest metric prefix whose value is greater than or equal to 1, using the binary values instead of decimal values.
Use case: Windows display the binary values, so as to align to windows file sizes for comparison.

I don't understand your request. May you add an example of what you are trying to achieve?

@jerrywoo96 there's a .ToBinaryString() method that should do what you need.


Cannot map a file over an existing one on Windows

Description
This is already known, but I need to cross-link it to the Kubernetes repo.
If you try to map a file over an existing one such as c:\windows\system32\drivers\etc\hosts in the container, then it will not start. This still reproduces on the master build of containerd.
Any other relevant information:

Tracked internal to MS as 24234313
Related to https://github.com/microsoft/hcsshim/pull/707 . This is a corner case that wasn't covered.
Blocks merging of https://github.com/kubernetes/kubernetes/pull/83730

@PatrickLang - containerd isn't at fault here. Do we really need a bug open on them?

/close
This isn't related to containerd and we're tracking the issue with https://github.com/kubernetes/kubernetes/issues/70189


Can I use this library if I need a refresh token, or do I have to write everything from scratch

Can I use this library if I need a refresh token, or do I have to write everything from scratch
I am trying to build an email automation tool for microsoft outlook, and it seems your api only give access token. Maybe, you can add a link for those people in need of refresh token if you cannot use this library for microsoft.

@rjpruitt16 Msal v2.0 is currently in beta and will provide you with a refresh token. Please feel free to try it out and let us know what you think! Msal v1.x does not support refresh tokens as it implements the Implicit Grant Flow.

@tnorling thank you for the timely response


"Parincea" commune is listed in the drop-down menu

Description:
The commune is listed in the drop-down menu according to the law
Preconditions :the website (https://peviitor-ro.github.io/ui.orase/) is up and runing.
After every step delete the text you typed from the search bar.

Step 1
Type "Parincea" in the search bar.
Expected results
The location is listed in the drop-down menu as "Parincea, Bacău"


Gracefully fallback to %-style string formatting if .format() fails

For compatibility with lots of code with %-like formatting in log messages, we need to provide a fallback to this formatting.
An example is Celery with the following code:
    success_msg = """\
        Task %(name)s[%(id)s] succeeded in %(runtime)ss: %(return_value)s
    """

...

        info(self.success_msg.strip(), {
                'id': self.id, 'name': self.name,
                'return_value': self.repr_result(ret_value),
                'runtime': runtime})

Provided solution is "quick&dirty" and the proper way to fix it is to use the style parameter in Formatter init.

@brutasse Any comments?

@saabeilin LogstashFormatter already accepts a style= argument __init__, so I'd favor the style approach directly.

@brutasse Hm, why does it than fail with Celery? Had no time to debug deeper yet.

Because the argument is thrown away? .format(**fields) is called regardless of what was passed in the style init argument.

Here's what Python's base Formatter does with style: https://github.com/python/cpython/blob/master/Lib/logging/init.py#L480-L485

@brutasse Yes, exactly. It would be good to implement similar logic?

@saabeilin yes, that would be perfect.

@saabeilin did you try your example? All attributes seem to get formatted correctly into the message. If you want them to appear as individual attributes in the JSON result, they need to be passed in the extra kwarg.

@sfriesel It just breaks with Celery if you try to use the logstash-formatter as a drop-in replacement. I'll post stacktraces and how-to-reproduce when I have time.


Medium severity vulnerability found on<EMAIL_ADDRESS>

The concat-stream version used in static-module contains a vulnerability as reported by Snyk. It has been fixed in version 1.5.2.

+1
Uninitialized Memory Exposure
Medium severity
Vulnerable module: concat-stream
Introduced through<EMAIL_ADDRESS>›<EMAIL_ADDRESS>https://snyk.io/vuln/npm:concat-stream:20160901

fixed in 1.3.2


ListView Fails to Remove Multiple Items with RemoveRange Operation in Bound Collection

Describe the bug
In a ListView with a bound Collection, the RemoveRange operation does not remove multiple items as intended. Instead of deleting the specified range of items (e.g., from index 0 to 4), only a single item is removed. This issue disrupts the functionality of bulk removal operations in ListView collections.
Steps to reproduce the bug

Run the attached sample application - ListViewTestSample.zip.

Click the "Remove" button in the view.

Observe that the ListView does not remove the specified range of items.

Expected behavior
Upon clicking the "Remove" button:

Five items (indices 0 through 4) should be removed from the collection.

The ListView should update accordingly to reflect the removal of these five items simultaneously.

Screenshots
Before Button Click :

After Button Click :

NuGet package version
WinUI 3 - Windows App SDK 1.6.3: 1.6.241114003
Windows version
Windows 11 (23H2): Build 22631
Additional context
No response

It works for me (Windows 10 22H2, Windows App SDK 1.6.241114003)
if I do instead :
 OnCollectionChanged(new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Reset));


Signal range out of physical range

Hello,
I'm a bit lost here as this used to run fine. I have a script that converts raw EEG recordings to BIDS format using MNE python. Recently it asked me to install edfio to write my files as edf, fine. I install this but now on export I get the following error:
ValueError: Signal range [0.0, 0.026120599609374996] out of physical range: [0.003053998779296875, 0.04780600390625]
It exported fine before, I thought it was a unit problem (I believe my data is in uV instead of V). I converted the data to V and still get this error. I don't really understand what it means and what I can do about it.
Any pointers ?
Thanks

Do you get a warning from MNE about padding? If so, this should be fixed with https://github.com/mne-tools/mne-python/pull/12676. Until this is released, you can manually set physical_range in MNE's export function.

I can do a little bit more explanation here. Like @hofaflo mentioned if you see a padding warning like this:
EDF format requires equal-length data blocks, so XX seconds of zeros were appended to all channels when writing the final block.
it's a bug from MNE rather than edfio. The error is there because your data length is not a multiple of the sampling rate, and MNE tries to pad zeroes to the end. However your original data range ([0.003053998779296875, 0.04780600390625]) does not include zero, thus triggering the error.
The dev version of MNE no longer pads data with zero but the edge values (e.g. the last available number) so the padded data is always within the original range.
A temporary workaround is to manually specify the physical range when using mne.export.export_raw
physical_range = [0, raw.get_data(units='uV').max()]
raw.export(fname, physical_range=physical_range)

Ah yes I did have those warnings, which I suppressed because MNE gives me warnings for everything lol.
I understand the issue now, thank you for taking the time to explain it. Your solution worked.
I'm closing the issue.


[#19] begin app with jreleaser assembly

fixes #19

Codecov Report

Merging #20 (7797e27) into main (743f20c) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##               main      #20   +/-   ##
=========================================
  Coverage     81.30%   81.30%
  Complexity       30       30
=========================================
  Files             7        7
  Lines           107      107
  Branches          3        3
=========================================
  Hits             87       87
  Misses           17       17
  Partials          3        3

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Basic Data Structures link

http://interactivepython.org/runestone/static/pythonds/BasicDS/basic.html
↑ this is the current link and it is broken
↓ this link leads to the table of contents, 'Basic Data Structures' section
http://interactivepython.org/runestone/static/pythonds/index.html#basic-data-structures

Thanks for catching, updated with https://github.com/bento-io/collection/commit/e2d4a50cc2b760d32b167c150693639e70c4abea


[FEATURE] Comments

41eeb02, though would be nice if this could be light mode if user is using light mode.


[Request] Named instances

I'd find it very valuable if we could name gekko instances such that the name would show up both in the web UI as well as in the console (in the title bar, for example). The problem for me is that if I have a number of gekkos running, I find it difficult to track which instance is which.
What are the thoughts on this? Maybe something like this already exists and I'm simply unaware of it. I guess a workaround would be to view log files instead.

As for the CLI I am not sure how to even do this. What I do is use screen and name screen sessions accordingly. In different terminals you can sometimes set the title (example).
I definitely agree that we need this for the UI! The first step would be #911 which gives users more way to actually manage live gekkos. This is a nice follow up to that :)

Screen works perfectly fine for me here.

And you could do this on Windows:
start "Hi mom" node gekko.js

Added this request to #911!


Node Js 16.20.0 is not supporting Vue-cli version ~4.5.19

I am trying to upgrade Vue Js Project from Node 14.18.1 to Node 16.20.0. But NPM Install is throwing the below error.
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! Found<EMAIL_ADDRESS>npm ERR! node_modules/eslint
npm ERR!   dev<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer eslint@">= 1.6.0 < 7.0.0" from<EMAIL_ADDRESS>npm ERR! node_modules/@vue/cli-plugin-eslint
npm ERR!   dev<EMAIL_ADDRESS>from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR!
I see eslint 7.29.0 is supports Node V10+ in its documentation(https://www.npmjs.com/package/eslint/v/7.29.0). I would like to understand Is there any reason for the above error. Please help.
My Node Version: 16.20.0
NPM Version: 9.6.7
Machine Windows
"vue": "^3.1.0",
"@vue/cli-service": "~4.5.19"

It has nothing to do with the node version, it has all to do with the versions you are trying to use, first of all remove the dependency on eslint, since it's already a peer dependency, so it can pull the correct version
Second, you are using very outdated versions of vue cli
The latest is 5.0.8

[en] The dependent version of my project
[zh-cn] 我项目的依赖包
 "dependencies": {
    "axios": "^1.5.0",
    "core-js": "^3.30.2",
    "element-ui": "2.15.13",
    "vue": "^2.7.14",
    "vue-router": "^3.6.5",
    "vuex": "^3.6.2"
  },
  "devDependencies": {
    "@babel/core": "^7.21.8",
    "@babel/eslint-parser": "^7.21.8",
    "@commitlint/cli": "^17.6.3",
    "@commitlint/config-conventional": "^17.6.3",
    "@vue/cli-plugin-babel": "^5.0.8",
    "@vue/cli-plugin-eslint": "^5.0.8",
    "@vue/cli-service": "^5.0.8",
    "@vue/eslint-config-prettier": "^7.1.0",
    "chalk": "^4.1.2",
    "eslint": "^8.41.0",
    "eslint-config-airbnb-base": "^15.0.0",
    "eslint-plugin-import": "^2.27.5",
    "eslint-plugin-prettier": "^4.2.1",
    "eslint-plugin-vue": "^9.13.0",
    "husky": "^8.0.3",
    "less": "^4.1.3",
    "less-loader": "^11.1.0",
    "lint-staged": "^13.2.0",
    "prettier": "^2.8.8",
    "sass": "^1.62.1",
    "sass-loader": "^13.2.2",
    "semver": "^7.5.1"
  },

[en] Stable operation on node 14.21.3 version
[zh-cn] 稳定运行在node 14.21.3 版本

[en] The dependent version of my project [zh-cn] 我项目的依赖包
 "dependencies": {
    "axios": "^1.5.0",
    "core-js": "^3.30.2",
    "element-ui": "2.15.13",
    "vue": "^2.7.14",
    "vue-router": "^3.6.5",
    "vuex": "^3.6.2"
  },
  "devDependencies": {
    "@babel/core": "^7.21.8",
    "@babel/eslint-parser": "^7.21.8",
    "@commitlint/cli": "^17.6.3",
    "@commitlint/config-conventional": "^17.6.3",
    "@vue/cli-plugin-babel": "^5.0.8",
    "@vue/cli-plugin-eslint": "^5.0.8",
    "@vue/cli-service": "^5.0.8",
    "@vue/eslint-config-prettier": "^7.1.0",
    "chalk": "^4.1.2",
    "eslint": "^8.41.0",
    "eslint-config-airbnb-base": "^15.0.0",
    "eslint-plugin-import": "^2.27.5",
    "eslint-plugin-prettier": "^4.2.1",
    "eslint-plugin-vue": "^9.13.0",
    "husky": "^8.0.3",
    "less": "^4.1.3",
    "less-loader": "^11.1.0",
    "lint-staged": "^13.2.0",
    "prettier": "^2.8.8",
    "sass": "^1.62.1",
    "sass-loader": "^13.2.2",
    "semver": "^7.5.1"
  },

[en] Stable operation on node 14.21.3 version [zh-cn] 稳定运行在node 14.21.3 版本

juejin-掘金


train interrupt in the end of the first epoch

I train the model on 3 RTX3090 and finish the first epoch after about 10hours ,but its stuck on the end of the first epoch before save checkpoint. I use this command to train.
torchpack dist-run -np 3 python tools/train.py configs/nuscenes/det/transfusion/secfpn/camera+lidar/swint_v0p075/convfuser.yaml --model.encoders.camera.backbone.init_cfg.checkpoint pretrained/swint-nuimages-pretrained.pth --load_from pretrained/lidar-only-det.pth

Hi @Surtr07,
Sorry for the delayed response. I was busy working on other projects recently. Judging from the snapshots you provided, it does not seem to me that you ran into a potentially OOM problem, and it seems that the GPUs still have high occupancies. You may add a -v flag to your command and see if there are any error messages shown on the screen when the program freezes. Besides, you could also try skipping the evaluation on validation set by setting this parameter to a very large value. Let me know if you have further information.
Best,
Haotian


move to gh action and codeclimate

Coverage report
Total coverage

Status
Category
Percentage
Covered / Total

🟢
Statements
100%
121/121

🟢
Branches
100%
45/45

🟢
Functions
100%
37/37

🟢
Lines
100%
224/224

Status of coverage: 🟢 - ok, 🟡 - slightly more than threshold, 🔴 - under the threshold

Report generated by 🧪jest coverage report action from 5efe68c02aa6d14c1f98b5ecee96947254e9a5b4


Accessibility: properly position cursor at bottom line on prompt asking for yes/no

Newsboat: d6a5a09e5d6778e7aa4c852c8c1f14274fb56aee
When hitting A, i.e. mark-feed-read, a prompt at the bottom of the screen
asks for confirmation of the action. However, the TTY cursor stays at the
article list and only the visual highlight indicates that keys are sent to the
prompt, not to the feed list.
This is an issue for blind/visually impaired users using a braille display
and/or speech synthesis, as they likely miss the prompt.
Newsboat should set the TTY cursor to the prompt whenever it pops up. Compare
also to mutt's behaviour, when e.g. deleting fiels from a mailbox, i.e. $.

I've made an attempt at https://github.com/newsboat/newsboat/pull/2883
If you are able to build from source, feel free to test it and let us know if there are any issues.

Thanks. The focus is correctly moved, yes. However, IIRC, before pressing y
was enough, where now y<enter> is required. Also, it seems that something in
the key pressing logic is broken now because A, y, <Enter> does not mark
any article as read.

Strange, for me it works exactly as before (no need for <Enter>) with the only visual difference being the cursor position+visibility.
I'm wondering whether this has to do with the STFL version/patches or some kind of interaction between STFL, Ncurses, and whichever terminal(multiplexer) Newsboat is run in.
If that is the case, I think it is better to postpone this change until after replacing STFL (https://github.com/newsboat/newsboat/issues/232).
Although, that probably still takes a long time so we could try to find a different way, e.g. the workaround suggested by @Minoru:

The cleanest solution would be to add some methods to STFL to control the cursor visibility, but we might get away with calling some ncurses functions directly

I've carried out a few more tests: in Tmux, on a "raw" Linux TTY and on
mate-terminal, all with the same result. Please let me know if I can do
anything else. Thanks!


Removing "vue-side-nav"

their GitHub repo indicates that the component is now depricated

https://github.com/vue-comps/vue-side-nav


Update module golang.org/x/net to v0.33.0 release-0.19 [SECURITY]

Description of your changes
This PR contains the following updates:

Package
Change
Age
Adoption
Passing
Confidence

golang.org/x/net
v0.25.0 -> v0.33.0

CVE-2024-45338
An attacker can craft an input to the Parse functions that would be processed non-linearly with respect to its length, resulting in extremely slow parsing. This could cause a denial of service.
I have:

[ ] Run make reviewable to ensure this PR is ready for review.

How has this code been tested

/test-examples="examples/workspace-inline-aws.yaml"


Add dashboard.nvim

glepnir/dashboard-nvim
I am unsure which section this plugin would belong in.

I think a new category called "Start" or "Start screen" would fit this.


chore: reduce VotingPeriod to 1 week

Closes https://github.com/celestiaorg/celestia-app/issues/2625

Codecov Report

Merging #2627 (057f00e) into main (44be82a) will decrease coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #2627      +/-   ##
==========================================
- Coverage   20.63%   20.62%   -0.01%
==========================================
  Files         133      133
  Lines       15346    15345       -1
==========================================
- Hits         3166     3165       -1
  Misses      11877    11877
  Partials      303      303

Files
Coverage Δ

app/default_overrides.go
15.10% <100.00%> (-0.61%)
:arrow_down:


Expose modfuns for future pipe use (AZ561)

After finding anonymous functions to be quite brittle during rolling upgrades, Riak Pipe is migrating to modfun tuples.  This patch exposes the functions that will be referenced as modfuns in the 1.1.0 version of Riak.  They are exposed here such that Riak 1.0.2 will know what to do with modfuns during the rolling upgrade to 1.1.0.

+1 to merge.


Create wg.txt

create wg.txt file for my school Willstätter-Gymnasium Nürnberg

@samynos Please provide us with:

the school official website URL
the school street address, including city and country
a proof, which shows that the school recognizes the domain you are submitting as an official email domain for the students.

@samynos You might miss my previous comment. Please react.

@samynos I am sorry, this request remains unanswered for a while. I have to close it without merging. Please reopen and comment if you have an update regarding the aforementioned issue. Thank you for your understanding!

@philipto

School-URL: http://www.willstaetter-gymnasium.de/
School-Address: Innerer Laufer Platz 11  90403 Nürnberg
my email is an official email domain but only for regitration or as login email (e.g. microsoft office, webuntis) and not for receiving emails outside the school


Issue: Getting Error while integrating confluence attachment

Issue you'd like to raise.
I'm encountering an error while trying to integrate confluenece attachment using the keyword "include_attachments=True", without these keyword I am able to do question answering on Text content.
But I want to fetch attachment of the confluence space. Below is my code:

I encounter the following error:

Suggestion:
No response

Created a chunk of size 494, which is longer than the specified 100
Created a chunk of size 230, which is longer than the specified 100
Created a chunk of size 121, which is longer than the specified 100
Created a chunk of size 224, which is longer than the specified 100
Created a chunk of size 103, which is longer than the specified 100
Created a chunk of size 638, which is longer than the specified 100
Created a chunk of size 112, which is longer than the specified 100
Created a chunk of size 228, which is longer than the specified 100
Created a chunk of size 147, which is longer than the specified 100
Created a chunk of size 127, which is longer than the specified 100
Created a chunk of size 306, which is longer than the specified 100
Created a chunk of size 105, which is longer than the specified 100
Created a chunk of size 147, which is longer than the specified 100
Created a chunk of size 127, which is longer than the specified 100
Created a chunk of size 461, which is longer than the specified 100
Created a chunk of size 160, which is longer than the specified 100
Created a chunk of size 866, which is longer than the specified 100
Created a chunk of size 288, which is longer than the specified 100
Created a chunk of size 6699, which is longer than the specified 100
Created a chunk of size 374, which is longer than the specified 100
Created a chunk of size 296, which is longer than the specified 100
Created a chunk of size 165, which is longer than the specified 100
Created a chunk of size 325, which is longer than the specified 100
Created a chunk of size 140, which is longer than the specified 100
Created a chunk of size 140, which is longer than the specified 100
Created a chunk of size 270, which is longer than the specified 100
Created a chunk of size 137, which is longer than the specified 100
Created a chunk of size 101, which is longer than the specified 100
Created a chunk of size 144, which is longer than the specified 100
Created a chunk of size 173, which is longer than the specified 100
Created a chunk of size 143, which is longer than the specified 100
Created a chunk of size 116, which is longer than the specified 100
Created a chunk of size 220, which is longer than the specified 100
Created a chunk of size 120, which is longer than the specified 100
Created a chunk of size 309, which is longer than the specified 100
Created a chunk of size 304, which is longer than the specified 100
Created a chunk of size 170, which is longer than the specified 100
Created a chunk of size 217, which is longer than the specified 100
Created a chunk of size 149, which is longer than the specified 100
Created a chunk of size 1142, which is longer than the specified 100
Created a chunk of size 101, which is longer than the specified 100
Created a chunk of size 179, which is longer than the specified 100
Created a chunk of size 131, which is longer than the specified 100
Created a chunk of size 1723, which is longer than the specified 100
Created a chunk of size 101, which is longer than the specified 100
Created a chunk of size 144, which is longer than the specified 100
Created a chunk of size 130, which is longer than the specified 100
Created a chunk of size 104, which is longer than the specified 100
Created a chunk of size 172, which is longer than the specified 100
Created a chunk of size 327, which is longer than the specified 100
Created a chunk of size 355, which is longer than the specified 100
Created a chunk of size 109, which is longer than the specified 100
Created a chunk of size 278, which is longer than the specified 100
Created a chunk of size 238, which is longer than the specified 100
Created a chunk of size 1624, which is longer than the specified 100
Created a chunk of size 2336, which is longer than the specified 100
Created a chunk of size 165, which is longer than the specified 100
Created a chunk of size 1237, which is longer than the specified 100
Created a chunk of size 325, which is longer than the specified 100
Created a chunk of size 228, which is longer than the specified 100


v5.0.2: Segfault when warping windows between displays each containing initially a single window

I have a segmentation fault with yabai version 5.0.2 installed via homebrew:
 ❯ brew info yabai
==> koekeishiya/formulae/yabai: stable 5.0.2, HEAD
A tiling window manager for macOS based on binary space partitioning.
https://github.com/koekeishiya/yabai
/usr/local/Cellar/yabai/5.0.2 (7 files, 1.7MB) *
  Built from source on 2022-12-17 at 08:45:40
From: https://github.com/koekeishiya/homebrew-formulae/blob/HEAD/yabai.rb
==> Requirements
Required: macOS >= 11 ✔

I have attached three displays to my macMini 2018 (Intel CPU) with macOS Monterey 12.6.1:
  Display Settings

All spaces use the bsp layout.
❯ yabai -m query --spaces | jq '.[] | "\(.index),  \(.type)"'
"1,  bsp"
"2,  bsp"
"3,  bsp"
"4,  bsp"
"5,  bsp"
"6,  bsp"
"7,  bsp"
"8,  bsp"
"9,  bsp"
"10,  bsp"
"11,  bsp"
"12,  bsp"
"13,  bsp"
"14,  bsp"
"15,  bsp"
"16,  bsp"

I open on the left and central display a single iterm2 window:
❯ yabai -m query --windows | jq -r '.[] | select(."is-visible") | {"id": .id, "app": .app, "display": .display, "stack-index": ."stack-index", "frame": .frame}'
{
  "id": 444,
  "app": "iTerm2",
  "display": 2,
  "stack-index": 0,
  "frame": {
    "x": -1080,
    "y": 0,
    "w": 1080,
    "h": 1920
  }
}
{
  "id": 587,
  "app": "iTerm2",
  "display": 1,
  "stack-index": 0,
  "frame": {
    "x": 0,
    "y": 0,
    "w": 2560,
    "h": 1440
  }
}

Now, I want to warp the terminal window from the left display to the central display.
With the help of --insert west I want to bring in the window from the side where the originating display is located.
~
❯ yabai -m window 587 --insert west
~
❯ yabai -m window 444 --warp 587
# NOW SEGFAULT

If the window would be on the right display, I would use --insert east.
I have started yabai with the --verbose option which has as the last output following two lines:
EVENT_HANDLER_DAEMON_MESSAGE: window 444 --warp 587
[1]    9240 segmentation fault  yabai --verbose

For the full log see:
❯ yabai --verbose
process_is_observable: loginwindow (193) is blacklisted! ignoring..
process_is_observable: ViewBridgeAuxiliary (431) was marked as xpc service! ignoring..
process_is_observable: Dock (478) is blacklisted! ignoring..
process_is_observable: ViewBridgeAuxiliary (487) was marked as xpc service! ignoring..
process_is_observable: QuickLookUIService (PID 482) (502) was marked as xpc service! ignoring..
process_manager_add_running_processes: Finder (482) was found! caching psn..
process_is_observable: Google Drive (523) was marked as xpc service! ignoring..
process_is_observable: BetterZip Finder Extension (524) was marked as xpc service! ignoring..
process_is_observable: imklaunchagent (558) is blacklisted! ignoring..
process_is_observable: Dock Extra (565) was marked as xpc service! ignoring..
process_is_observable: VimR Networking (2848) was marked as xpc service! ignoring..
process_is_observable: UIKitSystem (4150) is blacklisted! ignoring..
application_observe: error 'kAXErrorCannotComplete' for application 'universalaccessd' and notification 'kAXCreatedNotification'
application_observe: error 'kAXErrorCannotComplete' for application 'universalaccessd' and notification 'kAXFocusedWindowChangedNotification'
application_observe: error 'kAXErrorCannotComplete' for application 'universalaccessd' and notification 'kAXWindowMovedNotification'
application_observe: error 'kAXErrorCannotComplete' for application 'universalaccessd' and notification 'kAXWindowResizedNotification'
application_observe: error 'kAXErrorCannotComplete' for application 'universalaccessd' and notification 'kAXTitleChangedNotification'
application_observe: error 'kAXErrorCannotComplete' for application 'universalaccessd' and notification 'kAXMenuOpenedNotification'
application_observe: error 'kAXErrorCannotComplete' for application 'universalaccessd' and notification 'kAXMenuClosedNotification'
window_manager_add_existing_application_windows: Google Chrome has windows that are not yet resolved
application_observe: error 'kAXErrorCannotComplete' for application 'skhd' and notification 'kAXCreatedNotification'
application_observe: error 'kAXErrorCannotComplete' for application 'skhd' and notification 'kAXFocusedWindowChangedNotification'
application_observe: error 'kAXErrorCannotComplete' for application 'skhd' and notification 'kAXWindowMovedNotification'
application_observe: error 'kAXErrorCannotComplete' for application 'skhd' and notification 'kAXWindowResizedNotification'
application_observe: error 'kAXErrorCannotComplete' for application 'skhd' and notification 'kAXTitleChangedNotification'
application_observe: error 'kAXErrorCannotComplete' for application 'skhd' and notification 'kAXMenuOpenedNotification'
application_observe: error 'kAXErrorCannotComplete' for application 'skhd' and notification 'kAXMenuClosedNotification'
application_observe: error 'kAXErrorCannotComplete' for application 'karabiner_console_user_server' and notification 'kAXCreatedNotification'
application_observe: error 'kAXErrorCannotComplete' for application 'karabiner_console_user_server' and notification 'kAXFocusedWindowChangedNotification'
application_observe: error 'kAXErrorCannotComplete' for application 'karabiner_console_user_server' and notification 'kAXWindowMovedNotification'
application_observe: error 'kAXErrorCannotComplete' for application 'karabiner_console_user_server' and notification 'kAXWindowResizedNotification'
application_observe: error 'kAXErrorCannotComplete' for application 'karabiner_console_user_server' and notification 'kAXTitleChangedNotification'
application_observe: error 'kAXErrorCannotComplete' for application 'karabiner_console_user_server' and notification 'kAXMenuOpenedNotification'
application_observe: error 'kAXErrorCannotComplete' for application 'karabiner_console_user_server' and notification 'kAXMenuClosedNotification'
application_observe: error 'kAXErrorCannotComplete' for application 'softwareupdated' and notification 'kAXCreatedNotification'
application_observe: error 'kAXErrorCannotComplete' for application 'softwareupdated' and notification 'kAXFocusedWindowChangedNotification'
application_observe: error 'kAXErrorCannotComplete' for application 'softwareupdated' and notification 'kAXWindowMovedNotification'
application_observe: error 'kAXErrorCannotComplete' for application 'softwareupdated' and notification 'kAXWindowResizedNotification'
application_observe: error 'kAXErrorCannotComplete' for application 'softwareupdated' and notification 'kAXTitleChangedNotification'
application_observe: error 'kAXErrorCannotComplete' for application 'softwareupdated' and notification 'kAXMenuOpenedNotification'
application_observe: error 'kAXErrorCannotComplete' for application 'softwareupdated' and notification 'kAXMenuClosedNotification'
window_manager_create_and_add_window:213 iTerm2 - Hotkey Window
window_manager_create_and_add_window:444 iTerm2 - kiryph@ichi20: ~
window_manager_create_and_add_window:587 iTerm2 - kiryph@ichi20: ~ 🔔
EVENT_HANDLER_DAEMON_MESSAGE: signal --add event=dock_did_restart action=sudo yabai --load-sa
EVENT_HANDLER_DAEMON_MESSAGE: space 2 --label s2
EVENT_HANDLER_DAEMON_MESSAGE: space 3 --label s5
EVENT_HANDLER_DAEMON_MESSAGE: space 4 --label s8
EVENT_HANDLER_DAEMON_MESSAGE: space 5 --label s11
EVENT_HANDLER_DAEMON_MESSAGE: space 6 --label s14
EVENT_HANDLER_DAEMON_MESSAGE: space 7 --label s3
EVENT_HANDLER_DAEMON_MESSAGE: space 8 --label s6
EVENT_HANDLER_DAEMON_MESSAGE: space 9 --label s9
EVENT_HANDLER_DAEMON_MESSAGE: space 10 --label s12
EVENT_HANDLER_DAEMON_MESSAGE: space 11 --label s15
EVENT_HANDLER_DAEMON_MESSAGE: space 12 --label s4
EVENT_HANDLER_DAEMON_MESSAGE: space 13 --label s7
EVENT_HANDLER_DAEMON_MESSAGE: space 14 --label s10
EVENT_HANDLER_DAEMON_MESSAGE: space 15 --label s13
EVENT_HANDLER_DAEMON_MESSAGE: space 16 --label s16
EVENT_HANDLER_DAEMON_MESSAGE: space --focus 2
cannot focus an already focused space.

EVENT_HANDLER_WINDOW_FOCUSED: iTerm2 587
EVENT_HANDLER_WINDOW_TITLE_CHANGED: iTerm2 587
EVENT_HANDLER_WINDOW_DESTROYED: iTerm2 213
EVENT_HANDLER_MOUSE_DOWN: 444 -286.14, 293.62
EVENT_HANDLER_WINDOW_FOCUSED: iTerm2 444
EVENT_HANDLER_DISPLAY_CHANGED: 724064212 20
space_manager_refresh_application_windows: Google Chrome has windows that are not yet resolved
EVENT_HANDLER_MOUSE_UP: -286.14, 293.62
EVENT_HANDLER_DAEMON_MESSAGE: query --windows
EVENT_HANDLER_DAEMON_MESSAGE: window 587 --insert west
window_manager_create_and_add_window:213 iTerm2 - Hotkey Window
EVENT_HANDLER_DISPLAY_CHANGED: 722478165 6
space_manager_refresh_application_windows: Google Chrome has windows that are not yet resolved
EVENT_HANDLER_WINDOW_FOCUSED: iTerm2 213
EVENT_HANDLER_WINDOW_FOCUSED: iTerm2 587
EVENT_HANDLER_WINDOW_DESTROYED: iTerm2 213
EVENT_HANDLER_APPLICATION_FRONT_SWITCHED: Google Chrome (2212)
EVENT_HANDLER_APPLICATION_DEACTIVATED: iTerm2
EVENT_HANDLER_APPLICATION_ACTIVATED: Google Chrome
EVENT_HANDLER_APPLICATION_FRONT_SWITCHED: iTerm2 (635)
EVENT_HANDLER_APPLICATION_DEACTIVATED: Google Chrome
EVENT_HANDLER_APPLICATION_ACTIVATED: iTerm2
EVENT_HANDLER_WINDOW_FOCUSED: iTerm2 444
EVENT_HANDLER_DISPLAY_CHANGED: 724064212 20
space_manager_refresh_application_windows: Google Chrome has windows that are not yet resolved
EVENT_HANDLER_DAEMON_MESSAGE: window 444 --warp 587
[1]    9240 segmentation fault  yabai --verbose

Can someone else confirm this segmentation fault?
Can I debug with the release version (backtrace) or do I have to compile yabai myself with debug symbols?
The weird thing is when I have two windows open on the originating or target display, the segfault disappears:
❯ yabai -m query --windows | jq -r '.[] | select(."is-visible") | {"id": .id, "app": .app, "display": .display, "stack-index": ."stack-index", "frame": .frame}'
{
  "id": 444,
  "app": "iTerm2",
  "display": 2,
  "stack-index": 0,
  "frame": {
    "x": -1080,
    "y": 0,
    "w": 1080,
    "h": 1920
  }
}
{
  "id": 698,
  "app": "iTerm2",
  "display": 1,
  "stack-index": 0,
  "frame": {
    "x": 1283,
    "y": 0,
    "w": 1277,
    "h": 1440
  }
}
{
  "id": 587,
  "app": "iTerm2",
  "display": 1,
  "stack-index": 0,
  "frame": {
    "x": -0,
    "y": 0,
    "w": 1277,
    "h": 1440
  }
}

Now I can execute the commands.
Do I do something wrong? If so, yabai should still not segfaulting but tell me that my command cannot be executed ideally with a helpful error message.
Update: Crash Report from Console.app
Crash report
-------------------------------------
Translated Report (Full Report Below)
-------------------------------------

Process:               yabai [4174]
Path:                  /usr/local/opt/yabai/bin/yabai
Identifier:            yabai
Version:               ???
Code Type:             X86-64 (Native)
Parent Process:        launchd [1]
User ID:               501

Date/Time:             2022-12-26 10:27:30.3800 +0100
OS Version:            macOS 12.6.1 (21G217)
Report Version:        12
Bridge OS Version:     7.0 (20P411)
Anonymous UUID:        0D681FE9-1C76-C6B6-014C-5A03857C3DA8

Time Awake Since Boot: 670 seconds

System Integrity Protection: disabled

Crashed Thread:        1

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000138
Exception Codes:       0x0000000000000001, 0x0000000000000138
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    Namespace SIGNAL, Code 11 Segmentation fault: 11
Terminating Process:   exc handler [4174]

VM Region Info: 0x138 is not in any region.  Bytes before following region:<PHONE_NUMBER>75656
      REGION TYPE                    START - END         [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      UNUSED SPACE AT START
--->
      VM_ALLOCATE              7fffffe66000-7fffffe67000 [    4K] r-x/r-x SM=ALI

Thread 0::  Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	    0x7ff81f72897a mach_msg_trap + 10
1   libsystem_kernel.dylib        	    0x7ff81f728ce8 mach_msg + 56
2   CoreFoundation                	    0x7ff81f82c36d __CFRunLoopServiceMachPort + 319
3   CoreFoundation                	    0x7ff81f82a9f8 __CFRunLoopRun + 1276
4   CoreFoundation                	    0x7ff81f829e3c CFRunLoopRunSpecific + 562
5   yabai                         	       0x10419b634 main + 1972
6   dyld                          	       0x10787552e start + 462

Thread 1 Crashed:
0   yabai                         	       0x1041970ee window_manager_warp_window + 1182
1   yabai                         	       0x104179a07 handle_message + 11639
2   yabai                         	       0x1041a267f EVENT_HANDLER_DAEMON_MESSAGE + 319
3   yabai                         	       0x10417378e event_loop_run + 158
4   libsystem_pthread.dylib       	    0x7ff81f7654e1 _pthread_start + 125
5   libsystem_pthread.dylib       	    0x7ff81f760f6b thread_start + 15

Thread 2:
0   libsystem_kernel.dylib        	    0x7ff81f72f092 __accept + 10
1   yabai                         	       0x104181d7c message_loop_run + 60
2   libsystem_pthread.dylib       	    0x7ff81f7654e1 _pthread_start + 125
3   libsystem_pthread.dylib       	    0x7ff81f760f6b thread_start + 15

Thread 3:
0   libsystem_pthread.dylib       	    0x7ff81f760f48 start_wqthread + 0

Thread 4:
0   libsystem_pthread.dylib       	    0x7ff81f760f48 start_wqthread + 0

Thread 5:
0   libsystem_pthread.dylib       	    0x7ff81f760f48 start_wqthread + 0

Thread 1 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000000  rbx: 0x00006000034d6000  rcx: 0x0000000000000001  rdx: 0x000000000000011b
  rdi: 0x0000000000000001  rsi: 0x0000000000000000  rbp: 0x0000700005652b60  rsp: 0x0000700005652900
   r8: 0x00006000016f4380   r9: 0x0000000000000010  r10: 0x00000000000007fb  r11: 0x00000000000003ff
  r12: 0x00007fd5fba1c390  r13: 0x00006000016f4370  r14: 0x00007fd5fba0af20  r15: 0x000000010422f210
  rip: 0x00000001041970ee  rfl: 0x0000000000010246  cr2: 0x0000000000000138

Logical CPU:     2
Error Code:      0x00000006 (no mapping for user data write)
Trap Number:     14

Thread 1 instruction stream:
  bf 00 00 00 41 8b 8e 38-01 00 00 85 c9 75 1e 8b  ....A..8.....u..
  0d c5 81 09 00 83 f9 03-75 13 f3 41 0f 10 46 08  ........u..A..F.
  41 0f 2e 46 0c b9 02 00-00 00 83 d1 ff 48 8b 95  A..F.........H..
  c0 fd ff ff 80 7a 3b 00-0f 84 bd 02 00 00 f3 44  .....z;........D
  0f 2a 4a 30 f3 44 0f 59-0d 05 f6 00 00 e9 ad 02  .*J0.D.Y........
  00 00 4c 89 85 b0 fd ff-ff 41 8b 8e 38 01 00 00  ..L......

Binary Images:
    0x7ff81f727000 -     0x7ff81f75efff libsystem_kernel.dylib (*) <0ea0d8ac-c27b-3a71-a59b-ec3a6f116acf> /usr/lib/system/libsystem_kernel.dylib
    0x7ff81f7ac000 -     0x7ff81fcaefff com.apple.CoreFoundation (6.9) <93c48919-68af-367e-9a67-db4159bc962c> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
       0x10416c000 -        0x1041abfff yabai (*) <5a5f8f1c-f0a8-3c19-b925-3c74e4065154> /usr/local/Cellar/yabai/5.0.2/bin/yabai
       0x107870000 -        0x1078dbfff dyld (*) <7b87a986-a153-33c4-8470-d56410b7f9d5> /usr/lib/dyld
    0x7ff81f75f000 -     0x7ff81f76afff libsystem_pthread.dylib (*) <b5454e27-e8c7-3fdb-b77f-714f1e82e70b> /usr/lib/system/libsystem_pthread.dylib
               0x0 - 0xffffffffffffffff ??? (*) <00000000-0000-0000-0000-000000000000> ???

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 8
    thread_create: 8
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=846.6M resident=0K(0%) swapped_out_or_unallocated=846.6M(100%)
Writable regions: Total=930.8M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=930.8M(100%)

                                VIRTUAL   REGION
REGION TYPE                        SIZE    COUNT (non-coalesced)
===========                     =======  =======
Activity Tracing                   256K        1
CG backing stores                 56.2M        1
ColorSync                          204K       23
CoreGraphics                         8K        1
Kernel Alloc Once                    8K        1
MALLOC                           235.2M       32
MALLOC guard page                   24K        5
MALLOC_MEDIUM (reserved)         240.0M        2         reserved VM address space (unallocated)
MALLOC_NANO (reserved)           384.0M        1         reserved VM address space (unallocated)
ObjC additional data                15K        1
STACK GUARD                       56.0M        6
Stack                             10.5M        6
VM_ALLOCATE                       4648K       12
VM_ALLOCATE (reserved)             128K        1         reserved VM address space (unallocated)
__CTF                               756        1
__DATA                            17.4M      282
__DATA_CONST                      12.0M      168
__DATA_DIRTY                       534K       97
__FONT_DATA                          4K        1
__LINKEDIT                       645.4M        8
__TEXT                           201.2M      303
__UNICODE                          592K        1
dyld private memory               1024K        1
mapped file                       54.1M        9
shared memory                      768K       14
===========                     =======  =======
TOTAL                              1.9G      978
TOTAL, minus reserved VM space     1.3G      978

-----------
Full Report
-----------

{"app_name":"yabai","timestamp":"2022-12-26 10:27:30.00 +0100","app_version":"","slice_uuid":"5a5f8f1c-f0a8-3c19-b925-3c74e4065154","build_version":"","platform":1,"share_with_app_devs":0,"is_first_party":1,"bug_type":"309","os_version":"macOS 12.6.1 (21G217)","incident_id":"5CF7CA2D-8C14-4CD1-9D45-52F03BA9AE6B","name":"yabai"}
{
  "uptime" : 670,
  "procLaunch" : "2022-12-26 10:26:27.2386 +0100",
  "procRole" : "Unspecified",
  "version" : 2,
  "userID" : 501,
  "deployVersion" : 210,
  "modelCode" : "Macmini8,1",
  "procStartAbsTime" :<PHONE_NUMBER>73,
  "coalitionID" : 674,
  "osVersion" : {
    "train" : "macOS 12.6.1",
    "build" : "21G217",
    "releaseType" : "User"
  },
  "captureTime" : "2022-12-26 10:27:30.3800 +0100",
  "incident" : "5CF7CA2D-8C14-4CD1-9D45-52F03BA9AE6B",
  "bug_type" : "309",
  "pid" : 4174,
  "procExitAbsTime" :<PHONE_NUMBER>93,
  "cpuType" : "X86-64",
  "procName" : "yabai",
  "procPath" : "\/usr\/local\/opt\/yabai\/bin\/yabai",
  "parentProc" : "launchd",
  "parentPid" : 1,
  "coalitionName" : "homebrew.mxcl.yabai",
  "crashReporterKey" : "0D681FE9-1C76-C6B6-014C-5A03857C3DA8",
  "bridgeVersion" : {"build":"20P411","train":"7.0"},
  "sip" : "disabled",
  "vmRegionInfo" : "0x138 is not in any region.  Bytes before following region:<PHONE_NUMBER>75656\n      REGION TYPE                    START - END         [ VSIZE] PRT\/MAX SHRMOD  REGION DETAIL\n      UNUSED SPACE AT START\n--->  \n      VM_ALLOCATE              7fffffe66000-7fffffe67000 [    4K] r-x\/r-x SM=ALI  ",
  "isCorpse" : 1,
  "exception" : {"codes":"0x0000000000000001, 0x0000000000000138","rawCodes":[1,312],"type":"EXC_BAD_ACCESS","signal":"SIGSEGV","subtype":"KERN_INVALID_ADDRESS at 0x0000000000000138"},
  "termination" : {"flags":0,"code":11,"namespace":"SIGNAL","indicator":"Segmentation fault: 11","byProc":"exc handler","byPid":4174},
  "vmregioninfo" : "0x138 is not in any region.  Bytes before following region:<PHONE_NUMBER>75656\n      REGION TYPE                    START - END         [ VSIZE] PRT\/MAX SHRMOD  REGION DETAIL\n      UNUSED SPACE AT START\n--->  \n      VM_ALLOCATE              7fffffe66000-7fffffe67000 [    4K] r-x\/r-x SM=ALI  ",
  "extMods" : {"caller":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"system":{"thread_create":8,"thread_set_state":0,"task_for_pid":8},"targeted":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"warnings":0},
  "faultingThread" : 1,
  "threads" : [{"id":24686,"queue":"com.apple.main-thread","frames":[{"imageOffset":6522,"symbol":"mach_msg_trap","symbolLocation":10,"imageIndex":0},{"imageOffset":7400,"symbol":"mach_msg","symbolLocation":56,"imageIndex":0},{"imageOffset":525165,"symbol":"__CFRunLoopServiceMachPort","symbolLocation":319,"imageIndex":1},{"imageOffset":518648,"symbol":"__CFRunLoopRun","symbolLocation":1276,"imageIndex":1},{"imageOffset":515644,"symbol":"CFRunLoopRunSpecific","symbolLocation":562,"imageIndex":1},{"imageOffset":194100,"symbol":"main","symbolLocation":1972,"imageIndex":2},{"imageOffset":21806,"symbol":"start","symbolLocation":462,"imageIndex":3}]},{"triggered":true,"id":24715,"instructionState":{"instructionStream":{"bytes":[191,0,0,0,65,139,142,56,1,0,0,133,201,117,30,139,13,197,129,9,0,131,249,3,117,19,243,65,15,16,70,8,65,15,46,70,12,185,2,0,0,0,131,209,255,72,139,149,192,253,255,255,128,122,59,0,15,132,189,2,0,0,243,68,15,42,74,48,243,68,15,89,13,5,246,0,0,233,173,2,0,0,76,137,133,176,253,255,255,65,139,142,56,1,0,0,137,136,56,1,0,0,65,139,142,60,1,0,0,137,136,60,1,0,0,72,139,189,200,253,255,255,76,137,238,232,176,211,254,255,65,139,69,16,137,133,208,254,255,255,76,139,165,168,253,255,255,77,139,116,36,120,72,141,189,208,254,255,255,65,255,84,36,104,73,99,76,36,92,72,137,194,72,9,202,72,193,234,32,15,132,244,1,0,0,49,210,72,247,241,233,238],"offset":96}},"threadState":{"r13":{"value":105553140335472},"rax":{"value":0},"rflags":{"value":66118},"cpu":{"value":2},"r14":{"value":140557026373408},"rsi":{"value":0},"r8":{"value":105553140335488},"cr2":{"value":312},"rdx":{"value":283},"r10":{"value":2043},"r9":{"value":16},"r15":{"value":4364366352,"symbolLocation":0,"symbol":"g_space_manager"},"rbx":{"value":105553171668992},"trap":{"value":14,"description":"(no mapping for user data write)"},"err":{"value":6},"r11":{"value":1023},"rip":{"value":4363743470,"matchesCrashFrame":1},"rbp":{"value":123145392827232},"rsp":{"value":123145392826624},"r12":{"value":140557026444176},"rcx":{"value":1},"flavor":"x86_THREAD_STATE","rdi":{"value":1}},"frames":[{"imageOffset":176366,"symbol":"window_manager_warp_window","symbolLocation":1182,"imageIndex":2},{"imageOffset":55815,"symbol":"handle_message","symbolLocation":11639,"imageIndex":2},{"imageOffset":222847,"symbol":"EVENT_HANDLER_DAEMON_MESSAGE","symbolLocation":319,"imageIndex":2},{"imageOffset":30606,"symbol":"event_loop_run","symbolLocation":158,"imageIndex":2},{"imageOffset":25825,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":4},{"imageOffset":8043,"symbol":"thread_start","symbolLocation":15,"imageIndex":4}]},{"id":24721,"frames":[{"imageOffset":32914,"symbol":"__accept","symbolLocation":10,"imageIndex":0},{"imageOffset":89468,"symbol":"message_loop_run","symbolLocation":60,"imageIndex":2},{"imageOffset":25825,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":4},{"imageOffset":8043,"symbol":"thread_start","symbolLocation":15,"imageIndex":4}]},{"id":25268,"frames":[{"imageOffset":8008,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":4}]},{"id":25627,"frames":[{"imageOffset":8008,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":4}]},{"id":26310,"frames":[{"imageOffset":8008,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":4}]}],
  "usedImages" : [
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" :<PHONE_NUMBER>10432,
    "size" : 229376,
    "uuid" : "0ea0d8ac-c27b-3a71-a59b-ec3a6f116acf",
    "path" : "\/usr\/lib\/system\/libsystem_kernel.dylib",
    "name" : "libsystem_kernel.dylib"
  },
  {
    "source" : "P",
    "arch" : "x86_64h",
    "base" :<PHONE_NUMBER>55200,
    "CFBundleShortVersionString" : "6.9",
    "CFBundleIdentifier" : "com.apple.CoreFoundation",
    "size" : 5255168,
    "uuid" : "93c48919-68af-367e-9a67-db4159bc962c",
    "path" : "\/System\/Library\/Frameworks\/CoreFoundation.framework\/Versions\/A\/CoreFoundation",
    "name" : "CoreFoundation",
    "CFBundleVersion" : "1866"
  },
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" :<PHONE_NUMBER>,
    "size" : 262144,
    "uuid" : "5a5f8f1c-f0a8-3c19-b925-3c74e4065154",
    "path" : "\/usr\/local\/Cellar\/yabai\/5.0.2\/bin\/yabai",
    "name" : "yabai"
  },
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" :<PHONE_NUMBER>,
    "size" : 442368,
    "uuid" : "7b87a986-a153-33c4-8470-d56410b7f9d5",
    "path" : "\/usr\/lib\/dyld",
    "name" : "dyld"
  },
  {
    "source" : "P",
    "arch" : "x86_64",
    "base" :<PHONE_NUMBER>39808,
    "size" : 49152,
    "uuid" : "b5454e27-e8c7-3fdb-b77f-714f1e82e70b",
    "path" : "\/usr\/lib\/system\/libsystem_pthread.dylib",
    "name" : "libsystem_pthread.dylib"
  },
  {
    "size" : 0,
    "source" : "A",
    "base" : 0,
    "uuid" : "00000000-0000-0000-0000-000000000000"
  }
],
  "sharedCache" : {
  "base" :<PHONE_NUMBER>83488,
  "size" :<PHONE_NUMBER>8,
  "uuid" : "57de9b7b-39b3-3557-8aed-37ac450fa1f3"
},
  "vmSummary" : "ReadOnly portion of Libraries: Total=846.6M resident=0K(0%) swapped_out_or_unallocated=846.6M(100%)\nWritable regions: Total=930.8M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=930.8M(100%)\n\n                                VIRTUAL   REGION \nREGION TYPE                        SIZE    COUNT (non-coalesced) \n===========                     =======  ======= \nActivity Tracing                   256K        1 \nCG backing stores                 56.2M        1 \nColorSync                          204K       23 \nCoreGraphics                         8K        1 \nKernel Alloc Once                    8K        1 \nMALLOC                           235.2M       32 \nMALLOC guard page                   24K        5 \nMALLOC_MEDIUM (reserved)         240.0M        2         reserved VM address space (unallocated)\nMALLOC_NANO (reserved)           384.0M        1         reserved VM address space (unallocated)\nObjC additional data                15K        1 \nSTACK GUARD                       56.0M        6 \nStack                             10.5M        6 \nVM_ALLOCATE                       4648K       12 \nVM_ALLOCATE (reserved)             128K        1         reserved VM address space (unallocated)\n__CTF                               756        1 \n__DATA                            17.4M      282 \n__DATA_CONST                      12.0M      168 \n__DATA_DIRTY                       534K       97 \n__FONT_DATA                          4K        1 \n__LINKEDIT                       645.4M        8 \n__TEXT                           201.2M      303 \n__UNICODE                          592K        1 \ndyld private memory               1024K        1 \nmapped file                       54.1M        9 \nshared memory                      768K       14 \n===========                     =======  ======= \nTOTAL                              1.9G      978 \nTOTAL, minus reserved VM space     1.3G      978 \n",
  "legacyInfo" : {
  "threadTriggered" : {

  }
},
  "trialInfo" : {
  "rollouts" : [
    {
      "rolloutId" : "5fb4245a1bbfe8005e33a1e1",
      "factorPackIds" : {

      },
      "deploymentId" : 240000021
    },
    {
      "rolloutId" : "61301e3a61217b3110231469",
      "factorPackIds" : {
        "SIRI_FIND_MY_CONFIGURATION_FILES" : "6348493aa52bb16adc4e4d06"
      },
      "deploymentId" : 240000023
    }
  ],
  "experiments" : [

  ]
}
}

Attaching LLDB
$ lldb yabai -- --verbose
(lldb) target create "yabai"
Current executable set to 'yabai' (x86_64).
(lldb) settings set -- target.run-args  "--verbose"
(lldb) run

...

Process 15034 stopped
* thread #4, stop reason = EXC_BAD_ACCESS (code=1, address=0x138)
    frame #0: 0x000000010002b0ee yabai`window_manager_warp_window + 1182
yabai`window_manager_warp_window:
->  0x10002b0ee <+1182>: movl   %ecx, 0x138(%rax)
    0x10002b0f4 <+1188>: movl   0x13c(%r14), %ecx
    0x10002b0fb <+1195>: movl   %ecx, 0x13c(%rax)
    0x10002b101 <+1201>: movq   -0x238(%rbp), %rdi
Target 0: (yabai) stopped.
(lldb) bt
* thread #4, stop reason = EXC_BAD_ACCESS (code=1, address=0x138)
  * frame #0: 0x000000010002b0ee yabai`window_manager_warp_window + 1182
    frame #1: 0x000000010000da07 yabai`handle_message + 11639
    frame #2: 0x000000010003667f yabai`EVENT_HANDLER_DAEMON_MESSAGE + 319
    frame #3: 0x000000010000778e yabai`event_loop_run + 158
    frame #4: 0x00007ff81f7654e1 libsystem_pthread.dylib`_pthread_start + 125
    frame #5: 0x00007ff81f760f6b libsystem_pthread.dylib`thread_start + 15

yabai`window_manager_warp_window + 1182

https://github.com/koekeishiya/yabai/blob/8da85c696f24506c6d36a5b5fef9e3f6dada2da8/src/window_manager.c#L1619-L1731

My debugging session has revealed a problem within following code:
https://github.com/koekeishiya/yabai/blob/8da85c696f24506c6d36a5b5fef9e3f6dada2da8/src/window_manager.c#L1638-L1641
When both windows are the only windows on each space, a_node->parent and b_node->parent are both nil. Then accessing b_node->parent->split (line 1641) results in a segmentation fault.
My naive fix is, simply checking for nil of b_node->parent:
❯ git diff
diff --git a/src/window_manager.c b/src/window_manager.c
index e88e313..08bc07a 100644
--- a/src/window_manager.c
+++ b/src/window_manager.c
@@ -1636,7 +1636,7 @@ enum window_op_error window_manager_warp_window(struct space_manager *sm, struct

     if (a_node == b_node) return WINDOW_OP_ERROR_SAME_STACK;

-    if (a_node->parent == b_node->parent && a_node->window_count == 1) {
+    if (b_node->parent && a_node->parent == b_node->parent && a_node->window_count == 1) {
         if (window_node_contains_window(b_node, b_view->insertion_point)) {
             b_node->parent->split = b_node->split;
             b_node->parent->child = b_node->child;


Missing doc files

I'm trying to compile the project but it's missing many docs files

Hi @wonea, removed the files from the project. You should be able to build it now.


Use CSP nonces and SRI

We should start using nonces and SRI (both of which have more widespread implementations now).

Nonces done in b9520658.
@dqwiki - does SRI actually give us any benefits here? All of our assets are served from our application; there's no third-party assets loaded. If a malicious actor can change our assets, they can also change our application to serve different SRI hashes.

Moved to techdebt triage pending discussion on SRI, but with the nonces in place for dynamic scripts, I think we're in a good enough position for now.

Closing - SRI doesn't give us any benefits as we're not using any third-party hosted assets.


Contact page is needed

A contact page is needed for this website (Contact.html)

Can you assign me this issue ?

Completed


No notifications on Windows 10 19H1 with Franz 5.0.1

Describe the bug
There is no notification shown on my Windows 10 19H1 with Franz 5.0.1 installed.
This is a fresh install of Franz.
Other apps like Telegram, Outlook etc. are working fine with notification on same windows installation.
Already checked the settings app (notifications settings are set to sound and banner for Franz).
To Reproduce

Install Franz on Win10
Add Chat Account (e.g. Telegram)
Double Check that notifications for this Account are enabled
Minimize App to tray
Wait for incomming message

Expected behavior
Notification PopUp of Windows 10 should appear with contact/text
Desktop (please complete the following information):

OS: Windows 10 19H1
Franz 5.0.1

I second this. Notifications not working for WhatsApp either and this is on a fresh install of Windows 10 and first time using Franz. All notification settings are enabled. Also checked Android Message and Messenger too and I never got a notification sound or push notification. Franz gets a flag to notify you that you have notifications, but other than that, I get none.