go_router ios and android swipe back gestures are not detected

final goRouterProvider = Provider.autoDispose<GoRouter>((ref) {
  return GoRouter(
      initialLocation: "/auth",
      navigatorKey: _rootNavigator,
      refreshListenable:
          GoRouterRefreshStream(ref.watch(authUserProvider.stream)),
      redirect: (context, state) {
        final user = ref.read(authUserProvider);
        print("state location : ${state.location}");

        return user.when(
            data: ((data) {
              final isVerified = ref.read(authVerificationProvider);

              if (data == null &&
                  state.subloc != "/auth" &&
                  state.subloc != "/auth/signUp") {
                return "/auth";
              }
              if (data != null && state.subloc == "/auth" && isVerified) {
                return "/home";
              }
            }),
            error: ((error, stackTrace) {
              if (state.subloc != "/auth" && state.subloc != "/auth/signUp") {
                return "/auth";
              }
            }),
            loading: (() {}));
      },
      routes: [
        ShellRoute(
            navigatorKey: _shellNavigator,
            pageBuilder: ((context, state, child) {
              return NoTransitionPage(
                  key: state.pageKey,
                  child: SharedScaffold(
                    key: state.pageKey,
                    routerState: state,
                    child: child,
                  ));
            }),
            routes: [
              GoRoute(
                  path: "/home",
                  pageBuilder: (context, state) => MaterialPage(
                      key: state.pageKey,
                      child: HomePage(
                        key: state.pageKey,
                      )),
                  routes: [
                    GoRoute(
                        path: "magazine",
                        pageBuilder: (context, state) {
                          return MaterialPage(
                              key: state.pageKey,
                              child: MagazinePage(
                                key: state.pageKey,
                              ));
                        }),
                    GoRoute(
                        path: "cover",
                        name: "cover",
                        pageBuilder: (context, state) => MaterialPage(
                            key: state.pageKey,
                            child: CoverPage(
                              key: state.pageKey,
                            )),
                        routes: [
                          GoRoute(
                            path: "magazine",
                            pageBuilder: (context, state) => MaterialPage(
                                key: state.pageKey,
                                child: MagazinePage(
                                  key: state.pageKey,
                                )),
                          ),
                        ])
                  ]),
              GoRoute(
                  path: "/auth",
                  pageBuilder: (context, state) => MaterialPage(
                      key: state.pageKey,
                      child: AuthPage(
                        key: state.pageKey,
                      )),
                  routes: [
                    GoRoute(
                        path: "signUp",
                        pageBuilder: (context, state) => MaterialPage(
                            key: state.pageKey,
                            child: SignUpPage(
                              key: state.pageKey,
                            )))
                  ])
            ])
      ]);
});

when i use context.go , they are detected as redirect but when i use android or  ios swipe back gestures, they are not detected as redirect, and router state location is not changing(pages are rendered correctly). Is this not supported yet, or am i doing something wrong?
go_router :6.0.0
flutter: 3.3.10
flutter doctor : clean

Big thanks to team's hardwork(@chunhtai) 👏, i just tried this pr and it is fixing the problem.

Big thanks to team's hardwork(@chunhtai) 👏, i just tried this pr and it is fixing the problem.


Staff can pause pet applications

As staff, I can pause/unpause applications from the pets index screen
Mock:

Hey @nsiwnf, I think this can already be done, the option is just hidden in the dropdown. Do you want to pull this out of the dropdown and put it directly as a column instead?

@Ptrboro Right, I think it would be better to move that out of the menu into a column. Currently the "pause applications" in the menu doesn't include a "pause_reason"

I was debating whether we need a pause reason column any more. I am inclined to get rid of it. It made sense for one org with specific reasons, but now I think for many orgs just a simple pause feature works fine.

Ok great - either way, I think a toggle "pause application" column on the index page would be good, right?

Yes I agree @nsiwnf

Hello, I would like to work on this.
I have a couple questions:

I noticed the button redirects to the pets show page after the status of the application has been clicked. Do you want to maintain that behavior? I was thinking of updating the DOM dynamically for a better user experience.
Is there a way to add custom css if necessary? I noticed in the photo provided, the toggle button has text content rendered from within the switch. I don't know that this is doable by just using bootstrap

@aisayo Great!

I noticed the button redirects to the pets show page after the status of the application has been clicked. Do you want to maintain that behavior? I was thinking of updating the DOM dynamically for a better user experience.

Agreed - we dont need to redirect to the "show" page

Is there a way to add custom css if necessary? I noticed in the photo provided, the toggle button has text content rendered from within the switch. I don't know that this is doable by just using bootstrap

Hm, I think we're trying to avoid custom css - go ahead and leave out the text or make any other changes that are supported by bootstrap/geeksui

@aisayo how's this one going?

Can I be assigned to this?


Release version 0.1.0

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

Project coverage is 100.00%. Comparing base (ea057c2) to head (4ae9471).
Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff            @@
##              main      #187   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           38        38
  Lines          817       817
  Branches        31        31
=========================================
  Hits           817       817

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


Buggy local behavior after postgres segfault

Steps to reproduce
Not an easily reproducible bug, but it often happens when I run tests right after getting a segfault inside postgres. @hlinnaka mentioned seeing similar behavior.
Expected result
Tests run correctly.
Actual result
I get one of two errors, randomly:
E           Exception:             Run ['/home/bojan/src/neondatabase/neon/target/release/neon_local', 'init', '--config=/tmp/tmpbu652z6_', '--pg-version', '14'] failed:
E                         stdout: Starting pageserver at 'localhost:15004' in '/home/bojan/src/neondatabase/neon/test_output/test_pgbench_init[neon-45-10]/repo'
E
E           Pageserver started
E           Stopping pageserver gracefully...done!
E
E                         stderr: Failed to create initial tenant and timeline for pageserver: Error: Error: No such file or directory (os error 2)
E           pageserver init failed: Failed to create initial tenant and timeline for pageserver

test_runner/fixtures/neon_fixtures.py:1247: Exception

or
E           Exception:             Run ['/home/bojan/src/neondatabase/neon/target/release/neon_local', 'init', '--config=/tmp/tmpamico7us', '--pg-version',
'14'] failed:
E                         stdout: Starting pageserver at 'localhost:15004' in '/home/bojan/src/neondatabase/neon/test_output/test_pgbench_init[neon-45-10]/r
epo'
E
E           Pageserver started
E           Stopping pageserver gracefully...done!
E
E                         stderr: Failed to create initial tenant and timeline for pageserver: Failed to create timeline: Error: Response error: initdb fail
ed: 'could not identify current directory: No such file or directory
E           could not identify current directory: No such file or directory
E           could not identify current directory: No such file or directory
E           initdb: error: The program "postgres" is needed by initdb but was not found in the
E           same directory as "initdb".
E           Check your installation.
E           '
E           pageserver init failed: Failed to create initial tenant and timeline for pageserver

test_runner/fixtures/neon_fixtures.py:1247: Exception

It took me half a day to figure out that after running sudo pkill postgres; pkill pageserver; pkill safekeeper; the problem disappears. But I'm not sure why. Remembering to run pkill (and maybe also do a clean rebuild for good measure) after seeing a new error is not the solution.
Environment
Local

Found the root cause. For some reason, there were a pageserver & safekeeper from the past running at the right ports from an earlier test run. I had long deleted their test_output but the processes were still running.
neon_local created the directory and started new pageserver & safekeeper processes, but connected to the old ones.
In the old ones, execve() succeeded because the pg_install directory still existed but then the getcwd failed because their PWD had been deleted.


swap "talk to" and "bank" options for bankers, "talk-to" and "exchange" option for GE Clerks, OSbuddy has this, would love RL to

one of the many QOL things i really would like to see RL have is this, one click banking and one click use of the ge would be really nice <3

That's already in Runelite. Checkout the Menu entry swapper plugin.

If this is resolved you should close it.

When barb fishing, it says "Training: Agility" on Discord


menu item selected style doesnt work

+1
When clicking on one of the quality menu list item, the source successfully changed.
However, the selected list item doesn't show any style (ex, with background color or different text color from the un-selected ones) to recognize which is selected.

+1
not add .vjs-selected class to the .vjs-menu-item

This probably is because the item is not marked selectable: https://github.com/videojs/video.js/blob/4b325ea8f8188a5db76489243f7469ba8f7995ba/src/js/menu/menu-item.js#L111


Cache environment variables so that regenerated builds use the same value

I normally don't keep these variables defined for my environment.  This makes working with the generated builds a bit of a pain since modifying a cmake file will cause the build to fail when it goes to regenerate.  By caching the environment variable it will simply reuse that value.

I normally don't keep these variables defined for my environment

What is the point of this? You can just keep them in .bashrc.

Working in large teams across multiple platforms, I've found it's best to keep things simple by removing manual setup whenever possible.  In this case, it's easy to write a wrapper build script that sets the environment variables and generates the build.

I've found it's best to keep things simple by removing manual setup whenever possible

Why you have to do it manually?
So instead of setting environment variable once you have to add it to every Android build? Make no sense to me. Also such approach will not work with Hunter since POLLY_ANDROID_NDK will not be forwarded to 3rd parties:
Toolchain file is the only way to apply global settings for 3rd party projects in Hunter.
Only CMAKE_TOOLCHAIN_FILE will be forwarded for all packages, neither standard
CMAKE_CXX_COMPILER/CMAKE_CXX_FLAGS nor custom variables
like ANDROID_FOO=boo will be applied globally.


fix cancel button of class performance config modal

What changes are proposed in this pull request?
fix cancel button of class performance config modal
How is this patch tested? If it is not, please explain why.
(Details)
Release Notes
Is this a user-facing change that should be mentioned in the release notes?

[ ] No. You can skip the rest of this section.
[ ] Yes. Give a description of this change to be included in the release
notes for FiftyOne users.

(Details in 1-2 sentences. You can just refer to another PR with a description
if this PR is part of a larger change.)
What areas of FiftyOne does this PR affect?

[ ] App: FiftyOne application changes
[ ] Build: Build and test infrastructure changes
[ ] Core: Core fiftyone Python library changes
[ ] Documentation: FiftyOne documentation changes
[ ] Other

Summary by CodeRabbit

New Features

Introduced enhanced dialog handling for class performance and confusion matrix configurations.
Updated dialog components for editing notes and configurations to improve user interaction.

Improvements

Refined state management for dialog components to ensure accurate configuration application.
Enhanced type safety with the addition of EvaluationProps for better clarity in component properties.

Closing in favour of #5166


build(fee): sn_resources depend on resource bounds signature

This change is

#455
#454  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @nimrod-starkware and the rest of your teammates on  Graphite


Use new runners for GPU jobs

This PR is updating the workflows to use new GPU runners. We replace v100 GPUs with l4 as we have more l4 GPUs. We also remove the PARALLEL_LEVEL variable because the new runners are not exposing it anymore

@jjacobelli I'm so excited to see this. When you're ready to move forward, would you be able to file an issue in https://github.com/rapidsai/build-planning that documents the game plan for rolling out the new runners? It's good to have a central issue that we can cross-reference if/when issues arise.

To Do:

[ ] Remove -testing suffix for H100 nodes

Closing this for now.


notifierFilterResolver

How is notifierFilterResolver used.  Does it notify when a filter has been applied?

notifierFilterResolver has nothing to do with filters (filtering of columns).
notifierFilterResolver is used for state management of PlutoGrid.
PlutoGrid is state management with stream events.
Events are emitted when certain methods that change state in the stateManager are executed.
Each widget listens for this event to handle state changes.
At this point, a notifierFilterResolver is used to filter out events that are not of interest in each widget.
For example, when an event that changes the cell value is raised, this event is only needed in the cell widget.
Other widgets ignore events for cell value changes.
Contains information that filters events for these notifiers.
Below is an example code for receiving column filtering events.
import 'dart:async';

import 'package:flutter/material.dart';
import 'package:pluto_grid/pluto_grid.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: const MyHomePage(),
    );
  }
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({Key? key}) : super(key: key);

  @override
  _MyHomePageState createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  final List<PlutoColumn> columns = [
    PlutoColumn(title: 'Id', field: 'id', type: PlutoColumnType.text()),
    PlutoColumn(title: 'Name', field: 'name', type: PlutoColumnType.text()),
    PlutoColumn(title: 'Age', field: 'age', type: PlutoColumnType.number()),
  ];

  final List<PlutoRow> rows = [
    PlutoRow(cells: {
      'id': PlutoCell(value: '1'),
      'name': PlutoCell(value: 'Kim'),
      'age': PlutoCell(value: 20),
    }),
    PlutoRow(cells: {
      'id': PlutoCell(value: '2'),
      'name': PlutoCell(value: 'Lee'),
      'age': PlutoCell(value: 20),
    }),
  ];

  late PlutoGridStateManager stateManager;

  late StreamSubscription<PlutoGridEvent> events;

  @override
  void dispose() {
    events.cancel();

    super.dispose();
  }

  void _listener(PlutoGridEvent event) {
    if (event is PlutoGridChangeColumnFilterEvent) {
      print('changed filter value event');

      // Column on which filtering occurred.
      print(event.column.title);

      // The filtering type of the column where the filtering occurred.
      print(event.filterType);

      // Filtered values.
      print(event.filterValue);
    }
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: SafeArea(
        child: Container(
          padding: const EdgeInsets.all(15),
          child: PlutoGrid(
            columns: columns,
            rows: rows,
            onChanged: (PlutoGridOnChangedEvent event) {
              print(event);
            },
            onLoaded: (PlutoGridOnLoadedEvent event) {
              stateManager = event.stateManager;
              stateManager.setShowColumnFilter(true);
              events = stateManager.eventManager!.listener(_listener);
            },
          ),
        ),
      ),
    );
  }
}

Ok. Thanks.  I was looking for an on event for when filters are applied.


ISPN-6320 Improve stability of ClientEventsOOMTest

https://issues.jboss.org/browse/ISPN-6320
My local runs shows that sometimes this test takes pretty long (since JVM struggles for life in this test, such things might happen). I think this is the root cause why it fails [1].
[1] http://ci.infinispan.org/project.html?projectId=Infinispan&testNameId=5048793009923214371&tab=testDetails

Integrated. Thanks @slaskawi !


Added error code and message to unexpected WaiterError

Fixes boto/boto3#233
In that specific case, the result now looks like:
WaiterError: Waiter InstanceStopped failed: Request would have succeeded, but DryRun flag is set.

Looks good, but what do you think about incorporating the code somewhere in the error message in exceptions.py?
    fmt = 'Waiter {name} failed: An error {code} occured: {reason}'

or something along those lines?

Most WaiterErrors don't have a code associated, so unless we want to add some in then it wouldn't make sense to change the string to favor a single error.

Ok.  The only other option would be to subclass from WaiterError to have something specific for this scenario (that included a code in its error message format), which I'm ok with not doing for now.
:shipit:

The more I think about it, the more I think the subclassing might be a better idea. With what I have now, the customer would have to call e.kwargs.get('code') which doesn't seem like a great interface. If I subclass then I'll be able to add the response as an attribute, so something like this:
class WaiterUnknownError(WaiterError):
    """Waiter failed for an unknown reason"""
    fmt = 'Waiter {name} failed: An error {code} ocurred: {message}'

    def __init__(self, response, **kwargs):
        super(WaiterUnknownError, self).__init__(**kwargs)
        self.response = response

Though I'm not sure that's the best name for it

@JordonPhillips I would not worry too much about saving the response in the error. The rest of the exceptions other than a ClientError does not have the response. I think the point of this PR was to make the waiter error message clear and not have a bunch of vague messaging around it.
Given that we do not even use the code in the message to the error, I would be in favor of removing the code argument in the WaiterError's constructor and test that the error thrown simply includes the more detailed message.

Awesome. Looks better. Just one last small comment on your test assertion.

:+1:

LGTM :ship:

:shipit:


Add options.addIteratorToImage

This update allows option to suppress the iterator in screenshot filenames by setting the option addIteratorToImage: false.

Excluding the iterator in filenames prevents the screenshots from being renamed each time the order of the tests is changed in the test script(s). When there are a large number of tests, this is helpful to prevent duplicates and tracking which screenshots are freshly rendered. Deleting the directory that contains the screenshots is an option to start fresh but committing baseline images to the repo will have to be done each time a test is reordered or a test is removed from the suite.


Add check for empty email form submissions

Description
This PR addresses issue https://github.com/pulumi/marketing/issues/864 by adding a check to make sure events generated from Hubspot's callback do not generate fake form submission events to Segment, polluting metrics with empty form fills.

@cnunciato could you also check this PR?


Problems factory_girl faker data in has_many associations

I'm new rspec test and factory_girl, help me that problem, please!
I have 3 models User, Review and Activity look like
class User < ActiveRecord::Base
  has_many :reviews, dependent: :destroy
  has_many :activities, dependent: :destroy
end

class Review < ActiveRecord::Base
  belongs_to :user
end

class Activity < ActiveRecord::Base
  belongs_to :user

  validates :target_id, presence: true
  validates :action_type, presence: true

model Activity to save activity of each user. In this case, activity is reviewing. Whenever user create a new record in reviews table, the system also creates a record in activities table (target_id = review_id , action_type = "review")
Now, when i write rspec test for User model, i need test for association User has_many Activity. So how can i faker data of model User, Review and Activity by factory_girl to do that???
Thanks!!!

Hello @VoTaiTri. It sounds like you're writing a unit test for the User model. Instead of using factory_girl have you considered using shoulda-matchers?
describe User do
  it { should have_many(:activities) }
end

Or are you trying to test that a Review is actually created for a User and saved in to the Activity association by your application?

Thanks @jsom
I solved that problem by gem 'shoulda-matchers'


Few questions about Objection usage

I'm currently considering switching to Objection from TypeORM and I got a few questions because things somewhat different there.
First: can I use ORM-like update? For example,
    const like = await LikeModel.query().findById(131);
    if (like) {
        like.power = 2;
        await LikeModel.query().update(like);
    }

I expect it to execute UPDATE only for record that is specified in like object. I understand that it's not designed to work this way so I guess I should either add where or use patchAndFetchById. Is it right?
If so, is there a way to ignore specific fields (id in my case) when updating? I would like to go further and ignore fields that were not actually updated but I guess it will require writing more complex wrapper.
Second: how can I ignore fields that don't exist in database?
I use $afterGet hook to perform some computing after fetching data from database and set results to object fields but these fields don't exist in database. I know about pickJsonSchemaProperties but it's too verbose for me and I don't need any data validation.
I currently implemented ignoring fields starting with _ using $formatDatabaseJson, is it correct?
Third: Objection (and underlying Knex) doesn't work with JSON fields, right?
I had to also implement serialization in $formatDatabaseJson.
    $formatDatabaseJson(json: object) {
        json = super.$formatDatabaseJson(json);

        for (const key in json) {
            if (json.hasOwnProperty(key)) {
                if (key[0] == '_') {
                    delete json[key];
                }
                else {
                    const val = json[key];

                    if(_.isArray(val) || _.isPlainObject(val)) {
                        json[key] = JSON.stringify(val);
                    }
                }
            }
        }

        return json;
    }

One more question: to get count of rows (scalar value) it seems like I have to write such a query:
await LikeModel.query().count("* as c").pluck("c").where("id", "<", 200).first()
There is no shorthand?
Sorry if I ask something that exist in docs already, I read documentation and search for related issues there and had no direct answers.
I mean, switching ORM will require rewriting big amount of code and I try to get familiar with Objection first to make a decision.

is there a way to ignore specific fields (id in my case) when updating?

Id is used by Objection to figure out which entity you are actually updating, you don't need to exclude it.

Objection (and underlying Knex) doesn't work with JSON fields, right?

No, it supports JSON data type just fine on DBs that support it (MySQL, PostgreSQL). Simple Model.query().insert(modelInstance) should work fine for entities that include object data (example JsonSchema for such field would be payload: { type: ['object', 'null'] },)

@mxs42 Btw, I'm curious, what made you switch from TypeORM? Is it still buggy? Or is it about performance issues?

it doesn't work otherwise

Can you share error that you are getting? Also which DB and what column type are you using?

it doesn't work otherwise

Can you share error that you are getting? Also which DB and what column type are you using?

export class TestModel extends BaseModel {
    static tableName = "test";

    array: string[] = [];
    data: any = {};

    // static jsonSchema = {
    //     type: "object",
    //     required: ["array", "data"],
    //     properties: {
    //         array: {type: "object"},
    //         data: {type: "object"},
    //     }
    // };
}

    const test = new TestModel();
    await TestModel.query().insert(test);
    // (node:20592) UnhandledPromiseRejectionWarning: Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ', '2018-09-25 14:12:53.317', )' at line 1

console.dir(TestModel.query().insert(test).toSql());
//'insert into `test` (`array`, `data`) values (, {})'

@mxs42 Judging by what you have pasted, JSON is not a problem, array is.

can I use ORM-like update?

Yes, but in a query-builder-like way :smile:
    const like = await LikeModel.query().findById(131);
    if (like) {
        like.power = 2;
        await like.$query().patch()
    }

how can I ignore fields that don't exist in database?

For example by implementing the $formatDatabaseJson method
class SomeModel extends Model {
  $formatDatabaseJson(json) {
    delete json.someField
    delete json.anotherField
    return super.$formatDatabaseJson(json)
  }
}

If that's too verbose, you can create a shared base class that removes the fields based on some static class property (for example).

Objection (and underlying Knex) doesn't work with JSON fields, right?

Objection does. You can implement the static jsonAttribues = ['objectAttr', 'arrayAttr', 'whatever'] getter if you don't want to use jsonSchema.

to get count of rows (scalar value)

This should work
await LikeModel.query().where("id", "<", 200).resultSize()

Yes, but in a query-builder-like way 😄

It works but I believe typings are wrong for this case.
patch(modelOrObject: PartialUpdate<QM>): QueryBuilderYieldingCount<QM, RM>;
modelOrObject isn't optional there, seems like a bug.

Oh, that's true. It should be optional. Could you create an issue for that bug as a reminder. I'll fix it soon.


Can we get an easy to remember command to remove stopped containers?

File: engine/reference/commandline/rm.md
These docs suggest:
docker rm $(docker ps -a -q)

as the way to remove stopped containers. I have to look this up EVERY. SINGLE. TIME. Why not just docker rm --stopped?

Thanks for sharing the suggestion. If this is still applicable, please help create an issue for a feature request in the CLI repo at https://github.com/docker/cli


chore: clean use of simulate chart

Description
lets default the widths and colours and use those defaults instead of all the copy paste for same result

This is being done by Manfred on another PR
https://github.com/DARPA-ASKEM/Terarium/pull/1552


runtime v2: Close platform in runc shim's Shutdown method.

Previously, the platform was closed as part of the Delete method when the
process was an init for a task and there were no more tasks after its deletion.
This can create problems if another task is created within the shim right after
the delete runs, which results in the platform being closed but the shim
continuing to run.
This change moves closing the platform to the Shutdown method after the shim's
context is canceled, which ensures the platform is only closed once the shim
is sure its done servicing containers.
Signed-off-by: Erik Sipsma<EMAIL_ADDRESS>Fixes #3895

Hmm, I'm sure you are definitely correcting an important problem, but looks like we will have to figure out what criu doesn't like about this flow of operations:
--- FAIL: TestCheckpointRestorePTY (0.68s)
    container_checkpoint_test.go:104: runc did not terminate successfully: criu failed: type NOTIFY errno 0 path= /run/containerd-test/io.containerd.runtime.v2.task/testing/TestCheckpointRestorePTY/criu-dump.log: unknown
--- FAIL: TestCheckpointRestore (0.25s)
    container_checkpoint_test.go:218: runc did not terminate successfully: criu failed: type NOTIFY errno 0 path= /run/containerd-test/io.containerd.runtime.v2.task/testing/TestCheckpointRestore/criu-dump.log: unknown
--- FAIL: TestCheckpointRestoreNewContainer (0.25s)
    container_checkpoint_test.go:306: runc did not terminate successfully: criu failed: type NOTIFY errno 0 path= /run/containerd-test/io.containerd.runtime.v2.task/testing/TestCheckpointRestoreNewContainer/criu-dump.log: unknown
--- FAIL: TestCheckpointLeaveRunning (0.26s)
    container_checkpoint_test.go:398: runc did not terminate successfully: criu failed: type NOTIFY errno 0 path= /run/containerd-test/io.containerd.runtime.v2.task/testing/TestCheckpointLeaveRunning/criu-dump.log: unknown
--- FAIL: TestCRWithImagePath (0.20s)
    container_checkpoint_test.go:465: runc did not terminate successfully: criu failed: type NOTIFY errno 0 path= /run/containerd-test/io.containerd.runtime.v2.task/testing/TestCRWithImagePath-checkpoint/criu-dump.log: unknown
--- FAIL: TestContainerList (0.01s)
    container_test.go:70: expected 0 containers but received 5
FAIL

@estesp Just to understand the tests a bit better, it looks like those same failures occurred in both the run with TEST_RUNTIME=io.containerd.runc.v1 and the run with TEST_RUNTIME=io.containerd.runc.v2. But my change is only to runtime/v2/runc/v2/service.go so I wouldn't have expected io.containerd.runc.v1 to be impacted at all. Is there something I'm missing or some dependency between the two?

@estesp I looked into the failure a bit more, I am able to reproduce it locally when running against containerd master w/out the changes in this PR.

--- FAIL: TestCheckpointRestorePTY (0.67s)
    container_checkpoint_test.go:104: runc did not terminate successfully: criu failed: type NOTIFY errno 0 path= /run/containerd-test/io.containerd.runtime.v2.task/testing/TestCheckpointRestorePTY/criu-dump.log: unknown
--- FAIL: TestCheckpointRestore (0.30s)
    container_checkpoint_test.go:218: runc did not terminate successfully: criu failed: type NOTIFY errno 0 path= /run/containerd-test/io.containerd.runtime.v2.task/testing/TestCheckpointRestore/criu-dump.log: unknown
--- FAIL: TestCheckpointRestoreNewContainer (0.29s)
    container_checkpoint_test.go:306: runc did not terminate successfully: criu failed: type NOTIFY errno 0 path= /run/containerd-test/io.containerd.runtime.v2.task/testing/TestCheckpointRestoreNewContainer/criu-dump.log: unknown
--- FAIL: TestCheckpointLeaveRunning (0.31s)
    container_checkpoint_test.go:398: runc did not terminate successfully: criu failed: type NOTIFY errno 0 path= /run/containerd-test/io.containerd.runtime.v2.task/testing/TestCheckpointLeaveRunning/criu-dump.log: unknown
--- FAIL: TestCRWithImagePath (0.27s)
    container_checkpoint_test.go:465: runc did not terminate successfully: criu failed: type NOTIFY errno 0 path= /run/containerd-test/io.containerd.runtime.v2.task/testing/TestCRWithImagePath-checkpoint/criu-dump.log: unknown
--- FAIL: TestShimDoesNotLeakPipes (0.00s)
    container_linux_test.go:260: exit status 1
--- FAIL: TestContainerList (0.01s)
    container_test.go:70: expected 0 containers but received 5

There are a few extra errors (perhaps because I didn't replicate the travis env perfectly or container-in-container issues), but those CRIU errors are consistent and look to be the same as what this PR is getting.
It's very strange though because I can see recent builds of containerd's master branch all succeeded... Any ideas? Is it possible it's the failures are unrelated to the code in this PR?

Tried an empty force-push to re-run the tests, but got the exact same results.
One other thing I just noticed that may or may not be relevant, the most recent build of containerd's master that succeeded was using a travis worker with kernel version 4.15.0-1040-gcp. However, the runs here are using kernel version 5.0.0-1026-gcp in travis (seems like the travis workers may have been updated?)
When I reproduced the criu test failures locally on master branch, it was on a machine with kernel 5.0.0-1022-aws.
Is it possible for the containerd maintainers to retry builds of master in travis to see if a travis worker kernel upgrade could be interfering with criu tests?

@sipsma you are correct; it is a timing issue with you happening to catch a Travis kernel upgrade that no other PR or branch run has been on! A draft PR I just created hit the issue without any code changes. Now testing against a later criu build in case there are fixes for a 5.0 kernel issue.

Codecov Report

Merging #3896 into master will increase coverage by 4.46%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #3896      +/-   ##
==========================================
+ Coverage      38%   42.47%   +4.46%
==========================================
  Files          88      130      +42
  Lines       12326    14716    +2390
==========================================
+ Hits         4685     6251    +1566
- Misses       6994     7544     +550
- Partials      647      921     +274

Flag
Coverage Δ

#linux
45.86% <ø> (?)

#windows
38% <ø> (ø)
:arrow_up:

Impacted Files
Coverage Δ

mount/temp_unix.go
0% <0%> (ø)

sys/reaper_linux.go
0% <0%> (ø)

services/server/server_linux.go
0% <0%> (ø)

sys/env.go
100% <0%> (ø)

snapshots/devmapper/snapshotter.go
66.39% <0%> (ø)

sys/stat_unix.go
0% <0%> (ø)

runtime/v2/shim/shim_unix.go
0% <0%> (ø)

sys/reaper.go
0% <0%> (ø)

oci/spec_opts_linux.go
0% <0%> (ø)

sys/fds.go
0% <0%> (ø)

... and 41 more

Continue to review full report at Codecov.

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

LGTM

Cherry picked to release/1.3 in #3907


Guide/Tutorial how to make my own version of picker

Hey,
I can't find any guide how to assemble my own version of color picker. Could I ask you for any hint at this issue?

I dont have a guide at the moment, but I will put it on my list of things to do to put one together. If you take a look in src you can see each of the color pickers, those are essentialy just custom color pickers. You can steal one of those as a starting point and go from there!


Scan groups are inconsistent when there are duplicate packages in npm

If the same package version is installed multiple times under different groups in a package-lock.json file (i.e. in both dev and prod), osv-scanner scan behaves inconsistently in showing which groups the package belongs to.
e.g. with this package-lock.json (from package.json), the output is randomly:
╭─────────────────────────────────────┬──────┬───────────┬─────────┬─────────┬───────────────────╮
│ OSV URL                             │ CVSS │ ECOSYSTEM │ PACKAGE │ VERSION │ SOURCE            │
├─────────────────────────────────────┼──────┼───────────┼─────────┼─────────┼───────────────────┤
│ https://osv.dev/GHSA-v88g-cgmw-v5xw │ 5.6  │ npm       │ ajv     │ 5.5.2   │ package-lock.json │
╰─────────────────────────────────────┴──────┴───────────┴─────────┴─────────┴───────────────────╯

or
╭─────────────────────────────────────┬──────┬───────────┬───────────┬─────────┬───────────────────╮
│ OSV URL                             │ CVSS │ ECOSYSTEM │ PACKAGE   │ VERSION │ SOURCE            │
├─────────────────────────────────────┼──────┼───────────┼───────────┼─────────┼───────────────────┤
│ https://osv.dev/GHSA-v88g-cgmw-v5xw │ 5.6  │ npm       │ ajv (dev) │ 5.5.2   │ package-lock.json │
╰─────────────────────────────────────┴──────┴───────────┴───────────┴─────────┴───────────────────╯

Because<EMAIL_ADDRESS>is installed twice, once as a prod dependency, and once as a dev dependency:
    "node_modules/eslint/node_modules/ajv": {
      "version": "5.5.2",
      "resolved": "https://registry.npmjs.org/ajv/-/ajv-5.5.2.tgz",
      "integrity": "sha512-Ajr4IcMXq/2QmMkEmSvxqfLN5zGmJ92gHXAeOXq1OekoH2rfDNsgdDoL2f7QaRCy7G/E6TpxBVdRuNraMztGHw==",
      "dev": true,
      "dependencies": {
        "co": "^4.6.0",
        "fast-deep-equal": "^1.0.0",
        "fast-json-stable-stringify": "^2.0.0",
        "json-schema-traverse": "^0.3.0"
      }
    },
    "node_modules/table/node_modules/ajv": {
      "version": "5.5.2",
      "resolved": "https://registry.npmjs.org/ajv/-/ajv-5.5.2.tgz",
      "integrity": "sha512-Ajr4IcMXq/2QmMkEmSvxqfLN5zGmJ92gHXAeOXq1OekoH2rfDNsgdDoL2f7QaRCy7G/E6TpxBVdRuNraMztGHw==",
      "dependencies": {
        "co": "^4.6.0",
        "fast-deep-equal": "^1.0.0",
        "fast-json-stable-stringify": "^2.0.0",
        "json-schema-traverse": "^0.3.0"
      }
    },

Presumably, this would also affect groups in other lockfiles that can support the same package being installed multiple times.

@cuixq can you please take a look?

@oliverchang I was actually thinking this one could be something I pick up if you want @cuixq to focus on other things, but up to you 🙂

@G-Rath feel free to take it! I am working on another issue at the moment. :)

Ok this has been an interesting one - I think I've boiled it down to the question of "should packages be merged based on their group?"
i.e. if I have a@1 that is "optional" and a@1 that is "dev", should that be a@1, groups: optional and a@1, groups: dev or should be it a@1, groups: optional,dev?
I've got PRs for both and they're probably both alright but for the first one its a bit weird then that we have "groups" when they'll only ever have one item, and in the second it means an empty group denotes "production" and that we want to only include groups that all packages of the same name+version are in.


docs(Popup): make allowed content types statically analyzable

This is presumably an issue with all propType definitions that reuse propTypes defined in another variable. I traced it down to react-docgen being unable to parse the union type because it viewed it as dynamic, which is technically true because that type definition is referenced from a variable and as such the propType is resolved at runtime.
Before

After

Current coverage is 99.73% (diff: 100%)

Merging #990 into master will not change coverage

@@             master       #990   diff @@
==========================================
  Files           140        140
  Lines          2304       2304
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           2298       2298
  Misses            6          6
  Partials          0          0

Powered by Codecov. Last update fa9175a...0fcecf2

Yikes, thanks.  Since node is "anything that can be rendered" it includes string, so we can actually simplify this to PropTypes.node.  React PropTypes docs:

// Anything that can be rendered: numbers, strings, elements or an array
// (or fragment) containing these types.
optionalNode: React.PropTypes.node,

Good call, was not even paying attention to the types to be honest. Patch incoming.

Pushed and renamed commit accordingly

Thanks will merge on pass.

Released in<EMAIL_ADDRESS>


Golang: Search remote licenses not working in a CI pipeline when scanning Docker image

What happened:
In our CI pipeline we run syft to scan a Docker image. No Go environment is present. search-remote-licenses (in env or .syft.yaml) is configured as "true", but processed as  "false" by the app internally instead of "true". So Syft is not fetching remote licenses.
It looks that syft search-mod-cache-dir has a path dependency that it should not have when working in an environment without Go.
What you expected to happen:
If search-remote-licenses is set by config file or environment file it should work always if set.
Steps to reproduce the issue:
In a local environment set HOME to a directory where no Go stuff is present (I use an environment with Go compiler), set GOPATH to empty string.
I can see that local-mod-cache-dir is set to the value I set with HOME.
Working:
  golang:
      search-local-mod-cache-licenses: false
      local-mod-cache-dir: /home/joerg/go/pkg/mod
      search-remote-licenses: true

Not working:
I invalidated HOME to not find Go stuff. GOPATH is not set.
HOME=/home/joerki/projects/inspect/temp syft scan mongo:5.0.26-focal -o syft-json=mongo-syft-single.json -vv
  golang:
      search-local-mod-cache-licenses: false
      local-mod-cache-dir: /home/joerki/projects/inspect/temp/go/pkg/mod
      search-remote-licenses: false

Anything else we need to know?:
N/A
Environment:

Output of syft version:
Application: syft
Version:    1.2.0
BuildDate:  2024-04-12T18:31:58Z
GitCommit:  dde5d349b1eef740c285255e6a9e3a8f5c9938e1
GitDescription: v1.2.0
Platform:   linux/amd64
GoVersion:  go1.21.9
Compiler:   gc

OS (e.g: cat /etc/os-release or similar):
uname -a
Linux delly 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux

(Native Linux, no WSL)

Hi @Joerki -- I'm a bit confused what the problem is. I see search-remote-licenses is set to false, which is the default and I don't see this being set by an environment variable, so it's expected to be false. The default local-mod-cache-dir is based on your home directory, which is also expected. Could you elaborate on your configuration and the problem a bit to help me understand?

Hi @kzantow,
in .syft.yaml, search-remote-licenses is set to "true" always. I do not change this setting. But when I change $HOME, search-remote-licenses turns to "false" by the application in the output I printed. The log does not show what is set.
I hope this helps.
BR
Jörg

Hi @kzantow ,
I changed the inspection and updated the description.
I hope you can reproduce the problem.
BR,
Jörg

Hi @kzantow ,
now I can describe the exact problem after I debug it properly.
Syft assumes that Go is installed on the machine when Go binaries are inspected. But this is a wrong assumption.
I modified HOME in the environment (to simulate that I do not have go on my machine).
{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch Package",
            "type": "go",
            "request": "launch",
            "mode": "auto",
            "program": "cmd/syft/main.go",
            "args": ["scan", "mongo:5.0.26-focal", "-o", "syft-json=/home/joerg/projects/mongo_inspect/mongo-syft-single.json", "-vv"],
            "env": { "HOME": "/home/joerg/projects/mongo_inspect/temp", "GOPATH": "", "SYFT_GOLANG_SEARCH_REMOTE_LICENSES": "true" }
        }
    ]
}

Please look here:
syft/pkg/cataloger/golang/licenses.go
func modCacheResolver
Syft appended "go/pkg/mod" to my HOME path. This is the content of my modCacheDir parameter.
My $HOME exists, but not $HOME/go/pkg/mod.
The result is that the path is not found (a trace method is written, not a trace for me, the problem should be much more obvious), and an empty fileresolver is created. So downloaded licenses go to nowhere.
My temporary workaround in the pipeline will be hopefully the creation of $HOME/go/pkg/mod directory.
But Syft has to use a directory where packages can be written to and analysed.
BR,
Jörg

I can confirm that my temporary solution - the creation of $HOME/go/pkg/mod before Syft invocation - is working.

Hi @kzantow,
please check also the use of 'local-mod-cache-dir' that is documented as alternative to GO standard directories.
This is also no working for me. I see in the debug output of GOLANG flag variables are taken, but not the cache dir settings.
Thanks.

face the same issue and the creation of $HOME/go/pkg/mod directory - solved it
waiting for https://github.com/anchore/syft/pull/2852 to be merged /cc @kzantow


HTTP: Revert HeaderNames and HeaderValues deprecation

We would have more control over our own constants, at the cost of keeping on maintaining our own list.

Can you give an estimation of when you plan to publish this change?
I don’t need a definite date, it is just to plan whether we will migrate to 3.4.0 or wait for 3.4.1 to be released first. Is it a matter of days, weeks, months?

It depends on how many bugs we find and their gravity. If there's a blocking bug, we could release very fast. Otherwise, probably one month.
But then, I don't understand what this is a blocker for you: those are just deprecation warnings. You can still stick with HttpHeaderNames and HttpHeaderValues, live with the warnings and your code will still compile.

Thank you for the info!
You are right, those are only warnings. But we just don’t like to have warnings :)


Unmarshal polymorphic LRO final response into result envelope

The result envelope contains the customer unmarshaller for its
polymorphic return type.

Fixes https://github.com/Azure/autorest.go/issues/738


Improved Kendall's tau implementation

(Sorry if this is long.)
This patch fixes a few problems in scipy.stats.kendalltau() and improves performance significantly.

The original implementation (2009) was a line-by-line translation of our code in the LAW library. The code has been significantly simplified and improved (i.e., 84s instead of 126s on 4 million elements) in the last years. This patch re-aligns the code.

Seven years ago, after some discussion on https://github.com/scipy/scipy/issues/1526, our code was copied with no reference to the original. We like our code to be reused, but the implementation is part of a scientific paper and I added a quotation to said paper. I also added a note "The code is derived from the LAW library (http://law.di.unimi.it/).", so possibly future maintainers can look for further improvements. If you think it's too much, just take it away. If you need an explicit statement from us saying that we give this code under a BSD licence, we can do that, too, but I think that the fact that I'm contributing it personally has that value.

The implementation contained some false statement about Python using QuickSort to do sorting, and QuickSort being quadratic (it is not in practice) but faster because of constants (false). Because of that it was using a slow numpy lexsort call. Now it always uses the much faster Python implementation of TimSort. The option that selected the kind of sort to use is a NOP and documented as such.

The result is min/max'd with 1/-1 so that it never happens that because of computational errors you get a value like -1.0000000001. In our experience this leads to all sorts of bizarre behaviour, e.g., if you scale the result so that it is between 0 and 1 you can get a negative value anyway.

The p-value was completely broken if ties were present. The null statistics in the code is valid ONLY if no ties are present. The general statistics is very complicated and needs to be checked by a statistician (the Wikipedia page gives no external source). I can help with the code to compute the various pieces, as they must be computed along the value of tau. What I did was to return nan in case of ties, and document this fact. Presently people are really puzzled. I'll open an issue.

References to the Kendall 1938 and 1945 papers have been added, as well as a clear explanation that this code computes tau-b, but tau-b reduces to tau-a if there are no ties. This "tau-a vs. tau-b" thing is a constant problem even in the scientific literature. I hope that this clarifies that they are the same thing. People can also check the papers.

It is now documented that using 'omit' for NaNs will result in delegation to another implementation.

The tests has been slightly fixed and go through without problems. The results of this implementation has been cross-checked with the Java implementation.

I found a good reference to the tau-b null statistics (probably the Wikipedia one has been taken from here). It also quote a statistics book and, having glimpsed at it using Google Books, the null statistics seems reasonable. I'll try to check with another book.
Apparently R just gives up:
Warning message:
In cor.test.default(c(0, 1, 1), c(1, 2, 3), method = "kendall",  :
  Cannot compute exact p-value with ties

@@            master   #5754   diff @@
======================================
  Files          234     235     +1
  Stmts        43180   43215    +35
  Branches      8161    8163     +2
  Methods          0       0
======================================
+ Hit          33500   33539    +39
- Partial       2602    2603     +1
+ Missed        7078    7073     -5

Review entire Coverage Diff as of a34bd20

Powered by Codecov. Updated on successful CI builds.

@vigna There is a PR #5548  that is a complete rewrite of kendalltau that makes efficient use of existing fast helper functions. It looks like it's faster than the old implementation similar to the LAW implementation. (and it looks easier to understand)
I haven't looked at the p-value issue, I thought we match the inexact approximation used in R, but I haven't looked at it in a long time.

Oh damn. I did this for nothing. Well, not really nothing, I wanted to contribute later a weighted version and this was a warmup.
The implementation you point at is based on ranking using a Fenwick tree. I played with the idea some time ago, and theoretically it can be brought to O(n log log n) with sophisticated data structures, but the main problem is that is not parallelizable. The MergeSort version scales almost linearly with the number of cores, with a little bit of additional programming, and can be even distributed using MapReduce-like frameworks.
With the counting version you're stuck to sequential forever. I you have in mind to scale seriously, I would think a moment before committing to the rank-based algorithm.
Of course, being in Cython is blazingly fast :). I guess a similar MergeSort version would be slightly faster (as it happens in Java—it has better locality).
R refuses to return a p-value if there are ties (see above), so there's nothing you can match. The value currently output is just arbitrary.

I'm curious, so I Cythonized this implementation, too (as PR https://github.com/scipy/scipy/pull/5548 is).
The results are very interesting:

At 10K elements, this implementation is ≈700% faster than https://github.com/scipy/scipy/pull/5548
At 1M elements, this implementation is ≈500% faster than https://github.com/scipy/scipy/pull/5548
At 10M elements, this implementation is ≈400% faster than https://github.com/scipy/scipy/pull/5548
At 100M elements, this implementation is ≈300% faster than https://github.com/scipy/scipy/pull/5548

Moreover, this implementation uses about one half (but up to one third, it's difficult to track) of the additional memory used by https://github.com/scipy/scipy/pull/5548 . Note that at the scale above (100M) this means Gigabytes of bloated memory usage and 111s instead of 37s.
To achieve that, the implementation uses Cython's fused types to avoid constructing sorting permutations. The rank-based algorithm has to convert scores to ranks to work, but Knight's algorithm doesn't: everything is done with exactly two support arrays—one of the joint sorting permutation and one to support MergeSort. On the contrary, https://github.com/scipy/scipy/pull/5548 has to compute two permutations, allocate another vector for the Fenwick tree, and allocating several other vectors of the size of the data to perform the computations that our code executes with a simple loop.
Indeed, the very large gap in speed cannot only be explained by the better locality of MergeSort. I think it's also due to the bloated memory access.
As I said this implementation is easily parallelizable.
IMHO, if you want Scipy to be scalable the rank-based algorithm is not what you need. The current implementation is still not as fast as our Java implementation but it get close.

Anybody interested in this code?

@josef-pkt, @rgommers: ping
FWIW, looks good to me from the style side. I'm not familiar with the topic, but I'd trust the correctness here.

One thing is missing because I would need someone to tell me the best practice.
The _kendalltau() Cython code works for two fused types comprising int, long, float, double. If presently you try the code, say, with two arrays of strings, it will throw an exception.
Code has been prepared for that evenience—_toranks() is an efficient procedure to reduce any array to an array of ranks. The problem is that I haven't been able to find the correct way to check whether the type of a numpy array is compatible with a Cython fused type.
Of course one can always convert to ranks, but it's a major memory killer and it's a pity—99.99% of the calls will be with integers or doubles.
I considered catching the exception, but it's a problem anyway because the exception doesn't tell you which of the two arguments is causing the problem..
Presently the solutions I see are:

simple, slighly inefficient: catch exception and convert everything to ranks (might convert one array unnecessarily).
complicated, efficient: catch exception and try first to convert the first argument; if an exception is thrown, try to convert the second argument; if an exception is thrown, convert both arguments.

Any suggestion is welcome.

In principle the type check should be, for this fused type, if x.dtype in (np.intc, np.long, np.float32, np.float64): ... --- but I don't recall how Cython type cast exactly worked here. However, it might make sense to change the fused type to
cimport numpy as np
cdef fused ordered0:
    np.int32_t
    np.int64_t
    np.float32_t
    np.float64_t

so that you ensure the 64-bit data type is available even if int==long (iirc 32-bit Windows). The corresponding check is if x.dtype in (np.int32, np.int64, np.float32, np.float64): ....

Thank you! That was exactly the missing piece I was looking for.
I have added tests that check that ranks are computed when needed.

Anybody willing to merge and close the request?

The code looks good, and the arguments in favor of this over #5548 at least in terms of efficiency make sense to me. @vigna the idea is that this PR should be merged and therefore #5548 is unnecessary and should be closed, right?
@behzadnouri you are working on #5548 -- can you take a look at this proposal and see if it makes sense from your end, too?
@sturlamolden @ev-br it looks like you worked with #5548 a bit, feel free to have a look here if you have time.

I'd suggest that if there are no further comments within the next two days, merge as is.
(gitignore and small stylistic issues are IMO non-blocking, and not necessary to address for merge).

Works for me.

The main issue I see is the use of C long, which fails on Windows 64 where long is shorter than a pointer. This should be fixed before the code is merged.

I implemented all suggested fixes.

Actually: I left out the suggestion to use TimSort as it implies including a lot of C code. It would be better included at the numpy level—they already have several algorithms.

Using timsort instead of mergesort was just a suggestion, as were declaring arrays contiguous. The important part was getting rid of C long, which was an error on Windows 64.

https://github.com/scipy/scipy/pull/5548 code is simpler and easier to maintain (also ~150 lines of code shorter than this code)

fused types work like C++ templates (i.e duplicated code is generated for each type). That means longer compile time and larger binaries. With https://github.com/scipy/scipy/pull/5548 i get:
 $ stat --printf="%s" _stats.cpython-35m-x86_64-linux-gnu.so
 633880

whereas, this code generates:
 $ stat --printf="%s" _stats.cpython-35m-x86_64-linux-gnu.so
 3207312

That is 5 times larger binary.

performance-wise: the claims made here do not hold; It has always been the convention to show the code behind the benchmarks. With https://github.com/scipy/scipy/pull/5548 i see
 In [3]: import numpy as np
 In [4]: from scipy import stats
 In [5]: np.random.seed(2718281)
 In [6]: n, k = 1 << 20, 1 << 15
 In [7]: xs = np.random.randn(2 * n).reshape(2, n)
 In [8]: ys = np.random.choice(np.random.randn(k), (2, n))

 In [9]: %timeit -n 5 stats.kendalltau(xs[0], xs[1])  # no ties
 5 loops, best of 3: 1.24 s per loop

 In [10]: %timeit -n 5 stats.kendalltau(ys[0], ys[1])  # w/ ties
 5 loops, best of 3: 905 ms per loop

with this code:
 In [9]: %timeit -n 5 stats.kendalltau(xs[0], xs[1])  # no ties
 5 loops, best of 3: 1.19 s per loop

 In [10]: %timeit -n 5 stats.kendalltau(ys[0], ys[1])  # w/ ties
 5 loops, best of 3: 1.05 s per loop

https://github.com/scipy/scipy/pull/5548 can benefit much more when there are ties in the data, and otherwise performs inline with this code.

hopefully someone would verify the changes made to p-value calculations are accurate before merging in.

I agree with @behzadnouri  on this. #5548 is the one I would prefer if given a choise. It only uses Cython to count concordant and disjoint pairs, and that is all we need it for here.
The issue with tied ranks is orthogonal to this, as is tau-a vs. tau-b or tau-c.

Yes, the code is longer. But is is also parallelizable (e.g., for multicore platforms).  I prefer algorithms that are open to further development.

The binary is larger. It can be significantly reduced by eliminating from the fused type some of the types, e.g., 32-bit floats. It would be interesting to benchmark what happens with a single type (e.g., almost always passing from _toranks()). However, I don't see this as a problem—it's the whole point of templating.

This part is seriously weaseled. As anybody can check from the commit dates, I performed my benchmarks before a commit on #5548  that fixed many memory-bloated problems I reported. Rather than thanking me for finding bottlenecks and waste of resources in his code, the author decided to write that my claims "do not hold". Thanks :) The new code is now much faster, thanks to my suggestions. It is still significantly slower on the most difficult inputs—reversals:
 import numpy as np
 from scipy import stats
 x = list(xrange(10000000))
 y = list(reversed(x))
 x = np.asarray(x)
 y = np.asarray(y)
 %timeit stats.kendalltau(x, y)

#5548  before last commit: 7.77s
#5548 now: 2.89.s
This implementation: 1.72s

Things are different with a very large number of ties:
 x = [0]*5000000 + [1]*5000000
 y = list(reversed(x))
 x = np.asarray(x)
 y = np.asarray(y)
 %timeit stats.kendalltau(x, y)

#5548  before last commit: 5.22s
#5548 now: 1.14s
This implementation: 1.35s

So, yes, in the quite unlikely case of almost all ties #5548 takes 15% less time, against a 68% increase in time in the difficult cases. But once again, don't get fooled: if we enlarge tenfold the last input, we have

#5548  before last commit: 67s
#5548 now: 18.5s
This implementation: 13.9s

Even if we reduce tenfold the last input results are quite different:

#5548  before last commit: 568s
#5548 now: 104ms
This implementation: 102ms

You'll going to pay at some point for the cache-unfriendly access of Fenwick trees, no matter what. So there's a very selected set of inputs on which #5548 is slightly faster, but on most inputs it will be slower, often significantly.

The p-values returned currently, as those calculated by #5548, are entirely wrong in the presence of ties, as it is easy to check by comparison with mstats_basic.kendalltau(). I would be much more worried about that, frankly. My values have been cross-checked with that implementation.

The last commit on #5548 was on Nov 27, and you made your claim on Jan 25. Clearly it did not hold as #5548 was not different when you made your claim.
#5548 is not broken anymore than scipy master is broken. If tied rank computation is broken in master it is orthogonal to speeding up the computation by cythonization. It belongs on two PRs anyway.
Personally I don't see a significant difference in the performance.
As for parallalization: Do we need it? Nonparametric statistics is typically used on small data sets. Parallelization on Kendall's tau is likely to involve a batch of multiple taus rather than a single huge one. In that case a tool like joblib will do just fine.

Riding #5548 and master for tied ranks is a minor issue if they are broken (I haven't checked). Presumably it is just one LOC or so that needs to change.

@sturlamolden I'm sorry, but you are clueless.

The last commit was 11 hours ago:
https://github.com/behzadnouri/scipy/commit/b95778c35cba323738ec893d3e6896a74792e384
You are looking at commits backwards.

Please check Noether's book, or mstats_basic.kendalltau(), and learn how the correct p-value should be computed before saying nonsense like "just one LOC".

@sturlamolden Could you please motivate? In Python 2.7, range() creates a list, and we're trying to avoid the memory-bloated approach here. Can you refer to some programming guidelines, for instance? There are more than 100 calls to xrange() in Scipy—should they all be replaced? Is that what you're suggesting?
An alternative could be adding a dependency on six or python-future to avoid the range()/xrange() mess in Python 2 vs. 3. But I don't want to take that responsibility.

xrange can be used in Cython, and it translates to a C loop and is Py2/3 portable. I don't see problems with that.

We never use xrange in Cython.
The one on line 48 cannot be optimized to a C loop.

It does not translate to a C loop unless the argument is a C integer. Here it is a Python int.

We use xrange in Cython, find scipy -name '*.pyx' |xargs grep xrange|wc -l -> 61.
You can look at output from cython -a to convince yourself it indeed translates to C loops.

The fused types expansion is 640kb, debug info stripped. This is not so bad compared to other stuff we have, so I don't think it's a big problem, and it can be revised later if needed. I don't see issues blocking merge at the moment.

updated https://github.com/scipy/scipy/pull/5548. The benchmarks in this comment are now running
 In [3]: import numpy as np
 In [4]: from scipy import stats
 In [5]: np.random.seed(2718281)
 In [6]: n, k = 1 << 20, 1 << 15
 In [7]: xs = np.random.randn(2 * n).reshape(2, n)
 In [8]: ys = np.random.choice(np.random.randn(k), (2, n))

 In [9]: %timeit -n 5 stats.kendalltau(xs[0], xs[1])  # no ties
 5 loops, best of 3: 958 ms per loop

 In [10]: %timeit -n 5 stats.kendalltau(ys[0], ys[1])  # w/ ties
 5 loops, best of 3: 630 ms per loop

on https://github.com/scipy/scipy/pull/5548, versus, this code which runs:
 In [9]: %timeit -n 5 stats.kendalltau(xs[0], xs[1])  # no ties
 5 loops, best of 3: 1.19 s per loop

 In [10]: %timeit -n 5 stats.kendalltau(ys[0], ys[1])  # w/ ties
 5 loops, best of 3: 1.05 s per loop

the issue with p-values (if accurate) is entirely orthogonal to performance of counting number of ties and concordant/discordant pairs. it can be (and better be) handled in a separate commit.

 In my implementation, it takes more than 60% of the time, which is crazy. I'll try to see if I can get rid of it, too, without allocating so much memory (#5548 still allocates twice as memory as my implementation, which I don't like).

No. I'll try to explain again: a basic principle of programming and software engineering is that it is entirely useless to benchmark incorrect code in any way (speed, source-code metrics, etc.).

It requires that the benchmarked code is actually incorrect. If the error is elsewhere then fixing it is an orthogonal issue.

Just to put things in perspective:
x = range(10000000)
y = range(10000000)
stats.kendalltau(x,y)

takes 1.72s in this implementation, and 3.38 with #5548 .
x = np.random.randn(10000000)
y = np.random.randn(10000000)
stats.kendalltau(x,y)
takes 11s in this implementation, and 7.8s with #5548 .
x = range(10000000)
y = list(reversed(range(10000000)))
stats.kendalltau(x,y)

take 2.60s in this implementation, and 3.60 with #5548.
So in the case of total uncorrelation #5548 is about 40% faster than this implementation, but as we move towards complete correlation or complete uncorrelation it gets up to 200% slower. Fascinating.
As I already mentioned, this doesn't take into account that #5548 is skipping the work to compute a correct p-value. But that work is linear—I don't think is going to change significantly these figures.

Has nothing to do with correlation!
You can create correlated random variables with
n = 10000000
rho = 0.9
np.random.seed(2718281)
x = np.random.randn(n)
y = rho * x + np.sqrt(1 - rho*rho) * np.random.randn(n)
%timeit stats.kendalltau(x, y)

and see how the performance change with rho.
For example, on my machine for all the values of rho in [-0.9, 0.0, 0.9] https://github.com/scipy/scipy/pull/5548 performs faster by a fixed amount (with n = 10000000)

So in the case of total uncorrelation #5548 is about 40% faster than this implementation, but as we move towards complete correlation or complete uncorrelation it gets up to 200% slower. Fascinating.

Here is a profile across correlation values showing that is simply not true, and you are just extrapolating a false conclusion from a hand-picked degenerate example.
With https://github.com/scipy/scipy/pull/5548 I get:
In [5]: import numpy as np
In [6]: from scipy import stats
In [7]: np.random.seed(2718281)
In [8]: n = 1 << 20
In [9]: xs = np.random.randn(2 * n).reshape(2, n)

In [10]: for rho in [-.95, -.9, -.5, 0, .5, .9, .95]:    # correlation value
   ....:         ys = rho * xs[0] + np.sqrt(1 - rho*rho) * xs[1]
   ....:         %timeit -n 5 stats.kendalltau(xs[0], ys)
   ....:
5 loops, best of 3: 847 ms per loop
5 loops, best of 3: 882 ms per loop
5 loops, best of 3: 961 ms per loop
5 loops, best of 3: 957 ms per loop
5 loops, best of 3: 989 ms per loop
5 loops, best of 3: 911 ms per loop
5 loops, best of 3: 870 ms per loop

whereas your code performs:
5 loops, best of 3: 1.17 s per loop
5 loops, best of 3: 1.16 s per loop
5 loops, best of 3: 1.2 s per loop
5 loops, best of 3: 1.19 s per loop
5 loops, best of 3: 1.2 s per loop
5 loops, best of 3: 1.23 s per loop
5 loops, best of 3: 1.2 s per loop

so https://github.com/scipy/scipy/pull/5548 has better performance consistently across the correlation spectrum, with ~150 fewer lines of code and a simpler shorter algorithm and a binary 1/5th of the size generated by your code.
Above profile does not include any ties, and as shown in this comment, https://github.com/scipy/scipy/pull/5548 performs even faster when there are ties.

@behzadnouri , please calm down. Remember: you're the one who claimed my benchmarks were wrong after surreptitiously changing your code, fixing the problems I identified, and speeding it up. I haven't still got an apology.
My interest here is to get into Scipy a good implementation of the hyperbolic τ. Writing a good implementation of Kendall's τ was just a nice step to learn the environment and Cython. The only important thing is that Scipy gets a good implementation. That implementation can be based on ranking by Fenwick trees or Knight's algorithm—it doesn't make a difference to me. I think it is extremely good that your implementation, initially ten times slower and using much more memory, has improved so much: but this just happened because it was challenged by my implementation. Competition is good—it leads to better implementations. But competition is good if it is fair.
I've been tinkering with these two implementations two years ago a lot, while I was working on the hyperbolic τ. And in all my Java tests, there was no way for the ranking-based implementation to beat the other one on real-world, large-scale cases. I even have a survey paper detailing how to compute a series of different correlation indices using ranking, but I ended up never publishing it because the ranking-based implementation needs more memory, it is not parallelizable, and in my tests it was slower. Note that you never discuss memory, but for large-scale computations it is an issue (and yes, there are people computing Kendall's τ to establish similarity between rankings on billions of elements).
So what I'm trying to understand is whether we are hitting some Python limit that makes one implementation better than the other, whether my benchmarks two years ago were wrong, whether there's some engineering detail in your ranking-based implementation that makes it faster (as the Fenwick-tree code of mine, of course, is identical), or where there's some engineering mistake which makes my implementation now slower in several cases. I think understanding this is just a good thing.
One problem is your insistence in benchmarking code that does not compute a correct output. Computing the p-value requires a linear number of floating-point operation, and it does take a bit of time. The p-value is part of the output—it's not "orthogonal" in any way. I'd find ridiculous stripping away from my code the computation of the p-value to make it incorrect as yours.
Could you please just implement correctly the Kendall τ computation, including the p-value? It should match that of mstats_basic. Then comparing code and benchmarks will be meaningful.
For what matters correlation: I should have explained myself better. Kendall's τ has two natures: it is a statistical correlation index, and it is a similarity measure. In fact, if you read carefully Kendall's 1945 paper, you'll see that τ between n-point score vectors r and s is defined as the cosine similarity between two vectors r' and s' of dimension n(n-1)/2, indexed by i<j, where r'(i,j)=sgn(r(i)-r(j)), following a suggestion in a paper by Daniels who casted a number of statistical correlation measures as cosine similarity in suitable vector spaces.
When I say "correlated", I mean that the ranking are the same. All pairs are in the same order. "Uncorrelated" means half of the pairs in the same order, half not. I'm not talking about statistical correlation (there's a connection, of course) of samples from deviates. The following benchmark maybe explains better:
from scipy import stats
import time
import random
import numpy as np
n = 10000000
random.seed(-1)
for i in range(11):
    x = range(n)
    y = range(n)
    for p in random.sample(range(n), i*n/10):
        x[p] = random.randrange(n)
    for p in random.sample(range(n), i*n/10):
        y[p] = random.randrange(n)
    start = time.time(); stats.kendalltau(x,y); print time.time() - start

So we're taking two perfectly correlated scores, and perturbing a fraction of them until they become entirely uncorrelated. Timings with my implementation:
1.70250988007
4.65345907211
6.29708600044
8.14617800713
9.33617806435
10.9234230518
11.6215808392
12.3253178596
12.8257927895
13.5363130569
13.9489281178
With yours:
3.39184904099
4.96803808212
6.24258303642
7.4729039669
8.17202496529
8.7629570961
9.12338995934
9.63618612289
9.72986793518
9.62369203568
10.2939319611
Going towards perfectly opposite correlation the behaviour is symmetric. I'm noticing real now that the window in which my implementation is faster is quite small, and it would be certainly be even smaller if we added ties. So there's actually in most cases a small speed improvement, paid for using more memory. I'll do some testing to try to understand whether this is structural or there's something depending on Python.
I'd wait that everything is settled before committing any solution. Also, the speed vs. memory tradeoff is mostly a matter of taste.

Update: these are the timings after the improvements I suggested to @behzadnouri  for #5548 :
3.31774711609
4.87999415398
6.07502317429
7.35723209381
7.85929298401
8.45085310936
8.96431112289
9.3034260273
9.4725651741
9.55348515511
9.82043719292
This is clearly a few percents better, and I think is that further improvements in speed are possible.
Does anybody know whether it is possible to do cleanly one-instruction population counting in Cython? In gcc that would be __builtin_popcountll(). Using population counting one can significantly reduce the memory usage of the Fenwick tree by doing ranking-in-a-word manually.

We can use gcc intrinsics in Cython if we provide an alternative for MSVC (and Intel C on Windows). We have that in several places. All it takes is some preprocessor magic in a header file.

Good. I have now a Java implementation using a Fenwick tree with 64-bit leaves. It is maybe 1% slower than the standard tree, but it uses 1/32th of the additional memory of the standard implementation (i.e., almost nothing—two bits per element). This relieves from #5548 the problem of using much more additional memory. I'll look for sources with the preprocessor magic.

I did some more experiments today. My conclusions are that:

By using non-dense ranks and flattening the Fenwick tree, #5548 can use a negligible amount of memory more than my implementation. The memory used by the current implementation is dependent on the number of distinct values in the second argument, but without ties it is about 30 times larger than necessary. With a very small number of distinct values will be smaller instead. Note that this depends only on the ties in the second argument. In any case after the recent improvements we are talking about 50% additional support memory with respect to my implementation, which is not so bad.

Support for parallel recursion in Python is abysmal. The only way to get parallelism is by creating processes, and the overhead is so high that the advantage can be seen only after millions of elements (e.g., on my laptop I get a 4x increase in speed, easily outperforming #5548). This is in striking contrast with C or Java, where benefits of multithreading can be seen after a few thousand elements. So my argument about parallelization does not hold in this environment—at least not now.

Considering that speed results are so data dependent, I think that Fenwick trees are more than OK for Scipy. I'm closing this pull request and I'll reopen the issue about the wrong p-value.

@vigna  Thanks Sebastiano. I was curious how this speed comparison will turn out. I find it difficult to guess in advance how fast different algorithms and implementations are.

Coming more than two months late, I'd still like to say thanks @vigna .
While I do not claim to understand details, I wonder about your comment about parallelism. Naively, I'd expect that in Cython, in a nogil context what you have is just C or C++, so there should be no difference with parallelism. Where does this go wrong?
Whether we can use multithreading or some such is a separate issue: as a cross-platform project we are limited by the lowest common denominator of at least gcc and clang and MSVC and I'm not sure what sort of solution is possible within these constraints.
Also the issue with p-values and ties, I think, is separate. It's going to take a statistician to figure out (and I'm not) but if you have a clear idea of why the current handling of ties is wrong and how to fix it, I'm sure working on this would be appreciated.

Well, if you want to access parallelism via Python is quite heavy—you need to use processes. I do not know whether accessing parallelism at the C/C++ level could cause portability problem. Let's say it's just not a trivial issue.
The p-values are now fixed in this code, and aligned with mstats_basic.kendalltau(). It's not too difficult—you just have to compute a little bit more values, and compute a variance. The references I've given explain it all.

It is about the granularity of parallelism. nogil would allow multiple Kendall taus to be computed in parallel with Python threads, but a single Kendall tau would be computed on a single thread.
@vigna: processes are not needed. We can use threads. There are two code examples in scipy/spatial/ckdtree.pyx.

The smallest common denominator is Python threads.

If we are going to use threads spawned in C (that is, not Python or Cython), we have three options:

Use Python C API to spawn Python threads
Win32 threads on Windows (except with Cygwin), pthreads anywhere else
GCD on Apple, OpenGL anywhere else

The latter has a problem with libdispatch and libgomp conflicing with os.fork. FreeBSD needs special handling too.


Omnifunc support

Thanks for the great plugin! It works amazingly well out-of-the-box.
I see that the plugin depends on a "full" completion plugin to work properly, since the built-in vim.lsp.omnifunc seems to simply return a gigantic list of all available completion options, regardless of the current context. I'm curious whether this is a fundamental limitation or whether there's any chance of getting omnifunc support. If it's the latter, I'd be happy to contribute towards getting it to work.

Update: I realized this is actually related to a recent update to lua-language-server itself. Sorry for the trouble!

Hi José, sorry, didn't have the time yet to look into this, but glad it's not related to this plugin.
But you're saying that sumneko returns all suggestions for every completion? Maybe post an issue there? Doesn't sound right for sure

No worries, and thanks for putting this together. It's a strange issue, and I think it might be related to vim.lsp.omnifunc itself, but I'll investigate. Thanks again!

@jose-elias-alvarez have you been able to resolve this issue?
I'm trying to set up my lua dev environment with sumneko and this plugin.
Using omnifunc I don't get any useful values when completing after vim.api.

@jandamm Take a look at the Sumneko settings in defaults.nvim, which work well when using omnifunc for runtime files and plugins.

Thank you for the hint. I found a similar snippet in the lspinstall wiki.
I still wonder why it does not work with lua-dev since it uses  basically the same config. 🤷♂


[en]: description of the cronjob schedule timezone

Signed-off-by: cndoit18<EMAIL_ADDRESS>description of the cronjob schedule timezone
fixes: #29463
link: kubernetes/kubernetes#104404

hi, @sftim This is my first involvement with Kubernetes/website and I don't know much about the process involved.
Do I need to update the Kubernetes version above?
As well as my broken English may not support a large English description. 😢
I hope you can help me, thanks!

No problem @cndoit18. Can you squash your commits please? This looks ready to merge otherwise. I wouldn't mind seeing a tech review / validation from someone.
/lgtm

No problem @cndoit18. Can you squash your commits please? This looks ready to merge otherwise. I wouldn't mind seeing a tech review / validation from someone.
/lgtm

Done, thank you.

/lgtm
/approve

This PR is wrong, we never state that this functionality is officially supported. I'll open a revert when I figure out the entire situation with this.


The option "Python/Native Debugging" is missing.

Environment

Steps to Reproduce

Create new project: Visual C++ > Windows Desktop > Windows Console Application
Open the property page
Click Debugging tab
Click to open the drop-down list
Observes

Expected behavior
The option "Python/Native Debugging" should exist in the list.

Actual result
The option "Python/Native Debugging" is missing.

Hmm, this works for me on built bits. Something might be missing in the install.

Sorry not sure yet. I have to look into what the difference is between the installed bits and when I build the bits locally. Something that's happening locally isn't ending up in the final install.

Problem was a change the C++ team made. They changed their target path for projects from v160 to v170. I've updated our bits to reflect this.

@rchiodo
On today's build, this option is still missing.


Rethink maps

We are converging to Domain as an interface: it is any object type that supports eltype and in. We make methods with which one can combine domains, where the individual domains don't have to be Domain types. This is clearly very flexible. Perhaps we can do the same for maps and make the framework more generic/applicable?
A map is really just a function: y = f(x). Thus, perhaps any type that supports the calling operator can be seen as a map. Or perhaps any type that supports * can be a map. We could treat a matrix A as a map, the map then being the matrix-vector product y = A*x. Even a number could be a map: 2 represents multiplication by 2. As long as * is associative (which I think Julia already assumes in many cases), the interpretation of * as applying a map is consistent with composition: (A*B)*x = A*(B*x). With this approach, I think we would not even have to implement affine maps. We can just use the existing linear algebra functions and vectors/matrices.
Julia functions have a known output type if you give it a (combination of) input type(s). The current definition of AbstractMap{S,T} really is like a typed function. It corresponds to a function for which you restrict the input type to be S. The output type T is perhaps superfluous. From this point of view, a better name might be TypedMap{S} or TypedFunction{S}. It could have an implementation like:
(*)(f::TypedFunction{S}, x) where {S} = *(f, convert(S, x))

Any concrete subtype would implement multiplication for arguments of type S only.
In order to generically support maps like 2, cos and rand(2,2), it is somewhat restrictive to assume that the input type is known. We can in general assume that, given the map and the input type, the output type is known. (Worst case it is Any.) Thus, we could have TypedMap{S} <: AbstractMap where AbstractMap has no type parameters at all. What the map does, depends on the type of the input and is expressed by implementing (*)(m::MyMap, x).
Ideally, eventually, computing Jacobians etcetera is done generically via automatic differentiation. Composition of maps ideally would use fusion (like broadcast), rather than layered CompositeMap's or CompositeMap's with many elements.
As with domains, as long as you are manipulating variables of type AbstractMap we can use standard function names. If you intend to manipulate any object that implements the map interface, whatever we decide it to be, the intention has to be implicit in the name of the function that is being called (like convert_map and promote_map) or the operation has to be consistent with the generic meaning of the function name (as with *).
I'm sure there'll be some problems I'm not seeing at the moment too.

Maps as an interface is definitely the right approach. We would probably still need a special type for affine maps however as x -> (A*x) has to recompile for each A.
I think using composition notion ∘ is preferable to * as maps are not naturally an "algebra", and also, we want "right-associativity" (see https://discourse.julialang.org/t/why-is-multiplication-a-b-c-left-associative-foldl-not-right-associative-foldr/17552)
This question goes hand-in-hand with the question of broadcast and domains. That is, can we write exp(im*(0..1)) or should we require exp.(im .* (0..1)). Broadcast notation should be the "default" as its the easiest to implement, and support for other operations would be implemented by lowering to their broadcast variants, as in base (e.g., +(a::AbstractArray, b::AbstractArray) calls broadcast(+, a, b).)
I believe there is a package out there that has something like TypedFunction, but I couldn't find it.

Okay, good points! Let's use ∘ then for composition. I'm also very much in favour of using broadcast notation to easily make mapped domains. Perhaps that could even lead to fusion, but I have little experience with the broadcast framework so far.
About affine maps, I was thinking of the following:
struct CompositeMap{A} <: AbstractMap
    maps  :: A
end

where maps would be, say, a tuple of an array and an int. If we can not get this to work without having to define x -> A*x then I agree it is not worth it.
Perhaps it depends on what we define the operation of applying a map to be. If the syntax is y = f(x), it would be awkward to define the calling operation on abstract arrays in this package (even impossible because the type has to be concrete?). The syntax * has disadvantages too, because then we would like to define cos * 0.5 to be cos(0.5).
On the other hand, if we continue to use y = applymap(A, x), then we could define applymap for arrays, numbers, etcetera. Or we could have two fallbacks applymap(A, x) = A*x and applymap(f::Function, x) = f(x). The interface of what we consider to be a map would include an implementation of applymap.
As an interface and from the point of view that maps are functions, y = f(x) is of course nicer syntax.
I'm talking in thin air now, perhaps some exploring is called for.

My current feelings are:

* should be reserved only for algebras.
Operators and functions are not naturally an algebra. Operators are "functions of functions".
So ApproxFun's notation D*f is wrong: it should be D(f). and operator composition should be D ∘ D, not D*D. Note that this is the same change Chebfun did from Linop to Chebop.
Operators and functions are equivalent to (Quasi-)Matrices and (Quasi-)vectors, that do form an algebra and should support *. But "functions as functions" and "functions as vectors" should be two different types.

How does this fit into maps? Something like a rotation is both a function and a matrix, depending on what it's acting on. I guess I'm arguing these should be different types...

I completely agree here.

So, this would lead to using the y=f(x) syntax for calling a map, which is the most natural one, and wrapping matrices and numbers into a map type, is that right?
For Domains, each domain is free to implement in. However, in is also implemented at the general level of Domain{T} with some checks and conversions, calling indomain for concrete domains who can then assume that the argument is of type T and need not worry about conversions. We can't do this for the calling operation on an abstract Map type. (Though perhaps we don't want to.)

While we are rethinking maps, we may want to rethink MappedDomain as well. The only sensible definition of a mapped domain in DomainSets.jl is where you think of the mapped domain as the image of the original domain under a map. In particular, it should hold regardless of any distribution of the points within the domain or of any metric in the space involved. Thus, mapping 0..1 using y=x^2 should equal 0..1.
The equality of a MappedDomain with a concrete domain that represents the same image will of course be difficult to check in general. However, in all my current use cases of mapped domains, I am actually interested in retaining the map, since its jacobian is of interest. That is, I'm implicitly assuming the map alters some corresponding metric space. The latter clearly has no place in DomainSets.jl. (Or does it?)
Currently, there is no specific problem, but the two use-cases are incompatible and it may be good to keep the distinction in mind.

I think this needs to go hand in hand with broadcasting, and essentially the storing the map means a lazy broadcast. I think we could mirror the relationship between broadcast and BroadcastArray in LazyArrays.jl. That is, broadcast(+, 1:3, 1) returns 2:4 (and forgets the map) while BroadcastArray(+, 1:3, 1) is left “unmaterialised” and thereby remembers the map.
So I guess I’d rename MappedDomain to BroadcastDomain . Broadcasting is better than mapping since it’s more type stable, consider the arc:
BroadcastDomain(+, BroadcastDomain(exp, im*(0..1)), 2+im)

One issue is to support in we also need a maps inverse. Probably we could do this cleanly via a broadcastinv machinery.

Sounds sensible, it is a type of lazy domain. Most importantly, a user who is interested in retaining the map needs a safe way to store the map and the original domain. It is still somewhat fishy to do that in DomainSets itself, since it remains the case that as far as in is concerned 0..1 and BroadcastDomain( x->x^2, 0..1) are the same. If there is ever a package that has metric spaces, it should perhaps be in there.

I think this remains the largest open issue with DomainSets: to remove maps from the package itself, enable the use of various other packages that define maps, and to come up with a convenient interface for making mapped domains, for example using broadcast and lazy domains as outlined above.
The definition of a MappedDomain is already largely independent of what a map exactly is. Specific requirements for mapped domains are that ideally we know both the map and its inverse, and we want to support maps that are not fully invertible such as embeddings (i.e. a map from R to R2 to represent a line segment in the plane).


[PluginName] Issue: very short issue description

Describe the bug
The bug will display the typing indicator over the channel name several times instead of once.
To Reproduce
Steps to reproduce the behavior:

Have the plugin installed with show on channels enabled
Have another user start typing
The plugin will display the typing indicator more than once

Expected behavior
The typing indicator should display once.
Screenshots

Information (please complete the following information):

OS: Mac
Plugin Version: 0.5.4
Discord version: Stable
Compact Mode enabled? No

Additional context
None.

Reset fixed this. GitHub won't remove the draft I made so just closing it on my own.


Run benchmarks on CI

Motivation
Closes #335
Having the benchmark script added in #471 is nice, but we need to run the script regularly to get feedback on what's happening in terms of performance when we make changes. The ideal scenario is to get performance feedback directly on PRs.
Implementation
Added a new workflow to run benchmarks. The steps are

Restore the cached benchmark results from the main branch, which will be our point of comparison
Run the benchmark script. This will benchmark the code in the current PR and compare it with the results restore from cache. It will also always overwrite the results file, but that won't be saved in the cache for pull requests
The final step is to save the results file in the cache only once the commits are merged into main to update our baseline

References

GitHub actions context docs
Example workflow from actions/cache

Concerns
Not sure if this is the best way to cache results and compare. Any other ideas?

@KaanOzkan I'll look into how we can do that next.


ssheven 0.8.5 locks up on unsuccessful connection

If I attempt to ssh to a host that cannot be resolved (eg. is offline or incorrect hostname) the error "Connecting endpoint... OTConnect(ssh_con.endpoint, &sndCall, nil) failed" appears in the console. The program then immediately locks up and needs to be Force Quit using Cmd + Opt + Esc.
Using on an iMac G3 running Mac OS 9.2.2. Can't screenshot the above error as the system is unresponsive until ssheven is force quit anyway.
I am having no issues as long as the remote host being connected to responds.

thanks for the report, I've done a fix that will be in the next release

thanks for the report, I've done a fix that will be in the next release


All binary file opening must be protected with the CShareResource class

Run the 02_miniBlock program which builds the mini block database. While it's running, run the acctTree code. Both processes will hang and the data gets corrupted.

Moved to https://github.com/Great-Hill-Corporation/quickBlocks/issues/61


nomad_systemvinit.j2 issues

Hey Brian,
the nomad_sysvinit.j2 file is passing -pid-file "${PID_FILE}" which nomad doesn't seem to recognize, and I can't find that arg in any 0.5.6 docs.
Additionally, restart doesn't seem to work, but stop, sleep for some period, and start does.  I've seen this behavior in other procs like consul, and I'm not sure what's causing it.

Fixed in b0552c5


New major version with ESM

:tada: This PR is included in version 2.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket: