python3Packages.pg8000: 1.18.0 -> 1.19.0

Motivation for this change
Update to latest upstream release 1.19.0
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 117969 run on x86_64-linux 1

6 packages built:

python38Packages.pg8000
python38Packages.scramp
python38Packages.testing-postgresql
python39Packages.pg8000
python39Packages.scramp
python39Packages.testing-postgresql

Result of nixpkgs-review pr 117969 at 932cad8f run on aarch64-linux 1

6 packages built successfully:

python38Packages.pg8000
python38Packages.scramp
python38Packages.testing-postgresql
python39Packages.pg8000
python39Packages.scramp
python39Packages.testing-postgresql


Outdated

Can you please update the article to reflect the new Access Reviews UI and options. Lots has changed in two months :) I don't seem to have permissions to work with images over at GitHub in order to make the changes myself...

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

ID: b1dc21d8-8ebe-44fb-5b22-93d924829e73
Version Independent ID: 42cf0514-e903-7d9d-11f9-5c9adf1b1fc7
Content: Start an access review for Azure AD directory roles in PIM
Content Source: articles/active-directory/privileged-identity-management/pim-how-to-start-security-review.md
Service: active-directory
GitHub Login: @rolyon
Microsoft Alias: rolyon

@michevnew Thanks for your feedback! We will investigate and update as appropriate.

@michevnew I have assigned this to the content author @rolyon to look into your issue. If you would like to make any specific changes you can make a pull request and follow the shortcuts in this tutorial to add the images.

Hi @michevnew
Thanks for your feedback on this.

Hi @michevnew
Thanks for your feedback. We finally got this article updated.
https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-how-to-start-security-review

@MicrosoftDocs/azure-cxp-triage
#please-close


Don't show locked nodes in list tool for consistency

Alternative to #49302
The behavior of locked nodes showing up in list tool is inconsistent. Currently, list tool and alt+right click inside of 3D will allow you to see locked nodes in the list. In 2D, this only works for alt+right click, not list tool, and it also allows you to select locked nodes if it's the only thing you're hovering over, which is different from 3D.
This makes the behavior for 2D and 3D the same by making alt+right click & list tool in 2D and 3D not show locked nodes in list.
This also clarifies that locked nodes cannot be selected in the tooltip for the lock button.

This makes the behavior for 2D and 3D the same by making alt+right click & list tool in 2D and 3D not show locked nodes in list.

Uh, but Alt+Right click should show the locked nodes. They should be hidden only when using list too.

This makes the behavior for 2D and 3D the same by making alt+right click & list tool in 2D and 3D not show locked nodes in list.

Uh, but Alt+Right click should show the locked nodes. They should be hidden only when using list too.

It said they were the same. Should the tooltip be changed too? It could also clarify "list of unlocked nodes" instead of "list of all objects"

It could be "list of all selectable nodes"
I also noticed that selection tool tooltip mentions it in an odd way:
Alt+RMB: Depth list selection (depth list???)
It could be changed to
Alt+RMB: Show list of all nodes at position (including locked)

It could be "list of all selectable nodes"
I also noticed that selection tool tooltip mentions it in an odd way:
Alt+RMB: Depth list selection (depth list???)
It could be changed to
Alt+RMB: Show list of all nodes at position (including locked)
EDIT:

I think it's a bit confusing for one to allow selection and the other not to. If anything, the list tool should be the one that shows locked nodes through shift+click or something instead of the select tool through alt+right click. The select tool itself doesn't even have it's own keybind for forcibly selecting locked nodes, it seems odd the select tool's shortcut for list would.

This starts to spawn too much discussion. I think maybe you should open an issue about these tools. For me, the behavior is fine, but just needs the bugfix + tooltips could be clarified.

Alright, I've fixed the tooltips and behavior of alt+right click to show locked nodes.

Alright, I've fixed the conflicts & parameter's name

Thanks!


checklist: Get TTX diff matching for oswald

Once we get #806 merged, we'll be into the home strech of matching fontmake for oswald. This issue is intended to track the remaining sources of difference.
Diffs in the normalized markkern layout-normalizer output:

[ ] bigraphs: there is a difference in anchor propagation between fontmake & fontc for glyphs with multiple base components that are not ligatures. The best issue for this is https://github.com/googlefonts/glyphsLib/issues/368#issuecomment-2103445759. I believe cosimo has a fix ready for fontmake.
[ ] anchor propagation for marks: Anchor propagation behaviour differs between fontmake & fontc for some mark glyphs, which causes fontc to treat certain spacing non-combining marks in oswald as bases for the mark feature.  (#811)
[ ] marks for glyphs with no assigned unicode values: I don't fully understand this issue yet, but fontc is treating some glyphs as bases where fontmake is not; all of the glyphs in question have the property that they are not assigned a unicode value. This may be trivial. (#812)

Diffs in GPOS.ttx

[ ] there are various diffs here that were the original impetus for layout-normalizer: some lookups have different ids for instance, and delta indexes differ. I think long term we want to just use normalizer on this full table, and ignore it?

Diffs in GSUB.ttx

[ ] fontmake is generating an additional ccmp feature (two total), but this looks like a bug in fontmake, since the additional feature seems to be identical to the other one, except for a duplicate entry for one lookup?
[ ] various other differences similar to GPOS, where some ids are different. I think like with GPOS, the answer here is going to be to just improve layout-normalizer and ignore this table (#800)

Diffs in GDEF.ttx

[ ] missing the ligature caret table: (#809)
[ ] some differences in the GDEF categories; I'm not actually sure how we're generating these, it might be that we're sort of getting it by accident via fea-rs? Some of these differences are related to things like the different handling of digraphs, others will need a bit of investigation. (#805)
[ ] the ItemVariationStore differs significantly, but this is probably mostly the result of the GPOS diffs, where we have more deltas because we have more items/rules; we can revisit this after GPOS is matching.

Vigorous +1 to normalize GSUB and GPOS then ignore the raw ttx


Missing installation information for Linux hosts

Installation on my Debian system:
sudo aptitude install poppler-utils

hi @tbrowder - thanks for the feedback - it is not quite clear to me from your comment whether this is a gao in the docs or whether the module creates an error warning
please can you submit as a PR and I will accept"

well this works on my ubuntu with apt-get ... so I will document that


TypeError: Cannot set property 'innerHTML' of null

I installed all the dependencies with 'npm install' and then compiled the library with 'npm run compile'. The problem is that when I run it in my webpage, I get this error: "TypeError: Cannot set property 'innerHTML' of null". According to the console the error originates in:
document.querySelector(widgetId).innerHTML = null; //Line 483

@inakineitor It looks like the element referred to by widgetId can't be found.  Did you specify the selector for the element that should contain the sunburst chart when you instantiate PersonalitySunburstChart?  For example, if sunburstChart should contain the viz (), then you'd need to specify that when you create the chart:
var chart = new PersonalitySunburstChart({'selector': '#sunburstChart'});

Thank you, the problem was that the tutorial has not been updated and the new version uses a '#' before the selection name.


the path 'dataset/scannet' should be ‘dataset/scannetV2’

Please check the name, according to the 65th line of scannetv2_inst.py

Thanks for your issue. The path has been fixed.


Support websockets API

Is there any interest or progress towards adding support for interacting with the websocket API? I've been playing with the idea of implementing a WSClient, but don't want to duplicate efforts.

https://github.com/mtusman/gemini-python

Nice work


Error -32004: Transaction creation failed.

I implemented the started code to create a transaction and send one lamport. It worked for weeks but now it doesn't work on the Devnet or the Testnet. I am able to connect my wallet to my application and initiate the transaction but after I approve in Phantom I get this error:
Phantom - RPC Error: Transaction creation failed. {code: -32003, message: 'Transaction creation failed.'}
To reproduce implement the starter code and approve a transaction in Phantom.

Sorry, we don't handle dev support on Github. Please ask for help on Discord! Nothing has changed about the library or example code, so if it worked until now, it's likely that this is an issue with your project or the network.

@jordansexton I tried to join the Discord but the Anti-dupe Bot is kicking me "You have been kicked for using a duplicate username on the server, please change it before joinning again" so I am unable to join.


User defined validations

I would like to define my own validations like this:
class FooBarValidator
  include Lotus::Validations
  attr_accessor :foo

  validates :foo, :is_bar do |attribute|
    attribute.value == "bar"
  end
end

This pull request includes a first implementation and a integration test to illustrate the wanted behavior. Feedback welcome

Done

@kbredemeier Hello and thanks for this PR.
A block that yields only the attribute isn't enough. Sometimes you need values from other attributes (think of "password confirmation" case).
I like this syntax: validates :foo, with: BarValidator. The main problem of BarValidator.call is that it has to instantiate Error by hand. Which is error prone because of the amount of informations that it requires.
It's better to design a Lotus::Validator to mixin and make this job easier.

@kbredemeier @ianks That being said, would you folks love to contribute, think and code a solution for this? That would be AWESOME!! Ref #72

I like the idea too, IMO you have to worry about message error in your validator but not instantiate a class inside.

I will look into this. While I am doing this I would also like to extract the build-in validations from the Attribute class into separate validators. What about keeping the behavior with passing a block to validates method?

While I am doing this I would also like to extract the build-in validations from the Attribute class into separate validators.

I'm very much for this idea. It makes more sense to have them decoupled from the attribute class. I would just make sure to check that they are not significantly less performant.

What about keeping the behavior with passing a block to validates method?

In this case, would the validator check if something falsey is returned? If so, it would be nice to be able to specify an error message as well.

I think I am happy with the interface of the Validation module. I provided an usage example in the source. What do you think about it?

Looks good. The only thing I am not keen on is the add_error method. I think using a keyword arg for expected would be nice, so it is not ambiguous as to the meaning. Thoughts?

You are right. Passing the expected value as a keyword argument makes it much more expressive.

Hi guys, I'm experimenting with custom validations in an Hanami app and I'd like to share some thoughts of mine.
First a few general things on the code I will share:

I would rather not use the validator class name as the validation name. Convention over configuration makes sense when the configuration is defined in a different file using a different language, but Ruby allows us to define some minimalist, beautiful and more expressive DSLs that both configurations a conventions, so I would go for defining the validation name explicitly.
I would rather not use a DSL with conditionals. I think that putting conditional logic in a declarative DSL tends to get messy really soon. I would rather try to find an easy way to use blocks and invoke another validations from a validation, and then the conditional will be just a plain old Ruby script as simple or complex as we need
I would rather not change the binding to self in blocks

So, these all said, I've been playing with something like this to define custom validations for Hanami:
To declare custom validations we could use any of these:
validates :location, with: LocationValidator

# May be accept also an instance? That way we could parametrize validations, for instance
validates :location, with: RegexValidator.new(/.../, validation_name: :location_format)

validates :some_value, custom: :even_number do |validation|
   validation.add_error unless validation.actual_value.to_i % 2 == 0
end

Validator objects (such as LocationValidator and RegexValidator) and blocks should understand call(validation_context).
Here's an actual (partial) implementation that I'm playing with:
class LocationValidator
    include Validation

    validation_name :existent_location

    # Validating

    def validate()
        add_error unless is_location_valid?
    end

    # Asking

    def is_location_valid?()
        Google::Geocoding.query_address(actual_value).addresses_count == 1
    end
end

module Validation
    # Class methods

    def self.included(base_class)
        base_class.class_eval do
            extend ClassMethods
        end
    end

    module ClassMethods
        def validation_name(validation_name)
            @validation_name = validation_name
        end

        def get_validation_name()
            @validation_name
        end

        def validate(attributes, errors, attribute_name)
            self.new.call( ValidationContext.new(attributes, errors, attribute_name) )
        end
    end

    # Instance methods

    # Validating

    def call(validation_context)
        @validation_context = validation_context
        @validation_context.set_validation_name(self.class.get_validation_name) unless self.class.get_validation_name.nil?

        validate
    end

    def validate()
        raise 'Implementor class responsibility'
    end

    # Accessing

    def validation_context()
        @validation_context
    end

    def attributes()
        validation_context.attributes
    end

    def errors()
        validation_context.errors
    end

    def attribute_name()
        validation_context.attribute_name
    end

    def validation_name()
        validation_context.validation_name
    end

    def actual_value()
        validation_context.actual_value
    end

    def namespace()
        validation_context.namespace
    end

    # Adding errors

    def add_error(attribute_name: nil, validation_name: nil, expected_value: nil, actual_value: nil, namespace: nil)
        attribute_name = self.attribute_name if attribute_name.nil?
        validation_name = self.validation_name if validation_name.nil?
        expected_value = true if validation_name.nil?
        actual_value = self.actual_value if actual_value.nil?
        namespace = self.namespace if namespace.nil?

        add_error_for(
            attribute_name,
            validation_name: validation_name,
            expected_value: expected_value,
            actual_value: actual_value,
            namespace: namespace
        )
    end

    def add_error_for(attribute_name, validation_name: nil, expected_value: nil, actual_value: nil, namespace: nil)
        add_validation_error(
            Hanami::Validations::Error.new(
                attribute_name,
                validation_name,
                expected_value,
                actual_value,
                namespace
            )
        )
    end

    def add_validation_error(validation_error)
        errors.add(validation_error.attribute, validation_error)
    end

    # Running other validations

    # Run the validation named validation_name on the attribute named attribute_name
    def validate_attribute(attribute_name, with: validation_name)
        validation_context.validate_attribute(attribute_name, with: with)
    end

    # Answer whether there was an error from the validation named validation_name on an attribute
    def validated?(:validation_name, on: nil)
        validation_context.validated?(:validation_name, on: on)
    end
end

class ValidationContext
    # Initializing

    def initialize(attributes, errors, attribute_name = nil, validation_name = nil)
        @attributes = attributes
        @errors = errors
        @fully_qualified_attribute_name = attribute_name
        @validation_name = validation_name
    end

    # Accessing

    def attributes()
        @attributes
    end

    def errors()
        @errors
    end

    def fully_qualified_attribute_name()
        @fully_qualified_attribute_name
    end

    def set_validation_name(validation_name)
        @validation_name = validation_name
    end

    def validation_name()
        @validation_name
    end

    def attribute_name()
        fully_qualified_attribute_name.split('.')[-1]
    end

    def namespace()
        fully_qualified_attribute_name.split('.')[0..-2].join('.')
    end

    # Querying

    def actual_value()
        value_of(fully_qualified_attribute_name)
    end

    # Answer the value of the attribute named attribute_name
    def value_of(attribute_name)
        attribute_name.split('.').inject(attributes) { |value, accessor|
            value[accessor]
        }
    end

    # Running other validations

    # Run the validation named validation_name on the attribute named attribute_name
    def validate_attribute(attribute_name, with: validation_name)
        # ...
    end

    # Answer whether there was an error from the validation named validation_name on an attribute
    def validated?(:validation_name, on: nil)
        attribute_name = on.nil? : fully_qualified_attribute_name : on
        # ...
    end
end

Conditional validations can be handled like this:
validates :some_value, custom: :even_number do |validation|
   unless actual_value.nil?
      validation.add_error unless validation.actual_value.to_i % 2 == 0
   end
end

or it would be even better if we could invoke and ask the result of another validations:
class LocationValidator
    include Validation

    validation_name :existent_location

    # Validating

    def validate()
        return unless validated?(:presence)
        return unless validated?(:location_format)

        add_error unless is_location_valid?
    end

    # Asking

    def is_location_valid?()
        Google::Geocoding.query_address(actual_value).addresses_count == 1
    end
end

Any thoughts?

This feature was implemented by #100 https://github.com/hanami/validations#custom-predicates


Define a Clear Interface for Custom Homing Component and Integration with Pokeys

Issue: Define a Clear Interface for Custom Homing Component and Integration with Pokeys
Description:
A clear interface for the custom homing component pokeys_homecomp.comp needs to be defined. This will standardize the communication between the homing procedure and the PoKeys components, ensuring smooth operation in LinuxCNC. The separate HAL file pokeys_homing.hal should be created to define the linkage of pins from pokeys_homecomp.comp to the relevant PoKeys components.
Additionally, the following components must follow this newly defined interface:

pokeys.comp (userspace component)
pokeys_rt (realtime component)
pokeys_py (Python-based userspace)

Tasks:

Define pokeys_homecomp.comp Interface:

Establish the canonical structure for the custom homing component.
Ensure proper pin definitions for homing control, feedback, and status reporting.

Create pokeys_homing.hal:

Link the pins from pokeys_homecomp.comp to the appropriate PoKeys components.
Ensure proper connection to PoKeys digital IO, PEv2 axis homing signals, and feedback signals.

Update pokeys.comp (userspace):

Modify the userspace component to conform to the new homing interface.
Ensure that homing signals and status are handled properly.

Update pokeys_rt (realtime):

Adjust the realtime component to manage the custom homing interface.
Synchronize realtime homing behavior with the defined pokeys_homecomp.comp.

Update pokeys_py:

Implement the custom homing interface in the Python component.
Ensure that the Python script manages the homing signals correctly and adheres to the defined interface.

References:

pokeys_homecomp.comp
LinuxCNC HAL Documentation
PokeysLib
LinuxCNC Motion

Expected Outcome:
A standardized interface for the custom homing functionality that integrates seamlessly with the PoKeys family of components in LinuxCNC.
Branch Suggestion:

Branch Name: custom-homing-interface

Issue: Define a Clear Interface for Custom Homing Component and Integration with PoKeys
Task Description
A clear interface for the custom homing component pokeys_homecomp.comp should be defined to integrate homing functionality with the PoKeys hardware. The interface should cover the following areas:

Homing signal handling
Pin and parameter definitions following LinuxCNC canonical interfaces
Integration with userspace (pokeys.comp), real-time (pokeys_rt), and Python (pokeys_py) components.

The pokeys_homing.hal file should link the pins from pokeys_homecomp.comp to the corresponding PoKeys components.
Goals

Define a custom homing interface (pokeys_homecomp.comp) that can integrate seamlessly with PoKeys devices.
Ensure that pokeys.comp (userspace), pokeys_rt (realtime), and pokeys_py components follow the defined interface for handling homing signals and state.
Define the necessary HAL pins and parameters to reflect the homing state, switch inputs, and position feedback, according to the canonical LinuxCNC interface.

Restrictions to Consider
Userspace Components (pokeys.comp)

Latency Considerations: Userspace components are non-realtime and may introduce delays when handling homing signals.
Polling vs. Event-Driven: Avoid relying heavily on polling for homing state updates. Prefer event-driven signal handling where applicable.
Limited Realtime Access: Ensure status updates from homing are synchronized and reflected in userspace without requiring direct access to realtime hardware timers.

Realtime Components (pokeys_rt)

Strict Realtime Constraints: Homing should be handled with hard real-time constraints to ensure accurate, time-sensitive motor control.
Interrupt-Driven Behavior: Homing procedures should trigger based on interrupts from home or limit switches.
Deterministic Behavior: Ensure deterministic behavior in the homing sequence, especially during slow homing steps and position resets.

Python Components (pokeys_py)

Non-Realtime Nature: Python components cannot manage homing directly due to timing constraints. They should be used for high-level decision-making and monitoring.
Polling Frequency: Define an appropriate polling frequency to retrieve homing status updates, without relying on real-time execution.
State Synchronization: Python components should focus on relaying homing status to user interfaces or logging systems but should not control homing sequences directly.

General Interface Requirements

Pin and Parameter Definitions: Follow LinuxCNC canonical pin definitions, such as:

pokeys.[DevID].digin.[PinID].in
pokeys.[DevID].joint.[AxisID].homing
pokeys.[DevID].joint.[AxisID].pos-fb
pokeys.[DevID].joint.[AxisID].enable

Status Pins: Use status pins to reflect homing states:

pokeys.[DevID].PEv2.joint.[AxisID].homing
pokeys.[DevID].PEv2.joint.[AxisID].in-position

Mapping to Homing States: The PoKeys homing status (AxisState) should be mapped to the LinuxCNC joint and axis state pins.

PoKeys homing states:PK_PEAxisState_axHOMINGSTART  = 11
PK_PEAxisState_axHOMINGSEARCH = 12
PK_PEAxisState_axHOMINGBACK   = 13
PK_PEAxisState_axHOME         = 10

Corresponding HAL pins for the above states:joint.[N].homing
joint.[N].pos-fb
joint.[N].amp-enable-out

Error Reporting: Define error handling pins to reflect any homing errors or limit switch trips during the process:
pokeys.[DevID].joint.[AxisID].error
pokeys.[DevID].joint.[AxisID].homing-error

pokeys.comp not yet updated


Submission for team 1

this is not easy to review
there are many commits and there is no common history with the repo.
squash all the commits and rebase on top of the master branch in the repo so the request is reviewable.
checkout the other pull request from the other team to see.

New submission is at: https://github.com/nyuoss/mAIgic-nyu/pull/3


fix email link

fixed email link pointing to 404.

@kailash-manasarovar can you merge this PR? The email links in the footer were pointing to 404, got it fixed.


No null check present for SD card configuration component in visitDataSendAction for sensebox

Describe the bug

if send data to SD card is used without a corresponding configuration block an exception is thrown

To Reproduce
Steps to reproduce the behavior:

use send data to SD card block with no configuration block and see server error message

Expected behavior

an error popup message should be put on the block as for openSenseMap

User gets a suitable error message when used without configuration block.


Participant types and privileges

Question
Can we identify participants with special types like presenters and observers, and use this identification to restrict or grant permissions. For example: prevent participants from sharing their screen or unmuting themselves without the presenter granting it.
Additional context
We have adopted Twilio as our service provider for video integration but i'm unsure about how much we can do with this app or if we will need to build out our own JS app to support some of the features were hoping to have. Our use case is similar to that of a teacher to students. Where there will be a participant on the call who is the organizer and we would like to give this participant total control of what goes on in the room.

Hi @mattrothstein - thanks for the question!
This is a good question! Unfortunately, this app is built to serve a simple collaboration use case. This app doesn't have any concept of participant types, roles, or permissions. Every user is the same. Any user can share their screen, send a message in chat, or start a recording. So to answer your question, this app won't be able to accommodate a student/teacher use case out of the box.
Just for some context, this app is designed to be a few things:

It is meant to be a reference application, so developers can look at the code to learn how to implement features in their own apps.

It's meant to demonstrate the various features of the Twilio Video platform. We want developers to be able to launch this app quickly to see what the Twilio Video platform offers.

And it's meant to provide developers with a good starting point for their applications. Instead of building a video app completely from scratch, developers can get a head start by forking this app. Then, they can apply their own features and customizations to meet their use case. If you look through the apps forks or network graph, you may come across some interesting variations on this app.

Point being, I still think that this app could be helpful to you. While you would need to modify the app to meet your use case, I think that it could give you a rather good starting position to do so. I hope that it would be easier than building an app from scratch. You could even maintain two forks of this app - one for a 'teacher' version, and one for a 'student' version. I think there's some good potential here.
Anyway, I hope that helps! Please let me know if you have any other questions. I'm happy to help brainstorm implementation ideas, so don't be afraid to reach out.


When using the quote crate why I need the proc_macro2 crate even when I am on nightly ?

The libproc_macro data structures are not consistently available on nightly. You can compile code against it, but if used from a build.rs or binary crate every function call will panic. The proc_macro2 crate makes the same API available consistently across use cases.

Thank you Sir.
Will this :: https://doc.rust-lang.org/proc_macro/fn.quote.html
be compatible with the quote crate in the future ?

I don't know what the plan is for that macro. It is not actively being worked on. The input syntax is different from the macro in this crate.


OCPBUGS-19014: Apply private-router network policy only if running OCP 4.14

What this PR does / why we need it:
Removes the private-router network policy if OCP < 4.14 because it
prevents access to the ignition-server-proxy which doesn't have a
request-serving label in OCP < 4.14
Which issue(s) this PR fixes (optional, use fixes #<issue_number>(, fixes #<issue_number>, ...) format, where issue_number might be a GitHub issue, or a Jira story:
Fixes #OCPBUGS-19014
Checklist

[x] Subject and description added to both, commit and PR.
[x] Relevant issues have been referenced.

/hold

/lgtm

/lgtm

/test e2e-aws

/override ci/prow/arm64-images

In case we want to run from 4.14. branch
/cherry-pick release-4.14


Skip buffer when its already open in another split.

Is there a way to do this?

You mean instead of highlighting it?

ahh sorry, I wanted :bnext to behave in a way where if the buffer is already open in another pane, it will skip that buffer then go to the next one. Then I realized that this plugin does not handle those kind of things sorry for asking.

Ah. Yes, that’s outside the purview of this plugin. And no biggie.
This is actually something I wanted myself, though. So I wrote myself a small plugin that does just that. I’d like to release that if I ever figure out a proper shape for it, but I haven’t found that so far. What’s there works for me, though, and maybe it can be a starting point for you.

This is exactly what I was looking for! Thanks @ap!!!


Idea: check for Pod containerPort for every ServicePort

Enhancement idea:
See https://github.com/istio/istio/issues/15633
I spent four hours before understanding the problem of missing containerPort on a Service.  istio-vet does not detect it.

Thanks @esnible for filing this enhancement. This makes sense to add as if you don't specify container ports the proxy interception will not happen.


Static route management isn't idempotent

Hello,
I'm trying to create a playbook to manage our static routes (and we have appliances with many of them). First of all, the roles that exists allow only to add or update route, which is a bit contradictory towards the principle of idempotency, I would expect add and update to be actually merged in a single function.
Secondly, using only the add method seems to not doing anything when Force = False. Let's take the following inventory host.yml variables:
`
routes:
  - add_static_route_address: 'default'
    # Override the rest as needed
    add_static_route_enabled: True
    #add_static_route_maskOrPrefix: null
    add_static_route_gateway: '<IP_ADDRESS>'
    add_static_route_label: '1.1'
    #add_static_route_vlanId: null
    add_static_route_metric: 4
    add_static_route_comment: 'This is a test'
    add_static_route_table: 'main'
  - add_static_route_address: 'default'
    # Override the rest as needed
    add_static_route_enabled: True
    #add_static_route_maskOrPrefix: null
    add_static_route_gateway: '<IP_ADDRESS>'
    add_static_route_label: '1.1'
    #add_static_route_vlanId: null
    add_static_route_metric: 1
    #add_static_route_comment: ''
    add_static_route_table: 'main'

And the following playbook:
`
---

- name: "Set Static routes configuration"
  gather_facts: no
  hosts: "all"
  connection: local

  roles:
    - role: start_config
  post_tasks:
    - name: Set static routes configuration
      isam:
        appliance: "{{ inventory_hostname }}"
        username:  "{{ username }}"
        password:  "{{ password }}"
        lmi_port:  "{{ lmi_port | default(omit) }}"
        log:       "{{ log_level | default(omit) }}"
        force:     "{{ force }}"
        action: "ibmsecurity.isam.base.network.static_routes.add"
        isamapi:
          address:       "{{ item.add_static_route_address }}"
          enabled:       "{{ item.add_static_route_enabled | default(True) }}"
          #interfaceUUID: "{{ item.add_static_route_interfaceUUID | default('') }}"
          maskOrPrefix:  "{{ item.add_static_route_maskOrPrefix | default(omit) }}"
          gateway:       "{{ item.add_static_route_gateway | default('') }}"
          label:         "{{ item.add_static_route_label | default('') }}"
          vlanId:        "{{ item.add_static_route_vlanId | default(omit) }}"
          metric:        "{{ item.add_static_route_metric | default(0) }}"
          comment:       "{{ item.add_static_route_comment | default('') }}"
          table:         "{{ item.add_static_route_table | default('main') }}"
      loop:  "{{ routes }}"
      loop_control:
        label: "Processing route {{ item.add_static_route_address }} and gateway {{ item.add_static_route_gateway }} in table {{ item.add_static_route_table }}"
      notify: Commit Changes

Ansible is well looping through the routes but nothing is pushed towards the appliance. When I'm reading the code https://github.com/IBM-Security/ibmsecurity/blob/e3dd3f930bcd9f151e30eff0a394c50f98d3eccb/ibmsecurity/isam/base/network/static_routes.py, I would expect that:

The first route being a new one should be added
The second route being already configured, it should be ignored

Switching the flag "Force" to True will actually create both of them.
Do you confirm this is a feature to be ? :)
Regards,
Cédric Servais

Answer to myself, use the method SET instead of ADD or UPDATE.


Periodic freeze of sensor updates

Periodically (somewhere between 20-40 minutes) the updates just freeze/stop to HA.  A restart to the container and things return to normal for another 20-40 minutes.  The container typically continues to run, and there are no errors in the logs.  I ran with debug on and did not see anything that looked like it would cause a problem.  And in fact, the logs continue to show processing updates.  However, watching the traffic from MQTT explorer, no data was being published to HomeAssistant.
Then I noticed something odd in the Station Status data.  It changed from Reset Flags: BOR,PIN,POR to Reset Flags: PIN,SFT,HRDFLT.  The API does not address "HRDFLT" but have to guess that is hardware fault.  The hub reboots, and things appear to continue, but from the MQTT and HA side nothing is happening.
Not sure what is causing the HRDFLT.  I am going to monitor for a while without anything running to see if it is just a failure in the HW.
Anyway, sorry I can't give you more to go on.  But if you have some troubleshooting steps you would like me to run, certainly happy to do so.

Hi,
Thanks for reporting this, I will wait for you to report back, when you have got it back to the iot VLAN. I am honestly not a network guru, so I am not exactly sure how UDP traffic routes over VLANs, but I hope you figure it out, and maybe even put a description in here. Then I can link to it for others with the same issue.
Once you are up and running, let me know if you still get errors.
Btw. I have tried a few times to remove the power from my HUB to actually test for the "reboot" scenario, and I don't have any issues with it. All the program does is just sit there and listens to the data coming in on port 50222, so when nothing comes - nothing happens, but as soon as data is coming again, it will be reported.

Ok, can confirm this was related to the wifi configuration.  It stayed up overnight and continues to provide updates.  So now onto sensor discovery.

Just a FYI.  I had been running without incident until this morning when the docker container stopped unexpectedly and subsequently automatically restarted.  Everything just picked up where it left off.  I wouldn't have noticed if not for the notification on my Synology box where docker lives.  I found this in the log right before the restart:

Great we. got a real error 😛 It seems the Station Pressure did not deliver a number, so the Sea Leavel. Conversion function fails. I will add checks for this in all conversion functions, to ensure it does not fail. It will then just return a 0.
An error like this, might also be the reason for the missing sensors.
I think I can have it done within a day, and will then create a new Docker Container.


Added automatically set data to next week

Description

Fixes #31
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Checklist

[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings

@alanyee Removed the line.

@alanyee can you label thia as hacktoberfest-accepted


Ballerina parser drop extra positional arguments from SyntaxTree

Description:
When there are more than two positional arguments provided to error constructor arguments after first 2 are dropped.
Also add type-checking logic for those extra arguments.
https://github.com/ballerina-platform/ballerina-lang/pull/29059/files/781a817288212b1d417d806a7c8fb8cd354879b0#diff-f4fbb6e8ffab357b74e188781ad3f6e3235f8e48b64fba8dfb6ad72bf9ccaf93R2837
Steps to reproduce:
Affected Versions:
OS, DB, other environment details and versions:
Related Issues (optional):

Suggested Labels (optional):

Suggested Assignees (optional):

@rdhananjaya as per the spec, error-arg-list := positional-arg [, positional-arg] (, named-arg)*; maximum of two positional-args are allowed right?. So we perform validation on top of parsed positional arguments at the parser. If there are additional ones we mark them as invalid.

I far as I see we can't just drop user provided construct just because grammar doesn't match it.
error e = error("hi", error("hi"), 1 + "s");
In this case we should also display diagnostics for 1 + "s"

I far as I see we can't just drop user provided construct just because grammar doesn't match it.
error e = error("hi", error("hi"), 1 + "s");
In this case we should also display diagnostics for 1 + "s"

Ok. we can log the parser error and add the arg to the list.


Jenkins User / Password

Hi!
I have started via virtualbox.
Jenkins ask for user and password, I did not find this information in the documentation here?
Kind regards
Torsten

Huh weird... I thought it would install without a password. Anyways, I explicitly disabled the security check, for now. Do a git pull for the update.

Unfortunatly no change. I test this local on windows with Virtualbox.

Ok, yes, the security changes to disable login did not also include changes to allow running scripts. I'll fix this over the weekend. Thanks for the info! :)


程序运行问题

运行train.py文件，运行过程中出现以下内容，程序没有办法往下走，请问这是什么原因造成的？

Hello,
The reason is that the program tried to run the code in the "try" block but failed, so it stopped at the Pdb checkpoint in the "except" block. Please check if the numbers of the two variables are equal.

Thank you so much for answering my question on your busy schedule!
| |
张盼
|
|
@.***
|
---- 回复的原邮件 ----
| 发件人 | Xiaohui @.> |
| 发送日期 | 2024年6月21日 17:05 |
| 收件人 | @.> |
| 抄送人 | @.>,
@.> |
| 主题 | Re: [Cecile-hi/Regularized-Adaptive-Weight-Modification] 程序运行问题 (Issue #2) |
Hello,
The reason is that the program tried to run the code in the "try" block but failed, so it stopped at the Pdb checkpoint in the "except" block. Please check if the numbers of the two variables are equal.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>


Updated the installation instructions

Instead of editing the composer.json file manually, the require command is the new recommended way to install bundles.
In addition, in recent Composer versions, when you don't specify the dependency version, it installs the latest available stable version, so the command can be simplified.

closing becuase I merged your PR #267 which contains all these changes and many others


List SLP token by id.

Pull Request Test Coverage Report for Build 321

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 68.265%

Totals

Change from base Build 315:
0.0%

Covered Lines:
729

Relevant Lines:
1041

💛  - Coveralls

:tada: This PR is included in version 1.0.0 :tada:
Your semantic-release bot :package::rocket:


Bundle with tsup and replace babel-jest

Original PR: https://github.com/storybookjs/test-runner/pull/224 by @bryanjtc 👏
Bundles code and some dependencies with tsup.
Replaces babel-jest with @swc/core. With swc tests should run faster than using babel.
Adds require.resolve for jest-junit and jest-serializer-html.
Adds support for esm only projects that don't use a custom config file.
Tested locally using test-storybook:ci commands and some projects that I have with storybook and test-runner.

📦 Published PR as canary version: 0.9.5--canary.250.4891420.0

:sparkles: Test out this PR locally via:
npm install<EMAIL_ADDRESS># or
yarn add<EMAIL_ADDRESS>

Codecov Report
Base: 75.86% // Head: 76.13% // Increases project coverage by +0.27% :tada:

Coverage data is based on head (a561b1d) compared to base (942a3cc).
Patch coverage: 77.77% of modified lines in pull request are covered.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##             next     #250      +/-   ##
==========================================
+ Coverage   75.86%   76.13%   +0.27%
==========================================
  Files          11       11
  Lines         174      176       +2
  Branches       36       36
==========================================
+ Hits          132      134       +2
  Misses         42       42

Impacted Files
Coverage Δ

src/csf/transformCsf.ts
84.61% <ø> (ø)

src/util/getCliOptions.ts
60.00% <71.42%> (+4.44%)
:arrow_up:

src/playwright/transformPlaywrightJson.ts
94.28% <100.00%> (ø)

src/util/getParsedCliOptions.ts
5.88% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

Update on this?

@yannbf What are the next steps for this pr now that storybook v7 is released? I can separate the pr for better testing.

@yannbf let's look at this together, and merge/release it today if we can?

Hey there! Thanks a lot for your patience, I truly appreciate it.
Sorry I'm on vacation and will be back next Tuesday. Now that v7 is released, we can get this ready to merge into next so we can try it out in a new release. If you want to go to town with it @ndelangen feel free (but make sure test this well), else we can do it when I'm back
A couple of things:

For some reason, the @storybook/preview-api dependency got removed and @storybook/store got added. That seems to be incorrect
Would it be possible to use the tsup-node binary instead of tsup? The end result in dist is 10000% more friendly when not prebundling the dependencies, like a 600 loc vs 48000 loc.  Do we really need to prebundle the dependencies?
Are we sure about the implications of babel-jest with swc? Is it a 100% compatible change? Else this means a breaking change

I can move the dev dependencies that are being prebundled to dependencies. Tsup doesn't bundle dependencies. Replacing babel-jest with swc shouldn't be a breaking change. Swc jest is designed to be a drop-in replacement.

@yannbf Fixed everything. I also disabled code splitting, minification, treeshake and bundle in the tsup config. It should be easier to read and modify.

This is looking amazing, thank you once again @bryanjtc !! <3 <3


The worst-case time complexity of parallel::sort seems to be O(N^2).

Currently, the worst-case time complexity of parallel::sort seems to be O(N^2).
https://github.com/STEllAR-GROUP/hpx/blob/d55dc1b220b6ba78a715a38779180f995b632ae2/hpx/parallel/algorithms/sort.hpp#L80-L89
https://github.com/STEllAR-GROUP/hpx/blob/d55dc1b220b6ba78a715a38779180f995b632ae2/hpx/parallel/algorithms/sort.hpp#L95-L97
Surely, due to the two code blocks above, the possibility is very rare.
But, theoretically it still seems to be able to be O(N^2) in the worst-case.
Normally, for ensuring O(NlogN), switch algorithm to heap sort when recursion depth is higher than specific threshold.
If we want to ensure O(NlogN), we should modify Line 80 to
if (std::size_t(N) <= sort_limit_per_task || depth > recursion_depth_limit)

But, I'm afraid of performance change from those modifications.
I want to hear your thoughts about this.

@biddisco @hkaiser Because at first this algorithm was developed by you, I want to hear your thoughts.

@taeguk thhe algorithm was developed by Francisco (@fjtapia). John and I have just adapted it to HPX.

@taeguk - Tell me what are the rare circumstances where
std::size_t(N) <= sort_limit_per_task
could be false, but
depth > recursion_depth_limit
could be true?
Since the list is subdivided  on each recursion - surely the list will always get shorted (by roughly 1/2) - are you implying that there are cases where the list might be split om recursion, but by some factor that is way off 1/2 - and (say) only one element goes to one half of the tree and N-1 go to the other?
If that is the case, then yes, changing the switchover point by adding the recursion depth would help.

and (say) only one element goes to one half of the tree and N-1 go to the other?
If that is the case, then yes, changing the switchover point by adding the recursion depth would help.

@biddisco Yes, I implied that case. For ensuring time complexity to O(N*logN) , we should limit recursion depth. But, what I care is performance change from those limitation. As you think, is there possibility that performance will be decreased because of those limitation?
What should we do? Leave current parallel::sort ? Or Limit recursion depth for ensuring time complexity?

My suggestion would be to run the algorithm over a bunch of tests datasets and see if the recursion depth ever significantly exceeds the nominal threshold required for NlogN behaviour. If it happens frequently - then yes, add a limit. In my on tests I have not yet encountered problems of that kind (that doesn't mean it can't happen though).

Alternatively - add the extra check and verify that normal tests don't run any more slowly.

Hi,
I am reading the code of parallel_sort, and have a worst case of O(N²).
The way to prevent this is adding a counter with the number of subdivisions
in the algorithm. In each division, decrement the counter , and when zero,
sort with introsort.
Introsort have this counter, and begin to filter and divide with quicksort,
and when zero, switch to heapsort, which have a worst case of O(NLogN), but
is slower than quicksort.
Two years ago, when I wrote the code of sorting, only a few lines was used,
in the actual SW of HPX.
But the smart mindset is looking for the solution. The solution exist since
a year ago, as know John Biddiscombe. In my repository
https://github.com/fjtapia/HPX_sort you can find the code of all sorting
algorithms, and the documentation about it. The same code had been approved
recently in the Boost library.

single thread sort : introsort, with heap sort when the deep counter
is 0
parallel sort : internally block_indirect_sort. Parallel unstable
sort, very fast with very low additional memory
single thread stable_sort : internally spinsort
parallel stable_sort : internally parallel_stable_sort, based on
samplesort, using a half of the additional memory of samplesort
samplesort : parallel stable sort algorithms

For to use, add #include <hpx/parallel/sort/sort.hpp>
This version of paralle sort have a worst case of O(NLogN), and resolve
minor problems of previous versions. I had been testing this night, before
to show you
The benchmark of these algorithms you can find in the attached file to this
message. The parallel sort is notoriously faster than Intel Threading
Building Blocks
Other solution is change the actual code and add a subdivision counter. In
the file include/hpx/parallel/sort/detail/bis/parallel_sort.hpp you can see
an easy and clear implementation of the subdivision counter.
If you are interested in use my code, I would like if someone help me in
the development and optimization of the algorithm.
In the actual algorithms, I need threads which use thread local memory ,
previously initialized. But this feature is not in the C++ standard. Due
this, the implementation create threads, and store the works in a stack,
where the threads insert and extract the works, until it is empty.
This model run well in a machine where all the threads share the memory,
but I am not sure of their response in a group of machines, linked by a
network. If someone can run several benchmarks in a HPX with a small number
of machines connected by a network, can be very useful.
I would like, too, know internal details of HPX. When you run a new thread,
have any priority for to use the thread which create it? This can be
important to minimize the traffic of data between machines and improve the
cache performance.
Sometimes , I feel blind, as in the previous version of the algorithms,
where, trying to do with HPX threads, generate a pool of initialized
buffers in an atomic queue, and the threads, when start, extract one from
it. There was the same number of threads than buffers. But sometimes some
threads make more than 1000 attempts. In a single machine, the performance
is about 10% slower, but running in a group of machines , the performance
was around 50%, as said me John Biddiscombe.
If there is not interest in my code, please, say me , and I will put aside,
and will be only an admirer of the project, and clap your work
Yours
Francisco Tapia
2017-08-17 13:52 GMT+02:00 John Biddiscombe<EMAIL_ADDRESS>
Alternatively - add the extra check and verify that normal tests don't run
any more slowly.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/STEllAR-GROUP/hpx/issues/2836#issuecomment-323049155,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADrumPAKbVzgxCyzyyD3NHss8rHrEzbhks5sZClmgaJpZM4O4dyA
.

**         H P X : : P A R A L L E L : : S O R T              **

**                   B E N C H M A R K                        **

Arquitectura:          x86_64
modo(s) de operación de las CPUs:32-bit, 64-bit
Orden de bytes:        Little Endian
CPU(s):                12
On-line CPU(s) list:   0-11
Hilo(s) de procesamiento por núcleo:2
Núcleo(s) por «socket»:6
Socket(s):             1
Modo(s) NUMA:          1
ID de fabricante:      GenuineIntel
Familia de CPU:        6
Modelo:                63
Model name:            Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz
Revisión:             2
CPU MHz:               1397.625
CPU max MHz:           3600,0000
CPU min MHz:           1200,0000
BogoMIPS:              6600.02
Virtualización:       VT-x
Caché L1d:            32K
Caché L1i:            32K
Caché L2:             256K
Caché L3:             15360K
NUMA node0 CPU(s):     0-11
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm intel_ppin tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc dtherm ida arat pln pts
100000000 uint64_t elements already sorted
GCC std::sort                : 2.65679 secs
HPX sort                     : 0.0856454 secs
GCC std::stable_sort         : 5.24768 secs
HPX  stable_sort             : 0.0713636 secs
TBB parallel_sort            : 0.0458935 secs
HPX parallel_sort            : 0.0876892 secs
TBB parallel stable sort     : 0.670789 secs
HPX parallel stable sort     : 0.066981 secs
HPX sample sort              : 0.0838082 secs
100000000 uint64_t elements randomly filled
GCC std::sort                : 9.27454 secs
HPX sort                     : 8.63995 secs
GCC std::stable_sort         : 8.94908 secs
HPX  stable_sort             : 9.06915 secs
TBB parallel_sort            : 1.8426 secs
HPX parallel_sort            : 1.10332 secs
TBB parallel stable sort     : 2.25538 secs
HPX parallel stable sort     : 2.0783 secs
HPX sample sort              : 2.02486 secs
10000000 strings randomly filled
GCC std::sort                : 7.55374 secs
HPX sort                     : 8.04349 secs
GCC std::stable_sort         : 13.5451 secs
HPX  stable_sort             : 9.32374 secs
TBB parallel_sort            : 2.172 secs
HPX parallel_sort            : 1.37218 secs
TBB parallel stable sort     : 2.46657 secs
HPX parallel stable sort     : 3.15335 secs
HPX sample sort              : 2.4512 secs
================================================================
=                OBJECT COMPARISON                             =
=              ---------------------                           =
=                                                              =
= The objects are arrays of 64 bits numbers                    =
= They are compared in two ways :                              =
=    (H) Heavy : The comparison is the sum of all the numbers  =
=                of the array                                  =
=    (L) Light : The comparison is with the first element of   =
=                the array, as a key                           =
=                                                              =
100000000 elements of size 8 randomly filled
H E A V Y   C O M P A R I S O N
GCC std::sort                : 9.24636 secs
HPX sort                     : 9.04937 secs
GCC std::stable_sort         : 10.9146 secs
HPX  stable_sort             : 9.34338 secs
TBB parallel_sort            : 1.83879 secs
HPX parallel_sort            : 1.17504 secs
TBB parallel stable sort     : 2.35981 secs
HPX parallel stable sort     : 2.54364 secs
HPX sample sort              : 2.07547 secs
L I G H T   C O M P A R I S O N
GCC std::sort                : 9.61008 secs
HPX sort                     : 9.24874 secs
GCC std::stable_sort         : 11.2254 secs
HPX  stable_sort             : 9.33069 secs
TBB parallel_sort            : 1.89402 secs
HPX parallel_sort            : 1.5102 secs
TBB parallel stable sort     : 2.2112 secs
HPX parallel stable sort     : 2.54365 secs
HPX sample sort              : 2.0241 secs
50000000 elements of size 16 randomly filled
H E A V Y   C O M P A R I S O N
GCC std::sort                : 5.09317 secs
HPX sort                     : 4.8348 secs
GCC std::stable_sort         : 6.1044 secs
HPX  stable_sort             : 5.6755 secs
TBB parallel_sort            : 1.04078 secs
HPX parallel_sort            : 0.696541 secs
TBB parallel stable sort     : 1.45137 secs
HPX parallel stable sort     : 1.53507 secs
HPX sample sort              : 1.34131 secs
L I G H T   C O M P A R I S O N
GCC std::sort                : 5.04977 secs
HPX sort                     : 4.76086 secs
GCC std::stable_sort         : 5.80362 secs
HPX  stable_sort             : 5.05566 secs
TBB parallel_sort            : 0.963915 secs
HPX parallel_sort            : 0.653442 secs
TBB parallel stable sort     : 1.34845 secs
HPX parallel stable sort     : 1.31352 secs
HPX sample sort              : 1.20746 secs
25000000 elements of size 32 randomly filled
H E A V Y   C O M P A R I S O N
GCC std::sort                : 3.15829 secs
HPX sort                     : 2.95424 secs
GCC std::stable_sort         : 4.0104 secs
HPX  stable_sort             : 3.3834 secs
TBB parallel_sort            : 0.615975 secs
HPX parallel_sort            : 0.697791 secs
TBB parallel stable sort     : 0.962468 secs
HPX parallel stable sort     : 1.07537 secs
HPX sample sort              : 0.891413 secs
L I G H T   C O M P A R I S O N
GCC std::sort                : 2.85442 secs
HPX sort                     : 2.61642 secs
GCC std::stable_sort         : 3.58202 secs
HPX  stable_sort             : 2.82125 secs
TBB parallel_sort            : 0.645143 secs
HPX parallel_sort            : 0.48376 secs
TBB parallel stable sort     : 0.919681 secs
HPX parallel stable sort     : 0.925216 secs
HPX sample sort              : 0.776533 secs
12500000 elements of size 64 randomly filled
H E A V Y   C O M P A R I S O N
GCC std::sort                : 2.47338 secs
HPX sort                     : 2.21567 secs
GCC std::stable_sort         : 3.28297 secs
HPX  stable_sort             : 2.74118 secs
TBB parallel_sort            : 0.589234 secs
HPX parallel_sort            : 0.465219 secs
TBB parallel stable sort     : 0.901908 secs
HPX parallel stable sort     : 0.914365 secs
HPX sample sort              : 0.772351 secs
L I G H T   C O M P A R I S O N
GCC std::sort                : 1.77783 secs
HPX sort                     : 1.67127 secs
GCC std::stable_sort         : 2.81426 secs
HPX  stable_sort             : 2.17918 secs
TBB parallel_sort            : 0.482603 secs
HPX parallel_sort            : 0.418259 secs
TBB parallel stable sort     : 0.792557 secs
HPX parallel stable sort     : 0.802242 secs
HPX sample sort              : 0.689103 secs
6250000 elements of size 128 randomly filled
H E A V Y   C O M P A R I S O N
GCC std::sort                : 2.09116 secs
HPX sort                     : 1.84758 secs
GCC std::stable_sort         : 2.86589 secs
HPX  stable_sort             : 2.27605 secs
TBB parallel_sort            : 0.518487 secs
HPX parallel_sort            : 0.434963 secs
TBB parallel stable sort     : 0.839052 secs
HPX parallel stable sort     : 0.853302 secs
HPX sample sort              : 0.745378 secs
L I G H T   C O M P A R I S O N
GCC std::sort                : 1.47552 secs
HPX sort                     : 1.41978 secs
GCC std::stable_sort         : 2.64545 secs
HPX  stable_sort             : 1.84815 secs
TBB parallel_sort            : 0.471656 secs
HPX parallel_sort            : 0.404039 secs
TBB parallel stable sort     : 0.739945 secs
HPX parallel stable sort     : 0.776035 secs
HPX sample sort              : 0.705195 secs
3125000 elements of size 256 randomly filled
H E A V Y   C O M P A R I S O N
GCC std::sort                : 2.09095 secs
HPX sort                     : 2.09735 secs
GCC std::stable_sort         : 2.85211 secs
HPX  stable_sort             : 2.44499 secs
TBB parallel_sort            : 0.567121 secs
HPX parallel_sort            : 0.472408 secs
TBB parallel stable sort     : 0.834263 secs
HPX parallel stable sort     : 0.900596 secs
HPX sample sort              : 0.780577 secs
L I G H T   C O M P A R I S O N
GCC std::sort                : 1.72776 secs
HPX sort                     : 1.74781 secs
GCC std::stable_sort         : 2.49251 secs
HPX  stable_sort             : 1.99043 secs
TBB parallel_sort            : 0.447485 secs
HPX parallel_sort            : 0.446629 secs
TBB parallel stable sort     : 0.773182 secs
HPX parallel stable sort     : 0.810118 secs
HPX sample sort              : 0.689863 secs
1562500 elements of size 512 randomly filled
H E A V Y   C O M P A R I S O N
GCC std::sort                : 2.67612 secs
HPX sort                     : 2.62147 secs
GCC std::stable_sort         : 2.99261 secs
HPX  stable_sort             : 2.66403 secs
TBB parallel_sort            : 0.616895 secs
HPX parallel_sort            : 0.561857 secs
TBB parallel stable sort     : 0.859935 secs
HPX parallel stable sort     : 0.997386 secs
HPX sample sort              : 0.779245 secs
L I G H T   C O M P A R I S O N
GCC std::sort                : 1.55995 secs
HPX sort                     : 1.52954 secs
GCC std::stable_sort         : 2.43486 secs
HPX  stable_sort             : 1.87303 secs
TBB parallel_sort            : 0.453259 secs
HPX parallel_sort            : 0.430468 secs
TBB parallel stable sort     : 0.759556 secs
HPX parallel stable sort     : 0.779795 secs
HPX sample sort              : 0.631015 secs

@fjtapia Thank you for your reply and sorry to my late response.
I read https://github.com/fjtapia/HPX_sort/blob/master/block_indirect_sort_en.pdf. Your idea looks so awesome!
I want to consider your better parallel sorting algorithms for resolving this issue and getting better performance. But, maybe I should re-implement your implementation with HPX-tic way.
But, before I consider your idea, I have to ask you for you. Can I use your idea for HPX?

Hi Taeguk,
Thanks by your interest and your comments.
The problem of the worst case O(N²), is resolved . I sent the modified file
to Hartmut Kaiser some weeks ago. If you want take a look is the first
attached file to this message.
About the substitution of the actual code by block_indirect_sort, it’s not
so easy as appear.
First, must be interest in the change, and if exist, there is a long way
and a hard work for to do.
Block_indirect_sort use threads which reuse initialized memory. This memory
is initialized and destroyed only one time , and reuse many times. The C++
standard don’t support it. Due this, we implement our thread pool with
reused memory.
In a thread pool, when you throw a new thread, the function to execute and
the parameters are encapsulated and stored until a thread of the pool is
free, and then run the encapsulate information until finish and pass to be
a free thread.
In the thread pool of block indirect sort, when create the HPX threads of
the pool, initialize the buffers of memory, with a free state. Then each
thread execute the encapsulate information stored . The main difference is
that encapsulate information can access to the buffer create in the
initialization. When the HPX thread of the pool is destroyed, destroy too
the buffer.
The idea of to do using the thread pool, present several problems and
several alternatives.
A year and half ago, I did an implementation whith a pool of initialized
buffers, and each thread, when start, take a buffer of the pool, and when
finish return the buffer to the pool. There was the same number of buffers
and threads. I don’t know the internal mechanism of creation of threads in
HPX, but some threads need more than 1000 attempts for to obtain a buffer.
This, running in a single machine, had a penalty around 10% of the previous
version. But when John Biddiscombe ran over a network of machines, the
penalty was greater than the 40%.
If exist interest in the change, I have in mind have a version, where each
thread , create and initialize their own buffer, and destroy when finish.
This insert a penalty in each thread, and I expect to be lower than 10%.
But these things, only cover up the big problem. In the algorithms have two
kinds of works: calculus and data movements.
When the algorithm run over a single machine, the data movement is done in
the internal memory of the machine, and the time consumption is very low.
But when you run over a network of machines, the data movement can ruin the
performance of the algorithm. And there is a big difference in the
configuration. It is not the same machines connected with a triple 40 G
Infiniband bus, to machines connected with a single 1G Ethernet .
We need make test and time measures in different machines. If this problem
appear, there are internal parameters and strategies of the algorithm,
which can use to mitigate the problem.
But in any case, we will need the collaboration of the HPX users, running a
predefined test in their machines, and compare and evaluate the results.
Then, and only if the results justify it, it will be the moment of
substitute the actual internal parallel sort algorithm, by
block_indirect_sort.
The goal of this is provide to HPX the best algorithms as possible, and
many things of this are new and unexplored, but HPX will have it because is
working hard in the develop and debugging of the algorithm.
In a few weeks, I will actualize the repository, with a new version with
some fails corrected, and with all the algorithms running in the namespace
hpx::parallel::tr1, for to run with the actual code and do comparisons. The
second file attached to this message are the results of this new version
running on a single benchmark, comparing the proposed code (HPX
tr1::parallel_sort) with the actual code. (HPX parallel_sort)
Yours
Francisco
2017-09-10 17:30 GMT+02:00 Taeguk Kwon<EMAIL_ADDRESS>
@fjtapia https://github.com/fjtapia Thank you for your reply and sorry
to my late response.
I read https://github.com/fjtapia/HPX_sort/blob/master/block_
indirect_sort_en.pdf. Your idea looks so awesome!
I want to consider your better parallel sorting algorithms for resolving
this issue and getting better performance. But, maybe I should re-implement
your implementation with HPX-tic way.
But, before I consider your idea, I have to ask you for you. Can I use
your idea for HPX?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/STEllAR-GROUP/hpx/issues/2836#issuecomment-328350149,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADrumJE2uVqgMKz4DqMs_tYIbLZM4is5ks5shACkgaJpZM4O4dyA
.

**         H P X : : P A R A L L E L : : S O R T              **

**                   B E N C H M A R K                        **

Arquitectura:          x86_64
modo(s) de operación de las CPUs:32-bit, 64-bit
Orden de bytes:        Little Endian
CPU(s):                12
On-line CPU(s) list:   0-11
Hilo(s) de procesamiento por núcleo:2
Núcleo(s) por «socket»:6
Socket(s):             1
Modo(s) NUMA:          1
ID de fabricante:      GenuineIntel
Familia de CPU:        6
Modelo:                63
Model name:            Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz
Revisión:             2
CPU MHz:               1392.791
CPU max MHz:           3600,0000
CPU min MHz:           1200,0000
BogoMIPS:              6599.92
Virtualización:       VT-x
Caché L1d:            32K
Caché L1i:            32K
Caché L2:             256K
Caché L3:             15360K
NUMA node0 CPU(s):     0-11
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm intel_ppin tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc dtherm ida arat pln pts
100000000 uint64_t elements already sorted
GCC std::sort                : 2.60241 secs
HPX sort                     : 0.087891 secs
GCC std::stable_sort         : 5.28991 secs
HPX  stable_sort             : 0.0691075 secs
TBB parallel_sort            : 0.037605 secs
HPX tr1::parallel_sort       : 0.0749623 secs
HPX parallel_sort            : 0.0647351 secs
TBB parallel stable sort     : 0.706968 secs
HPX parallel stable sort     : 0.0838772 secs
HPX sample sort              : 0.0702617 secs
100000000 uint64_t elements randomly filled
GCC std::sort                : 9.02531 secs
HPX sort                     : 8.68727 secs
GCC std::stable_sort         : 8.98621 secs
HPX  stable_sort             : 9.02838 secs
TBB parallel_sort            : 1.763 secs
HPX tr1::parallel_sort       : 1.09071 secs
HPX parallel_sort            : 1.55907 secs
TBB parallel stable sort     : 2.07174 secs
HPX parallel stable sort     : 2.41496 secs
HPX sample sort              : 1.97174 secs
10000000 strings randomly filled
GCC std::sort                : 7.44621 secs
HPX sort                     : 7.92181 secs
GCC std::stable_sort         : 13.3771 secs
HPX  stable_sort             : 9.19583 secs
TBB parallel_sort            : 2.13058 secs
HPX tr1::parallel_sort       : 1.33244 secs
HPX parallel_sort            : 2.59292 secs
TBB parallel stable sort     : 2.34349 secs
HPX parallel stable sort     : 3.12607 secs
HPX sample sort              : 2.48383 secs
================================================================
=                OBJECT COMPARISON                             =
=              ---------------------                           =
=                                                              =
= The objects are arrays of 64 bits numbers                    =
= They are compared in two ways :                              =
=    (H) Heavy : The comparison is the sum of all the numbers  =
=                of the array                                  =
=    (L) Light : The comparison is with the first element of   =
=                the array, as a key                           =
=                                                              =
100000000 elements of size 8 randomly filled
H E A V Y   C O M P A R I S O N
GCC std::sort                : 9.05719 secs
HPX sort                     : 8.91211 secs
GCC std::stable_sort         : 10.9941 secs
HPX  stable_sort             : 9.12832 secs
TBB parallel_sort            : 1.84943 secs
HPX tr1::parallel_sort       : 1.49937 secs
HPX parallel_sort            : 1.5884 secs
TBB parallel stable sort     : 2.26178 secs
HPX parallel stable sort     : 2.52649 secs
HPX sample sort              : 2.0419 secs
L I G H T   C O M P A R I S O N
GCC std::sort                : 9.60662 secs
HPX sort                     : 8.95858 secs
GCC std::stable_sort         : 11.1955 secs
HPX  stable_sort             : 9.2155 secs
TBB parallel_sort            : 1.82679 secs
HPX tr1::parallel_sort       : 1.11486 secs
HPX parallel_sort            : 1.65892 secs
TBB parallel stable sort     : 2.17865 secs
HPX parallel stable sort     : 2.52737 secs
HPX sample sort              : 2.02748 secs
50000000 elements of size 16 randomly filled
H E A V Y   C O M P A R I S O N
GCC std::sort                : 5.16509 secs
HPX sort                     : 4.88129 secs
GCC std::stable_sort         : 6.08995 secs
HPX  stable_sort             : 5.5444 secs
TBB parallel_sort            : 0.973186 secs
HPX tr1::parallel_sort       : 0.686343 secs
HPX parallel_sort            : 0.984494 secs
TBB parallel stable sort     : 1.4443 secs
HPX parallel stable sort     : 1.53522 secs
HPX sample sort              : 1.39987 secs
L I G H T   C O M P A R I S O N
GCC std::sort                : 5.01757 secs
HPX sort                     : 4.6719 secs
GCC std::stable_sort         : 5.72705 secs
HPX  stable_sort             : 4.97378 secs
TBB parallel_sort            : 0.927114 secs
HPX tr1::parallel_sort       : 0.644089 secs
HPX parallel_sort            : 0.823175 secs
TBB parallel stable sort     : 1.32537 secs
HPX parallel stable sort     : 1.30084 secs
HPX sample sort              : 1.14904 secs
25000000 elements of size 32 randomly filled
H E A V Y   C O M P A R I S O N
GCC std::sort                : 3.23151 secs
HPX sort                     : 2.96121 secs
GCC std::stable_sort         : 4.05332 secs
HPX  stable_sort             : 3.4457 secs
TBB parallel_sort            : 0.661461 secs
HPX tr1::parallel_sort       : 0.515677 secs
HPX parallel_sort            : 0.618428 secs
TBB parallel stable sort     : 1.00107 secs
HPX parallel stable sort     : 1.09945 secs
HPX sample sort              : 0.901703 secs
L I G H T   C O M P A R I S O N
GCC std::sort                : 2.81681 secs
HPX sort                     : 2.58426 secs
GCC std::stable_sort         : 3.60017 secs
HPX  stable_sort             : 2.7965 secs
TBB parallel_sort            : 0.533744 secs
HPX tr1::parallel_sort       : 0.494393 secs
HPX parallel_sort            : 0.583845 secs
TBB parallel stable sort     : 0.874329 secs
HPX parallel stable sort     : 0.920968 secs
HPX sample sort              : 0.7335 secs
12500000 elements of size 64 randomly filled
H E A V Y   C O M P A R I S O N
GCC std::sort                : 2.47829 secs
HPX sort                     : 2.22867 secs
GCC std::stable_sort         : 3.27704 secs
HPX  stable_sort             : 2.72488 secs
TBB parallel_sort            : 0.619403 secs
HPX tr1::parallel_sort       : 0.469134 secs
HPX parallel_sort            : 0.555556 secs
TBB parallel stable sort     : 0.845072 secs
HPX parallel stable sort     : 0.919527 secs
HPX sample sort              : 0.792887 secs
L I G H T   C O M P A R I S O N
GCC std::sort                : 1.79291 secs
HPX sort                     : 1.65653 secs
GCC std::stable_sort         : 2.81221 secs
HPX  stable_sort             : 2.165 secs
TBB parallel_sort            : 0.499499 secs
HPX tr1::parallel_sort       : 0.431813 secs
HPX parallel_sort            : 0.474852 secs
TBB parallel stable sort     : 0.778591 secs
HPX parallel stable sort     : 0.830544 secs
HPX sample sort              : 0.685677 secs
6250000 elements of size 128 randomly filled
H E A V Y   C O M P A R I S O N
GCC std::sort                : 2.09258 secs
HPX sort                     : 1.83383 secs
GCC std::stable_sort         : 2.83864 secs
HPX  stable_sort             : 2.22892 secs
TBB parallel_sort            : 0.534752 secs
HPX tr1::parallel_sort       : 0.433769 secs
HPX parallel_sort            : 0.487857 secs
TBB parallel stable sort     : 0.817399 secs
HPX parallel stable sort     : 0.849965 secs
HPX sample sort              : 0.736171 secs
L I G H T   C O M P A R I S O N
GCC std::sort                : 1.45487 secs
HPX sort                     : 1.42989 secs
GCC std::stable_sort         : 2.61524 secs
HPX  stable_sort             : 1.8462 secs
TBB parallel_sort            : 0.471152 secs
HPX tr1::parallel_sort       : 0.3896 secs
HPX parallel_sort            : 0.435696 secs
TBB parallel stable sort     : 0.73162 secs
HPX parallel stable sort     : 0.787419 secs
HPX sample sort              : 0.63329 secs
3125000 elements of size 256 randomly filled
H E A V Y   C O M P A R I S O N
GCC std::sort                : 1.47963 secs
HPX sort                     : 1.46861 secs
GCC std::stable_sort         : 2.49858 secs
HPX  stable_sort             : 1.90743 secs
TBB parallel_sort            : 0.439718 secs
HPX tr1::parallel_sort       : 0.394152 secs
HPX parallel_sort            : 0.450641 secs
TBB parallel stable sort     : 0.760943 secs
HPX parallel stable sort     : 0.799024 secs
HPX sample sort              : 0.64447 secs
L I G H T   C O M P A R I S O N
GCC std::sort                : 1.04243 secs
HPX sort                     : 1.05095 secs
GCC std::stable_sort         : 2.4425 secs
HPX  stable_sort             : 1.6778 secs
TBB parallel_sort            : 0.370537 secs
HPX tr1::parallel_sort       : 0.359533 secs
HPX parallel_sort            : 0.417489 secs
TBB parallel stable sort     : 0.734163 secs
HPX parallel stable sort     : 0.725782 secs
HPX sample sort              : 0.664722 secs
1562500 elements of size 512 randomly filled
H E A V Y   C O M P A R I S O N
GCC std::sort                : 2.25914 secs
HPX sort                     : 2.21181 secs
GCC std::stable_sort         : 2.69855 secs
HPX  stable_sort             : 2.29027 secs
TBB parallel_sort            : 0.547796 secs
HPX tr1::parallel_sort       : 0.444853 secs
HPX parallel_sort            : 0.600206 secs
TBB parallel stable sort     : 0.801792 secs
HPX parallel stable sort     : 0.882202 secs
HPX sample sort              : 0.724445 secs
L I G H T   C O M P A R I S O N
GCC std::sort                : 1.01165 secs
HPX sort                     : 0.940796 secs
GCC std::stable_sort         : 2.50147 secs
HPX  stable_sort             : 1.68217 secs
TBB parallel_sort            : 0.364049 secs
HPX tr1::parallel_sort       : 0.343097 secs
HPX parallel_sort            : 0.391673 secs
TBB parallel stable sort     : 0.684558 secs
HPX parallel stable sort     : 0.744336 secs
HPX sample sort              : 0.611427 secs

@fjtapia

This, running in a single machine, had a penalty around 10% of the previous
version.

1 . Does this penalty means the overheads occurred by porting your original block_indirect_sort to HPX? That is, is there no penalty in original block_indirect_sort?
https://github.com/fjtapia/HPX_sort/blob/master/include/hpx/parallel/sort/detail/bis/backbone.hpp#L167-L170
2 . And I think that above codes cause frequent thread switching through std::this_thread::yield(). And it is very harmful for performance. How do you think about it?
3 . HPX have individual implementations of parallel algorithms for on a single machine and on a network. (/hpx/parallel/algorithms/ for single machine, and /hpx/parallel/segmented_algorithms for network.) So I think it is better that we first implement the algorithm running on only a single machine. And then consider running over a network.

i want to work on this. Can anyone guide me as i'm new to this?

Hi,
How is this issue resolved?
On Sat, Aug 3, 2019, 13:01 stale[bot]<EMAIL_ADDRESS>wrote:

Closed #2836 https://github.com/STEllAR-GROUP/hpx/issues/2836.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/STEllAR-GROUP/hpx/issues/2836?email_source=notifications&email_token=AHKLWMVH573YIADFYR2XLX3QCUX3RA5CNFSM4DXB3SAKYY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOS3PPB6Q#event-2531193082,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHKLWMWF3JUZLJMLF3ZTIU3QCUX3RANCNFSM4DXB3SAA
.

How is this issue resolved?

@shantanudwvd it was resolved as 'Won't Fix' as there was no activity for more than 6 month on this. If you are interested in helping to resolve the issue (or it is otherwise dear to you), please re-open it (as the comment above says).

Actually the worst case is O(N²)
The problem is resolved, but not implemented in the actual version. In this
list of messages, in September 16 of 2017 I answered this question and
attached a file with the code resolving the problem.
If you have any other question, please, contact me
Francisco Tapia
El sáb., 3 ago. 2019 a las 15:01, Hartmut Kaiser<EMAIL_ADDRESS>escribió:

How is this issue resolved?
@shantanudwvd https://github.com/shantanudwvd it was resolved as 'Won't
Fix' as there was no activity for more than 6 month on this. If you are
interested in helping to resolve the issue (or it is otherwise dear to
you), please re-open it (as the comment above says).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/STEllAR-GROUP/hpx/issues/2836?email_source=notifications&email_token=AA5O5GBJU73KAEFZN3UGMZTQCV6UHA5CNFSM4DXB3SAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3POCMI#issuecomment-517923121,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA5O5GCMLELHHVAOBTK5E7TQCV6UHANCNFSM4DXB3SAA
.

@fjtapia Francisco, would you mind re-attaching your reasoning you shared back then here, please?

I am a few days out of Madrid. The Next week I will prepare and send you
the corrections
El jue., 8 ago. 2019 4:34, Hartmut Kaiser<EMAIL_ADDRESS>escribió:

@fjtapia https://github.com/fjtapia Francisco, would you mind
re-attaching your reasoning you shared back then here, please?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/STEllAR-GROUP/hpx/issues/2836?email_source=notifications&email_token=AA5O5GE4PX3BHCZTOE2EP2TQDOA5DA5CNFSM4DXB3SAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD32HZ6A#issuecomment-519339256,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA5O5GC3LKCGZM4DNM7EM63QDOA5DANCNFSM4DXB3SAA
.

The HPX parallel sort is an implementation of the parallel introsort, which
internally is a quicksort plus heapsort.
Quicksort works, finding an element, called pivot, and filtering the
elements according to this. One part is the elements smaller than the pivot
and the others are the greatest. In this way divide the elements to sort in
two parts. Ideally, the two parts must have the same or very similar size.
The filtering process we can represent as a tree. If all the partitions are
perfect, we have a tree with nlevel levels. 2^ nlevels >= N, being N the
number of elements to sort. With the perfect partitions, the algorithm is
O(N log N).
But not all is perfect and can occur the worst case, and in the partition,
we obtain one of N – 1 element and other of 1 element. If this appears in
all the partitions we are in the worst case, and then, the algorithm is O (
N²).
To prevent this, we consider nlevels, the number of levels with perfect
partitions. If the level reaches the double of this, change to heapsort.
This algorithm is O ( N log N) in all the cases, but, in the practice is 3
or 4 times slower than quicksort.
In the parallel part of the algorithm, we make partitions and assign the
partitions to threads. When the number of elements is slower than 2 ^16 =
65536 elements, we sort with 1 thread. According to this the levels of the
parallel part are nlevels – 16. If you reach the double of this value
change to introsort with 1 thread.
The implementation of introsort we select 3 values, sort and select the
central as pivot. In this parallel version, we select the pivot between 9
values to improve the pivot selection and the partition.
In the zip file, you can find the file of hpx/parallel/algorithm/sort.hpp,
and a folder with several test programs. Some of them included in the HPX ,
and the file test_hpx_sort.cpp wich test several data set with the
algorithm.
If you see any error or any lack, please, say me to correct it as soon as
possible.
Yours
Francisco Tapia
El vie., 9 ago. 2019 a las 15:59, Hartmut Kaiser<EMAIL_ADDRESS>escribió:

Reopened #2836 https://github.com/STEllAR-GROUP/hpx/issues/2836.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/STEllAR-GROUP/hpx/issues/2836?email_source=notifications&email_token=AA5O5GF6PDB765SWIKORTKTQDVZ3VA5CNFSM4DXB3SAKYY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOS7EZQEY#event-2546571283,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA5O5GA4EZ4FTX5E7CY43TLQDVZ3VANCNFSM4DXB3SAA
.

Thanks Francisco! Would you be able to post the link to the file you are referring to somewhere?

Unzip the attached file of my message, and you will find the sort.hpp file
and a folder with the test programs used to check the correctness of the
modifications
El sáb., 7 sept. 2019 a las 18:51, Hartmut Kaiser<EMAIL_ADDRESS>escribió:

Thanks Francisco! Would you be able to post the link to the file you are
referring to somewhere?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/STEllAR-GROUP/hpx/issues/2836?email_source=notifications&email_token=AA5O5GAPUEA5MVHTNIWBGVLQIPLYVA5CNFSM4DXB3SAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6E464A#issuecomment-529125232,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA5O5GGONXTACIVGDHQ2EMTQIPLYVANCNFSM4DXB3SAA
.

@fjtapia Francisco, unfortunately, GitHub does not post attached files to the comments for a ticket. Would you mind uploading the files somewhere (gist?) and post the link here instead? Thanks!

Sorry I didn't know it about Github
I  put ii my Google Drive.
The link is
https://drive.google.com/drive/folders/1v-I9I9c0GKB5ruml8rTKFKpkTsi3FGCE?usp=sharing
If you have any problem, say me  and I try other option
El dom., 8 sept. 2019 a las 17:58, Hartmut Kaiser<EMAIL_ADDRESS>escribió:

@fjtapia https://github.com/fjtapia Francisco, unfortunately, GitHub
does not post attached files to the comments for a ticket. Would you mind
uploading the files somewhere (gist?) and post the link here instead?
Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/STEllAR-GROUP/hpx/issues/2836?email_source=notifications&email_token=AA5O5GFRWFSORHNSDF4XI63QIUOKRA5CNFSM4DXB3SAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6FTESY#issuecomment-529216075,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA5O5GGR4VEIKTA2EXQSE4DQIUOKRANCNFSM4DXB3SAA
.

Got it! Thanks a  lot!


Possibility to reset registered data for development mode

Add possibility to reset registered data for development mode, reset PackBytes and read from local storage
As proposal: https://github.com/gobuffalo/packr/pull/65/files

This should be fixed in v2. Closing this issue for now. Please re-open if the problem still persists with v2.


chore: rename receiver to requester

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md
We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

The PR edits only existing draft PRs.
The build passes.
Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
If matching on email address, the email address is the one publicly listed on your GitHub profile.

should occurrences of callback interfaces ERC7540DepositReceiver be renamed to ERC7540DepositRequest (same for redeem)?


2.x: Update escaping docs

Almost identical to https://github.com/timber/timber/pull/1841, so please look there for details.
Differences:

This PR doesn't add a fallback if autoescape is set to true.
This PR adds a note about the change in the Upgrade Guide.

@danielpost Cool, thank you for your help! 👍 I added some improvements to be more explicit in the changes.
When the fallback is merged into master, we’ll have it in 2.x as well.


Move Docker image to official OWASP Docker Hub account

The docker image is now hosted on the OWASP account with automated builds going.
https://hub.docker.com/r/owasp/railsgoat/


Return type for MonitorFromWindow incorrect

MonitorFromWindow generates the following import:
 internal static extern nint MonitorFromWindow(HWND hwnd, uint dwFlags);

However according to the doc, the return type should be HWND. https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-monitorfromwindow

Ignore. Tired eyes and misreading ;)

Ignore. Tired eyes and misreading ;)


Improve table display

Recent wide report tables with ~12 columns are not rendered well.  On a wide screen desktop the left most test name column is not readable as part is covered up by the ToC sidebar.  Collapsing the sidebar lets you read it, but that should not be needed.
On mobile some tables don't fit and there seems to be no way to scroll them or otherwise see the edge content.
Some sort of horizontal fit and scrolling ability may be needed.

additional issues with this are: the table of contents is produced by a javascript library and the components are inserted as another time and the usual z-index issues. This should not be a hard problem to solve, but it might take some time.

Do you have stats showing mobile vs desktop access? (btw. GA provides the data) I would expect developers preferring desktop as it's the development environment. Mobile version, on the contrary, could be more interesting to people looking for a product to use to check compliance.
Anyway, improving the visual style would be great.

They are just tables, they should display correctly everywhere.


Integrate EIA-861 2021 Early Release data

Made some additional changes based off of #1920 since I cant push to the rmi-electricity repo.
Still need to debug the actual ETL, as this fails with a strange error that doesn't seem related to the table/column mapping.
pudl_out = PudlTabl(pudl_engine=pudl_engine)
sales_eia861 = pudl_out.sales_eia861()

StopIteration                             Traceback (most recent call last)
File ~/code/catalyst/pudl/src/pudl/workspace/datastore.py:370, in Datastore.get_unique_resource(self, dataset, **filters)
    369 try:
--> 370     _, content = next(res)
    371 except StopIteration:

StopIteration:

During handling of the above exception, another exception occurred:

KeyError                                  Traceback (most recent call last)
File ~/code/catalyst/pudl/src/pudl/extract/excel.py:322, in GenericExtractor.load_excel_file(self, page, **partition)
    314 try:
    315     # eia860m exports the resources as raw xlsx files that are not
    316     # embedded in zip archives. To support this, we will first try
   (...)
    320     # TODO(rousik): if we can make it so, it would be useful to normalize
    321     # the eia860m and zip the xlsx files. Then we could simplify this code.
--> 322     res = self.ds.get_unique_resource(
    323         self._dataset_name, name=xlsx_filename
    324     )
    325     excel_file = pd.ExcelFile(res)

File ~/code/catalyst/pudl/src/pudl/workspace/datastore.py:372, in Datastore.get_unique_resource(self, dataset, **filters)
    371 except StopIteration:
--> 372     raise KeyError(f"No resources found for {dataset}: {filters}")
    373 try:

KeyError: "No resources found for eia861: {'name': nan}"

@arengel this seems to be working now if you want to give it a look.


Login attempt using wrong creds stalls app

Regression in latest develop build. ~Might be related to #415~
Reproduce: Login using wrong credentials (wrong email/passcode combination) -- see video
https://user-images.githubusercontent.com/21163286/230072444-d242700f-7bee-45e2-93ec-5fe77ec46224.mp4

Related to #387


Error: UNIQUE constraint failed: images.fingerprint

LXD version 3.0.2 (stable-3.0), 927a1b7afe7c0f967da4617e873456935d84d8c4, built from source, storage backend is btrfs.
lxc publish ... fails with Error: UNIQUE constraint failed: images.fingerprint.
[...]
+ lxc snapshot kubedee-container-image-b01edcb-dirty-setup snap
+ lxc publish kubedee-container-image-b01edcb-dirty-setup/snap --alias kubedee-container-image-b01edcb-dirty kubedee-version=b01edcb-dirty
Error: UNIQUE constraint failed: images.fingerprint

LXD debug log:
[...]
DBUG[08-26|11:23:13] handling                                 ip=@ method=POST url=/1.0/containers/kubedee-container-image-b01edcb-dirty-setup/snapshots
DBUG[08-26|11:23:13] Mounting BTRFS storage volume for container "kubedee-container-image-b01edcb-dirty-setup" on storage pool "kubedee"
DBUG[08-26|11:23:13] Mounting BTRFS storage pool "kubedee"
DBUG[08-26|11:23:13] Mounted BTRFS storage volume for container "kubedee-container-image-b01edcb-dirty-setup" on storage pool "kubedee"
DBUG[08-26|11:23:13] New task operation: 396f437d-55a9-4c4c-8822-e5909549c688
DBUG[08-26|11:23:13] Started task operation: 396f437d-55a9-4c4c-8822-e5909549c688
DBUG[08-26|11:23:13] Database error: &errors.errorString{s:"sql: no rows in result set"}
DBUG[08-26|11:23:13] handling                                 ip=@ method=GET url=/1.0/operations/396f437d-55a9-4c4c-8822-e5909549c688
INFO[08-26|11:23:14] Creating container                       ephemeral=false name=kubedee-container-image-b01edcb-dirty-setup/snap
INFO[08-26|11:23:14] Created container                        ephemeral=false name=kubedee-container-image-b01edcb-dirty-setup/snap
DBUG[08-26|11:23:14] Creating BTRFS storage volume for snapshot "kubedee-container-image-b01edcb-dirty-setup" on storage pool "kubedee"
DBUG[08-26|11:23:14] Mounting BTRFS storage pool "kubedee"
DBUG[08-26|11:23:16] Created BTRFS storage volume for snapshot "kubedee-container-image-b01edcb-dirty-setup" on storage pool "kubedee"
DBUG[08-26|11:23:16] Initializing BTRFS storage volume for snapshot "kubedee-container-image-b01edcb-dirty-setup/snap" on storage pool "kubedee"
DBUG[08-26|11:23:16] Mounting BTRFS storage pool "kubedee"
DBUG[08-26|11:23:17] Initialized BTRFS storage volume for snapshot "kubedee-container-image-b01edcb-dirty-setup/snap" on storage pool "kubedee"
DBUG[08-26|11:23:17] Stopping BTRFS storage volume for snapshot "kubedee-container-image-b01edcb-dirty-setup/snap" on storage pool "kubedee"
DBUG[08-26|11:23:17] Mounting BTRFS storage pool "kubedee"
DBUG[08-26|11:23:17] Stopped BTRFS storage volume for snapshot "kubedee-container-image-b01edcb-dirty-setup/snap" on storage pool "kubedee"
DBUG[08-26|11:23:17] Success for task operation: 396f437d-55a9-4c4c-8822-e5909549c688
DBUG[08-26|11:23:17] handling                                 ip=@ method=GET url=/1.0
DBUG[08-26|11:23:17] Disconnected event listener: 7dc52d8a-6be1-49bc-9bd4-cba11962203d
DBUG[08-26|11:23:17] handling                                 ip=@ method=GET url=/1.0/events
DBUG[08-26|11:23:17] New event listener: 639e1f7a-7193-4ef3-a846-eaa89ddb0852
DBUG[08-26|11:23:17] handling                                 ip=@ method=POST url=/1.0/images
DBUG[08-26|11:23:17] New task operation: 02fad25b-1bec-49be-974f-d693802f5b6e
DBUG[08-26|11:23:17] Started task operation: 02fad25b-1bec-49be-974f-d693802f5b6e
DBUG[08-26|11:23:17] handling                                 ip=@ method=GET url=/1.0/operations/02fad25b-1bec-49be-974f-d693802f5b6e
INFO[08-26|11:23:17] Exporting container                      created=2018-08-26T11:23:13+0200 ephemeral=false name=kubedee-container-image-b01edcb-dirty-setup/snap used=1970-01-01T01:00:00+0100
DBUG[08-26|11:23:17] Initializing BTRFS storage volume for snapshot "kubedee-container-image-b01edcb-dirty-setup/snap" on storage pool "kubedee"
DBUG[08-26|11:23:17] Mounting BTRFS storage pool "kubedee"
DBUG[08-26|11:23:17] Initialized BTRFS storage volume for snapshot "kubedee-container-image-b01edcb-dirty-setup/snap" on storage pool "kubedee"
INFO[08-26|11:23:21] Exported container                       created=2018-08-26T11:23:13+0200 ephemeral=false name=kubedee-container-image-b01edcb-dirty-setup/snap used=1970-01-01T01:00:00+0100
DBUG[08-26|11:23:23] Stopping BTRFS storage volume for snapshot "kubedee-container-image-b01edcb-dirty-setup/snap" on storage pool "kubedee"
DBUG[08-26|11:23:23] Mounting BTRFS storage pool "kubedee"
DBUG[08-26|11:23:23] Stopped BTRFS storage volume for snapshot "kubedee-container-image-b01edcb-dirty-setup/snap" on storage pool "kubedee"
DBUG[08-26|11:23:59] Database error: &errors.errorString{s:"sql: no rows in result set"}
INFO[08-26|11:24:04] Dqlite: closing client
DBUG[08-26|11:24:04] Database error: &errors.errorString{s:"driver: bad connection"}
DBUG[08-26|11:24:04] Retry failed db interaction (driver: bad connection)
INFO[08-26|11:24:04] Dqlite: handling new connection (fd=23)
INFO[08-26|11:24:04] Dqlite: connected address=0 attempt=0
DBUG[08-26|11:24:04] Database error: bindings.Error{Code:2067, Message:"UNIQUE constraint failed: images.fingerprint"}
DBUG[08-26|11:24:05] Failure for task operation: 02fad25b-1bec-49be-974f-d693802f5b6e: UNIQUE constraint failed: images.fingerprint

I've tried with both the master branch and with 3.0.2 and am unable to reproduce this in either environments.
Are you running a single node or a cluster? Does the issue happen consistently?
If so, can you show lxd sql global "SELECT * FROM images;"?

Ah, I think I figured it out, you're actually in a case where you should have gotten The image already exists: FINGERPRINT but you didn't because of likely unrelated database error which masked this.
Specifically those lines:
INFO[08-26|11:24:04] Dqlite: closing client
DBUG[08-26|11:24:04] Database error: &errors.errorString{s:"driver: bad connection"}
DBUG[08-26|11:24:04] Retry failed db interaction (driver: bad connection)
INFO[08-26|11:24:04] Dqlite: handling new connection (fd=23)
INFO[08-26|11:24:04] Dqlite: connected address=0 attempt=0

The timing lines up with when LXD would have checked whether the image already exists, our logic checks if we get an error (any error) and if we do, assume it means the record is missing and so should go ahead, this is obviously terrible error handling and I'll fix that.
In this case you should have received "driver: bad connection" as an error and publishing should have halted there. Not ideal and likely an indication of a go-dqlite bug, but better than what happened.
@freeekanayaka FYI, that closing/bad-connection/... stuff looks like a potential go-dqlite issue