Consider simplifying package usage

Issue:
The current PluginBase class requires overriding the getLints method and returning a Stream<Lint> without providing guidance or structure on how all the custom lints are to be provided. Users of this package must design their own way to go from a ResolvedUnitResult to yielding Lints.
To be more clear, when creating a single custom lint, the current implementation works fine (like your final providers lint in the example folder). The issue happens when trying to define multiple lints. How do we make lints easy to add/remove? How do we avoid getLints from becoming a giant method full of different lints? How do we decouple lints but also let them share an AstVisitor to speed up processing?
Essentially:

Lints aren't easily sharable because everyone will implement them differently
It's hard to get started writing custom lints because you don't just write the lint, you have to connect it with the PluginBase too
Related to point 2, there's more code to test as well, as users (who like to test their code, at least) must test their PluginBase too.

Solution:
Expect users to supply lint rules instead of a PluginBase.
I anticipate showing code will be the best way to explain this.
This code would be added to the custom_lint package (it's just an example, doesn't need to be done this way).
import 'dart:async';

import 'package:analyzer/dart/analysis/results.dart';
import 'package:analyzer/error/error.dart';
import 'package:analyzer/error/listener.dart';
import 'package:analyzer/source/line_info.dart';

//ignore: implementation_imports
import 'package:analyzer/src/lint/linter_visitor.dart';
import 'package:custom_lint_builder/custom_lint_builder.dart';
import 'package:example_lints/src/rules/example_rule.dart';

final List<ExampleLintRule> rules = [
  ExampleRule(),
];

// In this example, I extend PluginBase, but if you use my idea, the PluginBase can be modified
// itself instead.
//
// This class implements AnalysisErrorListener from the analyzer package so that it's onError
// method will be called when each rule reports a lint.
class ExamplePluginBase extends PluginBase implements AnalysisErrorListener {
  late StreamController<Lint> _streamController;

  @override
  Stream<Lint> getLints(ResolvedUnitResult resolvedUnitResult) {
    _streamController = StreamController<Lint>();

    // For the stream to work, it must work specifically in this order:
    // 1. Be created
    // 2. Be listened to (by being returned from this method)
    // 3. Have lints added
    // 4. Be closed
    //
    // If any of these steps are out of order, the stream will not work
    // correctly and lints will never be reported.
    //
    // Thus, the method which does to processing is done in an unawaited future
    // so that step 2 can happen before 3 or 4.
    unawaited(process(resolvedUnitResult));

    return _streamController.stream;
  }

  Future<void> process(ResolvedUnitResult resolvedUnitResult) async {
    // To speed up analysis, a single visitor is created, which will find each
    // AST node and send it to any registration from the registry.
    final registry = NodeLintRegistry(false);
    final visitor = LinterVisitor(registry);

    // When an ExampleLintRule finds a lint error, this reporter will send it
    // to the onError method below.
    final reporter = ErrorReporter(
      this,
      resolvedUnitResult.libraryElement.source,
      isNonNullableByDefault: true,
    );

    for (final rule in rules) {
      rule.reporter = reporter;
      rule.registerNodeVisitors(registry, resolvedUnitResult);
    }

    // Visit the AST tree.
    resolvedUnitResult.unit.visitChildren(visitor);

    // We have to be sure to close the stream, or the stream will be listened to indefinitely!
    _streamController.close();
  }

  // Any time a rule reports an error, we convert it to a Lint and send to the stream.
  @override
  void onError(AnalysisError error) {
    LineInfo lineInfo = LineInfo.fromContent(error.source.contents.data);

    final startLocation = lineInfo.getLocation(error.offset);
    final endLocation = lineInfo.getLocation(error.offset + error.length);

    _streamController.add(Lint(
      code: error.errorCode.name,
      message: error.message,
      location: LintLocation(
        offset: error.offset,
        length: error.length,
        startLine: startLocation.lineNumber,
        startColumn: startLocation.columnNumber,
        endLine: endLocation.lineNumber,
        endColumn: endLocation.columnNumber,
        filePath: error.source.uri.path,
      ),
    ));
  }
}

// Here we make our own version of a LintRule from the analyzer package.
abstract class ExampleLintRule extends LintRule {
  final LintSeverity severity;
  // I'm not sure if we need the group, or if we can just always make it Group.style.
  final Group lintGroup;
  final String message;
  final String code;
  final String? url;

  ExampleLintRule({
    required this.severity,
    required this.lintGroup,
    required this.message,
    required this.code,
    this.url,
  }) : super(
          name: code,
          group: lintGroup,
          description: message,
          details: 'No details',
        );

  // The original `registerNodeProcessors` method of the LintRule class expects to be given
  // a LinterContext, which we can't provide, so we make this method instead.
  void registerNodeVisitors(
      NodeLintRegistry registry, ResolvedUnitResult resolvedUnitResult);
}

Then for a user to define a lint rule, it's just a matter of defining an ExampleLintRule.
Here's the rewritten version of the final provider rule in the example folder.
bool _isProvider(DartType type) {
  final element = type.element! as ClassElement;
  final source = element.librarySource.uri;

  final isProviderBase = source.scheme == 'package' &&
      source.pathSegments.first == 'riverpod' &&
      element.name == 'ProviderBase';

  return isProviderBase || element.allSupertypes.any(_isProvider);
}

class FinalProviders extends ExampleLintRule {
  FinalProviders()
      : super(
          code: 'riverpod_final_provider',
          severity: LintSeverity.warning,
          message: r'Providers should always be declared as final',
        );

  @override
  void registerNodeVisitors(
      NodeLintRegistry registry, ResolvedUnitResult resolvedUnitResult) {
    var visitor = _Visitor(this);
    registry.addVariableDeclaration(this, visitor);
  }
}

class _Visitor extends SimpleAstVisitor<void> {
  final LintRule rule;

  _Visitor(this.rule);

  @override
  void visitVariableDeclaration(VariableDeclaration node) {
    final element = node.declaredElement2;
    if (element != null && !element.isFinal && _isProvider(element.type)) {
      rule.reportLint(node);
    }
  }
}

The benefits of this are:

Rules are sharable as they share a common interface
They are easier to write because instead of using resolvedUnitResult.libraryElement.topLevelElements.where(...).where(...), we visit variable declarations and use an if statement
It reuses existing code from the analyzer package
Relating to point 3, these rules are also written extremely similarly to the rules from the dart linter itself, making them potentially swappable in the future, or at least makes it easier to create a rule based of a dart lint.
It speeds up the processing of lint rules (if you have multiple) because we use a NodeLintRegistry so that PluginBase can create a single AstVisitor instead of each rule visiting the tree itself (they use a Visitor, but, it doesn't actually do any visiting...)

My code is a proof of concept and doesn't have to be the route you go, of course. You may use any, none, or all of it.
Conclusion:
The interaction with the custom_lint package can be greatly simplified by allowing users to define rules instead of a PluginBase.
In fact, with this approach, you could modify the startPlugin method to require a list of rules instead of a PluginBase. The startPlugin method would create the PluginBase itself and give it the rules (if a PluginBase is even required anymore).
final rules = [
  FinalProviders(),
  AnotherExampleLintRule(),
  //ARuleThatIsEasilyTemporarilyDisabledByCommentingItOut(),
  // This could allow for people to share their lints by publishing packages with lint rules! Like:
  ARuleFromSomebodyElsesPackage(),
];

void main(List<String> args, SendPort sendPort) {
  startPlugin(sendPort, rules);
}

Also, this could possibly solve #50, or at least get closer.
Depending on the implementation, this doesn't have to be a breaking change.

Hello!
I'm not against such a project. But it likely shouldn't be within custom_lint instead. It probably would be in a separate package (possibly official).
Doing that involves creating a new framework on top of the current mechanism. That's doable, but not within the scope of the current project.
For now, I'd like to focus on nailing the user experience/performance. With the current mechanism, you should be able to kind of do whatever you want.

Hi.
That was my guess as to what your answer would be, but if I may add some more arguments to the contrary...
My understanding of the goal of the custom_lint package is to make the developer experience for making lints much easier than using the analyzer_plugin. Indeed, the about section of the readme includes the phrases "a better developer experience", and "a simplified project setup". It's along these same lines that I believe a project like this would be the responsibility of this package, whatever it's form.
I don't think a framework from a separate package would be adopted remotely as much as if it was from this package. Additionally, it's better to change it sooner than later to reduce user migration efforts.
A package with great performance and functionality misses out on potential if it's not easy to use. After all, this is the problem with analyzer_plugin you are solving.
It's up to you. If you are still in favor of working on other things, wouldn't mind at all if you want to close this issue. I wrote this code for my own use and thought it wouldn't hurt to share.

Hence why I mentioned that the side package could be official.
If the side package is presented and used in custom_lint's doc, it'd likely get a decent usage.
I understand your view. I just don't think that the value is high enough to justify doing this over other things (especially when considering I work on many other packages).
I believe the current getLints is already decently simple. I already gave some care about simplifying that API (such as with exposing the Lint class and utils to compote a LintLocation).
We can most likely go further, yes. But there are some much better things to do, like working on an IDE extension to give superpowers to custom_Lint.
That's something I'm working on right now. It enables things like showing "analyzing" in the bottom bar of VScode, or showing prints & exceptions in the "output" tab, or even supporting an "attach to plugin process"  for debugging.

Alright, makes sense; that's some cool stuff! Thanks for the consideration and for making such awesome packages.

For reference, I personally use some utilities that allow a Visitor<T> to return a List<T>/Stream<T>. Is that something you'd be interested in?
For example I typically do:
class RiverpodLint extends PluginBase {
  @override
  Stream<Lint> getLints(ResolvedUnitResult unit) async* {
    final visitor = RiverpodVisitor(unit);
    yield* unit.unit.accept(visitor) ?? const Stream<Lint>.empty();
  }
}

class RiverpodVisitor extends CombiningRecursiveVisitor<Lint> {
  @override
  Iterable<Lint>? visitExpression(Expression node) sync* {
    if (something) {
      yield Lint(...);
    }
  }
}

The benefit of using streams is that this both:

waits for asynchronous logic (such that getLints correctly waits for everything to complete)
handles errors
supports hot-reload

And in the future, custom_lint could support canceling the previous getLints stream if the file is changed while getLints is running (because streams have a built-in cancel mechanism)

I don't disagree with the value of a stream. I'm not suggesting to remove it and my code above still has a stream too.
With your CombiningRecursiveVisitor example, how easy is to have more than one lint rule? How about 10, or 50? Would they share a visitor, in which case there's a lot of code in one place? Would you use multiple visitors, which is unoptimized because each one will visit the entire AST? How easy is it to temporarily remove a lint? With my code I shared, none of this is a problem because the plugin explicitly deals with a list of lint rules.
Would you be able to define your rules codes (riverpod_final_providers), their severity, and their message in one place? What if your rule is interested in multiple node types and thus has several yields associated with it? My code has it declared as the parameters of a class so it is accessible dynamically.
If someone else created a lint, how much effort would it take to add it to your own plugin base? With there being no framework to defining lints with this package, that other person may write it substantially different and it's not compatible with your own implementation.
Sure, a CombiningRecursiveVisitor could be one way of doing this. So is my version. There's lots of ways. When a developer uses your package for the first time, do you really want to make them make this decision for themselves before they can start writing lints? Any code they create they would need to test as well, assuming they follow that standard. My code version allows somebody to start writing lints immediately, and their lint rule logic is the only code to test.
Lastly, at the moment, there aren't very many examples of using your package. The final providers in the example folder was good start for the basics, but doesn't show you how to do anything more than check the features of a top level element. My code uses the exact same classes as Dart's lints (LintRule, NodeLintRegistry, SimpleAstVisitor) and they are written the same way too. This means every single dart lint that developers are familiar with can now be an example of writing your own lint. In fact, you can even copy-paste them into your custom lint plugin, assuming they don't import any dart linter internal code.
Dart lint rules code

I'll look more into how the SDK writes its lint. If I like it, forking their approach could be reasonable.

Honestly, I'm not convinced that the SDK approach is inherently faster. Technically having multiple visitors shouldn't be an issue. The amount of iteration done is the same (since the SDK does a loop on all lints on all methods of the visitor)
But I can see a value elsewhere.
Their approach could allow custom_lint to support enabling/disabling rules in the analysis_options.yaml with ease. That in itself is probably worth it
#50 is an added bonus
I'll see what I can do.

Cool, thanks for looking into it.
Regardless of the implementation of the visitors, each lint rule will indeed run the same amount of code (inspecting an element to see if it breaks the rule). The increase in cost of multiple visitors is in the visiting itself.
Lets say we have 10 lint rules, and our project has a single file with 100 AST nodes within it. If you use a single visitor, and each rule registers its processing with a NodeLintRegistry, then the shared visitor will visit each of the 100 nodes a single time. If each rule creates it's own visitor (which on it's own is accepted), each node will bevisited 10 times, for 1000 visits in total.
It is misleading that each rule (in my example and in the SDK) creates a "_Visitor" class, but this class is never accepted and instead is used merely for the reusability of having a method for each of the ≈200 different node types.

Coming back to this as I'm working on designing the new API right now (to support configuration/disabling rules)
What do you think about an API similar to:
// entrypoint of the plugin

PluginBase createPlugin() => RiverpodAnalysisPlugin();

class RiverpodAnalysisPlugin extends PluginBase {
  List<LintRule> getLintRules() => [
    PreferFinalProvider(),
     ...
  ];

  List<Assist> getAssists() => [
    ConvertToConsumerWidget(),
    ConvertToConsumerStatefulWidget(),
   ...
   ];
}

class PreferFinalProvider extends DartLintRule {
  // Get the lints for a dart file
  Stream<Lint> run(ResolvedUnitResult unit, LintOptions lintOptions) {
    // "run" wouldn't be invoked at all if the lint rule is disabled in the analysis_options.yaml or by ignore_for_file

    // LintOptions would include a JSON map of options resolved from the analysis_options file.

    // TODO return some lints. I have yet to work on potentially changing this part
    // We could fork the ErrorReporter class from the SDK.
    // Same goes for the NodeLintRegistry logic & other visitor utils if we want them.
  }

  <possibly move Lint.getFixes to LintRule.getFixes>
}

class ConvertToConsumerWidget extends Assist {
   Stream<Assist> run(ResolvedUnitResult unit, AssistOptions assistOptions, {required int offset, required int length}) {
     // Same thing but for refactorings
   }
}

This seems like a significant organization improvement, on top of natively supporting disabling rules and #50
Would that satisfy your simplification needs?

About visitors
It's more of a performance issue than a simplification issue (when this issue is about simplicity) but:
We could alternatively have those run methods return a visitor instead of a Stream<Lint>. Although I'm still not convinced that there's a meaningful performance gain by merging visitors. Afaik merging visitors is equivalent of going from:
for (final a in listA) {
  for (final b in listB) {
    a.doSomething(b);
  }
}

to:
for (final b in listB) {
  for (final a in listA) {
    a.doSomething(b);
  }
}

If it was simple to merge the visitors, I'd do it no questions asked.
But it seems to come with a certain complexity because we now need to register every visitX functions we use.
It also makes awaiting any possible asynchronous logic inside the visitor much harder. And the error handling is harder too.
And if someone truly cares about this small performance gain (if it exists), there's an alternate path: not use RecursiveVisitror and only visit the branches that you care about instead of visiting the whole tree.
I originally thought the SDK's NodeLintRegisty did that (as in don't visit some nodes if there's no listener for it), but it doesn't.
Is that fair?

By the way, I want to thank you for the time you spent on this issue.
It's rare that someone spends as much time & effort as you did. So thank you again for that :)

No problem, I'm happy to contribute!
This seems like a great improvement so far, especially since it lets the plugin know what rules there are ahead of time as you've mentioned.

possibly move Lint.getFixes to LintRule.getFixes

A change here makes sense to me; then you don't have to refer to the same getFixes function from every yield.
I really like the way the SDK does this. Their "Fixes" are generic classes that are agnostic to which rule they are used by. Then they provide a map of each rule and the fixes relevant to them. For example, the AddAsych fix can add async from any place in the code, so that multiple lint rules can use it. I see this being complicated for package users though.

I can already see folks overriding visitSomething on their visitor but forget to...

Yep, agree with you there! Perhaps instead of a single run method, you could make a lint rules class that has an overrideable method for each visitSomeElement type. You could then have the run method provided ahead of time and it would register any provided methods. Not sure about the details there, but my point is that "merging visitors" being complicated is not an issue if it's done in a single place in the package.

It also makes awaiting any possible asynchronous logic inside the visitor much harder. And the error handling is harder too.

I can't say I understand the concern here yet.

there's an alternate path: not use RecursiveVisitror and only visit the branches that you care about instead of visiting the whole tree.

Like I had said before, it's rather rare to be able to avoid full recursion. If you have a lint interested in AdjacentStrings, they can be anywhere in the code and so it needs to be recursive. It is like this for pretty much everything but top level elements.
Again, great progress!

Yep, agree with you there! Perhaps instead of a single run method, you could make a lint rules class that has an overrideable method for each visitSomeElement type. You could then have the run method provided ahead of time and it would register any provided methods. Not sure about the details there, but my point is that "merging visitors" being complicated is not an issue if it's done in a single place in the package.

How would this be any different from having the LintRule class be/return an AstVisitor?

My point is that "merging visitors" being complicated is not an issue if it's done in a single place in the package.

My concern is in not increasing the complexity for users, for what I currently believe to be a minor performance improvement (possibly even debatable)

I can't say I understand the concern here yet.

custom_lint needs to know when a plugin has finished emitting lints. That matters for things like the command line

How would this be any different from having the LintRule class be/return an AstVisitor?

I suppose you're right; it's the same is if you extended a visitor.

My concern is in not increasing the complexity for users, for what I currently believe to be a minor performance improvement (possibly even debatable)

Maybe I'll try to come up with a more concrete example showing the improvement. In any case, this is a separate issue for the most part and we can ignore it for now.

custom_lint needs to know when a plugin has finished emitting lints. That matters for things like the command line

I don't understand how this could get broken with different code organization. The plugin is done emitting lints when the Stream is closed. That won't and can't change.

Maybe I'll try to come up with a more concrete example showing the improvement. In any case, this is a separate issue for the most part and we can ignore it for now.

I can try this now...
Firstly, to make sure we're on the same page about what sharing a visitor means...
In either case, we have our predefined lint rule list, which can be any size:
final rules = <LintRule>[
  // lint rule #1
  // lint rule #2
  // ...
];

Sharing a visitor
Sharing a visitor means visitChildren happens once:
// Create a single visitor, which has each rule register in its NodeLintRegistry
final registry = NodeLintRegistry(false);
final visitor = LinterVisitor(registry);
for (final rule in rules) {
  // Registry done here:
  rule.registerNodeVisitors(registry, resolvedUnitResult);
}
// Visit the AST tree. The visitor recurs over every element once. Because it's a [LinterVisitor],
// it calls each registered callback from each rule for each node it finds.
resolvedUnitResult.unit.visitChildren(visitor);

Individual visitors:
Individual visitors means visitChildren happens multiple times:
for (final rule in rules) {
  rule.doYourLintingByYourself(resolvedUnitResult);
}

// With the LintRule class:
void doYourLintingByYourself(ResolvedUnitResult resolvedUnitResult) {
  resolvedUnitResult.unit.visitChildren(someVisitorForThisRule);
}

The first approach adds some overhead from registering callbacks in the registry, and them calling them. The registry works using lists, so callbacks are only attempted to be called if they have been created. This means this overhead has a time complexity of O(2c) where c is the number of registered callbacks. I know, officially, that would be simplified to O(c), but I want to avoid simplifying. This is a very minor overhead.
No matter the approach, the same amount of time will be spent for each rule to do it's computing (whether a node breaks its rules). We will call the number of rules r. We have a time complexity of O(r).
If we share a visitor, the recursive AST visiting will happen once, so each node is visited once. If the number of nodes in the code is n, we have a time complexity of O(n).
If we use different visitors, each will recursively visit the tree on its own. This is a time complexity of O(rn). To clarify, that's r (# of rules) times n (number of nodes), since it looks like the letter m when written together :P
Summary.
c = number of registered "visitSomeElement" callbacks
r = number of lint rules
n = number of AST nodes in the code
Shared visitor: O(n + r + 2c)
Individual visitor: O(rn + r)
"r * n" is significantly expensive, adding much more work per lint rule added.
This is my first time using big O notation outside of college, so it's possible I used it entirely wrong lol.

Thanks again for the time spent on this!
My concern is that the cost of every visitX method on the single AstVisitor is higher because they now have an added for loop. So while we are involving the visitX method fewer times, its execution is slower
But anyway, considering all the time you took to promote this approach, I figured I might as well write a benchmark.

Thanks again for the time spent on this!
My concern is that the cost of every visitX method on the single AstVisitor is higher because they now have an added for loop. So while we are involving the visitX method fewer times, its execution is slower
But anyway, considering all the time you took to promote this approach, I figured I might as well write a benchmark.
Shared visitor benchmark:

```dart
// Import BenchmarkBase class.
import 'package:analyzer/dart/analysis/features.dart';
import 'package:analyzer/dart/analysis/results.dart';
import 'package:analyzer/dart/analysis/utilities.dart';
import 'package:analyzer/dart/ast/ast.dart';
import 'package:analyzer/dart/ast/visitor.dart';
import 'package:analyzer/src/lint/linter_visitor.dart';
import 'package:analyzer/src/lint/linter.dart';
import 'package:benchmark_harness/benchmark_harness.dart';
void main() {
SharedVisitorBenchmark().report();
}
// Create a new benchmark by extending BenchmarkBase
class SharedVisitorBenchmark extends BenchmarkBase {
SharedVisitorBenchmark() : super('Shared visitors');
late ParseStringResult result;
late NodeLintRegistry registry;
// The benchmark code.
@override
void run() {
result.unit.accept(SharedVisitor(registry));
}
// Not measured setup code executed prior to the benchmark runs.
@override
void setup() {
registry = NodeLintRegistry(false);
registry.addMethodDeclaration(
Linter1(
name: 'linter1',
group: Group('name'),
description: '',
details: 'details',
),
Linter1Impl(),
);
registry.addExpressionStatement(
Linter2(
name: 'linter1',
group: Group('name'),
description: '',
details: 'details',
),
Linter2Impl(),
);
result = parseFile(
  path:
      '/Users/remirousselet/dev/invertase/custom_lint/packages/custom_lint/lib/custom_lint.dart',
  featureSet: FeatureSet.latestLanguageVersion(),
);

}
}
class SharedVisitor extends LinterVisitor {
SharedVisitor(super.registry);
}
class Linter1 extends LintRule {
Linter1({
required super.name,
required super.group,
required super.description,
required super.details,
});
}
class Linter1Impl extends SimpleAstVisitor {
@override
void visitMethodDeclaration(MethodDeclaration node) {
doSomething(node);
}
}
class Linter2 extends LintRule {
Linter2({
required super.name,
required super.group,
required super.description,
required super.details,
});
}
class Linter2Impl extends SimpleAstVisitor {
@override
void visitExpressionStatement(ExpressionStatement node) {
doSomething2(node);
super.visitExpressionStatement(node);
}
}
void doSomething(MethodDeclaration node) {}
void doSomething2(ExpressionStatement node) {}
</details>

One visitor per lint benchmark:

<details>
```dart
// Import BenchmarkBase class.
import 'package:analyzer/dart/analysis/features.dart';
import 'package:analyzer/dart/analysis/results.dart';
import 'package:analyzer/dart/analysis/utilities.dart';
import 'package:analyzer/dart/ast/ast.dart';
import 'package:analyzer/dart/ast/visitor.dart';
import 'package:analyzer/src/lint/linter_visitor.dart';
import 'package:benchmark_harness/benchmark_harness.dart';

void main() {
  MultipleVisitorBenchmark().report();
}

// Create a new benchmark by extending BenchmarkBase
class MultipleVisitorBenchmark extends BenchmarkBase {
  MultipleVisitorBenchmark() : super('Multiple visitors');

  late ParseStringResult result;

  // The benchmark code.
  @override
  void run() {
    result.unit.accept(Visitor1());
    result.unit.accept(Visitor2());
  }

  // Not measured setup code executed prior to the benchmark runs.
  @override
  void setup() {
    result = parseFile(
      path:
          '/Users/remirousselet/dev/invertase/custom_lint/packages/custom_lint/lib/custom_lint.dart',
      featureSet: FeatureSet.latestLanguageVersion(),
    );
  }
}

class Visitor1 extends RecursiveAstVisitor<void> {
  @override
  void visitMethodDeclaration(MethodDeclaration node) {
    doSomething(node);
    super.visitMethodDeclaration(node);
  }
}

class Visitor2 extends RecursiveAstVisitor<void> {
  @override
  void visitExpressionStatement(ExpressionStatement node) {
    doSomething2(node);
    super.visitExpressionStatement(node);
  }
}

void doSomething(MethodDeclaration node) {}

void doSomething2(ExpressionStatement node) {}

From my tests, the shared visitor is on average 10% slower than having one visitor per lint as I thought
Of course, I'm not exactly used to writing benchmarks, so I could've missed something. Please review them carefully :)

I ran your tests, and I do see a ≈7 microsecond increase with the shared visitor. I believe this is the O(2c) overhead that I mentioned before.
The problem with your perf test is you only have two rules, which doesn't allow the O(rn) complexity of the multiple visitors to show itself. I ran your same tests, but with more lint rules:

Perf test code
// Import BenchmarkBase class.
import 'package:analyzer/dart/analysis/features.dart';
import 'package:analyzer/dart/analysis/results.dart';
import 'package:analyzer/dart/analysis/utilities.dart';
import 'package:analyzer/dart/ast/ast.dart';
import 'package:analyzer/dart/ast/visitor.dart';
import 'package:analyzer/src/lint/linter.dart';
import 'package:analyzer/src/lint/linter_visitor.dart';
import 'package:benchmark_harness/benchmark_harness.dart';

const ruleCount = 10; // Change to any number

void main() {
  SharedVisitorBenchmark().report();
  MultipleVisitorBenchmark().report();
}

// Create a new benchmark by extending BenchmarkBase
class SharedVisitorBenchmark extends BenchmarkBase {
  SharedVisitorBenchmark() : super('Shared visitors');

  late ParseStringResult result;
  late NodeLintRegistry registry;

  // The benchmark code.
  @override
  void run() {
    result.unit.visitChildren(SharedVisitor(registry));
  }

  // Not measured setup code executed prior to the benchmark runs.
  @override
  void setup() {
    registry = NodeLintRegistry(false);
    for (var i = 0; i < ruleCount; i ++) {
      registry.addMethodDeclaration(
        MyLinter(name: 'linter'),
        LinterImpl(),
      );
    }

    result = parseFile(
      path:
          '/Users/H010675/StudioProjects/personal/projects/framework_example/lib/main.dart',
      featureSet: FeatureSet.latestLanguageVersion(),
    );
  }
}

class SharedVisitor extends LinterVisitor {
  SharedVisitor(super.registry);
}

class MyLinter extends LintRule {
  MyLinter({
    required super.name,
  }) : super(
          group: Group.style,
          description: name,
          details: 'details',
        );
}

class LinterImpl extends SimpleAstVisitor<void> {
  @override
  void visitAdjacentStrings(AdjacentStrings node) {
    doSomething(node);
  }
}

// Create a new benchmark by extending BenchmarkBase
class MultipleVisitorBenchmark extends BenchmarkBase {
  MultipleVisitorBenchmark() : super('Multiple visitors');

  late ParseStringResult result;

  // The benchmark code.
  @override
  void run() {
    for (var i = 0; i < ruleCount; i ++) {
      result.unit.visitChildren(IndividualVisitor());
    }
  }

  // Not measured setup code executed prior to the benchmark runs.
  @override
  void setup() {
    result = parseFile(
      path:
          '/Users/H010675/StudioProjects/personal/projects/framework_example/lib/main.dart',
      featureSet: FeatureSet.latestLanguageVersion(),
    );
  }
}

class IndividualVisitor extends RecursiveAstVisitor<void> {
  @override
  void visitMethodDeclaration(MethodDeclaration node) {
    doSomething(node);
    super.visitMethodDeclaration(node);
  }
}

void doSomething(AstNode node) {}

With 2 rules
Shared visitors(RunTime): 38.91495106311171 us.
Multiple visitors(RunTime): 29.818449089305464 us.
With 10 rules
Shared visitors(RunTime): 37.74900994616297 us.
Multiple visitors(RunTime):<PHONE_NUMBER>4590507 us.
With 100 rules
Shared visitors(RunTime): 61.3511756603272 us.
Multiple visitors(RunTime): 1579.019 us.
As you can see, adding more lint rules significantly increases run time with individual visitors due to the O(rn) complexity. This is why the Dart SDK shares a visitor. It makes it so adding more rules doesn't increasingly pollute the time it takes to compute lints. I'd say a 7 millisecond increase when you have a few lints is worth it running 25 times faster with 100 lints?

I really like the way the SDK does this. Their "Fixes" are generic classes that are agnostic to which rule they are used by. Then they provide a map of each rule and the fixes relevant to them. For example, the AddAsync fix can add async from any place in the code, so that multiple lint rules can use it. I see this being complicated for package users though.

Before I forget, here's the links for what I was talking about when I said this.
Here's all the "context agnostic" code corrections:
https://github.com/dart-lang/sdk/tree/main/pkg/analysis_server/lib/src/services/correction/dart
And here's where the lints are mapped to the corrections they can use:
https://github.com/dart-lang/sdk/blob/main/pkg/analysis_server/lib/src/services/correction/fix_internal.dart
It's a cool pattern worth considering, but could be complicated for package users because then they have to design their corrections to work in any context instead of just for the lint. It would be really awesome, though, if we could reuse these Dart corrections instead of making our own, but they are in src so they might not be not client friendly.

I see, thanks for the counter benchmark.
Stil I don't like the added complexity, and with such an approach, there's no way for custom_lint to await the execution of the lint logic.

If you're referring to knowing when all lints are done, then that is after resolvedUnitResult.unit.visitChildren(visitor); is completed.
If you're referring to knowing when a single lint is done, then that indeed seems impossible since all lints are mixed together into the same visitor. But why would you need to know this?

then that is after resolvedUnitResult.unit.visitChildren(visitor); is completed.

No, because some lints might want to be async.
A lint can have a visitor to be async, and visitChildren wouldn't know about it.

Not a single dart lint is asynchronous. Why would our custom lints need to be? They can do everything synchronously.

I've made several asynchronous lints before. It's not impossible that I missed some util that would've enabled me to make it synchronously instead of async.
But I know the average user will try to make an async lint at some point. And they will probably take a long time to realize that their async logic has broken the custom_lint CLI
Being able to handle asynchronous lints, even if optional, would add some safeguard.

A couple options come to mind.

Make a custom NodeLintRegistry which has callbacks that are FutureOr<void>. I don't think this solution is very ideal though, as that's a lot of code to maintain.
Have asynchronous work be done before AST analysis.
a. The SDK does this by gathering all possible information a lint would need to know into a LintContext model, and then provides this to the lints so that all data is available synchronously. However, with custom lints, this means the plugin could be spending time gathering information that no lints ever use. However, this has the benefit that an asynchronous task will only be done once.
b. As another option, we could have a FutureOr<void> setUp() method in the LintRule class, where any asynchronous work
can be done ahead of time and the results are stored within fields of the LintRule that can then be used within any of the
visit methods. However, this could mean that two lints that need the same asynchronous info compute it twice instead of sharing.

their async logic has broken the custom_lint CLI

If no methods of the LintRule may be a Future, it is impossible for a rule to have anything asynchronous and break it.

Yeah I'm experimenting with those right now. I'll see what I can come-up with.

Do we really need to register an AstVisitor for the shared Visitor btw?
I was thinking that we could do:
register(registry) {
  registry.onVisitVarialeDeclaration((variableDeclaration) {
    reporter.reportError(...);
  });
}

This removes the need for making a separate AstVisitor (which is apparently always a SimpleAstVisitor in the SDK), removing the need for registering each node listener.
In terms of organization, it's a bit worse. But it's probably more intuitive for the average Dart dev. Otherwise, I'm 100% sure many will forget the "register" step. Even I am sure I'll make the mistake at some point.

Yeah, I agree the registering needs to be more intuitive. It's extremely easy to forget to keep it up to date, and then when you miss something, there's no indication that's the problem.
Only way I could think of doing it more automatically is something like this that detects if a visit method has been overridden:

Classes
class LintRuleBase extends LintRule {
  LintRuleBase({
    required super.name,
    required super.group,
    required super.description,
    required super.details,
  });
}

abstract class ExampleLintRule extends SimpleAstVisitor<void> {
  final String message;
  final String code;
  final String? url;

  ExampleLintRule({
    required this.message,
    required this.code,
    this.url,
  });

  late LintRule rule = LintRuleBase(
    description: '',
    details: message,
    group: Group.style,
    name: code,
  );

  void registerNodeVisitors(NodeLintRegistry registry) {
    if (visitClassDeclarations != null) {
      registry.addClassDeclaration(rule, this);
    }
    // About 150 more if statements :(
  }

  Function(ClassDeclaration node)? get visitClassDeclarations => null;
  // 150 more getters :'(

  @override
  void visitClassDeclaration(ClassDeclaration node) {
    visitClassDeclarations?.call(node);
  }
  // 150 more visit methods D:
}

Then a developer uses it like this:

Usage
class FinalProviders extends ExampleLintRule {
  FinalProviders() : super(code: 'some_lint_code', message: 'Fix this');

  @override
  Function(ClassDeclaration node) get visitClassDeclarations => (ClassDeclaration node) {
    print('Hello world');
  };
}

But the syntax of overriding a getter that returns a method is strange.
Your example may just be the way to go, for lack of a better option.

Although, wait, the NodeLintRegistry's addSomethingDeclaration methods expect to be given a LintRule and a Visitor. How will you get those?

I wouldn't use the SDK's NodeLintRegistry.
It's not public anyway.
I'd make a custom implementation with a different prototype.

That could work then

For reference, I ended up with the following.
I've used the shared visitor logic for assists/fixes too.
import 'package:analyzer/error/error.dart';
import 'package:analyzer/error/listener.dart';
import 'package:analyzer/source/source_range.dart';
import 'package:custom_lint_builder/custom_lint_builder.dart';

const _providerBaseChecker =
    TypeChecker.fromName('ProviderBase', packageName: 'riverpod');

PluginBase createPlugin() => _RiverpodLint();

class _RiverpodLint extends PluginBase {
  @override
  List<LintRule> getLintRules(CustomLintConfigs configs) => [
        PreferFinalProviders(),
      ];

  @override
  List<Assist> getAssists() => [_ConvertToStreamProvider()];
}

class PreferFinalProviders extends DartLintRule {
  PreferFinalProviders() : super(code: _code);

  static const _code = LintCode(
    name: 'riverpod_final_provider',
    problemMessage: 'Providers should be declared using the `final` keyword.',
  );

  void run(
    CustomLintResolver resolver,
    ErrorReporter reporter,
    LintContext context,
  ) {
    context.registry.addVariableDeclaration((node) {
      final element = node.declaredElement;
      if (element == null ||
          element.isFinal ||
          !_providerBaseChecker.isAssignableFromType(element.type)) {
        return;
      }

      reporter.reportErrorForElement(PreferFinalProviders._code, element);
    });
  }

  @override
  List<Fix> getFixes() => [_MakeProviderFinalFix()];
}

class _MakeProviderFinalFix extends DartFix {
  @override
  void run(
    CustomLintResolver resolver,
    ChangeReporter reporter,
    LintContext context,
    AnalysisError analysisError,
    List<AnalysisError> others,
  ) {
    final errorRange = SourceRange(analysisError.offset, analysisError.length);

    context.registry.addVariableDeclarationList((node) {
      final nodeRange = SourceRange(node.offset, node.length);
      if (!errorRange.intersects(nodeRange)) return;

      final changeBuilder = reporter.createChangeBuilder(
        priority: 1,
        message: 'Make provider final',
      );
      changeBuilder.addDartFileEdit((builder) {
        final nodeKeyword = node.keyword;
        final nodeType = node.type;
        if (nodeKeyword != null) {
          // var x = ... => final x = ...
          builder.addSimpleReplacement(
            SourceRange(nodeKeyword.offset, nodeKeyword.length),
            'final',
          );
        } else if (nodeType != null) {
          // Type x = ... => final Type x = ...
          builder.addSimpleInsertion(nodeType.offset, 'final ');
        }
      });
    });
  }
}

class _ConvertToStreamProvider extends DartAssist {
  @override
  void run(
    CustomLintResolver resolver,
    ChangeReporter reporter,
    LintContext context,
    SourceRange target,
  ) {
    context.registry.addVariableDeclaration((node) {
      // Check that the visited node is under the cursor
      if (!target.intersects(SourceRange(node.offset, node.length))) {
        return;
      }

      // verify that the visited node is a provider, to only show the assist on providers
      final element = node.declaredElement;
      if (element == null ||
          element.isFinal ||
          !_providerBaseChecker.isAssignableFromType(element.type)) {
        return;
      }

      final changeBuilder = reporter.createChangeBuilder(
        priority: 1,
        message: 'Convert to StreamProvider',
      );
      // TODO implement change
    });
  }
}

Awesome, this is really great!

reporter.reportErrorForElement(PreferFinalProviders._code, element);

Could the reporter be given the code from within the package instead of users passing it on every report? If not, could this at least be this.code instead of PreferFinalProviders._code, since code is a field of super?

// Check that the visited node is under the cursor
if (!target.intersects(SourceRange(node.offset, node.length))) {
return;
}

Can/should this be done from within the package?

custom_lint:
rules:
- riverpod_final_provider: false

I'm assuming all rules will be enabled by default unless disabled, right? Hopefully this would be clear to users that it's the opposite from official dart lints.

Could the reporter be given the code from within the package instead of users passing it on every report? If not, could this at least be this.code instead of PreferFinalProviders._code, since code is a field of super?

The ErrorReporter class is from the SDK. I didn't write this one.
We could have a wrapper around it, but not sure that's truly necessary.
Using the static variable is not necessary. Technically there's a code property on the object. I just used the static one here because of a previous iteration where the visitor and the fix were separate (and therefore you had to pass the code to the visitor).
In this variant, using this.code should be fine

Can/should this be done from within the package?

I thought about it, but I'm skeptical. I figured someone may want to visit things that are outside of the cursor too.
If it's a problem, this can be revised later. But for now, I figured doing this manually was decent enough

I'm assuming all rules will be enabled by default unless disabled, right? Hopefully this would be clear to users that it's the opposite from official dart lints.

All lints are enabled by default, and there's a flag for changing the default. So you can do:
custom_lint:
  enable_all_lint_rules: false
  rules:
  - my_rule

Can/should this be done from within the package?

Continuing on this, one thought I had was to keep doing the if, but simplify the condition a bit by having some extensions on AstNode to obtain a SourceRange
So we could do:

      // Check that the visited node is under the cursor
      if (!target.intersects(node.sourceRange)) {
        return;
      }

The gain is minor though.

I'm also probably going to implement a custom_lint list command, for listing all the lints (for #50)
And I'm considering implementing auto-completion in the analysis_options.yaml, to auto-complete lint names.

I think you could use this:
https://github.com/dart-lang/sdk/blob/main/pkg/analyzer_plugin/lib/utilities/range_factory.dart
It would then be
if (!target.intersects(range.node(node)) {

Fair enough, didn't know it was a thing.

I'll still include an extension to do "node.sourceRange"
It's more intuitive as it shows up in the autocomplete.

Yep sounds good

It's all working on #63
I  was playing around with analyzing the non-dart file (which now works fine). I thought I'd find a similar visitor pattern in the SDK for Yaml/Pubspec/AnalysisOptions visitors, but apparently not.
I guess I'll add a "PubspecLintRule" & co at a later date.

Thanks a lot for doing this!

Thanks for your involvement in this issue too :)


Send an automated email when Mentor has been with CDC for one year

A nice way to say thank you and keep the mentor engaged.

This issue was moved to CoderDojoChi/c2#70


enable React Hot Loader

Super useful add on for development. Though it seems like it will soon be phased out in favor of React Transform

@sconnelley already added a hook for gulp-connect's LiveReload feature.
Just run your npm script with --reload.
Err, but looks like this reloads individual components, instead of the whole site? If i'm understanding correctly...fancy.
(TBH tho...I've never been a fan of hot/live reloading. I like my app to stay in the state I left it until I tell it to reload, with cmd+r. I seem to be the only one tho.)

Component reloading is mind blowing (when it works).

@ericsoco you often still have to refresh the page, like for example if you updated a reducer. Hot Reload can be nice when making minor changes to components.

I'm not arguing strongly against it. But. It really annoys me when I have my application in a particular state, I'm inspecting the DOM, whatever, and all of a sudden a hot loader pulls the rug (DOM) out from under me...

Yeah I can definitely see that being irritating.


Add note about unloading Native AOT DLLs

Summary
Note that unloading Native AOT libraries is not supported.
Fixes https://github.com/dotnet/runtime/issues/103028

Should we add the same note to the general .NET hosting topic (https://learn.microsoft.com/en-us/dotnet/core/tutorials/netcore-hosting)?

The sample has a link to old CoreRT that suggests that unloading works: https://github.com/dotnet/samples/blob/main/core/nativeaot/NativeLibrary/LoadLibrary.c#L71-L72 . We should fix that as well.

We should also make this PR against the dotnet/docs repo :)

We should also make this PR against the dotnet/docs repo :)

Oops!


Proposal: Add Emojis to the CEPS

Since each CEP is a single file, could use a emoji to signify its status? You can add these to the front of the commit message/PR. This would allow us to quickly see at a glance what the status of things are. I tried an example in the CEP-4 branch
🔨  for Draft
🛠 Proposed
✔ Accepted
➖ Rejected
✅ Implemented
⚡  Deferred (Not sure on this one)
@jezdez what do you think?

Hmm, I'd be worried about emoji in commit messages personally since it makes the commit log messy in the git log output and GitHub history view. Since commit messages are forever I'd keep it simple with those for now. There is also a bit of an issue for people that don't have a font with Emoji support installed for their command line (e.g. older Windows).
Alternatively, would having a listing of the current CEPs in the README with emojis help with the overview problem? E.g. a simple Markdown table like this:

Title
Status

CEP 0
CEP template
✔

CEP 1
CEP Purpose and Guidelines
💬

CEP 2
Add plugin architecture to Conda
✔

CEP 3
Using the Mamba solver in Conda
🚧

BTW, here'd be my proposal for the set of emojis:
🚧 for Draft
💬 Proposed
✔ Accepted
➖ Rejected
🎉 Implemented
🔙 Deferred (Not sure on this one)

Good points. Yeah maybe having it in the readme would work. I think it would be just very easy to then see which ones someone could maybe look at if they are wanting to, and its part of the flow. We could use labels too, but I don't think they work as well due to needing to work just with a github function and is outside the actual code/files

I like the idea of this information being in the Readme and kept up to date.
I like the emojis that Jannis proposed - those are all very clear to me.

Self writing READMEs are nice for this. There are some examples in those fancy profile page READMEs. I can work on that if needed.


IsMenuCurrent always returning false for current menu

Attempting to determine if a given navigation item is active, the following block never renders the class attribute:
{{if $currentNode.IsMenuCurrent "main" . }}class="active"{{end}}
It only appears to work for the root (/) endpoint.
v0.18-DEV BuildDate: 2016-10-10T22:08:27-07:00

Please use http://discuss.gohugo.io/ for questions/troubleshooting.


Windows support & Python bindings refactoring

This pull request makes matplotlib, seaborn and sklearn python modules bindings work on Windows. It also refactors the relevant pieces of code, so:

it doesn't leak memory
it doesn't crash Luna when called with "wrong" arguments
Python exceptions are translated to C++ exceptions and C++ exceptions are translated to Luna exceptions — all preserving the original error message from the throw location
it is MUCH shorter and simpler

It also adds unit tests that generate PNG plot and regression functions. Also CircleCI image has been updated so the test can succeed.
Notes:

This PR introduces a new C++ dependency: pybind11 (see updated README). It is a header-only library, so it should install without any hassle.
This PR introduces dependency between the core Dataframes library and Python with Numpy library. It is necessery — otherwise both Plot and Learn libraries (that do not know about each other) try to load their own Python interpreter, breaking each other. This is not a good long-term solution. When more Luna modules will want to use Python we will have to separate its loading into separate module.
huge parts of matplotlib-cpp code have been intentionally left as commented-out. I rewritten only the parts we do use. Other parts are left for future convenience — they can be pretty mechanically refactored, when we want to add a new chart type.

#47 should also be connected to this PR.

Going ahead with merge, to be tested by @sylwiabr


feature(actors): add CreateTimer unit tests

Add actors/timer UT

please @artursouza this PR

/ok-to-test

@1046102779  There are some conflicts now in actors_test.go.


feat(clerk-js): Card animations

Description

Checklist

[ ] npm test runs as expected.
[ ] npm run build runs as expected.
[ ] (If applicable) JSDoc comments have been added or updated for any package exports
[ ] (If applicable) Documentation has been updated

Type of change

[ ] 🐛 Bug fix
[ ] 🌟 New feature
[ ] 🔨 Breaking change
[ ] 📖 Refactoring / dependency upgrade / documentation
[ ] other:

Packages affected

[ ] @clerk/backend
[ ] @clerk/chrome-extension
[ ] @clerk/clerk-js
[ ] @clerk/clerk-expo
[ ] @clerk/fastify
[ ] gatsby-plugin-clerk
[ ] @clerk/localizations
[ ] @clerk/nextjs
[ ] @clerk/clerk-react
[ ] @clerk/remix
[ ] @clerk/clerk-sdk-node
[ ] @clerk/shared
[ ] @clerk/themes
[ ] @clerk/types
[ ] build/tooling/chore

!preview

Hey @desiprisg, your preview is currently deploying and should be available shortly.

Status
Preview
Updated (UTC)

:cook: Deploying...
Inspect
Jan 18, 2024 02:49 PM

@desiprisg did we decide on a way to disable the animations via the appearance prop?

@desiprisg did we decide on a way to disable the animations via the appearance prop?

We're going to need to discuss that a bit more, unless we just add a prop for this specific effect here.


http:curl return headers

Add secondary return value of request headers as table
Please review before merge.

Why strings.Join ? Why do you need the header to end with a comma?

It was the only way I could get it to compile. What would be the correct way to convert the []string so it can be stored in the LTable?

Maybe iterate thru the string slice if the len is greater than 1
So if the len is greater make a new table on that index?


[GDScript] Conflict between Variable Name and Type in Unresolvable Scope

Tested versions
v4.2.1.stable.official [b09f793f5]
v4.2.2.stable.official [15073afe3]
System information
N/A
Issue description
When declaring a variable with the syntax var a: TypeName followed by var TypeName in Godot Engine, an error is raised stating "Local variable 'TypeName' cannot be used as a type." This issue arises due to an unresolvable scope conflict where the engine cannot distinguish between TypeName as both a type and a variable.
Example Code:
func my_func():
	var a: TypeName # error
	var TypeName

Error Message:
Local variable "TypeName" cannot be used as a type.

The engine should either:

Allow the declaration without raising an error, correctly differentiating between the type and the variable name.
Provide a more informative error message that clearly explains the conflict and suggests using a different variable name.

Also,
var Variant
func my_func():
	var a: Variant # no error

func my_func():
	var Variant
	var a: Variant # error

func my_func():
	var a: Variant # error
	var Variant

Steps to reproduce
func my_func():
	var a: Variant # error
	var Variant

Minimal reproduction project (MRP)
N/A

Allow the declaration without raising an error, correctly differentiating between the type and the variable name.

I don't think this is possible, since you can still call static functions that exist on the types (not sure if Godot currently has any?). Also for classes, it wouldn't work due to static functions and methods like .new()

@RedMser
It seems there is a misunderstanding. My argument is not that variables should be used as types. Rather, my point is that there should be no conflict between variable names and type names within the same scope. Therefore, variables declared below should not be referenced above.
To clarify, please see the following example:
const Apple = preload("res://apple.gd")
func my_func() :
	var my_var: Apple
	var Apple = "pineapple"
	print(Apple)

The Apple in var my_var: Apple does not reference a variable. Similarly, the Variant in var my_var: Variant is also not a variable.
It's a discussion about shadowing, an unpreferred coding practice where an identifier is covered.
Please let me know if I am misunderstood.

This issue arises due to an unresolvable scope conflict where the engine cannot distinguish between TypeName as both a type and a variable.

A local constant can be used as a type hint if it contains a preloaded class or enum. So while we don't support types as first-class citizens, types share the same scope as variables, constants, functions, etc. So if you declare a local identifier, then you can no longer use the same name class or global identifier, no matter what it is: a variable, a type, etc.
The only bug here is that a constant declared after use should not obscure the identifier, only produce a warning. We fixed a similar bug in #79880, I'll look at that later for types.
Also note that we recommend using PascalCase only for types and constants that contain a preloaded type. Local variables should use snake_case, so the example would not be possible if you followed the recommended style. Shadowing is also generally seen as a bad practice.


Metronome ticks every 0.5 ticks

Would it be possible to make the metronome tick ever half a tick? I'd see this being useful when 1 tick prayer flicking.

Looks like a difficult one because the current metronome is bound to the tick event. I can't really see a solution that supports arbitrary intervals without using threading but I'm not sure what the team's opinion is on it.
A possible solution is to have a sound thread that plays the metronome at the given interval / frequency and uses the tick event to synchronise the timing of the metronome and the ticks but I'm not sure what the team's opinion on threading is. Doesn't look commonly used...


Microsoft.MixedReality.OpenXR.ARSubsystems.MarkerSubsystem doesn't exist in build on Hololens 2

The provided sample works fine with remoting, but the MarkerSubsystem is null in build.
I'm using Unity 2022.3.17 and latest Visual Studio version. I tried adding MRTK3 packages or only adding the Open XR 1.10 plugin - same result - the subsystem at ARMarkerManager.subsystem is null,.

You need to install the OpenXR 113 preview for this to work.   We are working on releasing 113 to GA in the near future.


__pydantic_extra__ type definition not inherited

Initial Checks

[X] I confirm that I'm using Pydantic V2

Description
When inheriting from a Model, the ConfigDict(extra='allow') is inherited, but the __pydantic_extra__ type declaration isn't.
I would expect this to be inherited as well.
This is the same behaviour as this test: https://github.com/pydantic/pydantic/blob/28ed33f1b70d4b9d626e8c614aed545137c24bc8/tests/test_main.py#L2839-L2868
Example Code
from pydantic import BaseModel, ConfigDict, SecretStr

class Model(BaseModel):
    model_config = ConfigDict(extra='allow')
    __pydantic_extra__: dict[str, SecretStr]

    y: int

class Child(Model):
    pass

m = Model(a='1', y=2)
print(m.__pydantic_extra__)  # {'a': SecretStr('**********')}
c = Child(a='1', y=2)
print(c.__pydantic_extra__)  # {'a': '1'}

Python, Pydantic & OS Version
pydantic version: 2.6.1
        pydantic-core version: 2.16.2
          pydantic-core build: profile=release pgo=true
                 install path: /Users/kasperzutterman/.pyenv/versions/3.12.1/envs/pydantic-3.12/lib/python3.12/site-packages/pydantic
               python version: 3.12.1 (main, Feb  2 2024, 09:13:09) [Clang 15.0.0 (clang-15<IP_ADDRESS>.5)]
                     platform: macOS-14.2.1-arm64-arm-64bit
             related packages: typing_extensions-4.9.0
                       commit: unknown

@KasperZutterman,
Ah yes, you're correct. This is a bug. Would you be interested in submitting a PR with a fix? I'd be happy to review :)

Hi @sydney-runkle,
I'm unfortunately not acquainted with the Pydantic codebase. Could you point me in the right direction for the fix?

@KasperZutterman,
No worries. Good news! This was actually fixed in https://github.com/pydantic/pydantic/commit/8b90de86033fbdfea01f775e25ece8222e6a4d8f, so I'm going to mark this as resolved. This fix will be released with 2.7!

Marking this as resolved :)


Newsletter Content Ideas: Drop Date 08/24/2016

Jupyter in Education interview with Lorena Barba, Daniel Soto, and Eric Ma.
Altair?
JupyterCon
PyData SF
JupyterDay Atlanta
Jupyter Mini-workshop recap
@Carreau @ellisonbg @willingc @fperez @Ruv7

Also Jupyter in Education interview of Demba Ba of Harvard
Perhaps a short mention of batchspawner being added to jupyterhub projects. Could go under JupyterHub workshop recap.
All looks good.

@willingc Could you connect me to him via email?

Moving this discussion to a new issue after a revision on the timeline and content development process for this next iteration.


Fix nil-pointer dereference on windows context

Issue: https://github.com/rancher/rancher/issues/37628
Passing certContext to the deferred function ensures that the value will
be taken at that point. The issue is that it is nil when the deferred
function is called.
This change will capture the variable so its real value is passed

Were you able to validate this fixes the issue? You would need to pin this SA commit in a fork of wins and then compile wins and push the binary to a windows test machine.

tested and the node came up


Automated cherry pick of #10265

Cherry pick of #10265 on release-6.7.
/cc  @mickmister
NONE

Will try to auto merge this PR once all tests and checks are passing. This might take up to an hour.

@amyblais Does this also need to be cherry-picked into cloud? Also, is there a way for me to determine this on my own?

@mickmister The next Cloud release is on May 11, but QA is already wrapping up release testing, so it's fine if this is not cherry-picked to that release.
This fix will go organically to May 25th cloud release and from there to v7.0 release https://community-daily.mattermost.com/core/pl/ux34sqpettbzfmt6jbpqn8cehy.


Remove support for metadata.name

Proposed changes

Remove support for metadata.name. Job name == suite name.

I would have commented against this, actually. Having the option of "Job names" is practical since a suite name could be a different indicator.
And I'm not sure if I can have spaces in a suite name?

And I'm not sure if I can have spaces in a suite name?

You can :)
Prior to this change, the job name was {metadata.name} - {suite.name}, which wasn't even documented ☹ . After this change, the job name will be exactly that of {suite.name}.


Context-aware auto-completion

The VSC extension should enable context-aware auto-completion. This includes:

Suggest semantically correct attributes / types (i.e. don't display attributes that would be invalid in this context)
The auto-completion should also show inline docs (similar to JSDoc for Prisma Client JS)

Combined with https://github.com/prisma/vscode/issues/107


Just closes

My MAL Library just closes up on opening it I had a older version installed updated it now it doesn't open anymore, what files do I need to delete to maybe reset cache if u need any more information feel free to write me.
Love ur work.
Kind regards,
Enu

To troubleshoot, right click the application. Open Contents > MacOS  and open MAL Library. Copy the terminal content. Crashlytics should pick up a crash if there is one on my end.

Last login: Tue Aug 15 21:23:29 on ttys000
ENU-MBP:~ enu$ /Applications/MAL\ Library.app/Contents/MacOS/MAL\ Library ; exit;
2017-08-17 15:28:01.987 MAL Library[36968:5306234] [Crashlytics] Version 3.8.4 (121)
2017-08-17 15:28:02.082 MAL Library[36968:5306247] [Crashlytics:Crash:Reports] Packaged report with id '04b2079a53b247af961225362032ed4c' for submission
2017-08-17 15:28:06.087 MAL Library[36968:5306234] -[__NSDictionaryI bytes]: unrecognized selector sent to instance 0x7f9036c3df60
Illegal instruction: 4
logout
Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.
Deleting expired sessions...169 completed.
[Prozess beendet]

Try this build. Crashlytics indicated it's something with the periodic key check. I have the request class to handle the JSON parsing instead of doing it manually.
mallibrary-2.2.dmg.zip

Working perfect now ! Thank you very much !


arch: arm: Initialize floating point registers for every CPU with a FPU

This restores the registers back to reset value, even if CONFIG_FLOAT
is not set.
These registers my be changed earlier for example by a bootloader. This
caused stack offset when booting from a build-in EFM32GG bootloader.
Clearing CPACR unconditionally supports switching between Full access
and Privileged access only.
Initialize the Floating Point Status and Control Register before the
Instruction Synchronization Barrier for symmetry with
arch_switch_to_main_thread.
Should support all combinations of CONFIG_FLOAT and CONFIG_FP_SHARING
Fixes #22977
Signed-off-by: Luuk Bosma<EMAIL_ADDRESS>

I am working out your solution.
But wouldn't it be more logical to keep the initialization in enable_floating_point (with updated comments) and completely remove it from arch_switch_to_main_thread instead?
Your solution splits the initialization over two functions, but for example Initialize the Floating Point Status and Control Register __set_FPSCR was already cleared two times.

Solution 1
https://github.com/zephyrproject-rtos/zephyr/pull/23008/commits/aaf7919fd0dced09618319e229c2ea25ca9d4ed4
Updated comments and removing initialization from arch_switch_to_main_thread to avoid initialization two times.
Solution 2
https://github.com/PierreAronnax/zephyr/commit/59075ee030a94e475a255ef5a1494093ae42c892
Updated according your proposal.
Still not sure about the comments…
Your thoughts?

I am working out your solution.
But wouldn't it be more logical to keep the initialization in enable_floating_point (with updated comments) and completely remove it from arch_switch_to_main_thread instead?
Your solution splits the initialization over two functions, but for example Initialize the Floating Point Status and Control Register __set_FPSCR was already cleared two times.

There is a reason for doing that, pls, check the relevant commit messages :)
We want to clear FPSCR at boot, in case floating point is used during the initialization of zephyr (e.g. drivers). So we need to clear it again before main.

@PierreAronnax I'll review your Solutions, 1, and 2.
You can see how I was thinking of fixing the bug here: https://github.com/zephyrproject-rtos/zephyr/pull/23074

I have verified your PR and it looks good to me.
However, your solution does not disable the CP10 and CP11 Co-Processors when CONFIG_FLOAT=n
Upon boot from bootloader Co-Processor Access Control Register is 0xf00000

I have verified your PR and it looks good to me.
However, your solution does not disable the CP10 and CP11 Co-Processors when CONFIG_FLOAT=n
Upon boot from bootloader Co-Processor Access Control Register is 0xf00000

Agreed. But, if CONFIG_FLOAT=n, the FP extension is not used, anyways.

I have verified your PR and it looks good to me.
Would you like to adopt the solution approach in #23074 in your PR then?

Please take over this PR and use your PR instead.

Please take over this PR and use your PR instead.

Oh I was thinking you'd like to be the author of this bug-fix.

Alright, will do tomorrow.

Alright, will do tomorrow.

OK great @PierreAronnax , we 'll wait for this bug-fix :)
Adding v2.2 milestone, to get this intor v2.2.0 release

I have made the changes, limited line length etc.
I also included your test, was that the intention?

I have made the changes, limited line length etc.
I also included your test, was that the intention?

Yes, it is good to have these checks in regression.
Do you have a platform to run this test and verify it is passing?

Board: efm32gg_stk3701a
CONFIG_FLOAT=y
CONFIG_FP_SHARING=y
*** Booting Zephyr OS build v2.2.0-rc1-262-g0d7e3dcc79ef  ***
Running test suite arm_thread_swap
===================================================================
starting test - test_arm_thread_swap
PASS - test_arm_thread_swap
===================================================================
Test suite arm_thread_swap succeeded
===================================================================
PROJECT EXECUTION SUCCESSFUL


always gets esp32 reboots

hi.
Tried to build this one but i always gets the esp32 rebooting, check voltage, straigt pins, different firmwware version but the results are always the same.
https://github.com/Micha213/BlueRetro-PS1-2-Receiver

What can i do?

Look like power issue like https://github.com/darthcloud/BlueRetro/discussions/170
maybe @Micha213 can help?

Yes, that sounds like a power problem. Did you connect 8v and GND (both) correctly? Can you please take a picture of the installation?

Tried with 8 volts from ps2 and also 8v and 3.3v from a power supply,
always same result.
El lun, 15 ago 2022 17:43, Micha213 @.***> escribió:

Yes, that sounds like a power problem. Did you connect 8v and GND (both)
correctly? Can you please take a picture of the installation?
—
Reply to this email directly, view it on GitHub
https://github.com/darthcloud/BlueRetro/issues/355#issuecomment-1215194601,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AK65N2QJY2TLQ4RXWRCSPP3VZJQQ7ANCNFSM56SKQLSA
.
You are receiving this because you authored the thread.Message ID:
@.***>


How do I set the background color?

I'd like to have my BottomBar use a custom color as the background for tabs, with non-selected tabs using another custom color for text/icon (essentially a darker version of said custom color), and the selected tab using white for text/color. So the same background color at all times, across all tabs. Sounds simple, but how can I accomplish this?
I have so far found useDarkMode which causes the bottom bar to be dark grey with white icons. If not using dark mode, the bottom bar is instead light grey with dark icons.
If setting setMaxFixedTabs(n-1), and NOT mapping any colors to tabs, my bottom bar gets the primaryColor from the theme as the background, with tabs in white/grey. This seems fairly undocumented, and why is there no way of having the BottomBar use R.attr.primaryColor without fixed tabs mode - why just light or dark..?
If I do use mapColorForTab, I can have my custom color as the background, but this only works if setMaxFixedTabs is used, which I don't particularly like due to the offset/resize effects (if having three tabs, I think it looks strange when the middle tab is not center-fixed). Also, I am not sure from where the unselected tabs get their color (it looks like white with 0.5 alpha or something).
Is there some combination of attributes I can use to achieve what I need? Why is there no simple setTabBackground and setInactiveTabColor?
I also noted that if using View.setBackgroundColor on the BottomBar, the background of my activity is instead changed; I guess this is because BottomBar is essentially a full-screen FrameLayout?

I found this ugly workaround for setting the background color:
mBottomBar.findViewById(R.id.bb_bottom_bar_background_view).setBackgroundColor(myColor);
But regarding unselected tab colors for text/icon, it seems mInActiveColor is hard-coded to mInActiveColor = ContextCompat.getColor(getContext(), R.color.bb_inActiveBottomBarItemColor);
I suggest adding setTabBackgroundColor(int) and setInactiveTabColor(int), what do you think?

You can override the styles.xml in your app and give the background colors there.

Can I? AFAIK you are not referencing styleable attributes but hard coded color ids?  Would you mind adding an example to the readme?

Ok so I understand how to change the inactive tab by declaring my own color with the name bb_inActiveBottomBarItemColor. Will this work also on pre-M devices though?
And regarding the background color I still see no way of simply overriding a color. As far as I can see, if NOT using the dark theme and NOT using fixed tabs, no call will be made to set the backgroundColor of mBackgroundView at all. It will get #ffffff hard-coded from the layout. I still see no way of changing it short of manually finding the R.id.bb_bottom_bar_background_view view?

Also wondering about this issue, any news here?

I have the same problem with this!

Ugh. Was it really this bad before?
With the new version, you can just go like android:background like it should've been all along.

Ok guys, i can't setBackground programmatically. I don't know why.
This works :
    <com.roughike.bottombar.BottomBar android:id="@+id/bottomBar"         android:layout_width="match_parent"         android:layout_height="60dp"         android:background="@color/colorAccent"         android:layout_alignParentBottom="true"         app:bb_tabXmlResource="@xml/bottombar_tabs" />
But this not :
BottomBar bottomBar = (BottomBar) findViewById(R.id.bottomBar);   bottomBar.setBackground(ContextCompat.getDrawable(this,R.color.colorAccent));
Can you help me for this ?

Shouldn't you be using getColor() as opposed to getDrawable()?
I'm thinking the system fails to find a drawable with the id of your color, and it ends up as a no-op?
Den 3 nov 2016 6:38 em skrev Etienne Théodore<EMAIL_ADDRESS>Ok guys, i can't setBackground programmatically. I don't know why.
This works :
<com.roughike.bottombar.BottomBar
android:id="@+id/bottomBar"
android:layout_width="match_parent"
android:layout_height="60dp"
android:background="@color/colorAccent"
android:layout_alignParentBottom="true"
app:bb_tabXmlResource="@xml/bottombar_tabs" />
But this not :
BottomBar bottomBar = (BottomBar) findViewById(R.id.bottomBar);
bottomBar.setBackground(ContextCompat.getDrawable(this,R.color.colorAccent));
Can you help me for this ?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/roughike/BottomBar/issues/205#issuecomment-258217376, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJKcQhLoRfWGr3WagEd7e_gRIadi5o58ks5q6hwCgaJpZM4IXJsZ.


More chat options

It would be nice to have toggle options for private/friends-chat/clan-chat/guest-clan-chat TTS messages.  Another idea is to have a TTS option for clan broadcasts and valuable loot messages.

Thanks for the suggestion ive added some of those since you posted this and will probably add more in the future


Cannot run rubywarrior on a fresh ubuntu environment that comes with a default ruby installation

tigerroar@ubuntu:~$ rubywarrior
Welcome to Ruby Warrior
/var/lib/gems/1.9.1/gems/rubywarrior-0.1.3/lib/ruby_warrior/profile.rb:31:in load': incompatible marshal file format (can't be read) (TypeError)         format version 4.8 required; 254.154 given         from /var/lib/gems/1.9.1/gems/rubywarrior-0.1.3/lib/ruby_warrior/profile.rb:31:indecode'
from /var/lib/gems/1.9.1/gems/rubywarrior-0.1.3/lib/ruby_warrior/profile.rb:35:in load'         from /var/lib/gems/1.9.1/gems/rubywarrior-0.1.3/lib/ruby_warrior/game.rb:8:instart'
from /var/lib/gems/1.9.1/gems/rubywarrior-0.1.3/lib/ruby_warrior/runner.rb:17:in run'         from /var/lib/gems/1.9.1/gems/rubywarrior-0.1.3/bin/rubywarrior:5:in<top (required)>'
from /usr/local/bin/rubywarrior:23:in load'         from /usr/local/bin/rubywarrior:23:in'
Newbie here. This is reproducible on a new ubuntu installation env that doesn't have the full ruby package installed yet.
To fix this, do=> "sudo apt-get install ruby-full"

I am having the same problem.... Have you figured out a solution?


cargo package --workspace is not very useful

Tracking
Unstable flag: -Zpackage-workspace
Stabilizing this would also close

#1169

Implementation

[x] #13947
[x] #14433
[ ] #14652

Changes since original plan

Added--registry and --index flags to cargo package to know what registry will be used for generating the Cargo.lock file as if the internal dependencies were already published
cargo publish is not atomic but it does verify all before publish

Open questions

Are we ok with a slight compatibility breakage in cargo package?  See https://github.com/rust-lang/cargo/issues/10948#issuecomment-2253530842
Are we ok stabilizing this and #1169 at the same time?  Currently, they are behind the same flag
What is the desired behavior for the publish timeout?  #14433 uploads the crates in batches (depending on the dependency graph), and we only timeout if nothing in the batch is available within the timeout, deferring the rest to the next wait-for-publish. So for example, if you have packages a, b, c then we'll wait up to 60 seconds and if only a and b were ready in that time, we'll then wait another 60 seconds for c.
What is the desired behavior when publishing some packages in a workspace that have publish = false? #14433 raises an error whenever any of the selected packages has publish = false, so it will error on cargo publish --workspace in a workspace with an unpublishable package. An alternative interface would implicitly exclude unpublishable packages in this case, but still error out if you explicitly select an unpublishable package with -p package-name (see #14356). #14433 behavior is the most conservative one as it can change from an error to implicit excludes later.

Known issues

#14396

Problem
Let's say you have a workspace
workspace/
  package_a/
    Cargo.toml (name="a", version="0.1.0")
  package_b/
    Cargo.toml (name="a", version="0.1.0", [dependencies] a="0.1.0")
  Cargo.toml (members = ["package_a","package_b"])

If you have already published a to crates.io, then cargo package --workspace will complete successfully.
Now, you update a to 0.1.1, and update b to use that new minimum version. If you try cargo package --workspace again, it will no longer work. You will get an error that 0.1.1 was not found.
This happens because cargo package makes a dummy package for your verification and it strips out all workspace and path information. This means it tries to retrieve the a 0.1.1 from the registry, which it fails to do.
Proposed Solution
If you have a workspace where some package b depends on another package a, where a is both specified by a version AND a path, AND that path is within the workspace members, then the following will happen:
cargo package --workspace

will make the new dummy project to verify the crates, but it will leave in the path information for a within b.
Notes
In my experience, I've never had a workspace where all crates are independent. There's always at least one that depends on another crate. When managing private registries, it's not uncommon to cargo package and upload the .crate file manually.
Currently, it's necessary to package each workspace member individually and upload them in the order they depend.
Ideally, we can run a single
cargo package --workspace

after bumping all versions, then get all of the .crate files and upload them in a batch.

This sounds very useful!

I took a look. First time contributor to cargo so just trying to find the relevant parts of the codebase. It looks to me like build_lock() in src/cargo/ops/cargo_package.rs might be where the logic of  @conradludgate described may be:

This happens because cargo package makes a dummy package for your verification and it strips out all workspace and path information. This means it tries to retrieve the a 0.1.1 from the registry, which it fails to do.

So I believe that here we is where we would need to implement @conradludgate 's proposed solution, and to do so in the order the crates depend on another.
This is after a quick look at the code for the very first time ever, so I may be off base. I'm going to keep looking and try to confirm what I think. Also I'm on Zulip if people want to chat/mentor there

One background knowledge: cargo publish is roughly cargo package + call crates.io API. Therefore, some shared code path between cargo publish and cargo package might affect each other. The requirement of a dependency existence on a registry might come from what cargo publish needs: a .crate file is supposed to be distributable.
One thing a bit weird is that packaging a crate with all verifications but not publishing the path dependencies. If cargo permit that, it make me feel like we try to convince cargo that our build is verified but only locally. As aforementioned a .crate file is supposed to be distributable. This rule may not be true anymore if doing so. Maybe we need to think more on whether enabling packaging with unpublished path dependencies is on the right direction, but I'd say the issue you have does exist and people hit it.
At this time being, a good tool for releasing crates is cargo-release, created by sunny87 and epage. I haven't tried it but I believe it works. Perhaps @epage can give you more experiences on this topic :)

BTW, this is somehow related to https://github.com/rust-lang/cargo/issues/9260#issuecomment-1219714903. There are more discussions in the wild regarding a more sequential and smooth packaging/publishing process, though I cannot find them now.

Cargo release is a good tool for workspaces. Unfortunately, we can't use it as-is since we don't have the ability to publish using cargo. However, its something we could fork and fix to work with our own registry

@jneem and I are looking into this. Some of the aspects we are considering are:

It's not so much that cargo package makes a dummy package with paths stripped, but the actual package that will get published has its paths stripped. In order to do verification when some of the (workspace) dependencies are not yet published, we will either have to do verification before we strip the paths, or we will have to create a (dummy) package just for verification, with the paths reinstated.
Whether or not to package one crate at a time (like how it works today), or to first prepare a workspace with all paths intact, and then verify each crate. The latter case would be simpler when there are dependency chains across the workspace.
Can we assume that all intra-workspace dependencies would be for the latest version, i.e. the path dependency? Or do we need to allow that some crates can depend on a specific version of another workspace crate? It would simplify things if cargo package could just throw an error if all workspace dependencies and current crate versions don't match up. In the case where you do want to depend on older versions, maybe you wouldn't try to publish the workspace as a whole anyway, but would rather publish individual crates?

If anybody has opinions on this, feel free to chime in.

@torhovland taking on a task like this, you might want to coordinate more with the Cargo team.  For example, we have Office Hours.
One way this could possibly be split up is

Implement this for --no-verify
Implement verification

It's not so much that cargo package makes a dummy package with paths stripped, but the actual package that will get published has its paths stripped. In order to do verification when some of the (workspace) dependencies are not yet published, we will either have to do verification before we strip the paths, or we will have to create a (dummy) package just for verification, with the paths reinstated.

For verification, we should be verifying the generated .crate, rather than an intermediate to ensure maximum verification.
I wonder if we can inject patches rather than changing anything about the code.  This can all be done in-memory, rather than writing it out to disk.

Whether or not to package one crate at a time (like how it works today), or to first prepare a workspace with all paths intact, and then verify each crate. The latter case would be simpler when there are dependency chains across the workspace.

I have no preference between whether we package+verify one at a time or package all then verify all.  We should likely do separate compilation per verify though.  #5931 would speed up the compile times for this.

Can we assume that all intra-workspace dependencies would be for the latest version, i.e. the path dependency? Or do we need to allow that some crates can depend on a specific version of another workspace crate? It would simplify things if cargo package could just throw an error if all workspace dependencies and current crate versions don't match up. In the case where you do want to depend on older versions, maybe you wouldn't try to publish the workspace as a whole anyway, but would rather publish individual crates?

There are times to depend on old versions of packages.

Dev-dependencies for comparing across versions (usually for major versions)
Semver hack (for major versions)
You can have access to a registry variant of a package through transitive dependencies, either semver compatible or not.

Currently, Cargo does not allow packaging and publishing a crate that depends on another crate unless that dependency is already published. With the change discussed in this issue, it's possible to package both crates and then only publish one of them. Would we need to add safeguards to cargo publish where it confirms that all dependencies exist (basically another round of verification)? If so, we also need to make sure it publishes the crates in the correct order. But this is really a separate concern (https://github.com/rust-lang/cargo/issues/1169#issuecomment-1753461359).

This isn't relevant to this issue but the follow up one.  Let's keep the conversations in each Issue focused and move this over to there.

Thanks for your input, it's been noted.

@torhovland taking on a task like this, you might want to coordinate more with the Cargo team. For example, we have Office Hours.

Sure, we will show up there.
The rough idea we have so far is:

Determine all intra-workspace path dependencies.
Package each crate using the existing code (without trying to compile/build it, or otherwise resolve online dependencies).
Unpack all packaged crates in a temporary directory, giving each one a random dir name.
Go through all workspace dependencies from step 1 and fix them up in each crate. Can we do this in-memory?
See if this builds.

Running into a chicken-and-egg problem with the lock files:
When packaging, Cargo strips away all path dependencies and generates lock files by expecting to find dependent packages online. So that elements like this can be put into the lock file:
[[package]]
name = "my-dep"
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "780f1cebed1629e4753a1a38a3c72d30b97ec044f0aef68cb26650a3c5cf363c"

But when generating a lock file using just a local path dependency, we do not get any source or checksum. While we could add on a source and a checksum after the fact, we can't really assume that the dependency will end up on crates.io. But we also cannot publish a crate that doesn't specify where to find its dependencies.
So it seems that packaging and publishing are strongly coupled, and there's no way around packaging+publishing one crate at a time.
Unless we introduced something like source = same-as-this-one.
Any ideas?

A possible solution is to let cargo package have the same --index option that cargo publish has for indicating which registry to use. So you'll use that to indicate which registry you intend to publish to.

Assuming we could use the --index option suggested above, we still need to figure out how to modify the generated lock files to include a source and a checksum. Ideally, we would like to modify the new_resolve in build_lock() before it gets serialised. But a Resolve seems quite immutable.
We could of course try to modify the lock file after serialisation, but that doesn't seem very nice. The alternative is to modify the resolver code so it can treat a crate as if it was pulled from a registry.

We have two problem steps in cargo package --workspace

Generating the lockfile for each .crate: path dependencies won't be in the registry yet, so this will fail.

Above they talked about forcing path dependencies to be used during the lockfile generation and then patching up the lockfile afterwards with the correct source and checksum
In theory, we could do some kind of decoration of crates.io to allow this in-memory...
Regardless of the method we use to workaround that, to generate the source, it seems like we need to know where the .crate files are intended for so we'd need --index / --registry flags

Verify step for each .crate: the decompressed .crate files will need to depend on each other, rather than their registry, to build

We could do in-memory patches
Maybe there are alternatives that build on what we did for the lockfile?

Re-opening to track stabilization

This seems to be a relatively large feature in terms of lines of code. Should we have an unstable doc section under https://doc.rust-lang.org/nightly/cargo/reference/unstable.html for it?

While implementing support for this in cargo-release, I realized I might need to still publish individual packages myself if

packages have multiple registries to publish to
packages have different platform targets to verify on

For --verify, I'm only doing it if all packages have it enabled (default).
Features are another messy case but no different than the rest of Cargo and I'm foisting that onto my users.

Call for testing
cargo package --workspace is now available and we're looking for feedback to see if this can be stabilized!
Basic steps:
Requirements:

1.85.0-nightly (2024-12-01) or newer

Try cargo package -Zpublic-dependency in your existing workflows and with various combinations of multiple packages being selected (--workspace, --exclude, -p foo -p bar)
Please leave feedback on this issue


Various inconsistencies with physical NTS-1 button/encoder changes vs NTS-Web

MOD, DELAY, & REVERB Type Settings
The linkage between the NTS-1 and NTS-web when changing TYPE for both MOD and DELAY are a bit buggy. For example with MOD, I can't get NTS-Web to show "Chorus", when I go far to the right (Phaser), NTS-web shows "Unknown. I'm not sure if this is related to having custom MODs on the NTS-1 or not (I'm still completely stock at the moment). Same oddities with DELAY & REVERB
OSC TYPE Setting

When you change TYPE to VPM on the NTS-1, the NTS-Web TYPE selector is set to SQUARE (or at least, is not set to VPM)

ARP Chord Scale Settings

When you press ARP+MOD on the NTS-1, the ARP chord type on the NTS-1 is set to Major Aug, but on NTS-web, the "SCALE" selector value is incorrectly set to Major Sus.
When you press ARP+DELAY on the NTS-1, the ARP chord type on the NTS-1 is set to Minor Triad, but on NTS-web, the "SCALE" selector value is incorrectly set to Major Augmented

For reference, changing ARP chord type, per the NTS-1 manual:

ARP + OSC = Octave
ARP + FILTER = Major Triad
ARP + EG = Major Sus
ARP + MOD = Major Aug
ARP + DELAY = Minor Triad
ARP + REVERB = Minor Dim

User OSC and Effects: I'm aware of this and already working on it. If you move the selector one step it should fix itself. I'm using some library for the knobs which is giving me problems. BTW does it still happen if you plug in the NTS-1 before starting the app?
Arp Chord Scale Setting: I don't see any problem here, at first glance seems to work well on my unit.

Could you provide which OS and browser do you use?

BTW does it still happen if you plug in the NTS-1 before starting the app?

I will do some more testing and let you know.

Arp Chord Scale Setting: I don't see any problem here, at first glance seems to work well on my unit.

I'll re-test and see if I can reliable repro it.

Could you provide which OS and browser do you use?

It was Brave Browser running on Win 10. I'll test in Chrome also and see if anything behaves differently.

Closed due to inactivity


⚠ SceneTime has degraded performance

In 7c3b0cf, SceneTime ($ST) experienced degraded performance:

HTTP code: 200
Response time: 10068 ms

Resolved: SceneTime performance has improved in a78e672.


spirv-fuzz: Add OpCompositeInsert instructions to create synonyms.

Similar to the fuzzer pass that adds extracts or vector shuffles, this pass should add OpCompositeInsert instructions to the module.
Each insert yields several synonym facts: every component of the result is synonymous with the components of the original id, except for the inserted component which is synonymous with the given operand.

I can implement this

It would be good to study the fuzzer pass that constructs composites and the fuzzer pass that shuffles vectors before working on this.


fixed typos

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Resolved as part of #135


[release-4.18] OCPBUGS-45119: bump library go

backport of https://github.com/openshift/cluster-openshift-controller-manager-operator/pull/370

/retest-required

@wangke19 hey, can you add cherry-pick-approved label ?

/label cherry-pick-approved

/retest-required


Set local Ruby version

Ran into this yesterday
❯ bundle install
Your Ruby version is 2.4.1, but your Gemfile specified 2.4.0

This fixes that issue by running rbenv local 2.4.0 and setting a local version.

Thanks!!


Improve contrast for selection text in type to filter

Testing #69299:
I quite like how this used to work:

It's also consistent with IntelliSense:

The new type to filter experience has some contrast problem, as the bg color of list item leaks into bg color of selection range because of transparency).

@joaomoreno I don't know if we are committed to this visual representation of filtering, but I'd suggest something like this (full height, offer 2 them-able colors for filtering, filterSelection fg/bg). This would make it much easier to maintain contrast.

@octref This is theme dependent. Type filter even exposes special theme keys for this. Which theme are you using?

I'm using Nord. Which color key are you using for the match box background on the labels? I guess Nord has it set to a color with transparency.

Hmm we're actually reusing findMatchHighlightColor for that.

"editor.findMatchBackground": "#88c0d066" is what Nord is using. This is readable against text editor background, but it's not readable on top of tree focus/select bg.

If a tree item is selected and tree is in focus, I can't see the type-to-filter box at all:

Then we'll just create that theme color.

@joaomoreno Thanks! Make sure you update vscode-docs as well.

Good call! https://github.com/microsoft/vscode-docs/commit/e92eee50b76b3efb8c8b677b821b5ad0d2eed12f


None of the exunit tests run

Noticed it locally at first then confirmed in CI.

[2022-12-17T05:42:33.927Z] warning: :ssl_verify_hostname.verify_fun/3 defined in application
 :ssl_verify_fun is used by the current application but the current application does not depend on
 :ssl_verify_fun. To fix this, you must do one of:
[2022-12-17T05:42:33.927Z]
[2022-12-17T05:42:33.927Z]   1. If :ssl_verify_fun is part of Erlang/Elixir, you must include it
 under :extra_applications inside "def application" in your mix.exs
[2022-12-17T05:42:33.927Z]
[2022-12-17T05:42:33.927Z]   2. If :ssl_verify_fun is a dependency, make sure it is listed under
 "def deps" in your mix.exs
[2022-12-17T05:42:33.927Z]
[2022-12-17T05:42:33.927Z]   3. In case you don't want to add a requirement to :ssl_verify_fun, you may optionally skip this warning by adding [xref: [exclude: [:ssl_verify_hostname]]] to your "def project" in mix.exs
[2022-12-17T05:42:33.927Z]
[2022-12-17T05:42:33.927Z] Invalid call found at 2 locations:
[2022-12-17T05:42:33.927Z]   test/elixir/lib/couch.ex:69: Couch.process_arguments/3
[2022-12-17T05:42:33.927Z]   test/elixir/lib/couch_raw.ex:2: Rawresp.process_arguments/3
[2022-12-17T05:42:33.927Z]
[2022-12-17T05:42:33.927Z] Generated couchdbtest app
[2022-12-17T05:42:33.928Z] There are no tests to run

In the meantime make exunit stage seems happy and green

Tried jumping back to
commit 3c24731a5e49bbb4a1d1f407f11f141ca8698e6c (HEAD)
Date:   Wed Nov 16 22:32:35 2022

Same results (tests ignored) jumping at least a month back, so not related to recent rebar/mix changes.

I guess things are not that dire, as it looks we only have one exunit test suite in dreyfus.
find . -name elixir -type d | grep -v '\./test/elixir'
./src/dreyfus/test/elixir

The tests are:
https://github.com/apache/couchdb/blob/main/src/dreyfus/test/elixir/test/search_test.exs
https://github.com/apache/couchdb/blob/main/src/dreyfus/test/elixir/test/partition_search_test.exs
Should we rewrite them in Erlang as well?

there are a few more, but not a lot:
> find  . -name exunit
./src/couch/test/exunit
> ls src/couch/test/exunit/
couch_compress_tests.exs	same_site_cookie_tests.exs	test_helper.exs

Thanks, @janl. A few more it seems. It might be a small beginner task to switch them to Erlang then we should be able to reduce our makefile and mix.exs size a bit. Also make the test suite run faster a bit.

I am interested in working on this task.  Looks like I cannot assign it to myself though -- could somebody help me with this please?

@pgj thank you for taking a look at it

I think we should move in another direction. Move eunit tests into elixir. My 2 cents.

I think we should move in another direction. Move eunit tests into elixir. My 2 cents.

I think elixir tests were an interesting experiment, but I have found that they add to the friction of developing and maintaining CouchDB.

I think we should move in another direction. Move eunit tests into elixir. My 2 cents.

@iilyak ideally, yes. But in 2-3 years we ended up with only 2 exunit files.  Elixir worked great for integration tests moving from Javascript to Elixir, and we got a lot of help from contributors there, but there just wasn't much interest in translating Erlang eunit tests to Elixir.
In the meantime EUnit tests have improved quite a bit: we have maps, so asserts matching on response shapes is more ergonomic, the TDEF/TDEF_FE macros make test suite nice to look at, we get better coverage reports, which helps immensely identifying areas we completely missed.


SwagCommercial -> EmployeeDetailPageEvent has no Employee.

Used Shopware Version: <IP_ADDRESS>
B2B for Shopware 6
Hi,
I've got Problem with SwagCommercial Plugin, there is not project to select like this.
Problem is in B2B Components (6.5.0 version).
In:
B2B/EmployeeManagement/Storefront/Page/Employee/Detail/EmployeeDetailPageLoader:57
setEmployee is set after event is executed.

[public] Automated response: This issue is linked to the internal issue https://shopware.atlassian.net/browse/B2B-1258.
[created from B2B-1258, comment 485023]


feat: offline server devnet

Summary of changes

Changes introduced in this pull request:

added support for devnets in the offline Forest.

Reference issue to close (if applicable)

Closes https://github.com/ChainSafe/forest/issues/4628
Other information and links

Change checklist

[x] I have performed a self-review of my own code,
[x] I have made corresponding changes to the documentation,
[x] I have added tests that prove my fix is effective or that my feature works (if possible),
[x] I have made sure the CHANGELOG is up-to-date. All user-facing changes should be reflected in this document.

@ruseinov @lemmih