hdfs support

Still trying to figure a few things out. This might be easier than I was initially expecting given it's the default shared filesystem other implementations have to be compatible with.
Some relevant info I've found so far:

spark docs discussing the hdfs state store provider. Note there were some other hits in it's RDD programming guide
since hdfs is only mentioned in the spark docs in reference to streaming datasets, I think these might be the relevant test. I looked through the rest of the hits not limited to that directory, and I didn't find any other test that reference hdfs directly.
Notes on unit testing spark jobs that require HDFS

all hits for object_store in crates happen within sail plan, so I'm guessing this should primarily be implemented within that crate?

hey, trying to setup spark for test but I'm running into an issue. even with a clean slate I'm getting a error somewhere
rm -rf opt/*
git clone https://github.com/apache/spark.git opt/spark
git clone https://github.com/ibis-project/testing-data.git opt/ibis-testing-data
scripts/spark-tests/build-pyspark.sh

here's the last bit of output. scrolling up can't take me  past a long stream of "copying " statements to the origin.
...
copying pyspark/tests/typing/test_resultiterable.yml -> pyspark-3.5.1/pyspark/tests/typing
copying pyspark.egg-info/SOURCES.txt -> pyspark-3.5.1/pyspark.egg-info
Writing pyspark-3.5.1/setup.cfg
creating dist
Creating tar archive
removing 'pyspark-3.5.1' (and everything under it)
error: Your local changes to the following files would be overwritten by checkout:
	pom.xml
Please commit your changes or stash them before you switch branches.
Aborting

given this post has a match for all the non-specific strings, I'm guessing this error comes from setup.py or immediately after setup.py is called. Any ideas what's going on?

Would it be alright if I pushed some "off-topic" commits? I added some changes to the build-pyspark.sh script that make it easier to resume after a failed partially-completed run, and makes sure the venv is setup/sourced before running the python command

I just took a look at the script change and I feel it goes a bit beyond what the script is supposed to do. Since the script is also used in CI, it may conflict with other parts of the GitHub Actions workflow.
Would you mind reverting the script change? Sorry for the back and forth. These are valuable suggested changes though. We'll definitely consider a way to incorporate the idea to make the developer experience better.

BTW I like the idea of using a lock file to skip expensive Maven build. I'll need some time to test it in CI so let's revisit this in a future PR.

I just took a look at the script change and I feel it goes a bit beyond what the script is supposed to do. Since the script is also used in CI, it may conflict with other parts of the GitHub Actions workflow.
Would you mind reverting the script change? Sorry for the back and forth. These are valuable suggested changes though. We'll definitely consider a way to incorporate the idea to make the developer experience better.

no worries, I used git reset to undo the last commit. and I'll push the script to a separate branch. Sorry for the delayed response, been running into issues getting the test environment setup

a couple things.
Is there a way to get pyo3 to use a uv installed python version? I tried running uv python install 3.11 prior to running start_server.sh but would still get linker errors for python3.11. I fixed this by installing it system level (sudo dnf install python3.11-devel), but was wondering if there was a way to easily avoid this (I try to keep development dependencies user level)
Second, I'm having trouble getting the run-client.sh script to work after everything has been set up. here's the output:
user@fedora ~/t/sail (hdfs_support) [1]> scripts/spark-tests/run-tests.sh
Removing existing test logs...
Test suite: test-connect
ERROR: module or package not found: pyspark.sql.tests.connect (missing __init__.py?)

================================================= test session starts ==================================================
platform linux -- Python 3.11.9, pytest-8.3.3, pluggy-1.5.0
rootdir: /path/to/sail
configfile: pyproject.toml
plugins: hypothesis-6.112.1, xdist-3.6.1, timeout-2.3.1, snapshot-0.9.0, reportlog-0.4.0, repeat-0.9.3, mock-3.14.0, pytest_httpserver-1.1.0
collected 0 items

-------- generated report log file: /path/to/sail/tmp/spark-tests/latest/test-connect.jsonl ---------
================================================ no tests ran in 0.17s =================================================
Test suite: doctest-column
===================== test session starts ======================
platform linux -- Python 3.11.9, pytest-8.3.3, pluggy-1.5.0
rootdir: /path/to/sail
configfile: pyproject.toml
plugins: hypothesis-6.112.1, xdist-3.6.1, timeout-2.3.1, snapshot-0.9.0, reportlog-0.4.0, repeat-0.9.3, mock-3.14.0, pytest_httpserver-1.1.0
collected 33 items

.venvs/test/lib/python3.11/site-packages/pyspark/sql/column.py E [  3%]
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE                         [100%]

- generated report log file: /path/to/sail/tmp/spark-tests/latest/doctest-column.jsonl -
====================== 33 errors in 0.22s ======================

I've made sure hatch run test:install-pyspark has run, and run-server.sh is running on a separate terminal. Kinda scratching my head on this one, it looks as though the issue comes from pyspark. I tried cding into opt/spark/python, running python setup.py sdist again, and rerunning the install script with hatch, but error is the same. Is there some step I'm missing?

Although, i'm also curious if maybe there is a problem with the Java installation. Unfortunately running the Spark tests requires Java to be installed.

I have java installed and JAVA_HOME set to /usr/lib/jvm/java-17-openjdk

Can we try to get some more verbose log outputs? It seems like doctest-column is able to run tests but they all fail. Maybe there are some useful error logs there:

when I ran that command. I'm getting a series of no such file or directory errors for files such as '/path/to/sail/.venvs/test/lib/python3.11/site-packages/pyspark/python/test_support'. when I look in the parent directory mentioned, the only contents are .venvs/test/lib/python3.11/site-packages/pyspark/python/lib/pyspark.zip, but when listing the contents of the zip, the missing files (i.e. test_support) are there. I'm guessing some late stage build step is suppose to unpack that file but isn't?

Could you run the Spark build script unmodified and see if it works? I took another look at #200 and it seems to me that the patch lock file may cause the patch to be skipped when you build the Python package. If the patch is not applied, neither the tests nor the test support files will be in the correct location in the zip package.
The Maven lock file seems fine to me though.

I renamed my current copy of sail and recloned the repo. Suprisingly it worked, but I'm not sure why given I removed the opt directory a few times (including the lock files), so I retested on my original copy (pruned/recreated the virtual envs, removed opt, reran the build script, etc). It's working now
I think I may finally have a hadoop container setup in pseudo-distributed mode for testing hdfs support. Where should it go? under scripts, opts or somewhere else?

Glad to hear that you got the setup working!
Let's define the container in compose.yml.
Testing external systems with containers is not part of CI right now but it could be future work. For this PR, it would be good enough to have a local setup. Either Python or Rust tests would be great.

hey, kind of stuck atm. I'm setting up hdfs in a local container, verifying it's working via the web portal, and then connecting to the hdfs container using the method mentioned in the dev docs.
p/t/sail> env SPARK_CONNECT_MODE_ENABLED=1 SPARK_REMOTE="sc://localhost:50051" hatch run pyspark
>>>path=hdfs://localhost:9000/user/skewballfox/test.json
>>>spark.read.json(path).show()

This throws a Object store error originating from this  generic IO error. I know it's connecting since the client returns okay, and because if I change it to a non-existent file, I get an error indicating the resource doesn't exist. So it's making it somewhere past the object store instantiation and failing during execution (I think). I'm having trouble tracing it any further than that though.
here's the last bit of traceback from python:
File "/p/t/sail/.venvs/default/lib/python3.11/site-packages/pyspark/sql/connect/client/core.py", line 1503, in _handle_error
    self._handle_rpc_error(error)
  File "p/t/sail/.venvs/default/lib/python3.11/site-packages/pyspark/sql/connect/client/core.py", line 1539, in _handle_rpc_error
    raise convert_exception(info, status.message) from None
pyspark.errors.exceptions.connect.SparkRuntimeException: Object Store error: Generic HdfsObjectStore error: IO error occurred while communicating with HDFS

here's the last trace from the server
[2024-09-19T18:39:08Z DEBUG sail_spark_connect::server trace:<PHONE_NUMBER>66876879727100582833342366091 span:<PHONE_NUMBER>847761413] ReleaseExecuteResponse { session_id: "487e2373-2881-41e9-ad87-d8362c5ef938", operation_id: Some("4e1997e1-2bd1-433a-a252-1826cb68986e") }

which is returned by release_execute
any ideas what the issue is or have suggestions on what I should try to track down the problem?

Just an update, Managed to finally read a json file from the hdfs instance, was a configuration issue. Still failing to write to hdfs, though that is probably also a configuration issue (working on fixing it).
Launching the hdfs container still doesn't work locally via podman compose. It keeps dying after around 15 seconds without producing any error and returning a normal exit code. I'm running the docker file under scripts/hadoop via
env HADOOP_USER_NAME=sail podman build -t hadoop-container .
podman run -it -p 50070:9870 -p 9000:9000 -p 9864:9864 -p 9866:9866 hadoop-container /bin/bash
#/hdfs-init.sh

I think i might have found a bug in the s3 code that may be upstream. If you upload a json file via the web portal, and then try to read it via spark.read.json(path).show() you'll get: Json error: Not valid JSON: EOF while parsing an object at line 1 column 1. It's definitely valid json, tested with a few files uploaded to the minIO instance
This doesn't happen with the code from the docs, but the query spark.sql("SELECT 1").write.json(path) isn't doing what it looks like. bar.json is created as a directory, and json files are created under it with the write command. When you look at the metadata for those files the content-type is listed as binary/octet-stream, whereas the files it fails to read have the content-type application/json. you can run read json commands on the octet-stream files created without issue

bar.json is created as a directory, and json files are created under it with the write command.

This is the expected behavior. The content type needs investigation though.

related issue for hdf-native-object-store

So I got reading, writing files working, at least for json. what other functions should I implement, confirm working prior to merging this?
with testing, I'm still using the dockerfile, bringing both containers up with the compose file doesn't seem to work, but it's most likely a misconfiguration of hadoop or podman. Traffic goes in to the container (write request are fulfilled), but responses don't make it back out.
Given that, should I just document how to set up the dockerfile?

btw, compose might work on other systems(with or without sudo).  I think part of the issue might be differences in rootless network configuration between podman-compose and podmans default on fedora 40. I know when launching hdfs via compose write request go through, because the files are created, outbound traffic is just broken

sorry I forgot to put [spark tests] in the commit message, could you retrigger it on your end?

sorry I forgot to put [spark tests] in the commit message, could you retrigger it on your end?

No worries! Since this PR does not change PySpark logic, it's fine to skip the tests. The tests will be run after the code is merged to main.
I've also created an issue (#227) so that the tests can be triggered without the special commit message.


Change improper use of ERL_DRV_EXTENDED_MAJOR_VERSION to the correct ERL_DRV_EXTENDED_MINOR_VERSION.

This change will allow erlang_js to work properly with R15.

+1


Memory and CPU usage does not update per process

On launch of PM2-GUI you can see how much memory and cpu a process is using:
"monit": {
"memory": "35M",
"cpu": 0
},
but these numbers are never updated...

+1

I'm currently working on a curses-like monitor, and I'll add this enhancement as soon as possible after the monitor being finished.

I would like this too, my processes typically don't stay on the same memory footprint.


Ability to lock status screen layout

Is your feature request related to a problem? Please describe:
It is very easy to mess up the status screen layout when using it on a touchscreen device like a tablet.   Instead of scrolling down the page, you end up resizing/moving widgets.
Describe the solution you'd like:
I would like to see a switch on the UI config settings (or elsewhere) to lock the layout.  This should then stop widgets being moved around accidentally.   When the layout is locked, the faint (+) add widget control should perhaps be hidden (or a message appear to inform the user that the layout is currently locked).
Describe alternatives you've considered:
I have checked and there doesn't seem to be any way to achieve this.
Additional context:
I normally use the UI on my laptop, but periodically when this is powered down I might open up the UI on my iPad to check something out or look at the logs.  Almost without fail, attempting to navigate the status screen on my iPad will result in "widget chaos", with panes flying hither and thither.  It's nigh on impossible to sensibly alter the layout using a touch screen, so I then have to power up my laptop to reset the layout again.  Thanks.

Click that + button, then click "Lock Layout".

Wow - how did I miss something so obvious.   Many thanks for such a rapid reply - and for producing such a great UI.  Apologies for wrongly logging an enhancement request.

np. I've had a few people ask. I might change that + symbol to a cog.

FYI the lock is per device.

Add feature to lock layout on touch devices that pretend to be a desktop.

Ok, great, thanks - I've now locked my layouts on my laptop and iPad.  I'd previously been looking for the lock facility on the 'UI Settings' page on the main menu.   It had been a while since I'd added an widgets, so must have not noticed that the lock facility was under there.  Yes, a cog icon would make it clearer that it isn't just adding a widget from here.
NB:  I've noted your change to this issue log - and yes in my view, locking by default on 'desktop class' touch devices makes a lot of sense.


Add Chef 12 updating docs

My vision for this is that it is the actual in-the-trenches guide to process and gotchas and the questions that everyone hits.  Not necessarily a wall of words on every last deprecation message no matter how small.
Also punting entirely on the question of what about chef-13 and now chef-14.  Chef-12 is the big pain point, so I don't care about upgrading from 13 and 14 right now.  We need people off 12.  We can reorganize the docs later when focus shifts.

tagging @tas50 and @chef/docs-team.
please just push commits directly to this branch and merge when complete
i'll fix stuff later if i find any issues.

Merging because imperfect docs >> no docs.  PRs accepted.


Build a standalone package for offline installation

Description of changes:
A convenience for offline or automated installations on Linux or macOS.
Same as the bundle for AWS CLI, which it's based on - https://github.com/aws/aws-cli/blob/1.16.314/scripts/make-bundle
It would be useful for me to have this published officially, even if only on Github (no need to host it on S3 like the AWS CLI bundle).
The goal of this script is simple:
  * Create a self contained install of the CLI that
  has requires no external resources during installation.
It does this by using all the normal python tooling
(virtualenv, pip) but provides a simple, easy to use
interface for those not familiar with the python
ecosystem.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Would be nice to at least get some kind of reply. Do you even consider merging this?

Sorry for the delay.  Looking into this today.
So to add on to this would we also add something to pipeline to push the packages to git?

Thanks!

So to add on to this would we also add something to pipeline to push the packages to git?

Probably yes. Though I have no idea about the pipeline setup in this project, that's why I didn't do it.

Was able to validate this works.  Double checking all the code one more time.


[GOREPORT] Fix linting issues maya/orchprovider/k8s/v1/util.go

Goreport is showing several linting errors. Please see the report at
https://goreportcard.com/report/github.com/openebs/maya
This issue is to fix the errors in
https://github.com/openebs/maya/blob/master/orchprovider/k8s/v1/util.go
Line 256: warning: comment on exported function SetControllerIPs should be of the form "SetControllerIPs ..." (golint)
Line 274: warning: comment on exported function SetReplicaIPs should be of the form "SetReplicaIPs ..." (golint)
Line 292: warning: comment on exported function SetControllerStatuses should be of the form "SetControllerStatuses ..." (golint)
Line 310: warning: comment on exported function SetReplicaStatuses should be of the form "SetReplicaStatuses ..." (golint)
Line 328: warning: comment on exported function SetServiceStatuses should be of the form "SetServiceStatuses ..." (golint)
Line 332: warning: exported function SetReplicaCount should have comment or be unexported (golint)
Line 336: warning: comment on exported function SetReplicaVolSize should be of the form "SetReplicaVolSize ..." (golint)
Line 347: warning: exported function SetIQN should have comment or be unexported (golint)
Line 351: warning: exported function SetControllerClusterIPs should have comment or be unexported (golint)
Line 368: warning: exported function SetISCSITargetPortals should have comment or be unexported (golint)

Hi @kmova @NisantaSahoo,
Is this issue open?
If yes, I'd like to take the same.

Hi I am working on the same, forgot to comment earlier.

@nsathyaseelan i will work on this

This issue is no longer valid


apt-get unhappy because of directory permissions

When running RootStock-NG.sh, I get errors like those shown below for the following modules:

libuchardet0_0.0.6-3
 libpruio-modules-4.19.79-ti-r30
rtl8723bu-modules-4.19.79-ti-r30
rtl8821cu-modules-4.19.79-ti-r30
ti-cmem-<IP_ADDRESS>-modules-4.19.79-ti-r30

The issue appears to be that /var/cache/apt/archives/partial/ has the following permissions/ownership:
drwx------ 2 _apt root      4096 Dec 11 11:08 partial

This directory must get deleted and recreated at some point, as setting the permissions to 0x777 before running RootStock-NG.sh caused it to revert to the permissions above.
I know the last 4 are installed from the chroot.sh script. I'm unclear why libuchardet0 is throwing a warning, as it's installed with a group of other packages much earlier on that all install without error. I also don't know why the way the chroot.sh script installing them is causing problems v.s. the way any of the other packages are installed.
Error text:
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  ti-cmem-<IP_ADDRESS>-modules-4.19.79-ti-r30
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 20.3 kB of archives.
After this operation, 66.6 kB of additional disk space will be used.
Get:1 http://repos.rcn-ee.com/debian buster/main armhf ti-cmem-<IP_ADDRESS>-modules-4.19.79-ti-r30 armhf 1buster [20.3 kB]
Fetched 20.3 kB in 0s (139 kB/s)
Selecting previously unselected package ti-cmem-<IP_ADDRESS>-modules-4.19.79-ti-r30.
(Reading database ... 39759 files and directories currently installed.)
Preparing to unpack .../ti-cmem-<IP_ADDRESS>-modules-4.19.79-ti-r30_1buster_armhf.deb ...
Unpacking ti-cmem-<IP_ADDRESS>-modules-4.19.79-ti-r30 (1buster) ...
Setting up ti-cmem-<IP_ADDRESS>-modules-4.19.79-ti-r30 (1buster) ...
W: Download is performed unsandboxed as root as file '/var/cache/apt/archives/partial/ti-cmem-<IP_ADDRESS>-modules-4.19.79-ti-r30_1buster_armhf.deb' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

Duplicate: https://github.com/RobertCNelson/omap-image-builder/issues/108
It's just a warning in apt, we are running the chroot as "root" but apt wants to be run as sandboxed "_apt" user.. yeah, don't worry about it..
Closing, it's a "feature"/bug/warning in apt..
Regards,


solved #10 added back to top button

Please check @sejalvasan ma'am

@maahiunnati will be keeping this issue on hold right now.


How to filter watched stories?

General Question
Read the Notes and fill out the form.
Switch to Preview for reading.
Notes
Your issue will be closed if you violate any rule below.

You need to include a meaningful descriptions and e.g. a screenshot.
You do not include screenshots of your code.
Read the Docs.
Capturing endpoints and similar can be found here
(read it if you are going to ask about it).
You can delete this section after reading it.

Form
Put an [x] if you meet the condition, else leave [ ].

[x] I've searched the Issues
[x] I've read the basic concepts
[x] I'm using the latest version

Question
How to filter watched stories?

You can only filter reels. They have a seen property.


Introduce support for sharded collections

This PR mainly builds on top of the work done by @clslrns in #1025. Changes include running travis tests on sharded cluster and some more relaxed error handling to account for different error messages depending on the MongoDB server version used. It also adds documentation for the sharding mapping as well as the @ShardKey annotation.
This also supersedes the work done in #691 and #325 which have been too long-running to be useful at this stage.
One feature that will be added at a later stage is the support for denormalizing the shard key values in non-simple references; this is not required but can greatly improve query times when fetching references on a sharded collection. This will be another PR as I'm waiting for #1349 to finalize the changes made to simple/full references.
TODO:

[x] Proofread and possibly expand documentation
[x] Re-visit checks for storage strategies in shard keys; currently fields using an increment strategy are excluded from shard keys. While this is technically a valid solution it might make more sense to just not update these fields in the query builder instead of throwing an error in the mapping.
[x] Store shard key values along with dbRef objects (waiting on #1349)

:+1:

Good to go once tests are green, yay! :+1:


CTRL+F2 highlights occurrences on scrollbar only downwards

When using CTRL+F2 to select all occurrences of a string all of them are selected within the file but the scrollbar feedback is limited to only those starting from current selection and downward.

VSCode Version: 1.18.0
OS Version: Windows 10 1703

Steps to Reproduce:

Open a reasonably long file with multiple occurrences of a specific string
Select a string occurrence somewhere in the middle
Observe tickmarks on scrollbar missing until current selection.

Duplicate of #1110

It's a completely different scenario than #1110.
It's an issue with checkmarks feedback on scrollbar, not actual code highlights.
You can try it with as little as 3 occurrences of a string in a file.
Please reopen and evaluate for duplicates more diligently.

@turboborsuk I cannot reproduce. I could not reproduce 2 hours ago, so I thought you just ran into #1110:

Can you perhaps add more precise information to help me reproduce ?

You can see this behavior below - when highlighting the first occurrence of the word "two" and hitting CTRL+F2 you get two checkmarks on the scrollbar. When doing the same after selecting the second one you get only one checkmark but the first occurrence is also highlighted for editing.
It can get annoying if you use the scrollbar feedback to know what parts of the file will be edited.

@turboborsuk thank you. I can reproduce now.


Support for VOLUME feature

Hi Wouter,
I really like your docker-maven-plugin, however the lack of the VOLUME feature in the plugin is the only thing I miss. Can you tell me if in some other way it is possible to make a docker directory accessible from outside the container? Or do you think this feature will be available soon?
E

Any progress on this?  At the moment, it seems to be the only thing missing that I need.

No real progress yet. It was really hard before, will have to check the REST API again.


fix parsing of STREAM frames that have the FinBit set

Fixes #542.
Probably also fixes #535. I found this issue while running the benchmark tests in my Ubuntu VM. With this fix, I didn't see any flaky benchmark test there anymore.
This could also be the fix for some of the other flaky tests.

lgtm


Enable override of BuildPayload()

Hi awesome plugin.
I am adding this in response to you inviting enabling other services for your plugin.
I enthusiastically installed the package for the obvious obfuscation of the Authorization methods.
I hit a snag when trying to do the first step of Authorizing the first defined service.
The BuildPayload() method is in a sealed class and uses a standard random no.
Our implication does something slightly different for additional security: e.g. :
The Authorization header for the authorize call is not using a radnom number but rather:
            string auth = Convert.ToBase64String(Encoding.UTF8.GetBytes(clientId + ":" + secret));

            var headers = new List<KeyValuePair<string, string>>
            {
                new KeyValuePair<string, string>("Content-Type", "application/x-www-form-urlencoded"),
                new KeyValuePair<string, string>("Authorization", "Basic " + auth)
            };

Being able to override this method will expand the amount of services you will be able to service exponentially.
It is offered as a suggestion rather than a bug.

I think you could do this, but for code based extensions we'd be expecting that rather than looking to override BuildPayload on the concrete class you would register your own implementation of IAuthorizationPayloadBuilder (the interface that defines this method).
It looks though that you are looking to implement OAuth Client Secret Authentication, so perhaps we can consider this as another configuration based option for authenticating with services.  Do you have a particular SaaS service you are looking to integrate with that uses this method?

Thanks Andy, Indeed we are implementing OAuth Client Secret Authentication.

@endstreet Were you able to implement something that lets you authenticate?
I was hoping to use the package with the Client Credentials Grant flow that we use for our own APIs.

Client credentials grant flow is something we've worked on, but we haven't released and documented it yet.  So it won't work with the current version of the package I'm afraid.  Look out for an update in the upcoming weeks though.

We'll have support for client credentials grant flow with the next release of the package, due next Tuesday.


Update CF Networking plugin

This adds the CF Networking plugin v1.2.0
We have added tooling to our CI repo to automatically generate these pull requests in the future. This tooling uses bosh interpolate to update the yml file, which orders all the keys within a hash alphabetically.
We discussed this briefly here, but there was some misunderstanding about what is alphabetized.  Hopefully this makes it more clear and future commits will look less messy.
/cc @chinangela

@mcwumbly Do you mind splitting up the commits for adding the plugin and changing the order?

@dkoper no problem, will do that now


Use SpansRepo in the SpansServiceImpl

Goal
Hook up the SpansRepository to the SDK
Testing
Add appropriate component tests

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

Current dependencies on/for this PR:

master

PR #266

PR #270   👈

This stack of pull requests is managed by Graphite.

The test flakieness seems to be caused by the spans feature not enabled for the background activity. This is likely a race condition inherent in how the service is intialized that was either exposed or exacerbated in the recent session orchestration refactors.
Given that the result would just be that spans will be delivered as part of the subsequent session, it's not a big deal. I'll merge this down and put together a fix that checks for this case.

Merge activity

Jan 24, 11:24 AM: @bidetofevil started a stack merge that includes this pull request via Graphite.


fixed: handling single element in content

I don't see any point in this. We are analyzing pairs. Single element does not form a pairs. So there is nothing to analyze.


Create example projects that utilize Docker/Vagrant

It would be helpful to have examples of possible configurations. so we can show the community how to make this play well with docker/vagrant.

Yeah agreed. Definitely worth setting up skeleton Dockerfile/Vagrantfile.
I think the barebones steps are:

base image (probably Ubuntu 14.04 or 16.04)
install virtualenv / virtualenv wrapper
clone repo (using the repo_name) variable
pip install requirements.txt

Could also include commented out steps to do things like:

make commands
run tests

Moved to discussion in #379


Additional code safety checks (disallow not-null assertion operator and force casting)

I've created two new rules for use at my company that I feel could be good additions for most Kotlin developers. Both are centered around code safety.
First, we have a rule to disallow the not-null assertion operator (!!). There are always safer ways to do things, and even if having null should cause a crash, it's clearer to explicitly throw an Exception when they're encountered.
Second, we have a rule to disallow force casting (using foo as Bar instead of foo as? Bar). Again, there are safer ways to do this, and if this is truly exceptional behavior, it's clearer to explicitly throw Exceptions.
Would others be interested in one or both of these rules? If so, which ruleset should they be added to?

I use each of these regularly and encourage their use. Both justifications are "it's clearer to explicitly throw an exception" which I don't really buy as an argument.
In Java I would write:
Thing thing = getSomeThing();
if (thing == null) {
  throw new NullPointerException("thing");
}

when I need to maintain the non-null invariant.
In Kotlin, not only can I write the shorter:
val thing = getSomeThing()!!

but I also get a better exception message for free as it includes (for now) the expression which produced the null rather than the local name (which is mostly useless).
It makes no sense to me to write
val thing = requireNonNull(getSomeThing()) { "thing" }

or
val thing = getSomeThing() ?: throw NullPointerException("thing")

when !! produces the exact same behavior in a more terse package. After all, isn't that the point of most of Kotlin? Reducing the verbosity of common patterns of Java?
If we're arguing against !! for being "bad" because it's a shorter version of a null check and throwing an exception, I would also like to ban ?. for being a shorter version of a null check and doing nothing. The safe call operator is dramatically worse than !! if we're purely focusing on syntactical shortenings that Kotlin provides. This operator silently allows null to propagate in your system. In the same way that we can't know whether !! was explicit, we can't know whether ?. was explicit and thus we would have to force people to use locals and normal null checks.
I, of course, do not believe that either are bad. But I do have a really hard time seeing how you can ban !! without also ?. since the former will thankfully at least always throw. In fact, by banning only !! you my inadvertently push people to ?. which is entirely the wrong thing which you should fail over to.
The choice between !!, ?., or any other handling of null is one which always requires thought. I do not believe that you can categorically replace the use of one of these with a longer construct, and especially not one without the other. These wouldn't be in the language if we weren't meant to use them. Someone misusing them is not a function of the operators being bad, it's an education issue. Certainly just about anything else can be misused to the same degree as well.
For as and as? I have the same general reasoning. I don't see value in categorically banning a language feature.

Those are totally valid arguments. It's interesting that force unwraps (swift's version of the not-null assertion operator) and force casts are both considered bad in the swift world, but not in the kotlin world. The swift equivalent of this library (swiftlint) has guards against both operators as defaults and everyone seems to agree that that's the right thing to do. Whether these rules are right or wrong for the kotlin community isn't my call. It was a good addition to our codebase, but if others feel they're not good rules for kotlin I'm happy to close the issue.

Project goal is to provide consistent code style. From this perspective usages of !! or as? are totally valid.
You rules are more related to the code quality that goes into the field of detekt.


Fixed bugs about cascade_roi_head.

Fixed the bug of refining bg rois at training when reg_class_agnostic is False.

Fixed the bug of potentially infering roi label to be bg at inference.

Hi @Jokoe66 ,
Thanks for your contribution. It seems that the modification changes the training logic if self.reg_class_agnostic=False. Have you validate the performance?

Hi, I don't validate it yet due to gpu limit.
Besides, I think the training logic of class-aware cascade roi head needs further modification. Under current modification, class-aware cascade roi head does not refine negative rois at training, but do it at inference by regarding them as their closest objects. I think it's better to keep the behavior at training consistent with that at inference. So I will change the gt_label of rois used to refine rois at training to what will be at inference.
------------------ Original ------------------
From: Wenwei Zhang<EMAIL_ADDRESS>Date: Thu,Jul 9,2020 2:22 AM
To: open-mmlab/mmdetection<EMAIL_ADDRESS>Cc: Jokoe66<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [open-mmlab/mmdetection] Fixed bugs about cascade_roi_head. (#3244)

The code looks good to me now. I will benchmark some models to validate the modification.

The code looks good to me now. I will benchmark some models to validate the modification.

Sure. Thanks.

The performance seems OK. I ran cascade mask r50 three times and obtained 41.1/35.9, 41.2/35.9, and 41.1/35.8 box/mask mAP.


outline-service-override does not see symbols from SymbolProvider

Adding getOutlineServiceOverride to the appPlayground example results in the Outline view complaining "The active editor cannot provide outline information":

Symbols can be correctly seen with ctrl-shift-o (for example sayHello when the cursor is in hello.ts) so the SymbolProvider is working. Is there an extra step to connect the SymbolProvider to the Outline when using vscode api? Sorry, I'm not sure if this is a mono-languageclient issue or a monaco-vscode issue.
Thanks

My mistake.  Was missing () in ...getOutlineServiceOverride() in vscodeApiConfig.serviceOverrides. Need to pass result of function call not the function itself.


Loadmat does not load the full data.mat file

I am loading data.mat into Python using the loadmat function.
I am missing some data, specifically I have 89823 samples in Matlab and I get 83741 samples in Python.
This loading is done at the beginning of the processing, so the data.mat have not been processed yet in any way.
I also do not know if the samples are lost all in the beginning or all at the end or randomly.
No error message is given during the script run.
scipy version: 1.13.0
Python version: 3.11.9

Can you share the file?

Sorry, I cannot.
It might contain sensitive information.

We need to be able to replicate the problem in order to work out what's going on.

Perhaps you can strip out everything except the variable in question, and confirm you have the same problem, before sharing.   If not, we will close this issue, but feel free to reopen if you have something we could reproduce with.


Switcher boiler integration

Switcher Water Heater Integration
Description:
Integration for controlling the Switcher Water Heater device (https://www.switcher.co.il/).
Example entry for configuration.yaml:
# Mandatory only configuration:
switcher_kis:
  phone_id: 'xxxx'
  device_id: 'xxxxxx'
  device_password: 'xxxxxxxx'

# Full configuration:
switcher_kis:
  phone_id: 'xxxx'
  device_id: 'xxxxxx'
  device_password: 'xxxxxxxx'
  name: 'my_boiler'
  include_schedule_sensors: true
  schedules_scan_interval:
    minutes: 5

# Defaults:
# name = 'boiler'
# include_sensors = false
# schedules_scan_interval = {'mintues': 5}

Checklist:

[x] The code change is tested and works locally.
[x] Local tests pass with tox. Your PR cannot be merged unless tests pass
[x] There is no commented out code in this PR.

If the code communicates with devices, web services, or third-party tools:

[x] New dependencies have been added to the REQUIREMENTS variable (example).
[x] New dependencies are only imported inside functions that use them (example).
[x] New or updated dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[x] New files were added to .coveragerc.

Thanks for contributing... there's a lot of code here to review, is it possible to break this down into a MVP with just a single platform?  It will help us get through it faster.

@andrewsayre
Thank you very much for your response.
First thing's first - I'll take care of the docs by tomorrow.
Regarding to the platform, I don't think it would be a good idea considering the component, if configured accordingly, creates 8 sensor entities representing 8 available schedule slots for the device, all the schedules updates are done with a single call to the device, so the entities are actually has a should_poll=false property and the main component pushes its updates to the entities. The same, but with a different concept goes for the switch entity as well.
I'll break it down a bit (and add some background):

This component is meant to allow full control of the Switcher V2 Water Heater Device, and in the future maybe even the other smart devices made by Switcher.
The communication with the device is based on sending and receiving messages via a tcp socket.
The messages are available for us to use locally only and was made available based on the R&D preformed by two other member in the community with full cooperation from the guys over at Switcher, you can find the original (python 2.7) script here.
This component has two custom-component ancestors:

switcher_heater Which was basically just a simple switch platform with the ability to turn on, off and get the current state of the device.
switcher_aio (the 'aio' stands for all-in-one) Which served two purposes:

It added numerous services for controlling not only the configuration of the device but also managing its schedules.
It was actually a "silly" attempt of me "trying to handle the user's frontend from the backend", if properly configured the component would create a view containing multiple groups and input_selects, input_numbers, input_booleans, scripts and etc. In retrospect, and with the Lovelace UI, It was wrong of me to do so.

I think that everyone who uses the Switcher V2 device with Home Assistant uses either one of my custom-components, and finally I found the long "awaited" (pun intended) time to re-write the whole component in high code standards so it can become more reliable and an official part of Home Assistant for ease of use.
The new name is switcher_kis, the 'kis' stands for keep-it-simple, the concept was actually keeping it simple and not messing with the frontend as the switcher_aio component did.
That's it with the background, now let's dive into the component's flow:
# line 477
v2bridge = SwitcherV2Thread(
    phone_id, device_id, device_password, async_initial_data_cb,
    async_update_device_cb, hass.loop)

v2bridge.start()

This will start a daemon threading.Thread instance which connects via socket and listens for broadcast messages from the device, which is launched every approximately 4 seconds.
The object will run the two coroutines passed as arguments (async_initial_data_cb and async_update_device_cb) using asyncio's run_coroutine_threadsafe from within hass's event loop.
The async_initial_data_cb coroutine will be called right after the very first broadcast message is picked up for the configured device, the async_update_device_cb coroutine will be called for each update of the specific device.
The async_initial_data_cb will create the the switch platform.
After initiating, the switch entity (called by default switch.switcher_kis_boiler) will register itself via the main component's designated async_register_switch_entity.
The async_update_device_cb coroutine which is called for every update of the device, will update the registered switch entity.
One more thing the async_initial_data_cb is responsible of is creating (if configured accordingly) 8 sensor entities representing the 8 available schedule slots in the device which will be called respectively `sensor.switcher_kis_boiler_schedule_X' (0-7).
The sensors state can vary, here are a few examples:

Due today at 17:30
Due tommorow at 17:00
Not enabled
Not configured

In resemblance to the switch entity, the sensor entities are also configured with the should_poll=false property and register themselves with the main component's async_register_sensor_entities coroutine.
The sensors update is scheduled with the async_track_time_interval helper every 5 minutes by default (if not else configured) using the component's async_update_schedules_data which calls the device's API and updates the registered sensors.
Using the async_listen_platform helper, the main component register the following coroutines for running as the individual platforms are discovered:

async_switch_platform_discoverd which registers the following services:

switcher_kis.turn_on
switcher_kis.turn_off
switcher_kis.turn_on_15_minutes
switcher_kis.turn_on_30_minutes
switcher_kis.turn_on_45_minutes
switcher_kis.turn_on_60_minutes
switcher_kis.set_auto_off
switcher_kis.update_device_name

async_sensor_platform_discoverd which registers the following services:

switcher_kis.create_schedule
switcher_kis.delete_schedule
switcher_kis.enable_schedule
switcher_kis.disable_schedule

All the communication to the device is made via the aioswitcher module I've built especially for this project. I plan on keeping the module maintained and updated so it could be of use with more projects and devices. The 'aioin the module name, stands for it beingasyncio` friendly.
The PyPi package can be found here, and the source here.

Pull request in home-assistant.io with documentation (if applicable): home-assistant/home-assistant.io#8480
Added docs.

Looking forward to see this integrated.
Maybe you should update the PR as per home-assistant/architecture#131
Simply move sensor/switcher_kis.py and switch/switcher_kis.py to components/switcher_kis/sensor.py and components/switcher_kis/switch.py

@andrewsayre
Thank you very much for your review.
I will do my best on following up on your change requests, I might need your help with clarifying some of them in the next couple of days while I'm working on meeting them.
Thank you in advance.

Most of the issues are around using socket and threading. There are async alternatives provided by the asyncio library.

Yes, I was actually doing some reading and planning on a new version of aioswitcher which will of course make use of these proper asyncio solutions.
I guess I'll have to speed things up for this component.
:-)

Imports of dependencies can only be done within functions. Only exception is in tests.

I understand the reasons for this rule, but I think there need to be another way to address this issue for rare cases when importing a dependency outside of the functions becomes a necessity. I think that was the case for some of your change requests, I'll of course go through all of them and consult you if that is true.

Please review the development docs for check lists and style guides.

I want assure you that I have and I am.
I know, this component needs some work before it can be integrated, and I know you have a lot of change requests, and as I said I really appreciate your review and I fully intend on following on all of them.
That being said, I don't think that the nature of the majority of the change requests might imply that I haven't been working closely with the development documentation, because I have and I am.
:-)

I understand the reasons for this rule, but I think there need to be another way to address this issue for rare cases when importing a dependency outside of the functions becomes a necessity.

This is not just a rule but an architectural requirement.  Requirements are not installed until the component or platform is loaded, which means that if the modules are parsed it will cause Home Assistant failures.  There are hundreds of other components and platforms that abide by this and have solved for it.  It means you have to rethink how you've designed the flow of the code.

I want assure you that I have and I am.

This is why we ask that you start small to get on the same page about how the checklists and style guides are interpreted.  It's extremely time-consuming to go through 1000s of lines of code and to have > 70 issues to go back and recheck.  There were also additional issues that I didn't call out at this time because I know the code is going to change significantly...

Then you can layer additional features in incrementally after you're up to speed with the style guidelines and checklists.  This will get you to done fast faster than if you continue with this big PR.

@andrewsayre
I think you are exaggerating a bit my friend.
We can divide your reviews in to two sections:

Asyncio implementation issues
Development checklist and guidelines issues

I admit it, the asyncio implementation part is my bad, fixing it will require updating the third-party library (which as I said, I had already planned on doing) and re-writing a lot of the component's code, which I don't think is a big deal.
Nevertheless, this part can take a couple of days.
The second part is on the fence in my point of view, some parts of the development documentation might be a bit misleading or unclear.
Then again the problem might be me, that's why its on the fence I think.
Nevertheless, all of these type of change requests shouldn't take more the two hours tops.
So, I'm sorry but, I do not agree with your suggestions of me not even reading the documentation, I would like to believe that in-spite of the amount of the change requests, it's still obvious that I did by my code.
I don't know why would you think that in this point in time the smart thing to do is to "dumb the component down" and strip it down to a simple switch.
The component has two working custom components ancestors and it is working, it's just not working as we want it to, you can even say it's not working as it should.
It's my job to make it do so based on your on-point review and change requests.
All I need from you is your help in maybe clarifying some of the requests and of course your much appreciated review once I'm done.
Please allow the time for me to do my part before you so decisively dim my PR and Component as "unworthy and needs to go back to the drawing board".
As you said, you found more then 70 issues and you could have find a lot more if you wanted to...
Common my friend, be reasonable, a lot of this issues are repeating themselves, which makes it obvious they are based on a wrong assumption of mine. There's no actual need to point out every occurrence of the issue, just to change the initial assumption.
I'll give you an example:
As you suggested, there's really no point of using Dict.get() on configuration values configured as Required in the configuration schema.
I didn't thought of that - That's a great tip, thank you. I will apply it not only in this component, but also in other projects of mine.
But, you didn't Have To point out every occurrence of that function, one example should do the trick.
You can, as you did, turn one issue into five issues by copying and pasting your comments to every occurrence of a resemble issue.
That will actually make my part easier, but you didn't Have To do that.
The same goes for the import issues, as I said, I was working under the (wrong) assumption that once the component has called for the installation of the third party library, that it was safe to import it outside of functions inside platforms.
My bad. You have corrected my assumption and I appreciate it, I will make the proper adjustments to the component.
Thank you, but again, you didn't have to point out every single occurrence of that type of import, one issue is enough, more then ten issues of the same exact content is redundant and just creates more work on your end.
Again, I really appreciate you doing that, you made my part a lot easier, thank you.
But if you're going to "send me back to the drawing board" based on the amount of issues, then it's not really fair considering a lot of this issues are replications of each other.
**Please don't get me the wrong way, "I come in peace", I really appreciate your review and your help.
And I would appreciate your continues help in clarifying some of the issues and review them again once I'm done fixing them.
Just please, allow me the time for following up on your change requests and make the proper adjustments.
Thank you.
:-)**

@andrewsayre
Hi friend.
Once again I want to say thank you for all of your help and reviews.
I've have uploaded the new version of the third-party module aioswitcher to PyPi,
It has been redesign and is now fully asynchronous and has no blocking code:
PyPi Package
Source Code
I've pushed the version of the component and platforms,
As you suspected and based on your review, there were a lot of change and a lot of the code had to be re-written.
I'm looking forward to your review, thanks.
:-)

As you suspected and based on your review, there were a lot of change and a lot of the code had to be re-written.

Now is a good time to start a fresh PR to get rid of the clutter.  Reference this one and I'll assign it to myself for review.
Also, in the future, do not merge dev into your branch to catch up with commits.  Follow the rebase flow: https://developers.home-assistant.io/docs/en/development_catching_up.html

As you suspected and based on your review, there were a lot of change and a lot of the code had to be re-written.

Now is a good time to start a fresh PR to get rid of the clutter. Reference this one and I'll assign it to myself for review.
Also, do not merge dev into your branch to catch up with commits as that pulls unrelated changes into your PR (another reason to start a fresh PR now). Follow the rebase flow: https://developers.home-assistant.io/docs/en/development_catching_up.html

I'm on it, thanks!

@andrewsayre
Pushed a new PR #22325
Thanks!


Formatting JSON removes blank lines

This is a copy of #37422.
Installing prettier doesn't solve the problem and using "json.format.enable": false removes the option to format the document.
You can easily test it with the settings file.
// edit using beautify also is the same, except you can manually select beautify file.

Using prettier now, "prettier.jsonEnable": [ "json", "jsonc" ], fixes the problem.

I think that using prettier is the best solution.


Turn off "restore" notifications?

I love the work you guys have done, and I am thankful that the extension tries to restore my dependencies - but is there a way to ask it to ... well, not?
It's a bit obtrusive to have it keep trying that constantly. Sometimes - actually most times - I need to do a restore when I'm ready to. I've had situations where I have stacks of 10 notifications keep pouring over the top of my screen trying to force me to restore my projects when that's just not what I want to do.
The same with the debugger. Can we set it to be downloaded and installed when we ask it to - instead of it always doing it for every project, automatically, the second it is opened? It makes it very hard to rapidly move between things, copy things out of old projects, etc. It's constantly doing things I'm really not asking it to do.

The debugger shouldn't be downloaded for each project. Are you referring to the popup that asks if you want to add tasks.json and launch.json?

This is the original bug https://github.com/OmniSharp/omnisharp-roslyn/issues/504

Yes, that would be the bug it seems. Sorry, I guess this is a pre-existing issue. I thought I was just going crazy.

No worries. It's something I've heard a number of times. I'll look at improving that experience. I think we can do some things in the C# extension for VS Code to make it better, as well as improving the OmniSharp server itself.

Hi @ciel, is this still an issue for you with the latest C# extension?

Yes. It is such a huge issue that VSC is completely unusable.
On Aug 27, 2016 5:52 AM, "Dustin Campbell"<EMAIL_ADDRESS>wrote:

Hi @ciel https://github.com/ciel, is this still an issue for you with
the latest C# extension?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/OmniSharp/omnisharp-vscode/issues/193#issuecomment-242910413,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAavtCtov5r-X5sB1_mITlwHq1AWCLa_ks5qkBbugaJpZM4IIa51
.

+1 because this becomes pretty annoying when e.g. opening a projects that are meant to be (or just have been) restored with special arguments by a build script (e.g. dotnet/cli).
But then it's pretty handy when working on new / small projects... so being able to configure it would be awesome.

@DustinCampbell There is some discussion on Slack about the auto-restore again. Everyone there is in agreement that VS Code should have a setting that allows us to turn off the auto-restore. I'm surprised this wouldn't be fairly easy to pull off. Isn't it just a workspace setting (bool) and an if block on the dotnet restore bits?

Where in Slack is this discussion happening? On the official OmniSharp Slack? I'd love to be a part of any discussion, or better yet, have the discussion here in the open.
Oh, I agree too. It's just a matter of finding the time to get this feature done at the moment, with other priorities. It's pretty high on my list, but not the highest. I have a couple of thoughts.

I suspect that everyone would like the restore popup quite a bit more if it didn't appear for every single change in the universe, but grouped them together into one prompt. I suspect that would be helpful.
It'd be great if we could be a bit smarter when someone does a normal operation like a git clean -xdf and not offer to restore immediately.

I don't think the change you suggest is the right one. We shouldn't be killing the event based on an option, but rather providing smarter behavior when the event fires.

It was on the aspnetcore Slack, and I mis-described it. It's was more of a "rant" among a couple of devs than a "discussion."
I'm sure it will be great when restore is smarter and better. However, I disagree with your point about not offering a way to completely disable automatic restore.
I use my extension, Status Bar Tasks, and when I want a restore, I trigger it manually with one click in the status bar. I can't think of a single situation where I would want an automatic restore. I prefer to be able to configure Omnisharp with a workspace setting that permanently disables it.
On the other hand and as I was saying to @shaunluttin, any of us can just clone the repo and make a version of this that does whatever we like, and I thank you, the Omnisharp team, and MS for making that possible. :+1:
Based on your response, it seems like the winds are blowing in the direction of never having a permanent disable option, so let me ask this in case I decide to clone and hack: Would it be as simple as removing ...
public onUnresolvedDependencies(listener: (e: protocol.UnresolvedDependenciesMessage) => any,
        thisArg?: any) {
    return this._addListener(Events.UnresolvedDependencies, listener, thisArg);
}

... and the d3 bit at ... https://github.com/OmniSharp/omnisharp-vscode/blob/ffc52290366467417cc7d673e4756821d8e19827/src/features/status.ts#L245-L256
let d3 = server.onUnresolvedDependencies(message => {
    let info = `There are unresolved dependencies from
        '${vscode.workspace.asRelativePath(message.FileName) }'. Please execute the restore
        command to continue.`;

    return vscode.window.showInformationMessage(info, 'Restore').then(value => {
        if (value) {
            dotnetRestoreForProject(server, message.FileName);
        }
    });
});

return vscode.Disposable.from(d0, d1, d2, d3);

... from server.ts?

Oh, I didn't say that I disagreed with offering a way to disable. I specifically said that I agreed. :smile:
On disabling, yes, it's certainly possible to do it in the extension (I'm taking PRs BTW). However, I've been wondering if it's probably better done in OmniSharp itself. After all, why bother registering a bunch of FIleSystemWatchers and firing events that aren't going to get handled.

@DustinCampbell I am the developer who started the rant about disabling the popup. Here are the things on my wish list:

A way to permanently disable the Info popup, when I decide it no longer provides value.
A keyboard shortcut to close the Info popup, so that I can keep my hands on the keyboard.

Right now, the Info popup significantly interferes my my flow during development.

Sounds good. :smile:

@DustinCampbell I am also confused about why it is called "auto-restore" because it isn't auto. Rather, it is more a "restore-notification" that we can click on manually to trigger restore.

I'm confused too. :smile: That's what it was called when I inherited the extension.

@DustinCampbell I deleted the comment... sorry.

@DustinCampbell Is there an existing keyboard shortcut to close those Info notifications?

It is actually almost impossible to develop in Visual Studio Code without a mouse unless we restore first.

I'm not sure if there's a keyboard shortcut or not. That's just the standard VS Code UI for displaying an information message.

Sorry guys ... lack of paying attention on my part when discussing: It's not auto-restore ... it's auto-notification that a restore is needed. I just don't need to be told that. Sorry again.

@DustinCampbell Could you please invite me to the omnisharp-vscode channel on Slack. That way I can rant there instead. :trollface:

Link is here: https://goo.gl/Ovnqr1

A new (release)[https://github.com/OmniSharp/omnisharp-vscode/releases/tag/v1.5-beta6] is ready which includes a csharp.suppressDotnetRestoreNotification option.


Subscription expired notification for auto-renewable subscription

I've implemented auto-renewable subscription successfully. The subscription duration is 1 year with 7days trial. I want to get notification when the subscription is expired to inform users like "Your subscription is expired now.".
Can I get notification from RMStore? Or should I check every time if the purchase is valid?

Did you figure out @leomyth330 ? I am also interested in it


Feature/139

closes #139

Adds antibody files model
Adds antibodyfiles.csv ingestion
Adds antibody files entity to django admin

todo:

Decide how to handle filehash

While testing the ingestion locally I noticed that the vendor name changed to unique. That doesn't fit with the vendor csv files we have for ingestion.
f.e. STEMCELL Technologies
So I changed it back to non-unique.

I also noticed that adding a new antibody through the django admin (not through the import plugin) the 'publisher' is unknown:


Invalid certificate on official library website

I was about to purchase a premium extension when suddenly the SSL certificates on the website expired. Is it still possible to purchase those extensions or will the project not be supported in the future?

Apologies and thank you for letting me know - the SSL certificate issue has
now been resolved.

Message ID: @.***>

Thanks very much


Workbox "Getting Started" updates for v3

This migrates the material in the Workbox getting started guides to use the new v3 syntax.
Adding the DO_NOT_MERGE label for now, as we want to time this following the official launch of Workbox v3.0.0.
Fixes: #5766
Target Live Date: 2018-03-08

[ ] This has been reviewed and approved by (@kaycebasques)
[X] I have run gulp test locally and all tests pass.
[X] I have added the appropriate type-something label.
[X] I've staged the site and manually verified that my content displays correctly.

CC: @petele @gauntface @addyosmani

:+1:

Good call re: using the shared CDN URL.
Regarding where this would live, I'm concerned about breaking existing URLs if we moved this around. My vote would be to keep this in its current spot and I'll make sure to remember to merge this post-v3 release.

Whoops!
There were 1 warnings that will prevent this PR from being merged. Please take a look, and either fix, or provide a justification for why they can't be fixed.
WARNINGS
src/content/en/tools/workbox/get-started/_shared/create.md#L42 - Line must be at most 100 characters

Sorry, @WebFundBot, that line's gotta be that long.