Fix from_hex_unchecked implementation for field elements with montgomery backend

impl<M, const NUM_LIMBS: usize> FieldElement<MontgomeryBackendPrimeField<M, NUM_LIMBS>>
where
    M: IsModulus<UnsignedInteger<NUM_LIMBS>> + Clone + Debug,
{
    /// Creates a `FieldElement` from a hexstring. It can contain `0x` or not.
    /// # Panics
    /// Panics if value is not a hexstring
    pub const fn from_hex_unchecked(hex: &str) -> Self {
        let integer = UnsignedInteger::<NUM_LIMBS>::from_hex_unchecked(hex);
        Self {
            value: MontgomeryAlgorithms::cios(
                &integer,
                &MontgomeryBackendPrimeField::<M, NUM_LIMBS>::R2,
                &M::MODULUS,
                &MontgomeryBackendPrimeField::<M, NUM_LIMBS>::MU,
            ),
        }
    }
}

here the documentation of the function states that the number can contain the 0x prefix or not, but then UnsignedInteger::<NUM_LIMBS>::from_hex_unchecked(hex); is called, and that function has the following documentation
 /// Creates an `UnsignedInteger` from a hexstring
    /// # Panics
    /// Panics if value is not a hexstring. Shouldn't start with `0x`
    pub const fn from_hex_unchecked(value: &str) -> Self {

so there is an inconsistency. Either the documentation must be changed or the functionality to strip the prefix must be added

I think for the sake of consistancy we should modifie from_hex_unchecked for UnsignedInteger as from_hex also states
https://github.com/lambdaclass/lambdaworks/blob/8fcd64f1db99a249a8bdfa84bff9731730455ca9/math/src/unsigned_integer/element.rs#L420-L421
for example this check https://github.com/lambdaclass/lambdaworks/blob/8fcd64f1db99a249a8bdfa84bff9731730455ca9/math/src/unsigned_integer/element.rs#L425-L432
should be used in from_hex_unchecked instead of from_hex it will make functions more consistance and we can than update the docs of UnsignedInteger's from_hex_unchecked.
Thought's @Oppen @MauroToscano


[SPARK-18519][SQL] map type can not be used in binary comparison

What changes were proposed in this pull request?
MapType is not orderable, we forbid users to use map type in join key and aggregate grouping key, we should also forbid map type in binary comparison.
How was this patch tested?
updated tests.

cc @yhuai @hvanhovell  @gatorsmile

Test build #68920 has started for PR 15956 at commit a7b6e42.

So technically I think map type should be able to be used in equality comparison, but not orderable, so I'm not sure if this is correct.
Spark SQL currently has a restriction that we just don't allow map types to be used in equality comparison at all, but I don't want to structure code in a way that would make it harder to support that in the future.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/68920/
Test FAILed.

Merged build finished. Test FAILed.

Spark SQL currently has a restriction that we just don't allow map types to be used in equality comparison at all, but I don't want to structure code in a way that would make it harder to support that in the future.

If we wanna support equality comparison for map type in the future, we can just update the type checking logic for BinaryComparison. For now I think it's better to forbid users to do this, to avoid confusing behaviors, e.g. SELECT MAP(1,2) = MAP(1,2) returns false.

Test build #68932 has started for PR 15956 at commit b95e25f.

Test build #68932 has finished for PR 15956 at commit b95e25f.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/68932/
Test FAILed.

Merged build finished. Test FAILed.

Test build #68938 has started for PR 15956 at commit fe6818b.

Test build #68938 has finished for PR 15956 at commit fe6818b.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/68938/
Test FAILed.

Test build #68940 has started for PR 15956 at commit c3275ed.

Test build #68940 has finished for PR 15956 at commit c3275ed.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/68940/
Test PASSed.

Merged build finished. Test PASSed.

Test build #68997 has started for PR 15956 at commit b5a50f4.

Test build #68997 has finished for PR 15956 at commit b5a50f4.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test build #69002 has started for PR 15956 at commit dff0b08.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/68997/
Test PASSed.

Merged build finished. Test PASSed.

LGTM pending Jenkins

Test build #69002 has finished for PR 15956 at commit dff0b08.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/69002/
Test PASSed.

LGTM - merging to master/2.0. Thanks!

@cloud-fan I cannot merge this to 2.0. Can you make a backport if we need one?

Yea, I'll backport


Override getName in ExampleWriteSupport

hi Neville 👋 👋 👋 🎉
Just adding this getName override so that the file metadata header will contain the key writer.model.name -> example and we can easily identify it/add discoverability tooling.

👋 Just released in 0.4.3 https://github.com/nevillelyh/parquet-extra/releases/tag/v0.4.3

amazing thank you 🙏


image_reaction.yag on URLs not functioning

Hi, currently as it stands the coding within ImageReaction allows any URL to be posted whether its an image URL or not.  Something within the Embed Media cmdlet doesn't appear to be functioning correctly and its either not looking at URLs ending extension i.e. ".jpg" similar to .Message.Attachments OR its too wide-open and needs to query from something like the AutomoderationV2 List function so we can Whitelist sites.
P.S. amazing script and appreciate the work and time that went into this.  Not really a deal breaker if nothing can be done for the things I mentioned.  Just more of pointing out some things that may or may not need to be addressed.

The link has a thumbnail field.
And the thumbnail has an image url, and thats how it triggers.
You may have seen people use their own domains to upload screenshots to.
The links then look like https://example.com/loPOhRdstZ or so and embed the image as thumbnail.
When i had it on to only look for extientions and stuff this wouldn't have worked.
I think the same also goes for twitter links.
If you have a fix for that feel free to mention it to me. Otherwise i don't think there is a fix for it.

That's fair and figured it would be an impractical thing to address because of what you mentioned.  Pretty much the only solution would to be to somehow trigger a whitelisting function.  In any case thank you for the amazing code and definitely using it within my Discord.


Parse IRE identifiers

52 IRE 7.S2
55 IRE 2.S1 (IEEE Std No 147)
61 IRE 15.S1 (IEEE 182)
61 IRE 28 S1 (IEEE 216)
62 IRE 12.S1 (IEEE 174)
62 IRE 7.S2 (IEEE 161)
IEEE Std 159-1972 (52 IRE 7 S2)
IEEE Std 218-1956 (Reaffirmed 1980, 56 IRE 28.S2)
IEEE Std 59 IRE 12, S1
IEEE Std 175-1960 (60 IRE 13 S1)

Seems the first number here is a year, for example: "52 IRE 7.S2" actually "IRE/IEEE 7.S2-1952"
@ronaldtse Should we generate output with IRE/IEEE for all this identifiers?

@mico yes you are right.
According to https://ewh.ieee.org/cmte/pa/Status/IEEE.html , IRE is one of two predecessor organizations (the other is AIEE):

The American Institute of Electrical Engineers (AIEE) and the Institute of Radio Engineers (IRE) united in 1963 to form the IEEE.

So these documents are by nature, dual-published by IRE and IEEE as they are re-labeled as IEEE standards after being published by IRE.


First set of change containing telemetry infrastructure for NTVS

@mousetraps @ryan-dawson

Hi @nareshjo, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Naresh Joshi). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

After some discussions we are proceeding with another approach significantly different from this one so closing this out and will send new PR with it


ClimateTrace Data Pipeline

Data pipeline for ClimateTrace (emissions by sector): https://climatetrace.org/downloads
Methodology including source data used in computation is available at https://github.com/climatetracecoalition
@MichaelTiemannOSC could you comment on usefulness of this data in OS-Climate context (any stream this would be interesting for?). Limitation of this approach is we would not get lineage from computations done by ClimateTrace.

I don't think we need computational lineage to start.  Federating the computed data we can compare/contrast with ESSD and others.  If, down the road, Climate trace wants to make deeper data public (possibly using the Data Commons architecture), so much the better.


[projmgr] Using existing .cprj as lockfile

With the recent advances to the .yml format and projmgr/csolution tools I'd like to reopen the discussion around lockfiles.
It seems that the source of truth for the projects are now likely to be the .yml files.
Use-case: User adds a compiler flag to the project

Manually edit the cproject/csolution.yml file to add the defined symbol
Run csolution/projmgr tool to update .cprj files
Trigger build of the project using cbuildgen and the cprj file

During step 2, if there is already a cprj file existing, we should preserve/reuse as much information from that as possible.
For example, the yml files may not specify any packs, or without any version ranges, but the .cprj may be strictly locked down to a specific pack+version.
Same for components.
For the above use-case, the user expects only the define to be added in the build. If the 2. would result in a full recompute/resolving of components+pack-versions it would make the .yml files impossible to use over time or between colleagues, since the contents of the .cprj would very likely be different due to changing CMSIS_PACK_ROOT contents.
This is a followup on the discussion from the build gap
Also, working in this way means that the user should put commit the .yml and the .cprj files in their git repository to make sure that colleagues/CI are building the same thing.

Same idea here thinking #82 cprj acting as lock file if end user resources.

High-level, there are a few main requirements of a lockfile:

Ensure the project is stable over the course of development. Principle of fewest surprises.

I should be able to add a new component to my project, and this should change as few things as possible

Ensure the project is reproducible

Each time I resolve/build my project I expect the same result

Ensure the project is shareable

I should be able to share my project with my colleagues and they should be able to use my locking information to build the same thing

Ensure the project state is obvious

If something changed in my project, it should be visible and obvious in the lockfile so that I can see it in git diff

In #171 we see that the cprj-format grows and grows to support the use-cases supported by the yml formats. I think this is a problem since it means that we will always have two different formats that always needs to support the same things.
Why? Sounds like a maintainers nightmare with no clear gain?.
I would much prefer if we either go in the route of yml->CMakeLists directly as in https://github.com/Open-CMSIS-Pack/devtools/issues/171#issuecomment-1061716257  or improve and align on the Generator input file (*.cgen.json) format that could also possibly serve as a lockfile (https://github.com/Open-CMSIS-Pack/devtools/blob/main/tools/projmgr/docs/Manual/YML-Format.md#generator-proposal and https://github.com/Open-CMSIS-Pack/Open-CMSIS-Pack-Spec/issues/104).
So we need:

When going from YML, take any existing Pack list from the lock file and ONLY use this set of packs for resolving. This will make the project stable and reproducible

If YML pack list is missing or loosely defined (ranges), reuse from the lock file, or define a pack list if the lock file is missing
If YML pack list definition is incompatible with the lockfile, update the lock file

When creating the lock file we should show at least these things to make it obvious:

Packs used (including checksum of the pack that could be optionally verified)
Target used
All conditions resolved in the project
Components used and from which packs they are used (including the condition used for the component)

All files used from the component (referencing project/pack in a shareable way)

The nice thing about this is that then we no longer need a tool to understand the complete state of the project, since everything has been made explicit in the lockfile.
We will also be able to detect non-obvious changes with git diff in the project due to condition resolving, e.g. adding ComponentB may make "ComponentA" resolve to a different "ComponentA"

The benefit I am seeing in the representation in the 'cprj' format is, that it only describes a single context in a "fully specified" way.
The benefit of csolution is that it should allow to specify all contexts of a solution with the freedom to range from loosely specified all the way to precisely specified. E.g. you can now specify the packs to be used even reference a copy of a pack which is "private" to the solution.
Therefore I still find this two phase approach csolution -> cprj(s) useful.

@jkrech  I agree about the single context, this is needed since a single csolution/cproject may resolve to several unique lockfiles, one per context.
To fullfil my needs, the current cprj-format would need to evolve abit, since it does not satisfy the obvious requirement at least.
Below is a small proposal of what a reproducible shareable and obvious lockfile could look like:
This is based/inspired by the cgen.json but not exactly the same:
{
    "device": "STM32F407IGHx",
    "board": "NucleoF407",
    "solution": "../MySolution.csolution.yml",
    "project": "../Blinky.cproject.yml",
    "build_type": "Debug",
    "target_type": "Nucleo",
    "packs": [
<EMAIL_ADDRESS>        { "pack"<EMAIL_ADDRESS>"sha256": "..." },
        { "pack"<EMAIL_ADDRESS>"path": "../Some/Path/toMyPack" }
    ],
    "components": [
        {
            "pack_id"<EMAIL_ADDRESS>            "name": "Device:STM32Cube<EMAIL_ADDRESS>            "condition": "STM32F4 GCC",
            "pack_files": [
                "./path_inside_pack/file.c"
            ],
            "project_files": [
                "./path_inside_project/file.c"
            ]
        },
        {
            "pack_id"<EMAIL_ADDRESS>            "name"<EMAIL_ADDRESS>            "condition": "STM32F4 GCC",
            "pack_files": [
                "./path_inside_pack/file.c"
            ],
            "project_files": [
                "./path_inside_project/file.c"
            ]
        },
        {
            "pack_id"<EMAIL_ADDRESS>            "name"<EMAIL_ADDRESS>            "condition": "STM32F4 GCC",
            "pack_files": [
                "./path_inside_pack/file.c"
            ],
            "project_files": [
                "./path_inside_project/file.c"
            ],
            "instances": {
                "WiFi": {
                    "instance": 0,
                    "setup": "wifi-config.json",
                    "baudrate": 19200
                },
                "Debug": {
                    "instance": 2,
                    "baudrate": 57600
                }
            }
        }
    ]
}

This lockfile could also be described like this using TypeScript types as "schema"

interface Lockfile {
    device: string,
    board: string,
    solution: string,   // Relative to lockfile directory
    project: string,    // Relative to lockfile directory
    packs: PackType[],
    build_type: string,
    target_type: string,
    components: ComponentType[],
}

type PackType = string | Pack;

interface Pack {
    pack: string,       // Full identifier of pack
    path?: string       // Optional path to where the pack is located, relative to the lockfile directory
    sha256?: string     // Optionally store sha256 of entire pack installation
}

interface ComponentType {
    pack_id: string,    // Identify which pack that brings this component
    name: string,       // Full name of the component
    condition: string,  // Condition used by the component
    pack_files: string[],     // Component files that stay in the pack installation location
    project_files: string[],  // Component files that end up in the project AKA "RTE files" AKA "attr=config" files
    instances?: InstancesType,
}

interface InstancesType {
    [instanceName: string]: InstancesType,
}

interface Instance {
    instance: number,
    setup?: string,     // Path to setup file
    baudrate: number,
}

Some open discussion points about this proposal:

It does not list user files
It does not show compiler flags
It does not show dependencies to other projects (build order)
All these three can still be found by parsing the referenced csolution/cproject files however.

The project_files from a component would be what we currently think of RTE files.
The pack_files from a component would be any other files that are coming from a component, but always stays in the pack-installation-location.
If we think we should go for a more detailed lockfile including the above three points, then I think we should consider moving directly from YML to CMakeLists, one CMakeList per context.

@slhultgren regarding 1.2 I think the devil is in the detail. I like the idea of "minimal" changes compared to previous lockfile but I doubt that this will always create the desired "update" behavior. E.g. if a newer version of the pack got installed but the previous version is no longer present, do we have to install the previous version in order to achieve minimal changes? What if the previous version is still installed, do we let the user know that there is a newer version available?
Maybe it is not for the tool to optimize for minimal changes, but allow the user to compare the previous and the latest lockfile to identify the changes. Restricting e.g. the pack selection in the csolution will allow the user to minimize the differences in the lock file. What am I missing?

@jkrech I agree there will be finer details to hash out indeed. for the ones you mention I would be very conservative:

Newer pack is available in CMSIS_PACK_ROOT but lockfile is using an older one that also exists in CMSIS_PACK_ROOT
-> Following the priniciple of least surprise and stability between colleagues who may very well have different contents in the CMSIS_PACK_ROOT, it means that we should indeed only use the version mentioned in the lockfile, regardless of what is available in the CMSIS_PACK_ROOT

If newer is in CMSIS_PACK_ROOT but the lockfile-pointed one is not
-> This should result in error (missing pack) with potential auto-suggestion, "would you like to install XXX@YYY"

This would be the minimum, then we could indeed add some more "sugar" on top, like suggesting possibly to move to a newer pack version. But moving to a newer pack version may change a lot of things in terms of component resolve state, so it needs to be a conscious choice by the user when and why this happens.
As you say, technically we could restrict the pack selection in the yml file, but this is a less nice user-experience IMO.
In case I later want to do a full "re-alignment" to the latest versions supported by my yml files I would simply remove the lockfile and recreate it from scratch. This would make the new lock file be created based on the latest information available in the CMSIS_PACK_ROOT combined with any version range or pack filter from the yml file.
Lastly however I also again want to highlight the value of having a file showing the complete state of the pack/component state of the project as the tools would understand it:

Showing which packs are used
Showing which components (exactly, meaning indicating both originating pack and condition)

Showing where RTE files ends up from these components (are some still left in the PACK_DIR, and are some in the project, and if so, exactly where in the project did they end up)

and not mentioned before, also indicate any potential unresolved component in the project

All of these features also fits perfectly IMO with the generator input file mentioned previously, which would simplify implementing generators, so having a file format to explicitly describe the exact project pack/component state is very attractive here.

@ReinhardKeil I would like to get your feedback on this as well since my latest thoughts in https://github.com/Open-CMSIS-Pack/devtools/issues/119#issuecomment-1096726705 is basically a slightly expanded version of your cgen.json proposal.
High-level idea is that we should have a format that can explain the exact pack+component state, and this same format can then fill the needs of both a generator input and a lockfile.

@slhultgren the *.CPRJ file has most of this information. I suggest we start there and make a gap analysis.
I understand that XML is not the best user-oriented format (and we may change that at a later point - which could be with a viewer or list utility), but fundamentally most of the information should already be there.  The fact that a single file serves the need of a log file and build input file has IMHO the benefit that it cannot deviate. Files from a previous build can be easily compared.
We can of course add missing information once we have understood the usage. For example it does currently not show the invocation line of the csolution tool so that a convert process is cannot be replicated.  Likewise the Environment variables and inherent settings (for example cdefault assumptions) is missing.  However, these gaps are minor, and we should just list them as requirements for further development.
We should also discuss if some of the current information should be removed.  For example timestamp (shown below) as this creates the effect that every convert run creates effectively a different file, even when the rest of the content is identical.
  <created timestamp="2022-04-27T15:31:27" tool="csolution 0.9.4"/>

We should check the behavior of git systems, so that the *.CPRJ file can be committed, but effectively does not change when csolution recreates the same content.

Note: the csolution tool as it is deployed right now has a bug as it does not fix the pack versions, but allows to use also later versions of that pack.  This is fixed already in the next iteration.

As discussed yesterday, I got confused by the difference of:

log file (a protocol that lists the current stated)
lock file (a way to fix the selection - obviously a lot more complicated).

With *.CPRJ I believe only the "log file" requirement can be fulfilled.  Are we aligned in this view?  I would then split this issue into two.

We could discuss the format, (I have some changes in mind to what I've previously posted), but I think it is also interesting to align on what this could bring for the tooling.
In my view, having a file that clearly both locks the state (by locking on packs) and describes the resolved state, it then means that the user no longer need any runtime tool to understand what and why something is part of the project.
This would also help streamline cbuildgen since thanks to the lockfile, it will no longer have to do any component/condition/RTE resolution at all to be able to construct the CMakeLists.txt.
This means that we remove the creation of the RTE from the build step.
I'll take a few use-cases to explain the flow:
Add a component [YML] high level

User edits YML files
User runs csolution to create RTE files and lockfile
User runs cbuildgen to create CMakeLists.txt
User runs cmake to build

Add a component [CPRJ] high level

User edits CPRJ file
User runs cprj (TBD) to create RTE files and lockfile
User runs cbuildgen to create CMakeLists.txt
User runs cmake to build

Add a component [YML] detailed

User edits the .cproject.yml and adds component CMSIS:Core
User edits the .csolution.yml and adds pack ARM.CMSIS note no version number
User runs csolution tool
3.1. csolution checks in the lockfile if there is a matching pack for ARM.CMSIS already being used
3.1.a. If there is a match, use this version
3.1.b. If there is no match, record the latest version of ARM.CMSIS pack found in CMSIS_PACK_ROOT in the lockfile
3.2. csolution resolves the CMSIS:Core loose description to an exact match, e.g<EMAIL_ADDRESS>Device # is used as separator to include condition id as well
3.2.1. csolution then creates all the RTE files for the component
3.2.2. csolution records the state of the created<EMAIL_ADDRESS>Device in the lockfile with

The full component id including condition id
The Pack id so that we know where it came from
Each file that the component is using is recorded with it's pack path and project path and condition id, category...

RTE files will have both a pack path and a project path
generated files will at least one of pack path and project path, possibly both, depends on the generator
other files will only have a pack path

User runs cbuildgen tool
4.1. cbuildgen reads the lockfile, concatenates paths from component files and their associated pack paths and constructs a CMakeLists.txt
User runs cmake to build their project

Using a generated component [YML]

User edits YML files to include a generated component (AKA component that uses generators)
User runs csolution to create RTE files and lockfile (lockfile contents based on pdsc description of generated component)
User runs csolution to trigger generators with the lockfile as argument to the generator since this is the full current state
3.1. generators can create their files by reading only the provided lockfile state, no condition resolving necessary
3.2. csolution uses the returned gpdsc description and updates the lockfile entry for the component with the generated contents
User runs cbuildgen to create CMakeLists.txt
User runs cmake to build the generated code

@slhultgren - in the meantime we have been discussing to disable the cbuildgen functionality regarding 'managing' RTE config files. Do you think that editing cprj files is still relevant?

Apologies for coming late to this conversation, but just recently I have been thinking about this issue from a slightly different perspective. Mostly due to the separation of concerns design principle, I have been thinking about how to manage CMSIS components in a project agnostic way.
This project agnostic approach is followed by most package managers, so in principle it should be relatively simple to replicate. However, CMSIS gives us an extra dimension, that package managers do not normally have to handle. Normally the package dependency being managed is the same as the library or component being used. With CMSIS we allow loosely defined component references, which can be resolved to a number of components that can be delivered by different packs. This increases flexibility, but makes both reproducibility and dependency management more tricky.
Another aspect that most package managers posses, is a separation between the "required" components (those that a developer explicitly wishes to use) and the dependencies of those components (e.g. Python's Pipfile vs Pipfile.lock). The reason this is important is dependency management over time. If a component is removed from a project, or new version of a component is released that has different dependencies, then all the irrelevant dependencies should be removed from the project. Unless the required components and dependencies are not stored separately, then it is not possible to automatically determine which components should be removed.
Conceptually we can used the csolution format to store the required components, assuming certain constraints are applied. For example, if the component references included in the cproject files are limiting to only those that are "required" and the pack list is not included in the csolution file, but instead deferred to a lock file.

Please note that the lock file does not include any project specific information, such as files, build settings etc. It solely contains the components being used and the packs that they come from.

A lock file could look something like the following, where the component reference is keyed from those included in the cproject file:
Components:
  - ComponentReference:
      Vendor: ARM
      Class: Device
      Bundle:
      Group: Startup
      Subgroup:
      Variant: C Startup
      Version:
    ComponentId:
      Vendor: ARM
      Class: Device
      Bundle:
      Group: Startup
      Subgroup:
      Variant: C Startup
      Version: 2.1.0
    PackId:
      Vendor: ARM
      Name: CMSIS
      Version: 5.9.0
    Dependencies:
      - ComponentId: {}
        PackId: {}
        Dependencies:
          - ComponentId: {}
            PackId: {}
            Dependencies: []

This results in a tree structure that makes it straight forward to manage component dependencies and packs. For reference the schema for this document is as follows:
{
  "$schema": "http://json-schema.org/draft-04/schema#",

  "definitions": {
    "ComponentReference": {
      "type": "object",
      "properties": {
        "Vendor": {
          "type": "string"
        },
        "Class": {
          "type": "string"
        },
        "Bundle": {
          "type": "string"
        },
        "Group": {
          "type": "string"
        },
        "Subgroup": {
          "type": "string"
        },
        "Variant": {
          "type": "string"
        },
        "Version": {
          "type": "string"
        }
      },
      "required": [
        "Class",
        "Group"
      ]
    },
    "ComponentId": {
      "type": "object",
      "properties": {
        "Vendor": {
          "type": "string"
        },
        "Class": {
          "type": "string"
        },
        "Bundle": {
          "type": "string"
        },
        "Group": {
          "type": "string"
        },
        "Subgroup": {
          "type": "string"
        },
        "Variant": {
          "type": "string"
        },
        "Version": {
          "type": "string"
        }
      },
      "required": [
        "Vendor",
        "Class",
        "Group",
        "Version"
      ]
    },
    "PackId": {
      "type": "object",
      "properties": {
        "Vendor": {
          "type": "string"
        },
        "Name": {
          "type": "string"
        },
        "Version": {
          "type": "string"
        }
      },
      "required": [
        "Vendor",
        "Name",
        "Version"
      ]
    },
    "Dependencies": {
      "type": "array",
      "items": [
        {
          "type": "object",
          "properties": {
            "ComponentId": {"$ref": "#/definitions/ComponentId"},
            "PackId": {"$ref": "#/definitions/PackId"},
            "Dependencies": {"$ref": "#/definitions/Dependencies"}
          },
          "required": [
            "ComponentId",
            "PackId"
          ]
        }
      ]
    }
  },

  "type": "object",
  "properties": {
    "Components": {
      "type": "array",
      "items": [
        {
          "type": "object",
          "properties": {
            "ComponentReference": {
              "$ref": "#/definitions/ComponentReference"
            },
            "ComponentId": {
              "$ref": "#/definitions/ComponentId"
            },
            "PackId": {
              "$ref": "#/definitions/PackId"
            },
            "Dependencies": {
              "$ref": "#/definitions/Dependencies"
            }
          }
        }
      ]
    }
  },
  "required": [
    "Components"
  ]
}

@madchutney thanks for the input, very interesting

separation between the "required" components (those that a developer explicitly wishes to use) and the dependencies of those components

Very valid point, I agree totally with this. Dependencies are not always that interesting, and indeed, if you change the top-level component, you likely also want to change/remove the now unused dependencies.
Q: Do we now then say that the list of the components in cproject.yml is now no longer necessarily the full list of components used in the project?
i.e. full list of components would be guaranteed in the lockfile, but not guaranteed in cproject.yml

Conceptually we can used the csolution format to store the required components, assuming certain constraints are applied. For example, if the component references included in the cproject files are limiting to only those that are "required" and the pack list is not included in the csolution file, but instead deferred to a lock file

On this I'm not sure I fully understand what you mean.
Does it imply this:

No need to have a pack list in csolution or cproject? =>  if so, then this sounds interesting, since it opens up more flexibility of even allowing to use components from different versions of the same pack series. I.e. a single project can combine ComponentA from ARM.CMSIS.5.9.0, and ComponentB from ARM.CMSIS.5.6.0 in theory
cprojects are only allowed to select between required components specified in csolution? => This I don't think is a good idea, it restricts the cprojects too much. The lockfile needs to be one per "permutation", (one per $BUILD_TYPE*$TARGET_TYPE*$CPROJECT_COMPONENT_LIST)

Please note that the lock file does not include any project specific information, such as files, build settings etc. It solely contains the components being used and the packs that they come from.

For build settings, we could discuss, I'm not sure myself. I do think we should find a simple workflow so that our tooling can be simpler than what it is today. Implementing YML logic in csolution.exe and cbuildgen.exe is not very nice IMO.
For files, I would argue that in case of CMSIS it is actually necessary to have it as part of the lockfile.
For me, the purpose of a lockfile is to describe

what you use in a project (so that colleagues can use the same)
why you have it (so that you can detect/debug mistakes)
where it comes from, and where it is placed (so that you can know and understand the project structure)

With a purely package based package manager like pip or NPM, the granularity is on the module/package level. If you know which module you have, then you implicitly also know all the files.
With CMSIS it is not that simple, since the file set is not static for a component (file-based conditions, RTE connection, Generated components).
To summarize my comments:

Allowing the cproject component list to be more focused on the top level components that the user is interested in, and delegating the pure dependencies to the lockfile is a good idea
ComponentID could be stored as a plain string using the official OpenCMSIS YML component ID format

ComponentID should also include condition id, otherwise it is not a unique match and requires more tooling logic to understand => Harder to understand for user when looking at the files
Every ID-part available for the selected component should be stored on the ComponentID. e.g. if the selected component specifices the optional Cvariant, then the lockfile should include the Cvariant in the ID string since we had this information during the resolution process.

files should be listed for the components since they are also condition-based, and changes in the project that modifies how/what files are included in the project should be reflected in the lockfile

To make RTE connection and generated components understandable, both the path_in_pack and path_in_project should be recorded for each file

Differentiating between "user required" components and those being selected to satisfy dependencies resonates with me. Considering the situation that there maybe choices in resolving dependencies, these user decisions would be recorded in the lock file, which means that the lock file becomes a mandatory project file or am I missing something?
I am wondering whether we could record such components as "secondary components". Meaning they could be "excluded" from build in case they are no longer showing in the dependency list.
When the users selects a component, there is a choice whether the component is required by the user's code (e.g. a certain USART interface is called directly, or to satisfy an I/O component's requirement to print to a terminal).

After reviewing this issue, there might be an intermix of different things:

a "log" file that lists all important parameters about a csolution/cproject
a "lock" mechanism that protects from accidently modifying properties

My suggestion: introduce a "log" file that lists all important information about a csolution based application in one file.  The information could include:

packs used
components used, with information about:

required components, which would indicated other components that are requested by conditions of that component
required-by components, which would indicated other components that request this component by conditions
pack indicates the software pack that defines the component

It should be also possible to list:

overall information for all context configuration and context specific information.
files that belong to the component along with path information.

This "log" file could be in YAML format (using the standard naming conventions) so that it is user digestible, but also serves as data source for analysis tools. Over time we could develop it into a "lock" mechanism (but I suggest this is not the initial priority).
After considering all feedback the *.CPRJ file seems not the right place to add above information, instead my proposal is a single "log" file per *.csolution.yml" that is generated by the csolution tool.

@slhultgren Thanks for taking the time to review my suggestion.

Q: Do we now then say that the list of the components in cproject.yml is now no longer necessarily the full list of components used in the project? i.e. full list of components would be guaranteed in the lockfile, but not guaranteed in cproject.yml

That was my thinking, yes.

Conceptually we can used the csolution format to store the required components, assuming certain constraints are applied. For example, if the component references included in the cproject files are limiting to only those that are "required" and the pack list is not included in the csolution file, but instead deferred to a lock file

On this I'm not sure I fully understand what you mean. Does it imply this:

I trying to illustrate how the csolution or cproject files could be the source of the requirements, while a lock file used to provide the additional information on component resolution and dependencies. If the constraints were not applied it would mean that it was not possible to differentiate between required components and dependencies and the the pack list in the would have to be synchronised somehow.

No need to have a pack list in csolution or cproject? =>  if so, then this sounds interesting, since it opens up more flexibility of even allowing to use components from different versions of the same pack series. I.e. a single project can combine ComponentA from ARM.CMSIS.5.9.0, and ComponentB from ARM.CMSIS.5.6.0 in theory

That is what I was thinking. The csolution or cproject may add this constraint but in terms of a lock file format I was trying to be as flexible as possible.

cprojects are only allowed to select between required components specified in csolution? => This I don't think is a good idea, it restricts the cprojects too much. The lockfile needs to be one per "permutation", (one per $BUILD_TYPE*$TARGET_TYPE*$CPROJECT_COMPONENT_LIST)

I agree, the lock file should be per Project Context ($BUILD_TYPE*$TARGET_TYPE*$PROJECT). The lock file format could be structured such that there was a "lock" per Project Context or an individual lock file per Project Context (my example takes the latter approach as this seemed simpler).

Please note that the lock file does not include any project specific information, such as files, build settings etc. It solely contains the components being used and the packs that they come from.

For build settings, we could discuss, I'm not sure myself. I do think we should find a simple workflow so that our tooling can be simpler than what it is today. Implementing YML logic in csolution.exe and cbuildgen.exe is not very nice IMO.
For files, I would argue that in case of CMSIS it is actually necessary to have it as part of the lockfile. For me, the purpose of a lockfile is to describe

what you use in a project (so that colleagues can use the same)
why you have it (so that you can detect/debug mistakes)
where it comes from, and where it is placed (so that you can know and understand the project structure)

With a purely package based package manager like pip or NPM, the granularity is on the module/package level. If you know which module you have, then you implicitly also know all the files.
With CMSIS it is not that simple, since the file set is not static for a component (file-based conditions, RTE connection, Generated components).

Great points, the lock file I was proposing is only for CMSIS Components and Packs. There is a lot of information missing that would need to be in Solution/ Project File and for that matter in the source files. I came at this from the perspective of what do we need for a Component Manager for CMSIS. I was hoping that breaking down the problem into the different concerns of Packaging and Project might make the tools more extensible and flexible.

Differentiating between "user required" components and those being selected to satisfy dependencies resonates with me. Considering the situation that there maybe choices in resolving dependencies, these user decisions would be recorded in the lock file, which means that the lock file becomes a mandatory project file or am I missing something?

Yes, my suggestion was to record user decisions in the lock file and not in the csolution/cproject files. So while the lock file is not perhaps mandatory in all cases (e.g. a generic example project) it would be needed for most situations.

I am wondering whether we could record such components as "secondary components". Meaning they could be "excluded" from build in case they are no longer showing in the dependency list. When the users selects a component, there is a choice whether the component is required by the user's code (e.g. a certain USART interface is called directly, or to satisfy an I/O component's requirement to print to a terminal).

I think the "secondary components" is the same concept as the dependencies. If a component is being added to resolve a dependency then it would be a "secondary component", but there should also be an option to make it a "primary component" even if it happens to satisfy a dependency requirement.
From a component management perspective I think it would be clearer if unused components and packs were removed from the definition.

My suggestion: introduce a "log" file that lists all important information about a csolution based application in one file. The information could include:

packs used

components used, with information about:

required components, which would indicated other components that are requested by conditions of that component
required-by components, which would indicated other components that request this component by conditions
pack indicates the software pack that defines the component

I think this information is very similar in content to the lock file format for components https://github.com/Open-CMSIS-Pack/devtools/issues/119#issuecomment-1180261244, although the organisation is different. Rather than using required and required-by a tree structure is used to convey the relationship between components.

@ReinhardKeil

After reviewing this issue, there might be an intermix of different things:

a "log" file that lists all important parameters about a csolution/cproject
a "lock" mechanism that protects from accidently modifying properties

Yes and no for me, all information that is put in the file is also functional, meaning that tools should use this data to understand the project.

My ideal view of the future is a simplified flow where cbuildgen doesn't have to understand:

the various details on how to resolve a component
the future flexibility options introduced for RTE file placement, or PLM in general

cbuildgen should simply by inspecting the lockfile be able to figure out which files it should pick and where they are located in the project.
For example, imagine that we in the future add a special property for the YML on where to place a specific component, today this flexibility also needs a reflection in CPRJ.
If cbuildgen only consumes the lockfile for component files, then it can trust that the files are already there.
So I would like to also streamline the lifecycle of our tooling to avoid re-implementing every flexibility feature we will introduce in the future.
Today the flow is
YML => csolution.exe => { PLM, RTE, GeneratedComponents, CPRJ } => cbuildgen.exe => { PLM, RTE, GeneratedComponents, CMakeLists.txt }

I would love it if it could be simplified to
YML => csolution.exe => { PLM, RTE, GeneratedComponents, Lockfile } => cbuildgen_new.exe => { CMakeLists.txt }

# with also a
CPRJ => cprjconvert_new.exe => YML

Because this means that only one tool need to consider PLM and dealing with flexibility of file placement etc (csolution.exe).
This streamlining is a bit of work I agree, but I would be happy to work in this direction.

I believe this is somewhat a duplicate with #434 -> suggest to close it.

I agree, lets close this one and continue in #434 , for me the cbuild.yml covers most of the discussion (if not all) so far


[ACCSEC-19360] Improve coverage

Jira Ticket

ACCSEC-19360

Description

Improve coverage

Testing

[x] Added unit tests
[x] Ran unit tests successfully
[ ] Added documentation for public APIs and/or Wiki

          1 Warning

:warning:
The Pull Request summary does not contain the commit message convention

  Generated by :no_entry_sign: Danger


Support IDE to recognize the $OUT_DIR generated Rust files

how to?
eg, in the example
pub mod hello_world {
    include!(concat!(env!("OUT_DIR"), "/helloworld.rs"));
}

the actually included file is
rpc-server\target\debug\build\tower-grpc-examples-147fe1cec4bcfebf\out\helloworld.rs

How to let IntelliJ can jump to this file?

How to let IntelliJ can jump to this file?

Tell them to implement the Language Server Protocol so RLS can do it for them, as it apparently does in Visual Studio Code? :slightly_smiling_face:

This issue is not specific to tower-grpc, and is rather a problem of the particular IDE.


Add Funkwhale

https://www.funkwhale.audio/

Has Funkwhale started using Podcasting 2.0 tags? :tada:
Do you have more info?

Oh, does this project only take Podcasting 2.0?

You don't have to use any of the tags. Do use any of the Podcast Index APIs?

We list apps/platforms that use either 2.0 tags or the Podcast Index API in some fashion.

Nevermind then.


Update instructions to clone in CONTRIBUTING.md

This is a contribution for the open-ended issue in #473. I faced some difficulty in cloning and submitting changes when I first started contributing. The instructions are not clear for submitting a Pull Request from a local copy, I have updated it based on the problems I faced.

@lacabra I have updated the instructions to create a Pull Request for both the cases in commit c2c0d74.


Changing SVG name to *-svg.svg

Preview SVG use standard SVG names.

Please DO NOT MERGE, I am still testing the built artifacts locally.
Thanks!

This PR is not necessary anymore.


changelog.rst: Update it

Up to date: 5085682d (Merge pull request #426 from byte-physics/mb/feature/6-compilation-test, 2023-03-15)

@MichaelHuth @Garados007 Please have a look.


Other possible auto syllabification issues

The automatic syllabification feature is nice. But it seems to be missing some easy breaks, and I haven't been able to determine why. (Either that, or I'm misunderstanding what | is supposed to signify.) Some seem to have to do with the glottal stop, and others with the stress marker, but I haven't found a pattern to it yet. Some examples from Input / Varieties / Wordsː
'bi|ta
'?|u.ru
|mamaː˦ ˨|
|'ka|mi
|ɾuɾu'naʲ˦|

The bar character (|) is used to mark the stem. Cog will only use the stem when comparing and ignore the prefix and suffix. In IPA, syllable breaks are marked using the period character (.). If you look in the Varieties view, you will see that Cog has inserted gray syllable break markers to show how it has syllabified a word. If there is already a boundary marker of some type at the syllable break (e.g. a stress marker), Cog will not bother to add the syllable break marker.
If a word already contains syllable breaks, Cog will not attempt to syllabify it. Cog will also recognize tone letters as syllable breaks. In other words, Cog will not syllabify a word if it contains a period or tone letter character in it. If all of the syllable breaks are not specified in these words, you will need to add them manually. I hope that clarifies what is happening.

It does clarify. Thanks.
I went through the doc before writing this up. I don't think there's
anything there explaining this. If it's not there or hard to find, I
think I would consider this a documentation bug.


Refactor plugin shutdown

Gracefully stop the lumberjack server and make sure any frame in transit
will be resend.
require https://github.com/elastic/ruby-lumberjack/pull/13

@jsvd a lot less of code to review.

@jsvd did I have answered all your concerns here?

tests pass but a "real life" test using this pr, ruby-lumberjack master and logstash 2.0 receiving events from logstash 1.5.4 failed:

2015-10-08T21:52:52.123Z Joaos-MBP.lan Hello world!
2015-10-08T21:52:52.123Z Joaos-MBP.lan Hello world!
2015-10-08T21:52:52.123Z Joaos-MBP.lan Hello world!
2015-10-08T21:52:52.123Z Joaos-MBP.lan Hello world!
^C2015-10-08T21:52:52.123Z Joaos-MBP.lan Hello world!
2015-10-08T21:52:52.123Z Joaos-MBP.lan Hello world!
SIGINT received. Shutting down the pipeline. {:level=>:warn}
2015-10-08T21:52:52.123Z Joaos-MBP.lan Hello world!
2015-10-08T21:52:52.123Z Joaos-MBP.lan Hello world!
2015-10-08T21:52:52.123Z Joaos-MBP.lan Hello world!
Lumberjack input: unhandled exception {:exception=>#<LocalJumpError: unexpected return>, :backtrace=>["org/jruby/RubyProc.java:271:in `call'", "/Users/joaoduarte/new_plugins/logstash-input-lumberjack/lib/logstash/inputs/lumberjack.rb:111:in `invoke'", "org/jruby/RubyProc.java:271:in `call'", "/Users/joaoduarte/projects/ruby-lumberjack/lib/lumberjack/server.rb:323:in `data'", "/Users/joaoduarte/projects/ruby-lumberjack/lib/lumberjack/server.rb:305:in `read_socket'", "/Users/joaoduarte/projects/ruby-lumberjack/lib/lumberjack/server.rb:247:in `data_field_value'", "/Users/joaoduarte/projects/ruby-lumberjack/lib/lumberjack/server.rb:158:in `feed'", "/Users/joaoduarte/projects/ruby-lumberjack/lib/lumberjack/server.rb:263:in `compressed_payload'", "/Users/joaoduarte/projects/ruby-lumberjack/lib/lumberjack/server.rb:158:in `feed'", "/Users/joaoduarte/projects/ruby-lumberjack/lib/lumberjack/server.rb:298:in `read_socket'", "/Users/joaoduarte/projects/ruby-lumberjack/lib/lumberjack/server.rb:283:in `run'", "/Users/joaoduarte/new_plugins/logstash-input-lumberjack/lib/logstash/inputs/lumberjack.rb:110:in `invoke'", "org/jruby/RubyProc.java:271:in `call'", "/Users/joaoduarte/projects/logstash/vendor/bundle/jruby/1.9/gems/concurrent-ruby-0.9.1-java/lib/concurrent/executor/executor_service.rb:515:in `run'", "Concurrent$$JavaExecutorService$$Job_290572486.gen:13:in `run'"], :level=>:error}
Lumberjack input: unhandled exception {:exception=>#<NoMethodError: undefined method `run' for nil:NilClass>, :backtrace=>["/Users/joaoduarte/new_plugins/logstash-input-lumberjack/lib/logstash/inputs/lumberjack.rb:110:in `invoke'", "org/jruby/RubyProc.java:271:in `call'", "/Users/joaoduarte/projects/logstash/vendor/bundle/jruby/1.9/gems/concurrent-ruby-0.9.1-java/lib/concurrent/executor/executor_service.rb:515:in `run'", "Concurrent$$JavaExecutorService$$Job_290572486.gen:13:in `run'"], :level=>:error}
Logstash shutdown completed

1.5.4 was using the bundled version of the input or the master branch?

@ph bundled version. is that reason enough to trigger these bugs on the server side?

 The problem and the fix is really simple. :palm_tree:
To test this make sure you have continuous event coming into logstash.
 If the proc you are calling is doing a return the parent function need to return something too if it doesn't you will get the LocalJump error.
Two way of fixing this:

using break (this is what I did)
make change invoke method to do return block.call

@jsvd this should fix the problem you had before. :dancer:

LGTM


"get all" command yields image download filesize that doesn't exceed 185bytes...

What steps will reproduce the problem?
Using get all.
What is the expected behavior? What do you get instead?
Normally it should download all the files without issue, but not a single one of them completes.
How often does this problem occur?
Always
What version of the program are you using? On what operating system?
5.4.2
Please provide any additional information below
I really don't understand the problem here.

Which source does this happen on?

Derpibooru, and I'm using my api.

Also, on windows 10 64 bit

Could you upload one of those files here?
Or directly put its contents here (by opening it with notepad). There must be some server error within, because I can't reproduce on my end.


Configure Evil-Sneak for F as in Clever-F?

Thanks for sharing this plugin!
Although your plugin works for me, I would like to have same thing as Clever-F.
I wonder if it's possible to emulate same behaviour as in Clever-F?

Not sure if you're still using this plugin, but native Clever-F style repeating has been implemented a while ago and evil-snipe-active-mode-map has been removed.
You can either replace evil-mode's native f/F/t/T/;/, functionality with evil snipe (which also enables evil-snipe repeating with s/S/f/F/t/T/;/,) like so:
(evil-snipe-replace-evil) ;; replaces evil-mode's f/F/t/T/;/, with snipe
Or just enable s/S repeating with:
(evil-snipe-enable-sS)    ;; enable repeating with s/S


Added Screenshot Function

Implemented #26 using html2canvas
I really needed that function right now, so I added it quickly.
After clicking the new "Download"-Button some CSS-Styles are temporarily rewritten to allow html2canvas to capture the whole preview in a single screenshot.
I had some other method in mind first but using html2canvas it was surprisingly easy to achieve a solid solution.
~~

Awesome, thanks for this! I'll take some time tomorrow/the weekend to review & merge this.


No way for buyer to get refund if seller withdraws listing after accepting an offer

Steps:

Seller: create a listing
Buyer: make an offer
Seller: accept the offer
Seller: withdraw the listing
Buyer: visit "My Purchases" and click on the purchase for the withdrawn listing

At step 5, as the buyer, I expect to see a page that lets me withdraw the offer, so I can get my offer refunded to me. Even better would be an automatic refund when the seller withdraws a listing with an accepted offer. This would involve less work for the buyer, and it seems fair for the seller to pay the gas for the refund.
Instead, what I see when clicking on the purchase is:

The only indication that the listing has been withdrawn is somewhat hidden in the lower right corner of the purchase page:

cc @micahalcorn @nick

Is that a DApp UI change only or does this require a contract change as well ?
Quickly looking at the contract code, the withdrawOffer reads the listing from storage but when a listing is withdrawn, it does get deleted it from storage... See code. So looks like that would be a problem...
We could fix in DApp only by not allowing a seller to close a listing while there are accepted offers. But I would not be surprised this comes up during the auditing if we don't fix in contracts as well ?

Marking as P0 for close tracking until we decide course of action.

The contract supports refunding the buyer in this scenario.

One question is whether or not sellers should be able to withdraw listings that are subject to current offers. Right now, that is their only option to remove listings from public view. In the future, we will probably want the ability for a seller to update a listing with a new quantity available but leave it intact for future availability.
More generally, I don't think that buyers are supposed to be able to withdraw an offer after it is accepted, are they? In the case of a withdrawn listing, does the offer still "work"?
On a separate note, we have a long-term plan for replacing that status card that is "hidden" and misleading right now.

Yea the offer will still work if the listing is withdrawn.  A buyer can withdraw an offer a) if it has not yet been accepted or b) if it has been accepted, but the listing has been withdrawn. So it's not in the seller's interest to withdraw a listing unless any outstanding offers have been finalized.
On withdrawing a listing... right now that is only doable by the depositManager - but for version 1 the seller is also the depositManager. In the future, we could potentially have an Origin depositManager that will only let sellers withdraw listings if there are no open offers.

@nick in my experience testing this, the funds do not get released to the seller as I would expect.
Steps To Reproduce

Create Listing (User A)
Make Offer (User B)
Accept Offer (User A)
Close Listing (User A)
Complete Sale (User B)

In this scenario, with a listing price of 1.00000 ETH, User B's wallet balance is reduced by 1.00000 ETH + some gas and User A's wallet balance is lower than it was at the beginning (due to gas cost).
Also, all references to the seller now return 0x0000000000000000000000000000000000000000, which is probably a secondary concern.
I can confirm that we don't want the buyer to be able to withdraw an accepted offer that the seller may be depending on. We can prevent the seller from withdrawing a listing that is subject to current offers via the DApp, but it seems like the contract may not be working as intended.

Due to the current UX confusion with statuses - close, [in]active, sold, pending, offered, accepted, disputed, etc - I think it’s reasonable to expect people to withdraw them in an effort to prevent other purchases or remove their listings from the home page.
I haven’t confirmed, but it sounds like our UI might also be broken in the event that a finalized offer’s listing is withdrawn.

Since we are getting super close from our launch, I'd be inclined to go for the simplest option proposed by @nick which is to not delete a listing from blockchain storage when a seller withdraws.
It means the seller will have to pay a little bit more gas to withdraw the listing (since we won't get gas back anymore for deleting data from storage), but imho that's totally acceptable for V1.
Does that sound good to everyone ?

Not deleting the listing sounds good to me.

Pushed OriginProtocol/origin-js#581 to address this.

Fixed by origin-js PR 581.


Add message indicating how long the password will live in the clipboard

Having an indication of how long we are going to wait before clearing the clipboard is useful to know before you go and copy another piece of data to your clipboard, only to lose it x amount of seconds later.

Current coverage is 79.33% (diff: 100%)

Merging #110 into master will increase coverage by 0.02%

@@             master       #110   diff @@
==========================================
  Files            18         18
  Lines          1015       1016     +1
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits            805        806     +1
  Misses          210        210
  Partials          0          0

Powered by Codecov. Last update e15742c...7d018b4

Thanks for your contribution @leonjza


Fixed Array[](start : Int, count : Int)

If we try to convert Ruby nils into Crystal exceptions, then Array(Int32).new[0,-1] should raise.
This is fixed by moving to the top of method, that simplifes the next line and allows to move one of returns higher.

I think this makes sense, :+1:
I guess in the midterm we should move the main logic for these overloads to something like at, fetch or slice with yielding behaviour and provide raising [] overloads and nil-returning []? overloads.


MongoDBAtlas Vectorstore Timeout

Describe the bug
When storing with MongoDBAtlas Vectorstore, it takes forever to run, causing a time out.

I found the issue:
The issue is that if we have many documents, then it calls "MongoDBAtlasVectorSearch" every time a new document is added to the documents list. It should be moved out of the loop, and let documents append all documents first.


Request limit

Added limit support in get_all()

Coverage increased (+0.03%) to 95.736% when pulling c700e470c21b1087180e882700e9f855f8b44843 on request-limit into b400758d9127713946a31187fda8d9d67c1c2861 on branch0.3.2.


WRKLDS-650: e2e: deploy the operator from the pipeline built image

Deploy the secondary scheduler operator from a PR built image.
This way any change made to the operator gets tested as part of a PR.
Note: IMAGE_FORMAT env is deprecated. Once the env is gone it can be replaced by RELEASE_IMAGE_LATEST which contains the registry as well.

/lgtm


Update font-sharetechmono-nerd-font-mono to 1.1.0

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} left no offenses.
[x] The commit message includes the cask’s name and version.

Additionally, if updating a cask:

[ ] sha256 changed but version stayed the same (what is this?).
I’m providing public confirmation below.

Thank you for the contribution. It was merged directly as 09a8b76b89bcf3b64ba11cec762b45df58ecbef9. Your contribution is still credited to you.


Overview view: Recent activity should pull from audit trail endpoint

@giseleblair do we have a link for endpoint for this ? thanks


redux store out of sync store().getState() with state from redux logger

Hi,
I'm using your starter razzle and I have problem with store. Everything working great, initialState creating on server received by window.initialState on client.  Problem starting when I whant to get current store by store().getState in my App.js
I have the same logic like your example with-redux
In this example CLIENT  is the store().getState() the second underline it's from redux logger

It looks like the store().getState() received always initialState.
react: 16.2.0
redux: 3.7.2
react-redux: 5.0.6

It is possible to create new store on client side with initialState ? so we can dispatch store on client side and access in whole component in app by store().getState() because now when I use store().getState() I create new store...


"UpdateLiveStats" gives wrong info

Up for less than 3 min, and already over 2 million XP.
Reproduced on Windows and Mac.
Visited 11,840 stops | Uptime : 0:02:42 | +2,390,550 XP | 52,993,466 XP/h | Earned 806,566 Stardust | 449.77km walked

Sorry, didn't see the previous one.


Original i8n Angular https://angular.io/guide/i18n

Is your feature related to a specific framework or general for this extension
It is specific to Angular
Is your feature request related to a problem? Please describe.
Do you support Original i8n Angular https://angular.io/guide/i18n  ? @angular/localize ?
Describe the solution you'd like
I see in the frameworks list Angular  with 2 packages (

Angular(ngx-translate)
@ngx-translate/core

Angular(transloco)
@ngneat/transloco

)
Should support also @angular/localize

Hi @ignatandrei. This is actually been considered in the very early stage #114. But however I am not good at dealing XLFFs. So if anyone interested in this, PRs are welcome :) Thanks!

Please continue in #114


Make better examples

Make examples that are simple and elegant. There should be no examples that are embarrassing.
If examples are embarrassing, improve the API to make the example more elegant.

Add examples to iterators in Forest Node struct

Request: an example of using XPath to extract something simple, like a single text node, from a Forest.

Great idea, but the Forest module is in the process of being replaced by a (hopefully) better tree implementation that uses strong and weak references to maintain parent/child relationships.
Once that code is ready, I'll write up an example along the lines you suggest.

Since this section of the code is getting rewritten, I won't depend on this code. But as part of learning how it works today, I came up with this example of using XPath but not XSLT. Recording here for posterity. If there's a better place, let me know.
fn test_xrust_xpath() {
    let parsed_expr = xpath::parse("/child::a/child::*");
    assert!(parsed_expr.is_ok());
    let xpath = parsed_expr.expect("Error parsing expression");
    let mut f = Forest::new();
    let input_doc = f.grow_tree("c").expect("XML parse failed...");
    let doc_node = f.get_ref(input_doc).expect("tree doesn't exist!").get_doc_node();
    let output_doc = f.plant_tree();
    let evaluator = Evaluator::new();
    let result = evaluator.evaluate(
        Some(Sequence::from(doc_node)), // context
        Some(1), // position
        &xpath, // XPath
        &mut f, // forest
        input_doc, // source document
        output_doc); // result document
    assert!(result.is_ok());
    assert_eq!(result.expect("Evaluation error").to_xml(Some(&f)), "c");
}

Thanks for that. It covers the current code using the Forest module.
Do you have any suggestions for how the API can be improved?
For example, the code I'm developing now defines a "Node" trait for both the document and nodes (unlike Forest which has separate Document and Node objects). This trait could define an "evaluate XPath expression" method that sets the self object as the context for the expression. Something like:
let source_doc = XML::from("<c>d</c>")
    .expect("unable to parse XML");
// Start with the document root node and evaluate an absolute path
let result1: Sequence = source_doc
    .xpath("/child::a/child::*")
    .expect("unable to evaluate XPath");
// The context will be a node and evaluate a relative path
let result2: Sequence = result1
    .xpath("child::*")
    .expect("unable to evaluate XPath");
assert_eq!(result2.to_xml(), "<c>d</c>")

Thoughts?

I like this a lot.
It would be nice if the new Forest implementation could be used standalone, or along with an XPath (or XSLT/XQuery) module that adds greater capability.
There would be a flexible set of ways to serialize a Sequence too, right? (Here is where Canonical XML might come in.)
Another question I had about the earlier example: there should be some way to easily set up / modify the static context, right? In particular, the set of builtin functions available...

An example has been added to the dev branch, named 'issue-30'. It demonstrates the use of the new transformation engine to evaluate an XPath expression on a source XML document without the use of XSLT.

NB. right now it is in the branch 'new-features-2023-11-28'. This branch will soon be merged into the dev branch.


Chrome browser: Token metadata API doesn't expand to show the available API's on selecting Tokens.

https://docs.hiro.so/metadata.
This seems to be working fine on Safari. I see the issue on the Chrome browser.
https://github.com/hirosystems/docs/assets/55154433/49bf6bb4-17ca-4612-8c92-ba596ff9f7bc

Works on my machine, but I fixed a scroll issue that only occurs when loading the site directly (via link), but not when loaded via the navbar. #404


I think there is infinite loop getting location data, is it okay?

First of all, I really thank you for this really nice app. I learned something from this app making my own running fitness app.
Issue

This app stop tracking locations in 5 minutes when the phone goes to sleep mode. Just like this issue  https://github.com/expo/expo/issues/10712
When phone awake from sleep mode, The tracking goes crazy. Not stop before I press the reset button several times.
I think there is an infinite loop getting location data. And wonder there is no problem with it..?

Background info
I'm running into this issue https://github.com/expo/expo/issues/10712
when I run this sample app. It worked well, but not in sleep mode. Like I said above issue, It stops tracking after 3~ 5 min.
But this app looks different from mine.
when I restarted this simple app from sleep mode, its tracking logs go crazy, and not stop before I press the reset button several times.
At first, I thought it store the tracking locations that have not tracked while the phone was in sleep mode.
but it isn't. it just looked like storing several same locations.
So, I looked into the code and found nothing looks strange but this code below
I think this goes infinite loop. Is there no problem with this..?
(onPollStorage update locations, locations update onPollStorage, new onPollStorage function trigger useEffect, and useEffect run onPollStorage)
and I wonder is it related to that number 2 issue?
https://github.com/byCedric/office-marathon/blob/2ddfbb571e78b02957b8d2f3a04f473d23c83048/src/services/location/index.ts#L72-L92

Oh, that's definitely possible! I kind of made this app in 2 hours, so it's not my best code, especially the part where it polls the location data from storage. I'll try to replace that code with something more event based, without polling.
As for the sleep stuff, I'm not able to reproduce it. I have used this app for a day, and it roughly registered most of the coordinates. It registered about 150 coordinates, which translates to a usage time of a rough 12.5 hours ((150 * 5) / 60 = 12.5).

Oh, that's definitely possible! I kind of made this app in 2 hours, so it's not my best code, especially the part where it polls the location data from storage. I'll try to replace that code with something more event based, without polling.
As for the sleep stuff, I'm not able to reproduce it. I have used this app for a day, and it roughly registered most of the coordinates. It registered about 150 coordinates, which translates to a usage time of a rough 12.5 hours ((150 * 5) / 60 = 12.5).

@byCedric
I really thank you for your effort. 👍
But the problem keeps happening and I cannot find anything from google.. So I came back again.. I'm sure you know something.
Would you try

timeInterval: 1000,
android 10 simulator
push start tracking
turn off the simulator to sleep mode
and wait 5 minutes?

I'm sure you can reproduce it!
just background..
I set the time as 1000 ms ( because I need to track a running person )
And I think this work on ios, not terminating process or app on sleep mode ( I tested about 1hour )
but on Android
On Android 10 simulator, this stops on sleep mode. For me, it logs about 72 locations and stops.
If I get out from sleep mode, It keeps logging.. ( for some reason It goes crazy.. )
The main problem is it stops tracking location on sleep mode..
and
for some reason, I think expo SDK40 gives me a permission error like this below
https://forums.expo.io/t/sdk40-android-unhandled-promise-rejection-error-not-authorized-to-use-background-location-services/46508/4
This makes me really exhausting. I want to know is it about google policy So I should wait for a while until expo team deals with it? or it's just a problem of me?

@byCedric
I really thank you for your effort. 👍
But the problem keeps happening and I cannot find anything from google.. So I came back again.. I'm sure you know something.
Would you try

timeInterval: 1000,
android 10 simulator
push start tracking
turn off the simulator to sleep mode
and wait 5 minutes?

I'm sure you can reproduce it!
just background..
I set the time as 1000 ms ( because I need to track a running person )
And I think this work on ios, not terminating process or app on sleep mode ( I tested about 1hour )
but on Android
On Android 10 simulator, this stops on sleep mode. For me, it logs about 72 locations and stops.
If I get out from sleep mode, It keeps logging.. ( for some reason It goes crazy.. )
The main problem is it stops tracking location on sleep mode..
and
for some reason, I think expo SDK40 gives me a permission error like this below
https://forums.expo.io/t/sdk40-android-unhandled-promise-rejection-error-not-authorized-to-use-background-location-services/46508/4
This makes me really exhausting. I want to know is it about google policy So I should wait for a while until expo team deals with it? or it's just a problem of me?


Prevent delete on forbidden move

This PR is supposed to fix #705.

A little git rebase to fixup/squash may be required before merging :-].

Just made the history a bit cleaner.


STY: confirm that extra whitespace for table formatting is allowed

Reference issue
Closes gh-12367
What does this implement/fix?
gh-12367 asked that the linter allow extra whitespace to improve table formatting. We have a different linter now that allows the extra whitespace, so we might be able to close the issue.
Additional information
That said, it is also not complaining locally about any of the usual whitespace rules:
stats.linregress(  x,  y ,x==  y )#OK

If we're not OK with that, maybe we need to adjust the issue to be about enforcing these sorts of rules except in the context of tabular data.

stats.linregress(  x,  y ,x==  y )#OK

These are covered by various preview rules in ruff, e.g. https://docs.astral.sh/ruff/rules/whitespace-after-open-bracket/ and https://docs.astral.sh/ruff/rules/whitespace-before-close-bracket/. If you send a PR to add some of those rules I can review. The lines to touch in the config file are https://github.com/scipy/scipy/blob/187d6b6432f81c7b3e35f4a6af91157e0490f6a2/tools/lint.toml#L15-L22.

In particular, you will need to follow the advice at https://docs.astral.sh/ruff/preview/#selecting-single-preview-rules to only select some preview rules.

Thanks. I didn't mean to get into adding style rules right now; just looked like gh-12367 could be closed. So I suppose we can either keep this PR as a small formatting improvement or close it. Your choice!


Correct alignment calculation in ssl3_setup_write

The alignment calculation in ssl3_setup_write incorrectly results in a
value of 3. The maximum alignment actually used in do_ssl3_write is 7
bytes - so there is a potential to overrun the buffer by up to 4 bytes.
Fortunately, the encryption overhead allowed for is 80 bytes which
consists of 16 bytes for the cipher block size and 64 bytes for the MAC
output. However the biggest MAC that we ever produce is HMAC-384 which is
48 bytes - so we have a headroom of 16 bytes (i.e. more than the 4 bytes
of potential overrun).
Fixes #11766

As it's just a "lucky accident" that this isn't a real (dangerous) bug, should the commit explicitly thank the person who reported it?

As it's just a "lucky accident" that this isn't a real (dangerous) bug, should the commit explicitly thank the person who reported it?

Good point. Done.
@nageshshegde - if you would rather have your real name in the commit rather than your github id - please let me know what it is!

Thanks for the fix.
Regards,
Nagesh Hegde

I updated the commit to mention Nagesh's proper name.

24 hours has passed since 'approval: done' was set, but this PR has failing CI tests.  Once the tests pass it will get moved to 'approval: ready to merge' automatically, alternatively please review and set the label manually.

(Travis failure is the unrelated CHANGES.md markdown nit.)

(I don't think it would always be 3.)

Err - yes it will?
The align calculation was previously:
align = (-SSL3_RT_HEADER_LENGTH) & (SSL3_ALIGN_PAYLOAD - 1);

These are fixed constant values* which simplify to:
align = (-5) & (8 - 1) = 0xffff...fb & 0x07 = 3

(* Strictly speaking the header files do allow you to define your own value of SSL3_ALIGN_PAYLOAD - but I'm not expecting that anyone actually does this - or at least very few). I could rewrite the commit message in terms of these macros if it makes things clearer, i.e. change the first para to this:

The alignment calculation in ssl3_setup_write incorrectly results in an alignment allowance of (-SSL3_RT_HEADER_LENGTH) & (SSL3_ALIGN_PAYLOAD - 1) bytes. This equals 3 in almost all cases. The maximum alignment actually used in do_ssl3_write is (SSL3_ALIGN_PAYLOAD - 1). This equals 7 bytes in almost all cases. So there is a potential to overrun the buffer by up to 4 bytes.

Right, I meant that I could define SSL3_ALIGN_PAYLOAD as, um, 2, if I was feeling particularly obtuse.
I would be happier with the new proposal for the commit message, but you can use my approval with either old or new version.

Pushed to master and 1.1.1. Thanks.


Collect fasteners and wiring images

Check dataset repos or collect images by my own.
List

https://www.openml.org/search?type=data
https://www.kaggle.com/datasets
https://archive.ics.uci.edu/ml/index.php
https://registry.opendata.aws/
https://datasetsearch.research.google.com/
https://msropendata.com/
https://github.com/awesomedata/awesome-public-datasets
https://data.gov.in/
https://www.data.gov/
https://www.opendatani.gov.uk/
https://data.europa.eu/euodp/data/dataset
https://www.visualdata.io/discovery

I found dataset.
Maybe useful.
https://www.mvtec.com/company/research/datasets/mvtec-screws (CC license)

Wiring: https://www.kaggle.com/zanellar/electric-wires-image-segmentation (42GB)


Set up NPM package to be instalable as a tool

Currently, if npm install is run on psychic-octo-robot, the "executable" doesn't work properly, and complains about not being able to find the desired path.
This could be a platform-specific issue, but probably shouldn't be.
Look at grunt and mocha for package examples that work as executables when installed

Fixed with #101


detect_drop_off_cliff algorithm

Added an experimental detect_drop_off_cliff algorithm.  The algorithm flags a datapoint as anomalous if the average of the last ten datapoints is <trigger> times greater than the last data point.  This algorithm is most suited to timeseries with most datapoints being > 100 (e.g high rate).  The arbitrary <trigger> values become more noisy with lower value datapoints, but it still matches drops off cliffs.
A real world timeseries is added as an example that experiences a drop of cliff pattern that the standard crucible (skyline) algorithms do not detect.
There is full info in the examples/detect_drop_off_cliff directory relating to the resultant crucible images from each algorithm, along with the original json data set too.
This has been tested on a lot of metrics and does prove effective at a detecting drop off cliff events on high rate constant, but variable metrics very well, with very few false positives.  It gets more noisy the lower the data range in the sample, but still works.  It only works on data sets with a positive integer range.
Testing welcome :)

More testing and usage reveals that it could be better, more work is being done on the <trigger> side.  So please hold off on any testing (unless anyone really wants to).
The ultimate aim here really being to detect a drop off cliff in a timeseries with consistently high (but variable) values like the example, but also a timeseries with a range of say 0.0 to 3.6 like the significant wave height (hm0) metric in swell modelling.


Fixing search bug by adding a trailing "/" to the end of searches.

Could you add a test to make it fail before the change you made?

Current coverage is 100% (diff: 100%)

Merging #90 into master will not change coverage

@@           master    #90   diff @@
====================================
  Files          63     63
  Lines        1844   1844
  Methods         0      0
  Messages        0      0
  Branches        0      0
====================================
  Hits         1844   1844
  Misses          0      0
  Partials        0      0

Powered by Codecov. Last update 31fa2f5...127302c


ANDROID: PayloadData is always empty onNotificationClicked when app is in foreground/background

@mirzemehdi When the app is in background (and even when the app is foreground, I also tried to be sure) so when I click on the notification, the method onNotificationClicked is triggered and the payload data is empty.
It happens to me in Android and I did set up everything in my MainActivity.kt so I do not know why it happens... And before clicking on the notification, the method onPayloadData is also triggered and my PayloadData is full.
I saw on another issue that it happens to someone and you fixed the issue in the 0.6.0 version. So I am sorry if I did something bad but I paid attention to what you wrote in your documentation.

The workaround I found is that in my class when I listen to the different methods, I set a variable like private var latestPayload: PayloadData? = null and inside the method onPayloadData I set my variable latestPayload to the data variable from the parameters, so that when I trigger the method onNotificationClicked I can get my payload data from my custom variable and not from the data parameter that is empty. :)

Thank you for workaround @jvondermarck. But it should work without any workarounds actually.
Can you please attach your full payload data that is printed on logs?
Also these should be called on launcher activity:
override fun onCreate(savedInstanceState: Bundle?) {
   super.onCreate(savedInstanceState)
      NotifierManager.onCreateOrOnNewIntent(intent)
      ...
    }

    override fun onNewIntent(intent: Intent?) {
        super.onNewIntent(intent)
        NotifierManager.onCreateOrOnNewIntent(intent)
    }


Windows Spyder: taskbar duplication error

Description

What steps will reproduce the problem?

When I execute the spyder, it generates another tab in the taskbar.

What is the expected output? What do you see instead?
They should be on the same icon like the other programs

Please provide any additional information below

Version and main components

Spyder Version:  2.3.4
Python Version:  2.7.8
Qt Version    :  4.8.6, PyQt4 (API v2) 4.10.4 on Windows

Optional dependencies
pyflakes >=0.5.0:  0.8.1 (OK)
pep8 >=0.6      :  1.6.2 (OK)
IPython >=1.0   :  3.0.0 (OK)
zmq >=2.1.11    :  14.5.0 (OK)
pygments >=1.6  :  2.0.2 (OK)
pandas >=0.13.1 :  0.15.2 (OK)
sphinx >=0.6.6  :  1.2.3 (OK)
rope >=0.9.2    :  0.9.4 (OK)
jedi >=0.8.1    :  0.8.1 (OK)
matplotlib >=1.0:  1.4.3 (OK)
sympy >=0.7.3   :  0.7.6 (OK)
pylint >=0.25   :  1.4.2 (OK)

Thanks for reporting. This is a duplicate of issue #1983, and @cjrh is trying to solve it on pull request #2185.

It looks like this issue was closed.  However, I am still experiencing it with Spyder 2.3.7 on Windows 7 64-bit and Windows 10 64-bit.

It was closed because it's a duplicate of issue #1983, as I mentioned above and which is still open.


add support for stylelint formatter and vue files

https://stylelint.io/
https://vuejs.org/

Hi @Chiel92
yes, sorry, I did it some time ago and without careful research. I am going to rework integration

Hi @Chiel92
I've fixed incorrect parts

Let's merge this. Thanks!


Fix #461: Add fallback to default paste command

I just found an open tab in my browser about issue #461 and realized that I never got around to do this… So, here we go! This actually turned out to be simpler than what I originally expected to do.
This change basically always enables the typescript_paste_and_format command but moves the check whether the TypeScript formatter could run inside the execution. If it is not possible, then it falls back to the default paste command.
That way, we can safely overwrite the standard keyboard shortcut without breaking paste when TypeScript cannot do this. So we can happily paste into new buffers again—yay!

Hi @poke, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, MSBOT;

👍  Thanks for the contribution!

That was super fast, thanks! :D


Custom str | bytes | bytearray type

Might be useful in a number of scenarios. E.g. parsing custom data types.

Apologies if I'm missing the forest for the trees but Is this issue about creating a type alias, or something more sophisticated?

not really, we need custom methods on inputs to allow any of these types without converting them.
TBH, I'm not sure this is really worth it, I created it before I implemented #287.
I'll close this for now to avoid confusion.


Update cf-typography docs to explain missing italic and demi

Additions

A short note to explain why @webfont-italic now references @webfont-regular and @webfont-demi now references @webfont-medium.

Just realized, this needs a [PATCH] if you want it to be published. The last time we decided to let it ride till the next release the change sat for three months till I made sure it was tagged.

I'm OK with that. I can't condone docs-only releases ;)
Someone could still update gh-pages by building with a linked version of cf-typography, though.

Someone could still update gh-pages by building with a linked version of cf-typography, though.

Do you mean a symlinked version?

Do you mean a symlinked version?

Yes.

That'll be wiped the minute someone else builds with the installed version, which I believe is what happened the last time when I patched in a doc update after realizing it wasn't there.

Fixed.
🤢


Update cache action

https://github.com/actions/cache/releases/tag/v2.0.0

Coverage decreased (-0.2%) to 82.213% when pulling 95cb3b32f8579376b07a5faa40dd86e7ce947ccd on Luni-4:update-cache into 863909bcd6b165975238cf67c2ad887c7ef9ed17 on xiph:master.


Feature/cubed sphere parallel meshgen

Hi @wdeconinck , I'm hoping you can provide me with some sage advice. (I've invited others along in case they can help or are interested).
I'm attempting to implement a multi-PE cubed sphere mesh-generator (this draft PR). And I think I'm having some trouble with the book-keeping. I'm not sure if there's a bug in my algorithm, or gap in my understanding of parallel mesh generators.
The algorithm places cells at the xy grid coordinates, then generates nodes around them. I've put a fairly detailed description of the steps at the top of the  CubedSphereMeshGenerator::generate definition in src/atlas/meshgenerator/detail/CubedSphereMeshGenerator.cc.
When I run it, it seems to make a nice looking mesh in gmsh. Here's an 8 PE mesh of an N24 grid with the equal regions partitioner:

However, if I look at the nodes fields, they come out as garbage. Here's the nodes().ghost() field:

If I run the exact same test on 1PE, everything comes out fine. Here's what the ghost field should look like:

And just for good measure, here's what my remote index field looks like on 1PE:

I wonder if I'm making any incorrect assumptions on the data I need to attribute to nodes and cells:
Here, each cell has:

a unique global index from 1 to nCells
a unique local index from 0 to however many cells are on the partition minus 1. (implied by data order)
a partition ID.

Just to complicate things there are two types of ghost node.

Type-A, which lie on edge and corners. Only one tile can own the edge nodes. This is defined at a global level by the CubedSphereTiles class.
Type-B, which are at the boundaries between partitions. This are defined at a local level and may change with the partitioner.

Each owned and Type-A ghost has:

a unique global index from 1 to nNodes (including edge ghosts)
a unique local index (implied by data order)
a remote index pointing to an owner node, if applicable.
the partition ID of the owner node.

Type B ghost are similar, but they inherit the global ID of the owner node. All nodes also have ghost and flags field values set.
The node global ID order goes: owned, Type-A ghost.
The node local ID order goes: owned, Type-A ghost, Type-B ghost.
I've done my best to figure out what metadata needs to be set at the end, but it was mostly guesswork.
It's also possible I've made an error in case_cubed_sphere_generic_mesh_test in src/tests/grid/test_cubedsphere.cc
It's quite possible I've got a bug in my algorithm, but I need to first make sure that I haven't made any obvious assumptions on how mesh generators are supposed to work.

An update, it's largely working now. Looks like one or two minor bugs to work out, but fields seem to be distributed correctly across PEs.

@odlomax - can you push the correction?

This branch is now ready for review. Marek's cubed sphere partitioner PR #56 need to be merged first.
I've remove the mesh test from /src/tests/grid/test_cubedsphere.cc and added it to /src/tests/grid/test_cubedsphere_meshgen.cc
Test constructs 2 and 8 PE cubed sphere meshes, one with the default cubed_sphere partitioning and the other with equal_regions partitioning. These are then output via gmsh:

To do on next PR:

Add halos
Add halo exchange test

@odlomax - for some reason the code diff between feature/cubed-sphere-base has not updated once feature/cubed-sphere-partitioner2 went in.

@odlomax - for some reason the code diff between feature/cubed-sphere-base has not updated once feature/cubed-sphere-partitioner2 went in.

@MarekWlasak I've just merged feature/cubed-sphere-base into the branch. All tests pass.


fix(github): fix octokit warnings

Short description of what this resolves:
Octokit deprecation warnings
Changes proposed in this pull request:

headers is deprecated and we shouldn't use it.
rejectUnauthorized set to false is a security issue, and we shouldn't bother to find a workaround for it.
https://github.com/shanalikhan/code-settings-sync/blob/f698ce9112d7d80b3db21b71674feed0475307b3/src/service/githubService.ts#L49
The authenticate function is deprecated and we should use the auth option in the constructor of Octokit.
https://github.com/octokit/rest.js#authentication

How Has This Been Tested?

Checklist:

[x] I have read the contribution guidelines.
[ ] My change requires a change to the documentation and GitHub Wiki.
[ ] I have updated the documentation and Wiki accordingly.

The authenticate function is deprecated and we should use the auth option in the constructor of Octokit.

Can you include this also in PR ?

That change it's already in this PR.


The steps to  link a set of related notifications of azure pipeline in teams channel are not provided.so please provide the steps to solve this. https://github.com/MicrosoftDocs/azure-devops-docs/issues/11815

Thank you for your feedback!
The issues in this repo are for documentation feedback.
If you are submitting your documentation feedback issue directly through GitHub, please provide the URL of the article so we can route the feedback to the correct author.
Please report Azure DevOps or TFS software bugs, feedback, or questions in the Azure DevOps Developer Community.

@krishna1733 -- please see https://github.com/MicrosoftDocs/azure-devops-docs/issues/11815#issuecomment-1318150793.
I am closing this issue now.  You are welcome to @ mention me for any followup.  We hope to hear from you again.


add show_package_total option

Description
I found that the package count was degrading the performance of neofetch in my machines, so I added a parameter to optionally disable this particular output.
Features
Add --show_package_total flag to enable/disable the package count display in neofetch.

Wow, it works well on Univalent GNU/Linux!

Oops, I forgot to attach the image what I turned off the option.

This feature already exists in neofetch. You can use --disable <infoname> to disable the detection of a specific item. In this case, you can use --disable packages

You can also turn off package manager detection by editing the ~/.config/neofetch/config.conf (specifically, comment out the info "Packages" packages line)


Add paper planes

About the PR

Adds an alt-verb to fold paper into a plane, and unfold the plane back to paper
Saves the writing/stamp for super discreet communication
Updated sprite to be directional so it looks correct when thrown
Bouncing in the video fixed by stopping momentum on collision
Nyooom

Screenshots

Changelog

:cl:

add: Added paper planes

They seem kind of... excessively bouncy.

They seem kind of... excessively bouncy.

Yea I reduced the friction so they could go far, but not sure how to make them stop on collision. We could increase the friction to reduce the bouncy, but then no yeeting down the whole hallway.

They seem kind of... excessively bouncy.

It's prolly fine and I think it'll lead to people doing funny things with them.

Fixed the bouncing by just killing the momentum on collision.

Use OBS nerd.

Creating another entity and putting the paper inside of that seems unnecessary when you could just modify the paper?

My original thought was that this would be good to prevent writing/stamping the plane, avoid alt-verb priority stuff, and handle the sprite change automatically.
Although thinking more on it now, I'd imagine you could accomplish it by just adding the PaperPlaneComponent and checking for its presence/absence when determining the verbs/sprites/etc.
I can look into changing it to be that way if we think that's the way to go.

sounds good to me

sounds good to me

As part of updating this I think I've also fixed the issue with the NoSpinOnThrow not aligning properly, but not sure how the local vs world rotation works for stuff like shuttles, etc.

needs reviews addressed


Seaching is slow

It takes two seconds to get the search result back for searching for all CS classes. I noticed that the response time is directly proportional to the number of entries returns back.

Search is slow mostly because we make sure to always return live data.
Antplanner is faster because it caches the search results, but the downside to that is the data you get is outdated. I think he updates his cache once a day (? not sure, don't quote me on this). But in any case the numbers you see on AntAlmanac should be the same as what you see on webSOC.
In any case, we have a dope loading gif haha
@devsdevsdevs

Have you considered defer loading live data? Like, return a cached but relatively fresh(like an hour) data immediately so that there's something on the screen that the users can see. Then retrieve the live data and update the page correspondingly.
Faster loading speed can improve user experiences a lot.

Update: the team is talking about it; you got a really good point there!
Thank you so much for the suggestion!

Glad that I can help!

@gitletH I think it's funny how you've come back to work on this feature urself XD

Closing this for now since we've pretty much explored everything in this thread.
But will always continue to improve search speed for a better ux.
Thanks @gitletH


How am I expected to use the search results given??

https://pastebin.com/wzA9uQfN
I get something like this. it isn't a dictionary or a list how am I expected to use the data within it?

solution:
https://www.reddit.com/r/learnpython/comments/kkyhn5/trying_to_use_tweepy_to_search_twitter_not/?utm_source=share&utm_medium=web2x&context=3

This is a list with a single Status object, which is how Tweepy models the Tweet object that Twitter's API returns as JSON.
You can access the JSON with Status._json. Otherwise, you can directly access the attributes of the Status/Tweet object.


Update docs to not set the docker tag in the manifest bundle tag

Our documentation has lines like this:
name: hello
version: 0.1.0
tag: getporter/porter-hello:v0.1.0

We now have a feature where the docker tag of the bundle automatically for you, including the v prefix. Let's encourage people to take advantage of this in our docs by updating them to look like this:
name: hello
version: 0.1.0
tag: getporter/porter-hello

Only update the documentation (*.md and porter.yaml files) in the following directories:

/examples - the examples can be previewed in github only, or in a markdown editor
/docs/content - See our contributing guide for how to preview our website
/workshop - this can be previewed in github or in a markdown editor

all the documentation got updated with pull request #1173.


Set proper Kptfile name when running init in current dir

If running kpt pkg init ., the name of the Kptfile will be set to .. With this change, we instead use the name of the current directory.
Fixes: #687

/lgtm


Change JSON API default port number

We are currently using port 8080 as the default port number for JSON API. Since this tends to be a frequently used value, we should change this to reduce the possibility of collisions. Something like 8083 could work.
We will also want to make changes to downstream locations including docker-compose scripts in this repo and other repos like stargate-mongoose and stargate-mongoose-sample-apps.

@jeffreyscarpenter Currently JsonApi is deployed in astra with port #8181. Will use the same port as default.


Update pods

FMDB: 2.6 → 2.6.2
OCMock: 3.3 → 3.4
Sparkle: 1.14.0 → 1.16.0

Hrm are you using a pre-release version of cocoapods ?

Nope. Just the standard gem version.

haha ok because I just updated my own cocoapods this morning and it was at 1.1.1 😄
do you want to try and modify .travis.yml and put the line before_script: pod repo update above the script line and see if that fixes the build?

Oh my bad it should probably be before_install instead of before_script. Also, does this supersede #774?

#774 should be merged first. ;)

Seems to have worked now.

Yeah... but now #774 is merged there are conflicts :> you might have to rebase it.


[ECS] BreakMethodCallsFixer false positive

While this new fixed makes some nice changes it also makes other changes that are not desired.
		return self::occur(
			(string) $unitId,
			[
				self::KEY_UNIT_PARAMETERS => $unitParameters->toArray(),
			]
		);

The fixer changes it to:
		return self::occur((string) $unitId, [
				self::KEY_UNIT_PARAMETERS => $unitParameters->toArray(),
			]);

... no thanks? ;-)

Could you send failing test case?

Resolved in #676