feat(mediatr): add mediatr pagination utils

created pagination request / response classes
created mediator api controller
added sample usage
added tests

Codecov Report

Merging #4 (281a0c9) into main (8887cf4) will decrease coverage by 1.62%.
The diff coverage is 87.85%.

@@            Coverage Diff             @@
##             main       #4      +/-   ##
==========================================
- Coverage   91.66%   90.03%   -1.63%
==========================================
  Files          12       20       +8
  Lines         144      251     +107
  Branches       13       24      +11
==========================================
+ Hits          132      226      +94
- Misses          7       15       +8
- Partials        5       10       +5

Impacted Files
Coverage Δ

...atR.Pagination.AspNetCore/MediatorApiController.cs
73.68% <73.68%> (ø)

...FluentUtils.MediatR.Pagination/PaginatedRequest.cs
90.00% <90.00%> (ø)

...tR.Samples/Core/Queries/GetWeatherForecastQuery.cs
92.59% <92.59%> (ø)

...R.Samples/Controllers/WeatherForecastController.cs
100.00% <100.00%> (ø)

samples/FluentUtils.MediatR.Samples/Program.cs
100.00% <100.00%> (ø)

...les/FluentUtils.MediatR.Samples/WeatherForecast.cs
100.00% <100.00%> (ø)

src/FluentUtils.MediatR.Pagination/Links.cs
100.00% <100.00%> (ø)

...luentUtils.MediatR.Pagination/PaginatedResponse.cs
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


ActivityTrait doesn't boot

Laravel 5.4.28, stream-laravel 2.2.8, stream-php 2.5.0.
A while ago my activity feeds stopped working and they kind of just got forgotten about. I'm coming back to it, and I've found:

My eloquent models are being created just fine, it's just not getting pushed to getstream.
Placed a log statement into ActivityTrait@bootActivityTrait to see if the trait is even being triggered.
The repository library I'm using, doesn't call Model::create(), it calls Model::newInstance(). I've tried directly calling MyModel::create() to see if the trait gets triggered, but it doesn't.

I've tried making a new app within get-stream, no success. If I manually push the activity within my model boot function, it works:
public static function boot()
{
    static::created(function ($model) {
        $manager = \App::make('feed_manager');
        $manager->activityCreated($model);
    });
}

This is an okay workaround for me personally, as I only have a handful of activity actions, but I really wouldn't want to do this if my models were any more complicated than a bridge between a user and an object. This also works when using Model::newInstance(), so I can only assume the issue lies within the trait not booting properly.

Hi!
I suspect you updated your installation of this package from 2.2.3 or earlier to 2.2.4 or later.
In 2.2.4 a breaking change was introduced, where you now have to do this in every activity model:
public static function boot()
{
    static::bootActivityTrait();
}

or simpler:
use ActivityTrait { bootActivityTrait as boot; }

// As opposed to previously:
use ActivityTrait;

See: https://github.com/GetStream/stream-laravel/compare/2.2.3...2.2.4#diff-e18ab2380fd8201ce8c6beaa50e03178L130
I'm truly sorry about this, under my watch this will never happen again ;-)


ajaxContentUrl does not load content

Hello, I created content.php and in it I use full URL like http://www.domain.com in the ajaxContentUrl
But the tooltip with ajax content html page with image does not show if I access the page with the
<?php readfile("http://www.domain.com/content.php"); ?>
I get no error in the network tab in dev inspector, but the image file is never loaded and shown. If i load same page direct in browser everything works fine. Only the readfile method does not work.
I need a way to load the tipso from my remote site.

My understanding is that readfile requires an absolute path and not a URL, but I may be wrong. Could you provide more code so I can try it out?

The Ajax does not work because Same-origin policy
https://en.wikipedia.org/wiki/Same-origin_policy
See here:
http://www.dreamincode.net/forums/topic/406094-readfile-echo-file-get-contents-does-not-load-content-properly/
I could not resolve this in this thread as nobody wanted to actually help.
So I resolved this in another friendly forum here by using javasript:
https://forums.phpfreaks.com/topic/304862-third-tier-quotes/#entry1550800
This a pain because as you can see the quotes are non standard to say the least. Who can know how to use this nonsense third tier quotes anyway? You should include examples likes this so other may use your great tooltip.

I am sorry you went through that. But, escaping quotes is a standard process, and this is clearly related to your specific usage of tipso, and not a tipso-related functionality issue.


Local development workflow improvements

This set of commits allows a user to work out of the host system's maestro folder while using Vagrant to build and rebuild those changes.
The dev workflow is now:

clone maestro on the host system
vagrant up
vagrant ssh -c "build_maestro"
make local changes on the host system.  this can include new commits or just leave things uncommitted.
repeat from step 3 until finished

@costanic Does https://github.com/armPelionEdge/maestro/pull/73/#issuecomment-589256144 also apply w.r.t. this PR?

@costanic Does #73 also apply w.r.t. this PR?

No, #73 attempted to make it easier to develop inside the Vagrant VM, whereas this PR is mainly around allowing the developer to work on the host and have those changes be moved into vagrant automatically.
The goal is that we want Vagrant to be treated like a build tool chain and not a dev environment.


reporter: Add authors to the evaluated model

This is part of resolving #5957.
Signed-off-by: Sebastian Schuberth<EMAIL_ADDRESS>

I think, the EvaluatedModelReporterFunTest fun test needs to be adapted.

I think, the EvaluatedModelReporterFunTest fun test needs to be adapted.

Indeed, thanks for reminding me. Done.


net: test fails - TestLookupDotsWithLocalSource

go version: 1.6.2 - also present when testing master branch
linux/amd64
trying to run all.bash eventually fails on testing packages.
--- FAIL: TestLookupDotsWithLocalSource (0.02s) 	lookup_test.go:457: netgo: got localhost.; want localhost FAIL FAIL	net	1.958s
I saw issue #14050 but my /etc/hosts does not contain any trailing dots.

apparently this does not present itself in version 1.5.4
I checked out go1.5.4 and afterward all tests pass and compilation continues

What does your /etc/hosts file look like?  What does dig <IP_ADDRESS>.in-addr.arpa print?
(For what it's worth, this test failure is not all that serious.   Can you show us the following:

/etc/resolv.conf, /etc/nsswitch.conf
configuration on the running local recursive/cache server or similar if possible. I'm sure there is someone who speaks DNS and returns "nobody.invalid." on your circumstances

resolv.conf

Generated by NetworkManager

search telus
nameserver <IP_ADDRESS>
nameserver <IP_ADDRESS>
nameserver 2001:568:ff09:10a::56
NOTE: the libc resolver may not support more than 3 nameservers.
The nameservers listed below may not be recognized.
nameserver 2001:568:ff09:10a::114
nsswitch.conf

Begin /etc/nsswitch.conf

passwd: files
group: files
shadow: files
publickey: files
hosts: files mdns_minimal [NOTFOUND=return] dns myhostname
networks: files
protocols: files
services: files
ethers: files
rpc: files
netgroup: files
End /etc/nsswitch.conf
i'm not sure what you mean by the second point. what else could be setting this?

@robjloranger,

i'm not sure what you mean by the second point. what else could be setting this?

Ah, you are using telus, that's enough for investigation, thanks. Probably we should skip TestLookupDotsWithLocalSource in short-mode on non-buildbots/trybots for avoiding complicated testing.

For the record, this might happen when the node under test uses a) some agent software that touches/modifies the local database file /etc/hosts, and b) some full resolver that provides local-data/local-zone-like RR caches.
From go1.6, the check on /etc/hosts runs every 5 secs, not every 5 mins. My dumb hypothesis is that;

some agent software makes /etc/hosts empty for some reason
built-in stub resolver reads the empty /etc/hosts file and has no record
built-in stub resolver throws a query to some full resolver
the full resolver replies its local-data/local-zone RR, which contains "127.in-addr.arpa. IN SOA localhost. nobody.invalid."
TestLookupDotsWithLocalSource barks at "localhost."

this stopped happening with go 1.6.2, and the test continues to pass in go 1.7rc2 as well


Cluster model can not sync the data with error Fail to list multipart upload - hawkey999/s3-migration-test/...

Create System Manager Parameter Store

Name: s3_migration_credentials
Type: SecureString
Content:

{
  "aws_access_key_id": "your_aws_access_key_id",
  "aws_secret_access_key": "your_aws_secret_access_key",
  "region": "cn-northwest-1"
}

Configure AWS CDK  app.py setting about source / desination S3 bucket and prefix

[{
    "src_bucket": "ray-cross-region-sync-oregon",
    "src_prefix": "broad-references",
    "des_bucket": "ray-cross-region-sync-zhy",
    "des_prefix": "broad-references"
    }]

deploy CDK

cd amazon-s3-resumable-upload/cluster/cdk-cluster
source ~/python3/env/bin/activate
pip3 install -r requirements.txt
export AWS_DEFAULT_REGION=us-west-2
npm install -g aws-cdk
cdk synth
cdk deploy s3-migration-cluster* --profile ${AWS_GLOBAL_PROFILE} --outputs-file "stack-outputs.json"

Testing

cdk deploy the resource for you, locate the S3 bucket NewS3BucketMigrateObjects in global region for upload new objects
upload the files

aws s3 cp amazon-corretto-8-x64-linux-jdk.rpm s3://s3-migration-cluster-reso-s3migratebucket676429fa-lt3gfz9nbfn7/crr-ningxia/

check the des_bucket

aws s3 ls s3://ray-cross-region-sync-zhy --region cn-northwest-1 --profile china

check the cloudwatch dashboard s3migrate* created by CDK
check the s3-migration-cluster-ec2-applog* CloudWatch log group

2020-09-17 03:24:21,724 INFO - Start multipart: s3-migration-cluster-reso-s3migratebucket676429fa-lt3gfz9nbfn7/crr-ningxia/amazon-corretto-8-x64-linux-jdk.rpm, Size: 117537571, versionId: null

2020-09-17 03:24:21,724 INFO - Getting unfinished upload id list - hawkey999/s3-migration-test/crr-ningxia/amazon-corretto-8-x64-linux-jdk.rpm..

2020-09-17 03:24:22,547 ERROR - Fail to list multipart upload - hawkey999/s3-migration-test/crr-ningxia/amazon-corretto-8-x64-linux-jdk.rpm - An error occurred (NoSuchBucket) when calling the ListMultipartUploads operation: The specified bucket does not exist | 2020-09-17 03:24:22,547 ERROR - Fail to list multipart upload - hawkey999/s3-migration-test/crr-ningxia/amazon-corretto-8-x64-linux-jdk.rpm - An error occurred (NoSuchBucket) when calling the ListMultipartUploads operation: The specified bucket does not exist
-- | --

2020-09-17 03:24:22,547 INFO - Create multipart upload - hawkey999/s3-migration-test/crr-ningxia/amazon-corretto-8-x64-linux-jdk.rpm | 2020-09-17 03:24:22,547 INFO - Create multipart upload - hawkey999/s3-migration-test/crr-ningxia/amazon-corretto-8-x64-linux-jdk.rpm
-- | --

2020-09-17 03:24:22,748 ERROR - Fail to create new multipart upload - hawkey999/s3-migration-test/crr-ningxia/amazon-corretto-8-x64-linux-jdk.rpm - An error occurred (NoSuchBucket) when calling the CreateMultipartUpload operation: The specified bucket does not exist | 2020-09-17 03:24:22,748 ERROR - Fail to create new multipart upload - hawkey999/s3-migration-test/crr-ningxia/amazon-corretto-8-x64-linux-jdk.rpm - An error occurred (NoSuchBucket) when calling the CreateMultipartUpload operation: The specified bucket does not exist
-- | --

From the error message, it goes to find the bucket name "hawkey999" which is not available.
After CDK deply, the bucket information is stored in SSM parameter store, please go to check the bucket name information.


Allow SDFs to accept a start state.

This PR attempts to close one aspect of #335. To checkpoint the state of an SDF, we need to do these 3 things:

When a job starts, retrieve (either from Dask datasets/S3/disk) the last known SDF state from previous runs.
Pass this retrieved state into an SDF so that the new run of this streamz job can pick up from where it left off — basically, allow SDFs to accept an initial state.
Publish (either to Dask/S3/disk) the updated SDF at the end of every batch.

This PR attempts to complete step 2 above.
For this PR, I have added the capability for most critical SDF operations (reductions, groupby, rolling, window, windowed-groupby) to accept a start state. This allows streamz pipelines with an SDF to pick up from an initial state.
The implementation is as follows:

For reductions and groupby-aggs like sum, the result of the current batch itself is the start state for the next batch.
For operations like groupby.mean, rolling, windowing, streamz maintains a state OR a historical backlog of events for accurate computations. In such cases, one needs to emit the entire state maintained along with the result at the end of every batch. This state can then be the start state for the next batch in case the job crashes.

I had initially added the start parameter at the root level of the operation. For e.g., sdf.groupby([cols], start=None), but then this will not work for groupby aggregate use cases, which are pretty common in pipelines. So, to account for cases like #303, I moved to an implementation like sdf.groupby([cols]).sum(start=None).  Please refer to test cases.
I would highly appreciate an in-depth review and suggestions so that I can make this more efficient. Once the code review is complete, I can add documentation.
This PR also has some changes to the current documentation indentation, and a small fix for cudf compatibility with timedelta.

All tests are passing, except one: from_kafka, which is unrelated to the PR. This might be due to an upstream change. @martindurant, @CJ-Wright, @jsmaupin any ideas?

I'm trying to figure out why the Kafka test is failing.
I ran the command:
STREAMZ_LAUNCH_KAFKA=true python -m pytest -vs streamz/tests/test_kafka.py::test_from_kafka.
I see a segfault with this trace:
======================================== test session starts ========================================
platform darwin -- Python 3.7.1, pytest-5.4.3, py-1.7.0, pluggy-0.13.1 -- /Users/cchandak/anaconda3/bin/python3
cachedir: .pytest_cache
rootdir: /Users/cchandak/Desktop/streamz
plugins: doctestplus-0.2.0, arraydiff-0.3, remotedata-0.3.1, openfiles-0.3.1
collected 1 item

streamz/tests/test_kafka.py::test_from_kafka Finding streamz-kafka ...
Stopping eca205cbd215 ...
eca205cbd215
docker run -d -p 2181:2181 -p 9092:9092 --env ADVERTISED_HOST=<IP_ADDRESS> --env ADVERTISED_PORT=9092 --name streamz-kafka spotify/kafka
Fatal Python error: Segmentation fault

Current thread 0x000070000a2dd000 (most recent call first):
  File "/Users/cchandak/Desktop/streamz/streamz/sources.py", line 416 in do_poll
  File "/Users/cchandak/Desktop/streamz/streamz/sources.py", line 423 in poll_kafka
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/tornado/gen.py", line 1147 in run
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/tornado/gen.py", line 1233 in inner
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/tornado/stack_context.py", line 300 in null_wrapper
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/tornado/ioloop.py", line 758 in _run_callback
  File "/Users/cchandak/anaconda3/lib/python3.7/asyncio/events.py", line 88 in _run
  File "/Users/cchandak/anaconda3/lib/python3.7/asyncio/base_events.py", line 1764 in _run_once
  File "/Users/cchandak/anaconda3/lib/python3.7/asyncio/base_events.py", line 528 in run_forever
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/tornado/platform/asyncio.py", line 132 in start
  File "/Users/cchandak/anaconda3/lib/python3.7/threading.py", line 865 in run
  File "/Users/cchandak/anaconda3/lib/python3.7/threading.py", line 917 in _bootstrap_inner
  File "/Users/cchandak/anaconda3/lib/python3.7/threading.py", line 885 in _bootstrap

Thread 0x0000700009bce000 (most recent call first):
  File "/Users/cchandak/anaconda3/lib/python3.7/concurrent/futures/thread.py", line 78 in _worker
  File "/Users/cchandak/anaconda3/lib/python3.7/threading.py", line 865 in run
  File "/Users/cchandak/anaconda3/lib/python3.7/threading.py", line 917 in _bootstrap_inner
  File "/Users/cchandak/anaconda3/lib/python3.7/threading.py", line 885 in _bootstrap

Thread 0x000000011e0915c0 (most recent call first):
  File "/Users/cchandak/anaconda3/lib/python3.7/selectors.py", line 558 in select
  File "/Users/cchandak/anaconda3/lib/python3.7/asyncio/base_events.py", line 1728 in _run_once
  File "/Users/cchandak/anaconda3/lib/python3.7/asyncio/base_events.py", line 528 in run_forever
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/tornado/platform/asyncio.py", line 132 in start
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/tornado/ioloop.py", line 571 in run_sync
  File "/Users/cchandak/Desktop/streamz/streamz/utils_test.py", line 69 in test_func
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/_pytest/python.py", line 182 in pytest_pyfunc_call
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/pluggy/callers.py", line 187 in _multicall
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/pluggy/manager.py", line 87 in <lambda>
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/pluggy/manager.py", line 93 in _hookexec
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/pluggy/hooks.py", line 286 in __call__
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/_pytest/python.py", line 1477 in runtest
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/_pytest/runner.py", line 135 in pytest_runtest_call
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/pluggy/callers.py", line 187 in _multicall
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/pluggy/manager.py", line 87 in <lambda>
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/pluggy/manager.py", line 93 in _hookexec
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/pluggy/hooks.py", line 286 in __call__
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/_pytest/runner.py", line 217 in <lambda>
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/_pytest/runner.py", line 244 in from_call
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/_pytest/runner.py", line 217 in call_runtest_hook
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/_pytest/runner.py", line 186 in call_and_report
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/_pytest/runner.py", line 100 in runtestprotocol
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/_pytest/runner.py", line 85 in pytest_runtest_protocol
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/pluggy/callers.py", line 187 in _multicall
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/pluggy/manager.py", line 87 in <lambda>
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/pluggy/manager.py", line 93 in _hookexec
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/pluggy/hooks.py", line 286 in __call__
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/_pytest/main.py", line 272 in pytest_runtestloop
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/pluggy/callers.py", line 187 in _multicall
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/pluggy/manager.py", line 87 in <lambda>
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/pluggy/manager.py", line 93 in _hookexec
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/pluggy/hooks.py", line 286 in __call__
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/_pytest/main.py", line 247 in _main
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/_pytest/main.py", line 191 in wrap_session
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/_pytest/main.py", line 240 in pytest_cmdline_main
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/pluggy/callers.py", line 187 in _multicall
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/pluggy/manager.py", line 87 in <lambda>
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/pluggy/manager.py", line 93 in _hookexec
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/pluggy/hooks.py", line 286 in __call__
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/_pytest/config/__init__.py", line 125 in main
  File "/Users/cchandak/anaconda3/lib/python3.7/site-packages/pytest/__main__.py", line 7 in <module>
  File "/Users/cchandak/anaconda3/lib/python3.7/runpy.py", line 85 in _run_code
  File "/Users/cchandak/anaconda3/lib/python3.7/runpy.py", line 193 in _run_module_as_main
[2]    4353 segmentation fault  STREAMZ_LAUNCH_KAFKA=true python3 -m pytest -vs

Not sure what is happening. Can someone please help?

Okay, all tests are now passing. Turns out the from_kafka test failure was a one-off. :(
I can add more tests if needed and some documentation after the code is reviewed. Please do have a look.

Random tests like test_tcp are failing now, can one of the maintainers please retrigger the travis CI build?

Agree about the flaky tests, but it is rather difficult - typically the CI test machines run slower and with unexpected latency compared to testing locally. We don't want to add sleep statements all over the place, although tolerances on waiting would be fine.

@CJ-Wright , there is quite a lot of good looking work here, do you think you'll have the chance to review?
@chinmaychandak , I didn't immediately spot doc or example or how the sdl_checkpoint parameter should be used. Are there other accumulation operations aside from SDFs that might benefit from setting not just an initial value, but also an initial state?

Agree about the flaky tests, but it is rather difficult - typically the CI test machines run slower and with unexpected latency compared to testing locally. We don't want to add sleep statements all over the place, although tolerances on waiting would be fine.

Should we just re-trigger the build in these cases then?

there is quite a lot of good looking work here, do you think you'll have the chance to review?

I would really appreciate that, @CJ-Wright. Thanks @martindurant!

I didn't immediately spot doc or example or how the sdf_checkpoint parameter should be used.

Apologies for not adding doc strings until now. I was hoping to get an initial review before doing so. To answer your question, sdf_checkpoint is a boolean which defaults to False. To ensure checkpointing in operations on SDFs that need to return current state along with the result, one needs to set this parameter to True. This will let the user know that they should expect the SDF operation's output to be (checkpoint_state, result). How one handles this checkpoint state downstream is a different problem altogether. Jarod and I will work on tying this to a Kafka checkpoint as part of the metadata. Note that this is in addition to the start parameter which is just the initial state.

Are there other accumulation operations aside from SDFs that might benefit from setting not just an initial value, but also an initial state?

I can't think of any other operations at this time. The initial state can be a complex Python object (dataframe, deque of dataframes, etc., as can be seen in the tests). This would primarily be obtained from an existing stream with SDFs when it crashes, so that when the stream restarts, it can be fed this last state. Basically, this is beneficial to streams that maintain state across batches — and SDFs are the only way to do that. If the stream has only within-each-batch operations, the Kafka checkpoint should take care of the crash already, and using an initial state along with this might be overkill. I cannot think of other accumulation operations without SDFs that can benefit from this initial state; even if they can, retrieving/getting an initial state in the first place would be inconvenient.

This sounds like a with_state parameter then, i.e., that the output is both the internal state and the calculated value. That doesn't sound like it should be specific to SDFs, though I can see why it's particularly useful for this case.

This sounds like a with_state parameter then

I agree. I was thinking of a better name than sdf_checkpoint myself. I'll change the name to  with_state then.

Should we just re-trigger the build in these cases then?

It's certainly the workable, if annoying, option. Some projects have used a @flaky marker, meaning that either the test will be re-tried some times, or that a certain number of tests marked like this are allowed to fail on a given run.

All good from me, aside from the rename and docstring updates.

@martindurant, @CJ-Wright I have changed the variable name to with_state, added/updated plenty of doc strings, and also added a @flaky marker to the pertinent tests.
All tests are passing. However, the coverage seems to have gone down, and I can't seem to understand why! The only changes made since the last commit (b5df231, that actually showed to have increased the code coverage) are the ones I mentioned above, and they shouldn't have impacted coverage.

The following diffs don't appear to be covered:
core.py:L879 return self._emit((self.state, x), metadata=metadata)
dataframe/core.py:L552 return Window(self.root.reset_index(), n=self.n, value=self.value,

@CJ-Wright , did you want another look at this?

The following diffs don't appear to be covered:
core.py:L879 return self._emit((self.state, x), metadata=metadata)
dataframe/core.py:L552 return Window(self.root.reset_index(), n=self.n, value=self.value,

@martindurant, I fixed these. But codecov still seems to complain. :(

OK, I'm going to ignore that. I'll give @CJ-Wright a chance to say something yet (24hr), and then merge.
For future reference, we could improve the coverage slightly by removing old py2 branches, which won't work now anyway.

@martindurant Is this good to merge now?

OK, I'm going to ignore that.

Any idea why it is complaining? This can become a problem for future PRs as well?


[diagram] fix exported SVG

Looks like some CSSs are missing

Added a missing export comment to statements.css


feat: Implement Create Module Command Layer

Description
Changes proposed in this pull request:

Implement the command layer of create module command
Unit tests for it

Related issue(s)
Resolves #26

The TODOs have been left at places where things can be taken one abstraction level above. Since this task just expects to get the command layer implemented, the refactoring should be part of the actual implementation of the command. Leaving those TODOs for easier navigation.

Blocked until the linting PR is merged.

This issue is linked to the main TODO, which is removed as part of review.


feat(instr-tedious): added support for v18

closes https://github.com/open-telemetry/opentelemetry-js-contrib/issues/2266
Why?

Tedious v18 moved @types/tedious to their repository.
Tedious v18 uses Typescript v5 and es2022

Problems:

We need to use different typescript versions in the project. This creates conflicts and errors. I think because by default TS checks all TS Definitions in the root folder, which are not compatible against the TS v5.
We are using an outdated module ts-mocha. Won't build with newer typescript targets.
NPM Workspaces do not support nohoisting. Using nohoist makes it possible to move all @types/* and typescript dependencies into the packages and would avoid errors we are getting from typescript regarding root dependencies.
Eslint packages no longer compatibale. We had to update eslint packages for typescript too (for the package)
I had to use ts-ignore flag to import different type notations into the test. Not optimal, but easiest way. And using dynamic imports based on the tedious version did not work for me. And doing it like mongo is soo much code duplications. But I am also not an expert in TS. I am open to full working solutions.

Possible follow up tickets:

There is a root typescript dependency and every sub package has its own TS version. That doesn't make sense to me. Either one root ts version which every packages use and a package can override it on its own or the other way around.
Use tilde for dev dependencies to speed up installation (consistency change).
Replace ts-mocha with ts-node everywhere.
Update mocha to latest version everywhere.
Find a better way to avoid using ts-ignore.

RFR
There were lots of challenges in this PR. I have tried my best to give context for the changes.

@open-telemetry/javascript-approvers Requesting a review

@open-telemetry/javascript-maintainers I would love to merge this. Requesting further feedback.

Hi. I took a look and tried to work through the same issues. I put up a branch for comparison:
https://github.com/open-telemetry/opentelemetry-js-contrib/compare/main...trentm:opentelemetry-js-contrib:tm-tedious-18-play
Repeating its commit message (because GitHub likes to hide those):
    tedious@18 adds its own .d.ts files. Compiling with them requires
    TypeScript v5, and either target:'es2022' for 'AggregateError'
    or using skipLibCheck:true in tsconfig.json.

    This change limits the update to TypeScript v5 to just while
    testing tedious@18 via test-all-versions' support for
    'peerDependencies'.

    THis also drops ts-mocha in favour of 'mocha --require ts-node/register'
    as was done on opentelemetry-js.git in https://github.com/open-telemetry/opentelemetry-js/pull/4840

It uses some of the work that you've done, and tries to limit some things (like not updating the typescript version in package.json).
I agree that TypeScript v5 is required to compile the test files with tedious@18. Given that we only need to do that for test-all-versions (TAV) testing, I used peerDependencies in ".tav.yml" for that (https://github.com/watson/test-all-versions?tab=readme-ov-file#peer-dependencies).
I limited some of the needed type changes in test/api.ts.
I also split out some of the versions in .tav.yml for minimum support Node.js versions. This wasn't completely necesasry because test/instrumentation.test.ts knows how to skip out if the current version of Node and tedious isn't supported.
I'm good with the switch to mocha --require ts-node/register. This was done a few months back in the opentelemetry-js.git repo. We should follow-up with a separate change to do the same for all the other packages in this repo.

on skipLibCheck

I found that skipLibCheck: true in "tsconfig.json" was necessary, otherwise the test code won't compile with tedious@18.

It would fail with:
../../../node_modules/tedious/lib/connection.d.ts:761:29 - error TS2304: Cannot find name 'AggregateError'.

761     loginError: undefined | AggregateError | ConnectionError;
                                ~~~~~~~~~~~~~~

The alternative would be to update the tsconfig "target" to "es2022". That might have an impact on the shipping code for instr-tedious, so I thought that should be avoided for now, at least.
options
Please let me know which you would prefer:

I could make a PR out of my branch for discussion and see about pushing that through, or
You could take the few changes I have from yours. If you do take my changes, please take my (smaller) diff to the top-level package-lock.json file as well.

@trentm Thanks so much for taking the time to review this.

I could make a PR out of my branch for discussion and see about pushing that through, or

This option sounds like the easiest. I'd suggest that we just open your PR and close mine :)

Closing in favor of https://github.com/open-telemetry/opentelemetry-js-contrib/pull/2381


blocking and muting

Rough model:
UserBlock
  belongs_to user
  belongs_to blocked_user

UserMute
  belongs_to user
  belongs_to muted_user

Todo:
Blocking

[x] Blocking removes any following relationships between you and them
[x] Prevents any future following relationships between you and them
[x] Prevents you from messaging each other
[x] Prevents you from commenting on each others observations
[x] Prevents you from adding identifications to each others observations
[x] Prevents you from adding annotations to each others observations
[x] Prevents you from adding quality metrics to each others observations
[x] Prevents you from adding observation field values to each others observations
[x] Prevents you from adding each others observations to projects
[x] Prevents you from seeing each others observations in search results
[x] Prevent both parties from being notified about anything the other does (e.g. comments on observations they both commented on prior to the block)
[x] You only get to block three people

Muting

[x] dont' generate notifications generated by activity of people you've muted
[x] automatically mark all messages from muted users as read
[x] don't generate emails for messages from muted users

Closed in https://github.com/inaturalist/inaturalist/pull/1488


unable to connect

RuntimeException in AbstractClient.php line 112:
Unable to connect: tls://gateway.sandbox.push.apple.com:2195: 2 (stream_socket_client(): unable to connect to tls://gateway.sandbox.push.apple.com:2195 (Connection refused))
Iam using Godaddy shared hosting ?

Looks like a problem with your infrastructure or with hosting environment.

Duplicate of https://github.com/Ph3nol/NotificationPusher/issues/133

@zerefati please check https://github.com/Ph3nol/NotificationPusher/issues/102 and https://github.com/Ph3nol/NotificationPusher/issues/133


Add lightmap baking

Related to https://github.com/blackears/cyclopsLevelBuilder/issues/15.
Please add support for baking lightmaps or add a "Convert to mesh" button.

This issue is a duplicate of https://github.com/blackears/cyclopsLevelBuilder/issues/15.
Note that exporting to the Godot mesh format has been implemented as of 1.0.2, so you can do that then bake lightmaps afterwards. This is a destructive operation, so you'll want to keep a copy of your source CyclopsBlocks around.


Bug report: Remove this title with a descriptive title.

Description
When I try to add multiple tasks in a single day in the schedule that uses SpeziScheduler, running the app causes it to crash, with the error message "Fatal error: Duplicate keys of type 'Event' were found in a Dictionary.
This usually means either that the type violates Hashable's requirements, or
that members of such a dictionary were mutated after insertion. The template app's PICSScheduler file (our project's version of it) initially has only the single task with static var SocialSupportTask: SpeziScheduler.Task, but I modified that to include 3 tasks instead of just 1, so it now includes:
static var PHQ4Task: SpeziScheduler.Task, static var EQ5D5LTask: SpeziScheduler.Task, and static var MiniNutritionalTask: SpeziScheduler.Task
And, the final convenience init is to incorporate:
convenience init() {
self.init(tasks: [Self.PHQ4Task, Self.EQ5D5LTask, Self.MiniNutritionalTask])}
These changes seem to have been enough to cause the error.
Reproduction
The error is also inconsistent as it produces the error sometimes when you complete just the first task, and sometimes when you complete the first task without error but then doing the second task causes the error. There are also when all three tasks can be completed without errors, but that is a more rare occurrence
Expected behavior
Each of the tasks should be completed without errors, with each task's updated completion text and icon showing up. Multiple tasks as defined in the PICSScheduler should be allowed to show up.
Additional context
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct and Contributing Guidelines

Thanks for reporting this issue.
As discussed in class today, this line is probably the problem, as the state might change within the lifetime of an event:
https://github.com/StanfordSpezi/SpeziScheduler/blob/adf793cb47dc199f8ae88f5c719f4d3ba06a4c4e/Sources/SpeziScheduler/Model/Event.swift#L233
While we don't really use the Hashable conformance within SpeziScheduler or the Application, SwiftUI does some magic when properties of a view conform to Hashable (e.g., to identify views and check if any contents of them changed). That's my current understanding of the problem and why the App crashes in the end. I started the App within the Debugger and set a breakpoint in the Hashable implementation and the hash method was always called from within the SwiftUI framework.
To resolve the issue I would propose to remove the line and replace it having the scheduledAt time. So an Event is uniquely identified by its Task Id and the Date it is scheduled at:
// hash(into:) implementation ...
hasher.combine(id)
hasher.combine(scheduledAt)

Do you want to tackle fixing this problem?
As part of this change, it would be great to add a small unit test inside SchedulerTests to verify that two instances of Event produce the same hash (scheduled vs. completed). You may look into the Swift Hasher to create hashes by your own 👍


Reproduction of the research paper

Hi, I would like to thank you for sharing these routines. Do you happen to share the replication code for your research paper?
When looking at the DEMO.m file, I am confused about how to obtain a p-value for unimodality. Is that enough to say that checking whether the set S is empty is sufficient for the test to say the data is from a multimodal distribution? Meaning that the procedure does not produce p-values. Apologies if I misunderstood something and  I appreciate your help in advance

Hi, thanks for your comment.
UU-test doesn't return a p-value for unimodality. It first decides unimodality/multimodality for a data distribution and in the case of unimodality, the set S  gives you the uniform mixture model (UMM). You have correctly understood that if the data distribution is multimodal, the set S is empty. However, if you need a p-value for unimodality, Hartigans' dip-test is a choice for you.  I hope i have answered your question clearly.

Hi, I would like to thank you for sharing these routines. Do you happen to share the replication code for your research paper?
When looking at the DEMO.m file, I am confused about how to obtain a p-value for unimodality. Is that enough to say that checking whether the set S is empty is sufficient for the test to say the data is from a multimodal distribution? Meaning that the procedure does not produce p-values. Apologies if I misunderstood something and I appreciate your help in advance

Hi, thanks for your comment.
UU-test doesn't return a p-value for unimodality. It first decides unimodality/multimodality for a data distribution and in the case of unimodality, the set S gives you the uniform mixture model (UMM). You have correctly understood that if the data distribution is multimodal, the set S is empty. However, if you need a p-value for unimodality, Hartigans' dip-test is a choice for you. I hope i have answered your question clearly.


WIP: HA dqlite

Could you provide some benchmarks of using dqlite and etcd? Thanks!

What do you think about this ? https://github.com/rancher/kine an etcdshim, to avoid patching the apiserver.

What do you think about this ? https://github.com/rancher/kine

We practically use this code patched to be embedded into the apiserver.

This work has moved to https://github.com/ubuntu/microk8s/pull/1208


:book: Add example to build an image from scratch for ubuntu fips

What this PR does / why we need it:
It adds a full e2e example to build a custom ubuntu fips-enabled image (license subscription is needed)

just re-tested it manually, works. merging it and we can fix/cleanup on later iterations


.NETStandard support?

Hi all,
I recently decided to switch PCLs of a project I'm starting on to target .NETStandard v1.1, as I wanted to get on the future bandwagon. As you can guess, it failed due to dependencies (although the RX libraries that are used as dependencies have updated .NETStandard versions).  Are there any plans for the future to move add in .NETStandard support? I can easily revert back to my previous PCL profiles to move forward, it's nothing that's stopping me, just wondered.
Thanks!
For reference:
Package reactiveui-core 6.5.2 is not compatible with netstandard1.1 (.NETStandard,Version=v1.1). Package reactiveui-core 6.5.2 supports:

monoandroid (MonoAndroid,Version=v0.0)
monomac (MonoMac,Version=v0.0)
monotouch (MonoTouch,Version=v0.0)
net45 (.NETFramework,Version=v4.5)
portable-net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile259)
portable-win81+wpa81 (.NETPortable,Version=v0.0,Profile=Profile32)
win8 (Windows,Version=v8.0)
wp8 (WindowsPhone,Version=v8.0)
xamarinios10 (Xamarin.iOS,Version=v1.0)
xamarinmac10 (Xamarin.Mac,Version=v1.0)
Package Splat 1.4.0 is not compatible with netstandard1.1 (.NETStandard,Version=v1.1). Package Splat 1.4.0 supports:
monoandroid (MonoAndroid,Version=v0.0)
monomac (MonoMac,Version=v0.0)
monotouch (MonoTouch,Version=v0.0)
net45 (.NETFramework,Version=v4.5)
netcore45 (.NETCore,Version=v4.5)
portable-net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile259)
portable-win81+wpa81 (.NETPortable,Version=v0.0,Profile=Profile32)
wp8 (WindowsPhone,Version=v8.0)
Package Rx-Interfaces 2.2.5 is not compatible with netstandard1.1 (.NETStandard,Version=v1.1). Package Rx-Interfaces 2.2.5 supports:
net40 (.NETFramework,Version=v4.0)
net45 (.NETFramework,Version=v4.5)
portable-net40+sl5+win8+wp8 (.NETPortable,Version=v0.0,Profile=Profile136)
portable-net45+win8+wp8 (.NETPortable,Version=v0.0,Profile=Profile78)
portable-net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile259)
portable-win81+wpa81 (.NETPortable,Version=v0.0,Profile=Profile32)
sl5 (Silverlight,Version=v5.0)
win8 (Windows,Version=v8.0)
wp71 (WindowsPhone,Version=v7.1)
wp8 (WindowsPhone,Version=v8.0)
Package Rx-Core 2.2.5 is not compatible with netstandard1.1 (.NETStandard,Version=v1.1). Package Rx-Core 2.2.5 supports:
net40 (.NETFramework,Version=v4.0)
net45 (.NETFramework,Version=v4.5)
portable-net40+sl5+win8+wp8 (.NETPortable,Version=v0.0,Profile=Profile136)
portable-net45+win8+wp8 (.NETPortable,Version=v0.0,Profile=Profile78)
portable-net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile259)
portable-win81+wpa81 (.NETPortable,Version=v0.0,Profile=Profile32)
sl5 (Silverlight,Version=v5.0)
win8 (Windows,Version=v8.0)
wp71 (WindowsPhone,Version=v7.1)
wp8 (WindowsPhone,Version=v8.0)
Package Rx-Linq 2.2.5 is not compatible with netstandard1.1 (.NETStandard,Version=v1.1). Package Rx-Linq 2.2.5 supports:
net40 (.NETFramework,Version=v4.0)
net45 (.NETFramework,Version=v4.5)
portable-net40+sl5+win8+wp8 (.NETPortable,Version=v0.0,Profile=Profile136)
portable-net45+win8+wp8 (.NETPortable,Version=v0.0,Profile=Profile78)
portable-net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile259)
portable-win81+wpa81 (.NETPortable,Version=v0.0,Profile=Profile32)
sl5 (Silverlight,Version=v5.0)
win8 (Windows,Version=v8.0)
wp71 (WindowsPhone,Version=v7.1)
wp8 (WindowsPhone,Version=v8.0)
Package Rx-PlatformServices 2.2.5 is not compatible with netstandard1.1 (.NETStandard,Version=v1.1). Package Rx-PlatformServices 2.2.5 supports:
net40 (.NETFramework,Version=v4.0)
net45 (.NETFramework,Version=v4.5)
portable-net40+sl5+win8+wp8 (.NETPortable,Version=v0.0,Profile=Profile136)
portable-net45+win8+wp8 (.NETPortable,Version=v0.0,Profile=Profile78)
portable-net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile259)
portable-win81+wpa81 (.NETPortable,Version=v0.0,Profile=Profile32)
sl5 (Silverlight,Version=v5.0)
win8 (Windows,Version=v8.0)
wp71 (WindowsPhone,Version=v7.1)
wp8 (WindowsPhone,Version=v8.0)
One or more packages are incompatible with .NETStandard,Version=v1.1.

Oh , I just read #1132. I'm assuming this and #1134 will eventually result in achieving the request?

@snickler we've been working through getting all the dependencies for ReactiveUI supporting netstandard before we can talk about netstandard support in RxUI. You can see the original notes here: https://github.com/reactiveui/ReactiveUI/issues/1132.
Lots of these projects have preview packages available with netstandard support, but I'll defer to @ghuntley on whether netstandard support is still in scope for ReactiveUI 7 - as mentioned in https://github.com/reactiveui/ReactiveUI/pull/850

Thanks for the reply! I'll definitely keep following to see what is decided.

I'd be interesting as well in the latest story regarding NETStandard support for RxUI?

I have tried to install RxUI to some .NET Standard libs and it didn't support it yet :(

@snhickler, @oliverw, @shiftkey and @superjmn. I've put this on hold until v7 stabilises as migration to netstandard at this stage will create a rift of those who can migrate and those who cannot. I (as in personally) specifically do not want to be concurrently supporting v7 (rx2) and v8 (netstandard/rx3) at the same time.

I would like to see the following investiged/closed out before switching to netstandard only:

https://github.com/reactiveui/ReactiveUI/issues/1236
https://github.com/reactiveui/ReactiveUI/issues/1235
https://github.com/reactiveui/ReactiveUI/issues/1233
https://github.com/reactiveui/ReactiveUI/issues/1231
https://github.com/reactiveui/ReactiveUI/issues/1228
https://github.com/reactiveui/ReactiveUI/issues/1223
https://github.com/reactiveui/ReactiveUI/issues/1227
https://github.com/reactiveui/ReactiveUI/pull/1230
https://github.com/reactiveui/ReactiveUI/pull/1171

Check out the netstandard branch on GitHub if you would like to help with progressing v8; let's talk.

We would <3 to and intend to grow our team in 2017. Additionally there's some open-pull requests and GitHub

Thanks @ghuntley . I'll check out that branch and see if there's any way I can help. Is there any documentation on what specifically will break for those who would run into issues that would prevent the migration, or even a quick outline anywhere?
Either way, I'd love to help out after I get a good look at it.

Off the top of my head.

Xamarin Forms is still PCL.
There are users that have dependencies that have not upgraded to RX3 yet. If we goto RX3 too soon it creates a python2 vs Python 3 adoption situation. I'm ready to do the jump once all of the above issues are investigated and at least one other maintainer signs off that the timing is right. This should involve looking at other dependencies commonly used such as Akavache and Lager (at min) but also includes @kentcb's genesis libraries. PR the ecosystem up and then make the jump has been the strategy so far.
Tooling is still rough; that branch was done in 2015 and a bunch of hacks/approaches are used to make it work. Best explained on video chat. Would be keen to migrate to pure VS2017 and the new csproj format now at AppVeyor has a build template. The Xamarin Studio story of compatibility needs to be checked as forcing RxUI source debugging to be only possible with VS2017 if XS doesn't support it is a no-go. Thus there's a research task you could do immediately. File new in vs2017 and then try it in XS/VS Mac.

Come join us in Slack and make yourself known; would love some additional help.

Has there been discussion about the viability of "adding support for netstandard and keeping PCL support too" instead of "switching from PCL to netstandard"?
The nupkg would still contain what it does now.  But it would also contain netstandard builds.  There would be TFM-specific dependencies, so that each build would get the right version of RX.
This worked out well for SQLitePCL.raw, so I'm curious if it could work here too.
I wish the entire .NET world could all be on PCLs on a Friday and then all be switched over to netstandard on Monday, but it sure looks to me like the transition is going to be more gradual than that.  So realistically, there will be a period of time when both need to be supported.

That would actually be very nice to have both PCL and netstandard support. All I want is to be able to use either or, but eventually move all of my projects to fully embrace netstandard. If there's a way we can have both in the meantime via NuGet packages, then I wouldn't mind that. It's up to everyone else though.
From: Eric<EMAIL_ADDRESS>Sent: ?Wednesday?, ?January? ?25?, ?2017 ?10?:?10? ?AM
To<EMAIL_ADDRESS>Cc: Jeremy<EMAIL_ADDRESS><EMAIL_ADDRESS>Has there been discussion about the viability of "adding support for netstandard and keeping PCL support too" instead of "switching from PCL to netstandard"?
The nupkg would still contain what it does now. But it would also contain netstandard builds. There would be TFM-specific dependencies, so that each build would get the right version of RX.
This worked out well for SQLitePCL.raw, so I'm curious if it could work here too.
I wish the entire .NET world could all be on PCLs on a Friday and then all be switched over to netstandard on Monday, but it sure looks to me like the transition is going to be more gradual than that. So realistically, there will be a period of time when both need to be supported.

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/reactiveui/ReactiveUI/issues/1190#issuecomment-275132848, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AD1IpXyV3IN6tmlAJmo1indKMRhtqUOuks5rV2XUgaJpZM4Kn6Gq.

Why would you want both PCL and netstandard? netstandard versions will install into compatible legacy PCL profiles.

Wouldn't this help to resolve the upgrade issues, though? There has to be a way to hold on to both PCL and NetStandard versions without generating more issues. If Rx30 isn't supported on Xamarin, then shouldn't try to install... right? If the PCL still meets all the dependencies then shouldn't it be the one to install or isn't there a way to force it to look at PCL only for the platforms that don't have all dependencies? Sorry if this mash of text is confusing.

Rx 3 is supported on Xamarin, not sure where that came from. Xamarin fully supports netstandard upto 1.6.
Furthermore, the dependency resolutions rules are that netstandard > portable-, so if both are in the package, you'll get the netstandard version. There's really no benefit to keeping portable around anymore; the tooling finally all supports netstandard.

Oh, okay. That makes sense then. So, it would just be pointless to keep supporting both. Sorry about the confusion with my previous message, I misread one of the other issues and for some reason thought of Xamarin and Rx3. I'm all for just doing whatever we can to move towards .NETStandard then.

Ya; Rx30 is fine on Xamarin. The question is what happens when you create a brand new class library from 2017 for netstandard using the new project system and then try on Xamarin Studio and Visual Studio for Mac. Can those products handle the changes to csproj introduced in 2017?

"Why would you want both PCL and netstandard? netstandard versions will install into compatible legacy PCL profiles."
Interop between PCL and netstandard seems to be something that works much better in theory than in practice.
And as far as I can tell, when a package attempts a black-and-white transition to netstandard, we end up with a bunch of edge cases that no longer Just Work.
At the risk of going off topic, here's an example or two:
Last week-ish, the maintainer of sqlite-net-pcl tried switching to netstandard.    I didn't look at the situation that carefully, so I don't know the details, but he ended up adding PCL support back in.  I assume that was just the easiest way to get back to a Just Works condition.
Here's the example from my current situation:
I work on a project called Csf20 (a codename).  It is a mobile app which supports iOS, Android, and UWP, and it has ASP.NET server elements as well.  We have some developers on Visual Studio, and some on Xamarin Studio on Macs.  We use Xamarin Forms, but also have some native UI stuff for Xamarin.Android and Xamarin.iOS.  The solution has 19 projects in it.
Our dependencies include Rx, ReactiveUI, SignalR, Newtonsoft.Json, SQLitePCL.raw, Xamarin Forms, a couple of Xamarin plugins, PCLStorage, modernhttpclient, and that's about it.
We have a core library called Csf20.Common, which is very basic stuff used by both client and server code.  This one has no dependencies.
And we have another library called Csf20.Core, which is the bulk of the client code.  This one depends on most of the packages mentioned above.
Right now, we are on packages.config and PCL profile 151.
Roughly every 4 weeks, I make an attempt to switch Common and Core to project.json and/or netstandard.  I have hit some kind of an obstacle every single time.
I try different levels of netstandard.  I try different settings for the "imports" section under the framework in project.json.  It just never quite works out.
At one point, I realized that SignalR is one of the most problematic libraries.  Its PCL profile is troublesome, and it is basically no longer being maintained because a rewrite is happening.  So I took that one out of the mix by building it myself and referencing the assembly directly instead of using the nuget package.
That gets me further, but the transition still fails every time.
I usually assume that this has something to do with my skill level on issues related to PCLs and netstandard.  More specifically, I assume that you ( @onovotny ) might be able to get all this working.  The problem here is that even though my knowledge is well below yours, I'm pretty sure I am way above average.
And that's kinda my point:  Something that doesn't work unless you have the knowledge of @onovotny is a nearly perfect definition of something that works better in theory than practice.
Unfortunately, Csf20 is not open source, or even publicly announced.  So, asking for help is a bit tricky.  I could post the specific errors I am encountering.  But I would be asking someone (probably you) to assist in a context where you can't see the code.  That's always tedious.
If I were more confident that seeking help would be likely to result in some kind of benefit to the community, I would do so.
So anyway, I've done this exercise 4 or 5 times now.  Every four weeks I go through it again.  Maybe I will learn something new.  Maybe the tooling has improved.  Maybe the packages I use have been updated to resolve some kind of issue.
I have to believe that in practice, many developers who try to move to netstandard are experiencing problems.

Not sure, but it is the way forward. project.json is gone. I imagine VSfM will get the full support of the sdk csproj because it has to.
The bigger question is how it handles the Xamarin build targets, but there's a fairly easy answer there too -- can you open a Xamarin.Android/iOS project created on VS today in XS/VSfM? If yes, then things should continue to work.
Essentially, what I've done to get Xamarin working with the SDK-style builds is to set the LanguageTargets import to the same thing the iOS/Android projects did individually. Of course, if you use UWP, then that cannot be built on Mac.

@ericsink sorry to hear about your troubles, and I do agree that the tooling and experience today is hard. It really is with a mix of VS 2015/CLI/project.json, etc. Having used VS 2017 a lot lately, I do think it's getting better. Things like PackageRef to replace packages.config/project.json will go a long way towards unifying things. They will require people to be on either VS 2017 or the latest XS/VSfM though.
For your case, I'd be happy to help if I can (sign an NDA if you want)/access a private repo. Perhaps if we can get you migrated, you can blog about it to share your learnings?

I know Visual Studio for Mac will at least handle it. I haven't tried in Xamarin Studio at all. If it DOES work in Xamarin Studio, I'm assuming it will have to be one of the alpha builds.

I would say that XS is pretty much dead with VSfM. Why would you have both?

I know some people that won't migrate to solely using VS for Mac because it's still in preview and since the Xamarin lib are running alpha. Me on the other hand, I ONLY use VS for Mac when I'm on it.

That's fair, but that's a point-in-time thing. VSfM will come out of preview at some point :)

Oh, I agree. For the most part VS4Mac has been pretty darn stable. VS2017 is stable enough for me now also. That's why I wanted to hop right into using .NETStandard with RxUI.

@onovotny Thanks.
First, your offer of help is too generous to refuse, so I intend to take you up on it.  I'd like to start by processing in the open as much as possible.  Probably I should just begin another attempt, and then contact you with details when I get stuck.  We can resort to giving you access to our project if that becomes necessary or if it becomes the best way to be considerate of your time.  Hopefully this would result in a blog entry that is beneficial for others.  I'll get back to you.
Second:  I love that my sob story caused you to offer help, but that's not really why I posted it.
To review, you said: "Why would you want both PCL and netstandard? netstandard versions will install into compatible legacy PCL profiles."
And I replied with: "Interop between PCL and netstandard seems to be something that works much better in theory than in practice."
And I was tempted to stop there, but I wanted to give more substance.  The intent of sharing my story was to give one example of a situation that I think is probably common.
Why would I want both PCL and netstandard?  Because even though I love where things are going, it seems to me that netstandard mostly doesn't work yet, and PCLs still do.  That's what I see.  But your remark seemed to come from a different perspective.
(begin digression about lack of civility in the .NET community)
I see an enormous amount of frustration in the .NET community right now.  And a lot of that frustration gets expressed as negativity and complaining and whining at Microsoft people.    I could nominate a few Microsoft employees for some kind of sainthood.
I know you are not a Microsoft employee, but I bet you get some of this junk thrown at you as well.
The reality is that all this stuff right now is a mess, and a lot of the community frustration is very understandable.  And yet, I still think this is the best time ever to be a .NET developer.  A lot of .NET developers are upset and angry all the time.  I'm just not.  But if I were, I might have responded to your remark differently.  Frustration plus PerspectiveDifference often equals VentedEmotions.
(end digression)
Anyway, like I said, your remark seems to come from a different perspective than mine.  I wanted to communicate that difference and express my interest in understanding it better.

@ericsink totally fair and welcome.
Stuff has been moving really fast in this area over the past 18-24 months and it's really easy to see how people get frustrated. None of it was intentional on either side; I don't think any one on the Microsoft side would have predicted two years ago where we ended up today. A lot of it was trial-and-error and learning in the open. I think that process itself has been fascinating to observe as traditionally these things all happened behind closed doors.
As to theory-vs-reality, I am genuinely curious to see how/why/where things fall apart because I really do feel peoples pain there and I don't want people to be in pain when working with .NET. I'd like to understand and help get people past that so they can get on with whatever it was they were trying to do. If there are actual blockers, that's when I try to raise issues with the appropriate teams to help ensure things are fixed.
I think one of the major issues so far with .NET Standard libs being pulled into PCL's are the packages.config mess -- the fact that it puts tons of effectively "blank" entries in the file is annoying. That's where some band-aid's like using project.json with csproj in 2015 can help, but it's not a total fix.
Anyway, the more I can capture from real-world scenarios, pain, good/bad, etc, the more I can relay things to the teams and help make sure that scenarios aren't overlooked and that things do "just work." That's really my end goal, to have this stuff "just work" without having to get into the weeds. Not quite there yet :)

NETStandard 2 and once the tools for moving out of the project.json files is supposed to smooth a lot of this out isn't it?
This doesn't really apply directly to ReactiveUI and the mobile world  but the place with all this I've ran into the most issues is keeping my CI stuff working inside VSTS.  For one of our current ASP.NET websites if I add a single netstandard library to it the entire VSTS thing just breaks. I can build in VS (with a csproj hack I found) but I can't get VSTS tools to work.  I've seen similar complaints around github as it relates to msbuild so really just kind of hoping that once VS 2017 build tools are all more official that it will "just work".  Right now a lot of those PCL libraries we use both places so if I switch my mobile stuff over to netstandard there's some up stream fall out with the websites right now
It seems like waiting for VS 2017 official and maybe netstandard 2 will limit the  hacks and refactors?
I really hope XS isn't dead.  I'm a big fan of just light weight specific IDEs  these days. VS Code for all web and XS for all mobile.  Hey look at that while typing this my VS crashed for some reason :-(
Though to be fair I haven't tried VSfM so I should try it before I knock it...  I'm curious how heavy it is given that I'm just using a little mac mini for all things XS

@PureWeen You should really try VSfM. It's the same as XS and MORE. I haven't opened XS since (well I did and happened to accidentally install an XS update which blew up MSBuild for me lol). It's been very stable for me.

@snickler .......
http://pertobello.files.wordpress.com/2012/06/radiohead-fry-squinty-eyes.jpg
Well it's good to hear that... I'll give it a try :-) I've never quite been able to get the Xaml Previewer stuff to work right so be neat if that's a bit better over in VSfM world.
Also over in the slack channels there always seems to be lots of grumblings around problems with VS 2017 so it's just made me cautious overall with these things. The last standup I watched they talked about how VS 2017 would mess up x64 targeting and you had to go in and modify some targets to fix...  So yea.... Cautious I've been :-) If it's not broke don't fix it right? But I guess then you miss out on all the new fun :-p

@PureWeen the only issues I've had with VS2017 were fixed in the latest preview.  I still have some issues where VS2017 gives up caring about the iOS build server connection and doesn't want to build anything anymore, requiring a restart of the app. Other than that, things have been very usable for me.

https://twitter.com/Nick_Craver/status/829527599583989761

Am I right in saying that assembly redirects (as a stopgap) are not feasible? That is, swapping in the Rx 3 DLLs whenever the 2.2.5 DLLs are requested.
I did a quick look into this and promptly came to the conclusion that this won't work because the public key has changed, but never actually validated. This seems a major bummer because otherwise people could have forced the usage of whichever version they like.

also includes @kentcb's genesis libraries

Frankly, I'm ready to make the jump as soon as the surrounding ecosystem does. In fact, I've left all relevant genesis libraries in alpha purely because I intend jumping to Rx3 before releasing them proper.

I did a quick look into this and promptly came to the conclusion that this won't work because the public key has changed, but never actually validated.

Yeah, we had to change the public key because it was shared with the .NET Framework. See also https://github.com/Reactive-Extensions/Rx.NET/issues/205 which discusses versioning changes due to netstandard.

@ghuntley

Frankly, I'm ready to make the jump as soon as the surrounding ecosystem does. In fact, I've left all relevant genesis libraries in alpha purely because I intend jumping to Rx3 before releasing them proper.

That's totally reasonable. Would be declaring the 7.x series as legacy and moving more aggressively towards .netstandard and System.Reactive 3.x an option?

re: when
Now that VS2017 is stable. I'm wondering if Xamarin Studio supports the new VS2017 project format yet? If so; it's time to start aggressively moving towards netstandard.

VS for Mac Preview has supported it. I doubt they will add it to Xamarin Studio.

@snickler @ghuntley Considering that Xamarin Studio is most likely dead after the arrival of VSfM and VSfM supporting the VS2017 Project Format, I'd say it's time to move on.

I'm currently in the middle of converting some stuff over to the netstandard/vs2017 formats and just wanted to confirm that XS on Mac and Windows does not support the new VS2017 format
As the others mentioned I wouldn't hold your breath :-)

I believe VS for Mac which is now released supports the new VS2017 formats. It's not the official replacement for XS for Mac.
As mentioned here https://releases.xamarin.com/category/visual-studio-for-mac/ :
Visual Studio for Mac is now generally available as announced at the Microsoft Build conference. It is the recommended environment for Xamarin developers on Mac moving forward. To get started with Visual Studio on Mac, download and run the Visual Studio for Mac installer. It will install Visual Studio for Mac as a new app alongside Xamarin Studio.

netstandard merged a couple days ago into the develop branch and is now available from our MyGet feed.

Awesome, what are the details for the myget?

https://reactiveui.net/slack and https://docs.reactiveui.net/en/contributing/framework/pre-release-builds.html

Awesome - thanks!
// EDDY

What is the state of Preview 8.0? I'm trying to use it in a Xamarin Forms project but is getting this error when trying to compile:

Exception while loading assemblies: System.IO.FileNotFoundException: Could not load assembly 'ReactiveUI, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken='. Perhaps it doesn't exist in the Mono for Android profile?
File name: 'ReactiveUI.dll'

Also, the preview-release link above is broken.

@1iveowl please open a new issue with details about your setup and repro, so we can dig into it.

Closing out this issue. We have started pushing V8 prerelease builds to NuGet.org. Please open a GitHun issue for any friction you experience (if at all). Thankyou.


Sample give error "Unknown client error occurred"

I cloned the repo and built the sample.
It runs fine but entering credentials gives the error:
"Unknown client error occurred"
I set the following...
const _awsUserPoolId = 'us-west-2_J********';
const _awsClientId = '3ugt2ss9vtls0s2p*********';

The UserPoolId I got from General Settings > Pool Id and ClientId from General Settings > AppClients > App client id. Is that right?
I believe Cognito is set up correctly but not 100% sure as I am not that familiar with it.
Any suggestions to what I can do?
I also tried logging a user that does not exist and that error is:
Unable to verify secret hash for client 3ugt2ss9vtls0s2p*********

I maybe getting further I followed: https://stackoverflow.com/questions/37438879/unable-to-verify-secret-hash-for-client-in-amazon-cognito-userpools and created an app client without a client app secret.
Get the error Attributes did not conform to the schema: email: the attribute is required.
Will look at it later

I got it to work. Cognito was setup to record the email address. I just had to add it to the sample.
    final userAttributes = [
      new AttributeArg(name: 'name', value: name),
      new AttributeArg(name: 'email', value: email),
    ];


Failed to execute 'createPolicy' on 'TrustedTypePolicyFactory'

Bug Report
What is the current behavior?
React-virtualized triggers this error
Failed to execute 'createPolicy' on 'TrustedTypePolicyFactory': Policy with name react-virtualized-auto-sizer already exists.
What is the expected behavior?
react-virtualized checks for existing policy
Which versions of React and react-virtualized, and which browser / OS are affected by this issue? Did this work in previous versions of react-virtualized?
Worked on previous versions. Most likely latest release with trusted types triggered this.

Browser
any

OS
any

React
16.4.0

React DOM
16.4.0

react-virtualized
9.22.3

Code that triggers error is in react-virtualized/dist/es/vendor/detectElementResize.js
        element.__resizeListeners__ = [];
        (element.__resizeTriggers__ = doc.createElement('div')).className = 'resize-triggers';
        var resizeTriggersHtml = '

' + '

';
        if (window.trustedTypes) {
          var staticPolicy = trustedTypes.createPolicy('react-virtualized-auto-sizer', {
            createHTML: function createHTML() {
              return resizeTriggersHtml;
            }
          });
          element.__resizeTriggers__.innerHTML = staticPolicy.createHTML('');

MiuiBrowser 12.9.3
XiaoMi Mi 10T
Android 10

Reproducible by:

Enable the #enable-experimental-productivity-features Chrome flag on chrome://flags. (This is what causes window.trustedTypes to exist)
Mount two <AutoSizer/> components on the same page.

Noticed this was fixed by #1627, though code has not yet been published to a new version.

We're also impacted by this issue. @bvaughn it seems that the bug has already been fixed but not published. Is there something we could do to help?

Same here

Same here+1

Same here+1


Benchmark our powers-of-two impl against libcore's

Our memory allocator uses a custom-written math module for calculating powers of two. This code was written before I was aware that powers of two functions exist in the standard library.
I'd like to refactor the memory allocator just to use the standard library functions, to avoid duplicating this functionality. However, if our implementation, which is different from the stdlib's, offers better performance, I'd like to prefer using it, since the allocator is a performance-critical component.
I should write a handful of benchmarks to determine which is faster.

Okay, here are some bench results:
Discovery-One :: Development/sos-kernel/alloc ‹±paging-dev↑1●› » cargo bench --features bench                                                                                [10:18:23]
   Compiling alloc v0.1.0 (file:///Users/eliza/Development/sos-kernel/alloc)
warning: unused import: `core::ptr`, #[warn(unused_imports)] on by default
 --> src/buddy/test.rs:5:5
  |
5 | use core::ptr;
  |     ^^^^^^^^^

    Finished release [optimized] target(s) in 2.84 secs
     Running target/release/deps/alloc-169c74eae7b6b9ac

running 10 tests
test buddy::math::tests::test_is_pow2 ... ignored
test buddy::math::tests::test_log2 ... ignored
test buddy::math::tests::test_next_pow2 ... ignored
test buddy::test::test_alloc_and_dealloc ... ignored
test buddy::test::test_allocation_size_and_order ... ignored
test buddy::test::test_get_buddy ... ignored
test buddy::math::tests::our_is_pow2           ... bench:      56,283 ns/iter (+/- 12,009)
test buddy::math::tests::our_next_pow2         ... bench:     196,357 ns/iter (+/- 92,106)
test buddy::math::tests::std_is_power_of_two   ... bench:     111,829 ns/iter (+/- 19,359)
test buddy::math::tests::std_next_power_of_two ... bench:     110,760 ns/iter (+/- 21,945)

test result: ok. 0 passed; 0 failed; 6 ignored; 4 measured

Discovery-One :: Development/sos-kernel/alloc ‹±paging-dev↑1●› »

It looks like the standard lib's next_power_of_two() is faster than ours (unsurprising, IIRC it uses intrinsics), but our is_pow2() is faster than the standard library's is_power_of_two().


undesired expansion of HL7 fields with type ID

This is a follow-on to the latter half of #4793, which has been resolved for the state of WA in PR #4807. When we receive HL7 results from senders, ID fields such as OBR-25, OBX-2, and OBX-11 are expanded from standard ID values (e.g. "F", "CWE") to fully expanded values such as
F^Final results^HL70123
CWE^Coded With Exceptions^HL70125
F^Final results; Can only be changed with a corrected result^HL70085

Impact
Receivers are expecting value type ID in these fields and messages will error.
To Reproduce
Steps to reproduce the behavior:
Run sample message in #4793 through RS for a state other than WA and note the output will match the "current" messages documented in that issue, rather than the "desired"
Expected behavior
HL7 ID fields will retain their values as received, instead of expanding them.
Additional context
Believe these values are getting set by the code in setCodeComponent. Excluding fields of type ID within this function (or possibly the calling function, if appropriate) should resolve the issue.

Try to fix Smoke Test by reversing the value_type.type: CODE and pushed the commit.  However, it auto-merged to master bank.  I will have to create another branch to fix the OBX-2 value_type.type: ID.

The OBX-2 is fixed in ticket 4990 by changing value_type from type: CODE to ID.  Ticket 4990: https://app.zenhub.com/workspaces/onboarding--operations-6166edbd409257001e09f1b2/issues/cdcgov/prime-reportstream/4996


Add SDKOption for default Credentials Provider Chain

Describe the feature
Every service client accepts an AwsCredentialsProviderChain that determines how credentials are resolved. It should be possible to configure a default during SDK initialization.
Use Case
STSProfileCredentialsProvider does not exist in default chain [150]. In certain codebases, it would be much more code-efficient to configure the credentials provider chain during initialization as opposed to passing a chain to construction of every client object.
Proposed Solution

Add a new CredentialsProviderChainOptions struct to Aws.h's SDKOptions
During InitSDK, check for presence of this struct's closure. If it is present, call some SetDefaultCredentialsProviderChain with the result of the closure. If it is not present, call Set...Chain method with DefaultAWSCredentialsProviderChain (current default)
Update all occurrences of DefaultAWSCredentialsProviderChain across clients with GetDefaultCredentialsProviderChain (to resolve to configured value or pre-existing DefaultAWSCredentialsProviderChain).

Other Information
posting a PR right now
Acknowledgements

[X] I may be able to implement this feature request
[ ] This feature might incur a breaking change

Thanks for opening this feature request and creating a PR to add this option. We are reviewing your PR to see if we would like to accept this changes and change how the credentials work.

Thanks for taking the time and effort to make this PR. But we don't want to accept these changes, as we have plans to rework the Credentials Provider.


Update Breaking Changes with Misc fixes

Update Breaking Changes with Misc fixes
This should fix some issues with migration tool:

Some compat diagnostics were being cut off if they had a comment in it
Code snippets not wrapping and resulting in tables not wrapping
Stray " on the titles
Addition of some compatibility analysers that were not being shown

Note: Please double check all the pages to make sure they are generated correctly now.
Suggested Reviewers
@ronpet @mairaw

That makes sense. I noticed that the code snippets are not resolving correctly... I need to fix those first.


Use idiomatic Kotlin preconditions in io.spine.internal.gradle.git.Config

Now the Config class uses precondition checks from com.google.api.client.util.Preconditions. This is suspicions even if it were a Java class because it adds dependency on Google API client library rather than on Guava.
Being a Kotlin class it should use idiomatic preconditions. So, instead of
Preconditions.checkArgument(
          name.isNotBlank(),
          "Name cannot be an empty string."
)

it should be:
check(name.isNotBlank()} { "Name cannot be an empty string." }

Also, please think of a better name for the class. Config is way too generic. Assuming it is about the user name and his email, it can be UserInfo or UserAccount or something like this.

Please also adjust the class documentation. It's not Wrapper for different Git settings., at least in its current form.


python3Packages.ambee: init at 0.2.1

Motivation for this change
Python client for Ambee API
https://github.com/frenck/python-ambee

Related Home Assistant change: https://github.com/home-assistant/core/pull/51645
Target Home Assistant release: 2021.7.0

ToDo:

[ ] Update component-packages
[ ] Enable tests in Home Assistant

Things done

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes

[ ] (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.

Result of nixpkgs-review pr 126326 at 7c915252 run on aarch64-linux 1

2 packages built successfully:

python38Packages.ambee
python39Packages.ambee

As the author of the package that is being re-packaged here. I'm against it being repacked into here.
While licensing wise I cannot stop you, I do hope you can honor my request.

@frenck, what's the reason you are against it?
It's a Home Assistant dependency and as a dependency it has to be present otherwise users would not be able to use the ambee integration.

It's a Home Assistant dependency and as a dependency it has to be present otherwise users would not be able to use the ambee integration.

That is not true. It is a pure Python package, Home Assistant will just fetch it from PyPi.

It's a Home Assistant dependency and as a dependency it has to be present otherwise users would not be able to use the ambee integration.

That is not true. It is a pure Python package, Home Assistant will just fetch it from PyPi using pip.

That is sadly not true and probably a large part of the misunderstanding here.
Given that Nix packaging results in immutable output paths, home-assistant simply cannot go around and modify its site-packages by itself. Users need to opt-in to the components at build time and for that to be possible we need to package their individual dependencies into nixpkgs.

In that case you are shipping an broken Home Assistant version.
Which u definitely don't want to be part of.
Please remove it.

In that case you are shipping an broken Home Assistant version.
Which I definitely don't want to be part of.
Please remove this package, including all my other packages.
Thank for respecting my wishes as the author of the source.

Hi! I'd like to understand your concerns a little better:

Would you be happier if we were using the release tarballs/wheels from your published PyPi releases instead?
Have you had support load from users of NixOS as a result of this that we haven't seen? That would certainly be unfortunate and is not our intent, but it would be good to know about now.
Would you be happier if we forked your upstream source to provide our own, or provided a similar Python package with an identical API that we can use as a drop-in replacement?
Are you aware of similar efforts to package Home Assistant in a manner suitable for other Linux distros, such as Gentoo, that also include your packages (by necessity)? Do you have similar concerns there?

I'm also a little anxious that this thread has the potential to get heated quite quickly, so if you have the time and are willing to it might be worth setting up a quick Jitsi Meet to talk about this. Failing that, maybe we should pull this off into a separate issue thread so we can discuss there instead.

My wishes are above, please respect those. I have no intensional of spending time in this project.
Thanks.

My wishes are above, please respect those. It is a fairly simple request, nothing heated about it. I have no intention of spending time in this project.
Thanks.

Thanks for your time. In a similar spirit, I'll spend no further time responding to this request. I'll leave it up to other people to decide what to do.

Thanks, @lukegb nevertheless thanks for your extended questions. 👍

Would you be happier if we forked your upstream source to provide our own, or provided a similar Python package with an identical API that we can use as a drop-in replacement?

This was already answered. Please don't repack my source in this repository was my request. I don't see how your suggestion is changing that.

The difference would be that users would no longer associate the software with you and they would surely go to nixpkgs to report bugs.
Another alternative would be requiring users to explicitly set config.ambee.acceptThatThisPackageIsNotSupportedByUpstreamDevelopersAndIWillGoToNixpkgsToReportAnyIssues = true to be able to install the package, or they would get an error that would make it even clearer. Would that be enough for you?

We1 can remove the package but that should only be a last resort after we have exhausted all other options.
That is because in the absence of the package in Nixpkgs, every NixOS user would have to create their own ambee package if they wanted to use it. And no, pip is not an option since it simply is not reproducible enough.

Well, there is not really any “we” – NixOS currently has no policy about this so the responsibility falls on the individual maintainers adding the package (@fabaff).

Would that be enough for you?

I feel like I'm starting to be on repeat now. Please don't add any of my stuff to this project. Thanks 👍

Would that be enough for you?

No. Please don't add it to this project. Thanks 👍

That is because in the absence of the package in Nixpkgs, every NixOS user would have to create their own ambee package if they wanted to use it. And no, pip is not an option since it simply is not reproducible enough.

I'm aware of the consequence. Luckily the Home Assistant project does not recommend or support that either (which is unrelated but makes me worry less).

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

2 packages built:

python38Packages.ambee
python39Packages.ambee

No. Please don't add it to this project. Thanks +1

Request kindly denied due to the lack of technical reasons. If you don't wish your code to be packaged in nixpkgs, than make sure it is not a dependency of home-assistant or choose a different license (which should have the same result).

@Mic92 I will re-license and bump the dependency in a way that you guys can't distribute. Mainly because of not playing nice.
Thanks 👍

@Mic92 I will re-license and bump the dependency in a way that you guys can't distribute. Mainly because of not playing nice.
Thanks +1

This would likely result in no longer being open source and hence the removal from home-assistant as well.

This would likely result in no longer being open source and hence the removal from home-assistant as well.

Unfortunately, you are wrong there. I will explicitly and publicly list parties that are allowed distribution in the license.

This pisses me off in a way and is disrespectful. I asked nicely.

PS: This package is outdated and not even compatible with the target release anymore.
But I guess that didn't matter, as along as you could merge, right?

Quoting from Debian’s thread on Distributing software written by hostile upstream developers:

If we can't have a sensible relationship with the upstream developers, then I believe it would be better not to expose Debian and our users to the problems that will likely arise from packaging and distributing their software.

I fully agree with that so I would be in favour of removing it.

This is not really an issue for us, we can switch the license to an unfree one and than it is no longer build in nixpkgs but we only ship the build description for building it.

This is not really an issue for us, we can switch the license to an unfree one and than it is no longer build in nixpkgs but we only ship the build description for building it.

Please do from the start, that possibility wasn't provided.

Locked for now. Please see https://github.com/NixOS/nixpkgs/issues/126677#issuecomment-860071285. Please don't merge this until everyone's had a chance to cool off.

This package is outdated and not even compatible with the target release anymore.

Our update automation for Home Assistant prints a list of outdated dependencies, so this package will surely be updated in Nixpkgs when Home Assistant is.

@frenck I'd like to point out that core contributors from the Nix community are handling your request to support our project.
I'd like to clarify from your sponsors page the following statement:

Are you enjoying my work? And want to support me in my effort helping the world to become a better place by dedicating my time & knowledge to create & innovate open source software solutions. Allowing everybody on this earth the privilege to enjoy those things for free?

Do you still believe in that?

There is no point in locking this thread if NixOS contributors are just gonna ignore that and continue posting here without @frenck being able to respond.

FYI, this thread has resulted in some pretty spirited discussion on hackernews.

FYI, this thread has resulted in some pretty spirited discussion on hackernews.

We are aware of this. Thanks for the link anyway. :)

See: https://github.com/NixOS/nixpkgs/pull/126319#issuecomment-860942061

This would likely result in no longer being open source and hence the removal from home-assistant as well.

Unfortunately, you are wrong there. I will explicitly and publicly list parties that are allowed distribution in the license and allow for requesting distribution requests.

I feel the need to clarify that even a restriction like that would contradict the first criteria of the Open Source Definition:

The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources.

It would also contradict the Free Software Definition. A restriction like that would therefore result in the project no longer being open-source or free software.

I'm well aware of licensing and open source. It is my full-time daily driver and is visible in the very first request I made indicating the license permits it.
For me, this was not about licensing specifically. However, that point unfortunately is missed and got lost. Which is unfortunate. A lot blew up on the route, which just sucks for both parties.
In the end, I think the way this project distributes Home Assistant and the integration is not providing the intended working and thus may surprise the end user. In the end, those users are likely to knock on the doors of the Home Assistant project and their integration maintainers, not this project.
That is my concern, hence, my initially, friendly request to not include my packages, just like they don't include hundreds of other dependencies of Home Assistant either.
The way it is now discussed and thorn out of proportion is neither my nor (I'm sure) this project intention.

@frenck you may want to remove the second line from your GitHub profile bio:

Multiple compromises were offered including super explicit opt-in noted here https://github.com/NixOS/nixpkgs/pull/126326#issuecomment-860064953. What you are requesting is not FOSS thus you may need to consider making your repository private. Also please consider reading this thread as well https://news.ycombinator.com/item?id=27505277
As for inherit issue "Some peeps might create an issue on my project" - I strongly doubt that it is going to happen and if it does -  since you did not agree to any of the options which would help us avoid such issues, I am afraid that you just gonna have to just deal with it :/

I feel I've arrived somewhat late to the discussion, but I think it would be reasonable to weigh in here, because I'm home-assistant's (and coincidentally wled's) primary maintainer on nixpkgs these days.
The community consensus seems to be that we really want to keep these packages around, as dropping some of them will unnecessarily break user experiences, which I hope is also not in your interest. I'll also hope we can get to a cordial outcome despite our differences of opinion.
It is true that a lot of components to this day remain unsupported due to missing packages. This is due to the immense number of dependencies home-assistant relies on - but we are certainly catching up.
We also run a significant number of these for the components where we have all dependencies packaged up. We invest a reasonable amount of time to debug failing tests and make sure things work within our environment.
We have rarely asked upstream for support, knowing full well that NixOS is a special snowflake with regard to how everything gets composed. But please recognize that this is the place where we collaborate to bring home-assistant together with our philosophy how system administration should work.
We take great care when updating home-assistant and its leaf packages, and the index you found is created by tooling that also compares versions of packaged and expected dependencies, so it is somewhat unlikely that we'll ship home-assistant with an outdated dependency.
I also firmly believe that our community is well aware of how we compose home-assistant, so that it runs on NixOS, that they also will be highly aware when breaking changes occur, that they might be our fault.
I'd be happy to more clearly make our users aware, that our distribution is not supported upstream and that issues should first and foremost be directed to us, if that unburdens your project. It was certainly not our intention to sour the relationship with our upstreams.
I hope that puts all technical misunderstandings to rest and we can move on.
Martin Weinelt


Multiple entries with same name should turn into array

Hey!
I just noticed that handling multiple entries with the same name will result in a single prop with the last value. Coming from plain ol HTML forms, I would expect that they turn into an array.
This situation occurs when I have multiple checkboxes with the same name, or (more problematic) a multi select:
<form id="myForm">
    <input type="checkbox" name="pets" value="cat" />
    <input type="checkbox" name="pets" value="dog" />
    <input type="checkbox" name="pets" value="pig" />

    <select name="colors" multiple>
        <option>Blue</option>
        <option>Red</option>
        <option>Gold</option>
    </select>
</form>

const formData = new FormData($('#myForm'));

Array.from(formData);
// [
//     ['pets', 'cat']
//     ['pets', 'dog']
//     ['colors', 'Red']
//     ['colors', 'Gold']
// ]

decode(formData, { arrays: ['pets', 'colors'] })
// {
//     pets: 'dog',
//     colors: 'Gold'
// }

I would expect to receive an array, if the same key is found multiple times, regardless if it's defined in the FormDataInfo or not. But the info need to be configured properly, to enforce receiving an array, if only a single value is selected, as we can not differentiate it from single value entries.
What do you think?

Thank you for cresting this issue. I will look into this and get back to you in the next few days.

You are right. This functionality was missing in v0.4.0. I fixed it in v0.5.0. Thanks for the hint. To be consistent and allow decode to return valid data even if no option is selected (empty array), the field must be specified in FormDataInfo.

Thanks a lot! Works as expected now!

allow decode to return valid data even if no option is selected

It is also required to define arrays in FormDataInfo if only a single option is checked, because we can not differentiate from a single text field.

Can documentation be provided for this?

Yes, I will improve the documentation from time to time as more people start using the library. Basically, you just need to specify each array in the info argument of decode. Is there anything specific you want to know?

 test('should decode non-indexed arrays', () => {
    const formData = new FormData();
    formData.append('array', 'index_0');
    formData.append('array', 'index_1');
    formData.append('array', 'index_2');
    expect(
      decode(formData, {
        arrays: ['array'],
      })
    ).toEqual({
      array: ['index_0', 'index_1', 'index_2'],
    });
  });

Thanks, but I found a relevant test for what I'm looking for. It wasn't very clear to me what was the required templating from the above thread.

Here is a sample code that is clearer and shows both cases:
// Create form data
const formData = new FormData();

// Add values for `foo` array (without index)
formData.append('foo', 'index_0');
formData.append('foo', 'index_1');

// Add values for `bar` array (with index)
formData.append('bar.0', 'index_0');
formData.append('bar.1', 'index_0');

// Decode form data
const data = decode(formData, {
  arrays: ['foo', 'bar'], // both is required here
});


Thoughts about socket connection life cycle

This are just some thoughts about the socket connection life cycle. It would be nice to get some feedback. ;)
Currently every time the connection gets closed (ir remote, tcp timeout) we try to reopen it immediately. This causes (at least for me) to wake up the soundbar from standby. I found that if i turn the soundbar off via the ir remote it closes the tcp connection which in turn would immediately turn it back on (as of version 0.2). Edit: Not opening a connection turns it back on but sending data. This is just from my observations and i have to confirm if this is always the case.
For my use case (homeassistant, hass) this is even more pronounced since the current hass component uses polling. Since a already open socket would update the components state itself, i tried to disable the polling. But this caused (as of version 0.1) the connection to drop completely which makes the hass entity kinda like a "zombie process". I'm not going into more detail here since this is mostly hass related and there need to be changes made to the hass component to implement proper uuid handling.
Ok, now my proposal. Instead of reopening the connection after receiving the null byte we close the client socket. Edit: It seems that this part is not needed since only sending data would turn the soundbar back on. If any library method is called afterwards we reopen the socket connection (if it is closed). This means that we don't get status updates if the soundbar is turned on (wake up from standby) from outside (ir remote, other socket connection) but in turn we allow it to go to sleep.
For the hass part this would mean we use the zeroconf announce (the soundbar sends on broadcast/start) to create the entity and reopen the socket on the same event to get the current status. Maybe zeroconf would also be interesting to implement here in case we get a announce for "wake up from standby" (didn't check yet).
Is there a part of this you would consider adding to this library in one or another (pull request) way?

Did you check if you get a "wake up from standby" via zeroconf ?

As far as i tested it does not. Only after it was completely powered off or if something on the network actively searches for it. But for standby this is not really relevant anymore since the new socket implementation (version > 0.2) has fixed the connection problems for me.
I deactivated the polling in hass (via custom_component) and now it does not wake up and does not loose the connection. So if there is no interest in adding zeroconf (which wouldn't be that easy since from my observations the published UUID changes regularly) to reestablish the socket after a disconnect (network down, power off, ...) i would say this discussion can be closed.

I deactivated the polling in hass (via custom_component) and now it does not wake up

good, what have you changed to disable polling?
I have modified this code line to have a unique_id that does not change.

good, what have you changed to disable polling?

Just add this here.
...
    @property
    def should_poll(self):
        """No polling needed."""
        return False
...

I have modified this code line to have a unique_id that does not change.

Yeah added something there too. Would be interested what you used as uuid, because i wanted to make a pull request with some of my changes. But i think we should take this conversation somewhere else since this is not library specific.

Thank you!
it seems that by disabling polling everything works...
to continue the discussion there is this open issue in home-assistant


[Concurrency] Warning and fixig to remove unsafe from nonisolated(unsafe) func

It doesn't mean anything to do "unsafe" on a func
rdar://130406646
resolves #74571

@swift-ci please smoke test

@swift-ci please smoke test

Meh, this is wrong now I realized, diagnoses too much; will follow up soon

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test


Two hands for Handpose

[ ] Use new Handsfree({hands: true})
[ ] Extend the single hand model class
[ ] Do two inferences per loop and add them to hand[0] and hand[1]
[ ] Document

Closing in preference from the new Holistic MediaPipe!