Unit missing in olevhalf in CMIP6_coordinate.json

Hi,
We wonder whether the unit of olevhalfin CMIP6_coordinate.json  should not be "m", currently it is empty. See (in current version) line 1032 in:
https://github.com/PCMDI/cmip6-cmor-tables/blob/master/Tables/CMIP6_coordinate.json
Currently we have the following trouble while cmorising zhalfo:
! Error: axis 4 (olevhalf, table: Omon): cmor and user units are
! incompatible:  and m

However, if we take unit "m" in olevhalf, then zhalfo is cmorising well.
Regards,
Thomas

Hi Thomas,
Thank you for uncovering this bug.  I am sorry for the trouble you have gone to diagnosing it.  We need to modify the coordinates.json file so that it includes "depth_coord_half".   It will have the correct standard_name, units, etc. for models that use depth as the vertical coordinate (or that are regridded to a depth coordinate.    If you use a different coordinate for your CMIP6 output, please let us know.
More generally, I have reviewed the CMIP6_coordinate.json table and find a number of problems with the handling of the vertical coordinates.  Here is a summary of the problems/issues which need to be addressed:

Add dimension

"depth_coord_half": {
            "standard_name": "depth",
            "units": "m",
            "axis": "Z",
            "long_name": "ocean depth coordinate",
            "climatology": "",
            "formula": "",
            "must_have_bounds": "no",
            "out_name": "lev",
            "positive": "down",
            "requested": "",
            "requested_bounds": "",
            "stored_direction": "increasing",
            "tolerance": "",
            "type": "",
            "valid_max": "12000.0",
            "valid_min": "0.0",
            "value": "",
            "z_bounds_factors": "",
            "z_factors": "",
            "bounds_values": "",
            "generic_level_name": "olevhalf"
},

This will not work, however, unless CMOR3 interprets generic_level_name="olevhalf" similarly to "alevhalf".  This needs to be confirmed.

Remove dimension "olevhalf" because it isn't needed.

Also consider removing hybrid_height and smooth_level coordinates because they won't work without adding orog, zsurf1 and zsurf2 to the following CMOR CMIP6 tables:  6hrlev, AERmon, Amon, CF3hr, CFday, CFmon, CFsubhr, E3hrPt, E6hrZ, Emon, Esubhr.

The following dimensions currently have units = "" but should be defined as follows:
natural_log_pressure units="Pa"
natural_log_pressure_half units="Pa"

Griffies et al, (https://www.geosci-model-dev.net/9/3231/2016/gmd-9-3231-2016.pdf) request ocean output be provided using one of the following coordinates: z (geopotential), z*(stretched depth), p (pressure), or p* (stretched pressure).  I think the CF convention isn't aware of z* or p*, and the cmor table hasn't yet been generalized to handle p, so z is the only option with CMOR.  We can augment CMOR and its table to handle p, z*, and p*, but I want to determine whether or not this is a priority.

Ok thank you for your reply. We indeed use a simple depth coordinate so that's alright. So we wait your update on including depth_coord_half (and the removal of olevhalf). Would this update come rather soon, like within a week or so?
I believe the rest of your points are not directly related to our current issue.
Regards,
Thomas

I've mentioned this in direct e-mail to @taylor13 , but for completeness I note here that the hybrid_height functionality in CMOR works fine for us; we end up with the orog variable in the each output file along with a and b coefficients and associated bounds. If useful I can dig into how this is supplied to CMOR, but it is working.

thanks @matthew-mizielinski for that information.  I'm glad CMOR can write orog along with the variable of interest in each file, as it should. I was afraid it didn't know about that "zfactor" but I was wrong.  That's good.  I've edited point 3 in my long post above so that I no longer suggest removing hybrid_height.

@mauzey1 -- @treerink has noticed a coordinate is missing from the CMIP6_coordinate.json file, and this is holding up their production.  Could we quickly add the depth_coord_half coordinate defined in  https://github.com/PCMDI/cmip6-cmor-tables/issues/237#issuecomment-470656858 and make it available?  Also we should remove the olevhalf coordinate as it shouldn't be needed.  Do we have a "nightly" version of the tables or would we need to make a new release?

@taylor13 I have made a pull requests that adds depth_coord_half to CMIP6_coordinate.json.  The dimension olevhalf appears to come from the data request.
<item altLabel="lev" axis="Z" bounds="no" boundsValues="" coords="" description="generic ocean model vertical coordinate (nondimensional or dimensional)" direction="" isGrid="" isIndex="ok" label="olevhalf" positive="down" requested="" tables="" title="ocean model half levels" tolRequested="" type="double" uid="dim:olevhalf" units="" value=""></item>

When you say "nightly" version, do you mean the latest changes in the master branch of this repo?

Actually, I don't know what I mean.  If, once you've merged the new coordinate.json file, @treerink can access the table at https://github.com/PCMDI/cmip6-cmor-tables/tree/master/Tables (or somewhere else you point us to), then we won't be holding up production.
thanks.

The changes to add depth_coord_half have been merged and are now available at https://github.com/PCMDI/cmip6-cmor-tables/tree/master/Tables

Thanks for adding depth_coord_half to CMIP6_coordinate.json. So closing issue.
Regards,
Thomas

I just recalled that in order to treat "generic" vertical coordinates correctly, I think the CMOR tables referring to olevhalf need to include at the top "generic_levels": "olevel", .  Perhaps because depth_coord_half can be handled like a regular coordinate, it isn't needed in this case.  But I don't really see why it should.  How does it know that depth_coord_half can be used to satisfy olevhalf?
Anyway, I think we need to modify the generic_levels list in tables Omon.json and Oclim.json to read:
"generic_levels": "olevel olevhalf",

Please confirm before changing.  Perhaps @treerink can say whether his code works without this change?

No we had not tested it yet.
With the updated cmor tables, we get the following error now:
C Traceback:
! In function: cmor_variable
!

!!!!!!!!!!!!!!!!!!!!!!!!!
!
! Error: You defined variable 'zhalfo' (table Omon) with axis id 'depth_coord_half' which is not part of this variable according to your table,
 it says: ( time olevhalf latitude longitude )
!
!!!!!!!!!!!!!!!!!!!!!!!!!

So I guess that confirms your hypothesis?

Yes, I  suspect it does.  @mauzey1 : how should we proceed?  Should we just add olevhalf to the generic_levels in tables Omon.json and Oclim.json, and then ask @treerink to retry?  Or is there some local testing we should do to confirm that this is the problem?

I tried testing zhalfo using the following code.
import cmor
import numpy

def main():

    cmor.setup(inpath='Tables',
               netcdf_file_action=cmor.CMOR_REPLACE_3)
    cmor.dataset_json("Test/CMOR_input_example.json")

    table = 'CMIP6_Omon.json'
    cmor.load_table(table)
    axes = [{'table_entry': 'time',
             'units': 'days since 1850-01-01 00:00:00',
             'coord_vals': [15.5, 45, ],
             'cell_bounds':[[0, 31], [31, 62]]
             },
            {'table_entry': 'depth_coord_half',
             'units': 'm',
             'coord_vals': [5000., 3000., 2000., 1000.]},
            {'table_entry': 'latitude',
             'units': 'degrees_north',
             'coord_vals': [0],
             'cell_bounds': [-1, 1]},
            {'table_entry': 'longitude',
             'units': 'degrees_east',
             'coord_vals': [90],
             'cell_bounds': [89, 91]},
            ]

    axis_ids = list()
    for axis in axes:
        print 'doing:', axis
        axis_id = cmor.axis(**axis)
        axis_ids.append(axis_id)

    for var, units, value in (('zhalfo', 'm', 274.),):
        values = numpy.ones(map(lambda x: len(x["coord_vals"]), axes)) * value
        values = values.astype("f")
        varid = cmor.variable(var,
                              units,
                              axis_ids,
                              history='variable history',
                              missing_value=-99
                              )
        cmor.write(varid, values)

    cmor.close()

if __name__ == '__main__':

    main()

This generated the same error that @treerink posted.  However, changing the generic_levels in CMIP6_Omon.json to "olevel olevhalf" didn't get rid of the error.

This is puzzling.  I guess something must be going wrong in the code in lines 1570-1618 of cmor_variables.c . Perhaps @doutriaux1  can help debug.  Why isn't it recognizing depth_coord_half as a valid option for the generic vertical coordinate olevhalf ?

By the way, thanks very much, @mauzey1 for devising the test!  I wonder if trying to write a variable defined on olevel  (e.g., dmso) using the depth_coord works?  It's supposed to, but I don't see any difference between that and a case with olevhalf and depth_coord_half.

I think I've found at least part of the solution:  We need to add a line to the cmor.h file:
#define DIMENSION_OLEVEL_HALF "olevhalf"

(probably placed after line 256).
And in cmor_variables.c following lines 1984-1988:
            if (n == -1) {
                j = strcmp(DIMENSION_ZLEVEL, dim);
                j *= strcmp(DIMENSION_ALEVEL, dim);
                j *= strcmp(DIMENSION_ALEVEL_HALF, dim);
                j *= strcmp(DIMENSION_OLEVEL, dim);

we need to add another line that includes DIMENSION_OLEVEL_HALF.

@taylor13 The bug with olevhalf was being caused by its inclusion in CMIP6_coordinate.json.
https://github.com/PCMDI/cmor/blob/19d6f632dacec5bf43ddcb950c1f1bd1291e8193/Src/cmor_variables.c#L1976-L2023
In this section of code, lines 1977-1982 will find the dimension olevhalf in CMIP6_coordinate.json.  This would cause it to skip the code in lines 1984-2021, preventing the variable var->dimensions[var->ndims] from being set to -2 and var->generic_level_name from being set to olevhalf.  This leads to errors in this section: https://github.com/PCMDI/cmor/blob/19d6f632dacec5bf43ddcb950c1f1bd1291e8193/Src/cmor_variables.c#L1571-L1617
I have made pull requests for PCMDI/xml-cmor3-database, PCMDI/cmip6-cmor-tabels, and PCMDI/cmor that add olevhalf to the generic_levels of CMIP6_Omon.json and remove it from CMIP6_coordinate.json.  I also added DIMENSION_OLEVEL_HALF to CMOR and added it to the section of code mentioned in https://github.com/PCMDI/cmip6-cmor-tables/issues/237#issuecomment-475437642.

Hi,
It looks you are (close) at a solution. But I tried updating the tables and I get still the same error, so that means these changes didn't make it so far to the repository. Is this coming soon?

@mauzey1 What is the status of this?

@taylor13 This issue should be fixed by https://github.com/PCMDI/cmip6-cmor-tables/pull/241.  I think we can close this issue.

Thanks, issue is indeed solved with the latest cmor table update.


Analyze update to use in-memory package map.

Updates the analyze command to pass a package map to analysis rather than a file path.
This allows us to avoid creating a needless temporary .packages file and host directory and saves us a trip to disk to retrieve the contents when building our URI resolvers for analysis.
cc @devoncarew @Hixie

lgtm!


Question: Using an Enum property

Hi,
Small question please:
In the JSON data which I receive from the server, I have key which can be 1 of 5 different string types. I’d like to transform it on my class to use an Enum which represents these 5 values.
Is such thing possible? Wasn’t sure how to achieve that.
Would love for some help :)
Thanks for this awesome library!

It works with numerical types using the @IsEnum decorator. For string enums there is no support yet.

Got you, could you please give an example of the usage of @isEnum?

import { IsNotEmpty, IsEnum } from 'class-validator';

export enum Difficulty {
  Easy = 1,
  Medium = 2,
  Hard = 3,
}

export class MyClass {

  @IsNotEmpty()
  @IsEnum(Difficulty)
  public difficulty: Difficulty;

}

Cool! Thanks!
Maybe we should add it also to the documentation.

@NoNameProvided String enums are supported by class-validator. I made a PR that was merged a few months ago.

@gempain wondering is it still working
because currently have a problem with this
sending wrong string as some enum, and it didn't throw any error

@NenadJovicic yes I was having issues with enums too.

looks like it is not working only in nested object @gempain
so, I got a validator with some enum check
export class PushSubscriptionDtoValidator extends PushSubscriptionDto {
    @IsNotEmpty({ message: ErrorType.PushSubscriptionRequired })
    @IsString({ message: ErrorType.PushSubscriptionRequired })
    pushToken: string;
    @IsNotEmpty({ message: ErrorType.PushDeviceTypeRequired })
    @IsEnum(DeviceType, { message: ErrorType.InvalidDeviceType })
    deviceType: DeviceType;

    constructor(subscription?: PushSubscriptionDtoValidator) {
        super(subscription);
    }
}

and then, got another validator that use this validator as a type of some property
export class LogoutDtoValidator implements LogoutDto {
    @IsOptional()
    @IsArray({ message: ErrorType.BadRequest })
    pushSubscriptions?: Array<PushSubscriptionDtoValidator> = [];
}

When I run some test that use as a body PushSubscriptionDtoValidator, it will throw a proper error for enum
But, when I use LogoutDtoValidator as a body, it won't validate this enum
But, interesting thing is, it will validate part about @IsNotEmpty() for both fields in PushSubscriptionDtoValidator when using LogoutDtoValidator

@NenadJovicic you have forgotten to use @ValidateNested() on your array, that's why class-validator is not recursively validating your array. I should have noticed it earlier, but here's a proof:
import {IsArray, IsEnum, IsNotEmpty, IsOptional, validate, ValidateNested} from 'class-validator';

export enum Enum {
    a = 'a',
}

export class Child {
    @IsNotEmpty()
    @IsEnum(Enum)
    enum: Enum;
}

export class Parent {
    @IsOptional()
    @IsEnum(Enum)
    enum?: Enum;
    @IsOptional()
    @IsArray()
    @ValidateNested()
    array?: Child[] = [];
}

describe('class validator enum', () => {
    describe('root object validation', () => {
        it('should validate enum on root object', async () => {
            const dto = new Parent();
            dto.enum = Enum.a;

            const validationErrors = await validate(dto);

            expect(validationErrors.length).toEqual(0);
        });

        it('should validate enum on root object', async () => {
            const dto = new Parent();
            dto.enum = 'val' as any;

            const validationErrors = await validate(dto);

            expect(validationErrors.length).toEqual(1);
        });
    });
    describe('nested validation', () => {
        it('should be valid when nested enum is valid', async () => {
            const dto = new Parent();
            const child = new Child();
            child.enum = Enum.a;
            dto.array.push(child);

            const validationErrors = await validate(dto);

            expect(validationErrors.length).toEqual(0);
        });
        it('should be invalid when nested enum is invalid', async () => {
            const dto = new Parent();
            const child = new Child();
            child.enum = 'val' as any;
            dto.array.push(child);

            const validationErrors = await validate(dto);

            expect(validationErrors.length).toEqual(1);
        });
    });
});

Which works fine on my side:

Remove the @ValidateNested() and you'll see the last test fails.


Help user when preceding port is being used (pub serve)

When a user specifies a port number for pub serve, both that port and port-1 (the preceding port) must be free.
If the preceding port is taken, pub serve prints:
Failed to create server socket (OS Error: Address already in use, errno = 48), address = <IP_ADDRESS>, port = 8080
and exits.
The user is not aware that the "secret" other port (port-1) is being opened, and thus doesn't know the work around is to choose a range of two adjacent ports.

This issue has been moved to dart-lang/pub#1129.


docs: add merge strategy

j'ai explicité le process de merge des pr (en gros squash and merge)

:tada: This PR is included in version 1.125.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Experiment with aiofile for true async on Linux

Closing this as "not worth it". May revisit later.


Create a codebook for the R01 study

Once we settle down on the data structure, we should start to write out the codebook for the R01 study.

With the recent revisions to the way our Java code is implemented, we could generate a code book for all measures and scales automatically, that is guaranteed to be in synch with the current web forms.


[GSSoC'23] Word Association Game.

A word association game that will have several levels, and based on that we'll be having questions, IN each question there will be 3-4 words and there will be 3 options, among those 3 options you have to find out the word that can be associated or common with all the words given above. if you are correct you are getting a point and if you are wrong, you will be getting negative points. I'm gonna use basic HTML, CSS, JS, React, and Rapid API to build the game.
Assign me this project under GSSoC'23.

Hi @Arka2708 , could you please elaborate on the features of the game with full details, demo / mock UI sample/Video, and tech stack? better share details documentation.


feat(nanocl:cargo): add missing options

- What I did
Adding following options to cargo exec :
tty
detach_keys
env
privileged
user
working_dir
- How I did it
Adding it to cargo exec opts
- How to verify it
Run cargo exec with following options
- Description for the changelog
Cargo exec options tty detach_keys env privileged user working_dir

Thanks!


README.md

README.md

Codecov Report

Merging #6 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master      #6   +/-   ##
======================================
  Coverage    77.1%   77.1%
======================================
  Files           4       4
  Lines         166     166
  Branches       28      28
======================================
  Hits          128     128
  Misses         38      38

Continue to review full report at Codecov.

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


Prototype model customization

This draft PR is not meant for merger but to provide an example of what would be necessary under the current SqlAlchemy backend to support model customization. This draft is relevant for further investigating a solution to #58 and #121.
At issue is the fact that some properties in STAC Items and Collections are meant to live at the top level of said Items and Collections - full-fledged STAC extensions but also the grey area of custom models which are technically not fully implemented as STAC extensions. Providing top level support of this kind means subclassing the Pydantic models used by stac-fastapi to provide type information for fastapi's automatic documentation generation. Unfortunately, this concession doesn't neatly fit for a few reasons. These limitations are discussed below. First, some example output from the collections endpoint as instantiated by Docker Compose:
{
  "id":"joplin",
  "description":"This imagery was acquired by the NOAA Remote Sensing Division to support NOAA national security and emergency response requirements. In addition, it will be used for ongoing research efforts for testing and developing standards for airborne digital imagery. Individual images have been combined into a larger mosaic and tiled for distribution. The approximate ground sample distance (GSD) for each pixel is 35 cm (1.14 feet).",
  "stac_version":"1.0.0-beta.2",
  "links":[
    {
      "href":"http://localhost:8081/collections/joplin",
      "rel":"self",
      "type":"application/json",
      "title":null,
      "label":null
    },
    {
      "href":"http://localhost:8081/",
      "rel":"parent",
      "type":"application/json",
      "title":null,
      "label":null
    },
    {
      "href":"http://localhost:8081/collections/joplin/items",
      "rel":"item",
      "type":"application/geo+json",
      "title":null,
      "label":null
    },
    {
      "href":"http://localhost:8081/",
      "rel":"root",
      "type":"application/json",
      "title":null,
      "label":null
    }
  ],
  "stac_extensions":[

  ],
  "title":null,
  "license":"public-domain",
  "extent":{
    "spatial":{
      "bbox":[
        [
          -94.6911621,
          37.0332547,
          -94.402771,
          37.1077651
        ]
      ]
    },
    "temporal":{
      "interval":[
        [
          "2000-02-01T00:00:00Z",
          "2000-02-12T00:00:00Z"
        ]
      ]
    }
  },
  "keywords":null,
  "providers":null,
  "summaries":null,
  "sci_doi":"default_doi",
  "sci_citation":"default_citation",
  "sci_publications":"publication1, publication2, publication3"
}

Pressing Issues
Type information determines response fields
In the above JSON, a host of null values are apparent which are not normally provided and which are not desirable. These are seen here because of a change introduced in router.py to ensure that fields unique to subclasses of Collection and Item are returned in responses. Without first turning pydantic instances into dictionaries, only fields provided on Item and Collection are found in the response. Perhaps a pretty_dict method could be required up the inheritance chain to avoid this ugliness.
Incorrect field names (outdated)
This issue can be avoided with aliases, though the solution might introduce some difficulties in complex cases.
The STAC scientific extension uses ":" instead of "_" to separate "sci" from "doi", "citation", and "publications". As pydantic models are simply python classes, field names can't include ":". To accommodate python, field names containing ":" will need to be systematically rewritten. Dictionaries can avoid this limitation but they do so at the cost of losing valuable type information. A solution to this problem which preserves use of pydantic is not apparent beyond users specifying transformations of field names inside the previously mentioned, speculative pretty_dict method.

I forgot to mention in the writeup that I've also included a JSON serialization optimization (conditional use of OrJSON instead of the standard library JSON module) which might be desirable if the automatic serialization of Pydantic model instances is found wanting (for reasons like the two mentioned above)

A solution to this problem which preserves use of pydantic is not apparent beyond users specifying transformations of field names inside the previously mentioned, speculative pretty_dict method.

Pydantic supports field aliasing which makes it possible to represent the extension namespace by aliasing the doi field to look like sci:doi but its not entirely pretty and has a pretty complex precedence for how these aliases are applied (which gets more complex when you use inheritance).

Thanks @geospatial-jeff, that solves the second of the two issues at least. I'm giving the pydantic docs another run through to make sure I've not missed something which might resolve the nullary fields being output as well.
Updated JSON:
{
  "id":"joplin",
  "description":"This imagery was acquired by the NOAA Remote Sensing Division to support NOAA national security and emergency response requirements. In addition, it will be used for ongoing research efforts for testing and developing standards for airborne digital imagery. Individual images have been combined into a larger mosaic and tiled for distribution. The approximate ground sample distance (GSD) for each pixel is 35 cm (1.14 feet).",
  "stac_version":"1.0.0-beta.2",
  "links":[
    {
      "href":"http://localhost:8081/collections/joplin",
      "rel":"self",
      "type":"application/json",
      "title":null,
      "label:assets":null
    },
    {
      "href":"http://localhost:8081/",
      "rel":"parent",
      "type":"application/json",
      "title":null,
      "label:assets":null
    },
    {
      "href":"http://localhost:8081/collections/joplin/items",
      "rel":"item",
      "type":"application/geo+json",
      "title":null,
      "label:assets":null
    },
    {
      "href":"http://localhost:8081/",
      "rel":"root",
      "type":"application/json",
      "title":null,
      "label:assets":null
    }
  ],
  "stac_extensions":[

  ],
  "title":null,
  "license":"public-domain",
  "extent":{
    "spatial":{
      "bbox":[
        [
          -94.6911621,
          37.0332547,
          -94.402771,
          37.1077651
        ]
      ]
    },
    "temporal":{
      "interval":[
        [
          "2000-02-01T00:00:00Z",
          "2000-02-12T00:00:00Z"
        ]
      ]
    }
  },
  "keywords":null,
  "providers":null,
  "summaries":null,
  "sci:doi":"default_doi",
  "sci:citation":"default_citation",
  "sci:publications":"publication1, publication2, publication3"
}

might resolve the nullary fields being output as well

You might want exclude_none=True on model.dict https://pydantic-docs.helpmanual.io/usage/exporting_models/#modeldict

I had tried exclude_unset to get rid of all the null fields and it worked for some but not others. It appears as though what I wanted was exclude_none. Thanks, @kylebarron, this was the missing piece
{
  "id":"joplin",
  "description":"This imagery was acquired by the NOAA Remote Sensing Division to support NOAA national security and emergency response requirements. In addition, it will be used for ongoing research efforts for testing and developing standards for airborne digital imagery. Individual images have been combined into a larger mosaic and tiled for distribution. The approximate ground sample distance (GSD) for each pixel is 35 cm (1.14 feet).",
  "stac_version":"1.0.0-beta.2",
  "links":[
    {
      "href":"http://localhost:8081/collections/joplin",
      "rel":"self",
      "type":"application/json"
    },
    {
      "href":"http://localhost:8081/",
      "rel":"parent",
      "type":"application/json"
    },
    {
      "href":"http://localhost:8081/collections/joplin/items",
      "rel":"item",
      "type":"application/geo+json"
    },
    {
      "href":"http://localhost:8081/",
      "rel":"root",
      "type":"application/json"
    }
  ],
  "stac_extensions":[

  ],
  "license":"public-domain",
  "extent":{
    "spatial":{
      "bbox":[
        [
          -94.6911621,
          37.0332547,
          -94.402771,
          37.1077651
        ]
      ]
    },
    "temporal":{
      "interval":[
        [
          "2000-02-01T00:00:00Z",
          "2000-02-12T00:00:00Z"
        ]
      ]
    }
  },
  "sci:doi":"default_doi",
  "sci:citation":"default_citation",
  "sci:publications":"publication1, publication2, publication3"
}

I had tried exclude_unset to get rid of all the null fields and it worked for some but not others

I believe @geospatial-jeff or @vincentsarago ran into issues with exclude_unset as well, but I don't remember the details. Maybe exclude_unset doesn't apply to fields with defaults?

It's looking like the negatives I ran into aren't actually such a great concern so long as people providing custom models provide appropriate aliasing information and dict gets all the flags it needs. There's also not that much of a footprint for providing said functionality in core. The remaining difficulty, then, is managing the backend implementation's models so that any custom fields which need to be stored/read are available for the from_orm call. This seems like it might be a non-issue w/ the work being done for pgstac

Closing this in favor of #147


OCPBUGS-36750: Checkout specific branch/tag of cloned coredns repo during build

This PR fixes the issue of always using master branch of cloned coredns repo during build. It checks out specific branch/tag of the cloned coredns repo.

/jira refresh

/assign @alebedev87

/lgtm
/approve


Inconsistent iterator interface in regards to label names.

The interface of the different iterators in https://github.com/dmlc/mxnet/blob/master/python/mxnet/io.py is inconsistent in regards to the handling of label names.
While for ImageRecordIter and MNISTIter the label name is specified via the label_name argument, NDArrayIter takes a more general approach and accepts a dictionary made up of { label_name : labels }.
It might be desirable to use the more general interface in all cases.

This is by design. ndarray iter is a general wrapper while the others are specific to certain data source.


cat painting step 47 missing comma

https://github.com/freeCodeCamp/freeCodeCamp/blob/8debeb2d2987a23a1e7be95210d8656d8100b784/curriculum/challenges/english/14-responsive-web-design-22/learn-intermediate-css-by-building-a-cat-painting/646de7b64467e96b7d35b5cd.md?plain=1#L10
this sentence is missing a comma after "absolute".

This looks like something that can be fixed by "first-time" code contributors to this repository. You should look at the file linked above.
Please make sure you read our guidelines for contributing, we prioritize contributors following the instructions in our guides. Join us in our chat room or our forum if you need help contributing; our moderators will guide you through this.
Sometimes we may get more than one pull request. We typically accept the most quality contribution followed by the one that is made first.
Happy contributing.

Mam, can you please tell me how can i fix those details you mentioned i have no idea how to do


options.PouchDB

Breaking changes

@hoodie/store-client used to depend on pouchdb. It has now been
removed and replaced by the new PouchDB option:
var PouchDB = require('pouchdb-core')
  .plugin(require('pouchdb-replication'))
  .plugin(require('pouchdb-adapter-memory'))
  .plugin(require('pouchdb-adapter-http'))
var Store = require('@hoodie/store-client')
var db = new Store('db', {
  PouchDB: PouchDB,
  remote: 'http://localhost:5984/db-remote'
})

options.ajax has been removed. It was passed trough to
pouchdb-hoodie-sync
where it is used to dynamically set the ajax PouchDB option.
For Hoodie, we used that to change the Authorization  header
based on user’s session. But instead of passing in an ajax
function to return the ajax setting dynamically, we will now
set a getter for options.ajax.headers.authorization that will
return the right session ID dynamically. This will simplify the
implementation

Progress

[x] remove options.ajax and .changeRemote() from pouchdb-hoodie-sync: https://github.com/hoodiehq/pouchdb-hoodie-sync/pull/83
[x] once released ^^, update pouchdb-hoodie-sync to latest version in package.json and update PR, then remove the WIP note

closes #134

ping @hoodiehq/maintainers 👀 this is ready for review


[FEATURE] Add Specs for CAT Point-in-Time actions

There are 6 PIT actions that was added to OS 2.4. The following 2 need to be added to this repo:

cat.all_pit_segments: GET _cat/pit_segments/_all
cat.pit_segments: GET _cat/pit_segments

Follow the Developer's Guide doc to fill in these actions.
You might have to manually make calls to an OS cluster to figure out the shape of the response bodies.

Hey! I would like to take this issue! :)

@Tokesh Split this into 2 issues. The other one can be found here https://github.com/opensearch-project/opensearch-api-specification/issues/100 and it is blocked by #91

@Tokesh Split this into 2 issues. The other one can be found here #100 and it is blocked by #91

I am delaying completing this issue due to my exams.  I made a draft pull request - you can see it right now and maybe some errors are already visible right now?
I had two questions while I was writing this part.
The first question is do I need to specify $version = 2? Or which version should I specify?
And the second question, should I write two APIs(_cat/pit_segments/_all and _cat/pit_segments) in one model or divide them into two different ones? I saw in one of your implementations there were two APIs in one model.

UPD: And here comes the most interesting part! I have passed all the checks in the PR and there are no errors from Smithy. It looks like this is correct, is it possible to check somehow? I mean, is there some kind of guideline I can pick it up and test it or something?

Hello everyone!
PR is ready for your review!
I tried to do everything as it is written in the Developer Guide.

@nhtruong We are also missing delete PIT by PIT ID in https://github.com/opensearch-project/opensearch-api-specification/blob/main/model/_global/delete_all_pits/operations.smithy

Closing via https://github.com/opensearch-project/opensearch-api-specification/pull/103.


Text field left icon

Description of Changes
I was missing a left icon in MDTextField, so I added it
Screenshot

Sample code
from kivy.lang import Builder
from kivy.properties import StringProperty

from kivymd.app import MDApp
from kivymd.uix.relativelayout import MDRelativeLayout

KV = '''
MDScreen:
    MDBoxLayout:
        orientation: "vertical"
        MDTextField:
            id: normal
            text: "123"

        MDTextField:
            id: left
            text: "456"
            icon_left: "clock-outline"
            icon_left_color: app.theme_cls.primary_dark

        MDTextField:
            id: right
            text: "789"
            icon_right: "arrow-down-drop-circle-outline"
            icon_right_color: app.theme_cls.primary_color

        MDTextField:
            id: leftright
            text:"012"
            icon_left: "clock-outline"
            icon_left_color: app.theme_cls.primary_dark
            icon_right: "arrow-down-drop-circle-outline"
            icon_right_color: app.theme_cls.primary_color
'''

class Test(MDApp):
    def build(self):
        return Builder.load_string(KV)

Test().run()

@vitoller
Thanks for PR.
It seems to me that the icon on the left is not centered in relation to the right icon.

@vitoller
It is also advisable to give examples of using the left icon for all types of text fields.

thanks for the feedback.

documentation added
vertical alignement is fixed
horizontal position of the helper text was fixed as well


Bind random port if all alternative ports fail

If binding of all ports in the _portAlts list fails, we get stuck in an infinite loop trying to bind the first port number. This change updates this._port on every retry so at the end of the list we listen with undefined which will give us a random port.
Code to reproduce the original issue:
const Discovery = require('hyperdiscovery');
const swarm = Discovery();

Then run: DEBUG=hyperdiscovery node index.js
Observed output:
 hyperdiscovery Port 3282 in use. Trying 3000.
 hyperdiscovery Port 3282 in use. Trying 3002.
 hyperdiscovery Port 3282 in use. Trying 3004.
 hyperdiscovery Port 3282 in use. Trying 2001.
 hyperdiscovery Port 3282 in use. Trying 2003.
 hyperdiscovery Port 3282 in use. Trying 2005.
 hyperdiscovery Port 3282 in use. Trying undefined.
 hyperdiscovery Port 3282 in use. Trying undefined.
...

After this change:
  hyperdiscovery Port 3282 in use. Trying 3000. +0ms
  hyperdiscovery Port 3000 in use. Trying 3002. +4ms
  hyperdiscovery Port 3002 in use. Trying 3004. +1ms
  hyperdiscovery Port 3004 in use. Trying 2001. +3ms
  hyperdiscovery Port 2001 in use. Trying 2003. +0ms
  hyperdiscovery Port 2003 in use. Trying 2005. +0ms
  hyperdiscovery Port 2005 in use. Trying undefined. +1ms
  hyperdiscovery swarm:listening { port: 62989 } +9ms

oh nice one, thanks for that @sammacbeth. I can add you to the npm & github org as a contributor

Thanks for the merge! Would it be possible to release a new version to npm with this fix so I can pull it into my project?

On it!

Out in 10.1.0 😁


Created movieFixtures

In this PR, we added the movieFixtures file and edited the content that was currently in it.

LGTM


Removed invalid community contribution reference

Neither the demo link nor the source code is accessible.
The user might have deleted his GitHub account.
Hope this helps ✌

@tino1008


WIP: mbw unit test coverage

What type of PR is this?
None - just want to check the coverage of added test
What this PR does / why we need it:
pre-PR of memory bandwidth management plugin; at this stage, to make sure the test cases of code that will be submitted provide adequate coverage
Which issue(s) this PR fixes:
NA
Special notes for your reviewer:

official PR had been pushed out for review. this pre-mr had served its purpose already.


Scrcpy Adjustment for Samsung DeX-like Experience

Here’s a polished version of your text with the new issue added:

I found scrcpy to be a great alternative to Samsung DeX and Phone Link (especially for using apps). I love the #virtual display option it offers—it gives me the same vibes as Samsung DeX. However, I’d like to optimize it further to mimic the Samsung DeX experience.
Key Issues and Feature Requests

DPI Adjustment:
The DPI of the virtual display makes the icons and text appear much larger than necessary. This takes up extra space and feels awkward to use. I’d like to adjust the DPI to make it more efficient and similar to the Samsung DeX layout.

Separate Virtual Displays for Apps:
I would like the ability to open individual apps in separate virtual displays so that I can use them seamlessly alongside Windows. Although it’s possible to achieve this by running multiple scripts in individual terminals, this method isn’t user-friendly.

Auto-Rotation/Video Rotation:
I’m currently facing an issue with auto-rotation or manually adjusting rotation when playing videos in a video player. It would be great if this could be handled more smoothly.

Current Script
Here’s the script I’m using currently for landscape:
scrcpy --audio-source=playback --new-display=3840x2160 -m 2160 --no-vd-destroy-content --video-codec=h265 -b 20M -f -K

Another variation I’ve tried:
scrcpy --audio-source=playback --new-display -m 2160 --no-vd-destroy-content --video-codec=h265 -b 20M -f -K

Feel free to review and improve these scripts to address the mentioned issues and make scrcpy a fantastic alternative to Samsung DeX.

My Setup

Phone: Nothing Phone (2)

Developer Options enabled:

Freeform windows
Force desktop mode
Force activities to be resizable
Non-resizable in multi-window mode

Laptop: Acer Predator Helios 300

2K display
12GB RAM
RTX 3060 (6GB VRAM)

Thanks in advance for considering these enhancements!

I’d like to adjust the DPI to make it more efficient and similar to the Samsung DeX layout.

https://github.com/Genymobile/scrcpy/blob/master/doc/virtual_display.md#new-display

I’d like to adjust the DPI to make it more efficient and similar to the Samsung DeX layout.

https://github.com/Genymobile/scrcpy/blob/master/doc/virtual_display.md#new-display

Thank You

Auto-Rotation/Video Rotation:
I’m currently facing an issue with auto-rotation or manually adjusting rotation when playing videos in a video player. It would be great if this could be handled more smoothly.

Looks like #5524. I cannot reproduce on my devices.

Separate Virtual Displays for Apps:
I would like the ability to open individual apps in separate virtual displays so that I can use them seamlessly alongside Windows. Although it’s possible to achieve this by running multiple scripts in individual terminals, this method isn’t user-friendly.

A workaround could be to always use the same script to launch scrcpy with a new virtual display and a launcher, and start your app from there: https://github.com/Genymobile/scrcpy/blob/master/doc/virtual_display.md#start-app

Separate Virtual Displays for Apps

https://github.com/viarotel-org/escrcpy can do this


Can't set own url of repository

Can't set own url of repository eg. as mydomain.jp/git/project
It's limited to github or doing something in wrong way?
How to solve problem?

Yes, we only currently support GitHub repositories.


/close does not close the config portal

I'm using Async_ConfigOnSwitch (1.1.2) unchanged on ESP32.
When I click "Exit Portal" (i.e. request /close) the WiFi Manager remains in config mode until timeout is reached. This is unexpected to me. I expected the config portal to close and for the WiFi Manager to go back to station mode.
In order to exit the config portal I have to hit "Configuration" and then "Save" without entering any values.
Does this work as designed?

@marcelstoer
Can you un-comment this Line 1715 from
//stopConfigPortal = true; //signal ready to shutdown config portal		//KH crash if use this ???

to
stopConfigPortal = true; //signal ready to shutdown config portal		//KH crash if use this ???

to see if that is what you expect.
Possibly I forgot to un-comment after tested last time.

Indeed, that's the behavior I would expect. Thanks! In fact, on iOS the config portal window/dialog closes so quickly now that you don't even get to see the /close response "page". Not that I would care about it anyway 😄 Important is that the portal is shut down and that works nicely now.

That's good. Will update in next release.

Can I ask you to keep issues open until the respective fix has landed on master? That would allow us to be notified by GitHub when we can update our dependencies.

Master updated.

See ESP_WiFiManager v1.2.0 and Contributions-and-Thanks
Releases v1.2.0

Restore cpp code besides Impl.h code to use in case of multiple definition linker error. See Change Implementation to seperate *.h and *.cpp file instead of *.h and *-Impl.h and Support building in PlatformIO PR. Also have a look at HOWTO Fix Multiple Definitions Linker Error
Fix bug /close does not close the config portal.


[tekton] incorrect image path in dist

Describe the bug
ERROR in<EMAIL_ADDRESS>1:0-70
Module not found: Error: Can't resolve '../plugins/tekton/src/imgs/signed-badge.svg' in '/Users/JounQin/Workspaces/Alauda/octopus/node_modules/@janus-idp/backstage-plugin-tekton/dist/utils'

Similar issue #1527
Expected Behavior
What are the steps to reproduce this bug?
https://unpkg.com/browse/<EMAIL_ADDRESS>Versions of software used and environment
<EMAIL_ADDRESS>

Same issue here :)

@JounQin @nicolasfagotti This fix landed in   @janus-idp/backstage-plugin-tekton:3.12.7. Could you please try again with 3.12.7 ?

It seems it is working now @karthikjeeyar. Thanks a lot!

Thanks for confirmation, I am closing this issue.


Load runtime dependency dynamically in client-cli

We can load @platformatic/runtime dynamically in client-cli and remove it from the dependencies to slim down the install size and dependency list.

Closed by #1666


Structural improvements: inheritance on paths and its sublevels

Based on @fehguy structure modification proposition on #563 and my ideas gathered while writing OpenAPI spec and writing my OpenAPI spec tutorial, I propose a new structure for the document.
Tony's proposal (focus on paths and what it needs):
paths:
  # paths object
parameters:
  # parameters which apply to all operations
responses:
  # responses which apply to all operations
responseHeaders:
  # headers to be returned in all responses
security:
  # security requirements which apply to all operations
# definitions
schemas:
  definitions:
    # payload definition objects
  parameters:
    # parameters objects
  responses:
    # responses objects
  responseHeaders:
    # headers returned in responses
  security:
    # security definitions

On root we only keep:

paths: The API's description (improved paths, see below)
schemas: All reusable objects used to describe to API

version:
  # OpenAPI version used by this document, replace swagger

info:
  # existing info object + externalDocs which was on root level
  # ... same properties as existing info object
  externalDocs:
  # (existing) Moving externalDocs from root to info

paths:
  # improved paths object (see below) contains what was on root
  parameters:
    # parameters which apply to all operations
  responses:
    # responses which apply to all operations
  responseHeaders:
    # headers to be returned in all responses
  security:
    # security requirements which apply to all operations

schemas:
  definitions:
    # payload definition objects
  parameters:
    # parameters objects
  responses:
    # responses objects
  responseHeaders:
    # headers returned in responses
  security:
    # security definitions

On paths, the idea is to extend what we already have with parameters declaration on path and operation level to everything that can be declared for an operation (parameters, responses, headers, ...) on all levels:
What we have now:
paths:
  /resources/{parameters}:
    parameters:
      # parameters apply to all operations
    get:
      parameters:
        # parameters apply to this operation

Extending this principle to all levels and properties in paths and its sub-level:
paths:
  # Everything on this level which is not a path, apply to all paths
  # We put here the things which were on root on Tony's proposal.
  # Everything can be overridden by sub levels.
  (... various declarations like tags, parameters, responses, responses headers, security
  and new others applying to all paths......)
  {/paths}:
  # (existing) path object
    # Everything on this level which is not an operation, apply to all operations.
    # Everything can be overridden by sub levels.
    (... various declarations like tags, parameters, responses, responses headers,
     security and new others applying to all operations......)
    {operation like get/post/...}:
      (...operation properties, can override what was described on the upper levels ...)
      responses:
        # Everything on this level which is not a response, apply to all responses.
        # Everything can be overridden by sub levels.
        (... various declarations like responses headers and
         new others applying to all responses......)
        {http status | default):
            (...operation properties, can override what was
             described on the upper levels ...)

parent #560

It definitely looks cleaner, however:

tags belong under the Info Object and not the Paths Object. They are not a global definition of tags that are applied to all paths but a documentation of what the tags mean.
I'm not a big fan of combining the globals at the same level of the paths. It can end up being messy, having too many things under one node, plus you could have parameters, /path, security, /path2 and that's just difficult to read. I get what you're trying to do with the other tickets and inheritance/overriding of the globals, but I don't think that's enough to justify it. As an alternative, we can either collect all the globals under a key (globals?) at the same level as paths, info and so on, or we can move the entire set of globals and paths under a common node (root?), having the globals defined alongside the paths key, keeping a similar structure to what it is now, just pushing it down a node.

I did not move tag documentation to paths. I only add the possibility of using tag on global, path and operations level (with current version we can only set tags on operation level).
Concerning globals (and their equivalent on sublevels), the most important thing (for me) is that we can define things on all levels (global/path/operation/response) with inheritance (like with existing parameters).
But I'm very fond of consistency :-) that's why I propose that : to have all these "shared things" defined the same way on all levels. But you're totally right it may be difficult to read. So what about something like that (applying globals idea on each level to group "shared things" and make the spec more easy to read). In the end it would be just like parameters on path level in the existing version but extended to all shared things (definitely need a better name):

paths:
  globals (or shared or another word):
    # Tags, parameters, responses, responses headers, security
    # (which were on root on Tony's proposal) and new others applying
    # to all paths
    # Everything can be overridden by sub levels.
  {/paths}:
    globals (or shared or another word):
      # Tags, parameters, responses, responses headers,
      # security and new other things applying to all operations
      # Everything can be overridden by sub levels.
    {operation like get/post/...}:
        responses:
          globals (or shared or another word):
            # Responses headers and new other things applying to all responses
            # Everything can be overridden by sub levels.
        {http status | default):
            # response object

Got it, wasn't clear in the original post. I'm ok with that.
I don't see where it would make sense to have something inherited to the response level. I believe in a different ticket you mentioned headers but that holds a set of other potential issues (which we already may have introduced in a different ticket). I'll add the comments to #690. However, is there anything else that would be inherited to the response level?
Another issue with both globals and consistency is that they are already inconsistent. security is overridden, parameters is added, for example.
I like the structure consistency you suggest, I don't like the somewhat bloat it adds. From a technical point of view, there shouldn't be a problem supporting it. Manually writing it can be a bit of a pain (you've written tutorials about the spec, try writing the same examples with the new construct). Consistency is important, but so is ease-of-write (especially for the design-first approach).

First things first: thank you and all the team for reading my issues and giving feedback, there are so many issues and comments in this repo! It took me a long time to figure which of my ideas were already there ... and I missed some of them :-)

in addition to headers, produces could also be inherited to the response level
you get a point about inconsistency between security and parameters inheritance behaviour, but that's already the case in version 2 :-)
as a writer of OpenAPI 2.0 specification, I really liked using this "3.0 version" applying (see below) this inheritance concept :-), easier to write and read because I don't have to rewrite too many things. It's finally only expanding the path/operation parameters principle to everything.

All shared object are in shared on each level
On path level:

userAgent param is set once for all the API instead of being defined on each path
X-Rate-Limit-Remaining and X-Rate-Limit-Reset are set once for all the API instead of being defined on each response
500 and default responses are set once for all the API instead of beging defined on each operation

On path level for /persons/{username}:

username is defined once (already possible in 2.0)
404 response is defined once too instead of having to define it for both get and delete

On responses level for post /js-less-persons:

produces is overriden for all responses
X-PARTNER-HEADER is defined for all responses (including global ones)

Overriding produces on 200 response level on get /image/{imageId}
Trying to use $ref for all reusable thing like security, I like the idea but don't know how it could work for security when you using Oauth 2 scopes (see paths.shared.security)
All reusable definitions (definitions, parameters, securitySchemes, ...) are moved to allDefinition, not fond of the name and I'm wondering if it's useful to do that

Here's the full 3.0 example based on the last file of part 6 of my tutorial:
version: '3.0'

info:
  version: 1.1.0
  title: Simple API
  description: A simple API to learn how to write OpenAPI Specification

schemes:
  - https
host: simple.api
basePath: /openapi101

paths:
  shared:
    security:
      - $ref: '#/allDefinitions/securityDefinitionsOauthSecurity'
        - user
      - $ref: '#/allDefinitions/securityLegacySecurity'
    consumes:
      - application/json
      - application/x-yaml
    produces:
      - application/json
      - application/x-yaml
    parameters:
      - $ref: '#/allDefinitions/parameters/userAgent'
    responseHeaders:
      X-Rate-Limit-Remaining:
        type: integer
      X-Rate-Limit-Reset:
        type: string
        format: date-time
    responses:
      '500':
        $ref: '#/allDefinitions/responses/Standard500ErrorResponse'
      default:
        $ref: '#/allDefinitions/responses/TotallyUnexpectedResponse'

  /persons:
    get:
      summary: Gets some persons
      description: Returns a list containing all persons. The list supports paging.
      parameters:
        - $ref: '#/allDefinitions/parameters/pageSize'
        - $ref: '#/allDefinitions/parameters/pageNumber'
        - $ref: '#/allDefinitions/parameters/includeNonVerifiedUsers'
        - $ref: '#/allDefinitions/parameters/sortPersons'
      responses:
        '200':
          description: A list of Person
          schema:
            $ref: '#/allDefinitions/definitions/Persons'
    post:
      summary: Creates a person
      description: Adds a new person to the persons list.
      security:
        - OauthSecurity:
          - admin
        - LegacySecurity: []
      parameters:
        - name: person
          in: body
          required: true
          description: The person to create.
          schema:
            $ref: '#/allDefinitions/definitions/Person'
      responses:
        '204':
          description: Person succesfully created.
        '400':
          description: Person couldn't have been created.

  /js-less-consumer-persons:
    post:
      summary: Creates a person
      description: For JS-less partners
      security:
        - OauthSecurity:
          - admin
        - LegacySecurity: []
      consumes:
        - application/x-www-form-urlencoded
      parameters:
        - name: username
          in: formData
          required: true
          pattern: '[a-z0-9]{8,64}'
          minLength: 8
          maxLength: 64
          type: string
        - name: firstname
          in: formData
          type: string
        - name: lastname
          in: formData
          type: string
        - name: dateOfBirth
          in: formData
          type: string
          format: date
      responses:
        shared:
          produces:
            - text/html
          responseHeaders:
            X-PARTNER-HEADER:
              description: a dummy header returned by all post /js-less-consumers-persons responses
              type: string
        '204':
          description: Person succesfully created.
        '400':
          description: Person couldn't have been created.
  '/persons/{username}':
    shared:
      parameters:
        - $ref: '#/allDefinitions/parameters/username'
      responses:
       '404':
          $ref: '#/allDefinitions/responses/PersonDoesNotExistResponse'
    get:
      summary: Gets a person
      description: Returns a single person for its username.
      responses:
        '200':
          description: A Person
          schema:
            $ref: '#/allDefinitions/definitions/Person'
    delete:
      summary: Deletes a person
      description: Delete a single person identified via its username
      responses:
        '204':
          description: Person successfully deleted.
  '/persons/{username}/friends':
    shared:
      parameters:
        - $ref: '#/allDefinitions/parameters/username'
      responses:
       '404':
          $ref: '#/allDefinitions/responses/PersonDoesNotExistResponse'
    get:
      summary: Gets a person's friends
      description: Returns a list containing all persons. The list supports paging.
      parameters:
        - $ref: '#/allDefinitions/parameters/pageSize'
        - $ref: '#/allDefinitions/parameters/pageNumber'
        - $ref: '#/allDefinitions/parameters/includeNonVerifiedUsers'
        - $ref: '#/allDefinitions/parameters/sortPersons'
      responses:
        '200':
          description: A person's friends list
          schema:
            $ref: '#/allDefinitions/definitions/PagedPersons'
  '/persons/{username}/collecting-items':
    shared:
      parameters:
        - $ref: '#/allDefinitions/parameters/username'
      responses:
       '404':
          $ref: '#/allDefinitions/responses/PersonDoesNotExistResponse'
    get:
      summary: Gets a person's collecting items list
      description: >-
        Returns a list containing all items this person is looking for. The list
        supports paging.
      parameters:
        - $ref: '#/allDefinitions/parameters/pageSize'
        - $ref: '#/allDefinitions/parameters/pageNumber'
        - $ref: '#/allDefinitions/parameters/filterItemTypes'
      responses:
        '200':
          description: A collected items list
          schema:
            $ref: '#/allDefinitions/definitions/PagedCollectingItems'
  /images:
    post:
      summary: Uploads an image
      security:
        - MediaSecurity: []
      consumes:
        - multipart/form-data
      parameters:
        - name: image
          in: formData
          type: file
      responses:
        '200':
          description: Image's ID
          schema:
            properties:
              imageId:
                type: string
  /images/{imageId}:
    get:
      summary: Gets an image
      parameters:
        - name: imageId
          in: path
          required: true
          type: string
      responses:
        '200':
          description: The image
          produces:
            - image/png
            - image/gif
            - image/jpeg

allDefinitions:

  securityDefinitions:
    OauthSecurity:
      type: oauth2
      flow: accessCode
      authorizationUrl: 'https://oauth.simple.api/authorization'
      tokenUrl: 'https://oauth.simple.api/token'
      scopes:
        admin: Admin scope
        user: User scope
    MediaSecurity:
      type: apiKey
      in: query
      name: media-api-key
    LegacySecurity:
      type: basic

  definitions:
    Person:
      required:
        - username
      properties:
        firstName:
          type: string
        lastName:
          type: string
        username:
          type: string
          pattern: '[a-z0-9]{8,64}'
          minLength: 8
          maxLength: 64
        dateOfBirth:
          type: string
          format: date
        lastTimeOnline:
          type: string
          format: date-time
          readOnly: true
        avatarBase64PNG:
          type: string
          format: byte
          default: data:image/png;base64,[encoded data, 7936 characters]
        spokenLanguages:
          $ref: '#/allDefinitions/definitions/SpokenLanguages'
    SpokenLanguages:
      additionalProperties:
        type: string
      properties:
        defaultLanguage:
          type: string
          default: english
    Persons:
      required:
        - items
      properties:
        items:
          type: array
          minItems: 10
          maxItems: 100
          uniqueItems: true
          items:
            $ref: '#/allDefinitions/definitions/Person'
    ErrorMessage:
      required:
        - longMessage
        - shortMessage
      properties:
        longMessage:
          type: string
        shortMessage:
          type: string
    MultilingualErrorMessage:
      additionalProperties:
        $ref: '#/allDefinitions/definitions/ErrorMessage'
      properties:
        defaultLanguage:
          $ref: '#/allDefinitions/definitions/ErrorMessage'
    Error:
      required:
        - code
        - message
      properties:
        code:
          type: string
          enum:
            - DBERR
            - NTERR
            - UNERR
        message:
          $ref: '#/allDefinitions/definitions/MultilingualErrorMessage'
    CollectingItem:
      discriminator: itemType
      required:
        - itemType
      properties:
        itemType:
          type: string
          enum:
            - AudioCassette
            - Vinyl
            - VHS
        imageId:
          type: string
        maxPrice:
          type: number
          format: double
          minimum: 0
          maximum: 10000
          exclusiveMinimum: true
          exclusiveMaximum: false
    Vinyl:
      allOf:
        - $ref: '#/allDefinitions/definitions/CollectingItem'
        - required:
            - albumName
            - artist
          properties:
            albumName:
              type: string
            artist:
              type: string
    VHS:
      allOf:
        - $ref: '#/allDefinitions/definitions/CollectingItem'
        - required:
            - movieTitle
          properties:
            movieTitle:
              type: string
            director:
              type: string
    AudioCassette:
      allOf:
        - $ref: '#/allDefinitions/definitions/CollectingItem'
        - required:
            - albumName
            - artist
          properties:
            albumName:
              type: string
            artist:
              type: string
    Paging:
      required:
        - totalItems
        - totalPages
        - pageSize
        - currentPage
      properties:
        totalItems:
          type: integer
        totalPages:
          type: integer
        pageSize:
          type: integer
        currentPage:
          type: integer
    PagedPersons:
      allOf:
        - $ref: '#/allDefinitions/definitions/Persons'
        - $ref: '#/allDefinitions/definitions/Paging'
    PagedCollectingItems:
      allOf:
        - properties:
            items:
              type: array
              minItems: 10
              maxItems: 100
              uniqueItems: true
              items:
                $ref: '#/allDefinitions/definitions/CollectingItem'
        - $ref: '#/allDefinitions/definitions/Paging'
  responses:
    Standard500ErrorResponse:
      description: An unexpected error occured.
      schema:
        $ref: '#/allDefinitions/definitions/Error'
    PersonDoesNotExistResponse:
      description: Person does not exist.
    TotallyUnexpectedResponse:
      description: A totally unexpected response

  parameters:
    username:
      name: username
      in: path
      required: true
      description: The person's username
      type: string
    pageSize:
      name: pageSize
      in: query
      description: Number of persons returned
      type: integer
      format: int32
      minimum: 0
      exclusiveMinimum: true
      maximum: 100
      exclusiveMaximum: false
      multipleOf: 10
      default: 20
    pageNumber:
      name: pageNumber
      in: query
      description: Page number
      type: integer
      default: 1
    includeNonVerifiedUsers:
      name: includeNonVerifiedUsers
      in: query
      type: boolean
      default: false
      allowEmptyValue: true
    sortPersons:
      name: sort
      in: query
      type: array
      uniqueItems: true
      minItems: 1
      maxItems: 3
      collectionFormat: pipes
      items:
        type: string
        pattern: '[-+](username|lastTimeOnline|firstname|lastname)'
      default:
        - -lastTimeOnline
        - +username
    filterItemTypes:
      name: itemType
      in: query
      type: array
      collectionFormat: multi
      uniqueItems: true
      items:
        type: string
        enum:
          - AudioCassette
          - Vinyl
          - VHS
    userAgent:
      name: User-Agent
      type: string
      in: header
      required: true

@arno-di-loreto Great proposal, it removes a lot of unnecessary  duplication from Swagger files.
But I totally agree with @webron on:

Another issue with both globals and consistency is that they are already inconsistent. security is overridden, parameters are added, for example.

But it's very easy to solve if we support default property along side with shared.
And it will be very simple algorithm for figuring out values for particular operation:

All properties inside operation used as initial values.
Go one level up.
Values from default set as property values but only if matching property is undefined at the moment.
Values from shared prepend to the current value of the property.
Repeat steps 2-4.

So path-level parameters from 2.0 will move to path-level shared.
And root-level security will move to paths-level default.
It will also allow for many other things that not possible in 2.0.
For example, to define global OAuth scopes but allow individual operations to add their own.
P.S. @arno-di-loreto Such big code samples make Github issues harder to scroll.
Can you please replace sample from your last comment with a link to a Gist?

Thanks @IvanGoncharov . I've replaced the full example by a link to a gist.


add Theme: zhiyin

Hello Kyome!
I added a theme named zhiyin, which you can check exe here
A funny and popular dancing idol 🤣

@Weidows
Is this character copyright free?

@Weidows Is this character copyright free?

This kind of creation is quite popular. Last year I uploaded my fork on a video platform
He doesn't care about works that have no negative impact on his personal image

@Weidows
It doesn't seem to be popular in Japan, and I didn't think it would be a good idea for RunCat to officially support it. Even when I saw the animation you implemented, I couldn't understand how interesting it was.
Thank you for the pull request, but I will not merge it.


chore(deps): update node.js to >=v18.14.1

This PR contains the following updates:

Package
Type
Update
Change
Pending

node
engines
patch
>=v18.14.0 -> >=v18.14.1
v18.14.2

@types/node (source)
devDependencies
minor
^18.8.3 -> ^18.13.0
18.14.0

Release Notes

nodejs/node
v18.14.1: 2023-02-16, Version 18.14.1 'Hydrogen' (LTS), @RafaelGSS prepared by @juanarbol
Compare Source
This is a security release.
Notable Changes
The following CVEs are fixed in this release:

CVE-2023-23918: Node.js Permissions policies can be bypassed via process.mainModule (High)
CVE-2023-23919: Node.js OpenSSL error handling issues in nodejs crypto library (Medium)
CVE-2023-23936: Fetch API in Node.js did not protect against CRLF injection in host headers (Medium)
CVE-2023-24807: Regular Expression Denial of Service in Headers in Node.js fetch API (Low)
CVE-2023-23920: Node.js insecure loading of ICU data through ICU_DATA environment variable (Low)

More detailed information on each of the vulnerabilities can be found in February 2023 Security Releases blog post.
This security release includes OpenSSL security updates as outlined in the recent
OpenSSL security advisory.
Commits

[8393ebc72d] - build: build ICU with ICU_NO_USER_DATA_OVERRIDE (RafaelGSS) nodejs-private/node-private#379
[004e34d046] - crypto: clear OpenSSL error on invalid ca cert (RafaelGSS) #46572
[5e0142a852] - deps: cherry-pick Windows ARM64 fix for openssl (Richard Lau) #46572
[f71fe278a6] - deps: update archs files for quictls/openssl-3.0.8+quic (RafaelGSS) #46572
[2c6817e42b] - deps: upgrade openssl sources to quictls/openssl-3.0.8+quic (RafaelGSS) #46572
[f0afa0bfe5] - deps: update undici to 5.19.1 (Node.js GitHub Bot) #46634
[c26a34c13e] - deps: update undici to 5.18.0 (Node.js GitHub Bot) #46634
[db93ee4a15] - deps: update undici to 5.17.1 (Node.js GitHub Bot) #46634
[b4e49fb02c] - deps: update undici to 5.16.0 (Node.js GitHub Bot) #46634
[90994e6a2c] - deps: update undici to 5.15.1 (Node.js GitHub Bot) #46634
[00302fc7ac] - deps: update undici to 5.15.0 (Node.js GitHub Bot) #46634
[0e3b796cc5] - lib: makeRequireFunction patch when experimental policy (RafaelGSS) nodejs-private/node-private#371
[7cccd5565f] - policy: makeRequireFunction on mainModule.require (RafaelGSS) nodejs-private/node-private#371

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.

This PR has been generated by Renovate Bot.

Renovate Ignore Notification
As this PR has been closed unmerged, Renovate will now ignore this update (>=v18.14.1). You will still receive a PR once a newer version is released, so if you wish to permanently ignore this dependency, please add it to the ignoreDeps array of your renovate config.
If this PR was closed by mistake or you changed your mind, you can simply rename this PR and you will soon get a fresh replacement PR opened.


Windows GVim Crashes

Symptoms currently seen:

Top left buffer doesn't open properly.
Python threads appear to freeze, might be related to above.

Did a bit of testing. tied directly to the Buffer class updates. Might be a bit annoying tracing.

Crash fixed on branch windows. In fact, almost works perfectly.


Windows Server 2004 image runs in process isolation mode on Windows 10 20H2 despite indication otherwise

I am running Windows 10 20H2 Build 19042.746.
I did a pull:

docker pull mcr.microsoft.com/windows/servercore:2004

I am able to run this image in both hyperv and process isolation modes.
This is surprising as the official documentation page here: Windows container version compatibility
indicates that process isolation is not supported for this configuration:

Is the documentation out of date?  Has the Windows docker technology been improved?
Note: I used docker inspect to check the isolation mode of the containers.
Thanks.

It is a waste of time to open issues here.  Seems the repo is not being monitored.  Back to SO.


Experiments table shows all rows expanded on first load

I've only had to do this a couple of times and it is officially a PITA.
https://user-images.githubusercontent.com/37993418/164365405-c6af9ee4-3365-4614-8a16-7b2cfd7235c6.mov
My initial thought is that we could:

retain the state between session
provide a collapse all action (also expand all)
default to all closed (also not a great option)

Has not been important enough to prioritise.


confusing on className="brush"

I could not manage to construct className="brush"
I was wondering what was the proper way to form className="brush" in the example code

please  let me know
regards

Hi there!
Can you show me some more of your code? Right now I don't understand what your are doing exactly.

Thank you first
I am new to React
I try to integrate your brush example to my isomorphic server.
var MyComponent = React.createClass({
..
,.

app.get('/', (request, response) => {
const reactHtml = ReactDOMServer.renderToString();
response.render('index',{reactInitialData: JSON.stringify(contacts),
content: reactHtml });
the graph  is rendered to client but brush is not working.
(my current thought is that the problem has to with rendering style).
how did you inject your css file to client?
thank you

I am not doing isomorphic rendering in my example.
Can you show me how you create the brush?

var MyComponent = React.createClass({
...
    return (

            <LineChart
               data={this.state.data}
               width={400}
               height={400}
               margin={{top: 10, bottom: 50, left: 50, right: 20}}
               xScale={this.state.xScale}
               xAxis={{tickValues: this.state.xScale.ticks(d3.time.day, 2), tickFormat: d3.time.format("%m /%d")}}
            />

            <Brush
               width={400}
               height={50}
               margin={{top: 0, bottom: 30, left: 50, right: 20}}
               xScale={this.state.xScaleBrush}
               extent={[new Date(2015, 2, 10), new Date(2015, 2, 12)]}
               onChange={this._onChange}
               xAxis={{tickValues: this.state.xScaleBrush.ticks(d3.time.day, 2), tickFormat: d3.time.format("%m /%d")}}
            />

    );
},

on the server
app.get('/', (request, response) => {
let componentInstance = ContactsAppFactory({contacts:contacts});
const reactHtml = ReactDOMServer.renderToString();
response.render('index',{reactInitialData: JSON.stringify(contacts),
content: reactHtml });
But, I am not sure whether I am doing right on constructing the brush on the server.
Is brush only client issue?
However, Chrome inspect shows brush structure.
regards

Sorry for correction
const reactHtml = ReactDOMServer.renderToString() will be
const reactHtml = ReactDOMServer.renderToString()

const reactHtml = ReactDOMServer.renderToString(

I never did server side rendering so I cannot say if that is the problem, sorry.
Otherwise this.state.xScaleBrush might be a source of error. Maybe if it's set incorrectly the brush might be rendered incorrectly.
I am sorry I cannot help you more at the moment :(

About the CSS..
I am using the following in the example. Maybe it helps you?
.brush .extent {
  stroke: #000;
  fill-opacity: .125;
  shape-rendering: crispEdges;
}

.brush .background {
  fill: #ddd;
}

thank  you foe all


Adds CMake support and updates to new version of JRTPLIB

I took the time to add CMake support so I can compile this project to Android. I also had to upload jrtplib to the newest version because it contained a quirk to compile for Android. Hope you're able to accept this pull request :)
I'll test this lib with my cameras and fix any problems I have with it, and maybe add support for other things such MJPEG.

thanks for the merge, now its going to be easier to keep up with your updates. Gonna do heavy testing on Android and with my cameras and provide some patches if necessary. Good work!


Add all features unit test job

Follow-up of https://github.com/containers/oci-spec-rs/pull/15#discussion_r691286220

Codecov Report

Merging #18 (8c61e03) into main (b67aa8f) will increase coverage by 0.14%.
The diff coverage is 40.62%.

@@            Coverage Diff             @@
##             main      #18      +/-   ##
==========================================
+ Coverage   26.88%   27.03%   +0.14%
==========================================
  Files           7        7
  Lines         491      492       +1
  Branches      248      248
==========================================
+ Hits          132      133       +1
  Misses        130      130
  Partials      229      229

Running both tests (with and without all features) in sequence works too :)


Feature/incremental estimator

Uses iSAM2 and moved parameter loading to laser_slam_ros. Depends on #3.

@exodaniel it would be awesome if you could have a quick look over this PR. Sorry for the size, the parameters moved around quite a bit! ;) Thanks!

@exodaniel thanks for having a look! I included your comments! :-)

retest this please


ENH: Hierarchical approach to 3d registration

Closes #94
Assuming you have already created a sequence of CT nodes and extracted the relevant volumes you wish to track, you should be able to follow the following steps to run the 3D to 3D pipeline.
Creating a Hierarchy
Navigate to the data module and select the Subject Hierarchy tab. Right click on the node list and select Create new subject, name this whatever you would like. Then you can drag the partial volumes into a hierarchy.

Tracking
Given a sequence of n frames, this module will track a set of volumes over the frames [1,n]. This assumes that frame 0 is the neutral volume or the volume that the partial volumes were segmented from (the transform is identity).
Some small volumes, such as the pisiform, will fail to track.

[ ] Vary the step size within the parameter file to address this issue -> based on the size of the volume

https://github.com/BrownBiomechanics/SlicerAutoscoperM/blob/c6983696348ba42b1b7ef3e2b3addd9ec61feac9/Tracking3D/Resources/ParameterFiles/rigid.txt#L37-L41
Navigate to the Tracking3D module, this is under the tracking folder. Ensure that you select the subject you created in the previous step. You can also optionally select and initial guess transform. Click the apply button to launch the tracking, this will take a while. Some information will be sent to the log during the process. The apply button will transform into a cancel button if stopping the registration is necessary.

Before registration
During registration

Exporting Transforms as an Autoscoper TRA file
Simply ensure that the subject is selected then press the Export transforms button. All tra files will be written to the {slicer cache dir}/AutoscoperM-Pre-Processing/Tracking folder (same directory used by the AutoscoperM module).

 BN00107
Since there's no projection- I figured there would be no use of origin2dicom.tfm (check)
Though the bones all look slightly offset... (3dto3d in blue)

the stl location in pose of your solution in slicer aligns with the known stl export from Markerless registration.

Sometimes the closer we are the optimial position the worse the registration results are:

Input
Result

Running just on the ROI:

Cropped CT
Input
Result

We can get good results by using an un-optimal input

Input
Result

NOTE: This problem is not persistent when registering the moving volume to a copy of itself. So this is likely and issue with the ROI cropping used during the pipline.
Script to run registration using this module
import Tracking3D

fixed = getNode() # CT scan
moving = getNode() # Ridged body
transform = getNode() # Used for Initial guess and output

Tracking3DLogic = Tracking3D.Tracking3DLogic()
Tracking3DLogic.parameterFile = r"C:\Users\anthony.lombardi\Projects\SAM\3d-reg-rel\lib\Slicer-5.5\qt-scripted-modules\Resources\ParameterFiles\rigid.txt"
Tracking3DLogic.registerRigidBody(
  CT=fixed,
  body=moving,
  outputTransform=transform,
)

We will use Squash and Merge to integrate this with the following commit message:
ENH: Introduce Hierarchical 3D to 3D registration module

This module registers a set of partial volumes to  Sequential 3D CT or 4D CT data.
Volume to volume registration is performed using ITK-Elastix. The hierarchical input
heuristic used on each frame of the sequence is based off of  [Marai et al (2006)](https://ieeexplore.ieee.org/document/1583764).

This pipeline will likely superseed the Virtual Radiograph Generation (VRG) pipeline.

I know this is already commit to main- but fyi, I am testing with SUBJECTS
On a non-lifespan machine- will compare a subject and 2-3 poses and report back
@jjcrisco
@jcfr
@sbelsk

@sbelsk , I'm investigating what state the partial volume (.tiff) needs to be in order for the registration to properly run
Using BN00121, I attempted to use the rad, tpm, mc1 in a hierarchy (as described above)
I loaded the tiff without the spatial referencing tfm created in prprocessing (shown red)

Unremarkably- when we apply the respective tfm - the red partial volumes overlay wiht the white (in neutral frame)

I harded the tfm for each bone at this stage- and then dragged the tpm, mc1 as children of the rad-
I toggled the 3dHeiracrchy module, initialized the .tra (identity transforms)..

and attempted 2 frames of the sequence with my embeded heiracrchy

buuuutt

that didn't work


💡[FEATURE]: Auto Commenting when an issue is closed by maintainer

Is your feature request related to a problem? Please describe.
Yes, the feature request is related to the problem of lack of communication and acknowledgment when issues are closed in the repository. Contributors may feel neglected or uncertain about the status of their issues if they are closed without any feedback or acknowledgment. This can lead to frustration and a decrease in motivation to contribute further.
Describe the solution you'd like
The solution is to automatically post a comment on the issue whenever it gets closed. This comment should thank the issue creator for their contribution and inform them that their issue has been closed. The message can include the issue number and a friendly greeting to make it more personal. This automation ensures that every closed issue receives a consistent and timely response, improving communication and contributor experience.

@kartikayasijaa please assign me this issue under gssoc'24


Add Bucks CC project story

PT: https://www.pivotaltracker.com/n/projects/1364344

LGTM

Was this meant to go into production? There are a few things which I've spotted on https://unboxed.co/project-stories/bucks-cc
Text is too long for the first tile, leaving a white gap underneath the image:

Same issue on the "MVP prototyping using user feedback" section:

And Leon's caricature looks small in comparison to the rest of the team:

Oh goddamit! The PR was made against production by mistake, my bad for not checking it.

Is the only solution to the white gap issue reducing the amount of text? I've seen the same issue with a few other project stories?

@tlfrd The solution we've been going with in the past is to reduce the text, yep. Another solution is to remove the bottom padding of the .text-tile so that there is a little bit of an overflow in case it happens. I'd recommend making that change, but it's still worth visually testing the responsiveness of the site.


Consider changing ambient iptables logic

Currently, the new ambient mode uses iptables to do it's bidding, but unlike the sidecar logic, it doesn't use -j RETURN. It means that if another tool uses iptables, it can't really cooperate (unless the other tool is working around it ofc, by being before ambient).
I suggest to change it to -j RETURN instead of -j ACCEPT
This came up in this Slack chat:
https://istio.slack.com/archives/C041EQL1XMY/p1721759899167519

Thanks for the explanation.


Line chart cut at the top

Example: http://krispo.github.io/angular-nvd3/#/lineChart
Screenshot:

I have the same problem, please fix this issue

I also have this issue. How is it going?

Same issue over here. Is it fixable?

The same +1

I had the same problem and got it resolved using a chart property called clipEdge.  You need to set it to false.

Hey @b3hrooz, thanks for sharing! I'll close the issue


Join region 2

🗃 Github Issue Or Explanation for this PR. (What is it supposed to do and Why is needed)
#1616
✅ Checklist

[x] Github issue details are up to date for people to QA.
[x] I have tested all my changes.

🕵♂ Notes for Code Reviewer
Added:

Use case to get regions from chain and firebas
Join region bloc.
More UI to build the regions results list.

🙈 Screenshots

e.
👯♀ Paired with
"nobody"

U think for the conflicts, you should use your changes and ignore the change in master


Add deployment tracker

https://github.com/IBM-Bluemix/cf-deployment-tracker-client-python

https://github.com/watson-developer-cloud/answer-retrieval/pull/28 - PR for deployment tracker.


On vendor\emojis submodule update

I need info on what to do if you did commit that vendor\emoji thingie to your working branch.

Ah, awesome, @olyism! Thanks, I'm adding this info to the style guide.


Update Guice

Overview
Update Guice to 4.2.1, which has gained a proper Java 10
support in AOP-enabled version. This is likely to fix
the flaky service_runtime IT (will be verified separately).
See also: https://github.com/google/guice/issues/1181#issuecomment-423216468

Definition of Done

[x] There are no TODOs left in the code
[x] Changelog is updated if needed (in case of notable or breaking changes)
[ ] The continuous integration build passes

Well, it didn't work — we got a failure of that service runtime test in the first build. However, the PR from dependabot succeeded — so it is still flaky.
I guess we'll need to reproduce the issue with sth simpler. Or go back to non-AOP flavour of Guice (I think that the only usage of it must be replaced anyway with hand-written logging because log levels must be different for each method).

Already using a more recent version.


Single Sign On Script is ServiceNow needs to be changed

I found that in ServiceNow, the Single Sign On Script in Identity Providers --> Advanced Tab needs to be set to MultiSSOv2_SAML2_custom. The default MultiSSO_SAML2_Update1 did not pass the Authn Step after testing.

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

ID: d507f0ce-f27f-1ffd-7129-7bb4e37b07ff
Version Independent ID: ec9f7c43-e967-d2e7-cde7-111c5897a798
Content: Tutorial: Azure Active Directory single sign-on (SSO) integration with ServiceNow
Content Source: articles/active-directory/saas-apps/servicenow-tutorial.md
Service: active-directory
Sub-service: saas-app-tutorial
GitHub Login: @jeevansd
Microsoft Alias: jeedes

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

@Dragonsong3k Thanks for the feedback here. We will update our doc now.
@v-viinde and @v-nagta Please update the doc.
CC: @chetansriv

Excellent work guys. I love the feedback system built in to the documentation!

Sorry was not sure if I was supposed to close this :(

@Dragonsong3k We have now updated the article with the new screenshot. Thanks for reporting this.
I am closing this ticket now.

#please-close

I know this is closed, but I would say that the mechanism that pushes the identity provider to ServiceNow should correct for this rather than us have to alter it after the push, which will need to be done for every setup (?)

In addition to my previous comment: I do see that the screenshot is updated to reflect this step, but in contrary to the other elements on the screenshot that needs attention, there's not a red square around it. I had to find the answer elsewhere:
https://community.servicenow.com/community?id=community_question&sys_id=0eb91abfdb26c4d4d82ffb243996197a
Proposal: Either mark it with a red square around it or change the push mechanism as suggested in my previous comment.
Thank you

The Custom script does not work, it redirects to https://idp.ssocircle.com/sso/UI/Login?module=peopleMembership
If change leave it on Update1 it works correctly.

@chetansriv and @v-nagta Can you please review this?  I think we need to update the screenshot.

On Wed, Apr 8, 2020 at 8:10 PM Jeevan Desarda<EMAIL_ADDRESS>wrote:

@chetansriv https://github.com/chetansriv and @v-nagta
https://github.com/v-nagta Can you please review this? I think we need
to update the screenshot.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/azure-docs/issues/43306#issuecomment-611256605,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJ5MZ6DO6HTSS2ELDDFD22DRLUG55ANCNFSM4JQGSZUA
.

--
Terry Anthony Colbert Jr

The Custom script does not work, it redirects to https://idp.ssocircle.com/sso/UI/Login?module=peopleMembership
If you leave it on Update1 it works correctly.

It seems to be relative to ServiceNow Instance version, so that from Newyork, you need to use the custom script variant.
-Anders

We're on New York, and the custom script did not work. It kept redirecting to that SSOCIRCLE site. Switched it back to Update1 and it worked as expected.
Build name: Newyork
Build date: 03-02-2020_2243
Build tag: glide-newyork-06-26-2019__patch7-02-25-2020

We're on New York, and the custom script did not work. It kept redirecting to that SSOCIRCLE site. Switched it back to Update1 and it worked as expected.
I experience the opposite concerning redirection, where changing from update1 to custom fixed it for me..(newyork only)

This hi-article seems relevant to the matter..


Fixed composer installation in README.md

Reason for This PR
Docs of installation via composer are incorrect and don't even work (maybe just deprecated)
Description of Changes
Changed from composer require spiral/roadrunner-http spiral/roadrunner-worker nyholm/psr7 to composer require spiral/roadrunner-cli as noted at https://docs.roadrunner.dev/general/install
License Acceptance
By submitting this pull request, I confirm that my contribution is made under the terms of the MIT license.
PR Checklist

[ ] All commits in this PR are signed (git commit -s).
[ ] The reason for this PR is clearly provided (issue no. or explanation).
[ ] The description of changes is clear and encompassing.
[ ] Any required documentation changes (code and docs) are included in this PR.
[ ] Any user-facing changes are mentioned in CHANGELOG.md.
[ ] All added/changed functionality is tested.

Summary by CodeRabbit

Documentation

Updated the composer require command in the README to simplify package installation by including roadrunner-cli.

Hey @Filipponik 👋 Thanks for the PR 👍
These deps are not needed to download the RR binary. The installation process describes how to install RR, not a PHP worker.
The process of creating the PHP Worker is described here: link with all needed deps.

@rustatian yeah but i wanted to try roadrunner, then i read README.md for install. Installing via composer doesnt work and dont match web docs

i mean composer require spiral/roadrunner-http spiral/roadrunner-worker nyholm/psr7 doesnt create vendor/bin/rr file and cli command dont work

What exactly doesn't match (btw, there is no http and worker deps in the web-docs installation process)?
And what error do you have while installing via compose?

i see this

i do composer require spiral/roadrunner-http spiral/roadrunner-worker nyholm/psr7, packages succesfully installed

i do ./vendor/bin/rr get-binary and i receive error -bash: ./vendor/bin/rr: No such file or directory

doesn't match:
insallation via composer in web docs:

insallation via composer in README.md:

Oh yeah, sorry, you're right. Your PR is good to go, it should be cli. Have you tried to install RR via cli (./vendor/bin/rr get)?

@rustatian yeah ./vendor/bin/rr ... works after composer require spiral/roadrunner-cli as noted in web docs

Cool 👍 LGTM, thanks ❤


update(lci pp): update the default version of LCI autofetch to v1.7.5

LCI v1.7.5 improves its flexibility and usability. It also fixes various minor compilation warnings and errors.

Can one of the admins verify this patch?

@hkaiser This PR is ready to merge.

@hkaiser This PR is ready to merge.

bors merge


Broker vm.swappiness configuration is lost after VM reboot.

Describe the issue
sysctl configuration was lost after Broker VM reboot.
https://man7.org/linux/man-pages/man5/sysctl.d.5.html
Default value: kafka_broker_sysctl_file: /usr/lib/sysctl.d/sysctl.conf
https://github.com/confluentinc/cp-ansible/blob/7.1.6-post/roles/kafka_broker/defaults/main.yml#L59
To Reproduce
Steps to reproduce the behaviour:
Kafka Broker sysctl configuration: hosts.yaml
 kafka_broker_sysctl:
  vm.swappiness: 1
  vm.dirty_background_ratio: 5
  vm.dirty_ratio: 80
  vm.max_map_count: 262144

When cp-ansible ends, from the Broker shell:
$ sysctl vm.swappiness
    vm.swappiness = 1

Reboot the Broker VM:
$ sysctl vm.swappiness
    vm.swappiness = 30

Expected behaviour
 $ sysctl vm.swappiness
    vm.swappiness = 1

Inventory File
 kafka_broker_sysctl:
  vm.swappiness: 1
  vm.dirty_background_ratio: 5
  vm.dirty_ratio: 80
  vm.max_map_count: 262144

Logs
TASK [confluent.platform.kafka_broker : Tune virtual memory settings] *********************************************************
changed: [cp-node] => (item={'key': 'vm.swappiness', 'value': 1})
changed: [cp-node] => (item={'key': 'vm.dirty_background_ratio', 'value': 5})
changed: [cp-node] => (item={'key': 'vm.dirty_ratio', 'value': 80})
changed: [cp-node] => (item={'key': 'vm.max_map_count', 'value': 262144})

Environment (please complete the following information):

OS: RHEL 8
CP-Ansible Branch: 7.1.6
Ansible Version: 2.14.3

Additional context
Adding the following configuration to the hosts.yaml:
kafka_broker_sysctl_file: /etc/sysctl.d/90-kafka-broker.conf

keeps the value vm.swappiness=1 after a VM reboot.

We see the same, and have found that tuned is the culprit. In our /usr/lib/tuned/virtual-guest/tuned.conf we find vm.swappiness = 30. Tuned's plugin_sysctl will check /run/sysctl.d/*.conf, /etc/sysctl.d/*.conf and /etc/sysctl.conf for values, and not override those found in those files. But it will not, however, check /usr/lib/sysctl.d/*.conf, where your file is.
This appears to be by design. Maybe try dropping the file into /etc/sysctl.d instead?


Fix Win11ARM victim in install.ps1

Fix typo that prevents Win11ARM victim to load the correct configuration.

Hey Ana!
Just wanted to let you know that you forgot to remove the '-not' to the $victim.IsPresent.
All the best :)

Fixed in #324. Included the changes from @zemfoliveira. Thanks!


Structured output proof of concept

This introduces an 'event' api where events can be 'emitted' by
commands, which goes through the following pipeline:

a set of callbacks are registered with each command (similar to
script hooks) by name
when an event is emitted, one of these names must be provided
the data is fed to the registered callback, which returns a Report
which describes how to log and serialize the data
this report is taken by the event api and depending on whether the
structured output flag is set will either

serialize the data to json (with a very basic hand rolled encoder)
and write it to stdout
log it with the given Logger

The basic structure is as such:
command.new {
   name = "my-cool-command",
   description = ":D",
   exec = function(): integer
      event.emit("cool_event", { adjective = "cool" })
      event.emit("cool_event", { adjective = "neat" })
      return 0
   end,
   events = {
      cool_event = function(params: {string:any}): event.Report
         return {
            log_format = "This is from a %(adjective) event happening",
            parameters = { adjective = params.adjective },
         },
      end,
   },
}

Which with unstructured output will produce
$ cyan my-cool-command
     Info This is from a cool event happening
     Info This is from a neat event happening

But with structured output will produce
$ cyan --structured-output my-cool-command
{"event":"cool_event","data":{"adjective":"cool"}}
{"event":"cool_event","data":{"adjective":"neat"}}

This commit adds a little bit of this as a proof of concept to the
current build command, but not for everything that build can log.
But running
$ cyan build --update-all --structured-output --no-script

will produce nicely structured output, and some data massaging with jq
is easy enough. The following will produce an array of files that were
written by build
$ cyan build --update-all --structured-output --no-script | jq -n '[inputs | select(.event == "wrote_file") | .data.file]'

Relevant issue #21


Require user confirmation if running unreleased version

consider baking a protective mechanism into CLI if someone complies directly from develop - “are you sure you want to use this non-stable version of the wallet? If you want to carry on, enter the command ‘I accept this risk’, or get the tested/stable version from (link)”

This is a bit troublesome to have to confirm especially in development and pre-release execution of the CI.


Separate Connection and Channel. Introduce ConnectionConfig

I don't like how configuration is implemented in fs2-rabbit and akka-alpakka. So I suggest this approach. It allows user to work with configuration just like with connection factory (e.g. set parameters with uri and then overwrite them partially) in functional way. But it makes getting parameters back from config impossible.

Closing given how long it has been open for. Please re-open if you would like to revisit this


Expose package versions

This is another big PR... And it makes aswfdocker look a bit more like a very simple package management system using docker images...
DockerHub descriptions will now be automatically updated on release, see https://hub.docker.com/repository/docker/aswftesting/ci-base/general
Added

Added ci-baseqt image which was not pushed in a while.
All ci-package-* images now have their actual version in the label and in their tags (e.g. aswf/ci-package-openexr:2019-2.3.0).
New aswfdocker dockergen command line tool to re-generate CI Image Dockerfile and Readme files from a set of templates and current versions.
New aswfdocker pushoverview command line tool to upload descriptions to DockerHub on release.

Changed

All CI images (except ci-common) are now automatically generated from a template and come with a Readme.md (also templated) containing all the current package version numbers.
All package versions have been moved from version bash scripts into the versions.yaml file, which enables the tagging of the image with these versions.
VFX 2021 images are now built against CUDA-11.1.

Fixes #63
Fixes #29
For now nvidia/cudagl:11.1-devel-centos7 is not available yet but I've been told it will be there tomorrow...

A couple of nitpicks:

data.yml seems a bit generic, should it be packages.yml for instance?
Readme.md is a bit surprising, README.md seems more common?

It could be that it's already doing it, should the data.yml files make it into the container to make it easier for consumers of the containers to programmatically determine what's inside?
Also, should the auto-generated filess exist as elements in the git repo, or should they just be generated at build time?

Thanks JF, these are really good points! I'll try to answer:

data.yml seems a bit generic, should it be packages.yml for instance?
-> very generic indeed, but packages is not quite right either as the file contains image name/title/description as well. What about image.yaml?
Readme.md is a bit surprising, README.md seems more common?
-> indeed!
It could be that it's already doing it, should the data.yml files make it into the container to make it easier for consumers of the containers to programmatically determine what's inside?
-> very good idea, I'll copy it into the /usr/local/aswf folder, as well as a cut-down readme and relevant versions if I can...
Also, should the auto-generated filess exist as elements in the git repo, or should they just be generated at build time?
-> I've been going back and forth on this one... I think I prefer keeping them into the repo (hence the aswfdocker dockergen --check command that verifies that the data is up to date), the main reason being that it makes these files a lot more discoverable in the github repo, and I hope would help with visibility and understandability issues... That said it does bloat the PR quite a bit, and could cause confusion if people try to modify these files manually (but I added warnings on all the auto-generated files). If you have good arguments either way please share!

I'm still changing a few things as I want the ci-common to also be templated... expect a few more changes over the next few days!

I'm happy with the current state of the code now, I'll be releasing all the new aswftesting ci packages now so that the tests start passing again.

Thanks JF, indeed .jinja1 seems to be a newish standard, done!

I also started releasing the aswfdocker python utility on pypi... I'm hoping the new templating feature will grow in a way that could help some self-service docker image creation for opensource projects, we'll see!
https://pypi.org/project/aswfdocker/