shairport-sync.service: libalac.so.0 not found

Hi @nicokaiser
just used this repo to set up Bluetooth / Airplay on my Raspberry Pi 3 B on Raspberry Pi OS Lite Buster at commit https://github.com/nicokaiser/rpi-audio-receiver/commit/26d6a31fbf3732825a5969cc1b60202c985e3756 of this repo.
One thing that did not work out of the box: Airplay.
It seems as though the compiled version of libalac is put into /usr/local/lib ... the LD_LIBRARY_PATH does not contain this path though, so we have to set in the shairport-sync.service:
systemctl edit shairport-sync.service

[put the line with 'Environment=' in there]

# /etc/systemd/system/shairport-sync.service.d/override.conf
[Service]
# Avahi daemon needs some time until fully ready
ExecStartPre=/bin/sleep 3
Environment=LD_LIBRARY_PATH=/usr/local/lib

Cheers
Thomas

Submitted a PR to address this, see comments there: https://github.com/nicokaiser/rpi-audio-receiver/pull/106

This is strange, since shairport-sync is also compiled from source (thus, installed to /usr/local/bin/shairport-sync), so it should find its libraries in /usr/local/lib.
I'll try to install a fresh version of the script to see what's wrong and if the LD_LIBRARY_PATH is really needed...

@TwizzyDizzy Can you check if this works: the current install script I just pushed runs ldconfig after installing alac. This should fix the issue without needing to provide a LD_LIBRARY_PATH.

Yeah, this solution is to be preferred over the workaround in the systemd unit which is what I meant with

Might also be solved by configureing different LDFLAGS here: e579b0e.

in the PR.
I'll give it a spin with a spare SD and your pushed version, probably tomorrow, and report back.
Cheers
Thomas

Ah.. did it now so we can finish this: can confirm, your ldconfig does the trick.
This works due to:
root@livingroom:~# cat /etc/ld.so.conf.d/libc.conf
# libc default configuration
/usr/local/lib

The output of ldd now shows: libalac.so.0 is found:
root@raspberrypi:/opt/rpi-audio-receiver# ldd /usr/local/bin/shairport-sync
	linux-vdso.so.1 (0x7ee0b000)
	/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so => /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so (0x76f23000)
	libmosquitto.so.1 => /lib/arm-linux-gnueabihf/libmosquitto.so.1 (0x76f06000)
	libgio-2.0.so.0 => /lib/arm-linux-gnueabihf/libgio-2.0.so.0 (0x76d8a000)
	libgobject-2.0.so.0 => /lib/arm-linux-gnueabihf/libgobject-2.0.so.0 (0x76d2d000)
	libglib-2.0.so.0 => /lib/arm-linux-gnueabihf/libglib-2.0.so.0 (0x76c1d000)
	libsndfile.so.1 => /lib/arm-linux-gnueabihf/libsndfile.so.1 (0x76ba1000)
	libasound.so.2 => /lib/arm-linux-gnueabihf/libasound.so.2 (0x76ac0000)
	libavahi-common.so.3 => /lib/arm-linux-gnueabihf/libavahi-common.so.3 (0x76aa5000)
	libavahi-client.so.3 => /lib/arm-linux-gnueabihf/libavahi-client.so.3 (0x76a86000)
	libsoxr.so.0 => /lib/arm-linux-gnueabihf/libsoxr.so.0 (0x76a24000)
	libssl.so.1.1 => /lib/arm-linux-gnueabihf/libssl.so.1.1 (0x769a5000)
	libcrypto.so.1.1 => /lib/arm-linux-gnueabihf/libcrypto.so.1.1 (0x7678b000)
	libalac.so.0 => /usr/local/lib/libalac.so.0 (0x76772000)
	libconfig.so.9 => /lib/arm-linux-gnueabihf/libconfig.so.9 (0x76758000)
	libpopt.so.0 => /lib/arm-linux-gnueabihf/libpopt.so.0 (0x7673d000)
	libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76713000)
	librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x766fc000)
	libstdc++.so.6 => /lib/arm-linux-gnueabihf/libstdc++.so.6 (0x765b5000)
	libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x76533000)
	libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x76506000)
	libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x763b8000)
	/lib/ld-linux-armhf.so.3 (0x76f38000)
	libgmodule-2.0.so.0 => /lib/arm-linux-gnueabihf/libgmodule-2.0.so.0 (0x763a4000)
	libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0x76379000)
	libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x76366000)
	libmount.so.1 => /lib/arm-linux-gnueabihf/libmount.so.1 (0x76305000)
	libselinux.so.1 => /lib/arm-linux-gnueabihf/libselinux.so.1 (0x762d3000)
	libresolv.so.2 => /lib/arm-linux-gnueabihf/libresolv.so.2 (0x762af000)
	libffi.so.6 => /lib/arm-linux-gnueabihf/libffi.so.6 (0x76297000)
	libpcre.so.3 => /lib/arm-linux-gnueabihf/libpcre.so.3 (0x76220000)
	libFLAC.so.8 => /lib/arm-linux-gnueabihf/libFLAC.so.8 (0x761c0000)
	libogg.so.0 => /lib/arm-linux-gnueabihf/libogg.so.0 (0x761ab000)
	libvorbis.so.0 => /lib/arm-linux-gnueabihf/libvorbis.so.0 (0x76174000)
	libvorbisenc.so.2 => /lib/arm-linux-gnueabihf/libvorbisenc.so.2 (0x760e2000)
	libdbus-1.so.3 => /lib/arm-linux-gnueabihf/libdbus-1.so.3 (0x76091000)
	libgomp.so.1 => /lib/arm-linux-gnueabihf/libgomp.so.1 (0x76059000)
	libblkid.so.1 => /lib/arm-linux-gnueabihf/libblkid.so.1 (0x76001000)
	libsystemd.so.0 => /lib/arm-linux-gnueabihf/libsystemd.so.0 (0x75f64000)
	libuuid.so.1 => /lib/arm-linux-gnueabihf/libuuid.so.1 (0x75f4d000)
	liblzma.so.5 => /lib/arm-linux-gnueabihf/liblzma.so.5 (0x75f1c000)
	liblz4.so.1 => /lib/arm-linux-gnueabihf/liblz4.so.1 (0x75ef0000)
	libgcrypt.so.20 => /lib/arm-linux-gnueabihf/libgcrypt.so.20 (0x75e16000)
	libgpg-error.so.0 => /lib/arm-linux-gnueabihf/libgpg-error.so.0 (0x75dea000)

Cheers
Thomas


Main blog page isn't updated upon refresh

Repro:

Tweak some blog post words
Go to /blog
Refresh browser
No change picked up

This works fine on individual blog post pages.

@chenglou I will try to reproduce this.

I managed to reproduce it.


[FLINK-26816] Verify the java doc is consistent with the code implementation

We need to verity the java doc is consistent with the code implementation via the CI. Otherwise, it is very easy to forget to re-generate the java doc after some changes. Thanks git diff we could make the verification easier :)
A failed case could be found here. https://github.com/wangyang0918/flink-kubernetes-operator/runs/5656298427?check_suite_focus=true

cc @gyfora

+1 nice

Thanks @morhidi for your review. Merging now.


[no ticket] Fix linting errors with CRLF vs LF on Windows machines

Ticket: n/a
Feature flag: n/a

Purpose
On Windows machines, Git installer's default is to checkout to CRLF line endings and commit LF. This was causing linting errors within the project. These changes just ensure linting matches to the machine it's running on.
Summary of Changes
Added check for linebreak style in .eslintrc.js and removed forced LF in .editorconfig.

Pull Request Test Coverage Report for Build 3451

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 75.47%

Totals

Change from base Build 3439:
0.0%

Covered Lines:
7787

Relevant Lines:
9062

💛  - Coveralls


Not really an issue: Maybe update "How to Support" with other coins?

LTC, ETH or good 'old BTC? For the unlucky among us without XCH?

Lol I just deleted my LTC and other blockchains to make room for testing the plotter on my dev machine...

@madMAx43v3r Perhaps just set up Github sponsors / Patreon or something haha


Edit toon color ramp selected by material

When replacing certain model textures, such as Mythra's hair textures, the in-game shader effects will "blend" the color of the new texture with the color it was originally designed to accent. The ability to edit these materials should hopefully improve the look of certain texture replacements in-game.
Massive Melee Mythra's (Right) hair texture replaced with with Pyra-Style Mythra's (Left)

Sword Fighter Class jacket textures replaced with Noah's Color 2 jacket textures (Noah's Color 2 Outfit used for Comparison)

The color shifts on Noah's jacket are caused by the color ramps selected by the jacket material to use in the toon shading pass. The jacket basically has dark red lighting applied. I'm not sure about the cause for Mythra's hair.
There's still a bit of work that needs to be done on xc3_wgpu and xc3_viewer to understand what the material parameters actually do. Material edits will be possible once model rebuilding in xc3_model includes materials (hopefully 0.6.0). The easiest way to make material edits will be with a short Python script and xc3_model_py once the changes get ported to the Python bindings. I would add example scripts for people to use as a reference.

Interesting, thanks for the insight.
I know it's just conjecture on my part, but I still feel like the Mythra hair issue has to be caused by something in the .wimdo no? Even if it's not caused by the material "hikari_hair_NEW2," each of Mythra's different models always seems to know which color/shading effects are supposed to applied to them in-game: Yellow for Base Mythra, Massive Melee Mythra, and Radiant Beach Mythra, Red for Pyra-Style Mythra, Purple for Carbon Mythra, and surprisingly, nothing for Hotsprings Mythra from what I've been able to see (replaced hair textures have no effects applied to them in-game).
Another character model of note is Base Pyra, as hair texture replacements also have no effect applied on them:
Blue Sky Pyra
Base Pyra with Blue Sky Pyra's green hair texture
So either the hair materials for some models are programmed without any color/shading effects, or it's just something else entirely (which is probably the more likely answer).
Don't know if any of this information will be helpful to you but I thought I'd at least share the results of tests I've done for over a year now (back when 3096's Ether Furnace was the only public texture replacement tool)

The color shifts you're seeing on Massive Melee Mythra are also caused by the toon shading lighting gradients. This is just the lighting gradients for Massive Melee Mythra, default Rex, and default Pyra.

This is with Mythra's hair set to Pyra's hair color. The hair effectively has yellow lighting applied.

Material edits won't be available for a while, so I would recommend trying to apply the textures to one of Mythra's other costumes if the UVs are the same. The toon lighting color isn't 100% saturated, so it's technically possible to adjust the RGB gain of the Pyra inspired textures to look mostly correct with a lot of trial and error.

Good to finally know the exact cause.
I can definitely wait until material edits become available. My temporary solution though has always been to edit the hair texture hues in such a way that it still looks similar to the intended color even after the yellow lighting is applied:
Pyra-Style Mythra
Pyra-Style Massive Melee Mythra (with edited hair texture)
I think I adapted my MMM edits pretty well all things considering, but I do look forward to the day when material edits become a thing so I can make them look even more official (via edited lighting gradients and outlines).
As for your recommendation to apply to these textures to other Mythra models, while it would be helpful for making hair edits to Mythra's base design(s), it actually doesn't mesh well (no pun intended) with Massive Melee Mythra's textures as they don't have the mesh for the covered up chest window, or the special lighting effect for the stockings:
Carbon Mythra's Textures on Massive Melee Mythra

Massive Melee Mythra's Stocking Textures on Carbon Mythra

The selected toon gradient can be edited on the latest xenoblade_blender release: https://github.com/ScanMountGoat/xenoblade_blender/releases/tag/v<IP_ADDRESS>


[Feature] Week 4 Features

Changes

Added basic algorithm for the algo project

Made all the necessary changes.
I think my mistake was that I was too focused on this being an algorithm problem - where I usually only have to worry about the worst case runtime. In a real software engineering scenario, average case, best case and edge case runtimes actually matter and I did not take those into consideration.


Minor bug in rating card dark mode

Colour of. Submit button to be white.

@anushbhatia can you assign this to me?

any update?

Can I work on this? You can assign it to me.

Can you assign this to me @anushbhatia
I know how to do this.
I am GSSoC'21 participant.

Sure @adrishyantee


Communication Identity | Skipping CTE Tests for improving pass rate

Instead of ignoring tests, made changes to skip it to improve the pass rate
User Story
Contributing to the Azure SDK
Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.
For specific information about pull request etiquette and best practices, see this section.

/azp run net - Azure.Communication.Identity - tests

API change check
API changes are not detected in this pull request.

/azp run net - Azure.Communication.Identity - tests

/azp run net - Azure.Communication.Identity - tests

I am not sure I understand it correctly. What was wrong with ignoring these tests (apart from the fact if obviously lowered the coverage)? These tests shouldn't run in certain environments, so marking them as pass would be a bit misleading IMO. I don't think that the goal should be to have high coverage at all costs. For example in this case we just need to keep in mind that for INT and PPE the coverage will be lower due to the fact we can't test some scenarios. What do others think?

The Ignore assert was considering the tests in the ignored category. Pass assert will include it in the Pass category, the test are still not getting executed. This is just to improve the pass rate. Same thing has been done for other platforms as well. Also, this block will be removed from the source code once the CTE resources are enabled in INT & PPE environments.


create duration from  human string

Hello everyone,
This is a new feature can be adding to  moment duration
now we can create duration just from a string like  "1 day 57 minutes 34 seconds" will be  parse into normal object and create duration object
how work??
import moment from 'moment ';
console.log(moment.duration().fromString("1 day 57 minutes 34 seconds" )) // duration object

i hope that can be useful

Coverage decreased (-0.008%) to 88.494% when pulling 2747fb859962e3844538321fbd5ab4a5e7f03db1 on jamalroger:develop into 1811de9d3e2040cc64882b50eaf9e05b4025b465 on moment:develop.


Fix cookie tests in test_environ.TestResponse

This is a solution for #791.
A few tests are failing because of some recent changes in http.cookies:

test_set_cookie_secure
test_set_cookie_httponly

test_delete_cookie fails too, I'm not entirely sure why. The workaround is to check for containment of 'Max-Age=-1'.
Also, I added Python 3.5 to .travis.yml.

Not the first time python bugfixes in http.cookie broke something. Thanks for the quick fix.


Lokalise: Translations update

This pull request was initiated by Lokalise (user Peter Murray) at 2021-01-21 01:49:19

yarn run v1.22.4
$ eslint .
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

yarn run v1.22.4
$ eslint .
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.


Update version of monaco-editor to ">0.22.0"

Updates the version of "monaco-editor" to ">0.22.0"  to include newer versions of monaco.

Thanks

Thanks for the package man :)

I'll release new version tomorrow


Ensure that RDP access is restricted from the internet

Possible check to target the following resource

[ ] azure_security_group_rule

closing, tracking in spreadsheet

closing, tracking in spreadsheet


Remove node created backref

Similar to #4810
Relates to https://openscience.atlassian.net/browse/OSF-5406
Purpose
Remove the created backref on the creator field of the Node, to prevent unecessary locking when updating nodes or users caused by the backref.
Changes

Remove created backref on the creator field of the Node
Make new created property on User that queries for nodes that user has created
Update merge_user method of User model to use new created property
Remove test made to test the removed backref
Reload ingeretance project test to update test context

Side effects

created backref can no longer be used

Pass finished.


Create GitHub Actions to re-build the package on each update

We need a GitHub actions to be set up for GAMBLR, in a way that will trigger package build when PR is created and master is updated. This will allow us to catch any dependencies issues at the time when (if) they are introduced, and will ensure successful reproducible installation in a new environment every time.

This is implemented in #177


Include example utils in pip-installed package

Goal: All examples should be runnable as stand alone python files after pip install pyro-ppl.
Why?
Beginning users often start using Pyro by forking existing examples and modifying them. Currently Pyro's examples include helpers examples/util.py and examples/utils/*. Since these helpers are not part of the pip-installed package, users are forced to either (1) fork examples in Pyro's examples/ directory and use Pyro's version control (not ideal for e.g. class projects), or (2) copy all of pyro/examples/utils/ into their own projects.
How?
This issue proposes to move helper code (for plotting and data loading) into the main Pyro package. This could be a single package pyro.contrib.examples or possibly multiple packages pyro.contrib.visualization + pyro.contrib.datasets. These new packages would have weaker guarantees for backwards compatibility, so pyro.contrib seems like a reasonable home.

@jpchen @neerajprad do you have any opinions on package naming?

this reminds me of a recent forum post with the same problem. not particularly opinionated as to the package namespace, but something like pyro.examples.data_loader or pyro.examples.visualization makes sense to me. what do you think?

The names sound fine to me. Longer term, another thing to possibly explore would be separating out the examples as its own package. This will be useful if we have examples that have heavy dependencies like pandas, sklearn etc. that we don't want the core to inherit. I think PyTorch has a similar approach.
Right now, we are kind of doing that (probably accidentally?) except that everything is being installed from setup.py. Both examples and profiler seem to be top level modules along with pyro, and we can do the following import:
from examples.utils.custom_mlp import Exp


Replace davidson with eigsolve from KrylovKit in dmrg

This fixes #234. Besides that issue, I have seen that eigsolve and davidson give very similar results for DMRG, for example for example/dmrg/1d_Heisenberg_dmrg.jl (using a fixed seed):
This branch (dmrg using eigsolve)
After sweep 1 energy=-137.585233665598 maxlinkdim=9 time=0.152
After sweep 2 energy=-138.935109267445 maxlinkdim=20 time=0.354
After sweep 3 energy=-138.940079055055 maxlinkdim=92 time=1.360
After sweep 4 energy=-138.940086046771 maxlinkdim=100 time=3.040
After sweep 5 energy=-138.940086072140 maxlinkdim=96 time=3.309
Final energy = -138.940086072140

On master (dmrg using davidson)
After sweep 1 energy=-137.585233665598 maxlinkdim=9 time=0.148
After sweep 2 energy=-138.935109267445 maxlinkdim=20 time=0.430
After sweep 3 energy=-138.940079055055 maxlinkdim=92 time=1.312
After sweep 4 energy=-138.940086046771 maxlinkdim=100 time=3.415
After sweep 5 energy=-138.940086072140 maxlinkdim=96 time=3.808
Final energy = -138.940086072140

so it seems like a pretty safe replacement.

There are some questions this raises about the keyword arguments that get passed to eigsolve.
The maxiter kwarg in davidson is nearly the same as the krylovdim kwarg in eigsolve (though it appears that they are off by one). I actually prefer the name krylovdim instead of maxiter since it is more descriptive. It is a bit confusing since eigsolve also has a maxiter kwarg which controls the number of restarts.
I almost think we should be very explicit with the keyword arguments, for example name them eigsolve_krylovdim, eigsolve_tol, eigsolve_maxiter, etc (see here for the list of options). Then it is clear that these are keyword arguments that get passed to eigsolve.

That sounds good to me, I can make those changes in this pull request. What if we remove maxiter right now, with an error directing people towards eigsolve_krylovdim (and explain the off-by-one issue), and discuss adding something like cpp_maxiter later?

Probably most people aren't even setting maxiter themselves, so I doubt this will affect many people.

I think that's a good plan. For the most part, people can either just learn the new approach right away or very easily migrate from the old set of arguments. (We can include this in the transition guide we should write on the website for migrating from C++ ITensor to Julia ITensor. Not too soon to start on that!)

Ok, I've changed errgoal to eigsolve_tol and maxiter to eigsolve_krylovdim. This is good to go from my end if it looks good to you.

By the way, is there a problem with Travis? Why aren't the checks showing up on pull requests?

Not sure about the Travis issues but that's the second one I've seen. Another is that sometimes one build will succeed and the other fails (the Mac one fails). I did recently bump the Julia version to 1.4 so maybe that's partly the reason?


Identity first-time contributors and external contributors

We like to tweet to congratulate and thank first-time contributors and external contributors.  It would be useful for a comment to explicitly @mention the outreach team so they know to tweet.
Currently, it is possible to identify first-time contributors by filtering emails for "Welcome to the Cesium community", but I don't know if there is a unique way to filter for external contributors, but this would be easy for the concierge to check.
CC @slchow @vanessamoore

Bumping this since we like to tweet about all community contributions.
When a pull request from a community contributor is merged, the concierge could just @ mention someone(s) (configurable) and also say if it is a first time contributor.
Longer-term, if/when the concierge can label issues, it could label issues as "community contribution", "first-time contributor", etc. - which would be useful for stats as well.

@OmarShehata is this one on the short-term radar?

Yes, I ran into the same problem of checking the correct branch/fork as in this PR https://github.com/AnalyticalGraphicsInc/cesium-concierge/pull/118 so it'll be easy to do right after that one.

This is merged, and I have seen concierge reporting "Thanks for your first time contribution!" need to investigate why it didn't post for this one https://github.com/AnalyticalGraphicsInc/cesium/pull/7944.

@OmarShehata Is it because the first PR I submitted before was shut down by myself, so it was not identified this time?  https://github.com/AnalyticalGraphicsInc/cesium/pull/7911，When I shut down the pr, I received a message from the concierge.

I think it may be an error in my logic, that Concierge checks the branch you're merging into to see if your name is in the contributors.md, and decides based on that whether you're a new contributor.
But I think what happened here, is that since Concierge checks after the PR is merged, then your name is already in contributors.md in master, so it doesn't post. I think I need to check for the commit when the PR was opened, not when the PR is merged.


Add 'is retired' field to classification output

The classification output should have a boolean field that says whether or not that subject has been retired. I imagine this might turn into a string at some point for a retirement reason, as is done for Snapshot Serengeti. But since Panoptes just supports one type of retirement right now (correct?), then a boolean is fine for now.

I like this. We've noticed on Snapshot Serengeti that sometimes there are a few images that never seem to have been retired, even though the season is "complete." This would help sleuth out weirdnesses.

It's actually essential, not just nice. I need to know whether to expect more classifications on any given subject, or whether I have them all.


Rebase to IPFS v0.4.7

Coverage remained the same at 29.53% when pulling d77f32b0c2e279ba81e8bdc7872f8754fb644917 on rebase into 4d4091846b39ba26dc02d54b1ec3fe3621a2aa2e on master.


[Game Crash] Crash on audio sync calibration, even in dance gametype

Describe how it crashed by giving us those informations:
OutFox 4.9.9HF3 crashes after attempting to exit the sync screen (the screen where you press left and right repeatedly to calibrate the offset). This was originally reported by Sevish on Discord and replicated by me.
Sevish reported this happening on Ubuntu and didn't mention whether he/she was using the dance gametype or not.
This happens for me on Raspberry Pi OS 64-bit, and I am using the dance gametype, which is supposed to work.
info.txt
log.txt
I cannot find a crashinfo.txt. Never seen one, which is odd because there's been a lot of crashes...
Explain how we can reproduce the error

Start the game
Options > Input & Calibration > Calibrate Audio Sync
Go for a round of syncing
Hold escape to finalize the offset
Press yes  to save offset, game crashes.

I have also had this happen while selecting 'no', IIRC.
Video: https://youtu.be/PxdCk6Pp_wM

This also happens to me on Windows 10. I don't even need to try to sync. Just exiting the mode without trying to change anything also results in a crash.

Same issue here on Ubuntu 21.04. I guess it's not OS-dependent issue?

Same issue on my end. Probably worth noting that the new offset still saves as normal if you select Yes.
Looking through other issues, could this be related to #395 in some way?
Here's my logs:
crashinfo.txt
info.txt
log.txt

This one is fixed in Hotfix 4, we had a weird one where an ancient upstream bug crept up and bit us

Thanks for reporting!


Add an edit/request widget to the How-to Guides tab

We don't expose this widget on our How-to Guides pages, but we should, or something like it:

Additionally, we should give users who hit the "no guides" path a way to submit a request (or a PR) for a new guide:

This link should probably be shown in all cases --- e.g., if you reach the bottom of the list and haven't found what you were hoping to, we give you somewhere to go next.

related: https://github.com/pulumi/registry/issues/221

hmm, curious what the context was around today's convo?


Kasperky Internet Security reports 3.8 release contains Trojan.Multi.GenAutorunReg.A

n/t

Please attach a screenshot.
Did you do a new installation from *.msi or updated from previous version using built-in updater?

It was picked up when automatically downloading the update, and I also downloaded the zip file from here and scanned it to double check. Also picked up there.

ran the installer through https://scan.kaspersky.com and it reported the same.

edited the release, added a note about the possible infection, and marked it as a pre-release. @jansokoly high recommend scanning your local machine :)

From the name of the "trojan" being HEUR:Trojan.Win32.Generic, I assume it's just Kaspersky false positive based on some overprotective heuristic, probably identifying update mechanism as a trojan.
I recommend checking the file with more then just one antivirus before mocking. https://www.virustotal.com/en/file/a7726321acf1e45ad8f724529bd036e4b19ffd88ba496eba7648160d6effdc41/analysis/

That's why I put both screenshots in there, once loaded in memory, it was more specific. I definitely leave it up to you guys as to how you want to handle it, though.

@jansokoly I didn't read the messages as anyone mocking you. hopefully you don't think that. I only edited that release to pre-release as a precaution. if you feel that this is a false positive, please do change it to full release. total faith in you bud!

Greetings.
I got the update via built-in "AutoUpdater" (a feature that can't be disabled? - found no option in settings)
The "behavioral analysis" of G Data InternetSecurity jumped in and reported suspicious actions:

The program connects to a network.
The program has created or manipulated an executable file.
The program has tried to delete its own program file.
The program tried to change the name of its own program file.
The program has tried to move its own program file.

I was asked whether I want to allow or deny those actions.
The .exe itself is reported to be clean. Just the behavioral thing when the update was applied automatically.
Seems to be a false positive.
@jansokoly Thank you for maintaining the application!

thanks for investigating @regmebaby

I'll go ahead and close the issue.

@shellscape @jansokoly Well, I'll keep it closed, because there's no need to scare the world, but I can't even get Kaspersky to whitelist your file. I won't be able to run this without changes. Want me to create an "incompatibility" issue?

@pskerr I'm not familiar with Kaspersky, but they seem to have a form to report false positives here: https://newvirus.kaspersky.com
Not sure if we can do anything else than submit url to installer (https://github.com/shellscape/Gmail-Notifier-Plus/releases/download/v3.8/Gmail-Notifier-Plus-3.8.msi) via that form.

Received an email from a user with HitmanPro, claiming there was a trojan in the update:

Hi, I've been using Gmail Notifier Plus for some time now and like it. HitmanPro is saying, however, that there is a Trojan in the files after the most recent update. Do you have any information on this?

I'm no longer on Windows and don't have access to it, so I cannot verify.

I've performed a multiclient online scan, and a scan on Sophos for mac with only hits on Kaspersky clients and clients which depend on Kaspersky data:

These results point to false positives. Will leave the issue open for additional input.


GitHub extension PRs and issues are not persisting after restart

Dev Home version
<IP_ADDRESS>
Windows build number
10.0.23493.1000
Other software
OS Build Version: 10.0.23493.1000.amd64fre.ni_prerelease.230624-1828
.NET Version: .NET 6.0.16
Steps to reproduce the bug

Add pinned widgets for PRs and issues from GitHub
Restart the PC
Open Dev Home

Expected result
To see the pinned widgets on the dashboard
Actual result
The dashboard has no widgets at all
Included System Information
Physical Memory: 31.69GB (12.64GB free)
Processor Architecture: x64
Included Extensions Information
Extensions:
Microsoft.Windows.DevHome_<IP_ADDRESS>_x64__8wekyb3d8bbwe
Microsoft.Windows.DevHomeGitHubExtension_<IP_ADDRESS>_x64__8wekyb3d8bbwe

Duplicate of #742


distrubutes ServiceResource throughout path

Adds utilization of the ServiceResource struct to all of
the path package functionality.  In general, this takes
most instances where a service and resource
are requested, and replaces those values with a
slice of ServiceResource tuples.
To keep the review smaller, this change does not update
any packages outside of path.  Therefore the tests and
build are guaranteed to fail.  The next PR, which
updates all other packages with the changes, is
necessary for both PRs to move forward.

Does this PR need a docs update or release note?

[x] :no_entry: No

Type of change

[x] :sunflower: Feature

Issue(s)

#3993

Test Plan

[x] :zap: Unit test
[x] :green_heart: E2E

closing: not going to use this pattern


Add Support for C++ plugin system

Update the AR2 resolver plugin to support OpenAssetIO's C++ plugin system.
Acceptance Criteria
Update use of plugin system in AR 2 resolver to use prefer the C++ plugin system.
Test against C++ manager plugin.
Dependent on: https://github.com/OpenAssetIO/OpenAssetIO/issues/1324

Whilst developing this we discovered that the PyPI build of OpenAssetIO cannot load C++ manager plugins.
This is because the PyPI build uses a single shared library (the Python extension module) with the core C++ library baked into it from a static library.
This causes two problems:

Our build system setup is designed to block all symbols from being exported except for those explicitly made visible. This means the Python extension module hides the symbols from the "foreign" C++ core library, so there are no symbols for a C++ manager plugin to link to.
Python extension modules are loaded by the Python interpreter using RTLD_LOCAL (on POSIX), which prevents symbols from "leaking" between binaries, so even if our Python extension module exposes the necessary symbols, they will be "blocked" from other shared libraries.

The first problem could be solved by refactoring our build system to allow the libopenassetio.a library's symbols to be exported from the _openassetio.so Python extension module. This means

No longer having CMake generate an export.h header (generate_export_header()), since the generated export header for a static library is just a stub without any visibility flags. Instead, we would have to roll our own that works for both static and shared libraries and across platforms (lots of other projects do this).
Ensure we use $<LINK_LIBRARY:WHOLE_ARCHIVE,openassetio-core>, so that all symbols, not just those used by the Python extension module, are exported from the static library.
Somehow exclude the core C++ library from the --exclude-libs,ALL linker argument, probably requiring us to eschew ALL and instead provide an explicit list of what libraries to exclude.

The second problem is more serious, though easier to "fix".

We have to override the flags using sys.setdlopenflags(os.RTLD_GLOBAL | os.RTLD_LAZY)
However, the Python docs say

Portability therefore requires not to make any assumptions about symbol visibility. This means that all symbols in extension modules should be declared static, except for the module’s initialization function, in order to avoid name clashes with other extension modules [...] And it means that symbols that should be accessible from other extension modules must be exported in a different way.

That last point especially means that the correct solution would be to split the Python extension module and the core C++ (shared) library, so that the extension module can depend on the shared library, as can plugins.
In the past this caused problems with linker search paths, however.  On Linux we have RPATH and on macOS we have @loader_path, but on Windows we have nothing. Fixing this will take further experimentation/consultation.


Add Watsonx provider with tests using the python SDK

Summary of Changes
Implemented WatsonxProvider class in watsonx_provider.py.

Added methods for initializing the provider, creating chat completions, and normalizing responses.

Created a guide for Watsonx in watsonx.md.

Included instructions for setting up a Watsonx account, obtaining API credentials, setting environment variables, and creating chat completions using aisuite.

Added unit test for WatsonxProvider in tests/test_watsonx_provider.py.

Also add Watsonx test for test_client.py

@ksolo found some issues upon revisiting the code and pushed the fixes


Rename RELEASING.md to RELEASING.md.template

This follows the naming convention used for other template files within this project.

+1


New version: Hecke v0.22.8

Registering package: Hecke
Repository: https://github.com/thofma/Hecke.jl
Created by: @thofma
Version: v0.22.8
Commit: 1aab0d4f6a5118891b3865423f23a9ee596f056b
Reviewed by: @thofma
Reference: https://github.com/thofma/Hecke.jl/commit/1aab0d4f6a5118891b3865423f23a9ee596f056b#commitcomment-133336280
Description: Computational algebraic number theory

Sorry, I did an oopsie. This can be closed.


Headers are not treated as case insensitive

I'm submitting a bug report

Library Version:
1.0.0

Please tell us about your environment:

Operating System:
Ubuntu 16.04

Node Version:
6.3.1

NPM Version:
3.10.3

JSPM OR Webpack AND Version
any

Browser:
all | Chrome | Firefox

Language:
all

Current behavior:
The current implementation of Headers isn't case-insensitive since the get(key: string) function just uses the argument as an key without any normalization. If the response header name was ETag and I try to get etag the function has(key: string) returns true because it's case insensitive, but get(key: string) returns false because it's case sensitive.
Expected/desired behavior:
Regarding the RF2616 section 4.2 standard all message header names (general-, request-, response- and entity-headers) has to be handled as case insensitive.

What is the expected behavior?
With response header ETag: soemthing the function get(key: string) and has(key: string) should return true with the parameter etag, ETAG, ETag and any other case combination.

What is the motivation / use case for changing the behavior?
Firefox 49.0 seem convert the Header names in some abstruse way while Chrome 51.0.2704.79 doesn't. Therefore headers in Chrome are handled properly but not in Firefox and the other way.

@fragsalat Any interest in making a PR to fix this?

@EisenbergEffect I'll do for sure :smile:

Fantastic. Thank you!

This is pretty urgent: starting with the latest Chrome version (53.0.2785.143) all header names are lowercased and it breaks content-type recognition, thus breaking any Aurelia application which trusts http-client's responseType.


conform-prAction  should check PR description

It should check that the PR description ends with a dot. In particular, it should not end with whitespace.

@AlekSi what if PR description is empty? Should it be considered as valid?
Also, I'll call the checker checkBody, not checkDescription as in Github API this field is called "body", not "description".

@AlekSi would such output work? Or would you prefer different formatting?

Answers:

Empty description is valid
Various punctuation is possible (?, !, etc)
Leave such formatting for now (we will use md in the future)


Add Messaging Troubleshooting guide for Java to docs.microsoft.com

Tracking issue to add conceptual doc topics, such as troubleshooting tips, to https://docs.microsoft.com/en-us/azure/developer/java/sdk for Messaging (AMQP based) client libraries.
/cc @conniey @anuchandy @ki1729

Add documentation about low-level receivers:

Document that the Receiver(s) can throw; hence application should be prepared to handle it - Shutdown-Gracefully Or App-level Retry.

After retries are exhausted, it can throw.

Inform the spring team building on the top of Low-Level Receiver to expect this;

The az-spring libs should either do their own retry or notify necessary spring hooks so that the app can Shutdown-Gracefully.

Should do this before #20991


Make shift-tab go to the previous corner in the calibration grid

What the title says. Tabbing takes you to the next corner, my muscle memory tells me shift-tab should go counterclockwise. I missed this a few times in my dogfooding cutting session yesterday.

I’ve been thinking this one as well. Just keep forgetting to write it down. Thank you!


[BUG]: Log purge correctness

Closes #2922
Closes #2912
It might be related to #2905
Description of changes
Summarize the changes made by this PR.

Improvements & Bug fixes

...

New functionality

...

Test plan
How are these changes tested?

[ ] Tests pass locally with pytest for python, yarn test for js, cargo test for rust

Documentation Changes
Are all docstrings for user-facing APIs updated if required? Do we need to make documentation changes in the docs repository?

#2923  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @tazarov and the rest of your teammates on  Graphite

This needs a rebase after #2924 merge to resolve the linting issue.

I believe there is a property test for log purging. I think @codetheweb - we should update it for this case.

Log purging is generally tested in the embedding state machine (chromadb/test/property/test_embeddings.py), but that state machine only deals with a single collection. I don't think we currently have a multi-collection property test that adds data to collections, maybe we can update chromadb/test/property/test_collections.py. Given the severity of the bug I would personally rather merge with an ok test for now and then add/update a proptest in a future PR.

I didn't say to block the PR on that.

Merge activity

Oct 10, 1:41 PM EDT: A user started a stack merge that includes this pull request via Graphite.


[Bug] Plugins are blank

Describe the Bug
get nothing but this error in console:
TypeError: Cannot read property 'getName' of undefined
    at V2C_PluginCard.setInitialState (main.min.js:55)
    at new PluginCard (main.min.js:55)
    at Co (2e9d0ce55589ffe3f1fb.js:73)
    at Za (2e9d0ce55589ffe3f1fb.js:73)
    at Ps (2e9d0ce55589ffe3f1fb.js:73)
    at Gu (2e9d0ce55589ffe3f1fb.js:73)
    at wu (2e9d0ce55589ffe3f1fb.js:73)
    at yu (2e9d0ce55589ffe3f1fb.js:73)
    at 2e9d0ce55589ffe3f1fb.js:73
    at t.unstable_runWithPriority (2e9d0ce55589ffe3f1fb.js:81)
    at Ji (2e9d0ce55589ffe3f1fb.js:73)
    at Zi (2e9d0ce55589ffe3f1fb.js:73)
    at $i (2e9d0ce55589ffe3f1fb.js:73)
    at gu (2e9d0ce55589ffe3f1fb.js:73)
    at fc (2e9d0ce55589ffe3f1fb.js:73)
    at Tc (2e9d0ce55589ffe3f1fb.js:73)
    at Object.render (2e9d0ce55589ffe3f1fb.js:73)
    at V2_SettingsPanel.renderPluginPane (main.min.js:55)
    at V2_SettingsPanel.sideBarOnClick (main.min.js:55)
    at onChange (main.min.js:55)
    at Object.b.ModuleUtils.forceAllUpdates (BDFDB.min.js:1)
    at A (BDFDB.min.js:1)
    at BDFDB.min.js:1
    at NodeList.forEach (<anonymous>)
    at BDFDB.min.js:1
    at Array.forEach (<anonymous>)
    at MutationObserver.<anonymous> (BDFDB.min.js:1)
gs @ 2e9d0ce55589ffe3f1fb.js:73
Ds.n.callback @ 2e9d0ce55589ffe3f1fb.js:73
Oo @ 2e9d0ce55589ffe3f1fb.js:73
Ao @ 2e9d0ce55589ffe3f1fb.js:73
Fu @ 2e9d0ce55589ffe3f1fb.js:73
t.unstable_runWithPriority @ 2e9d0ce55589ffe3f1fb.js:81
Ji @ 2e9d0ce55589ffe3f1fb.js:73
Yu @ 2e9d0ce55589ffe3f1fb.js:73
yu @ 2e9d0ce55589ffe3f1fb.js:73
(anonymous) @ 2e9d0ce55589ffe3f1fb.js:73
t.unstable_runWithPriority @ 2e9d0ce55589ffe3f1fb.js:81
Ji @ 2e9d0ce55589ffe3f1fb.js:73
Zi @ 2e9d0ce55589ffe3f1fb.js:73
$i @ 2e9d0ce55589ffe3f1fb.js:73
gu @ 2e9d0ce55589ffe3f1fb.js:73
fc @ 2e9d0ce55589ffe3f1fb.js:73
Tc @ 2e9d0ce55589ffe3f1fb.js:73
render @ 2e9d0ce55589ffe3f1fb.js:73
renderPluginPane @ main.min.js:55
sideBarOnClick @ main.min.js:55
onChange @ main.min.js:55
b.ModuleUtils.forceAllUpdates @ BDFDB.min.js:1
A @ BDFDB.min.js:1
(anonymous) @ BDFDB.min.js:1
(anonymous) @ BDFDB.min.js:1
(anonymous) @ BDFDB.min.js:1

To Reproduce
Click on Plugins in Settings.
Expected Behavior
Should be able to see a list of plugins to enable/disable.
Screenshots

Discord Version
Stable

You can try reloading, but this is an issue with DevilBro's library

Reloading did not work. I'll open an issue over there, thanks!


Update library to Python 3

I've updated python-fitparse to run on Python 3.
As a part of this update and in order to test generate_profile.py script I also updated FIT SDK to 13.20 released recently.

Seems that @dtcooper is no longer maintaining this project. Perhaps we can merge this PR and others and create a new fork and upload an stable version to PyPI. What do you think?

That is me. I should probably get on that.
On Tuesday, 21 April 2015, Marc<EMAIL_ADDRESS>wrote:

Seems that @dtcooper https://github.com/dtcooper is no longer
maintaining this project. Perhaps we can merge this PR and others and
create a new fork and upload an stable version to PyPI. What do you think?
—
Reply to this email directly or view it on GitHub
https://github.com/dtcooper/python-fitparse/pull/13#issuecomment-94714502
.

I'm glad to see you are alive! thanks @dtcooper

@dtcooper Great! If you need any help, just drop me a line.
@marctc Looks like there is no need to fork.

@kropp yep!


[Bug]: The variable 'step_rew_funcs' is not defined in BaseReward class.

🐛 Bug
The variable 'step_rew_funcs' is not defined in BaseReward class. In addition, the 'step' function of the RewardWrapper class should also be modified accordingly.
'
if extra_data:
extra_data.update({"actions": action})
extra_data.update({"obs": obs})
extra_data.update({"rewards": rewards})
extra_data.update({"dones": dones})
extra_data.update({"infos": infos})
rewards, new_infos = self.reward_class.step_reward(data=extra_data)
        num_envs = len(infos)
        for i in range(num_envs):
            infos[i].update(new_infos[i])

'
To Reproduce
from openrl import ...

Relevant log output / Error message
Traceback (most recent call last):
  File "/data/workspace/openrl/examples/cartpole/train_ppo.py", line 39, in <module>
    agent = train()
  File "/data/workspace/openrl/examples/cartpole/train_ppo.py", line 17, in train
    agent.train(total_time_steps=20000)
  File "/data/workspace/openrl/openrl/runners/common/ppo_agent.py", line 134, in train
    driver.run()
  File "/data/workspace/openrl/openrl/drivers/onpolicy_driver.py", line 227, in run
    self._inner_loop()
  File "/data/workspace/openrl/openrl/drivers/onpolicy_driver.py", line 112, in _inner_loop
    rollout_infos = self.actor_rollout()
  File "/data/workspace/openrl/openrl/drivers/onpolicy_driver.py", line 189, in actor_rollout
    obs, rewards, dones, infos = self.envs.step(actions, extra_data)
  File "/data/workspace/openrl/openrl/envs/vec_env/wrappers/vec_monitor_wrapper.py", line 37, in step
    returns = self.env.step(action, extra_data)
  File "/data/workspace/openrl/openrl/envs/vec_env/wrappers/reward_wrapper.py", line 50, in step
    infos[i].update(new_infos[i])
IndexError: list index out of range

System Info
No response
Checklist

[X] I have checked that there is no similar issues in the repo
[X] I have read the documentation
[X] I have provided a minimal working example to reproduce the bug
[X] I have version numbers, operating system and environment, where applicable

Maybe you guys should run all the examples before releasing it.

bug fixed in #29


[SPARK-46569][SQL] Remove ThreadLocal due to SecureRandom is thread safe since JDK9

What changes were proposed in this pull request?
This PR propose to remove ThreadLocal due to SecureRandom is thread safe since JDK9.
Why are the changes needed?
Spark already upgraded the JDK version to 17.
Before JDK9, we use ThreadLocal to keep the thread safe for SecureRandom.
There are some javadoc of SecureRandom since JDK9 show below.

Now, we can remove ThreadLocal due to SecureRandom is thread safe since JDK9.
Does this PR introduce any user-facing change?
'No'.
How was this patch tested?
GA tests.
Was this patch authored or co-authored using generative AI tooling?
'No'.

+CC @srowen

The GA failure is unrelated.
Merged to master. @mridulm @srowen @LuciferYang Thank you!

It seems that the previous merging failed.
I merged this to master for Apache Spark 4.0.0. Thank you, @beliefer and all.

@dongjoon-hyun Thank you very much!
I use a new computer and the the dev environment seems works bad. I will check my environment.


fix fix that missed rows don't match merged rows

Proposed changes
Issue Number: close #xxx
Problem summary
Due to concurrent load, there may be duplication in the delete bitmap of historical data and incremental calculations, resulting in duplicate calculations of missed rows.
Checklist(Required)

[ ] Does it affect the original behavior
[ ] Has unit tests been added
[ ] Has document been added or modified
[ ] Does it need to update dependencies
[ ] Is this PR support rollback (If NO, please explain WHY)

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


Possibility to override default search method

Q1 . Is it currently possible to override the default search method ?
I need to get the search results from an API instead of doing some client search ?
Q2. Is it possible to find an element by something else other that the text ?
I did the following
tree.find({ id : childNodeId }) // wrong result

but going this approach got me the right results
tree.find( n => n.id === childnodeid ) // right result

Q1 . Is it currently possible to override the default search method ?

You can pass a function to override the default behaviour.

tree.find({ id : childNodeId }) // wrong result

It works for me. This method returns Selection API.

Q1 . Is it currently possible to override the default search method ?

You can pass a function to override the default behaviour.

What's the method to override ?

tree.find({ id : childNodeId }) // wrong result

It works for me. This method returns Selection API.

Odd. I tried using it yesterday and it returned the rootNode instead of the first child node.

For example:
const treeData = [
  {text: 'D15', data: {d: 15}},
  {text: 'D20', data: {d: 20}},
  {text: 'D25', data: {d: 25}},
]

const items = this.$refs.tree.findAll(node => node.data.d >= 20)

Q1 . Is it currently possible to override the default search method ?
You can pass a function to override the default behaviour.

Still having figured out how to override the default search behavior.
I'd appreciate if you could do showcase/example how to.
This is the approach I tried
treeOptions: {
     minFetchDelay: 500,
     dnd: true,
     filter: function (query) {
           console.log(query) // still does the same work
     },

Ohh. Search and filtering are slightly different.

To override filtering:

filter: {
    matcher(query, node) {
        return query == node.data.complexity
    },
    showChildren: false
}

To find node (and proceed to use it via API):

const node = this.$refs.tree.find({text: /^text/})

const node = this.$refs.tree.find({state: disabled})

const node = this.$refs.tree.find(node => {
  return node.data.SOME_PROP === 55
})

You will find a lot of examples if you clone repo and npm run dev

I already cloned the project, there's much I gotten out if it to be honest.
What I actually want to do is, instead of doing the search on the front, I want to send a request to the backend.
The snippets you posted are fine when filtering/searching on the front, but since I'm asynchronysly load the children, going down this approach won't help me.

I can help you if you show me what you want to do. Snippets below can solve almost any possible problem (I think...):
fetchData(node) {
  // Here you do search on the server.
  return fetch(`/searchAPI?nodeID=${node.id}`).then(r => r.json())

 // you can send whatever you want
 return fetch(`/searchAPI?p=${node.data.p}&d=${node.data.d}`).then(r => r.json())
}

Also you can do search on client side. For example you have a huge array of data (const users = []).
 fetchData(node) {
   return new Promise(resolve => {
     resolve(
       users.filter(user => node.data.roles.includes(user.role))
     )
   })
 }

Note that this method calls only if node has isBatch property.


MacVim Release 155 appears to be broken

I just now was prompted by MacVim to upgrade to the latest release.  When I allowed MacVim to perform the update and restart, I immediately began getting the following errors when I tried to enter using insert mode:
Error detected while processing function <SNR>49_HighLightEOLWhitespaceExceptionCurrentLine: line   1: E461: Illegal variable name: a:exclude_current_line_eol_whitespace_pattern Press ENTER or type command to continue.
I have MacVim 8.1.950 (155) running on macOS 10.12.6.

I couldn't reproduce this. I searched online and seems like you are using https://github.com/ntpeters/vim-better-whitespace? I downloaded the plugin and it still works fine.
The variable (exclude_current_line_eol_whitespace_pattern) that your logs show seems to indicate it's an old build as it was removed in https://github.com/ntpeters/vim-better-whitespace/pull/100. I would suggest updating the plugin and/or re-downloading it.
If the issue persists, try running MacVim with mvim -u NONE -U NONE (in general it's a good idea to do so to help isolate problems) and that fixes the problem, you may want to file the issue with the plugin's repo.

Looking more into it I'm pretty sure you just need to update your plugin. Vim has recently introduced a new behavior that tightened the restrictions on writing VimScript, and you can no longer assign to a: variables. The older version of the plugin has a bug of writing to a: that gets exposed in the new version of Vim.
If you can confirm the new version of the plugin fixes the issue, please close the issue.

Updating the plugin fixed the error for me; thanks a lot @ychin 👍

Closing, since this can be fixed by updating plugin.


Use Relaxed ordering mode

The Relaxed ordering mode is much more efficient than SeqCst and its good enough for the use case of either loading statistics or updating the current statistic with a delta.
I had a wrong understanding of the ordering mode and I apologize for the confusion. I have updated the code to use Relaxed ordering mode instead of SeqCst. This will make the code more efficient and will be good enough for the use case of either loading statistics or updating the current statistic with a delta.
As an example here for example what ordering mode is used by tokio for incrementing the number of threads created.
There is a good explanation about the semantics of the ordering parameter in this book, specifically this section, which explains that the memory ordering is about the ordering of the atomic instructions rather than the synchronization of the threads for a specific memory address

Makes sense, thanks!


Repository description uses incorrect capitalization for macOS

Describe the bug
The repository description says “C++ Library Manager for Windows, Linux, and MacOS”. The M in “MacOS” should not be capitalized.
Environment

OS: Linux
Browser: Firefox 129.0

To Reproduce
Steps to reproduce the behavior:

Go to https://github.com/microsoft/vcpkg.
Look for the “About” heading in the right-hand column.
Read the repository description that’s beneath the “About” heading.

Expected behavior
macOS should be written with a lowercase m. “macOS” is the official capitalization (source).

@data-queue
I don't have permission to edit the About section, and there's no gear icon to click. Could you help me make the changes?


Failed test when installing

Trying to install on a Mac with Chrome  v. 70.0.3538.110.
I'm failing a test:
#   Failed test 'The two links were found'
#   at t/51-mech-links.t line 72.
#          got: '3'
#     expected: '2'
# relative
# myiframe
# http://searchguide.level3.com/search/?q=http://somewhere.example/myiframe&t=0
# Looks like you failed 1 test of 7.
t/51-mech-links.t ................
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/7 subtests

Hello Steve,
this seems to be an indication that your machine or your browser has been infected by some "Search Plugin" redirector. The complete distribution doesn't contain the words searchguide.level3.com or searchguide. Either you have installed a nasty browser plugin that secretly shares "your" surf data with the outside world or your machine itself has been infected by such a program. At least a cursory Google search for searchguide.level3.com turns up lots of pages that claim to help removing something like this, but I don't know which site or what recipe is a good recipe there.
Sorry to be the bearer of bad news...

Thanks for getting back. Turned out it was an extension that helped me find content in open tabs. I turned it off and I get no more error on installation now.


support for SH1106

Hi,
Any chance of supporting the SH1106 as well?
The only difference seems to be the size of the memory buffer, like described here
https://forum.arduino.cc/index.php?topic=256374.0

There is only one small difference between SSD1306 and SH1106: The SH1106 controller has an internal RAM of 132x64 pixel. The SSD1306 only has 128x64 pixel.
First problem for standard 128x64 OLEDs with SH1106 controller is: How is the 128x64 window mapped into the 132x64 RAM?
It seems, that the 128x64 OLED is centered in most cases within the 132x64 area, that means pixel (2,0) in ram is pixel (0,0) on the display.
For u8glib, the update for the SH1106 was very small. I just had to shift the display by 2 pixel. This is more complicated with the Adafruit lib.

Cheers
/edit ebay 1.3" oled's seem to use this chip. i don t actually know if it displays all pixels or it s just cropped to the center 128 px.

+1

I would also appreciate if you can include SH1106 support

I can do testing and debug for you on the ESP8266 - Digidtump Oak -  and the SH1106

If you want to change it on your own: http://blog.squix.org/2015/12/esp8266-weather-station-new-version.html#comment-400

I can add support for SH1106 once I get one of those 1.3'' modules. The foundation for this is #41.

Hi guys,
just to be sure I'm not missing something, SH1106 displays are not yet supported in v3.0.0 ? correct ?
I've got some so if anyone can point me where to do modifications in v3.0.0, I can test and do PR.
I imagine I need to create a new file SH1106Wire.h for example but I think modification are so small that may be some #ifdef OLED_TYPE_SH1106in SSD1306Wire.h and a new SH1106.h lcontaining new define symbol for SH1106 could be easy ?
// File SH1106.h
#ifndef SH1106_h
#define SH1106_h
#define OLED_TYPE_SH1106
#include "SSD1306Wire.h"
#endif

just let me know

Hi @hallard
currently it is not supported, yes. The changes that i had linked are valid for an older version. Maybe this: https://github.com/rene-mt/esp8266-oled-sh1106 helps to figure out what needs to be changed?
Best Regards, Uli

Yeah, I remember I already done this for My ArduiPi OLED for SH1106 support, apparently one diff on init and other when transferring data but with this new lib there is some minBoundY and maxBoundY that I'm not sure to understand, and having time to think about this.

I guess the problem is that neither Fabrice nor me have a display for development. I will order one now but it will take a whlie until it arrives. In the meantime you are more than welcome to create a pull request.

Should be okay with this PR

I got this one within a few days for 10Euro (shiiping from germany) from Eckstein-Shop:
Waveshare 1.3 inch 128x64 OLED SPI/I2C Interfaces vertical/horizontal pinheader SH1106
So i vote +1
Best regards
Dirk

Released in 3.2.1

tested and works great btw


@types/promise-mysql Typescript Typings

Any plans to include an index.d.ts with the project?

I don't use typescript myself, but if someone wants to submit a pull
request I'll be happy to merge it.
On Wed, 24 May 2017, 18:29 move-zig<EMAIL_ADDRESS>wrote:

Any plans to include an index.d.ts with the project?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/lukeb-uk/node-promise-mysql/issues/53, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AEjy1Pwz4atsgOwprYDyQcK4Z39lyFVSks5r9GkOgaJpZM4Nlbdj
.


Feature: Self-Type-Checking Types

TLDR: The following introduces and explains what this PR does, but to get a very rough idea see the self-types-string-literal.ts and self-types-case-insensitive.ts tests.
Self-Type-Checking Types
One of the most popular category of feature requests are new type constructs, some examples include exact types (#12936), json type (#1897), regex types (#41160), negated types (#4196), tuple-from-union type (#13298) and more.
But probably very few people realise you can implement almost any new type construct entirely in userland without having to make changes to the compiler. Of course it has some downsides which is precisely what this PR tackles.
But first let me show you how you'd implement a new type construct, what are the problems with it, what are the current workarounds to those problems and how this PR eliminates having to use these workarounds. For example let's implement the string literal type (#51513), it's an extremely simple and reasonable feature request (see the linked issue description), so it'll make a good example.
Implementing a new type construct userland
The idea is simple, we want a new type called StringLiteral which is subtype of all string literals but not string. You'd use it like this...
declare const query:
  (q: StringLiteral) => Promise<unknown>

query("test") // should compile
query(document.title) // should not compile
query(0) // should not compile

Now implementing this is rather simple...
type StringLiteral<Self> =
  Self extends string
    ? string extends Self
        ? never
        : Self
    : string

declare const query:
  <T>(q: StringLiteral<T>) => Promise<unknown>

query("test")
// compiles

query(document.title)
// doesn't compile
// Argument of type 'string' is not assignable to parameter of type 'never'

query(0)
// doesn't compile
// Argument of type 'number' is not assignable to parameter of type 'string'

But there are two problems with this approach...
Problem A: No error messages
The first problem is the lack of error messages. "Argument of type 'string' is not assignable to parameter of type 'never'" doesn't tell what the error is, ie the user of query would ask themselves why does query takes an argument of type never in the first place? Then they'd see the type declaraion of query and then realise that what it really wants is a string literal.
Also note that the type could resolve to different nevers for different errors (here the error is only one) but it'd be impossible to see where did the never came from (eg from which branch), because all nevers are the same.
Simply put, the nevers implicitly carry an error given by the author but it doesn't reach the user.
Workaround for Problem A: String literals with error messages
The workaround for this problem is silly but simple, you just resolve to a string literal with an error message instead of never...
type StringLiteral<Self> =
  Self extends string
    ? string extends Self
        ? "Error: Not a string literal"
        : Self
    : string

declare const query:
  <T>(q: StringLiteral<T>) => Promise<unknown>

query(document.title)
// doesn't compile
// Argument of type 'string' is not assignable to parameter of type '"Error: Not a string literal"'

The error message "Argument of type 'string' is not assignable to parameter of type '"Error: Not a string literal"'" reads silly but it does the job putting across what the error is. And with this all errors also become distinct they are no longer nevers.
Problem B: It's not easy to compose the type
Imagine we have an existing piece of code that looks something like this...
type Order =
  { id: number
  , meta: { securityRemark: string }
  }

declare const placeOrder:
  (o: Order) => void

Now one day we realise we want securityRemark to be a hard-coded string literal. Guess what the diff looks like...
type Order<Self> =
  { id: number
  , meta: { securityRemark: StringLiteral<Prop<Prop<Self, "meta">, "securityRemark">> }
  }

type Prop<T, K> =
  K extends keyof T ? T[K] : never

declare const placeOrder:
  <T extends Order<T>>(o: T) => void

So you see the type StringLiteral<Self> is not easily composible, had it been a type without type parameters we'd have just replaced string with StringLiteral.
And composing it like so is a nightmare because the type parameter propagates all the way to the root of the dependence tree. Ie imagine we had a type Factory that depends on type LineUp that depends on type Order. Now turning Order into Order<Self> would mean that we need to compose Order in LineUp in this same fashion turning LineUp into LineUp<Self> and finally Factory into Factory<Self>
And not to mention it also breaks existing code at places like...
let order: Order = {
//         ~~~~~
// Generic type 'Order' requires 1 type argument(s).
  id: 0,
  meta: { securityRemark: "test" }
}

Workaround for Problem B: Use an opaque type with a constructor
We can solve this problem of composition by using the type-parameter version of StringLiteral only while constructing the final non-type-parameterized type...
type StringLiteral =
  & string
  & { readonly __tag: unique symbol }

type ParseStringLiteral<Self> =
  Self extends string
    ? string extends Self
        ? "Error: Not a string literal"
        : Self
    : string

declare const s:
  <T>(t: ParseStringLiteral<T>) => StringLiteral

With this we can now simply replace string with StringLiteral in our existing types with the drawback being we'll have to use s everywhere we're constructing a string literal...
type Order =
  { id: number
  , meta: { securityRemark: StringLiteral }
  }

let order: Order = {
  id: 0,
  meta: { securityRemark: s("test") }
}

Another less significant drawback being now the constructed type loses some information ie instead of being a string literal type "test" it's now the type StringLiteral.
How this PR solves Problem A and B
With this PR you can now write StringLiteral as the following which solves both problem A and problem B...
type StringLiteral =
  self extends string
    ? string extends self
        ? Never<`Type '${Print<self>}' is not assignable to type 'StringLiteral'`>
        : self
    : string

This PR roughly brings these three changes...

Type aliases can now reference an implicit type parameter called self, which gets instantiated with the type-being-related-to while checking for a type relation (eg the subtype relation).

There now is a global intrinsic type alias called Never that resolves to a never but takes a type argument of string literal or a tuple of string literals that gets displayed as error message or stacks of error messages instead of error messages like "Type 'X' is not assignable to 'never'".

There now is a global instrinsic type alias called Print that takes a type as an argument and resolves to the print of that type as a string literal type.

What is this Foo<Self> pattern, why it works and why it's called self-type-checking?
A type is a set of values. A set of values is a propositional function that takes a value. Which implies a type is a propositional function that takes a value. Which is exactly what Foo<Self> types are: they take a value (as a type) and return true (as unknown type) or false (as never type)...
type NonZeroNumber<Self> =
  Self extends number
    ? Self extends 0
        ? never
        : unknown
    : never

declare const divide:
  <T extends [NonZeroNumber<T[0]>]>(a: number, ...b: T) => number

divide(1, 0 as 0)
// doesn't compile, argument of type 'number' is not assignable to parameter of type 'never'.

divide(1, 1 as 1)
// compiles

But there's a richer way to think about this... The compiler has a algorithm to check if a source type is subtype of target type and to produce errors if it's not. But given TypeScript's type system is turing-complete what if that subtype-checking algorithm is expressed in a type itself? So when a compiler wants to check the subtype relationship between a self-type-checking source type and a target type, it passes the target type to the self-type-checking type which in turns does the type-checking and produces required errors.
For example let's recreate mapped types without using TypeScript's mapped types, that is to say write our own type-checking algorithm for mapped types and not use the one in TypeScript compiler's source. Imagine we have a mapped type called FlipValues<T, K1, K2>...
type User =
  { name: string, age: number }

let t0: FlipValues<User, "name", "age"> = {
  name: "foo",
  age: "foo"
}
// doesn't compile
// Type 'string' is not assignable to type 'number'.
//   The expected type comes from property 'name' which is declared here on type 'FlipValues<User, "name", "age">'

let t1: FlipValues<User, "name", "age"> = {
  name: 0,
  age: "foo"
}
// compiles

type FlipValues<T, K1 extends keyof T, K2 extends keyof T> =
  { [K in keyof T]:
      K extends K1 ? T[K2] :
      K extends K2 ? T[K1] :
      T[K]
  }

This is how we create the FlipValues<T, K1, K2> without using mapped types... (No need to read too much into it, this is for the curious and advanced typescripters)
type User =
  { name: string, age: number }

let t0: FlipValues<User, "name", "age"> = {
  name: "foo",
  age: 0
}
// doesn't compile
// Type '{ name: string; age: number; }' is not assignable to type 'FlipValues<User, "name", "age">'
//   Type '{ name: string; age: number; }' is not assignable to type '{ age: string; name: number; }'
//     Types at property 'age' are incompatible
//       Type 'number' is not assignable to type 'string'

let t1: FlipValues<User, "name", "age"> = {
  name: 0,
  age: "foo"
}
// compiles

let t32: FlipValues<User, "name", "age"> = {
  name: 0
}

type FlipValues<T, K1 extends keyof T, K2 extends keyof T> =
  Mapped<
    keyof T, "FlipValues",  [T, K1, K2],
    `FlipValues<${Print<T>}, ${Print<K1>}, ${Print<K2>}>`
  >

interface Mappers<K, A>
  { FlipValues:
      A extends [infer T, infer K1, infer K2]
        ? K extends K1 ? T[K2 & keyof T] :
          K extends K2 ? T[K1 & keyof T] :
          T[K & keyof T]
        : never
  }

/**
 * @param K key of new type
 * @param F mapper identifier
 * @param A extra argument to mapper
 * @param N name of new type
 */
type Mapped<K, F, A, N> =
  MappedError<K, F, A, N, self> extends infer E extends string | string[]
    ? [E] extends [never] ? self : Never<E>
    : never

type MappedError<K, F, A, N, Self, KCopy = K> =
  UShift<
    K extends unknown
      ? K extends keyof Self
          ? Get<Mappers<K, A>, F> extends infer Fka // F<K, A>
              ? Self[K] extends Fka
                  ? never
                  : [ `Type '${Print<Self>}' is not assignable to type '${N & string}'`
                    , `Type '${Print<Self>}' is not assignable to type '${PrintMapped<KCopy, F, A>}'`
                    , `Types at property '${PrintKey<K>}' are incompatible`
                    , `Type '${Print<Self[K]>}' is not assignable to type '${Print<Fka>}'`
                    ]
              : never
          : [ `Type '${Print<Self>}' is not assignable to type '${N & string}'`
            , `Type '${Print<Self>}' is not assignable to type '${PrintMapped<KCopy, F, A>}'`
            , `Property '${PrintKey<K>}' is required in target type but missing in source type`
            ]
      : never
  >

interface Mappers<K, A> {}

type PrintMapped<K, F, A> =
  `{ ${Join<
    K extends unknown
      ? `${PrintKey<K>}: ${Print<Get<Mappers<K, A>, F>>};`
      : never,
    " "
  >} }`

type Join<T extends string, D extends string> =
  UIsUnit<T> extends true ? `${T}` :
  `${Cast<UShift<T>, string | number>}${D}${Join<UShifted<T>, D>}`

type UShift<U> =
  UToIntersection<U extends unknown ? (x: U) => void : never> extends (_: infer H) => void
    ? H
    : never

type UToIntersection<T> =
  (T extends unknown ? (_: T) => void : never) extends ((_: infer I) => void)
    ? I
    : never

type UShifted<U> =
  Exclude<U, UShift<U>>

type UIsUnit<U> =
  [UShifted<U>] extends [never] ? true : false

type Cast<T, U> =
  T extends U ? T : U

type PrintKey<K> =
  K extends symbol ? Print<K> :
  K extends string ? K :
  K extends number ? K :
  never

type Get<T, K> =
  K extends keyof T ? T[K] : never

So you see the type-checking algorithm is in the type itself ie it type-checks on it's own, hence they're called self-type-checking types.
A simple yet powerful example
I chose the StringLiteral example to give an introduction with because it was the simplest and later the FlipValues mapped type without using mapped types example to show how powerful these types are, but now let me give a simple yet powerful example by creating a type for case-insenstive string literals...
type CaseInsensitive<T extends string> =
  self extends string
    ? Lowercase<self> extends Lowercase<T>
        ? self
        : Never<[
          `Type '${Print<self>}' is not assignable to type 'CaseInsensitive<${Print<T>}>'`,
          `Type 'Lowercase<${Print<self>}>' is not assignable to 'Lowercase<${Print<T>}>'`,
          `Type '${Print<Lowercase<self>>}' is not assignable to '${Print<Lowercase<T>>}'`
        ]>
    : T

declare const setHeader:
  (key: CaseInsensitive<"Set-Cookie" | "Accept">, value: string) => void

setHeader("Set-Cookie", "ok")
setHeader("Accept", "ok")
setHeader("SET-COOKIE", "ok")
setHeader("sEt-cOoKiE", "stop writing headers like this but ok")
setHeader("Acept", "nah this has a typo")
// Type '"Acept"' is not assignable to type 'CaseInsensitive<"Set-Cookie" | "Accept">'
//   Type 'Lowercase<"Acept">' is not assignable to 'Lowercase<"Set-Cookie" | "Accept">'
//     Type '"acept"' is not assignable to '"set-cookie" | "accept"'

In mere 10 simple lines of code you can create a new type construct which gives a more correct and richer type to our setHeader function.
This example also shows how creating a new type construct for a type can be a gazillion times more peformant than expressing it with existing type constructs like this...
type CaseInsensitive<S extends string> =
  S extends `${infer H}${infer T}`
    ? `${Lowercase<H>}${CaseInsensitive<T>}` | `${Uppercase<H>}${CaseInsensitive<T>}`
    : S

This produces a union of 2^a0 + 2^a1 + ... + 2^an string literals (n being the number of constituent string literals in the type parameter and ai being the length of i-th string literal). Not only this is slow enough to not to be used, in a limiting case TypeScript itself won't allow using it by giving a "Expression produces a union type that is too complex to represent" error.
Not to mention the error message is readable, expressive and complete.
There are several other interesting example and type constructs that you can find in the tests. For example there are tests that implement exact types (#12936), json type (#1897), and tuple-from-union type (#13298).
Please note that some tests are purposely creative and extreme, the users are not expected to write such complex types, eg self-types-color.ts, self-types-json.ts. And some tests reflect realistic simple usages, eg self-types-string-literal.ts, self-types-case-insensitive.ts, self-types-json-simple.ts, self-types-probability.ts, self-types-non-zero-number.ts, self-types-state-machine.ts.
Future
The Foo<Self> pattern is an organic discovery and not an invention sprung out of thin air. It's something that works. And its working can be cleany traced back to theory. So in some sense all that this PR does is that it facilitates the usage of this natural, working, backed-by-theory pattern.
I've written this PR for fun and as an experiment, so no pressure to merge this in, but it's something I'd like the TypeScript team to consider. If the TypeScript team likes the idea then we can take this PR further and fill in the remaining gaps.
Thanks for reading.

There are some tests that need updating. Most of them are trivial eg addition of a new global completion called "self". So I'll fix the tests soon. Meanwhile you can test the PR in two ways locally... (instructions for those not whose are familiar)

hereby runtests -t self-types*
hereby min and then use locally built compiler for intellisense in vscode by hovering "{}" next to bottom right "TypeScript" then "Select Version" and then the one that has path as "built/local"

Also can the bot create a playground for a failing PR as the build passes nonetheless? sounds too much of an ask haha

about error messages, please take a look at #40468 throw types

First off, thanks for the neat PR. I thought this deserved a bit of a deep dive.
Regarding the implementation of self - in general it doesn't "work" to try to create new assignability rules by, at the top level, checking for special properties of the target type, as happens here. This gets you correct top-level behavior, of course, but higher-level stuff doesn't work like expected:
type Box<T> = { value: T };
type Fooish = CaseInsensitive<"Foo">;
const x1: CaseInsensitive<"Foo"> = "FOO"; // OK
const x2: Fooish = "FOO"; // OK due to alias resolution
const x3: Box<CaseInsensitive<"Foo">> = { value: "FOO" }; // OK
const x4: Box<Fooish> = { value: "FOO" }; // Fails

tbi/a.ts:18:27 - error TS2322: Type '"FOO"' is not assignable to type 'CaseInsensitive<"Foo">'.

18 const x4: Box<Fooish> = { value: "FOO" }; // Fails
                             ~~~~~

A similar problem occurs if you just try to do a refactor on your example:
type HeaderNames = CaseInsensitive<"Set-Cookie" | "Accept">;
declare const setHeader: (key: HeaderNames, value: string) => void
// all invocations fail

I was kind of surprised this didn't work, not sure what's going wrong (I was trying to demonstrate some other stuff but got stuck here):
type DistributeCaseInsensitive<T extends string> = T extends unknown ? CaseInsensitive<T> : never;
// Fails, should be OK
let m: DistributeCaseInsensitive<"A" | "B"> = 'a'

Regarding the feature itself... using self types that don't evince higher-order relational behavior creates very large completeness gaps that would be immediately apparent:
type AnyString<T> = self extends string ? T : never;
function foo<T extends string>(a: CaseInsensitive<T>) {
  let m: AnyString<T> = a;
  //  ~
}

a.ts:15:7 - error TS2322: Type 'CaseInsensitive<T>' is not assignable to type 'AnyString<T>'.
  Type 'T | (Lowercase<self> extends Lowercase<T> ? self : never)' is not assignable to type 'AnyString<T> | AnyString<T>'.
    Type 'T' is not assignable to type 'AnyString<T> | AnyString<T>'.
      Type 'string' is not assignable to type 'AnyString<T> | AnyString<T>'.

The idea of a type that can do its own validation is interesting and worth thinking about how to manifest, but I think in practice the problem is that people generally expect types to evince higher-order behavior, especially if they've encoded the rules of those types in the type system's syntax itself. A good example that comes to mind is the relation between T and Partial<T> -- the assignability relationship implied by those two types doesn't just "happen" if you make a naive Partial implementation, you actually have to do the work to identify that it is a subtype, and until you do this, it seems very very buggy that it doesn't "work".
We see this all the time as people try to do relations involving aliased higher-order operations which don't produce any higher-order behavior, e.g. they expect that Omit<T, K0> should be assignable to Omit<T, K1>as long asK1was produced by a named operation fromK0` that would imply the subtyping. But they're just higher-order types and we can't relate them in those terms, even though it "looks like can" because those behaviors were named in terms of type aliases.
Taking this problem to the infinite degree by allowing you to, as described, "write programs", makes the problem infinitely worse, because talking about whether one program accepts a superset or subset of values of some other program is just plainly intractable beyond the trivial cases. It's very powerful to talk about the behavior of a single arbitrary program, but it necessarily involves giving up the ability to reason about the relation of one program's inputs to another's.
Moving on, there some mundane practical reasons we haven't invested in a "signaling never" (presuming that such a construct would be allowed to exist outside of a self type, which AFAICT from experimentation is not implemented in this PR):

If widely adopted, it'd be bad for performance
Error messages from user code can't be localized, and a lot of people actually do use localized error messages
Heuristics for reporting the "best" error generally stop working
Signaling never can't be used to tell you why an overload wasn't selected, for example -- it only works in error cases
How exactly they behave when e.g. distributed as part of a union is confusing at best to think about

I think all of those objections are, well, fairly mundane and likely something that could be overcome in due time, but in each of the use cases where they seem to come up it's been a case where other solutions either elsewhere in the type system or just via simple signaling literals as described in the OP seem to be a better trade-off.

Taking this problem to the infinite degree by allowing you to, as described, "write programs", makes the problem infinitely worse, because talking about whether one program accepts a superset or subset of values of some other program is just plainly intractable beyond the trivial cases. It's very powerful to talk about the behavior of a single arbitrary program, but it necessarily involves giving up the ability to reason about the relation of one program's inputs to another's.

First off, thanks for the neat PR. I thought this deserved a bit of a deep dive.

Thanks, glad you liked it.

Regarding the implementation of self - in general it doesn't "work" to try to create new assignability rules by, at the top level, checking for special properties of the target type, as happens here. This gets you correct top-level behavior, of course, but higher-level stuff doesn't work like expected

It's true there's gap in implementation but it's not the one you mention. Consider this even more complex case...
type Foo<T> =
  T extends "foo"
    ? CaseInsensitive<"bar">
    : never

declare const f:
  <T extends string>(x: T, y: Foo<T>) => void

f("foo", "BAR")
//       ~~~~~
// Argument of type '"BAR"' is not assignable to parameter of type 'CaseInsensitive<"bar">'.

This too doesn't compile when it should, but we can see that at the end of the day we're still checking "BAR" with CaseInsensitive<"bar"> (same is with your snippets too). The question is how come the control doesn't reach the change made in this PR when this assignability is checked? Or if the TypeFlags.ContainsSelf gets lost somewhere? There's a bug here but the approach of having a change in the "at the top level" checking seems to be right.

using self types that don't evince higher-order relational behavior creates very large completeness gaps that would be immediately apparent

As you yourself mention this is not a self types issue but rather the issue of the compiler not being smart enough to check subtype relationships of generic constructs. So the completeness gaps users would see if they do something complex are the same completeness gaps that they see today itself elsewhere. What needs to be checked if the completeness gaps come up way more than desired.
It's true that if a type construct is implemented in the compiler as opposed to in a type it can do more and go out of the way and make things more complete, but self types are not intended to create complex type constructs in the first place.
The example you mention though seems to be working correctly, the error elaboration seems to stop at Type 'string' is not assignable to type 'AnyString<T> | AnyString<T>' but we can go futher manually...
type AnyString<T> = self extends string ? T : never;
function foo<T extends string>(a: CaseInsensitive<T>) {
  let m: AnyString<T> = a;
  //  ~
  // Type 'CaseInsensitive<T>' is not assignable to type 'AnyString<T>'.
  //   Type 'T | (Lowercase<self> extends Lowercase<T> ? self : never)' is not assignable to type 'AnyString<T> | AnyString<T>'.
  //     Type 'T' is not assignable to type 'AnyString<T> | AnyString<T>'.
  //       Type 'string' is not assignable to type 'AnyString<T> | AnyString<T>'.

  let n: AnyString<T> | AnyString<T> = {} as string
  // Type 'string' is not assignable to type 'T'.
  //   'string' is assignable to the constraint of type 'T', but 'T' could be instantiated with a different subtype of constraint 'string'.
}

So the error at m is right. Imagine if T is "FOO" and a is "foo", in that case AnyString<T> becomes "FOO" and a is not assignable to m as "foo" is not assignable to "FOO". Had AnyString been self extends string ? self : never the assignment would work, except it does't work because of the same implementation bug we saw above, but again we can check it manually...
type AnyString = self extends string ? self : never;
function foo<T extends string>(a: CaseInsensitive<T>) {
  let m: AnyString = a;
  //  ~
  // Type 'CaseInsensitive<T>' is not assignable to type 'AnyString'.
  //   Type 'T | (Lowercase<self> extends Lowercase<T> ? self : never)' is not assignable to type 'AnyString | AnyString'.
  //     Type 'T' is not assignable to type 'AnyString | AnyString'.
  //       Type 'string' is not assignable to type 'AnyString | AnyString'

  let n: AnyString | AnyString = {} as string
  // compiles
}

But more importantly in this snippet we're comparing two different self types, and I haven't made clear what should happen in such case, which I do in the next point...

Taking this problem to the infinite degree by allowing you to, as described, "write programs", makes the problem infinitely worse, because talking about whether one program accepts a superset or subset of values of some other program is just plainly intractable beyond the trivial cases. It's very powerful to talk about the behavior of a single arbitrary program, but it necessarily involves giving up the ability to reason about the relation of one program's inputs to another's.

This isn't a problem. We're talking about a case where two self types are being related. Two self types relate with each other in the same way two branded types do. Meaning most of the times they aren't a subtype of each other and that's how they're indended to be. Let me explain this a bit.
Imagine you have the following code...
type Probability =
  self extends number
    ? IsProbability<self> extends true
      ? self
      : Never<`Type '${Print<self>}' is not assignable to type 'Probability'`>
    : number

type IsProbability<T extends number> =
  `${T}` extends `${infer H}${infer R}`
      ? H extends "0" ? true :
        H extends "1" ? R extends "" ? true : false :
        false
      : false

type ZeroPointFive =
  self extends 0.5 ? self : never

declare let a: Probability
declare let b: ZeroPointFive
a = b
// Type 'ZeroPointFive' is not assignable to type 'Probability'.

One would consider this a bug as ZeroPointFive should be a subtype of Probability. But this is known incompleteness, and it is the same incompleteness if you were to implement the workaround I show in the OP...
type Probability = number & { readonly __tag: unique symbol }
type ZeroPointFive = 0.5 & { readonly __tag: unique symbol }

declare let a: Probability
declare let b: ZeroPointFive
a = b
// Type 'ZeroPointFive' is not assignable to type 'Probability'.

So ZeroPointFive not being a subtype of Probability is just the status quo, self types don't bring any improvements in this area.
Some times although two self types might have the correct subtype relationship, eg...
type A = self extends "a" ? self : never
type AB = self extends "a" | "b" ? self : never
let x: AB = {} as A // compiles

This is because we don't go out of our way to make two self types nominal, if we can find a subtype relationship we remain true to it.
And this is another good way to think of self types, they're branded types except they remove the pain of asserting a hardcoded value that we know is a subtype. That is to say imagine if we're working with probabilities, today we'd implement the above branded Probability type, but here and there we have some 0, 1, 0.5 hardcoded which we have to be asserted 0 as Probability, now enter self types, we make Probability a self type and all those assertions go away.

AFAICT from experimentation is not implemented in this PR

It is implemented but there might be some bugs. And yes it is intended to be an independent feature which works outside self types.

I think all of those objections are, well, fairly mundane and likely something that could be overcome in due time, but in each of the use cases where they seem to come up it's been a case where other solutions either elsewhere in the type system or just via simple signaling literals as described in the OP seem to be a better trade-off.

All the points you describe apply to signaling string literals and plain never as well. A Never<"foo"> is as bad as "foo" or never except we can improve some points because we have the information that it signals an error, in case of "foo" or never it's totally indistinguishable from a legitimate string literal type or a legitimate never type.

about error messages, please take a look at https://github.com/microsoft/TypeScript/pull/40468 throw types

What is happening here is totally unrelated to #40468. We're not throwing here, we're just retuning the type equivalent of logical false in the propositional function that a self type is. The never here is not a "workaround" we actually want a never, and Never literally constructs a never just with additional meta information of a message. And moreover having an effect in a pure functional langauge is semantically incoherent and problematic.
To give you a simple example the former declaration would produce two errors whereas the latter would produce only one (afaiu what throw is meant to be)...
let x: { a: Never<"a">, b: Never<"b"> } = { a: 0, b: 0 }
let y: { a: throw "a", b: throw "b" } = { a: 0, b: 0 }

Again this is just an example, it's not representative of the huge philosophical gap there is between both PRs. There could be some cross pollination of ideas but that's a secondary thing.

Or if the TypeFlags.ContainsSelf gets lost somewhere?

As I guessed this is what was happening. It was too much hassle to juggle and preserve that flag around so I created a new type construct instead, which also made the implementation little more simple and clean. So the bugs you highlighted are fixed, see self-types-ryan.ts.
And the CI should also be passing, I fixed those other trivial tests.

Btw how do you only run a specific test case? eg I want to run src/testRunner/unittests/publicApi.ts only to generate the new baseline for public api and not the whole test suite. Is there a way to do that?

@devanshj the available options are listed here. I usually just run this:
hereby runtests --tests=myTest

I'm aware of that so I tried hereby runtests -t publicApi.ts (I guess that does the same thing) but apparently it doesn't work, ie it results into empty test suite. Maybe the -t filter only works for fourslash tests idk because hereby runtests -t self-types* works as expected.

It seems that unit tests are somewhat special and they might run conditionally. I found some things related to that in this file - but I wasn't able to quickly craft a command that would do what you want here.

That's a good pointer, I tried a thing or two but nothing works...

hereby runtests -t publicApi.ts --runUnitTests
echo '{ "tests": ["publicApi.ts"], "runUnitTests": true }' > mytest.config && hereby runtests --config mytest.config.

Btw the CI is passing, so can I get a playground build for this? That'll make it easier for everyone to play and test this PR.

@ahejlsberg have you seen this PR? I wonder if you like it? :P — I understand Ryan represents the whole team and I can discuss the nitty-gritties with him but I was just curious to know your initial reaction.

Super cool stuff.
I made a suggestion recently here that is very similar to this.
The main thing that differs between my suggestion and this is that I thought it would be good to use infer in the start of the type definition, i.e. type a = infer Self ... instead of type a = self ....
I might have overestimated how big of a problem name collisions would be with your approach, what are your thoughts about this?

does user-defined types takes precedence?

Yes to make the change non-breaking.

I don't think this will be a big issue

I don't see how this is an issue at all.

Also, on the topic of negated types, would your change allow something like this?

That would work but check tests/cases/compiler/self-types-not.ts for better ideas on how to implement and write not types.

@devanshj I love this proposal so much. Playing with it a bit locally, I seem to have hit a gap in the implementation. It looks like Never doesn't handle object types gracefully:
const foo: Never<""> = { abc: 1 };

Checking this code results in RangeError: Maximum call stack size exceeded

Another interesting hiccup:
// By normal `extends` semantics, the LHS of `extends` can have more properties than the RHS:
type NormalExtends = {
  a: 1;
  b: 2;
} extends {
  a: 1;
}
  ? true
  : false;

// ✅
const a: NormalExtends = true;

/////

// Yet this doesn't hold through `self`:
type SelfTyped = self extends {
  a: 1;
}
  ? self
  : never;

// ❌ The extra `b` makes this fail.
const b: SelfTyped = {
  a: 1,
  b: 2,
};

// ✅ It passes if if has exactly the property on the RHS of `extends`.
const c: SelfTyped = {
  a: 1,
};

// ❌ Missing the `a` is (correctly) a failure.
const d: SelfTyped = {};

/////

// Notably, though, if the RHS is an *empty* object, these all pass.
type SelfTypedWithEmpty = self extends {} ? self : never;

// ✅
const b2: SelfTypedWithEmpty = {
  a: 1,
  b: 2,
};

// ✅
const c2: SelfTypedWithEmpty = {
  a: 1,
};

// ✅
const d2: SelfTypedWithEmpty = {};

Hey @Peeja, I'm not actively working on this PR so I might not be able to reply. Although feel free to keep posting these bugs/anomalies. And thanks for liking the PR!


memoory leak when insert boxshadow in decoration

when I used the code below, the application crashed then I checked that the blurRadius line affects the performance and memory
device: IP 6

decoration: BoxDecoration(
                  color: white,
                  borderRadius: BorderRadius.circular(25),
                  boxShadow: [
                    BoxShadow(
                        offset: Offset(0, 7),
                        blurRadius: 64, ---> error when add this line
                        spreadRadius: 0,
                        color: black_7)
                  ]

try instead 64 blurRadius by any number < 25 (borderRadius)

Hi @trantrongkim98
does the proposed solution solved this issue?
If the issue is still present, please provide the output of "flutter doctor -v"

Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now. Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.


requests does not install if Python has no SSL support

here's what happens if you try to install requests in a Python environment that doesn't have SSL support:
Downloading/unpacking requests
  Downloading requests-0.8.4.tar.gz (52Kb): 52Kb downloaded
  Running setup.py egg_info for package requests
    Traceback (most recent call last):
      File "<string>", line 14, in <module>
      File "/usr/local/src/cogo/platform/systemfiles/analyst/home/config/build/requests/setup.py", line 6, in <module>
        import requests
      File "requests/__init__.py", line 27, in <module>
        from .models import Request, Response
      File "requests/models.py", line 19, in <module>
        from .packages import oreos
      File "requests/packages/__init__.py", line 3, in <module>
        from . import urllib3
      File "requests/packages/urllib3/__init__.py", line 16, in <module>
        from .connectionpool import (
      File "requests/packages/urllib3/connectionpool.py", line 11, in <module>
        from httplib import HTTPConnection, HTTPSConnection, HTTPException
    ImportError: cannot import name HTTPSConnection
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):

  File "<string>", line 14, in <module>

  File "/usr/local/src/cogo/platform/systemfiles/analyst/home/config/build/requests/setup.py", line 6, in <module>

    import requests

  File "requests/__init__.py", line 27, in <module>

    from .models import Request, Response

  File "requests/models.py", line 19, in <module>

    from .packages import oreos

  File "requests/packages/__init__.py", line 3, in <module>

    from . import urllib3

  File "requests/packages/urllib3/__init__.py", line 16, in <module>

    from .connectionpool import (

  File "requests/packages/urllib3/connectionpool.py", line 11, in <module>

    from httplib import HTTPConnection, HTTPSConnection, HTTPException

ImportError: cannot import name HTTPSConnection

----------------------------------------
Command python setup.py egg_info failed with error code 1

not only is this very inconvenient, but it seems to contradict the assertion that requests has "zero dependencies".

Interesting. We should definitely fix this.
Now I'm curious though — what's the best way to hand this? Raise a ConnectionError when someone tries to open an https url? Or maybe a ProtocolNotAvailable error?

Shouldn't this be handled in the urllib3?

@piotr-dobrogost: urllib3 is, as always, not an issue.
Probally worth noting to @shazow though.

Hmm I've never seen that happen before. I could try to handle the case better by providing a built-in faux-HTTPSConnection object, though not sure if it would work at all without replicating a lot of the logic.
ProtocolNotAvailable sounds good to me, maybe even inherit from a ConnectionError. :)

I'm tempted to just say that we require it.

Closing this, since this is technically a urllib3 bug.

@shazow - asking here rather than filing an issue on urllib3, as I'm looking for clarification.
I've just run into this exact issue myself. Seeing as how it's been marked closed 'urllib3 bug', would you like an issue opened for it? I'm not seeing one currently.

@pudquick Please open a urllib3 bug, I'll try to get this fixed this weekend.


(PUP-6122) Deprecate resource_types endpoint

Add a deprecation message to the resource_types endpoint.

CLA signed by all contributors.

Deprecated APIs have a docs page at https://docs.puppet.com/puppet/4.4/reference/deprecated_api.html. CC @jtappa

The warning message looks good to me.  👍

@kylog @justinstoller I've gone ahead and updated that message to contain a link to the latest docs on docs.puppet.com rather than to a docs page on the master branch of the puppetserver github repo. I would use a shortlink but since those are broken right now I figured this was best.
@gguillotte Do you need me to do anything with the deprecated_api docs page?

👍

@fpringvaldsen CC @jtappa for the docs. There at least needs to be release notes on the JIRA ticket.

We look to have quorum for a merge.  @fpringvaldsen please be sure to add release notes to the ticket as @gguillotte requested.


WFLY-9371 Fix failing RemoteEJBTwoClusterTestCase

Jira
https://issues.jboss.org/browse/WFLY-9371

Fails intermittently.


Add Google Cloud Logging to dependencies

Describe the bug
Google cloud logging is not defined in pyproject.toml. This means that enabling GOOGLE_CLOUD_LOGGING using the published Dockerfile throws an exception as google.cloud.logging is imported. The following line needs to be added to pyproject.toml:
google-cloud-logging==3.9.0
I would create a PR, but I can't get the poetry.lock diff to look good.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Environment (please complete the following information):

OS: [e.g. iOS]
Label Studio Version [e.g. 0.8.0]

Additional context
Add any other context about the problem here.

Hi @tsr10 - thanks for your report! I'll get this fixed soon.
Cheers,
Jo