Collect images for hero images

Need to talk to Marie to expense the following images found in:
#54
#39

http://www.shutterstock.com/pic-344201303/stock-photo-group-of-diverse-hands-together-joining-concept.html?src=9jj1VEg5oTub4q2QZalo1Q-1-22
http://www.shutterstock.com/pic-273553727/stock-photo-a-researcher-is-testing-dropping-reagent-to-test-tube-at-laboratory-with-chemical-equations-and-periodic-table-background.html?src=C-Vrla0xmq-W-wy9nBl6NQ-1-64
http://www.shutterstock.com/pic-112184054/stock-photo-atlanta-ga-usa-april-28-2012-a-group-of-unidentified-women-competing-in-the-dirty-girl-mud-run-splash-through-mud-as-they-near-the-finish-line-of-the-women-only-race-on-april-28.html?src=44bU3iuzOZjULE_ddXfP1g-1-42

Pricing for shutterstock:
http://www.shutterstock.com/subscribe?clicksrc=header
£32 for 5 images
£139 for 25 images

Selfie image is getty images...would be good to get them all from one source.
Here are some alternatives:
https://www.shutterstock.com/search?searchterm=selfie+adventure&search_source=base_search_form&language=en&page=1&sort=popular&image_type=all&category=People&safe=true
@jazbinda could you choose one to replace this: https://cloud.githubusercontent.com/assets/19264436/15183824/b065937c-178a-11e6-93a6-387bb8ca9e1f.png

Can we please wait until tomorrow to buy images as they were all placeholders for now

@jazbinda: ok...woops, I have gotten the top 3 image, compressed and plumbed them into the site. We will leave everything else until tomorrow.


fix: wrong symbols in v6.

This PR fixes the issue https://github.com/nodejs/node-api-headers/issues/5.

Any chance of this being published to npm?

@Julusian yes I will provide to publish later.


docs: adds updated tutorial for deploying Prisma > 1.8 to Kubernetes

This PR contains the updated tutorial on how to deploy Prisma >= 1.8 to Kubernetes.

Hey @akoenig, sorry our process for merging docs PRs has been extremely messed up over the past few weeks/months 😐 If you have a PR you want to get reviewed/merged, the best way is to ping me directly so I can take care of it. In any case, thanks so much for updating the tutorial! 🙏


add ability to specify search configuration for ts_query command

Added third optional parameter in TSQUERY to allow usage of text search configuration other than 'default'. See http://www.postgresql.org/docs/8.3/static/textsearch-intro.html#TEXTSEARCH-INTRO-CONFIGURATIONS.

thanks

You're welcome. But pay attention, the composer.json file also got merged (did not intend to include that in the pull request). You'll need to reset the package name there to it's original value.
regards

Rollbacked, thank you)


factorialcpp

this program is used to find factorial by using c++
Please see CONTRIBUTING.md for how to set up your development environment and run tests.

accept for hacktoberfest and this code is done by me.

From the Hacktoberfest website:

PRs can be made to any public repo on GitHub, not only the ones with
issues labeled Hacktoberfest. If a maintainer reports your pull
request as spam or behavior not in line with the project’s code of
conduct, you will be ineligible to participate.

How do you feel that this PR fits with Infer (and shouldn't be classified as "spam")?


Make setup script idempotent

ie. what if the user (needs to) run it twice?
Perhaps check if venv already exists?
https://github.com/ohsu-comp-bio/vrs-python-testing/blob/development/scripts/setup.sh#L3-L6
Are there other issues if setup run twice?

To my understanding, the script still works if I am rerunning the setup, here's the logs

bash scripts/setup.sh
Requirement already satisfied: ga4gh.vrs==2.0.0a5 in ./venv/lib/python3.12/site-packages (from ga4gh.vrs[extras]==2.0.0a5->-r requirements.txt (line 1)) (2.0.0a5)
Requirement already satisfied: diskcache in ./venv/lib/python3.12/site-packages (from -r requirements.txt (line 2)) (5.6.3)
Requirement already satisfied: biocommons.seqrepo in ./venv/lib/python3.12/site-packages (from -r requirements.txt (line 3)) (0.6.9)
Requirement already satisfied: glom in ./venv/lib/python3.12/site-packages (from -r requirements.txt (line 4)) (23.5.0)
Requirement already satisfied: click in ./venv/lib/python3.12/site-packages (from -r requirements.txt (line 5)) (8.1.7)
Requirement already satisfied: pyyaml in ./venv/lib/python3.12/site-packages (from -r requirements.txt (line 6)) (6.0.1)
Requirement already satisfied: google in ./venv/lib/python3.12/site-packages (from -r requirements.txt (line 7)) (3.0.0)
Requirement already satisfied: requests in ./venv/lib/python3.12/site-packages (from -r requirements.txt (line 8)) (2.31.0)
Requirement already satisfied: boto3 in ./venv/lib/python3.12/site-packages (from -r requirements.txt (line 9)) (1.34.60)
Requirement already satisfied: tqdm in ./venv/lib/python3.12/site-packages (from -r requirements.txt (line 10)) (4.66.2)
Requirement already satisfied: google-cloud-storage in ./venv/lib/python3.12/site-packages (from -r requirements.txt (line 11)) (2.15.0)
Requirement already satisfied: bioutils in ./venv/lib/python3.12/site-packages (from ga4gh.vrs==2.0.0a5->ga4gh.vrs[extras]==2.0.0a5->-r requirements.txt (line 1)) (0.5.8.post1)
Requirement already satisfied: canonicaljson in ./venv/lib/python3.12/site-packages (from ga4gh.vrs==2.0.0a5->ga4gh.vrs[extras]==2.0.0a5->-r requirements.txt (line 1)) (2.0.0)
Requirement already satisfied: coloredlogs in ./venv/lib/python3.12/site-packages (from ga4gh.vrs==2.0.0a5->ga4gh.vrs[extras]==2.0.0a5->-r requirements.txt (line 1)) (15.0.1)
Requirement already satisfied: numpy in ./venv/lib/python3.12/site-packages (from ga4gh.vrs==2.0.0a5->ga4gh.vrs[extras]==2.0.0a5->-r requirements.txt (line 1)) (1.26.4)
Requirement already satisfied: pydantic~=2.1 in ./venv/lib/python3.12/site-packages (from ga4gh.vrs==2.0.0a5->ga4gh.vrs[extras]==2.0.0a5->-r requirements.txt (line 1)) (2.6.4)
Requirement already satisfied: psycopg2-binary in ./venv/lib/python3.12/site-packages (from ga4gh.vrs[extras]==2.0.0a5->-r requirements.txt (line 1)) (2.9.9)
Requirement already satisfied: hgvs>=1.4 in ./venv/lib/python3.12/site-packages (from ga4gh.vrs[extras]==2.0.0a5->-r requirements.txt (line 1)) (1.5.4)
Requirement already satisfied: dill~=0.3.7 in ./venv/lib/python3.12/site-packages (from ga4gh.vrs[extras]==2.0.0a5->-r requirements.txt (line 1)) (0.3.8)
Requirement already satisfied: ipython~=8.4 in ./venv/lib/python3.12/site-packages (from biocommons.seqrepo->-r requirements.txt (line 3)) (8.22.2)
Requirement already satisfied: pysam~=0.22 in ./venv/lib/python3.12/site-packages (from biocommons.seqrepo->-r requirements.txt (line 3)) (0.22.0)
Requirement already satisfied: six~=1.16 in ./venv/lib/python3.12/site-packages (from biocommons.seqrepo->-r requirements.txt (line 3)) (1.16.0)
Requirement already satisfied: yoyo-migrations~=8.2 in ./venv/lib/python3.12/site-packages (from biocommons.seqrepo->-r requirements.txt (line 3)) (8.2.0)
Requirement already satisfied: boltons>=19.3.0 in ./venv/lib/python3.12/site-packages (from glom->-r requirements.txt (line 4)) (23.1.1)
Requirement already satisfied: attrs in ./venv/lib/python3.12/site-packages (from glom->-r requirements.txt (line 4)) (23.2.0)
Requirement already satisfied: face==20.1.1 in ./venv/lib/python3.12/site-packages (from glom->-r requirements.txt (line 4)) (20.1.1)
Requirement already satisfied: beautifulsoup4 in ./venv/lib/python3.12/site-packages (from google->-r requirements.txt (line 7)) (4.12.3)
Requirement already satisfied: charset-normalizer<4,>=2 in ./venv/lib/python3.12/site-packages (from requests->-r requirements.txt (line 8)) (3.3.2)
Requirement already satisfied: idna<4,>=2.5 in ./venv/lib/python3.12/site-packages (from requests->-r requirements.txt (line 8)) (3.6)
Requirement already satisfied: urllib3<3,>=1.21.1 in ./venv/lib/python3.12/site-packages (from requests->-r requirements.txt (line 8)) (1.26.18)
Requirement already satisfied: certifi>=2017.4.17 in ./venv/lib/python3.12/site-packages (from requests->-r requirements.txt (line 8)) (2024.2.2)
Requirement already satisfied: botocore<1.35.0,>=1.34.60 in ./venv/lib/python3.12/site-packages (from boto3->-r requirements.txt (line 9)) (1.34.60)
Requirement already satisfied: jmespath<2.0.0,>=0.7.1 in ./venv/lib/python3.12/site-packages (from boto3->-r requirements.txt (line 9)) (1.0.1)
Requirement already satisfied: s3transfer<0.11.0,>=0.10.0 in ./venv/lib/python3.12/site-packages (from boto3->-r requirements.txt (line 9)) (0.10.0)
Requirement already satisfied: google-auth<3.0dev,>=2.26.1 in ./venv/lib/python3.12/site-packages (from google-cloud-storage->-r requirements.txt (line 11)) (2.28.2)
Requirement already satisfied: google-api-core<3.0.0dev,>=2.15.0 in ./venv/lib/python3.12/site-packages (from google-cloud-storage->-r requirements.txt (line 11)) (2.17.1)
Requirement already satisfied: google-cloud-core<3.0dev,>=2.3.0 in ./venv/lib/python3.12/site-packages (from google-cloud-storage->-r requirements.txt (line 11)) (2.4.1)
Requirement already satisfied: google-resumable-media>=2.6.0 in ./venv/lib/python3.12/site-packages (from google-cloud-storage->-r requirements.txt (line 11)) (2.7.0)
Requirement already satisfied: google-crc32c<2.0dev,>=1.0 in ./venv/lib/python3.12/site-packages (from google-cloud-storage->-r requirements.txt (line 11)) (1.5.0)
Requirement already satisfied: python-dateutil<3.0.0,>=2.1 in ./venv/lib/python3.12/site-packages (from botocore<1.35.0,>=1.34.60->boto3->-r requirements.txt (line 9)) (2.9.0.post0)
Requirement already satisfied: humanfriendly>=9.1 in ./venv/lib/python3.12/site-packages (from coloredlogs->ga4gh.vrs==2.0.0a5->ga4gh.vrs[extras]==2.0.0a5->-r requirements.txt (line 1)) (10.0)
Requirement already satisfied: googleapis-common-protos<2.0.dev0,>=1.56.2 in ./venv/lib/python3.12/site-packages (from google-api-core<3.0.0dev,>=2.15.0->google-cloud-storage->-r requirements.txt (line 11)) (1.63.0)
Requirement already satisfied: protobuf!=3.20.0,!=3.20.1,!=4.21.0,!=4.21.1,!=4.21.2,!=4.21.3,!=4.21.4,!=4.21.5,<5.0.0.dev0,>=3.19.5 in ./venv/lib/python3.12/site-packages (from google-api-core<3.0.0dev,>=2.15.0->google-cloud-storage->-r requirements.txt (line 11)) (4.25.3)
Requirement already satisfied: cachetools<6.0,>=2.0.0 in ./venv/lib/python3.12/site-packages (from google-auth<3.0dev,>=2.26.1->google-cloud-storage->-r requirements.txt (line 11)) (5.3.3)
Requirement already satisfied: pyasn1-modules>=0.2.1 in ./venv/lib/python3.12/site-packages (from google-auth<3.0dev,>=2.26.1->google-cloud-storage->-r requirements.txt (line 11)) (0.3.0)
Requirement already satisfied: rsa<5,>=3.1.4 in ./venv/lib/python3.12/site-packages (from google-auth<3.0dev,>=2.26.1->google-cloud-storage->-r requirements.txt (line 11)) (4.9)
Requirement already satisfied: configparser>=3.3.0 in ./venv/lib/python3.12/site-packages (from hgvs>=1.4->ga4gh.vrs[extras]==2.0.0a5->-r requirements.txt (line 1)) (6.0.1)
Requirement already satisfied: parsley in ./venv/lib/python3.12/site-packages (from hgvs>=1.4->ga4gh.vrs[extras]==2.0.0a5->-r requirements.txt (line 1)) (1.3)
Requirement already satisfied: psycopg2 in ./venv/lib/python3.12/site-packages (from hgvs>=1.4->ga4gh.vrs[extras]==2.0.0a5->-r requirements.txt (line 1)) (2.9.9)
Requirement already satisfied: decorator in ./venv/lib/python3.12/site-packages (from ipython~=8.4->biocommons.seqrepo->-r requirements.txt (line 3)) (5.1.1)
Requirement already satisfied: jedi>=0.16 in ./venv/lib/python3.12/site-packages (from ipython~=8.4->biocommons.seqrepo->-r requirements.txt (line 3)) (0.19.1)
Requirement already satisfied: matplotlib-inline in ./venv/lib/python3.12/site-packages (from ipython~=8.4->biocommons.seqrepo->-r requirements.txt (line 3)) (0.1.6)
Requirement already satisfied: prompt-toolkit<3.1.0,>=3.0.41 in ./venv/lib/python3.12/site-packages (from ipython~=8.4->biocommons.seqrepo->-r requirements.txt (line 3)) (3.0.43)
Requirement already satisfied: pygments>=2.4.0 in ./venv/lib/python3.12/site-packages (from ipython~=8.4->biocommons.seqrepo->-r requirements.txt (line 3)) (2.17.2)
Requirement already satisfied: stack-data in ./venv/lib/python3.12/site-packages (from ipython~=8.4->biocommons.seqrepo->-r requirements.txt (line 3)) (0.6.3)
Requirement already satisfied: traitlets>=5.13.0 in ./venv/lib/python3.12/site-packages (from ipython~=8.4->biocommons.seqrepo->-r requirements.txt (line 3)) (5.14.2)
Requirement already satisfied: pexpect>4.3 in ./venv/lib/python3.12/site-packages (from ipython~=8.4->biocommons.seqrepo->-r requirements.txt (line 3)) (4.9.0)
Requirement already satisfied: annotated-types>=0.4.0 in ./venv/lib/python3.12/site-packages (from pydantic~=2.1->ga4gh.vrs==2.0.0a5->ga4gh.vrs[extras]==2.0.0a5->-r requirements.txt (line 1)) (0.6.0)
Requirement already satisfied: pydantic-core==2.16.3 in ./venv/lib/python3.12/site-packages (from pydantic~=2.1->ga4gh.vrs==2.0.0a5->ga4gh.vrs[extras]==2.0.0a5->-r requirements.txt (line 1)) (2.16.3)
Requirement already satisfied: typing-extensions>=4.6.1 in ./venv/lib/python3.12/site-packages (from pydantic~=2.1->ga4gh.vrs==2.0.0a5->ga4gh.vrs[extras]==2.0.0a5->-r requirements.txt (line 1)) (4.10.0)
Requirement already satisfied: sqlparse in ./venv/lib/python3.12/site-packages (from yoyo-migrations~=8.2->biocommons.seqrepo->-r requirements.txt (line 3)) (0.4.4)
Requirement already satisfied: tabulate in ./venv/lib/python3.12/site-packages (from yoyo-migrations~=8.2->biocommons.seqrepo->-r requirements.txt (line 3)) (0.9.0)
Requirement already satisfied: importlib-metadata>=3.6.0 in ./venv/lib/python3.12/site-packages (from yoyo-migrations~=8.2->biocommons.seqrepo->-r requirements.txt (line 3)) (7.0.2)
Requirement already satisfied: soupsieve>1.2 in ./venv/lib/python3.12/site-packages (from beautifulsoup4->google->-r requirements.txt (line 7)) (2.5)
Requirement already satisfied: zipp>=0.5 in ./venv/lib/python3.12/site-packages (from importlib-metadata>=3.6.0->yoyo-migrations~=8.2->biocommons.seqrepo->-r requirements.txt (line 3)) (3.17.0)
Requirement already satisfied: parso<0.9.0,>=0.8.3 in ./venv/lib/python3.12/site-packages (from jedi>=0.16->ipython~=8.4->biocommons.seqrepo->-r requirements.txt (line 3)) (0.8.3)
Requirement already satisfied: ptyprocess>=0.5 in ./venv/lib/python3.12/site-packages (from pexpect>4.3->ipython~=8.4->biocommons.seqrepo->-r requirements.txt (line 3)) (0.7.0)
Requirement already satisfied: wcwidth in ./venv/lib/python3.12/site-packages (from prompt-toolkit<3.1.0,>=3.0.41->ipython~=8.4->biocommons.seqrepo->-r requirements.txt (line 3)) (0.2.13)
Requirement already satisfied: pyasn1<0.6.0,>=0.4.6 in ./venv/lib/python3.12/site-packages (from pyasn1-modules>=0.2.1->google-auth<3.0dev,>=2.26.1->google-cloud-storage->-r requirements.txt (line 11)) (0.5.1)
Requirement already satisfied: executing>=1.2.0 in ./venv/lib/python3.12/site-packages (from stack-data->ipython~=8.4->biocommons.seqrepo->-r requirements.txt (line 3)) (2.0.1)
Requirement already satisfied: asttokens>=2.1.0 in ./venv/lib/python3.12/site-packages (from stack-data->ipython~=8.4->biocommons.seqrepo->-r requirements.txt (line 3)) (2.4.1)
Requirement already satisfied: pure-eval in ./venv/lib/python3.12/site-packages (from stack-data->ipython~=8.4->biocommons.seqrepo->-r requirements.txt (line 3)) (0.2.2)
mkdir: /Users/wongq/seqrepo: File exists
WARNING:biocommons.seqrepo.cli:2024-02-20: instance already exists; skipping
bcftools already installed, not installing

let me know if I'm missing something

add documentation about adding postgresql for Linux (psql) or otherwise
also add to setup script python < 3.12 setup:
if running-on-terra and python-version < 3.12:
  install pyenv
  install 3.12 on pyenv
  update .bashrc
# continue with setup

# install pyenv
curl https://pyenv.run/ | bash

# setup your path
cat ~/.bashrc
>>> export PYENV_ROOT="$HOME/.pyenv"
>>> [[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH"

source  ~/.bashrc

# confirm installation ok
pyenv versions

# install 3.12
pyenv install 3.12

# update 3.12 for our project
cd  /home/jupyter/vrs-python-testing
pyenv local 3.12

# re-create vent
rm -r vent

# setup venv …. pip install ….


Upgrade blueprint benchmark template

I refactored some code and due to https://github.com/sbsoftware/to_html.cr/pull/16 I noticed that HTML.escape slow down the rendering, so I made available a version to those who controls the content being rendered and want to focus on performance. And some refactoring improved the safe blueprint too, from ~9x to ~5x, I think it was the reuse of the same buffer to build element attributes instead creating a new one for each element.
          ecr   3.45M (289.48ns) (± 1.51%)  4.27kB/op        fastest
      to_html   1.88M (533.03ns) (± 1.62%)  5.52kB/op   1.84× slower
raw blueprint   1.07M (938.61ns) (± 0.90%)   4.9kB/op   3.24× slower
    blueprint 628.81k (  1.59µs) (± 1.27%)   4.9kB/op   5.49× slower
 html_builder 117.60k (  8.50µs) (± 2.56%)  10.4kB/op  29.37× slower
        water 114.54k (  8.73µs) (± 0.68%)  11.2kB/op  30.16× slower
      markout  89.33k ( 11.19µs) (± 0.96%)  15.6kB/op  38.67× slower

Hey @stephannv, I'd rather avoid having multiple variants of the same shard in this benchmark. I think it would be enough to include the raw version only - so far, to_html.cr does no escaping either, so comparing it to the variant of blueprint featuring it seems unfair anyway. Maybe we can add a second benchmark at some point which will include more features. What do you think?

I think it's fair. But if you want to keep only one, I prefer the Blueprint::HTML, but it's up to you to decide.
I opened a PR to html_builder, improving its performance, it went from ~29x to ~5x.
                           ecr   3.42M (292.20ns) (± 1.63%)  4.27kB/op        fastest
            html_builder (New) 664.95k (  1.50µs) (± 2.18%)  8.39kB/op   5.15× slower
        html_builder (Current) 118.40k (  8.45µs) (± 0.74%)  10.4kB/op  28.90× slower

So I think it makes sense to close this PR and let you upgrade the dependencies when you think it best to do so, so you can upgrade multiple libs and update the benchmark result.

I'll keep the one you prefer for now then. At some point in the future I might very well implement some form of escaping for to_html.cr, too, and then I will decide how to handle the different cases in the benchmark.


fix(deps): pin colors package to 1.4.0 due to security vulnerability

Another one, hopefully contains all required changes :weary:
Pin colors package to 1.4.0 version due to security vulnerability. See details:

1.4.0...1.4.2 diff
https://github.com/Marak/colors.js/issues/285
https://www.theverge.com/2022/1/9/22874949/developer-corrupts-open-source-libraries-projects-affected
https://www.bleepingcomputer.com/news/security/dev-corrupts-npm-libs-colors-and-faker-breaking-thousands-of-apps/

is it possible if we set in config color:false don't load/require the color to avoid similar issue in the future?

is it possible if we set in config color:false don't load/require the color to avoid similar issue in the future?

I'd rather replace colors with another package (e.g. chalk) in the long run.

Would be great if you would merge this - if only as a temporary workaround - as it's likely affecting MANY users worldwide ;-)
Happy for you to use an alternative, but delays cost lots of hair pulling.

Here is an interim solution https://github.com/nrwl/nx/issues/8450#issuecomment-1008759313 !

Update: NPM has pulled versions 1.4.2 and 1.4.1. Installing the latest colors version will give you 1.4.0. This means that the problem is solved for karma users today, but this PR should still be merged IMO, for the karma users of tomorrow. (and later be replaced with a package that has a responsible maintainer)

@sergei-startsev please fix the CI tests :)

@sergei-startsev please fix the CI tests :)

Sorry, I just realized that CI will turn green after https://github.com/karma-runner/karma/pull/3742 is merged. Let's just wait for that.

closes #3740

Thank you


Allow building device paths as constants

Splitting this off from https://github.com/rust-osdev/uefi-rs/issues/970.

It would be nice to be able to build device paths as global constants as well. This would sidestep the use-after-free issues from nix-community/lanzaboote#194.

Originally posted by @blitz in https://github.com/rust-osdev/uefi-rs/issues/970#issuecomment-1775618414

I took a look at this, and I think it would be quite difficult to do right now with const types and functions. Many of the tools we want are available in unstable Rust, but it may be a while before it becomes straightforward to do in stable Rust. A couple specific things:

There's no way to call trait methods from const fns (you can't make a const trait, or declare methods in a trait const, or create a const impl of a trait). So the current BuildNode interface wouldn't work at all. There is a fairly straightforward workaround for this one, albeit not super ergonomic: we could generate a big BuildNode enum containing all the node types.
Mutable references are not allowed in const fns. Mutable pointers are, but you can't do much with them; writing and dereferencing are not allowed. So that means you can't pass a byte buffer into a const fn and write to it. The alternative here is to create the byte buffer within the const fn and return it. That works, but copying in the data gets pretty gnarly. You can't use copy_from_slice or anything like that. You could copy the bytes one at a time in a loop, but you can't even use a for loop in a const fn, so it all has to be done very manually and verbosely.

Given the difficulties, and the fact that this will (probably) get easier in the future as more things get stabilized, and the fact that I suspect fully const/static device paths are rare, I recommend we not try to add a const device path builder yet. Some potential alternatives for projects that want this:

Generate the device path in build.rs. You can add uefi-rs as a build dependency and use the regular DevicePathBuilder to create a path, then call as_bytes to get the raw bytes. Write those raw bytes out to a file and include_bytes! in your source. Or generate a bit of Rust code containing the raw bytes and include! that.
Hardcode the raw bytes in the static, then have a unit test that creates the same path with DevicePathBuilder. Compare the byte slices and make sure they match.

Lastly, it's totally possible I missed something in my exploration of what const fns can do, and maybe it's not actually as hard to add a const device path builder as I think -- happy to hear if I missed anything!

The approach with build.rs might be a good solution. That's a good idea.


chore: update styling of homepage on small devices

Related Issue
Closes #1899
Description

Mentioned in the Issue description (just styling update)

Screenshots

Please don't merge PRs that change structure, otherwise it will create merge conflicts.
Let me know if there are any changes required.


Handle partial attributes factory for child factories.

Hi, this PR aims to solve the issue #50.
Given the following Pydantic models and Factory:
from pydantic_factories import ModelFactory
from pydantic import BaseModel

class Pet(BaseModel):
    name: str
    age: int

class Person(BaseModel):
    name: str
    pets: list[Pet]
    age: int

class PersonFactory(ModelFactory[Person]):
    __model__ = Person

When trying to build:
data = {
    'name': 'John',
    'pets': [
        {'name': 'dog'},
        {'name': 'cat'},
    ],
}

PersonFactory.build(**data)

Then the following exception is raised:
ValidationError: 2 validation errors for Person
pets -> 0 -> age
  field required (type=value_error.missing)
pets -> 1 -> age
  field required (type=value_error.missing)

We see that the age is missing in the data, so the factory is not able to construct the model.
If we add the age to the data:
data = {
    'name': 'John',
    'pets': [
        {'name': 'dog', 'age': 3},
        {'name': 'cat', 'age': 4},
    ],
}

PersonFactory.build(**data)

The factory will construct the model instance:
Person(name='John', pets=[Pet(name='dog', age=3), Pet(name='cat', age=4)], age=5978)

Note: only the age of the Pets (child model) is necessary, ModelFactory handles to randomly fill the age of Person.
It would be great to have the same behaviour of Factory Boy. If we pass only part of the attributes of a child model, then the factory will generate the missing attributes for us.

With the modifications of this PR we now have:
class PersonFactory(ModelFactory[Person]):
    __model__ = Person

data = {
    'name': 'John',
    'pets': [
        {'name': 'dog'},
        {'name': 'cat'},
    ],
}

person = PersonFactory.build(**data)

print(person.json(indent=4))

Result:
{
    "name": "John",
    "pets": [
        {
            "name": "dog",
            "age": 9005
        },
        {
            "name": "cat",
            "age": 2455
        }
    ],
    "age": 975
}

Looks very good. Please update the readme and changelog.

Thank you!
Readme and changeling updated.


Nextcord does not work with discord-ui

Hey, I tried today to rewrite my Discord bot to Nextcord but somehow I can't because discord-ui requires discord.py and the lib of Discord-UI doesn't support Nextcord, is there any way to fix this?
Before the question comes up, I am using discord-ui version 5.1.5

discord-ui should work together with nextcord, do you have an exception or something for me?

I can't because discord-ui requires discord.py

what exaclty do you mean by that? if you mean the imports, discord-ui uses the discord module which will be replaced by nextcord during the installation

And discord.py is not installed there

can you try to reinstall nextcord?

reinstall both?

Did it, now it works. Thank you!


Add containerd+CRI ideas

This idea was originally added by @thockin in doc
Now it's missing, and I hope to add it back.

Hey @resouer just issue a pull request.
Make sure the idea has a mentor + link to github issue + desc

Sure, thank you for reminding!


Different solutions to equivalent optimization problems

For two equivalent optimization problems, two different solutions are provided by the find_local_max_ipopt function. Is this expected behavior?
When using the find_local_max_ipopt funciton to find the optimal input for the experiments, I can describe the constraints in multiple equivalent ways. Let D(x) be the D-Optimal-Criterium.
 \begin{aligned}
	  \text{minimize} \  D(x) \\
	  s.t. \\

	  0 \leq x_1 \leq 5 \\
	  0 \leq x_2 \leq 15 \\
	  1 \leq x_3 \leq 1 \\
	  \\
	  x_1 + 0.2 * x_2 + 0 * x_3 \leq 5 \\
	  x_1 - x_2 + 0 * x_3 \leq 5 \\
	  \\
	  \Leftrightarrow \\
	  \\
	  \text{minimize} \ D(x)\\
	  s.t. \\

	  0 \leq x_1 \leq 5 \\
	  0 \leq x_2 \leq 15 \\
	  1 \leq x_3 \leq 1 \\
	  \\
	  x_1 + 0.2 * x_2 + 100 * x_3 \leq 105 \\
	  x_1 - x_2 + 100 * x_3 \leq 105\\
  \end{aligned}

As $x_3$ is bound to exactly 1 both optimization problems should have the same solution. Writing this in code results in:
from bofire.data_models.constraints.api import LinearInequalityConstraint
from bofire.data_models.domain.api import Domain
from bofire.data_models.features.api import (
    ContinuousInput,
    ContinuousOutput,
)
from bofire.strategies.doe.design import find_local_max_ipopt
import numpy as np
import torch
import random

torch.manual_seed(0)

domain = Domain(
        inputs=[
            ContinuousInput(key="x1", bounds=(0, 5)),
            ContinuousInput(key="x2", bounds=(0, 15)),
            ContinuousInput(key="x3", bounds=(1, 1)),
        ],
        outputs=[ContinuousOutput(key="y")],
        constraints=[
            LinearInequalityConstraint(features=["x1", "x2", "x3"], coefficients=[1, 0.2, 0], rhs=5),
            LinearInequalityConstraint(features=["x1", "x2", "x3"], coefficients=[1, -1, 0], rhs=5),
        ],
    )

result = find_local_max_ipopt(
    domain, "linear", n_experiments=3, ipopt_options={"disp": 0}
)
print(result)

This returns:
                x1            x2   x3
exp0 -7.099351e-09  1.716973e-09  1.0
exp1  5.000000e+00 -1.515150e-09  1.0
exp2  8.313947e-01  1.500000e+01  1.0

When changing the linear inequality constraints to
LinearInequalityConstraint(features=["x1", "x2", "x3"], coefficients=[1, 0.2, 100], rhs=105),
LinearInequalityConstraint(features=["x1", "x2", "x3"], coefficients=[1, -1, 100], rhs=105),

The result is:
                x1            x2   x3
exp0 -8.784069e-09 -6.152546e-09  1.0
exp1  5.000000e+00 -9.999960e-09  1.0
exp2  2.605568e-01  1.500000e+01  1.0

Here, x1 in exp2 differs from the value it had in the previous minimization problem. Its value is now around 0.26 where it was at 0.83 before.

Hi @ufukguenes,
thanks for pointing this out! I can reproduce your output. The only difference between both constraint sets you used is the gradient with respect to x3. As far as I know IPOPT takes variables with lower_bound == upper_bound out of the optimization process, so in principle the gradient with respect to x3 should not be relevant. However, you can see in the implementation of theLinearConstraint class that a linear constraint is normalized with the norm of the coefficient vector.
def __call__(self, experiments: pd.DataFrame) -> pd.Series:
        return (
            experiments[self.features] @ self.coefficients - self.rhs
        ) / np.linalg.norm(self.coefficients)

My assumption is that this leads to small numerical differences which lead IPOPT to find different local optima (the D-optimality is the same for both design). Does this sound plausible to you?  Since both optima seem to be equivalent w.r.t D-optimality, the issue you pointed out is not too worrying for me, do you agree?
cheers
Aaron :)


Add missing brace to message_connection_status

This will fix #64, though should it be back-ported to any branch/tag that gets rendered on gh-pages, as it will break the schema resolving?

Oh wow, I'm sorry!!


Specify image repo URL explicitly

This fix supplies domain for container image repo because
in some runtime configuration, 'docker.io' is not specified as
default container repository url.

Pull Request Test Coverage Report for Build 232187697

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 70.997%

Totals

Change from base Build 216836786:
0.0%

Covered Lines:
1082

Relevant Lines:
1524

💛  - Coveralls


Polar plot for forced response analysis

The Bode plot (amplitude and phase) should provide an option to be shown in its Polar form.
In cases for which the excitation does not clearly excites a certain critical speed, the polar form of the Bode Plot can be very helpful to identify the critical speed passing.

When plotting unbalance response or frequency response, it'll be returned this format:

Perfect!
The example shown generates a weird polar plot because of the low damping of the first critical. But that's exactely what I had in mind. Thanks!


Multi-line and extended delimiter literal lexing

Update the delimiter lexing logic to handle /.../, an extended variant that allows an arbitrary number of balanced pounds, e.g ##/.../##, and a multi-line mode when the extended variant starts with a newline. The multi-line mode uses extended regex syntax by default, allowing for non-semantic whitespace and end-of-line comments.
Additionally, disable the #|...|#, re'...', and rx'...' spellings for now.

@swift-ci please test

Given this patch allows the lexing of /.../, we can actually update https://github.com/apple/swift/pull/42119 to lex using that logic (though the heuristics remain on the compiler side for now).


Future of blocked property for usecase in list/tree

OpenUI5 version: 1.69+
Depending on your strategy this is a consulting or feature request issue. With version 1.69 the blocked property of sap.ui.core.Control has been marked deprecated due to accessibility reasons with the example of a list control.
I'm missing an explanation what your strategy or other solution is.
To be more concrete I have the need to disable a list or tree entry as long as some asynchronous server side logic is running. Are you introducing the enabled property on list/tree items in a way that a user can navigate over these entries without being able to select or trigger press or tap?
Or is it totally fine to continue using the blocked property but being aware of the accessibility drawbacks?

Hi @mkueng1, thanks again for your input. We understand the difficulties in some scenarios to fulfill all expectations for blocked handling and thorough accessibility. As had been explained, the given functionality can not always cover both. But good to hear that with loosening the a11y aspect you could achieve the desired result. As we don't have specific plans to further address the topic, we'll close this issue. Thanks + BR, Andreas


feat(card) - box-shadow fix

https://kontur.fibery.io/Tasks/Task/Fix-shadow-from-Analytics-panel-13478
solution idea - fix  box-shadow, not to change z-index to prevent affection of box-shadow.
existing box-shadow
0 1px 2px rgba(0, 0, 0, 0.3), 0 16px 24px rgba(0, 0, 0, 0.06), 0 2px 6px rgba(0, 0, 0, 0.04), 0 0 1px rgba(0, 0, 0, 0.04);
final
0 1px 2px rgba(0, 0, 0, 0.3), 0 2px 6px rgba(0, 0, 0, 0.04), 0 0 1px rgba(0, 0, 0, 0.04);
so I just get rid of this section 0 16px 24px rgba(0, 0, 0, 0.06), that affected bottom panel
Screenshots: (pay attention on the middle panel, it's top part got darkened because of top panel shadows)
before

after

Since it design change (less smooth shadow) need review from designers.
From code perspective - why not fix --elevation-1 value instead?

Since it design change (less smooth shadow) need review from designers. From code perspective - why not fix --elevation-1 value instead?

From code perspective - why not fix --elevation-1 value instead?

it's a variable used in a lot of places in ui-kit and in DN FE directly, it's a risk of unexpected changes.
To do it need to recheck all the affected places.

Since shadows is part of theming it better to keep into variables

why not create another variable like elevation-2?

@Akiyamka @IlyaIzr
we already have variables elevation-1/2/3, but I've found out that we have shadows defined in our figma
https://www.figma.com/file/C2TlBs45hTL0U5pqZl2n9d/Kontur-Design-System?node-id=8553%3A38440&t=Xz7jO92lwiME0iYZ-0
and it's different shadows!
So I've added these new ones, old ones marked as deprecated.
--shadow-medium is used for panels and because of blur reduced it won't overlap bottom panel (designers updated blur value)


Deployment using Buddy

This change adds the article about how to deploy Eleventy using Buddy CI/CD

Thank you!


Could not call remote function ``

According to TrackJS, this error happened on Windows 8.1 when clicking "Burn" when a burn was already in process (around ~30%).
Could not call remote function ``. Check that the function signature is correct. Underlying error: Error processing argument -1.
Error: Could not call remote function ``. Check that the function signature is correct. Underlying error: Error processing argument -1.
    at callFunction (C:\Users\Alexandros\resin-etcher\node_modules\electron-prebuilt\dist\resources\atom.asar\browser\lib\rpc-server.js:203:11)
    at EventEmitter.<anonymous> (C:\Users\Alexandros\resin-etcher\node_modules\electron-prebuilt\dist\resources\atom.asar\browser\lib\rpc-server.js:293:12)
    at emitMany (events.js:108:13)
    at EventEmitter.emit (events.js:182:7)
    at EventEmitter.<anonymous> (C:\Users\Alexandros\resin-etcher\node_modules\electron-prebuilt\dist\resources\atom.asar\browser\api\lib\web-contents.js:129:25)
    at emitTwo (events.js:87:13)
    at EventEmitter.emit (events.js:172:7)

I can't reproduce in OS X, so it looks like a Windows specific one.

Our assumption seems to be incorrect. The burn button is completely un-clickable once the burn starts. The fact that the error mentions a "remote function" makes me think it was a one time IPC error on Electron itself.
I'll keep the issue around for some more time before closing it, in case it happens again.

Closing since it doesn't seems to be happening anymore.

I got this error trying to make a bootable usb out of Windows_NTFS
Sun Jun 19 2016 21:11:13 GMT+0500 (YEKT) Flash ({"image":"/Users/agapov/Downloads/Windows.10/Windows 10.iso","device":"/dev/disk2"})
Sun Jun 19 2016 21:11:13 GMT+0500 (YEKT) Forking: /Applications/Etcher.app/Contents/Resources/app.asar /Users/agapov/Downloads/Windows.10/Windows 10.iso --drive /dev/disk2 --ipc --unmount --check
Sun Jun 19 2016 21:11:15 GMT+0500 (YEKT) Flash error
Error: Could not call remote function ''. Check that the function signature is correct. Underlying error: Error processing argument at index 0, conversion failure from
Error: Could not call remote function ''. Check that the function signature is correct. Underlying error: Error processing argument at index 0, conversion failure from
    at callFunction (/Applications/Etcher.app/Contents/Resources/electron.asar/browser/rpc-server.js:218:11)
    at EventEmitter.<anonymous> (/Applications/Etcher.app/Contents/Resources/electron.asar/browser/rpc-server.js:299:5)
    at emitMany (events.js:127:13)
    at EventEmitter.emit (events.js:201:7)
    at EventEmitter.<anonymous> (/Applications/Etcher.app/Contents/Resources/electron.asar/browser/api/web-contents.js:139:25)
    at emitTwo (events.js:106:13)
    at EventEmitter.emit (events.js:191:7)
    at metaToValue (/Applications/Etcher.app/Contents/Resources/electron.asar/renderer/api/remote.js:176:13)
    at Object.remoteMemberFunction (/Applications/Etcher.app/Contents/Resources/electron.asar/renderer/api/remote.js:110:18)
    at showError (/Applications/Etcher.app/Contents/Resources/app.asar/lib/gui/os/dialog/services/dialog.js:97:28)
    at file:///Applications/Etcher.app/Contents/Resources/app.asar/lib/gui/app.js:300:23
    at processQueue (/Applications/Etcher.app/Contents/Resources/app.asar/node_modules/angular/angular.js:16170:28)
    at /Applications/Etcher.app/Contents/Resources/app.asar/node_modules/angular/angular.js:16186:27
    at Scope.$eval (/Applications/Etcher.app/Contents/Resources/app.asar/node_modules/angular/angular.js:17444:28)
    at Scope.$digest (/Applications/Etcher.app/Contents/Resources/app.asar/node_modules/angular/angular.js:17257:31)
    at /Applications/Etcher.app/Contents/Resources/app.asar/node_modules/angular/angular.js:17483:26
    at completeOutstandingRequest (/Applications/Etcher.app/Contents/Resources/app.asar/node_modules/angular/angular.js:5955:10)
    at /Applications/Etcher.app/Contents/Resources/app.asar/node_modules/angular/angular.js:6234:7
    at d.util.hasFunction.f.(anonymous function) (file:///Applications/Etcher.app/Contents/Resources/app.asar/node_modules/trackjs/tracker.js:3:492) undefined

Hi @Leshich ,
Thanks for reporting this.

In conclusion, it would be nice to have some kind of alert or info message, that NTFS USB won't work and I have to make it FAT32 myself (using Disk Utility).

I don't think this is the root cause of the problem. Etcher doesn't care about the drive format since it access the raw disk and blindly writes bytes to it, so it must be something else.
In any case, I've tried flashing to an NTFS drive but as I expected I was not able to reproduce the issue.
Can you actively reproduce when formatting as NTFS?
What Etcher version are you running BTW?

So after some investigation, turns out Electron throws this error when you call a native function of the main process from the renderer process with the wrong arguments.
According to your stack trace, you get an error during the flash process the gets passed to OSDialogService.showError() from lib/gui/app.js:
// See https://github.com/resin-io/etcher/blob/v1.0.0-beta.8/lib/gui/app.js#L291
.catch(function(error) {

      if (error.type === 'check') {
        AnalyticsService.logEvent('Validation error');
      } else {
        AnalyticsService.logEvent('Flash error');
      }

      self.writer.resetState();
      OSDialogService.showError(error);
    })

OSDialogService.showError() calls electron.remote.dialog.showErrorBox(), a native function from the main process. According to the error, there is a conversion issue with the first parameter, the error title, which is computed like this:
const title = error.message || error.code || 'An error ocurred';

The conversion hint makes me thing that either error.message or error.code (most probably this one) is a number, and not a string.
This issue is obscuring the real bug. I'll submit a PR to make sure title is a string as a way to prevent these from happening in the future, but I'd be amazing if you can manage to reproduce the error, so we can hopefully get to the bottom it.
Please let me know if you do have a way to reliably trigger this error and I'll send a custom build to you containing extra debugging information.
Thank you very much again and let me know how it goes!

This error has been fixed in https://github.com/resin-io/etcher/pull/497. This of course doesn't solve the root problem you're facing, but Could not call remote function, will disappear, giving you the real error you're facing instead, which should be reported as a separate issue.


Change_dependencies feedback

Due to the complexity of supporting both HTTP and HttpServer, we liberally merge PRs to this branch for easier experimentation. There's also issue #84, but that doesn't need to be cluttered with 'caps and tabs' details.
'Code review' and TO DO comments go here.
I'm working on a file-by-file list, but this is the most core. On branches HTTP/master and Websockets/Change_dependencies.
julia> begin
           using HTTP
           using WebSockets
           port = 8000
           @async HTTP.listen("<IP_ADDRESS>",UInt16(port)) do http
                  if WebSockets.is_upgrade(http.message)
                      WebSockets.upgrade(http) do ws
                          while ws.state == WebSockets.CONNECTED
                              msg = String(read(ws))
                              println("Echoing $msg") # Write the received message to the REPL
                              write(ws,msg)
                          end
                      end
                  end
            end
            sleep(2)
            WebSockets.open("ws://<IP_ADDRESS>:$(port)") do ws
                   write(ws, "Foo")
                   write(ws, "Bar")
                   println("Got back ", String(read(ws)) )
                   println("Got back ", String(read(ws)))
                   close(ws)
           end
       end
I- Listening on: <IP_ADDRESS>:8000
I- Accept:  🔗    0↑     0↓    <IP_ADDRESS>:8000:8000 ≣16
Echoing Foo
Got back Foo
Echoing Bar
Got back Bar
INFO: Server received OPCODE_CLOSE
Echoing
HTTP.MessagesE- .Error:   💀    1↑     1↓🔒   <IP_ADDRESS>:8000:8000 ≣16Response
:|
e = """read: connection reset by peer (ECONNRESET)

HTTP/1.1 101 Switching Protocols
|  Upgrade: websocket
catch_stacktrace() = Connection: Upgrade
StackFrame[]Sec-WebSocket-Accept: aWCLPwDjhD4k2F6In03w96kczvs=

I- """Closed:  💀    1↑     1↓🔒   <IP_ADDRESS>:8000:8000 ≣16

Oh, I forgot: @EricForgy.
As part of the review, and also as a kind of template for assisting in modifying the test suite, I added a more verbose / explicit chat example. I'll ask you to kindly review it when we make a PR for merging the branch.
It contains an alternative approach to doing without IDs. It also does away with JSON (which is very slow, this will improve with JSON2 and Julia 0.7). The slowness doesn't matter in the example.
The motivation is otherwise listed at the top of chat_explore.jl
Occasionaly I still manage to get untrappable errors from HttpServer. WebSockets is not part of the stack trace. I will report here if I manage to provoke it again; it would be lovely if we could modify HttpServer to trap the so-called errors.
Next step for me will be to extend chat_explore.jl  with a simultaneous HTTP port server. Then provide show(io, STDOUT) for the types defined here.

I am super happy @samoconnor found the problem with the for loops and this PR reflects the fix: https://github.com/JuliaWeb/WebSockets.jl/pull/92 😊

It should be much easier to write tests now and ultimately do some benchmarking / comparisons with HTTP.WebSockets. I'm super optimistic about the outcome of all this 👍

My current understanding is this: We're always working on a single thread of execution. In normal code, we don't expect our tasks to be interrupted except when we sleep() or yield(). But when we're reacting to events like sockets opening or closing, the new tasks take immediate control. When e.g. a browser closes all of its tabs or we're restarting a server with several open tabs, all the tasks are just barely able to start before they're interrupted by the next close or open event. Browsers open lots of sockets very quickly, even when we're just typing in urls.
So assigning place for a socket in a collection, and THEN putting in the reference to it is bound to cause trouble. That's one reason why httpserver sometimes just fails while opening sockets.
Not a computer guy, but this is what I think is good practice just now: If we can't update our immutable collections in just one line, we shouldn't do it at all.
In other words,
push!(COLLECTION, client)

is fine. Other solutions cause random pain. Even HttpServer ought to be updated if I'm understanding this right. Still learning, though.

Ref. WebSockets/HTTP.jl:33-37 and 58-61.
        try
            f(ws)
        finally
            close(ws)
        end

We are not giving the user the opportunity to write his own gatekeeper / selector functions, for example based on header "Sec-WebSocket-Protocol". This could be achieved by also accepting two- or three-argument f. For example:
f(ws)
f(ws, http)
f(ws, http, binary)
f(ws, subprotocol)

We could of course put gatekeeper/ selector function in before handshakes, when we still have access to argument 'http::HTTP.Stream', but couldn't that potentially be unsafe? I think it's easier and cleaner to do this after a handshake and upgrade.
But how to find out which arguments f take? I don't know any way to dispatch elegantly on the number of arguments that argument 'f' take. Would you approve of a pull request based on something like this? Or something of the sort?
  upgrade_ws(f::Function, http::HTTP.Stream; binary=false)
  upgrade_ws_http(f::Function, http::HTTP.Stream; binary=false)
  upgrade_ws_http_binary(f::Function, http::HTTP.Stream; binary=false)

new tasks take immediate control [...] tasks are just barely able to start before they're interrupted ...

I don't think its quite right to thing about tasks being interrupted or other tasks taking control. Tasks are not interrupted or preempted by other tasks. The only way an inactive task ever gets to run is if an active task calls wait(). Inside wait() the runtime runs scheduled tasks in a loop and/or calls process_events(). Inside process_events() libuv checks all the currently active files/sockets/pipes for activity and runs IO callbacks.
So, if you have a task that never calls wait() no other task will run.
The places that wait() is called include: sleep, yield and any place that an IO operation has to wait for the network, disk access etc.
The key thing to realise is that the task "scheduler" is not an all-powerful omnipresent entity that lives in a parallel dimension (a thread scheduler is like that). The task "scheduler" is just an ordinary Julia function that has to be explicitly called by another Julia function.
The "scheduler" is the wait() function: https://github.com/JuliaLang/julia/blob/master/base/event.jl#L255
function wait()
    while true
        if isempty(Workqueue)
            c = process_events(true)
            if c == 0 && eventloop() != C_NULL && isempty(Workqueue)
                # if there are no active handles and no runnable tasks, just
                # wait for signals.
                pause()
            end
        else
            reftask = poptask()
            if reftask !== nothing
                result = try_yieldto(ensure_rescheduled, reftask)
                process_events(false)
                # return when we come out of the queue
                return result
            end
        end
    end
    # unreachable
end

... gatekeeper / selector functions, for example based on header "Sec-WebSocket-Protocol"

You could add a request::HTTP.Request field to struct Websocket and then define:
header(ws::WebSocket, k, d="") = header(ws.request, k, d)
hasheader(ws::WebSocket, k) = hasheader(ws.request, k)

That would give the f(ws) code easy access to the request headers.

Re dispatching based on different function signatures in a do function:
HTTP.Servers.handle_stream has an example of this using applicable(f, ...):
function handle_stream(f::Function, http::Stream)

    try
        if applicable(f, http)
            f(http)
        else
            handle_request(f, http)
        end
    catch e
        ...
    end

    closeread(http)
    closewrite(http)
    return
end

A neater and more backwards-compatible style could be achieved by also accepting two- or three-argument f. For example:

f(ws)
f(ws, http)
f(ws, http, binary)
f(ws, subprotocol)

I have some ideas to make this clean for users. Will try some things out and report back 😊

I think we are close to having WebSockets.jl in shape to work as a server with both HTTP and HttpServer and as a client with HTTP. Once we have a more complete / robust set of tests, then I would suggest comparing / contrasting WebSockets.WebSocket and HTTP.WebSockets.WebSocket more deeply and consider revising the WebSocket type accordingly. For example, the String bytes issue together with the expected performance enhancements, I am liking @samoconnor's txpayload and rxpayload. HTTP.WebSockets was immune to the for loop String bytes issue. On the offer hand, I like the three states ( CONNECTED, CLOSING and CLOSED) of WebSockets.WebSocket.
My wish is that a single WebSockets module will emerge from this that we're all happy with 🙏

Sam, thank you for taking the time to correct my bad! It's so easy to construct wrong explanations, and hard to get out of it without help.
The example below shows you're right and also shows me how I can debug some other code. It also demonstrates some seeming randomness in Julia's behaviour that I saw in the initial browser tests. This has to do with compiling, and starts to produce consistent output the the third run of the begin-end block. The first run may not print anything at all.
const CLOSEAFTER = Base.Dates.Microsecond(1)
function gg()
           print("|", "|")
           print("|", "|")
       end
function ff()
           print("-", "-")
           print("-", "-")
       end
begin
         t0 = now()
        while now() - t0 < CLOSEAFTER
        @async ff()
        @async gg()
    end
end

So for consistent message reception, perhaps good practice is simply sending a couple of echo messages at each application start. And absolutely avoid @schedule and @async in loops. Increase CLOSEAFTER if you dare.

Eric, I'm sure you are right. With a small exception perhaps. Some of the symbols used for logging status in HTTP are not displayable in Windows. They work fine in cygwin, but are not covered by the Dejavu Sans Mono, which is the best we have in Atom, REPL or VSCode editors.
You are wisely not choosing now at once between the two suggested approaches: a) Extend Websocket, b) Extend the function (s).
I implemented the function approach with Sam's suggestion by overwriting the update function. chat_explore.jl
The example is now serving chat_explore.html on BOTH dependencies. HTTP fans can open localhost 8080, and the old guys can open 8000.
Currently, I'm trying to share the websocket handler and get this message, which I can't interpret today.
julia> include("chat_explore.jl")
INFO: Loading HTTP methods...
INFO: Loading HttpServer methods...
Chat server listening on 8000
INFO: Start HTTP server on port 8080
Listening on <IP_ADDRESS>:8000...

I- Listening on: <IP_ADDRESS>:8080
julia> Received: userName:fe
Tell everybody about fe
Received: fff
I- Accept:  🔗    0↑     0↓    <IP_ADDRESS>:8080:8080 ≣16
I- Accept:  🔗    0↑     0↓    <IP_ADDRESS>:8080:8080 ≣16
I- Accept:  🔗    0↑     0↓    <IP_ADDRESS>:8080:8080 ≣16
I- Accept:  🔗    0↑     0↓    <IP_ADDRESS>:8080:8080 ≣16
I- Closed:  💀    1↑     1↓🔒   <IP_ADDRESS>:8080:8080 ≣16
I- Closed:  💀    1↑     1↓🔒   <IP_ADDRESS>:8080:8080 ≣16
I- Accept:  🔗    0↑     0↓    <IP_ADDRESS>:8080:8080 ≣16
E- MethodError(gatekeeper_newtype, (WebSockets.WebSocket{TCPSocket}(TCPSocket(Base.Libc.WindowsRawSo                              cket(Ptr{Void} @0xffffffffffffffff) closed, 0 bytes waiting), true, CLOSED::WebSockets.ReadyState =                               3),), 0x0000000000005583)
|  catch_stacktrace() = StackFrame[#upgrade#34(::Bool, ::Function, ::#gatekeeper_newtype, ::HTTP.Str                              eams.Stream{HTTP.Messages.Request,HTTP.ConnectionPool.Transaction{TCPSocket}}) at HTTP.jl:59, server                              _def_newtype at chat_explore.jl:271 [inlined], handle_stream(::#server_def_newtype, ::HTTP.Streams.S                              tream{HTTP.Messages.Request,HTTP.ConnectionPool.Transaction{TCPSocket}}) at Servers.jl:446, (::HTTP.                              Servers.##46#47{#server_def_newtype,HTTP.ConnectionPool.Transaction{TCPSocket},HTTP.Streams.Stream{H                              TTP.Messages.Request,HTTP.ConnectionPool.Transaction{TCPSocket}}})() at task.jl:335]
I- Closed:  💀    1↑     1↓🔒   <IP_ADDRESS>:8080:8080 ≣16
I- Closed:  💀    0↑     0↓🔒   <IP_ADDRESS>:8080:8080 ≣16 inactive 70.0s
I- Closed:  💀    0↑     0↓🔒   <IP_ADDRESS>:8080:8080 ≣16 inactive 70.0s

Some of the symbols used for logging status in HTTP are not displayable in Windows.

Menlo is a good programming font: https://github.com/hbin/top-programming-fonts

In your ff() gg() example you are doing console IO in the async code (println), this will lead to unpredictable task switching.

Sam, thanks for the font tip.
The unpredictable task switching doesnt seem to happen in this case because both functions take exactly the same time. But my initial logs were full of it.
I like the log style where you use symbols like skulls and chains. That comment about the font wasnt a good one. If it works out, lets put the font tip in readme.md and define similar show methods.

Installed the font, Sam. It's nice but those symbols still don't display in other than the mintty cygwin terminal. Example below.
Also updated the chat example. It's closing after one message, will fix. But it is now working for exploring types so we can find a good common interface.
Old-style websockets pass a HttpCommon.request to the gatekeeper function. The useful part is its request.headers field, which is a Dict{String, String} currently.
For HTTP origin websockets, the http.message.headers field ought to be sufficient info. The current example in chat_explore.jl doesn't make a Dict out of it.
The gatekeeper function can't do the subprotocol upgrade. This would be an easy addition to add to WebSockets/HTTP.jl, I think.
Main> I- Accept:  �    0↑     0↓    <IP_ADDRESS>:8080:8080 ≣16
I- Accept:  �    0↑     0↓    <IP_ADDRESS>:8080:8080 ≣16
I- Accept:  �    0↑     0↓    <IP_ADDRESS>:8080:8080 ≣16
I- Accept:  �    0↑     0↓    <IP_ADDRESS>:8080:8080 ≣16
I- Closed:  �    1↑     1↓�   <IP_ADDRESS>:8080:8080 ≣16
I- Closed:  �    1↑     1↓�   <IP_ADDRESS>:8080:8080 ≣16
Received: userName:HTTPfan@8080
Tell everybody about HTTPfan@8080
I- Closed:  �    0↑     0↓�   <IP_ADDRESS>:8080:8080 ≣16 inactive 26.2s
Received: userName:OldBoy@8000
Tell everybody about OldBoy@8000
Received: I like Mike
Closing connection with OldBoy@8000
Received: Shouldn't have said that, OldBoy!
Closing connection with HTTPfan@8080
I- Closed:  �    1↑     1↓�   <IP_ADDRESS>:8080:8080 ≣16 inactive 184.5s

True. Minor issue, but the cool symbols do no render in Windows 😊

Just an update / status.
I'm working on an efficient logging system, meaning that there should be practically no delay when logging to Base.DevNullStream. It's implemented in a private server package so far. Nothing to commit just yet.

chat_explore.html is modernized and simplified to my eyes. This will serve as a part template for rewriting socket tests. It is tempting to extend it with drag-n-drop for various file types, demonstrating binary sockets.
chat_explore.jl distinguishes between various error types and has an added close_from_outside() function. The aim with this file has moved towards a template for 'real' websocket server. I.e. one that runs all day without hazzle.

Base.show methods are still not added.
Need to check/ implement subprotocols for HTTP source websockets.
How much time this takes to finish depends on the local weather here. Eric, do you expect to make more contributions here?

Hi @hustf,
As far as I'm concerned, I'm happy with the current state of things. I expect some private packages might break, but active packages in METADATA seem unaffected.
I like the fact WebSockets now has almost no real dependencies so others can extend it easily.
I still think we need a shootout between WebSockets.jl and HTTP.WebSockets.jl which will liky lead to more changes to WebSockets.jl as the two converge, e.g. we may want to add payload vectors to eliminate the need for allocation, but that is second order and can probably done later.
Personally, I don't expect any significant changes any time soon 😊

Hi @hustf, @EricForgy,
I have some questions that maybe you can answer given your experience using WebSockets with real live browser and js framework implementations...

What's up with fragmentation and frames? The RFC says "Unless specified otherwise by an extension, frames have no semantic meaning". Do you have to think about frames in real world WebSockets apps? Are there any commonly used "extensions" that specify a meaning for frames? The read method goes to some effort (with efficiency cost) to collect all the fragments of a frame before returning. Is this an essential feature in real-world use?

https://github.com/JuliaWeb/WebSockets.jl/blob/bafb17567136b2111d73e97a681b42d363e1189a/src/WebSockets.jl#L348-L367

Is a WebSocket more like a Channel (a message stream) or an IO stream (a byte stream)? i.e. in real world apps, are you receiving odd chunks of bytes into a buffer, then checking for delimiters, complete JSONs, etc? Or do you always receive a nice complete chunk containing exactly one JSON message?

Do real world applications care about text-mode vs binary mode? or does everyone tend to use the same mode?

Sam,
at parties, people always talk about TCP and changing packet sizes. So it's tempting to pretend I know something. But I don't. Websockets are a layer on top of TCP, so the minimum buffer is a packet size. Frame sizes could be made to fit in a packet if you need ultimate responsiveness.  Last time I listened, there was a 64 KiB definite upper limit to packet size.
We'd like to support somebody using Julia to get rich on second-to-second trading, or somebody making RC cars that send intermittent bursts of sensor data. Data must be buffered on a frame-to-frame basis. The sensors wouldn't know the length of the message when they start sending.
Chrome obscures the difference between message and frame (check F12 / network / ws - there's no distinction). Perhaps it adapts based on the current network? So extended logs from our local browser tests wouldn't  give a definite answer.
Regarding binary, there's an example in the tests. Javascript don't get access to the binary array. It can make views into it, but it's job is really to just pass a reference to the lower-level part of the browser that actually does the job of displaying the picture (in Internet Explorer, we do process it). It's hard for us now to imagine how this, and the evolving subprotocol standard, can be applied. The libraries/ subprotocols I read up tries to hide this kind of detail from the front-end-developer ('just install our library on the server, try with our server first'). Is there any benefit to removing binary support?

at parties, people always talk about TCP

You should try to get invited to better parties 😂

Is there any benefit to removing binary support?

Not that I know of, it's more a matter of learning what are the most common real-world use cases in order to be able to reason about performance tradeoffs.
It seems like there is a choice with messages and frames.

make the WebSockets.jl API message-based:
write(::WebSocket, message) and take!(::WebSocket) -> message, or...
make WebSockets.jl API frame based:
write(::WebSocket, frame, last=true) and readavailable(::WebSocket) -> frame

If we take option 2. and basically just ignore the concept of messages, there are some performance benefits (less state to deal with, don't have to buffer-up fragments before returning result).
This is an issue that only effects the receiving of data, and given that the main use case is Julia server receiving data from chrome/safari/ie, the questions become:

Is it more convenient to have API 1. or API 2.?
Are there degenerate performance cases for API 1. e.g. if the js code does send(Blob) for a huge file it wouldn't be good to buffer the whole message before returning.

Perhaps the answer is to provide take!(::WebSocket) -> message and readavailable(::WebSocket) -> frame and let the person writing the Julia server decide what suits them best.

Just two cents before heading into a day-long meeting...
WebSockets are for "web" (obviously 😃 ), so for WebSockets clients, I would look at the JavaScript API and for WebSockets servers, I would look at the Node API (which I would think is essentially the same?). We should not be too far off from the JS implementations I would think.

WebSockets were intended for "web", but WebSockets for Julia just could be the optimal choice for controlling hardware or calculation-heavy back-end. It's hard to beat node.js for the general web user.
Zmq defines some functions that you start diving into when meeting buffering problems. It would be nice to support API 2, but since it's clearly for highly optimized applications I suggest we only export message-based methods.

Just in case you guys see a solution: Would it be worth to optimize this little function for the logger? It's used in conjuction with a truncating function to show a little of the content in a Response. I don't really know when RegExp's are faster.
function _compact_format(s::String)
   				replace(s, "\r\n", "\n") |>
   				s-> replace(s, "\n\n", "\n") |>
   				s -> replace(s, "\t\t", "\t") |>
   				s -> replace(s, "\n\t", "\n") |>
   				s -> replace(s, "\n", "\n\t")
end

Just to let you know things are coming along. I'm working on adapting the specialized logger, which is quite time consuming. With the current pace, it may take yet another month before merging this branch, but again, dependent on local weather.

I am not concerned at all, but I am confused why a logger would hold up this PR. Isn't it two completely separate things? 😊

I admit to being in doubt here too, but I think we need to be thorough this time. A logger is already implemented in the test suite, but it uses globals for redirection of output (which allocates some memory at each call and affects speed for small messages).
Websockets is a very enabling technology so I hope we can reduce the effort for new users, and also make the test suite easier to maintain by including  the improved logger with show methods and @requires dependencies into the main code.
We also introduce a new and very enabling feature, but I am loath to go out and proudly recommend dropping zmq without having  more examples. Search discourse zmq for recent examples. Should we add links to eg Pages.jl?

... imported WebSockets.open, then modified 'open' ...

Importing HTTP.WebSockets.open into a module that relies on open being Base.open isn't right.  HTTP.WebSockets.open and Base.open are two different functions. If you want to define a new method of HTTP.WebSockets.open for some new parameter types, you can define it like this:
module MyModule
    HTTP.WebSockets.open(f::Function, x::Dict) = HTTP.WebSockets.open(f, x["url"])
end

What were the disadvantages that led you to take away the .id field?

It just smelled bad. It suggested unneeded coupling, poor separation of concerns, or leaky abstraction layering.
Wikipedia has some decent summaries of basic software engineering principles:
https://en.wikipedia.org/wiki/Code_smell
https://en.wikipedia.org/wiki/Separation_of_concerns
https://en.wikipedia.org/wiki/Coupling_(computer_programming)
https://en.wikipedia.org/wiki/Information_hiding
https://en.wikipedia.org/wiki/Software_design_pattern
https://en.wikipedia.org/wiki/Composition_over_inheritance
https://en.wikipedia.org/wiki/Abstraction_layer
https://en.wikipedia.org/wiki/Code_refactoring
https://en.wikipedia.org/wiki/Extensibility

Thanks for the reply, Sam. I appreciate those hand-picked links. Having read up on words, I may use some of them against you in future discussions!
You are right about importing HTTP.WebSockets.open into a module which relies on 'open' would be bad. But I didn't. My module relied on 'readdlm' with a file name as an argument. Which is accessible from any module. This type of errors used to occur much more often with Julia a couple of versions ago. People are getting more used to the code style which makes Julia actually work.
I don't know what is the best code style for making Julia actually work. One idea has been to export the functions expected to be used outside. The best documentation has sometimes been what you get when you type 'using Colors;whos(Colors)'.
HTTP follows a different style than that, which is OK. Another style idea is prefixing internal functions with underscore: WebSockets._checkupgrade(..) would be an example.
Thank also for the explanation about Websocket.id. Makes sense, and a bit more so after reading the wikipedia links.
I'll add another reason for keeping the number of fields down. It becomes very difficult to make type constructor when there's more than say four fields in a type. Long argument lists in general are a pain.

I just pushed some changes after testing with Firefox. This is just a preliminary, working version before implementing other changes:

optionalProtocol checking moving into WebSockets. A turned-down socket connection should receive some standardized response. No need for every user to learn that.
Changing the field names. Still open to discussion of course.

[29] (::HTTP.#kw##open)(...)
[30] #open#5(...) at C:\Users\F.julia\v0.6\Graphloop\src\instructions.jl:478
[31] #readdlm_auto#11(...) at .\datafmt.jl:134

If you have defined a method of HTTP.WebSockets.open, or HTTP.open and Base.readdlm has called it instead of Base.open that is a bug in Julia that should be reported here: https://github.com/JuliaLang/julia/issues

..but I dont see this as a bug at all. There is no reason to import HTTP.open normally.
Httpserver and the old websocket avoids this little trap by defining lots of ad hoc types like httphandler and websockethandler. HTTP avoids it by not exporting, not bringing it into the user code scope.
I have also not tried to reproduce. There might be other explanations, although the stack frame seems clear.
If there's an actual crash with base syntax, which is always in scope of course, it is clear where the change should be made. Open is probably not moving out of base ever, although there used to be many more such functions to avoid in previous versions.

This was fixed in HTTP.jl, but maybe is copy / pasted here before the fix?
PS: Flight was delayed. It is 3:24am and I just checked into the hotel with meetings in the morning so this is a drive by comment without looking at the code 😅

I hope the meeting turned out well anyway! I  just pushed the correction above.
Also, it's fixed in the same way in HTTP. I must do Pkg.update() more often!

Regarding "binary" websockets.
Ehem. There really is no such thing. To explain why that distinction ever got important: We just recently added optionalProtocol (subprotocol) to this package.
A optional protol could choose to have every 42nd message be text if there was a reason for it, although all frames in a message should be of the same type. Eric, you actually do something like that in the rewritten binary test. You transfer the UUID as text, then in the next message you read binary data.
On the browser side, the 'user', i.e. the javascript guy, needs to poke in at a slightly deeper level to speed up how incoming binary messages are interpreted.  So the binaryType is "arraybuffer" or "blob". The very same websocket can happily continue to receive text messages. Ideally, javascript never accesses the contents of the binary but passes references to where they are needed.
But this browser distinction does not apply to clients generated by e.g. Julia or Python. So we can choose to test for 'binary' websockets but this would rather belong in the examples folder.
And the Websocket object or the upgrade function shouldn't convey information about 'binary'. That info is fully defined by the optionalProtocol.
P.S.
The HttpServer handshake isn't working in the pushed version, due to lowercase / uppercase. My bad, will fix.

Just pushed some changes, still a temporary version.
Modified the HTTP upgrade function to be in line with the old upgrade function:

Check length of key before calling generate_websocket_key
Postponing setting response status to 101 before all checks are made.
Check for supported subprotocols
Includes subprotocol header in response
Added comment to upgrade field
No longer responds with a WebSocketError when incoming connections are turned down.
The error messages trapped by HTTP would not be shown in the browser, so this debug mechanism is
less useful. Chrome and Firefox may show some more useful error messages in the developer console
when we reply according to protocol.
Removed the 'binary' parameter from the call to the user's handler.

Modified the HttpServer upgrade function:

Improved comment

Modifed WebSockets.jl
hasprotocol(s::String ) - hasprotocol(s::AbstractString)

Calling WebSockets.open is still making noises when not done in quite the right way. Here is another example for later checking:
julia> @edit WebSockets.open(myfun, SERVERURL, optionalProtocol = "relay_backend")
ERROR: could not determine location of method definition
Stacktrace:
 [1] functionloc(::Method) at .\reflection.jl:873
 [2] edit(::Function, ::Any) at .\interactiveutil.jl:88

julia> methods(WebSockets.open)
# 1 method for generic function "open":
open(f::Function, url; binary, verbose, optionalProtocol, kw...) in WebSockets at C:\Users\F\.julia\v0.6\WebSockets\src\HTTP.jl:5

julia> WebSockets.open(myfun, SERVERURL, optionalProtocol = "relay_backend")
18:47:58.57  WebSocket{TCPSocket}(client, (✓) CONNECTED, 0)
HTTP.Messages.Response:
"""
HTTP/1.1 101 Switching Protocols
Sec-WebSocket-Protocol: relay_backend
Sec-WebSocket-Accept: KrL8ARZgLQgIPzge8gF1rCwJW+k=
Upgrade: websocket
Connection: Upgrade

"""

Also, some thoughts about making the interface extendable beyond local experimenting on a computer. We don't need to do this now, but it's a good time to think the best parts from HttpServer and HTTP.
I would appreciate your comments, but in the meantime I'm going to update and add examples with the current interface I think.
It is recommended to do some further checks of the upgrade request beyond what 'upgrade' does now. For local experimenting, this can of course be neglected, so the user shouldn't have to bother about it.

The URI field is intended for identifying from where this particular connection is coming from, for
example which test or which html file.
"Origin" header: Included by clients in browsers, e.g: => "http://localhost:8000", but not by
other local programs.
"Sec-WebSocket-Extensions" => "permessage-deflate" (for example)

So one way to tell 'upgrade' which connections to accept might be requiring a WebSockethandler object with a dictionary of acceptance criteria, or just fields with liberal starting value. This is more like the stricter interface of HttpServer. Loosely, a WebSockethandler could be defined with:
.handlerfunction
.acceptURI
acceptprotocols
.acceptsource
.acceptorigin
.acceptzip...
For reference, these are typical headers from Chrome:
"Connection"               => "keep-alive, Upgrade"
"Sec-WebSocket-Version"    => "13"
"http_minor"               => "1"
"Keep-Alive"               => "1"
"User-Agent"               => "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Fi…
"Accept-Encoding"          => "gzip, deflate"
"Cache-Control"            => "no-cache"
"Origin"                   => "http://localhost:8000"
"Sec-WebSocket-Key"        => "R9b6CHWxy9cg3H+1WuCFCA=="
"Sec-WebSocket-Protocol"   => "relay_frontend"
"Sec-WebSocket-Extensions" => "permessage-deflate"
"Host"                     => "localhost:8000"
"Upgrade"                  => "websocket"
"Pragma"                   => "no-cache"
"http_major"               => "1"
"Accept"                   => "text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8"
"Accept-Language"          => "en-US,en;q=0.5"

I experimented a bit locally with changing the @requires, because they lead to more recompiling. But the @requires is the only way I get Atom to work. It seems some parts of Atom use HTTP and some parts use HttpServer.
Here's a graph layout of the dependencies neighborhood from a couple of months back. This includes testing dependencies. The lighter ones are the dependencies on this package.
Dependencies and test dependencies neighborhood

Just pushed a commit with added benchmarks and logging utilities. See commit message.
An example result with plots is included in benchmark/log
The other significant change is adding a non-blocking read with timeout during closing handshakes. This hopefully gets rid of most ECONNRESETS.
There will be no large benefit to merging and tagging this while on Julia 0.6, since it adds seconds of loading time to e.g. Atom. That is less of a worry if a faster alternative is ready for 0.7.

Just pushed commit 8edb459, which reverts a major change from master.
Control frames, like PONG, now iterates to the next control frame instead of returning.
For example, OPCODE_CLOSE or _PONG would make read(ws) return some binary data. Now, read() does not return at all. An alternative that enables listening for possible PONG is using or modifying the non-exported read_nonblocking(ws). It would also be nice to have something like read_timed. Low priority.
The commit also includes ServerWS, serve(::ServeWS, etc...) and some constructors.
This can be avoided if HTTP.Serve can be extended slightly. It also defines a Websockethandler wrapper type for HTTP that would be better off as HTTP.WebsocketHandler.

Cool to see progress 👍 I doubt HTTP.Serve will extended. In fact, I believe removing it was discussed and is likely in favor of "listen".

Commit bb9af69 reinstates readframe(ws) checking for mask.
    if mask != ws.server
        error("WebSocket reader cannot handle incoming messages without mask. " *
            "See http://tools.ietf.org/html/rfc6455#section-5.3")
    end

The original test was probably removed to enable WebSockets|client, but since the function now takes a WebSocket and not just any IO, we can do this.

It would be interesting to know how the Serve discussion turns out. I added this interface to try and get rid of console output from HTTP, but was only able to turn off some messages.
'ServeWS' assumes that user understands http requests and responses, but doesn't know what streams are. This is nice for some. But then it demands that users know about these ad-hoc function wrappers which don't really add any functionality: HttpHandle, WebSocketHandle.
They do add some structure to defining servers, though. This structure would read clearer using keyword arguments. Using a specific type for these function wrappers is also beneficial for logging dispatch.
I especially don't like the term WebsocketHandler. A handler is a function that reacts to an outside event and returns something useful. A WebSocketHandler doesn't do that. I would say it's an event handling subroutine that does various stuff with the argument. But then, I'm not a computer guy.
If you can think of alternative names or interfaces, I would appreciate the input.

Commit 15adbdf introduces status codes for closing handshakes, server and client side.

The mask is wrongly applied to 'payload length'. When both the client and server is this package, there's no consequence. It can even work for short messages and with external servers which don't check too carefully, but it is certainly failing for frames > 126 bytes.
Will try to fix and include a test.

I thought it was merged already :)

One would, looking at the dates. Blame the weather!
Commit b510f88 improves exception handling, provokes the exceptions and checks the new and nice reasons for closing. There's just one instance where the provocations lead to a 'hundreds of lines'-output. We're mostly containing it now.
I'll have a look at the documents before merging. We're at 100% compliance with the standard I hope, except for checking that no-one used the reserved bits.

Pretty much a large reshuffle of Readme.md.
I have tried to emphasize the bits which confused me the most, namely how the workflow actually works.
I thought for a long time that releasing references to a websocket was what made the callers release resources. The examples, with infinite while..end loops, led me to that misunderstanding.

Commit ada7f2d reshuffles Readme.md again to make the actual interfaces / starting point clear. Also improved inline docs for WebSockets.serve.
Remaining: Restructure browsertest. Include the 'client' example from readme in examples. Update wiki. But the wiki is edited in the repo web interface, and interface is settled, so I'm merging this to master now.


DEP-107 Rearranged testData structure

Refactored test data into classes
Refactored impacted tests
Description
testData structure has been simplified.  All test interfaces, classes, and data are now contained in standalone files in the testData folder.  Common support functions are in testData/supportFunctions - these are used only by the test data objects, and are not intended to be used inside of either tests or page objects.
All test data objects have been refactored into interfaces and classes.  The factory functions have been removed.  Class and interface objects are now interchangeable - a new class object using an interface object must be called to take advantage of randomization.
Test data types
CreditCard and ShowingInfo
These are simple interfaces with predefined consts available in the package.  Randomization is not appropriate for these data types, so the consts can be used directly.
CustomerInfo
Must call a new CustomerInfo object using a const to take advantage of randomization.  The data members will be populated in the class slightly differently depending on the value of the const data members:
fullName:  The value in the const object will be ignored, as the first name will always have a random value appended.
phoneNumber:  If a value exists in the const object, it will be used.  Otherwise a phone number will be randomly generated.
email:  If a value exists in the const object, it will be used.  Otherwise the first and last name, affixed with<EMAIL_ADDRESS>will be used to automatically generate this value.
EventInfo
Must call a new EventInfo object using a const to take advantage of randomization.  eventFullName will be automatically generated from the other fields - the value in the const object will be ignored.
SeasonInfo
Must call a new EventInfo object using a const to take advantage of randomization.  seasonName will have a UUID affixed, but all other members will be taken from the const object.
Risks
Limited backward compatibility - all tests not in main will need to refactor to use the test data objects properly.
The class and interface objects are interchangeable.  No errors will be raised if somebody uses a const instead of creating a class object.
Validation
Tested in local.
Issue
https://wondertix.atlassian.net/browse/DEP-107?atlOrigin=eyJpIjoiMmY3NmQwNTQ1NjJkNDRmYWE0OWQwZmQwNjA1M2Y1MDIiLCJwIjoiaiJ9
Operating System
Windows 11

eventFullName has been removed.  The logic to build the appropriate string was moved into the EventsPage object and is no longer required in testData.


Update README

Adds instruction to navigate to the directory containing tweet.js

The README isn't really clear about this, but you should be able to just provide the path to the tweet.js file to the script: delete-tweets --until 2018-01-01 data/tweet.js.

why was this closed?
couldn't figure out what is tweet.js before reading the pull request


Build failure: veusz

Steps To Reproduce
Steps to reproduce the behavior:
nix-shell -p veusz
Build log
Traceback (most recent call last):
  File "/build/veusz-3.6.2/tests/.runselftest.py-wrapped", line 319, in <module>
    runTests(
  File "/build/veusz-3.6.2/tests/.runselftest.py-wrapped", line 246, in runTests
    renderVszTest(infile, outfile, test_saves=test_saves,
  File "/build/veusz-3.6.2/tests/.runselftest.py-wrapped", line 184, in renderVszTest
    ifc.Export(outfile)
  File "/nix/store/1h7fccsz5xc5zfqwh1s8m3facg6565cj-veusz-3.6.2/lib/python3.11/site-packages/veusz/document/commandinterface.py", line 810, in Export
    e.add(filename, pages)
  File "/nix/store/1h7fccsz5xc5zfqwh1s8m3facg6565cj-veusz-3.6.2/lib/python3.11/site-packages/veusz/document/export.py", line 453, in add
    self.doc.paintTo(phelper, page)
  File "/nix/store/1h7fccsz5xc5zfqwh1s8m3facg6565cj-veusz-3.6.2/lib/python3.11/site-packages/veusz/document/doc.py", line 369, in paintTo
    self.basewidget.draw(painthelper, page)
  File "/nix/store/1h7fccsz5xc5zfqwh1s8m3facg6565cj-veusz-3.6.2/lib/python3.11/site-packages/veusz/widgets/root.py", line 144, in draw
    page.draw( posn, painthelper )
  File "/nix/store/1h7fccsz5xc5zfqwh1s8m3facg6565cj-veusz-3.6.2/lib/python3.11/site-packages/veusz/widgets/page.py", line 371, in draw
    bounds = widget.Widget.draw(
             ^^^^^^^^^^^^^^^^^^^
  File "/nix/store/1h7fccsz5xc5zfqwh1s8m3facg6565cj-veusz-3.6.2/lib/python3.11/site-packages/veusz/widgets/widget.py", line 298, in draw
    c.draw(bounds, painthelper, outerbounds=outerbounds)
  File "/nix/store/1h7fccsz5xc5zfqwh1s8m3facg6565cj-veusz-3.6.2/lib/python3.11/site-packages/veusz/widgets/scene3d.py", line 220, in draw
    root = self.makeObjects(painter, bounds, painthelper)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/nix/store/1h7fccsz5xc5zfqwh1s8m3facg6565cj-veusz-3.6.2/lib/python3.11/site-packages/veusz/widgets/scene3d.py", line 174, in makeObjects
    obj = c.drawToObject(painter, painthelper)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/nix/store/1h7fccsz5xc5zfqwh1s8m3facg6565cj-veusz-3.6.2/lib/python3.11/site-packages/veusz/widgets/graph3d.py", line 236, in drawToObject
    self.addBorder(painter, cont)
  File "/nix/store/1h7fccsz5xc5zfqwh1s8m3facg6565cj-veusz-3.6.2/lib/python3.11/site-packages/veusz/widgets/graph3d.py", line 169, in addBorder
    ls = threed.LineSegments(
         ^^^^^^^^^^^^^^^^^^^^
TypeError: arguments did not match any overloaded call:
  LineSegments(x1: ValVector, y1: ValVector, z1: ValVector, x2: ValVector, y2: ValVector, z2: ValVector, prop: Optional[LineProp]): argument 2 has unexpected type 'ValVector'
  LineSegments(pts1: ValVector, pts2: ValVector, prop: Optional[LineProp]): argument 2 has unexpected type 'ValVector'
  LineSegments(a0: LineSegments): argument 1 has unexpected type 'ValVector'
error: builder for '/nix/store/p1mw9fz1jj383shwxcxvp53g7ksmlzrb-veusz-3.6.2.drv' failed with exit code 1;
       last 10 log lines:
       >           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       >   File "/nix/store/1h7fccsz5xc5zfqwh1s8m3facg6565cj-veusz-3.6.2/lib/python3.11/site-packages/veusz/widgets/graph3d.py", line 236, in drawToObject
       >     self.addBorder(painter, cont)
       >   File "/nix/store/1h7fccsz5xc5zfqwh1s8m3facg6565cj-veusz-3.6.2/lib/python3.11/site-packages/veusz/widgets/graph3d.py", line 169, in addBorder
       >     ls = threed.LineSegments(
       >          ^^^^^^^^^^^^^^^^^^^^
       > TypeError: arguments did not match any overloaded call:
       >   LineSegments(x1: ValVector, y1: ValVector, z1: ValVector, x2: ValVector, y2: ValVector, z2: ValVector, prop: Optional[LineProp]): argument 2 has unexpected type 'ValVector'
       >   LineSegments(pts1: ValVector, pts2: ValVector, prop: Optional[LineProp]): argument 2 has unexpected type 'ValVector'
       >   LineSegments(a0: LineSegments): argument 1 has unexpected type 'ValVector'
       For full logs, run 'nix-store -l /nix/store/p1mw9fz1jj383shwxcxvp53g7ksmlzrb-veusz-3.6.2.drv'.

Additional context
Add any other context about the problem here.
Notify maintainers
@laikq
Metadata
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
- system: `"x86_64-linux"`
- host os: `Linux 6.6.15, NixOS, 23.11 (Tapir), 23.11.4117.6832d0d99649`
- multi-user?: `yes`
- sandbox: `yes`
- version: `nix-env (Nix) 2.18.1`
- channels(root): `"home-manager-23.11.tar.gz, nixos-23.11, nixos-unstable"`
- nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Add a :+1: reaction to issues you find important.

Unable to reproduce on master branch.

Seems to only fail on 23.11 (and was never successfully built after 23.11 branch was created at all):
https://hydra.nixos.org/job/nixos/release-23.11/nixpkgs.veusz.x86_64-linux/all
It was failing on unstable with same error between 2023-10-23 and 2023-12-12:
https://hydra.nixos.org/job/nixos/trunk-combined/nixpkgs.veusz.x86_64-linux
TypeError: arguments did not match any overloaded call:
  LineSegments(x1: ValVector, y1: ValVector, z1: ValVector, x2: ValVector, y2: ValVector, z2: ValVector, prop: Optional[LineProp]): argument 2 has unexpected type 'ValVector'
  LineSegments(pts1: ValVector, pts2: ValVector, prop: Optional[LineProp]): argument 2 has unexpected type 'ValVector'
  LineSegments(a0: LineSegments): argument 1 has unexpected type 'ValVector'

But builds fine on unstable after build on 2024-01-13.


Updated readme

Changed to have explainer on how to use the - omit function.

Sweet, thanks Jase - will merge naow. :)

Cool, very small change - but I'm always looking at Readme files to see what's what :)


[Proposal] Add an @embed tag to Blade

Hi.
i thing it would be great to add @embed directive, which is well know from TWIG
http://twig.sensiolabs.org/doc/tags/embed.html
It is basically way to use layouts inside @sections.it helps to do shorter blade templates
usage
@section('content')
    ....
    @embed('layout.box')
        @section('title','My form')
        @section('body')
             @include('my._form')
         @endsection
    @endembed

@endsection

layout.box.blade

      @if ($__env->yieldContent('title',false))

@yield('title')

      @endif

...

            @yield('body')

...

Requirements

global blade variables whould be accessible inside @embed
it would be nice if i can define @section in @embed -  for example @section('scripts') to have opportunity, to add some


CPU Temperatures doesn't return any values

I am attempting to pull the CPU temperatures, I get a response but with no values.
This is reproducible using the code I have attached below;
`valueObject = {
cpu:'brand',
cpuTemperature: 'main, cores, max'
}
si.get(valueObject).then(data => console.log(data));`
Output
From main.js
{ cpu: { brand: 'Ryzen 5 2600 Six-Core Processor' },
cpuTemperature: { main: null, cores: [], max: null }
Expected behavior
I was expecting to recieve CPU temperatures!
Environment (please complete the following information):

systeminformation package version: Windows 10 Pro, Using Visual Studio
OS: Windows
Hardware: Ryzen 5 2600, MSI X470 carbon motherboard,

Extra Info
I have already tried running as an administrator through powershell but to no success!

@dan953 please have look at https://systeminformation.io/issues.html.
Did you checked if WMIC returns correct values?
Can you post result of
wmic /namespace:\\root\wmi PATH MSAcpi_ThermalZoneTemperature get CurrentTemperature

@dan953 please have look at https://systeminformation.io/issues.html.
Did you checked if WMIC returns correct values?
Can you post result of
wmic /namespace:\\root\wmi PATH MSAcpi_ThermalZoneTemperature get CurrentTemperature

Node - DAN-RYZEN-2600
ERROR:
Description = Not supported

Node - DAN-RYZEN-2600
ERROR:
Description = Not supported

@dan953 Thank you for rechecking - so then if Windows cannot determine temperature this way, then systeminformation also cannot get the value (as described in its known issues https://systeminformation.io/issues.html section of the docs).
Closing this for now.

@dan953 Thank you for rechecking - so then if Windows cannot determine temperature this way, then systeminformation also cannot get the value (as described in its known issues https://systeminformation.io/issues.html section of the docs).
Closing this for now.


Check mapzen geocoder implementation in search input

It seems specially bad now...
If you go to 201 Moore st, Brooklyn it points you to the middle of nowhere for example.

I checked this (using 210 Moore St, Brooklyn) and it seems to be working fine now. CartoDB.js is basically triggering a request (https://search.mapzen.com/v1/search?text=201 moore st%2C brooklyn&api_key=XXXX) to MapZen's API, so there's little we can do to improve this on our side AFAIK 😞 .


[Bug] --write-subs and --embed-subs don't simultaneously work, you only get one.

I can't get subs both embedded and written. Not sure what kind of output is needed for this but this is all I have.

This is intentional.

Deleting original file YouTube Captions and Subtitles-QRS8MkLhQmM.en.vtt (pass -k to keep)


Selecting tasks using their superset

What does this implement/fix? Explain your changes.

Implements https://github.com/huggingface/lighteval/issues/294
Add support for using multiple task groups in single run or mixing the task groups with normal task definitions

Comments:

Some typing fixes to get less red lines
Moved custom module handling into registry, imo it make logically sense
I use _x to signify a private property. I know there is no such a thing in python, but it's a common way to signify that the variable shouldn't be modified outside a class code

You'll need to fix the tests first :)

@hynky1999 where are we wrt this PR? is it still active?

Yes, just have other things to focus on rn. Will try to update it by the of this week

No urgency, just going through to see what to close

I skimmed it, that looks good, merging.
Thanks for the update!


Handshake failed when uploading to Azure

Hello,
Following the tutorial for Unity, I've hooked up DataManager and added the Connection String to my Azure Storage Account and it is able to create a blob and upload an image, however the second time I try, it will hang and then eventually give a handshake failed error.
Restarting fixes this however after the first upload or download I get the same error.
Is there a way to see why it failed or fix the problem?
Error Message:
System.Net.Http.HttpRequestException: An error occurred while sending the request ---> System.Net.WebException: Error: TrustFailure (One or more errors occurred.) ---> System.AggregateException: One or more errors occurred. ---> System.Security.Authentication.AuthenticationException: A call to SSPI failed, see inner exception. ---> Mono.Security.Interface.TlsException: Handshake failed - error code: UNITYTLS_INTERNAL_ERROR, verify result: UNITYTLS_X509VERIFY_FLAG_NOT_TRUSTED

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

ID: f15853f4-20ac-bea9-89b0-4cd7da19a5be
Version Independent ID: 398529a4-fee0-21bb-6cc6-b57b47d25ea1
Content: Integrating Azure storage - Mixed Reality
Content Source: mixed-reality-docs/mr-dev-docs/develop/unity/tutorials/mr-learning-azure-02.md
Product: mixed-reality
Technology: mr-dev
GitHub Login: @jessemcculloch
Microsoft Alias: jemccull

@veeruby-developer Is this something you've encountered before?

@hferrone  we will look into it....

Following the tutorial for Unity, I've hooked up DataManager and added the Connection String to my Azure Storage Account and it is able to create a blob and upload an image, however the second time I try, it will hang and then eventually give a handshake failed error.
can you please provide us more details, we were not able to reproduce this issue. we were able to set the object multiple times and upload images.

@MagmaPenguin Can you give us some more details so we can try and reproduce?

I had this on my first project, I followed the tutorial and setup the DataManager so I could upload and download images to my Azure Storage but doing an upload multiple times would cause the handshake error.
I was originally using a large image file, could this have caused the error because the original upload hadn't finished before I attempted another?
I changed and began testing with smaller image sizes and it mostly worked each time. Is there a way also to cancel an upload/download by using a Cancellation Token?

@MagmaPenguin @hferrone any updates? Can we close if resolved or not resolvable?


Automate the release

Updating pypi with a new version is a bit of a headache.
Automate the process as much as possible.

This is turning into a minor nightmare! I need to read up more on tags...

This is turning into a minor nightmare! I need to read up more on tags...


Persist range state in plots

This ensures that both skyplot and scatter plot ranges persist when adding and removing metrics and when switching between simple and detailed views.
Additionally this redesigns how plots are instantiated a bit.

This does not yet handle persistence of state in a more general sense, which I'd like to postpone until https://github.com/holoviz/panel/pull/1150 is merged which will give us bidirectional control over query parameters in param.


feat: exception handler improvements

TODO:

[x] Update HTTP exception handler for all cases

[x] Use whoops for non-production (for now)
[x] Display generic 500 page

[ ] Handle kernel exceptions before exception handlers are loaded
[x] Tests

Pull Request Test Coverage Report for Build<PHONE_NUMBER>1
Details

9 of 55 (16.36%)  changed or added relevant lines in 9 files are covered.
26 unchanged lines in 4 files lost coverage.
Overall coverage decreased (-0.07%) to 82.526%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/Tempest/Console/src/ConsoleApplication.php
0
1
0.0%

src/Tempest/Console/src/Initializers/ConsoleApplicationInitializer.php
0
1
0.0%

src/Tempest/Console/src/Initializers/ConsoleInitializer.php
2
3
66.67%

src/Tempest/Http/src/HttpApplication.php
0
1
0.0%

src/Tempest/Core/src/Kernel.php
3
14
21.43%

src/Tempest/Console/src/Exceptions/ConsoleExceptionHandler.php
0
15
0.0%

src/Tempest/Http/src/Exceptions/HttpProductionExceptionHandler.php
0
16
0.0%

Files with Coverage Reduction
New Missed Lines
%

src/Tempest/Console/src/Initializers/ConsoleApplicationInitializer.php
1
0.0%

src/Tempest/Console/src/Initializers/ConsoleInitializer.php
1
57.89%

src/Tempest/Core/src/Kernel.php
1
62.34%

src/Tempest/Console/src/Exceptions/ConsoleExceptionHandler.php
23
4.35%

Totals

Change from base Build<PHONE_NUMBER>9:
-0.07%

Covered Lines:
7084

Relevant Lines:
8584

💛  - Coveralls

About tests: I don't know what to test, because PHPUnit complains whenever you add custom exception handlers…

I decided it was better to have exception handlers being resolved via the container, which means that they have to be registered after discovery. I've made an issue for it: https://github.com/tempestphp/tempest-framework/issues/671


Add missing description

This is necessary to display the proper description in the tooling

@hbelmiro can you cherry-pick this commit and apply in the quarkus2 branch too?

@hbelmiro can you cherry-pick this commit and apply in the quarkus2 branch too?

@gastaldi done: https://github.com/quarkiverse/quarkus-openapi-generator/pull/247


Need a way to update wiki using MD docs

Updating GitHub wiki is pretty painful now. Need an app which can sync wiki content and some specific repo content where people can push their PR into.

Similar to https://github.com/palantir/godel/wiki/GitHub-wiki

@wolfy-j maybe move docs to separate service and save only md files in repo?