Add CIF to AEM Archetype

Description
This PR adds Commerce Integration Framework (CIF) capabilities to the AEM Archetype.
It adds:

Archetype optional options includeCommerce & commerceEndpoint
CIF Core Components depencency
proxy components for CIF Core Components
default CIF project config for a minimum setup
CSS files to ui.frontend project

Related Issue
CIF-1212
How Has This Been Tested?
Manually with AEM on prem, AEM Cloud SDK & AEM Cloud instance
Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] I have signed the Adobe Open Source CLA.
[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

Don't merge yet, we will update the PR with CIF Core Components V 1.0.0 once these are released. ETA: 05/14/2020


Bug 1963730: Bump library-go for unrevisioned resourcs

Needs https://github.com/openshift/library-go/pull/1089 and https://github.com/openshift/library-go/pull/1090.

/bugzilla refresh

/lgtm

/lgtm
/approve


Change output level options

Similar to #65 - verbose mode is getting a little - well verbose.
Thinking of having:
-v : verbose mode : useful details to understand how it is running.
-d : debug mode: full output to understand the execution path of the application.

Reflecting on this again I think something is needed as if called with no option it should really put no output otherwise G CLI gets in the way of peoples tools. So we probably want at least 3 levels of output:

Nothing at all. The only things that are seen are what the called VI provides or errors.
Basic operational information - Client has connected, probably the main one.
Full debug output. LabVIEW versions found, LabVIEW launch information etc.

Maybe 2 isn't even necessary.

Going to remove 2. So you get nothing or verbose mode.


Registration

@JuliaRegistrator register

Initial version

Registration pull request created: JuliaRegistries/General/44984
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.0 -m "<description of version>" ec03204a1fec808af7dd41a711794b31a56d2a3d
git push origin v0.1.0

@JuliaRegistrator register

Registration pull request created: JuliaRegistries/General/48074
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.1 -m "<description of version>" 7e2ea3f6ba27882b6f72c57c9e7576c107be105a
git push origin v0.1.1

@JuliaRegistrator register

Add an option for all algorithms to specify if the data should be statically or dynamically allocated, this allows for efficient searches in high-dimensional data

Registration pull request created: JuliaRegistries/General/49048
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.2 -m "<description of version>" 05eecfb10b258a7354a0384fa94314236015ec3f
git push origin v0.1.2

@JuliaRegistrator register
Parallel neighbors fix.

Registration pull request created: JuliaRegistries/General/56113
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.3 -m "<description of version>" 12565d11d57518317718a662be7f5ced7afd5234
git push origin v0.1.3

@JuliaRegistrator register
Support for new OutlierDetectionInterface

@JuliaRegistrator register
Release notes:
Support for new OutlierDetectionInterface

Registration pull request created: JuliaRegistries/General/97776
Tip: Release Notes
Did you know you can add release notes too? Just add markdown formatted text underneath the comment after the text
"Release notes:" and it will be added to the registry PR, and if TagBot is installed it will also be added to the
release that TagBot creates. i.e.
@JuliaRegistrator register

Release notes:

## Breaking changes

- blah

To add them here just re-invoke and the PR will be updated.
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.4 -m "<description of version>" bf52151e50fd9b1f89fd8f58b5e361383e4ac323
git push origin v0.1.4

Registration pull request updated: JuliaRegistries/General/97776
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.4 -m "<description of version>" bf52151e50fd9b1f89fd8f58b5e361383e4ac323
git push origin v0.1.4

Registration pull request created: JuliaRegistries/General/98283
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.1.5 -m "<description of version>" 256ebe6a9a64c189b11c30a3ef6bceb3c2e29b61
git push origin v0.1.5


Nice. I think this fixed my issue. I approve


Can you add this method for stream object?

This would allow the voice mute，I really need this method，Thank you very much.

localMediaStream.getAudioTracks()[0].enabled = false;

I have plan to support it. Maybe 1 week later.

@zhenlovezhen2012 pc.removeStream(localStream) works for muting for me.

@voidvoxel Thanks voidvoxel .Actually I also thought about this solution，but I think this is not the best solution.If we use "localMediaStream.getAudioTracks()[0].enabled = false",the pc only emit an event of onicecandidate.If the scene is many-to-many,if we use "removeStream" method ,we must remove  pc's localStream from every pc object.
Thank you again.
My English is not  good, I hope you can understand. ~.~

@zhenlovezhen2012 yeah, that makes sense. I didn't even think about that because my app only allows one-to-one. Thanks for the issue; this would be very helpful in the future :)

Hi, is this (ability to enable/disable individual tracks) under development?

Not yet.

Thanks. I dont mind to create  PR for it myself but I think I need access to RTCMediaStream.m


Finding 3x4 projection matrix for a camera in CARLA

I'm running CARLA 9.11 on Ubuntu 18.04.
I want to find 3x4 projection matrices for cameras in CARLA. In other words, I want to find a matrix P such that if I have a 3D point provided by something like vehicle.get_location() (the location part of CARLA's transforms) on the shape X =
x
y
z
1

, then I want to be able to get the corresponding 2D position in that camera by x2D ~ P * X, where x2D are the 2D position on format
x
y
1

.
I think this is a pretty common camera matrix format, but I cannot figure out how to get it from CARLA. I can get the location and rotation of the camera (as x, y, z, pitch, roll, yaw), but I have not been able to convert it to a projection matrix P.
The projection matrix P is typically composed as follows:
P = K * [R t]
where K is a 3x3 intrinsic matrix given by
[f 0 Cx
 0 f Cy
 0 0 1]

which I have found (as there are several examples computing it), R is a 3x3 rotation matrix and t is a 3x1 translation.
I have been using the formula from https://github.com/carla-simulator/carla/issues/2516 to get the rotation matrix from pitch, roll, yaw. To get the translation, I've just computed it as t = -R C where C is the camera center position (which I have).
However, doing so does simply not work. I seem to be missing something. Anybody got a clue what's wrong?

Solved it! Turn out CARLA has inconsistent coordinate systems. Instead of P = K * [R t], you instead do P = K * F * [R t]
where
F = flip = np.array([[ 0,  1,  0 ], [ 0,  0, -1 ], [ 1,  0,  0 ]], dtype=np.float32)

please tell me how can you get K, particularly the f of K matrix. I don't know how to get the f of rgb camera in carla.
appreciating

So first you set the field of view (fov) and image size to whatever you want, like so:
fov = 90
im_size_x = 1280
im_size_y = 720
cam_bp = world.get_blueprint_library().find('sensor.camera.rgb')
cam_bp.set_attribute('image_size_x', str(im_size_x))
cam_bp.set_attribute('image_size_y', str(im_size_y))
cam_bp.set_attribute('fov', str(fov))

Then you can manually compute f, Cx and Cy like so:
f  = im_size_x /(2.0 * tan(fov * pi / 360))
Cx = im_size_x / 2.0
Cy = im_size_y / 2.0

Finally, you can build K by
K = np.array([[f, 0, Cx], [0, f, Cy], [0, 0, 1]], dtype=np.float64)

Could you please tell me how to get the RT value? I don't fully understand, thanks so much .

As I mentioned earlier, you get t from t = -R @ C. To get R, see https://github.com/carla-simulator/carla/issues/2516


1.9.0rc2 cherry-pick request: [tf.data] Properly export choose_from_datasets()

This change adds a missing import statement in the tf.contrib.data library. The tf.contrib.data.choose_from_datasets() is already mentioned in the release notes, and its implementation is there, but I neglected to check that it was accessible via the public API. Not including it in the release would make the release notes incorrect.

Thanks Mike!


Add CLI to the model

Add CLI support for the following commands:

Pass a dataset to the model for training
Pass a dataset to the model for testing given a trained model path
Pass a dataset to the model which splits it for training then testing
Pass a single sentence to the model for prediction given a trained model path

Depends on #14

Hi, I am interested in helping out with this issue ...
       I already made some progress and made the CLI for training, testing and single sentence prediction with python fire module ... I just wanted to clarify about the train test split requirement exactly ... you are expecting it to be saving the complete data after the train test split into files and loading them back for repeatability because that's already being taken care of by random state parameter ... so if you can add some info to the exact requirement for train test split separately would be helpful...

Thank You.

Hi @dheerajgattupalli, thanks for your collaboration, there's no need to save the train/test data into separate files on disk.

So what should that command do?

It would take a dataset path, read it into pandas dataframe, then split it to train/test using sklearn train_test_split method, use the training data to train doc2vec then classifier, use the testing data to test the classifier, report back the accuracy metrics.


BigInt serialization support

The BigInt type used throughout the library errors on JSON.serialize (by design) but is a footgun for developers.
My intuition is that something like the suggestion on the linked issue, except just including the receiver function to the JSON.stringify, might be sufficient for our internal JSON serializing of state.
The issue is that deserializing might not be so straightforward since, from a string we may not be able to infer the return type based on the JSON.parse function signature.
JS is so wonderful. Maybe if there is a way at the SDK level to override the stringify and parse methods of BigInt, similar to what this comment suggests, might be the cleanest?

I was just about to create the same issue. Thanks!

JS is so wonderful. Maybe if there is a way at the SDK level to override the stringify and parse methods of BigInt, similar to what https://github.com/GoogleChromeLabs/jsbi/issues/30#issuecomment-1006088574 suggests, might be the cleanest?

Good idea!


Docker: InfluxDB High CPU Usage

OS: Raspbian 10 - Buster
Hardware: Raspberry Pi 4 Model B Rev 1.2
Unifi-poller architecture: Docker-Compose with minimal config changes.
Opening this issue to help others using Unifi-Poller with Docker and experiencing the same issue.
InfluxDB was using 120-130% CPU on average until I made an influxdb.conf in the same folder as the docker-compose yaml with the following parameters (key to the fix is the "store-enabled = false" line, re: https://github.com/influxdata/influxdb/issues/9475):
[meta]
  dir = "/var/lib/influxdb/meta"

[data]
  dir = "/var/lib/influxdb/data"
  wal-dir = "/var/lib/influxdb/wal"
  max-concurrent-compactions = 1

[monitor]
  store-enabled = false
  store-database = "_internal"
  store-interval = "10s"

And then edited the docker-compose file to run influxd with the config, and mount the config as read-only in the container:
services:
  influxdb:
    restart: always
    image: influxdb:latest
    ports:
      - '8086:8086'
    command: influxd -config /etc/influxdb/influxdb.conf
    volumes:
      - influxdb-storage:/var/lib/influxdb
      - ./influxdb.conf:/etc/influxdb/influxdb.conf:ro
    environment:
      - INFLUXDB_DB=${INFLUXDB_DB}
      - INFLUXDB_HTTP_AUTH_ENABLED=${INFLUXDB_HTTP_AUTH_ENABLED}
      - INFLUXDB_ADMIN_USER=${INFLUXDB_ADMIN_USER}
      - INFLUXDB_ADMIN_PASSWORD=${INFLUXDB_ADMIN_PASSWORD}

The InfluxDB container CPU usage is down to 10-14% now. I don't know if this is an issue with the forthcoming InfluxDB 2.0.

The fix was to to disable internal influxdb statistics collection? Is it possible that container runs on a slow disk so the CPU spent a lot of time waiting for the disk?

@davidnewhall What would you call a slow disk? I'm using a Class 10 Samsung Evo+ and utilizing packages like log2ram to limit continuous writes.
When I was searching about this issue, the results came down to either disabling statistics collection or corrupted TSM files or shards during compaction, and I saw no indication in the logs of the latter.

Artificially throttling write speeds sounds like a slow disk.

Really not sure why InfluxDB was giving you high CPU usage. Sounds bad. :(

I'm afraid I don't have much more to add here. If the problem is persistent you may want to reach out to InfluxDB to see if you're running into some sort of a bug. Please re-open this issue if you have more questions I can help with. Good luck!


[Questions] Array input, any scalar type and pagination improvement

It's not a bug, but just a question. In my direct webonyx/graphql implementation, I had an abstract grid schema like:
myGrid(
  filters: {
    id: { operator: in /* enum */, value: [1, 2, 3] },
    name: { operator: like, value: '%test%' }
  },
  sorting: {
    date: asc /* enum */
  },
  limit: { page: 0, size: 15}
) {
  isFirst
  isLast
  currentSize
  totalSize
  rows {
    id
    name
    // etc
  }
}

Now my questions are whether same schema is possible to be achieved in graphqlite. It doesn't have to be one to one, but:

Can I add input which behaves like an array type of any scalar value?
Can I have default values for the input?
Can I extend what is displayed above rows, cause I saw in the documentation that you only return total size there
Eager loading (deferred resolvers). I know someone asked already about it
If those things are not possible, will they? and if they will, can we participate in development to speed things up?

Hey @golaod !

Can I add input which behaves like an array type of any scalar value?

Is this allowed by the GraphQL spec and Webonyx? My understanding is that union types can only be used on objects. Could you maybe post your Webonyx Input type? That would help me understand how to reproduce this.

Can I have default values for the input?

Yes, you simply put the default value in the method signature.
For instance:
/**
 * @Factory
 */
public function filters(string $status = 'on'): Filter

Can I extend what is displayed above rows, cause I saw in the documentation that you only return total size there

You are referring to pagination with Porpaginas (https://graphqlite.thecodingmachine.io/docs/pagination), right?
It is possible, though not very simple.
What you want to do is to write your own "TypeMapper" that maps your class (in our case a class implementing the Porpaginas\ResultIterator interface) to a Webonyx Object type.
You can actually copy-paste the PorpaginasTypeMapper in your code and customize it.
https://github.com/thecodingmachine/graphqlite/blob/b997a25df4815dfb0e3489501f3783c62ec470c3/src/Mappers/PorpaginasTypeMapper.php
You then need to register the type mapper in your application. The way you do that depends on the framework you are using.

Eager loading (deferred resolvers). I know someone asked already about it

Not yet.
That will go in v3.1. See https://github.com/thecodingmachine/graphqlite/issues/14
I actually need help to find a simple syntax for deferred resolvers.

If those things are not possible, will they? and if they will, can we participate in development to speed things up?

Any help is definitely welcome! :)

We contacted you already by email to solve the problem for us, but because you asked here how we did any scalar, I'm attaching it for others who may need it:
Type::nonNull(Type::listOf(new AnyScalarType()))

And the type itself:
class AnyScalarType extends ScalarType
{
    const NAME = 'AnyScalar';

    const SCALAR_NODES = [
        StringValueNode::class,
        BooleanValueNode::class,
        IntValueNode::class,
        FloatValueNode::class
    ];

    /**
     * Serializes an internal value to include in a response.
     *
     * @param string $value
     * @return string
     */
    public function serialize($value)
    {
        return $value;
    }

    /**
     * Parses an externally provided value (query variable) to use as an input
     *
     * @param mixed $value
     * @return mixed
     */
    public function parseValue($value)
    {
        if (!is_scalar($value)) {
            throw new Error('Cannot represent following value as scalar: ' . Utils::printSafeJson($value));
        }

        return $value;
    }

    /**
     * Parses an externally provided literal value (hardcoded in GraphQL query) to use as an input.
     *
     * E.g.
     * {
     *   user(email<EMAIL_ADDRESS>     * }
     *
     * @param \GraphQL\Language\AST\Node $valueNode
     * @return string
     * @throws Error
     */
    public function parseLiteral($valueNode)
    {
        $isScalar = false;
        foreach (self::SCALAR_NODES as $nodeClass) {
            if ($valueNode instanceof $nodeClass) {
                $isScalar = true;
                break;
            }
        }

        if (!$isScalar) {
            throw new Error("Not a valid scalar", [$valueNode]);
        }
        return $valueNode->value;
    }
}

For the record, this was fixed by various PRs in the last month.
Documentation is here:
https://graphqlite.thecodingmachine.io/docs/next/custom-types#registering-a-custom-scalar-type-advanced


File type parsing improve heuristics

With certain files, the wrong filetype appears to be getting parsed.
For example, this m2ts file prases as an AC3 file.
ParsedFile(path=WindowsPath('C:/Users/light/Encoding/temp/maria/00002.m2ts'), ext='.ac3', encoding=None, file_type=<FileType.AUDIO: 'audio'>, mime='application/octet-stream')

ffprobe's results:
Input #0, mpegts, from '00002.m2ts':
  Duration: 00:25:27.87, start: 5614.566667, bitrate: 42425 kb/s
  Program 1
  Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p(tv, bt709, top first), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn
  Stream #0:1[0x1100]: Audio: pcm_bluray (HDMV / 0x564D4448), 48000 Hz, stereo, s16, 1536 kb/s
  Stream #0:2[0x1101]: Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, fltp, 448 kb/s

The first couple bytes
file_bytes=b'\x0bw\\\xccG@\x00\x10\x00\x00\xb0\x11\x00\x00\xc1\x00\x00\x00'

This file gets parsed correctly upon any form of remuxing, even when trying to generate a test clip using the following command:
ffmpeg -to 0:03.00 -i "00002.m2ts" -c copy test.m2ts

Having additional heuristics to determine a file type would be appreciated, but I'm not sure how much can be done here.
One kind of hacky solution I can think of for vssource.source is to check if a video is parsed as anything but VIDEO/IMAGE, and then try simpler heuristics and see if those return a video or image.

Can just force ffprobe


Global styles

Update global styling to match theme (colors, font sizes, fonts, text-decorations...).

I would use a theme concept here as well. where we can add a 'theme' class name to the body so we can add different styles for this theme for this site specifically. this way the blocks can be used in other caesars sites and those can have different themes as well.


Crash related to Iron Chests(?)

Got this crash: https://gist.github.com/Canatee/8681ad5520b6fbc2e786e1d95e607fac
Just after placing an incubator next to an iron chest from the mod Iron Chests like this, see pic.

Have tried to recreate, without luck.
Unsure if it's HF side or IC chest, so forgive me if it's wrong to report it here.
MC 1.10.2
Forge <IP_ADDRESS>1
Harvest Festival 0.5.22
Iron Chests <IP_ADDRESS>7

I added a check, should hopefully be fixed in 0,6


feedback fixes

-double clicking same day does not hide end time in date input
-mouse leaving calendar resets hover highlighting

gr 🎱


Bug in weekly counts?

For a long time, I've been noticing strange things with the :slwiki  (Slovenian language) statistics in the Gender by Wikipedia Language tab, I hope this is the right place for reporting.
Firstly, :slwiki's point is usually not displayed on the "Changes" graph, unless the wiki is in Top 10 or Bottom 10. As far as I gather, other wikis are always there. Secondly, this week (29 Jan '17 - 05 Feb '17) it's in Bottom 10 with 3 new female biographies out of 25, but this number is wrong - a single user in a single day created twice as many female biographies and linked them to corresponding WD items, all correctly labeled as female: see Q11212510, Q18358722, Q28565659, Q2844965, Q7070333 and Q1563211, not to mention multiple other female biographies by others this week (Q28602429, Q28599231 etc.). In fact, if my manual count is correct, 57 biographies were created in this period on :slwiki, out of which there are 31 females and one transgender person (currently female).
Can you please check? This issue might affect other wikis, too.

EDIT: nevermind, it just has a lag of one week (which could simply be explained somewhere on the page). Only the issue with the :slwiki's point remains.


Syntax error? Umm....

Okay so I went to test and got this. I don't know what's wrong. I've copied everything from the tutorial exactly.
module.js:657
    throw err;
    ^
SyntaxError: C:\Users\Etanarvazac Taseet\Desktop\Custom Discord Bot\auth.json: Unexpected token ) in JSON at position 76
    at JSON.parse (<anonymous>)
    at Object.Module._extensions..json (module.js:654:27)
    at Module.load (module.js:554:32)
    at tryModuleLoad (module.js:497:12)
    at Function.Module._load (module.js:489:3)
    at Module.require (module.js:579:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (C:\Users\Etanarvazac Taseet\Desktop\Custom Discord Bot\bot.js:3:12)
    at Module._compile (module.js:635:30)
    at Object.Module._extensions..js (module.js:646:10)

Not sure why the code field is not working...

Found it. I made a big error in the auth.json somehow. (Had the wrong symbol at the end of doc)


add desired of ocp into clusterinfo.status

issue: https://github.com/open-cluster-management/backlog/issues/12519

/assign @qiujian16


Add Decimal128 and Decimal256 to downcast_primitive

Which issue does this PR close?

Closes #3055.
Rationale for this change

What changes are included in this PR?

Are there any user-facing changes?

Interesting, there are a few tests failed due to this change. I will take a deep look.

I've added an API change, as this may lead to downstream breakage (likely a good thing)

I will rebase once https://github.com/apache/arrow-rs/pull/3064 is merged.


FIP: Specify the BLS algorithm

The protocol assumes aggregatable signatures (e.g., BLS, Schnorr), resilient to rogue public key attacks (see Boneh, Drijvers, and Neven construction).

We need to specify the exact BLS algorithm we use.

@Kubuxu could you add a line to the FIP specifying this?

It's not.

Specifically, document #592.

https://github.com/filecoin-project/FIPs/pull/1064

Closing as https://github.com/filecoin-project/FIPs/pull/1064 has been merged


updated our support matrix

What does this pull request do?
Marks some old versions as deprecated, while adding some new versions.
Why is it important?
Some versions have reached EOL a long time ago (Django 1.10 and older),
others a bit more recently (Python 3.4 went EOL on March 16 2019),
and lastly, some Flask versions are just really old (Flask doesn't
have EOL policies).
The plan is to mark these deprecated in 5.4, and drop them from the
support matrix in 6.0. We'd also stop testing these versions,
and remove any old compatibility shims with 6.0.

@nehaduggal @lreuven please weigh in on these plans if you'd like. We don't have any usage statistics for how many users are still on old flask/django versions, but at least for Django, the versions we intend to stop supporting went EOL years ago.
As for Python 3.4, download statistics show it below 1%.


Update projects-enhanced-report-format.md

I think these 2 items are no longer valid:

You can't publish the report in Power BI App.
You can't download PBIX.

I base it on this article which has the same list but has been recently updated:
https://github.com/MicrosoftDocs/powerbi-docs/blob/f4e689cc8837b0a72fb00f1f536404147ed74dbe/powerbi-docs/developer/projects/projects-report.md

@maggiesMSFT
Can you review the proposed changes?
Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off


⚠ Bofrost.at has degraded performance

In 8d4c50e, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 3137 ms

Resolved: Bofrost.at performance has improved in 2ce9937 after 8 minutes.


Mentioning about the Classic and London unit testing styles

I think it would be worth having a section where the 2 different styles of unit testing: Classic and London are presented with further references. I think is very important to be aware of the 2 styles, their pros and cons, and choose the style that fits the need.
As a book that I recommend is Unit Testing Principles, Practices, and Patterns for understanding better the 2 different styles.

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

ID: 51947dc8-9ae8-21fa-13db-a7ffb3f9bc0e
Version Independent ID: be661bf5-6f6e-cd18-344b-253edf5751ae
Content: Best practices for writing unit tests - .NET Core
Content Source: docs/core/testing/unit-testing-best-practices.md
Product: dotnet-core
GitHub Login: @jpreese
Microsoft Alias: wiwagn

cc @jpreese

cc @jpreese


chore: prepare 2.9.2 release

Summary
Suggesting to roll a new release after merging this one

I think we still need to fix the HasFactory issue right?

@barryvdh good point, I merged https://github.com/barryvdh/laravel-ide-helper/pull/1196 and redid this one!

Merged and tagged! Thanks!


Readonly mode

I think it would be useful for presentation if people want to follow what's going on in Atom on their computer, but not allow anyone else to edit.  Also, having the ability to give people access to edit would be useful too

FWIW: This would be super helpful for me when teaching, so that students see my code if they fall behind, but I don't want them to be able to change my code.
I'm willing to research the effort required to implement this if someone can point me in the right direction.

@JeffCohen: Thanks for the feedback. And a big thanks for the offer to help! :bow:
I can definitely see the benefit of a read-only mode for teaching. However, given that Teletype is focused on collaborative coding, read-only mode doesn't feel like a feature that is within the scope that we have have envisioned for Teletype. I worry that adding a read-only mode would complicate the user interface and increase the complexity of the code, thus increasing the cost of developing/maintaining Teletype's core functionality of collaborative coding.
If you think that a read-only mode should be within the scope of Teletype's vision and that there's a way to implement it where the benefits outweigh the costs, the first step would be for you to open an RFC describing the feature in detail. We don't yet have a template for RFCs, but you can use RFC-001 as an example. You'd want your RFC to include the same sections (Summary, Motivation, Explanation, Drawbacks, and Unresolved Questions) and roughly the same level of detail. You would then open a pull request that adds your RFC to doc/rfcs, similar to the way that https://github.com/atom/teletype/pull/231 introduced RFC-001. I hope this helps. If you have any questions about putting together the RFC, just let us know.

Got it, that explanation helps a lot.  I'll definitely ponder if there's a low-impact way to do this, and if so I'll definitely put an RFC together.  Thanks!


Colab branch is outdated

E.g. in 1.1(master, Colab) the Colab branch has outdated (pre-BIP maybe?) definition of Schnorr signing, but uses test_framework from master. Due to this mismatch the exercises are unsolvable.
Is there anything else than rebasing Colab on top of master needed?

Fixed in #173


Daily Data Date Filter Enhancement

Problem statement
The Daily Data table date filter is used by both the support team and STLTs. The date filter starts with very high (01/01/2000) and very low (01/01/3000) values that make using the date selector tool difficult because you need to scroll for lots of years in order to get to something similar to today. Ideally, it should start at a date closer to when RS started receiving data, and end at something less than 900 years away to make the date selection tool more usable. Additionally, once you input a date range and click filter, the date filter returns to the default values instead of showing the dates that are currently filtered for.
What you need to know

Daily Data Page
Screenshot:
 ...

Acceptance criteria

[ ] Daily Data date filter has more useable default values
[ ] After filtering for a date range, the Daily Data date filter shows the current date range filtered for instead of the default values

To do

[ ] ...

split into two tickets. #8588 and #8554


{CI} Migrate pipeline to new organization azclitools

Migrate pipeline to azclitools org.
Build pipeline
Release pipeline

/azp where

/azp where

/azp where

/azp run


Stub Amperize module to improve tests

At the moment, we're using Amperize in our {{amp_content}} helper to make our HTML AMP conform.
Amperize should be stubbed to return values or errors we want. This would improve our tests and we would actually be able to test for error handling on our side and use fake image-sources instead of real one.
See comment here

Closing. I doubt anybody will work on this. We will try to optimise unit tests when continuing with #9178.


features：pdk.kong.upstream

New features：
pdk.kong.upstream
https://discuss.konghq.com/t/data-center-aware-load-balancing/5667

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


safeeyes: 2.2.1 -> 2.2.2

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for safeeyes is: Protect your eyes from eye strain using this simple and beautiful, yet extensible break reminder. A Free and Open Source Linux alternative to EyeLeo
meta.homepage for safeeyes is: http://slgobinath.github.io/SafeEyes
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.2.2 with grep in /nix/store/sa3shw77wcnkzpmnagq7wpyq3chgj41m-safeeyes-2.2.2
found 2.2.2 in filename of file in /nix/store/sa3shw77wcnkzpmnagq7wpyq3chgj41m-safeeyes-2.2.2

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

safeeyes

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/sa3shw77wcnkzpmnagq7wpyq3chgj41m-safeeyes-2.2.2 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A safeeyes https://github.com/r-ryantm/nixpkgs/archive/b361684c722b0b78a1058e2492381eb22d2e147d.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/b361684c722b0b78a1058e2492381eb22d2e147d#safeeyes

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/sa3shw77wcnkzpmnagq7wpyq3chgj41m-safeeyes-2.2.2
ls -la /nix/store/sa3shw77wcnkzpmnagq7wpyq3chgj41m-safeeyes-2.2.2/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages built:

safeeyes
safeeyes.dist

Maintainer pings
cc @srghma for testing.

Note: libappindicator-gtk3 is no longer a buildInput

https://github.com/slgobinath/SafeEyes/commit/ea2c74797804736cb43d7b1bd991ad9396a4eb19


Metrics Explorer: implement the time selector menu

The time selector menu is an important part of the explorer experience.
This is an aspect of the current explore tool that people like.

To implement:

implement a metric API call for detemining the initial time range for the explorer
implement a metric API that returns available time grains based on the minimum-available timegrain of the dataset
use existing menu components to implement the menu
implement the button & subtext time range

We need to get this together. I think @djbarnwal or @ericpgreen2 could tackle this piece as well.

@AdityaHegde is there an API call that would enable us to get the initial time range?
I'm not usre we need the "metric API that returns available time grains" part for MVP ~ let me know what y'all think. This should be directly accessible from the model state, since we know the minimum available time grain for each TIMESTAMP column.


Add missing elasticsearch dependencies to opencast-ingest feature

The ingest service has a dependency on the elastic search bundles, but the feature does not contain those. This PR adds the elastic search bundles to the opencast-ingest feature.
It would be the first time that a non-admin node uses the index. Can this have side effects?
Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=opencast-ingest; type=karaf.feature; version="[12.0.0,12.0.0]"; filter:="(&(osgi.identity=opencast-ingest)(type=karaf.feature)(version>=12.0.0)(version<=12.0.0))" [caused by: Unable to resolve opencast-ingest/12.0.0: missing requirement [opencast-ingest/12.0.0] osgi.identity; osgi.identity=opencast-ingest-service-impl; type=osgi.bundle; version="[12.0.0,12.0.0]"; resolution:=mandatory [caused by: Unable to resolve opencast-ingest-service-impl/12.0.0: missing requirement [opencast-ingest-service-impl/12.0.0] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.opencastproject.elasticsearch.api)(version>=12.0.0)(!(version>=13.0.0)))"]]

[ ] have a concise title
[ ] close an accompanying issue if one exists
[ ] be against the correct branch
[ ] include migration scripts and documentation, if appropriate
[ ] pass automated tests
[ ] have a clean commit history
[ ] have proper commit messages (title and body) for all commits

It would be the first time that a non-admin node uses the index. Can this have side effects?

I think that will break the ingest distributions since the default setup doesn't allow them access to Elasticsearch.
Do you know where this dependency came from?

It was introduced with the removal of the series service solr index. I deployed the fix on our cluster. The ingest node is working now, but I have to test it further.

It was introduced with the removal of the series service solr index. I deployed the fix on our cluster. The ingest node is working now, but I have to test it further.

The problem is that according to our docs, no node except admin needs to have access to Elasticsearch. So this may cause significant infrastructure trouble. At least, we need a major documentation update.

Seems like this is used only for this new feature: https://github.com/opencast/opencast/pull/3586
Let's see if we cannot implement that differently

Pull request #3810 contains an alternative approach to fixing the issue, removing the dependency altogether.


Group state might be misbehaving because

System Health details
upon updating to 1.9.10 I changed several groups from listing entities (lights in this case) to the new wildcard,
documented in  https://github.com/bramstroker/homeassistant-powercalc/blob/master/docs/source/sensor-types/group/include-entities.rst#wildcard
config see below.
these lights are mostly powered off physically, and with the listed entities that never caused a logging. With the new wildcard, it seems to bother Powercalc ;-): Group state might be misbehaving because
I can understand PC notices it cant see the lights currently, but maybe this is a debug message, and not as much a error level message.
It is by design of the user
Moreover: when actually powered the grouped sensor does not change from unavailable to a state.
I fear I do experience the same as https://github.com/bramstroker/homeassistant-powercalc/issues/1920 because even with my original entities those grouped sensors remain unavailable.
downgrading to 1.9.9 brings back my grouped sensor values correctly
Checklist

[X] I have read the FAQ to see if there is a known solution to my problem.
[X] I have enabled debug logging for my installation.
[X] I have filled out the issue template to the best of my ability.
[X] This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
[X] This issue is not a duplicate issue of currently previous issues..

Describe the issue
unexpected error logging
Reproduction steps

See description

...
Debug logs
Deze fout is ontstaan door een aangepaste integratie.

Logger: custom_components.powercalc.sensor
Source: custom_components/powercalc/sensor.py:631
Integration: Powercalc (documentation, issues)
First occurred: 14:40:18 (3 occurrences)
Last logged: 14:40:18

Group state might be misbehaving because there was an error with an entity
Traceback (most recent call last):
  File "/config/custom_components/powercalc/sensor.py", line 631, in create_sensors
    child_entities = await create_sensors(
                     ^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/powercalc/sensor.py", line 680, in create_sensors
    raise SensorConfigurationError(exception_message)
custom_components.powercalc.errors.SensorConfigurationError: Could not resolve any entities in group 'Plafond spots'

Diagnostics dump or YAML config
            - create_group: Terrace outdoors
              unique_id: powercalc_group_terrace_outdoors
              include:
                wildcard: light.terrace_spot_*
#               entities:
#                 - entity_id: light.terrace_spot_1
#                 - entity_id: light.terrace_spot_2
#                 - entity_id: light.terrace_spot_3
#                 - entity_id: light.terrace_spot_4

The error message is about "Plafond spots"
Could not resolve any entities in group 'Plafond spots'
But the configuration you shared is about Terrace outdoors?
Also entities is not really formatted right, is this also part of the configuration? Or you just mentioning these as possible entities for the issue report?

sorry, missed a few ticks there. and arghh been copying to much today:
this is Plafond spots:
            - create_group: Plafond spots
              unique_id: powercalc_group_plafond_spots
# https://github.com/bramstroker/homeassistant-powercalc/blob/master/docs/source/sensor-types/group/include-entities.rst#wildcard
#               include:
#                 wildcard: light.hue_ambiance_spot_*
              entities:
                - entity_id: light.hue_ambiance_spot_1
                - entity_id: light.hue_ambiance_spot_2
                - entity_id: light.hue_ambiance_spot_3
                - entity_id: light.hue_ambiance_spot_4
                - entity_id: light.hue_ambiance_spot_5
                - entity_id: light.hue_ambiance_spot_6
                - entity_id: light.hue_ambiance_spot_7
                - entity_id: light.hue_ambiance_spot_8
                - entity_id: light.hue_ambiance_spot_9
                - entity_id: light.hue_ambiance_spot_10
                - entity_id: light.hue_ambiance_spot_11
                - entity_id: light.hue_ambiance_spot_12
                - entity_id: light.hue_ambiance_spot_13
                - entity_id: light.hue_ambiance_spot_14

same story: off power mostly, doesnt throw an error in 1.9.9 as configured above.
when 1.9.10 the posted error is thrown and even turning on the power does not bring the unavailable entities back to live.

Let's try to focus at one things at a time. This is too much information and clutter to get clear reproduction steps. The problem with initial unknown is definitely a non related / other issue. I think it was reported before by another user, but unsure if this was still an issue.
The error message you posted "Could not resolve entities" is definitely an error message and no debug message. This means powercalc could not find any entities to setup the group.
So that's also the reason the group cannot be setup and stays unavailable.
Let's focus on your posted configuration and group.
 - create_group: Plafond spots
   unique_id: powercalc_group_plafond_spots
   ....

I see you commented the wildcard part, so I can conclude this is not active anymore?
If I understand correctly you are saying this group does not work with the manual entities listing light.hue_ambiance_spot_1 to light.hue_ambiance_spot_14 in v1.9.10, but when you revert to v1.9.9 it works again?
I went through all the changes in v1.9.10 and only part which was overhauled is related to the include functionality. The behaviour for the entities configuration should be the similar as before the changes, and I have several test cases which also work fine.
So I'm highly surprised this is broken for you somehow.
Before investigating further I want to be 100% certain this is the case. You don't have any wildcard or include logic going on anymore and restarted afterwards?

Btw https://github.com/bramstroker/homeassistant-powercalc/issues/1922
This issue report seems very similar to your initial "unknown" problem.

Should hopefully be fixed now with #1954
Are you able to test by installing the latest master branch version? Thanks.

Issue with initial unknown as reported in #1922 should be fixed now. The problem was the power groups were only updated on state changes of underlying sensors, but unavailable sensors / which stay unavailable will never cause a state change, so that's why the power sensor always stayed unknown, until one of the power sensors became available.
I calculate the initial group state now once during startup of HA, and after that only on state changes.
This does not solve your other issue where you have problems with setting up the group at all in v1.9.10.
See my comment above. This needs more information / debugging.

ok, let me try to install that master from a working 1.9.9 configuration with group entities listed verbosely.
uhm... it wont go, remains swirling. Maybe I need to try manual download:

Maybe my case of problems with group sensors might help finding the problem:

I have a all yaml configuration
the problem started very likely after 1.9.6, downgrading helped for a few days but not for good
currently I am on V1.9.10 with several re-installs (without deleted the integration before though)
for the groups in question power sensors and energy sensors have been correctly created by powercalc

Excerpt from the error logs seem to point towards this: energy calc is done ('new value..') but then the sensor goes back to an initial value of always the same value ('recalculate ...').
here are some of the relevant lines:
2023-12-19 09:10:03.876 DEBUG (MainThread) [custom_components.powercalc.sensors.group] sensor.technik_energy: New value: 2836.1160 2023-12-19 09:11:03.898 DEBUG (MainThread) [custom_components.powercalc.sensors.group] sensor.technik_energy: Recalculate, current value: 2836 2023-12-19 09:11:03.902 DEBUG (MainThread) [custom_components.powercalc.sensors.group] sensor.technik_energy: New value: 2836.1192 2023-12-19 09:12:00.860 DEBUG (MainThread) [custom_components.powercalc.sensors.group] sensor.technik_energy: Recalculate, current value: 2836

@RoSche2001 I appreciate your efforts to provide good debug information. But currently we are mixing up different issues in this same issue report. This makes it very hard to keep track of things and creates a lot of confusion.
The issue report from @Mariusthvdb was about the include wildcard option not working correctly. When this option is used it results in the error Could not resolve any entities in group 'Dining table'. So please only post comments / information related to that.
@RoSche2001 could you please post your reply for the energy calculation misbehaving in a new issue report, and delete the comment here. That would help a lot to keep things organized. Thanks.

are you sure this config is correct? I copied it from the documentation, and was surprised we didnt have to use the entities option too, so please check if I should do that after all? otoh, the config checks fine so I guess that's not it...

Yes it should work the way you have it.
It's clear now everything is working fine the old way, but stops working when you try to use the wildcard pattern feature.
I'll have a closer look in a few days.

did a quick test in my local dev instance but it's working fine for me.
what does your full configuration looks including the parent group?

here you go, Ive cut down on a lot of entities, but this is the full structure of my config:
##########################################################################################
# package Power calc
# https://github.com/bramstroker/homeassistant-powercalc
# https://github.com/bramstroker/homeassistant-powercalc/blob/master/docs/supported_models.md
##########################################################################################

powercalc:
  disable_extended_attributes: true
  enable_autodiscovery: false
  energy_sensor_naming: '{} device energy'
  power_sensor_naming: '{} device power'
  ignore_unavailable_state: true
  energy_sensor_precision: 2
  unavailable_power: 0
  create_utility_meters: true
  utility_meter_types:
    - daily
    - yearly

  sensors:

##########################################################################################
# Daily energy, so the consumption of the devices connected to the plugs
# creates: daily energy sensors for all individuals sensor.[source object_id]_daily
# and the following grouped sensors:
# sensor.alle_schakelaars_samen_totaal_daily, summed daily energy sensor for all entities
# sensor.alle_schakelaars_samen_actueel, summed power for all entities W (source: '_actueel')
# sensor.alle_schakelaars_samen_totaal, summed energy for all entities kWh (source: '_totaal)
##########################################################################################

    - energy_sensor_id: sensor.patchboard_zolder_totaal
      power_sensor_id: sensor.patchboard_zolder_actueel

    - energy_sensor_id: sensor.inductieplaat_totaal
      power_sensor_id: sensor.inductieplaat_actueel

    - create_group: Alle schakelaars samen
      unique_id: powercalc_group_alle_schakelaars_samen
      energy_sensor_naming: '{} totaal'
      power_sensor_naming: '{} actueel'
      utility_meter_types:
        - daily

      entities:
##########################################################################################
# Power consumption sensors
##########################################################################################

# Shelly
        - energy_sensor_id: sensor.toaster_keuken_totaal
          power_sensor_id: sensor.toaster_keuken_actueel
        - energy_sensor_id: sensor.plus_plug_s_totaal
          power_sensor_id: sensor.plus_plug_s_actueel
        - energy_sensor_id: sensor.tester_totaal
          power_sensor_id: sensor.tester_actueel

# Qubin0
        - energy_sensor_id: sensor.netwerk_library_totaal
          power_sensor_id: sensor.netwerk_library_actueel

#etcec

##########################################################################################
# Device energy/power sensors, so the device consumption of the plugs themselves
##########################################################################################

    - create_group: Switches total
      unique_id: powercalc_group_switches_total
      entities:
#         - entity_id: switch.attic_living

        - entity_id: switch.freezer_bijkeuken
        - entity_id: switch.freezer_garage
        - entity_id: switch.front_room
        - entity_id: switch.vaatwasser_keuken
        # etc
# Shelly:
        - entity_id: switch.toaster_keuken
          <<: &shelly
            standby_power: 0.5
            fixed:
              power: 0.8
        - entity_id: switch.plus_plug_s
          <<: *shelly
        - entity_id: switch.tester
        - entity_id: switch.slaapkamer_stopcontact
          <<: *shelly

    - create_group: Alle lampen
      unique_id: powercalc_group_alle_lampen
      entities:

        - create_group: Light inside total
          unique_id: powercalc_group_lights_inside_total
          entities:

#           via DIRIGERA Homekit
            - entity_id: light.bol_lamp

#           via ZHA Skyconnect
            - create_group: Kerst sterren
              unique_id: powercalc_group_kerst_sterren
              entities:
                - entity_id: light.ster_links
                - entity_id: light.ster_rechts

            - create_group: Plafond spots
              unique_id: powercalc_group_plafond_spots
# https://github.com/bramstroker/homeassistant-powercalc/blob/master/docs/source/sensor-types/group/include-entities.rst#wildcard
#               include:
#                 wildcard: light.hue_ambiance_spot_*
              entities:
                - entity_id: light.hue_ambiance_spot_1
                - entity_id: light.hue_ambiance_spot_2
                - entity_id: light.hue_ambiance_spot_3
                - entity_id: light.hue_ambiance_spot_4
                - entity_id: light.hue_ambiance_spot_5
                - entity_id: light.hue_ambiance_spot_6
                - entity_id: light.hue_ambiance_spot_7
                - entity_id: light.hue_ambiance_spot_8
                - entity_id: light.hue_ambiance_spot_9
                - entity_id: light.hue_ambiance_spot_10
                - entity_id: light.hue_ambiance_spot_11
                - entity_id: light.hue_ambiance_spot_12
                - entity_id: light.hue_ambiance_spot_13
                - entity_id: light.hue_ambiance_spot_14

            - create_group: Dining table
              unique_id: powercalc_group_dining_table
#               include:
#                 wildcard: light.dining_table_lamp_*
              entities:
                - entity_id: light.dining_table_lamp_1
                - entity_id: light.dining_table_lamp_2
                - entity_id: light.dining_table_lamp_3

#     Ikea Tradfri
            - entity_id: light.corridor_pool
            - entity_id: light.boekenkas
              standby_power: 0.18
              linear:
                attribute: brightness
                calibrate:
                  - 1 -> 0.3
                  - 3 -> 0.7
                  - 13 -> 0.8
                  - 26 -> 0.9
                  - 38 -> 1.0
                  - 51 -> 1.1
                  - 64 -> 1.3
                  - 76 -> 1.4
                  - 89 -> 1.6
                  - 102 -> 1.8
                  - 115 -> 2.3
                  - 128 -> 2.5
                  - 140 -> 2.9
                  - 153 -> 3.3
                  - 166 -> 3.8
                  - 178 -> 4.1
                  - 191 -> 5.1
                  - 204 -> 5.9
                  - 217 -> 6.4
                  - 230 -> 8.1
                  - 242 -> 9.4
                  - 255 -> 10.8
            - entity_id: light.bureau_left
            - entity_id: light.bureau_right
            - entity_id: light.pantry
            - entity_id: light.gym

#     Philips Hue
#         Philips Hue smart plug
            - entity_id: light.attic_living
            - entity_id: light.hue_go
            - entity_id: light.corridor_cabinet
            - entity_id: light.dorm_ceiling_panel

        - create_group: Light outside total
          unique_id: powercalc_group_lights_outside_total
          entities:

            - create_group: Terrace outdoors
              unique_id: powercalc_group_terrace_outdoors
#               include:
#                 wildcard: light.terrace_spot_*
              entities:
                - entity_id: light.terrace_spot_1
                - entity_id: light.terrace_spot_2
                - entity_id: light.terrace_spot_3
                - entity_id: light.terrace_spot_4

# Ikea Tradfri
            - entity_id: light.parking_light
# Philips Hue
            - entity_id: light.backdoor_outdoors
            - entity_id: light.pond_alley
            - entity_id: light.garden_terrace_floodlight
            - entity_id: light.garden_backyard_floodlight
            - entity_id: light.driveway_floodlight
            - entity_id: light.porch_floodlight
            - entity_id: light.gate_outdoors
            - entity_id: light.pond_tools

    - create_group: Non Switches total
      unique_id: powercalc_group_non_switches_total
      entities:
        - entity_id: device_tracker.smartgateways_watermeter
          fixed:
            power: 4.9
#         - entity_id: device_tracker.airport_express_water
#           fixed:
#             power: 4.1
        - entity_id: device_tracker.awair_element
          fixed:
            states_power:
              home: 1.1
              not_home: 0
        - entity_id: sensor.vindstyrka_temperature
          fixed:
            power: 0.9
        - entity_id: media_player.googlehome_hub
          standby_power: 2.3
          fixed:
            states_power:
              playing: 4.1
              paused: 3.3
              idle: 2.8
        - entity_id: media_player.googlehome_hall
        - entity_id: media_player.homepod_keuken

        - entity_id: fan.luchtreiniger_hall
          <<: &ikea_fan
            standby_power: 0.5
            linear:
              attribute: percentage
              calibrate:
                - 10 -> 1.5
                - 18 -> 1.6
                - 20 -> 1.7
                - 30 -> 2.1
                - 40 -> 3.3
                - 50 -> 5.2
                - 60 -> 8.5
                - 70 -> 11.4
                - 80 -> 16.3
                - 90 -> 18.8
                - 100 -> 21.9
        - entity_id: fan.luchtreiniger_woonkamer
          <<: *ikea_fan

        - unique_id: powercalc_daily_fixed_bel_trafo
          daily_fixed_energy:
            value: 4.9
            unit_of_measurement: W

    - create_group: Heaters total
##########################################################################################
# creates only group entities:
# sensor.heaters_total_energy
# sensor.heaters_total_energy_daily
# sensor.heaters_total_energy_yearly
# sensor.heaters_total_power
##########################################################################################
      unique_id: powercalc_group_heaters_total
      energy_sensor_naming: '{} energy'
      power_sensor_naming: '{} power'
      entities:

        - create_group: Heaters devices
##########################################################################################
# creates
# group entities:
# sensor.heaters_devices_device_energy
# sensor.heaters_devices_device_energy_daily
# sensor.heaters_devices_device_energy_yearly
# sensor.heaters_devices_device_power

# individual entities:
# sensor.[object_id]_device_power
# sensor.[object_id]_device_energy
# sensor.[object_id]_device_energy_daily
##########################################################################################
          unique_id: powercalc_group_heaters_devices
          entities:
            - entity_id: device_tracker.heater_dorm
              <<: &mill_heater
                fixed:
                  states_power:
                    home: 1.7
                    not_home: 0
            - entity_id: device_tracker.heater_library
              <<: *mill_heater
            - entity_id: device_tracker.heater_office
              <<: *mill_heater

        - create_group: Heaters consumption
##########################################################################################
# creates:
# sensor.heaters_consumption_energy
# sensor.heaters_consumption_energy_daily
# sensor.heaters_consumption_energy_yearly
# sensor.heaters_consumption_power

# required a lot of manual editing of the 'Dummy' object_ids and not use the default
# _device_energy naming....
# sensor.[object_id]_current_energy
# sensor.[object_id]_current_energy_daily
# sensor.[object_id]_current_energy_yearly
##########################################################################################
          unique_id: powercalc_group_heaters_consumption
          energy_sensor_naming: '{} energy'
          power_sensor_naming: '{} power'
          entities:
            - power_sensor_id: sensor.heater_library_current_power
            - power_sensor_id: sensor.heater_office_current_power
            - power_sensor_id: sensor.heater_dorm_current_power

restarted again with debug on:
2023-12-21 11:17:07.875 DEBUG (MainThread) [custom_components.powercalc.group_include.include] Found possible include entities: ['light.dining_table_lamp_2', 'light.dining_table_lamp_3', 'light.dining_table_lamp_1']
2023-12-21 11:17:07.875 ERROR (MainThread) [custom_components.powercalc.sensor] Group state might be misbehaving because there was an error with an entity
Traceback (most recent call last):
  File "/config/custom_components/powercalc/sensor.py", line 631, in create_sensors
    child_entities = await create_sensors(
                     ^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/powercalc/sensor.py", line 680, in create_sensors
    raise SensorConfigurationError(exception_message)
custom_components.powercalc.errors.SensorConfigurationError: Could not resolve any entities in group 'Dining table'

note this Is with power cut off from those bulbs, which the regular group config with the listed entities does Not bother.

restarting with the lights on power yields the same but not the same....:
2023-12-21 11:20:44.331 DEBUG (MainThread) [custom_components.powercalc.group_include.include] Found possible include entities: ['light.dining_table_lamp_2', 'light.dining_table_lamp_3', 'light.dining_table_lamp_1']
2023-12-21 11:20:44.331 ERROR (MainThread) [custom_components.powercalc.sensor] Group state might be misbehaving because there was an error with an entity
  File "/config/custom_components/powercalc/sensor.py", line 631, in create_sensors
  File "/config/custom_components/powercalc/sensor.py", line 680, in create_sensors
custom_components.powercalc.errors.SensorConfigurationError: Could not resolve any entities in group 'Dining table'

separate log for the entities listed group:
2023-12-21 11:26:47.048 DEBUG (MainThread) [custom_components.powercalc.discovery] light.dining_table_lamp_1: Auto discovered model (manufacturer=Signify Netherlands B.V., model=Hue ambiance lamp (LTW010))
2023-12-21 11:26:47.048 DEBUG (MainThread) [custom_components.powercalc.sensors.power] Creating power sensor (entity_id=light.dining_table_lamp_1 entity_category=None, sensor_name=Dining table lamp 1 device power strategy=lut manufacturer=signify model=LTW010 unique_id=1492a44a-207f-4732-88f2-089303564d29)
2023-12-21 11:26:47.048 DEBUG (MainThread) [custom_components.powercalc.strategy.lut] Loading LUT data file: /config/custom_components/powercalc/power_profile/../data/signify/LTW010/color_temp.csv.gz
2023-12-21 11:26:47.054 DEBUG (MainThread) [custom_components.powercalc.strategy.lut] LUT file loaded: 1785 lines
2023-12-21 11:26:47.054 DEBUG (MainThread) [custom_components.powercalc.sensors.energy] Creating energy sensor: Dining table lamp 1 device energy
2023-12-21 11:26:47.054 DEBUG (MainThread) [custom_components.powercalc.sensors.utility_meter] Creating utility_meter sensor: Dining table lamp 1 device energy daily (entity_id=sensor.dining_table_lamp_1_device_energy_daily)
2023-12-21 11:26:47.054 DEBUG (MainThread) [custom_components.powercalc.sensors.utility_meter] Creating utility_meter sensor: Dining table lamp 1 device energy yearly (entity_id=sensor.dining_table_lamp_1_device_energy_yearly)
2023-12-21 11:26:47.055 DEBUG (MainThread) [custom_components.powercalc.discovery] light.dining_table_lamp_2: Auto discovered model (manufacturer=Signify Netherlands B.V., model=Hue ambiance lamp (LTW010))
2023-12-21 11:26:47.055 DEBUG (MainThread) [custom_components.powercalc.sensors.power] Creating power sensor (entity_id=light.dining_table_lamp_2 entity_category=None, sensor_name=Dining table lamp 2 device power strategy=lut manufacturer=signify model=LTW010 unique_id=38b13e99-1b93-4f76-be40-edcdf7cd647d)
2023-12-21 11:26:47.055 DEBUG (MainThread) [custom_components.powercalc.sensors.energy] Creating energy sensor: Dining table lamp 2 device energy
2023-12-21 11:26:47.055 DEBUG (MainThread) [custom_components.powercalc.sensors.utility_meter] Creating utility_meter sensor: Dining table lamp 2 device energy daily (entity_id=sensor.dining_table_lamp_2_device_energy_daily)
2023-12-21 11:26:47.055 DEBUG (MainThread) [custom_components.powercalc.sensors.utility_meter] Creating utility_meter sensor: Dining table lamp 2 device energy yearly (entity_id=sensor.dining_table_lamp_2_device_energy_yearly)
2023-12-21 11:26:47.055 DEBUG (MainThread) [custom_components.powercalc.discovery] light.dining_table_lamp_3: Auto discovered model (manufacturer=Signify Netherlands B.V., model=Hue ambiance lamp (LTW010))
2023-12-21 11:26:47.055 DEBUG (MainThread) [custom_components.powercalc.sensors.power] Creating power sensor (entity_id=light.dining_table_lamp_3 entity_category=None, sensor_name=Dining table lamp 3 device power strategy=lut manufacturer=signify model=LTW010 unique_id=ae2465cc-7a42-4dd0-8ad5-6ae75437506c)
2023-12-21 11:26:47.055 DEBUG (MainThread) [custom_components.powercalc.sensors.energy] Creating energy sensor: Dining table lamp 3 device energy
2023-12-21 11:26:47.055 DEBUG (MainThread) [custom_components.powercalc.sensors.utility_meter] Creating utility_meter sensor: Dining table lamp 3 device energy daily (entity_id=sensor.dining_table_lamp_3_device_energy_daily)
2023-12-21 11:26:47.056 DEBUG (MainThread) [custom_components.powercalc.sensors.utility_meter] Creating utility_meter sensor: Dining table lamp 3 device energy yearly (entity_id=sensor.dining_table_lamp_3_device_energy_yearly)
2023-12-21 11:26:47.056 DEBUG (MainThread) [custom_components.powercalc.sensors.group] Creating grouped power sensor: Dining table device power (entity_id=sensor.dining_table_device_power)
2023-12-21 11:26:47.056 DEBUG (MainThread) [custom_components.powercalc.sensors.group] Creating grouped energy sensor: Dining table device energy (entity_id=sensor.dining_table_device_energy)
2023-12-21 11:26:47.056 DEBUG (MainThread) [custom_components.powercalc.sensors.utility_meter] Creating utility_meter sensor: Dining table device energy daily (entity_id=sensor.dining_table_device_energy_daily)
2023-12-21 11:26:47.057 DEBUG (MainThread) [custom_components.powercalc.sensors.utility_meter] Creating utility_meter sensor: Dining table device energy yearly (entity_id=sensor.dining_table_device_energy_yearly)

I would suggest to create a separate wildcard group first without any nesting. To keep it as simple as possible and see if that one works correctly.
powercalc:
  sensors:
     - create_group: Plafond spots test
        unique_id: powercalc_group_plafond_spots_test
        include:
           wildcard: light.hue_ambiance_spot_*

a that sound like an idea.
Can I create a second group of the same entities I already have in the nest? (afraid I otherwise will overwrite that or other issues might arise?

No, that's no problem. You can put same entity in multiple groups. It won't have impact on your existing groups.

yeah, I noticed. I'll wait 15 minutes to see if the unknowns get a value, and the unavailable will too because of that.
if that happens, Ill again restart, but then with power cut to those lights

Ah I see your edit now. So that concludes that everything is working fine when it's a seperate group, but when you use the wildcard inside some nested groups it won't work.
I will see if I can reproduce this behaviour and fix it.
Will come back in a few days.

yeah, I noticed. I'll wait 15 minutes to see if the unknowns get a value, and the unavailable will too because of that.
if that happens, Ill again restart, but then with power cut to those lights

That's fixed now in latest version, that the initial state directly gets 0, instead of after 15 minutes.
But that's unrelated to group being setup succesfull or not.

made some changes for the include functionality. See #1959
Currently the include option was only working when you have either setup powercalc entities for the light via the GUI, or defined the entity_id in YAML.
I have made some changes to also directly setup powercalc entities for supported devices directly from the include option.

1.9.11 only made some changes to the startup state of group power sensors, I did nothing regarding to energy sensors (yet).
Your initial bug report regarding that state being unknown was specifically about the power sensor in W, so I did have a look into that spefically.

made some changes for the include functionality. See #1959
Currently the include option was only working when you have either setup powercalc entities for the light via the GUI, or defined the entity_id in YAML. I have made some changes to also directly setup powercalc entities for supported devices directly from the include option.
Are you able to test this by installing master branch? Thanks!

dl as we speak, Ill report back, thanks for looking into this!

@Mariusthvdb Didn't get a notification about your edit, so didn't know you were already able to test.
Thanks for testing and great to hear things are solved for you.

lets close this now? great present for the holidays!


Update docs

[ ] Explain the new possibilities enabled by class-resolver
[ ] Incorporate architecture picture with explanation
[ ] link to readthedocs in readme

It would be great to make an example where Kiez is applied to the embeddings coming from PyKEEN. This tutorial shows how to get embeddings out after training. The following example shows it for TransE:
from pykeen.pipeline import pipeline

results = pipeline(
    model='TransE',
    dataset='Nations',
    epochs=1,  # change this to ~25 for real usage on Nations
)

entity_embeddings   = results.model.entity_representations[0]()    # is torch.Size([14, 50])
relation_embeddings = results.model.relation_representations[0]()  # is torch.Size([55, 50])

These are torch tensors, which can be converted to numpy ndarrays of the same dimensions with
entity_embeddings   = results.model.entity_representations[0]().detach().numpy()
relation_embeddings = results.model.relation_representations[0]().detach().numpy()

The main purpose of Kiez (for now) is to use it for entity resolution, i.e. I have entity embeddings of two datasources (source & target) and want to find the nearest neighbors of source entities in the target space.
However using it to find nearest neighbors within a single source is technically already possible, e.g.
from kiez import Kiez
source = ... # get embeddings from somewhere
k_inst = Kiez()
k_inst.fit(source, source)
k_inst.kneighbors()

I want to adapt the API to make this use-case more intuitively available. In the course of that I would add your mentioned example in the doc and implement the convenience function for pykeen.

Oh I see. There are a few pykeen datasets that are constructed such that they contain 2 knowledge graphs with support edges linking the same entity in each (like a english and german version of the same graph, with different completeness) but none of them are directly accessible to give a really good example at the moment

I will close this and we can continue to talk about use cases in #11

@dobraczka great! Looking forward to it.


[CSM-531] Revert "[CSM-491] Add timeout reports in blistener"

New description (by @gromakovsky)
After addition of logWarningWaitLinear to wallet's BListener LRC hangs in wallet. That's because applyBlocks is called from bracket (safe-exceptions version) which applies uninterruptibleMask to given action. And logWarningWaitLinear uses uninterruptibleCancel to kill a thread which just hangs (due to uninterruptibleMask which is preserved when thread is forked).
We will fix it properly soon, for now the hotfix is to revert CSM-491. Note that this fix won't be necessary if #1772 is merged.
Old description (by @Martoon-00)
After addition of these logs we started to observe the issue, when after
new epoch start BListener application hang, mentioned logging emitted infinite
warnings about timeout.
Further investigation showed strange behaviour of logWarningWaitInf
function. It forks a thread via withAsync which periodically drops warnings
and this thread gets killed when primary action completes.
However, in our case, looks like uninterruptibleCancel hangs trying to kill
that forked thread, which in turn occurs to be on delay at that moment.
(And all these happens only upon a new epoch for some reason)
I hope someone explains me how could it be. Till that moment or some progress in investigation, I remove this logging-on-timeout.

I found out that BListener logic occur to proceed under MaskUninterruptible state when happen upon new epoch, we will fix it in another way

See https://github.com/input-output-hk/cardano-sl/pull/1836#issuecomment-340301486

Given #1772 is merged, is it safe to close this? @gromakovsky @Martoon-00

Yes, should be safe to close.


Mouse scroll support

Holding modifier key scrolling up/down with mouse triggers macro (or another key) only once till modidier key pressed.
Usecase: Working in graphical environment (CADs, diagram software) with one hand on mouse there is more comfortable to use mod+mwheeldown to copy (give it to me association) and mod+mwheelup to paste (take it back association). Selecting area with mouse, then holding mod key scrolling down (copy), then moves cursor to new position and scroll up (paste). This approach also useful while editing wysiwyg-type document editors.

I would like to boost this

Would love this. Currently trying to set up button4+scroll to switch windows in paperwm, which is harder than it ought to be


release: v1.0.0a11

Needed to unblock https://github.com/inveniosoftware/invenio-files-rest/pull/133

LGTM


Backport "Bypass alpn cache when alpn not negotiated" to 3.x

Addresses issue https://github.com/adobe/fetch/issues/431 - requesting this backport to 3.x
Backports:

ALPN cache bypass for connections not using alpn to 3.x branch
The correction (thank you!) from @stefan-guggisberg

Related Issues
https://github.com/adobe/fetch/issues/410

Thanks for providing the PR!


copier: 8.1.0 -> 9.1.1

copier fails to build on current Nixpkgs because of a dependency conflict with pydantic (the packaged version of pydantic is too high for the constraints specified by copier).
Updating copier to its current release version (9.1.1) resolves this issue.
Description of changes

Updated copier to v. 9.1.1
Added an entry to the 24.05 release notes pointing out the documented breaking change in 9.0.0

Things done

Built on platform(s)

[x] x86_64-linux
[x] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[x] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review run on aarch64-linux 1

1 package blacklisted:

nixos-install-tools

2 packages built:

copier
copier.dist

I prepared this PR remotely and currently have no x64 box running on which I could test this build, too. Will do so in the next couple of days.

Builds fine for me on x64

For me, too:
Result of nixpkgs-review run on x86_64-linux 1

2 packages built:

copier
copier.dist

Done in #322852.


Release candidate 1

Codecov Report

Merging #61 (7e2c716) into main (3833ddf) will increase coverage by 3.76%.
The diff coverage is 84.28%.

:exclamation: Current head 7e2c716 differs from pull request most recent head dda2c4d. Consider uploading reports for the commit dda2c4d to get more accurate results

@@            Coverage Diff             @@
##             main      #61      +/-   ##
==========================================
+ Coverage   82.62%   86.39%   +3.76%
==========================================
  Files          36       42       +6
  Lines        1347     1698     +351
==========================================
+ Hits         1113     1467     +354
+ Misses        234      231       -3

Flag
Coverage Δ

unittests
86.39% <84.28%> (+3.76%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

repid/connections/redis/message_broker.py
69.81% <69.81%> (ø)

repid/connections/rabbitmq/consumer.py
73.41% <73.41%> (ø)

repid/connections/rabbitmq/message_broker.py
71.59% <77.77%> (-5.23%)
:arrow_down:

repid/connections/dummy/consumer.py
78.94% <78.94%> (ø)

repid/_runner.py
95.58% <81.25%> (+0.42%)
:arrow_up:

repid/connections/dummy/bucket_broker.py
86.66% <81.81%> (-0.18%)
:arrow_down:

repid/connections/redis/consumer.py
83.65% <83.65%> (ø)

repid/connections/redis/bucket_broker.py
84.61% <84.61%> (ø)

repid/middlewares/middleware.py
94.73% <85.71%> (-2.64%)
:arrow_down:

repid/connections/redis/utils.py
86.66% <86.66%> (ø)

... and 41 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Bors: Automatically delete merged branches in the main repo

Already set up and used successfully in ppb/pursuedpybear.

bors r+


Update globalwheat_dataset.py

Thanks! I'll close this and we will add this in with the larger unlabeled PR, since that will arrive soon.


standalone/io/process_sync_test timing out frequently on Win debug-ia32

It takes >2min on Windows debug mode. Could we reduce the size/number of iterations in this test to avoid these timeouts and reduce buildbot cycle time, @sgjesse ?

https://codereview.chromium.org/1402123004/ reduces running time of this test on my machine from 12s to 9s.

The running time of this test, when it passes, is quite stable, at around 16 seconds.  I think the failures are due to the test hanging, not due to it being slow.  So speeding up the test will not necessarily solve the problem.

I think you're right - these timeouts are likely due to a crash, and the test hanging afterwards. There are more examples of this - e.g. tests expected to crash are frequently timing out on Windows.

@zanderso Just stumbled over this: You recently fixed Windows-related hanging issues. Could these tests be related?

If you just hit a hang on bleeding edge, then it is probably unrelated. The bug I fixed could have caused hangs in a wide variety of situations, so if you don't have the fix, then it could be related.

Maybe we should remove them from the status file to test if they still time out.

Checked the current test results page and this test appears to be green on all configurations. Closing this issue.


Is there any way to configure utoipa behind reverse proxy?

OpenAPI supports servers but reverse proxy could be configured independently for a particular service sitting behind that proxy. utoipa has support for servers but it looks like the trait Modify is static. Is there some way to use X-Forwarded headers like for example it's done in https://github.com/domaindrivendev/Swashbuckle.AspNetCore/pull/1801 ?

Hi, I've also run into the same issue.
My setup: Axum server running behind Reverse Proxy, with URL rewrite: "/api" -> "/"
I could modify the OpenAPI documentation with this trick:
struct PathPrefixAddon;

impl Modify for PathPrefixAddon {
    fn modify(&self, openapi: &mut utoipa::openapi::OpenApi) {
        match env::var("PATH_PREFIX") {
            Some(prefix) => openapi.servers = Some(vec![Server::new(prefix)]),
            None => ()
        }
    }
}

async fn main() {
    #[derive(OpenApi)]
    #[openapi(modifiers(&PathPrefixAddon))]
    struct ApiDoc;
}

However, I could not trick utoipa to host the actual openapi.json resource without the PathPrefix, while configuring the url with the PathPrefix for the swagger-ui.
I looked at the source code, it seems this use-case was not considered at all when setting up swagger-ui.

tricks utoipa to use "/{prefix}" to access the server, which essentially adds a prefix to every endpoint.

Hi @plang-arista, thanks for your workaround. I can confirm it also works for the Swagger UI part on Actix-web, the next problem I am facing is the "Try it out" part still using the wrong endpoint.
for example, my server is http://www.abcd.com/, set Apache reverse proxy to http://www.abcd.com/rusttest/ for Rust Actix-web
The swagger UI URL becomes http://www.abcd.com/rusttest/swagger/
The actual API endpoint is http://www.abcd.com/rusttest/api/xxxxABC
The "Try it out" in utoipa swagger UI send request to http://www.abcd.com/api/xxxxABC, the prefix "/rusttest" is missing.
Could you please help to see what's wrong in my code? thanks heaps
use actix_cors::Cors;
use actix_web::{App, HttpServer, web::Data};
use std::{error::Error, env};
use utoipa::{OpenApi, Modify, openapi::server::Server};
use utoipa_swagger_ui::{SwaggerUi, Config};

struct PathPrefixAddon;

impl Modify for PathPrefixAddon {
    fn modify(&self, openapi: &mut utoipa::openapi::OpenApi) {
        match env::var("PATH_PREFIX") {
            Ok(prefix) => openapi.servers = Some(vec![Server::new(prefix)]),
            Err(_) => ()
        }
    }
}

async fn main() -> Result<(), Box<dyn Error>> {
    dotenv().ok();

    //Auto-generate API documentation using utoipa and utoipa-swagger-ui
    #[derive(OpenApi)]
    #[openapi(
        modifiers(&PathPrefixAddon),
        paths(
            get_pages,
        ),
        components(schemas(
            Page,
        ))
    )]
    struct ApiDoc;

    let openapi = ApiDoc::openapi();

    HttpServer::new(move || {
        App::new()
            .wrap(Cors::permissive()) // Add this line to enable CORS for all origins
            .service(
                //Because Apache reverse proxy configuration, we have to use PathPrefixAddon
                //It tricks utoipa to use "/{prefix}" to access the server, which essentially adds a prefix to every endpoint.
                SwaggerUi::new("/swagger/{_:.*}").config(Config::new(["openapi.json"])).url("/swagger/openapi.json", openapi.clone()),
            )
            .configure(init_routes)   // Route being handled by routes.rs
    })
    .bind((CONFIG_PARAMETERS.webserver_host.to_string(), CONFIG_PARAMETERS.webserver_port,))?
    .run()
    .await?;
    Ok(())
}

tricks utoipa to use "/{prefix}" to access the server, which essentially adds a prefix to every endpoint.

Hi @plang-arista, thanks for your workaround. I can confirm it also works for the Swagger UI part when loading openapi.json on Actix-web, the next problem I am facing is the "Try it out" part still using the wrong endpoint.

Hi, this is weird, this should work. Can you add logging that you have set your PATH_PREFIX env var to /rusttest/ as well?
In the swagger page you should see a new Drop-Down select, labelled "Servers" with value single value /rusttest/. This is how swagger-ui would know that your /api/xxxxABC api calls would need to be made against /rusttest/ server on the same host, essentially becoming http://www.abcd.com/rusttest/api/xxxxABC.
If that variable is also properly set up, I'm not sure how to go on.

tricks utoipa to use "/{prefix}" to access the server, which essentially adds a prefix to every endpoint.

Hi @plang-arista, thanks for your workaround. I can confirm it also works for the Swagger UI part when loading openapi.json on Actix-web, the next problem I am facing is the "Try it out" part still using the wrong endpoint.

Hi, this is weird, this should work. Can you add logging that you have set your PATH_PREFIX env var to /rusttest/ as well? You can also just hard-code that value for your test, to be on the safe side.
In the swagger page you should see a new Drop-Down select, labelled "Servers" with single value /rusttest/. This is how swagger-ui would know that your /api/xxxxABC api calls would need to be made against /rusttest/ server on the same host, essentially becoming http://www.abcd.com/rusttest/api/xxxxABC.
If that variable is also properly set up, I'm not sure how to go on.

Thanks for the reply. For the current swagger page, it didn't show Drop-Down select, labelled "Servers" with single value /rusttest/. So might be env var problem.
As the server is an internal server behind the firewall, so I could not test it over the weekend at home. Will look into this next Monday.

tricks utoipa to use "/{prefix}" to access the server, which essentially adds a prefix to every endpoint.

Hi @plang-arista, thanks for your workaround. I can confirm it also works for the Swagger UI part when loading openapi.json on Actix-web, the next problem I am facing is the "Try it out" part still using the wrong endpoint.

Hi, this is weird, this should work. Can you add logging that you have set your PATH_PREFIX env var to /rusttest/ as well? You can also just hard-code that value for your test, to be on the safe side.
In the swagger page you should see a new Drop-Down select, labelled "Servers" with single value /rusttest/. This is how swagger-ui would know that your /api/xxxxABC api calls would need to be made against /rusttest/ server on the same host, essentially becoming http://www.abcd.com/rusttest/api/xxxxABC.
If that variable is also properly set up, I'm not sure how to go on.

Hi @plang-arista, after I correctly set PATH_PREFIX env var to /rusttest/, Swagger UI is working properly now. thanks for your help.

The workaround given will not fix the problem with trailing slash redirect from https://github.com/juhaku/utoipa/blob/4d798bc3e79a0991460c14b657b03bd17d08d7df/utoipa-swagger-ui/src/axum.rs#L52
thus if the API is available under prefix /service as /api it will work as /service/api/ but /service/api will give a bad redirect to /api

The workaround given will not fix the problem with trailing slash redirect from
https://github.com/juhaku/utoipa/blob/4d798bc3e79a0991460c14b657b03bd17d08d7df/utoipa-swagger-ui/src/axum.rs#L52
thus if the API is available under prefix /service as /api it will work as /service/api/ but /service/api will give a bad redirect to /api

Yeah, I've covered that in:

Axum / Utoipa might respond 303 for requests to /docs to redirect it to Location /docs/. In your reverse-proxy you also need to setup redirect translation. E.g.: in Nginx I had to add proxy_redirect  /  /api/; to prepend the proper prefix.

This is what I have in my nginx reverse proxy to handle that:
server {
  location /api {
    rewrite /api/(.*) /$1 break;
    proxy_pass        http://backend-proxied:5000;
    proxy_redirect    / /api/;
    proxy_buffering   off;
    proxy_set_header  Host $host;
  }
}


Custom Dropdown usage?

We have been using the Dropdown component from reactstrap 4 to create dropdowns for a number custom input components, for example:

Usage is basically:
    <Dropdown isOpen={!disabled && open} toggle={this.toggle}>
      <InputGroup className={className}>...</InputGroup>
      <DropdownMenu>...</DropdownMenu>
    </Dropdown>

and it worked really well.
However in upgrading to reactstrap 5 - This approach breaks without a DropdownToggle button:
Error: Target missing. Popper must be given a target from the Popper Manager, or as a prop.
We can't use DropdownToggle due the logic we have in the Inputs, so what would be the recommended upgrade path for this?
(Note we don't always use InputGroups, so can't just put a DropdownToggle button in the InputGroupAddon.)

There are a few way to achieve what you want.
You can use DropdownToggle with the tag prop to change the underlying component it renders to be whatever you want (such as an InputGroup or  Input)
You can use a Popover (this is what I do for my date inputs). You can even use the hideArrow prop to make it appear without the arrow tip thing.
You can use the PopperContent helper with the target helper which Popover and Tooltip uses directly, or you can use react-popper directly.
I'm on mobile, so I cannot provide examples/demos. I know the Popover way works and is relatively easy (you have to tie the calendar data to the input, but I imagine that you have to do that with the previous way it worked for you).

Ah, thanks @TheSharpieOne , I missed you can specify tag prop.  In this case I can just use a <div> around the InputGroup
<Dropdown ...>
  <DropdownToggle tag="div">
    <InputGroup>
      <Input />
      <InputGroupAddon addonType="append">...</InputGroupAddon>
    </InputGroup>
  </DropdownToggle>
  <DropdownMenu className="w-100">
    ...
  </DropdownMenu>
</Dropdown>

Sample here for others:
https://stackblitz.com/edit/reactstrap-v5-beta-starter-eilhwl?file=index.js

How to use up/down arrow key to select in this custom dropdown ?


How can I keep my rich-text control from changing word case when I press F3?

WHAT I HAVE:
Visual Basic 2019, .NET 4+, WinForms
MY PROBLEM;
I've created a custom control (configured for .NET 4.0) which incorporates a  RichTextBox constituent control, which in turned is hooked up to a ContextMenuStrip with options for Find (Ctrl+F), Find Next (F3), and Find Previous (Shift+F3). The control highlights search text in the rich-text box when an occurrence is found. The problem is, when I use the context-menu shortcut keys F3 and Shift+F3, the text box changes the case on the selected text--even though I've used the shortcut keys to override any standard keystroke behavior for the rich-text box. I want to be able to use those keys to highlight next and previous occurrences of given search text without that text being changed upon highlighting. Is there way to disable the case-changing behavior? (It used to be a problem only when the host program using my custom control was configured for .NET 4.7.1 or higher, but now it happens even for lower configurations!)
Please give me an answer ASAP and in VB.NET--and keep the solution as simple as possible.

Problem was with the spell-checker tool, not the RichTextBox! Silly me.


ensure that luxon based tests are not os locale dependent

These packages had tests which will render OS locale dependent text if this setup code is not in place.
No changeset since it only affects tests

interesting. should we add it as a default to new plugin tests in the create plugin template? :)

Hm! Not sure, only if you're actually using specifically luxon specifically in this way etc 🤔 but yeah it IS a gotcha that may keep returning


Investigate complete stop of data-receive via USB if transferring data in the first two seconds of boot

@davids5 This is not something to debug, but to validate on NuttX-next: If you connect to the board just after it booted and transmit data immediately, it renders the USB layer unable to receive any data. The TX direction is working fine though.
Priority is gated by nuttx_next efforts, so not critical right now.

Fixed on master / stable / beta.


Sparse Fieldsets collide when a resource has a "self join" relationship

According the spec (source), sparse fieldsets must use fields[TYPE] parameter. This would prevent a resource that has a self join association from including a subset of an included resources' attributes without omitting attributes from the document's primary data. If I am understanding the sparse fieldsets section of the spec correctly, you can not request discrete fields for the followers/followees relationship (see examples below).
A naive solution could be allowing sparse fieldsets to be fetched via fields[TYPE] or fields[RELATIONSHIP].
I understand this is an edge case. The solution may just be "design a better API". The examples below are theoretical. This is not an issue I am dealing with in a production application, but I figured this was worth bringing up.
Without Sparse Fieldsets:
GET /users/1?include=followers,followees HTTP/1.1
Accept: application/vnd.api+json

{
  "data": {
    "id": "1",
    "type": "users",
    "attributes": { "first-name": "User", "last-name": "A" },
    "relationships": {
      "followees": {
        "data": [{ "id": "2", "type": "users" }]
      },
      "followers": {
        "data": [{ "id": "3", "type": "users" }]
      }
    }
  },
  "included": [
    {
      "id": "2",
      "type": "users",
      "attributes": { "first-name": "User", "last-name": "B" }
    },
    {
      "id": "3",
      "type": "users",
      "attributes": { "first-name": "User", "last-name": "C" }
    }
  ]
}

With Sparse Fieldsets:
GET /users/1?fields%5Busers%5D=last-name&include=followers,followees HTTP/1.1
Accept: application/vnd.api+json

{
  "data": {
    "id": "1",
    "type": "users",
    "attributes": { "last-name": "A" },
    "relationships": {
      "followees": {
        "data": [{ "id": "2", "type": "users" }]
      },
      "followers": {
        "data": [{ "id": "3", "type": "users" }]
      }
    }
  },
  "included": [
    {
      "id": "2",
      "type": "users",
      "attributes": { "last-name": "B" }
    },
    {
      "id": "3",
      "type": "users",
      "attributes": { "last-name": "C" }
    }
  ]
}

A single resource can be both primary data and included, although in can only appear once in the document. If we were to limit a resource's fields by relationship then we would need to allow a union of fields specified across multiple relationships, which we deemed too complex a requirement for the server. This is the rationale behind specifying sparse fieldsets by type instead of relationship.
If related resources are unique enough to warrant unique fields, you could consider giving them a unique type. If your clients have the intelligence to understand that users and followers all represent different aspects of the same underlying thing (a person), they could choose a more unified approach to modeling.


Schedule a meeting with Dr. Franks in March to present our progress

Riley is unavailable Feb. 10-19

updated this to March


lib and pkgs.lib loose sync when trying to overlay lib

Describe the bug
Attempt to add overlay lib have effect only on pkgs module argument attrset and not on lib.
Steps To Reproduce
Steps to reproduce the behavior:

Prepare dummy NixOS configuration

# flake.nix
{
  outputs = { nixpkgs, ... }@inputs: with inputs; {
    nixosConfigurations.ony = nixpkgs.lib.nixosSystem rec {
      system = "x86_64-linux";
      modules = [ ./configuration.nix ];
    };
    defaultPackage.x86_64-linux = self.nixosConfigurations.ony.config.system.build.toplevel;
  };
}

{ lib, pkgs, ... }:
{
  nixpkgs.overlays = [
    (final: prev: {
      lib = prev.lib // {
        licenses = prev.lib.licenses // {
          sspl = prev.lib.licenses.sspl // {
            shortName = "sspl";  # try to fix upper case SSPL not matching attribute
          };
        };
      };
    })
  ];
  nixpkgs.config = {
    # blocklistedLicenses = with lib.licenses; [ sspl ]; # => ‘SSPL’ is not an attribute of lib.licenses
    blocklistedLicenses = with pkgs.lib.licenses; [ sspl ]; # => ‘sspl’ is not an attribute of lib.licenses
  };
}

Run nix flake check

Expected behavior

There should be no difference between using lib or pkgs (via pkgs.lib) arguments of module.
Overriding lib in overlay should have effect on check-meta.nix evaluations too. That message indicates that licenses referenced in blocklistedLicenses and in attrset lib.licenses were different even if sspl attribute was found. See comment for issue with SSPL.

Screenshots
When using lib.licenses (no effect from overlay)
zsh%  nix flake check
error: ‘SSPL’ is not an attribute of lib.licenses
(use '--show-trace' to show detailed location information)

When using pkgs.lib.licenses (license do not match one referenced in check-meta.nix)
zsh%  nix flake check
error: ‘sspl’ is not an attribute of lib.licenses
(use '--show-trace' to show detailed location information)

(notice lower case version of shortName)
Additional context
When there is requirement for blocklistedLicenses to reference only licenses from lib.licenses, we need a way extend that attrset to allow having packages and licenses outside of main nixpkgs repo.
Notify maintainers

Metadata
nix run nixpkgs\#nix-info -- -m

system: "x86_64-linux"
host os: Linux 5.10.81, NixOS, 21.11 (Porcupine)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.4
channels(root): "nixos-21.11.334684.1158f346391"
channels(nikolay): "nixpkgs-unstable-21.11pre310022.14b0f20fa1f"
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

It is not possible to override lib from within a module, as this would create an infinite recursion:
To evaluate config.system.build.toplevel (ie the "whole" config), we must evaluate all module configs, many of which are defined through lib.mkIf and therefore lib, which would have to come from, again, the configs.
To override the lib module argument, you'll have to pass the modified lib to the nixosSystem function.
cc @ncfavier If we do make nixosSystem use the final lib, we can recommend let lib = nixpkgs.lib.extend foo; in lib.nixosSystem. Working with only one lib like that is perhaps easier.

 rec {

This is redundant. It's generally a good idea not to use it, especially in places where you can access the same values through a "fixed point" like the flake self argument or an overlay's final argument.

cc @ncfavier If we do make nixosSystem use the final lib, we can recommend let lib = nixpkgs.lib.extend foo; in lib.nixosSystem. Working with only one lib like that is perhaps easier.

Yes, that's exactly the use case I had in mind

@ncfavier , thank you for lib.extend that saves some boilerplate.
But using that modified lib.nixosSystem and passing into it modified lib do have effect on module lib, but do not effect pkgs.lib like nixpkgs.overlays do. And it still fails on finding sspl in lib.licenses.

I was thinking about that earlier. It seems like a complete solution would look like introducing a concept of an "ambient" lib that's passed around the files in pkgs instead of importing ../lib. Or maybe just add a simple { inherit lib; } overlay in specific places.

I wonder if simple solution would be to not depend on lib.licenses in check-meta.nix.
@roberth , I would expect recursion only in case if overlay overrides something used to lookup and combine overlays. Otherwise it should be able to traverse to original "bootstrap" attrset through all //.

Opened https://github.com/NixOS/nixpkgs/pull/157056


add tests

for JOSS and Travis-CI, we need some test functions

added enough tests for now in #92. all main functions performing array manipulations are tested now. I/O operations or file reading during run time cannot be tested with pytest-functions. same counts for plotting and all top-level functions of the package.


Docker image hardcoded to sqlite, does not honour ENV vars

From my understanding, the docker build process copies in the sqlite file: orchestrator-sample-sqlite.conf.json
Code is here:
https://github.com/openark/orchestrator/blob/master/docker/Dockerfile#L29
I think that goes against the entrypoint environment options that are discussed here:
https://github.com/openark/orchestrator/blob/master/docker/entrypoint.sh#L2
Since the file /etc/orchestrator.conf.json will always exist in the container.
I was able to work around the issue by building a local container using the following Dockerfile:
FROM openarkcode/orchestrator

RUN rm -rf /etc/orchestrator.conf.json

Would it be possible to have the entrypoint.sh file overwrite the values in the configuration file using something like envsubst ?

Hi, thank you! Could you please explain again what the expected behavior is, and what the misbehavior is?

Got it, thank you!

Same issue as #1023