Auto detect color scheme not working after reload window

Issue Type: Bug
window.autoDetectColorScheme setting is not respected after running "Reload Window" from the command palette, it always fall back to whatever value in workbench.colorTheme after reload.
VS Code version: Code 1.57.1 (Universal) (507ce72a4466fbb27b715c3722558bb15afa9f48, 2021-06-17T13:28:32.912Z)
OS version: Darwin arm64 20.5.0
Restricted Mode: No

System Info

Item
Value

CPUs
Apple M1 (8 x 24)

GPU Status
2d_canvas: enabledgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
4, 4, 3

Memory (System)
16.00GB (0.46GB free)

Process Argv
--crash-reporter-id d551408c-e011-484b-b16f-64ba39c5e720

Screen Reader
no

VM
0%

Extensions (28)

Extension
Author (truncated)
Version

swagger-viewer
Arj
3.0.1

markdown-mermaid
bie
1.9.2

better-toml
bun
0.3.2

mustache
daw
1.1.1

vscode-faker
dee
1.5.0

emulate
Die
1.4.0

gitlens
eam
11.5.1

prettier-vscode
esb
6.4.0

vscode-jest-runner
fir
0.4.44

graphql-for-vscode
kum
1.15.3

vscode-apache
mrm
1.2.0

hexeditor
ms-
1.7.1

wordcount
ms-
0.1.0

debugger-for-chrome
msj
4.12.12

uuid-generator
net
0.0.4

java
red
0.79.2

vscode-commons
red
0.0.6

vscode-xml
red
0.16.1

vscode-yaml
red
0.20.0

velocity
sod
0.2.0

vscodeintellicode
Vis
1.2.14

vscode-java-debug
vsc
0.34.0

vscode-java-dependency
vsc
0.18.4

vscode-java-pack
vsc
0.16.0

vscode-java-test
vsc
0.30.0

vscode-maven
vsc
0.31.0

vscode-import-cost
wix
2.15.0

markdown-all-in-one
yzh
3.4.0

A/B Experiments
vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
pythonvspyt678:30270856
pythonvspyt602:30300191
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyt639:30300192
pythontb:30283811
pythonvspyt551cf:30311713
vspre833:30321513
pythonptprofiler:30281270
vshan820:30294714
pythondataviewer:30285071
vscus158:30321503
pythonvsuse255:30323308
vscorehov:30309549
vscod805cf:30301675
vscextlangct:30322307
binariesv615:30323119

great release

What window.autoDetectColorScheme does is that when a OS color scheme change is detected, it changes the workbench.colorTheme to the the preferred theme: Either workbench.preferredDarkColorTheme or workbench.preferredLightColorTheme.
OS color scheme change are detection happens while VSCode is open or if VSCode is restarted and the OS theme is different from when VSCode was closed.
So a reload will not change the theme, and also should not.

Do you mean that the value of workbench.colorTheme will be modified daily based on OS sunset schedules, hence synchronized to my other machines?
Every time I called "Reload Window" in the evening, it shows the light theme when it should be dark. So it is basically doing what it shouldn't.
Shall I attach a screen recording as a proof?

Yes, it will be synchronized to other machines, which might not be what you want.
What is the settings before you click reload?

The only settings that is not default is window.autoDetectColorScheme.
When trying to reproduce this, I noticed that when launching VS Code at the evening, reloading window retains the dark theme.
It only resets to light theme upon reload if VS Code was launched in the morning and didn't closed once until evening.

Sorry if I'm not familiar with this feature, is the OS switching the light/dark scheme depending on the day time?
I know that some VS Code extensions do that, but looking at your extensions list, I don't see any related extension?

Sorry if I'm not familiar with this feature, is the OS switching the light/dark scheme depending on the day time?

Yes. It usually defaults to the universal sunset of current timezone, for example SunCalc. Most operating systems also let you set your own daily schedule to switch your prefers-color-scheme twice a day.

I know that some VS Code extensions do that, but looking at your extensions list, I don't see any related extension?

I believe it is a built-in feature, the configuration key is window.autoDetectColorScheme.

I am seeing this issue too (on a Mac). Steps to reproduce are:

Set computer to dark mode
Open VSCode
Enable the "Window: Auto Detect Color Scheme" setting -- you should see the window adopt the dark color scheme
Run VScode's "Developer: Reload Window" command
Wait for the window to reload

The bug is now apparent: the window has the light theme applied even though 1. your computer is in dark mode and 2. "Window: Auto Detect Color Scheme" is enabled. This bug only happens after reloading the window; the bug doesn't reproduce if you actually quit and reopen the VSCode app.
This bug can be temporarily fixed by simply unchecking and rechecking the "Window: Auto Detect Color Scheme" setting, which will get things back in sync (without needing to restart VSCode). But the bug will pop up again the next time you reload the window when your computer is in dark mode.


Katib: Add components guide

Fixes: https://github.com/kubeflow/katib/issues/1668.
This PR: https://github.com/kubeflow/katib/pull/1667 removes components guide from the README, we should add it in the Kubeflow guides.
@tenzen-y I am not sure that we need to mention kustomize in the installation guides, as we discussed here: https://github.com/kubeflow/katib/pull/1667#issuecomment-921109438.
I noticed that Kubeflow Pipelines also uses kubectl apply -k: https://www.kubeflow.org/docs/components/pipelines/installation/standalone-deployment/#deploying-kubeflow-pipelines.
More advance users can always clone the Katib repo and use kustomize to modify our manifests before installation, we can explain it in the developer guide.
What do you think about it @tenzen-y @gaocegege @johnugeorge ?
cc @RFMVasconcelos
/hold for the review

More advance users can always clone the Katib repo and use kustomize to modify our manifests before installation, we can explain it in the developer guide.

LGTM! @andreyvelich
It might be better to change the required kustomize version in the following section.
https://github.com/kubeflow/katib/blob/a6cf571ea026fec6b9572f0b3cae4d8864771dda/docs/developer-guide.md#requirements

/approve

/hold cancel


Fix tab to spaces replacement logic

The existing implementation of converting a tab into spaces inadvertently includes an off-by-one error, producing one less space than desired. Resolves #358.

Done!


CachingAuthService - if subject.user null return empty cache.

service/threads requires permission service.run.threads and prompts for login.
On admin login, access is denied.
AuthWebAgent calls auth.check with session.getContext() which does not have the 'admin' user.
During troubleshooting - walk the auth proxy chain calling check on each auth service. The CachingAuthService fails with NPE on dereference of Subject.user, which is null.    If an empty cache is returned when user is null, then the admin access to service/threads succeeds.

AuthWebAgent calls authenticate before the auth check. The session and its context should have been setup. A null value on Subject.user shouldn't have gotten that far into the CachingAuthService, the earlier decorator in the chain should handle the case.

You don't need to always login. Consider a public website or a website like Amazon which lets you browse before logging in to purchase.

If we don't require login to access service/threads, shouldn't the service be un-authenticated then it won't use AuthWebAgent.
https://github.com/foam-framework/foam2/blob/7c708de6aa46c679b4326ef70bc940e240c87996/src/foam/nanos/http/NanoRouter.java#L189-L191


Bruteforcing/cracking unknown rotors with rotors - Kriegsmarine model

It should be made more clear in the README that to solve for unknown rotors including VI, VII, and VIII, kriegsmarine_model should be passed to smart_decipher/bruteforce_decipher instead of m3_model. I was under the impression that m3_model would have contained the extra rotors, based on some other tools.

Good point. I am thinking about whether to make Kriegsmarine the default M3 in the future.
I added some comments to the README in commit c126b34.


⚠ TorrentLeech has degraded performance

In 0371499, TorrentLeech ($TL) experienced degraded performance:

HTTP code: 200
Response time: 7511 ms

Resolved: TorrentLeech performance has improved in 3672bd2.


[Translatable + Filterable] Getting null values with getResult

Hello there :)
First of all, thank you for your time and for the work behind this bundle !
Context
I try to implement a "search" functionnality to my Article entity (with some translated field).
I did some research before coming here and tried several things :

"Fetch join" the translation table of my Article is not enough, still getting null values
I was doing my LIKE statement with DQL but tried the filterable feature => same result
This happens only when I try to filter my result. Without filtering, I get what I want.

Some thought:

I was thinking maybe it's because of Doctrine lazy loading ?
If I use getArrayResult() it works but the data doesn't fit my entity Article : it has a "translations" field with every translated data :

  {
    "id": 1,
    "created_at": "2016-07-21T10:33:07+0200",
    "updated_at": "2016-07-21T10:33:07+0200",
    "free": true,
    "translations": {
      "fr": {
        "title": "mon article",
        "subtitle": "mon introduction",
        "description": "description de mon article",
        "video": "",
        "locale": "fr",
        "id": 1
      }
    }
  },

How the data should look like :
{
  "title": "title",
  "subtitle": "introduction",
  "description": "my article description",
  "video": "",
  "free": true,
  "id": 1,
  "created_at": "2016-07-21T10:33:07+0200",
  "updated_at": "2016-07-21T10:33:07+0200",
  "tags": [
    {
      "name": "TagTest2_EN",
      "id": 3
    }
  ],
  "publisher": null,
  "picture": null
}

Some code
Controller :
    public function listAction(ParamFetcher $paramFetcher)
    {
        $search = $paramFetcher->get('search');

        $em = $this->getDoctrine()->getEntityManager();
        $repository = $em->getRepository("MyBundle:Article")
            ->filterBy(['translation:title' => $search])
            ->getQuery()
            ->getResult()
        ;

        return $repository;
    }

Repository :
class ArticleRepository extends \Doctrine\ORM\EntityRepository
{
    use FilterableRepository;

    protected function createFilterQueryBuilder()
    {
        return $this->createQueryBuilder('article')
            ->select('article','translation')
            ->leftJoin('article.translations', 'translation')
        ;
    }

    /**
     * @inheritDoc
     */
    public function getLikeFilterColumns()
    {
        return [];
    }

    /**
     * @inheritDoc
     */
    public function getILikeFilterColumns()
    {
        return ['translation:title'];
    }

    /**
     * @inheritDoc
     */
    public function getEqualFilterColumns()
    {
        return [];
    }

    /**
     * @inheritDoc
     */
    public function getInFilterColumns()
    {
        return [];
    }
}

The result :
[
  {
    "title": null,
    "subtitle": null,
    "description": null,
    "video": null,
    "free": true,
    "id": 1,
    "created_at": "2016-07-21T10:33:07+0200",
    "updated_at": "2016-07-21T10:33:07+0200",
    "tags": [
      {
        "name": "TagTest2_EN",
        "id": 3
      }
    ],
    "publisher": null,
    "picture": null
  },
]

Question
So as you can see, i receive null values and don't know why :)
If someone could explain !
Thank you in advance

+1

I'm going through the old issues/PRs and closing most of them so we can focus on now.
This one is missing any feedback or reasoning so I cannot deduce anything from it.
Thanks for you though, but closing for reasons above.
If the bug still remains, please send failing test case to verify it. Only with test we'll be albe to help.


Sample workspace JSON generates jackson exception structurizr-cli-1.12.1.jar

Checked out master, did build and copy jar to etc ( ./gradlew bootJar && cp build/libs/structurizr-cli-1.12.1.jar etc/) then with
sample / starter example I get:
com.fasterxml.jackson.core.JsonParseException: Unrecognized token 'workspace': was expecting (JSON String, Number, Array, Object or token 'null', 'true' or 'false')
Upload as follows: ./etc/structurizr.sh push -id  -key KEY -secret  -workspace structurizr-model.json
Simple example from actual structurizr docs:
`
workspace {
model {
    user = person "User"
    softwareSystem = softwareSystem "Software System"

    user -> softwareSystem "Uses"
}

views {
    systemContext softwareSystem {
        include *
        autolayout
    }

    theme default
}

}
`

That example isn't JSON, it's the Structurizr DSL ... try renaming the file to structurizr-model.dsl.

My bad, yes this worked.
$ mv structurizr-model.json structurizr-model.dsl


Fix admin ghosts not being able to see items in pouches or interact with them

About the PR
Media

[x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

shouldnt anyone be able to see what pouches you have

shouldnt anyone be able to see what pouches you have

for 13 parity yes probably but that's for another time


Error with opening the browser

Opening the web browser still does not work. An attempt is made to open the window as under Linux.
Information:

OS: Windows 11
OS version: 23H2
Program version: v.0.5.5.beta
Operating mode: WSL

I had test this and now it work's fine.


Feature Request: MultiTool

Diamond Saw blade upgrade: makes the Drill be able to Chop down wood fast.
Diamond Excavator upgrade: makes the drill be able to harvest a big area, 3x3 4x4 of wheat, grass, for farming and upon right click makes it till soil like a hoe.
Diamond Blade upgrade: Make it so that it causes 14 attack damage to mobs.
Shift right click while holding the drill to change modes.

Multitools won't be a thing (except for the Final Tier tool). Chainsaws are already planned, as well as plant harvesters. Not sure about weapons.

The Flux-Infused Crusher is now available in the 1.3 update, so I'll probably close this...

I think you should do a Crusher version for EnderIo too, for those who don't want to play with Thermal Expansion.

I will, but it will take a while because I have some big plans for that.
I want the Dark Steel Crusher to be a cheaper, less powerful version of the Flux-Infused Crusher, but with upgrades. So you'll have to earn your 3x3, 5x5 or (maybe?) 7x7 modes.

http://minecraft.curseforge.com/mc-mods/229846-rfdrills/files
The EnderIO crusher is done, so I'll probably close this.


Terminal editors June plan

This is a plan for terminal tabs issue: https://github.com/microsoft/vscode/issues/10546, I read through all the comments on that issue while coming up with the below.
If you have feedback on this feature, please put it in https://github.com/microsoft/vscode/issues/10546
Philosophy
The terminal view is convenient, it's nice to have all terminals in a single space where you can reliably go to in order to see all your terminals. Having said that, some people don't like the terminal panel and would prefer to work with editors. There are a few reasons for this:

They want to use a true grid view with more than 1 dimension - this isn't implemented in the terminal view to keep things simple and lightweight.
They want terminals that are persistent and will always be visible regardless of panel state.
They want to save the panel's real estate for something else like the debug console or problems.
They want to make better use of monitors.
They want to temporarily use a terminal on the side to give it more real estate and use as a reference - this is something I use a text editors in a second editor group for.
They want to have a single full screen editor group, being able to switch to the terminal without messing with its dimensions

The plan is to make terminal editors optional/opt-in. If the user doesn't want to use them, then they probably wouldn't even notice they exist. Terminal editors will complement the existing terminal tabs, both can be used if the user wants.
Tasks
For an up to date list of tasks check this query.

Create TerminalEditor class @meganrogge
Create TerminalGroupService to manage instances and whether they are in the panel or editor @Tyriar
Commands

Move terminal to active editor group
Move terminal editor to terminal view

Settings

Default terminal location setting, this will let the user route create terminal commands to the editor, name needs some work

Handle reconnect properly - don't restore editors on restart
Drag and drop terminal -> editor
Drag and drop editor -> terminal
Add terminal editors to term quick pick, show categories
Terminal editor tab context menu - look at different editor types to see what should go into this
Terminal view tab context menu entry to move to editor (feature discovery)
Support editor actions for the terminal (split/kill? What does split do?)

Verification

Ensure API Terminal.show works for terminal editors
Ensure tab color, icon works for terminal editors
Status works for terminal editors, including the task running animation
Ensure status hover shows when hovering terminal editor tabs
Backgrounded terminal editors on reload should be restored correctly - the process should reconnect but the editor should not be created until focused
Ensure terminal editors are always pinned
Linux/Windows: Does ctrl+w close the tab as expected?
Does split editor (cmd/ctrl+) work as expected within the terminal editor?
Does split terminal command work as expected within the terminal editor?
Reconnected terminal editors don't resize terminal unless the window size has changed

Investigations

Consider setting to include editor terminals in next/previous terminal commands?
Investigate lock editor group/secondary editor concept https://github.com/microsoft/vscode/issues/124709
Keybindings? Create terminal is option+T in Cloud9 https://github.com/microsoft/vscode/issues/10546#issuecomment-332536901
How should ctrl+shift+t interact with closed terminal editors? Should the processes stick around for x seconds in case it was closed accidentally?
Is there anything else we should do wrt discoverability?
:muscle: Support detaching terminals https://github.com/microsoft/vscode/issues/118276
Do a once over of all terminal commands, are there any others we need to handle specially?
Can/should the terminal editor code be loaded asynchronously since it's an optional feature?
Linking text editors to a particular terminal? ISE has a feature like this https://github.com/microsoft/vscode/issues/10546#issuecomment-597546111 - What if there was a run text/file in linked terminal command?

References

Atom terminal-tab https://atom.io/packages/terminal-tab, https://github.com/microsoft/vscode/issues/10546#issuecomment-377086938
VS Code Terminal Tab extension using webviews by @mmis1000 https://github.com/mmis1000/Vscode-terminal-tab

Locking as this is just for planning, please put any feedback on the main issue https://github.com/microsoft/vscode/issues/10546

Calling this done, there are a few items that didn't make the cut that will probably be done in next iteration


ok this was the 'bug'

and now its fixed ;-)
https://twitter.com/sqldbawithbeard/status/1029822270427017217

wait, what was the difference?

The curly braces in the Database.Tests
It went
Describe {
Describe {}
Describe {}
Describe {}
Describe {}
}
Grrrr but it seems different versions of pester treat that differently

So completely my fault but weird all the same

ah haaa! yeah totally weird

I'm holding off on 4.4.0 because I had it fail on tags in a custom repo that I am using at a shop and I do not want to break that one


To simplfy, maybe reduce dependency to Dynamo

Just to start a discussion, I guess I want some feedback here as well.
Why not store the data in S3? As far as I can see, the counters are relative costly.  Possibly the following would work:

Store any hit to s3, either find a way to efficiently append to a s3 data struct or throw single hits into one folder. if you take the day, month, year into account, folders can make up for some of the lost features.
Provide lambda magic to determine if there is data and do the calculations: day, month, year, per site. Remember: The data is write once, so as soon as this is done, its read only. Exception: actual month.

daily has to be generated each day
updating the actual months totals sum(days)
updating yearly totals sum(year)
maybe a dynamic solution for real time data, a listener for s3 writes will possibly do.

The obvious flaws are missing "Paging" of detail data and  large datasets. However, I did not wanted to imply that dynamo is completely off the board, but maybe its a simplification to initially give the data to s3

Reducing the fixed costs (dynamodb, kinesis) with a simplified architecture (apigw -> lambda -> s3) would indeed be useful. Athena could help with the aggregations/stats, but it would require some thought.


Make sure we are in the default namespace in getHostLinkIPs

Coverage decreased (-0.08%) to 75.261% when pulling 786cbc8dec35b5640df40b395e1d07aa2c5178d0 on rastislavszabo:master into 52b1e457f9709169aefe500b566b997f87c8e9de on contiv:master.


Update README

added me

Also add me :D

Not merging to master branch, merge to contributor file in dev


Provide Dial(net, addr) and DialTimeout(network, address string, timeout time.Duration)

over the millisecond int?

Yeah, I agree that DialTimeout("tcp", ":7070", 500*time.Millisecond) reads better.
The reason there isn't a default Dial() (w/o timeout) is because the range of desirable real-world timeouts is pretty enormous. Do you have an opinion about what a reasonable default would be?

True! A few seconds seems like it would be generous but I agree it might be better to just force people to make their own choice

So I changed Dial to use time.Duration. I'm going to leave the issue open in case someone feels strongly about the simpler constructor.

rad!


Changed the eventListener to not use EventInstances with Data since this has a major impact on memory usage.

Changed the eventListener to not use EventInstances with Data since this has a major impact on memory usage.

Codecov Report
Attention: Patch coverage is 70.00000% with 6 lines in your changes missing coverage. Please review.

Project coverage is 80.38%. Comparing base (c97cc9b) to head (f26c6ca).
Report is 1 commits behind head on master.

Files
Patch %
Lines

...in/scala/com/ing/bakery/components/EventSink.scala
0.00%
4 Missing :warning:

...n/scala/com/ing/baker/runtime/akka/AkkaBaker.scala
0.00%
1 Missing :warning:

.../akka/actor/process_instance/ProcessInstance.scala
50.00%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1685      +/-   ##
==========================================
+ Coverage   80.36%   80.38%   +0.01%
==========================================
  Files         143      143
  Lines        4792     4980     +188
  Branches      168      161       -7
==========================================
+ Hits         3851     4003     +152
- Misses        941      977      +36

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


remote-cli not being added to PATH with "terminal.integrated.inheritEnv": false

Revives https://github.com/microsoft/vscode/pull/142740

Thanks @alexdima and sorry for the trouble.

No worries!  It was very interesting to find out that it's Path on windows, and not PATH and that process.env is a very special kind of object that works case-insensitive :).


Possible bug

Trying to figure this out, but I am getting an annoying autocomplete bug when writing sass.  Wondering if this is just my setup or are others having this issue?

Hello, this looks like it's an issue with a 3rd party extension (SASS perhaps). Vue's syntax highlight embeds the functionality of that extension.


feat(benchmark): support comparing benchmark result

Description

Closes https://github.com/vitest-dev/vitest/issues/5297

Starting a PR so that we can discuss the design with a proof of concept.
Example
# save current run as bench.json
$ pnpm -C test/benchmark bench --outputFile bench.json
... output is same as before ...

# compare against bench.json
$ pnpm -C test/benchmark bench --compare bench.json

TBD

[ ] what to name the flag? --compare, --baseline?
[ ] the feature lives completely in default reporter. json reporter is not used or changed at all, so just keep it as is?
[ ] tweak text/style?
[ ] non-tty output?

TODO

[x] integrate to current default tty reporter output
[x] cli flags
[x] test

I couldn't find a way to assert tty output with CI=true. For now, the test is enabled only on local.

[ ] doc

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[x] It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
[x] Ideally, include a test that fails without this PR but passes with it.
[ ] Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.

Tests

[ ] Run the tests with pnpm test:ci.

Documentation

[ ] If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

[x] Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.

what to name the flag? --compare, --baseline?

I like --compare

the feature lives completely in default reporter. json reporter is not used or changed at all, so just keep it as is?

Yeah, I don't think we need to update the json output since we get the data for compare from json? 🤔

Can you resolve the conflict, please?


swarm.peers() doesn't return a Promise

At some point the swarm commands were re-implemented and in the process, their return type was changed from Promise to callback. This breaks the use of js-ipfs-api in older projects.
Furthermore, the APIs return different data: on js-ipfs-api, it's { Strings: [<addresses>] } and on js-ipfs it's an array of Multiaddresses.

It now returns a promise (see: https://github.com/ipfs/js-ipfs-api/blob/master/src/api/swarm.js#L8)
And we are making the API compatible through interface-ipfs-core, we just need to get the pull-streams in and change the libp2p to support multiaddrs without ipfs ids too. Follow here:
https://github.com/ipfs/js-ipfs/issues/439 :)


Test dask.bag with unicode strings

Related to https://github.com/dask/partd/pull/16
Fixes https://github.com/dask/dask/issues/1452

LGTM after merge conflicts fixed.


Release 22.1.0

Ops didn't see this but pushed the same thing now to main - thanks to submitting it though!


Add diagnostic settings for core resources

Fixes #1746
What is being addressed
When something gets wrong in some azure resources it's hard to figure out the problem without logs. I came across this with Application Gateway, but we have other resources as well that don't save logs.
It is also valuable information for security audits and trackback scenarios.
How is this addressed

Add diagnostic settings definition for resource in the core tre infra: application gateway, service bus, keyvault
Small: remove appgw ip data object as it's not really needed for static IPs.

/test-extended

/test


Src template classes

Added a new class to some of the markdown helpers that we wrote (image, iframe, video). Modified test cases for this as well.
This PR can be reviewed and merged. It will have no effect on chaise as it is only modifying templates to add a new class that isn't used anywhere yet.

Made the suggested changes and merged the logging changes into my branch.

Merging this PR since it only adds  class and won't have any negative effects.


production option: minify bundle.js

While we definitely want the full code in development, in production we should minify bundle.js which is currently 9.38MB over the wire. That's cacheable, but it's expensive.
(related, we should make sure we have good cache control headers on it so that our updates go out properly)

It looks like the npm run build step isn't getting run when moving the application into the docker container. That includes a minification step, and should end up with the bundled JavaScript being called something like main.9364da6e.js. On my test site that's ending up a little under 1MB. That should help improve the startup time a bit.

This was an issue with the way I was deploying the docker container that I set up for Chicon 8.


Added HTML Cheet Sheet |&| Added HTML Guide i18n file

Describe your changes
Added HTML Cheet Sheet
Added i18n file for HTML Cheat Sheet
Added HTML Guide
Added HTML Guide i18n file

Closes #41
Checklist

[x] I have read the Contributing Guidelines.
[x] I have performed a self-review of my code
[x] If this solves a Open GitHub-issue: I have added the issue number and link
[x] If this is a new Doc: My doc complies with applicable licenses (not copy pasted without permission or license)

Closes #64


Keep attrs by default?

I've held this view in low confidence for a while and wanted to socialize it to see whether there's something to it: Should we keep attrs in operations by default?
Advantages:

I think most of the time people want to keep attrs after operations

Is that right? Are there cases where it wouldn't be a reasonable default? e.g. good points here for not always keeping coords around

It's easy to remove them with a (currently unimplemented) drop_attrs method when people do want to remove them

Disadvantages:

Backward incompatible change with an expensive deprecate cycle (would be impractical to have a deprecation warning every time someone ran a function on an object with attrs I think? At least without adding a once filter warning)
?

Here are some existing relevant discussions:

https://github.com/pydata/xarray/issues/3815#issuecomment-603974527
https://github.com/pydata/xarray/issues/688
https://github.com/pydata/xarray/pull/2482
https://github.com/pydata/xarray/issues/3304

I think this is an easy situation to get into:

We make an incorrect-but-insignificant design decision; e.g. some methods don't keep attrs
We want to change that, but avoid breaking backward-compatibility
So we add kwargs and eventually a global config
But now we have a global config that requires global context and lots of kwargs! :(

I'm up for leaning towards breaking changes if it makes the library better: I think xarray will grow immensely, and so the narrow immediate pain is worth the broader future positive impact. Clearly if the immediate pain stops xarray growing, then it's not a good tradeoff.

Why would you want a .drop_attrs() method? .attrs.clear() will do just fine.
I fully agree we should keep attrs by default.

Why would you want a .drop_attrs() method? .attrs.clear() will do just fine.

Yes that's fine if people are happy with .attrs.clear(). A method that returns the dataset object is useful for "fluent" method chaining.

See https://github.com/pydata/xarray/issues/1614 for related discussion.
I'm happy to set aside backwards compatibility concerns for now and ponder what the ideal policy would be. The original choices here were not made in a super careful way.
My longest-standing concern here is about units. One common use case for attrs is to mark the units of an array, and those aren't always preserved by naive arithmetic. But perhaps this is less of a concern now that you can use pint with xarray?
The other concern is how to combine attrs in operations that involve multiple arrays. Currently we just copy attrs from the first object, but that probably is not the most consistent (e.g., ideally arithmetic should be reflexive).

@shoyer to me this it would make the most sense to do a union of the inputs:

if a key is present only in one input, it goes to the output
if a key is present in multiple inputs, always take the leftmost

Note how this would be different from how scalar coords are treated; scalar coords are discarded when they arrive from multiple inputs and are mismatched. The reason I don't think it's wise to do the same with attrs is that it could be uncontrollably expensive to compute equality, depending on what people loaded in them. I've personally seen them used as back-references to the whole application framework. Also there's no guarantee that they implement __eq__ or that it returns a bool; e.g. you can't compare two data structures that somewhere inside contain numpy arrays.

I think this is a good question @max-sixty , and I have some opinions based on my experience with xBOUT.
Firstly I agree with you that for those users who use xarray as a convenience wrapper or for whom it's useful but not critical it makes more sense to keep attrs by default. "Drop by default because otherwise they might become inconsistent with your data" never really made sense to me, because if you care that much about attrs being consistent with data then you really need well-defined rules for how they are propagated in all cases, which we don't (yet) offer. In all other cases you would rather keep them and have to deal with the edge cases (which is why I wanted #2482 ).
As a concrete usage example of wanting to preserve attrs while not being overly-concerned if they sometimes get dropped: in xBOUT, our data requires carting around some regions attributes so that we know how to plot it later. One day this could maybe be handled by custom indexes in xBOUT, but there are probably other communities whose attrs requirements couldn't be.
After the casual wrapper case, the most important cases are:

Units, which IMO becomes much less relevant once pint integration is complete,
Data provenance,
CF conventions
Other domain-specific types of grids (like the xBOUT case, or staggered grids etc.)

At the risk of repeating what's in #1614 , I would like to see some hybrid approach, which gives a simple global default along the lines of what @crusaderky suggests, but also allows a plugin which takes over and rigorously specifies the behaviour for the users who do care. Then we can outsource the work of the complex logic to e.g. the community that actually has to preserve CF conventions, or a separate data provenance package.
(Also I made a new metadata issue label for these discussions)

Great, thanks @TomNicholas , appreciate the thoughtful reply.
One thing we could do (NB: I don't think we should do this right now, but building on the points above as ideation) is to defer to the attrs themselves. For example, in an operation dividing one dataarray by another, if they both share an attr which has a __div__ method, we call that and put the returned value on the resulting dataarray. That way, even ex-pint integration, Unit('m') / Unit('s') could evaluate to Unit('m/s'). And where units want to be dropped, they could use those methods to return None.
Re next steps on setting the default to be True, what are people's thoughts? Would we take a PR for 0.16? Would we want a deprecation warning on any operation with an attr?

For example, in an operation dividing one dataarray by another, if they both share an attr which has a div method, we call that and put the returned value on the resulting dataarray.

I agree that this would be very powerful, and also users to implement all the things they want (provenance, units handling etc.), but this also seems like a big undertaking. In order to have well-defined handling of attrs through operations like merge, concat, and ufuncs, wouldn't the attr-handling interface have to be almost as complicated as xarray's actual interface? Not saying we shouldn't do it, but what's the minimum set of attr-handling hooks that would have to be defined (and implemented and tested)?
Do you think it would be useful to get input from someone who actually wants this for a complex use case? I think the most hardcore one will be data provenance, because that (a) will need complicated underlying logic, (b) ideally needs to be pretty fault-tolerant, and (c) won't be made redundant by pint or duck-array integration. There was someone on #1614 who was asking about this IIRC.

Would we want a deprecation warning on any operation with an attr?

That would be almost every operation wouldn't it?

I'm trying to imagine what the approach that delegated the largest fraction of the work to an attrs-handling plugin would be. Would it be to give the attrs plugin the input, and the name of the function/method that was being called, and let the plugin completely decide the output attrs? Or would that be under-specified?

Would we want a deprecation warning on any operation with an attr?

That would be almost every operation wouldn't it?

Right, anything involving an object with attrs... hence my reluctance. Do we think it's OK to do this on a major version without a warning?

I think it would probably be OK to start propagating more attrs by default as a breaking change. There's no easy way to roll this out incrementally, and I doubt too many users are relying upon metadata disappearing when they do xarray operations, given the somewhat inconsistent state of the current rules.

I did not think this through carefully, but I wonder if we should extend merge_attrs to also take a function with a list of attrs as its only parameter and move towards something like combine_attrs instead of keep_attrs: setting keep_attrs seems to choose between combine_attrs="drop" and combine_attrs="override".

I did not think this through carefully, but I wonder if we should extend merge_attrs to also take a function with a list of attrs as its only parameter and move towards something like combine_attrs instead of keep_attrs: setting keep_attrs seems to choose between combine_attrs="drop" and combine_attrs="override".

if I remember correctly, we decided to allow passing a user-provided function to combine_attrs and to extend keep_attrs to accept a bool, a str or a function.
Something to keep in mind is that not all strategies make sense for operations that involve only a single variable, like isnull, but I guess for those all string options except drop mean "keep the attributes".

and to extend keep_attrs to accept a bool, a str or a function.

If we allow keep_attrs to be a custom function, then we could move towards some of the ideas in here: https://github.com/pydata/xarray/issues/988 . If that custom function received something like the UfuncContext in that issue, then an external library could implement data provenance handling like the history attribute, and set things like cell_methods. The context manager idea seems a little complex but doing something like
xr.set_options(keep_attrs=cf_xarray.attrs_handler)

could be OK, where all decisions are left up to the external package (here cf_xarray).
(Though what's stopping us from directly adding cell_methods attributes now for reductions, weighted, and coarsen?)

Moving from #8205 (I had searched for keep_attrs in issues, w underscore...)

@keewis writes:

It is true that it is more common to just globally set keep_attrs=True, so we might want to consider changing the default (see #3891, which you opened a long time ago).
We also (partially) changed keep_attrs to accept the names of builtin attrs merging functions and user functions (callables), which is important for operations that take more than a single variable. Though I guess in that case we could also just rename to combine_attrs.

I think the distinction of combining objects vs. a function that operates on a single object is important.
In the case I was working on, this was just a transformation of a single object, so I don't see much of a downside of separating out the ability to drop attrs into a different function.
Would there be any interest in:

changing the default to True
not adding keep_attrs for new functions
potentially soft-deprecating for functions which operate on a single object (the vast majority of functions)

i.e. remove from docs, without raising warnings everywhere. Like we did for .drop, which seems to have gone quite well...


Create Changelog Subpage

[ ] collect the links/paths to the changelog files of different Brightway packages
[ ] update the Sphinx build files to merge all changelog information to a single Changelog page
[ ] create a Brighway changelog file that contains information on major releases only

Implementation in pvlib "What's new" page:
.. include:: whatsnew/v0.9.3.rst
.. include:: whatsnew/v0.9.2.rst
.. include:: whatsnew/v0.9.1.rst
etc.

"Include files from other repositories in a Sphinx project": intersphinx
Compare also these questions on StackOverflow: 1, 2

...other alternative: pull files from submodules (compare https://github.com/brightway-lca/brightway-documentation/issues/14#issuecomment-1325108341).

Initial page setup completed with https://github.com/brightway-lca/brightway-documentation/commit/da956c7c550206e2d90fa163a00e1832a1a6a0d6


backend for TetWild

We should investigate building a meshing backend based on TetWild.
This would likely work similar to the cq/mmg backend where openCascade is used to create an stl geometry, and then use TetWild to improve upon that.
By default TetWild creates a volume-mesh but seems to do so quite well - it would appear from the docs that this tet-mesh can be used to create a surface mesh as well.

closing as we are not likely to get to this in the foreseeable future


Some fixes/improvements to the core typechecker

Most importantly:

Core/Tactics: controlling SMT guards and unfolding for check_equiv: this adds a new flag to the check_equiv invocation to forbid it from generating guards and unfolding definitions. I plan to use it from Pulse to match vprops.

Core.check_equiv: always WHNF: adding some normalization to always work with terms in HNF. This makes matching, for example, 1+2 and 3 trivial.

Core: allow checking pure/ghost (non-Tot) lets: talked about with @nikswamy. The first call to check lb.lbdef will accumulate a guard for the precondition if need be, and similarly for the body, so this should be safe. What we are not doing is using the spec of the lbdef to weaken the guard of the body. To do that I think we would need to obtain the strongest post of the lbdef, and we don't have machinery for that. I wonder if instead of accumulating guards Core could accumulate a WP of the checked term, in which case this would just be WP composition, and at the top-level we would instantiate with the fun _ -> True postcondition. In any case, it doesn't seem like a limitation in the tests I'm doing, and it is sound.

Core: fix checking of letbinding: fix the type in the subtyping call, it was off by one level.

Tactics: exposing full check_equiv with both flags: the check_equiv tactic is now derived from the t_check_equiv primitive which provides access to both flags. check_equiv_nosmt is defined to set both flags to false. This will require a small Pulse patch since the snapshot has fully resolved names.

Thanks @mtzguido
I reviews the core changes and they look good to me.
I agree that we could weaken the guard as an additional improvement in the future, but it's sound to not do that. So, I'm okay with it as is for now.

Thanks for reviewing! Merging.


Update the plugin will be something wrong

When I update the Laravel-Plugins,if you use some static method exm "User::find($id)" will waring to " Non-static method User::find() should not be called statically",this very bad!

https://github.com/barryvdh/laravel-ide-helper/issues/541#issuecomment-322265795

@barryvdh another issue fixed since @mixin support, can be closed :}


Fix DuplicateSectionError

This fixes DuplicateSectionError when a fake object is stored (written to) more than once.

Thanks for the pull request!

Thank you!


masac

Has masac been trained in the multiagent particle envs? Can it converge?

This repo is under reconstruction right now, so the code implementation in the repository is not rigorously tested.


Support the cluster-autoscaler's ProvisioningRequest API

How to categorize this issue?

/area auto-scaling
/kind enhancement
What would you like to be added:
In the upstream cluster-autoscaler v1.30 the ProvisioningRequest API was added.
Instructions how to enabled the API: Enabling ProvisioningRequest Support.
The proposal document: Provisioning Request CRD
Some specific things we discovered during the testing:

The  best-effort-atomic-scale-up.autoscaling.x-k8s.io provisioning class is added in CA 1.30.2. I would be nice if our fork syncs CA 1.30.2 so that this class is supported for K8s 1.30 clusters.
The feature is supported only for cluster-autoscaler 1.30.1, hence only Shoots with Kubernetes version 1.30+ needs to enable support for the ProvisioningRequest API.

Proposal for API:
apiVersion: core.gardener.cloud/v1beta1
kind: Shoot
# ...
spec:
  kubernetes:
    # ...
    clusterAutoscaler:
      provisioningRequests:
        enabled: true|false

Why is this needed:

Enable API that is supported by the cluster-autoscaler. See the motivation for the API in the Background section in the proposal
The ProvisioningRequest API can be potentially used by the VPA in future to address a well known limitation of VPA where VPA recommends more resources that the larges Node's allocatable turning the Pod in Pending state.

cc @gardener/autoscaler-maintainers
cc @tobschli @dergeberl

/assign

I think we can close this issue, as we do not need the ProvisioningRequest-API in the Shoots anymore.
What do you think @ialidzhikov?

I think it still makes sense to enable the ProvisioningRequest API as a feature of the cluster-autoscaler. We won't invest anymore into the VPA and CA integration for now but I imagine that end users soon or later will want to use this API. It makes sense to me to still expose/enable the ProvisioningRequest API.
If you don't have capacity to invest, I can have a look.

Capacitywise, I can clean up the changes and open a PR, I can do that :)
I will go on and open the PR in the next days.
Only tests are missing until at the moment


Smithy 1.13

Motivation and Context
Upgrade to Smithy 1.13. The new release is breaking CI because the CLI version is being autodiscovered.
Description
The Smith 1.13 upgrade adds new restJson protocol tests. These demonstrated two issues:

We were not properly using the http binding index to compute content types. We should not have fallen back to a default content type—instead we need to use exactly what is given. We were also using the index incorrectly: document in the context of the index refers to anything in the HTTP body, not the Smithy document type.
We were sending Content-Length: 0 even when no HTTP body was modeled.
We were sending an empty body for structures targeted @httpPayload trait in restJson. We should instead be sending on an empty JSON body: {}.

Testing

[x] Protocol tests
[ ] Manually review codegen diff

Checklist

[ ] I have updated CHANGELOG.md
[ ] I have updated aws/SDK_CHANGELOG.md if applicable

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

That diff generator is so helpful for reviewing these, thanks again for setting that up


Throw if missed initialize on dexter

Just ran into a stack trace where I missed initialize. I find this change will throw clear on stack trace.
Thanks for the clean library.

Also, I'd call the method checkInstanceNotNull to follow the same convention as in DexterInstance, besides that, :+1:

Thanks for your PR @vignesh-iopex !
We will release a new version with the most recent fixes including this one


CSS modules

Please create modules based on: https://github.com/opentelekomcloud/python-otcextensions/pull/222
Doc: https://docs.otc.t-systems.com/api/css/css_03_0008.html

[x] cluster_info
[x] #146
[x] #142
[x] #143

all done.


fix for invalid texture

does what it says on the tin!
Please give this a test!

Totally agree! Just wanted to see if this solves the flickering issue first.

In my MacBook ,
the   gl.getParameter(gl.MAX_TEXTURE_IMAGE_UNITS)==16 ,  settings.SPRITE_MAX_TEXTURES==32 .
So I think the correct way is using these codes :
const glMaxTextures = gl.getParameter(gl.MAX_TEXTURE_IMAGE_UNITS);
const maxTextures = Math.min(glMaxTextures, settings.SPRITE_MAX_TEXTURES);

.

I test my case , still has
WebGL: INVALID_ENUM: activeTexture: texture unit out of range

I think the key point is not  the number of maxTextures.
It's  about  https://github.com/pixijs/pixi.js/issues/3373#issuecomment-265764333

why group.ids[j] could be -1 ?
why all t._enabled === TICK ?  https://github.com/pixijs/pixi.js/blob/dev/src/core/sprites/webgl/SpriteRenderer.js#L275-L295

Interesting! Please can you share the code for your case?
On Thu, 22 Dec 2016 at 14:33, finscn<EMAIL_ADDRESS>wrote:

I think the key point is not the number of maxTextures.
It's about #3373 (comment)
https://github.com/pixijs/pixi.js/issues/3373#issuecomment-265764333

why group.ids[j] could be -1 ?
why all t._enabled === TICK ?
https://github.com/pixijs/pixi.js/blob/dev/src/core/sprites/webgl/SpriteRenderer.js#L275-L295

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/pixijs/pixi.js/pull/3474#issuecomment-268811276, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AC998hD469CY8iGLbqwcZfdDeeUJmXWPks5rKopCgaJpZM4LPrOP
.

@GoodBoyDigital  , my test case is very complex , it's a real game project.
It will render many sprites, meshes, graphics (include rect circle etc.)   in one game tick.

after  https://github.com/pixijs/pixi.js/pull/3474/files#diff-b87a2a9840fecac0080b87cdd72de184R93
you miss a  break; , I think

Good catch! Will tweak when I get home :)
On Thu, 29 Dec 2016 at 06:40, finscn<EMAIL_ADDRESS>wrote:

after
https://github.com/pixijs/pixi.js/pull/3474/files#diff-b87a2a9840fecac0080b87cdd72de184R93
you miss a break; , I think
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/pixijs/pixi.js/pull/3474#issuecomment-269588541, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AC998iVxqowtfYcDQ0x2k8EtsaUmpS0Yks5rM1XigaJpZM4LPrOP
.

@GoodBoyDigital  , the new patch still didn't fix this bug.

For my test case , this error message is throw at WebGLRenderer.prototype.bindTexture
            // bind the current texture
            this.boundTextures[location] = texture;

// ****** this line ******
            gl.activeTexture(gl.TEXTURE0 + location);

            gl.bindTexture(gl.TEXTURE_2D, glTexture.texture);

#3474

Thanks for letting me know @finscn !
The issue occurs when the same texture is bound to two different texture locations. This situation can result in -1 being passed in as the texture location. Getting closer though! :)
If you could share you code I would be happy to debug. That way I can get to the bottom of the issue much quicker! (maybe on a private channel if its sensitive stuff?)

@GoodBoyDigital  , I've modified my reply . Your patch is OK for me.

wooo! 👍

@GoodBoyDigital  I think it's time to merge some PRs  which have been  approved , and release a new version of PIXI.js  as a gift for  New Year.
BTW : why there is an error of travis in this PR ? Could you fix it ?
And
Happy New Year.

@staff0rd fixed :D

@ivanpopelyshev do you have any follow-up here?


Map / Canvas Doesn't Display correctly

Actual Behavior:
Release: 18.2
On ios devices running ios < 12.4 the map and chart display doesn't work as expected. The map doesn't render and the UI tools are in a different alignment.
See images
Steps to Reproduce the Bug:
When I...
The visualization does not work as expected.

Go to covidcast.cmu.edu  in a device with safari or chrome on a device running ios 12.2 or older

Expected behavior
The site will function as it does in that same device running ios 13.
Screenshots

For reference, this is Release 16

Rating Scale (1 is minor, 7 is severe):
5
Context

Browser: IOs 12.1 , Safari / Chrome

Additional context

@cgg-cmu please test again with the upcoming v1.9

@sgratzl is this able to be replicated with chrome devtools or do you need an actual iOS device?

I cannot reproduce it since v1.8.2 That's why I asked for a confirmation that it is now working

Closing this as not reproducible.  I checked analytics and there are no recent iOS users who've come to the site with < 12.4.


fix: resume overlay after Vite full-reload

Codecov Report

Merging #91 (9b1db76) into main (6542594) will increase coverage by 0.64%.
The diff coverage is 61.11%.

@@            Coverage Diff             @@
##             main      #91      +/-   ##
==========================================
+ Coverage   37.30%   37.94%   +0.64%
==========================================
  Files          13       13
  Lines         630      643      +13
  Branches      125      131       +6
==========================================
+ Hits          235      244       +9
- Misses        394      398       +4
  Partials        1        1

Impacted Files
Coverage Δ

...es/vite-plugin-checker/src/checkers/eslint/main.ts
22.61% <0.00%> (-0.28%)
:arrow_down:

...ite-plugin-checker/src/checkers/typescript/main.ts
26.02% <0.00%> (-0.74%)
:arrow_down:

...kages/vite-plugin-checker/src/checkers/vls/main.ts
51.72% <0.00%> (-1.85%)
:arrow_down:

packages/vite-plugin-checker/src/types.ts
100.00% <ø> (ø)

packages/vite-plugin-checker/src/main.ts
78.94% <100.00%> (+2.82%)
:arrow_up:

Continue to review full report at Codecov.

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


make test-coverage always succeeds

make test-coverage never errors, even if the tests failed to build. Expected behavior: in case of any error, abort make and set the exit code, as all the normal build targets do.
This is especially funny when you realize that the test suite never actually ran after a few weeks.

@vmarkovtsev Is this still happening? Could you share more info about the project where this is happening? Do you have a link to an example build on Travis CI exhibiting this problem?

I will be able to recover on Monday.

Link: https://ci.appveyor.com/project/mcuadros/client-go/build/5#L61
I don't see it in the recent builds, so maybe the cause of that particular error was fixed. I am not sure that the ignoring behavior is still present.


prepare_gpf.py generates incorrect gridcenter and the affinity from docking result is positive

I followed the tutorial on https://autodock-vina.readthedocs.io/en/latest/docking_basic.html. The problem I had was that the prepare_gpf.py script generated different npts and gridcenter values with respect to the tutorial.  I did what the tutorial taught: got the STI molecule from protein data bank and used the prepare_gpf.py to calculate the grid info. The gridcenter from the tutorial was: 15.190 53.903 16.917. However when I regenerated the gpf file with this code pythonsh <script_directory>/prepare_gpf.py -l 1iep_ligand.pdbqt -r 1iep_receptor.pdbqt -y, what I got was:-0.117 -0.053 0.216.
With the new gridcenter value, the affinity value was positive. With the gridcenter value provided by the tutorial, I got the similar negative value as the tutorial shows.

Hi @Forever8341
I was able to reproduce your outcome by using the "ideal SDF" downloded from https://www.rcsb.org/ligand/STI as the original structure file for the ligand.
The -y option in "prepare_gpf.py" sets the gridcenter to be the center of the ligand pdbqt file. 1iep_ligand.sdf, the provided ligand sdf in the tutorial, has the desired center to be the grid center. For your own work you can manually set the grid center for your receptor, before or after you run prepare_gpf.py.

Hi @Forever8341
I was able to reproduce your outcome by using the "ideal SDF" downloded from https://www.rcsb.org/ligand/STI as the original structure file for the ligand.
The -y option in "prepare_gpf.py" sets the gridcenter to be the center of the ligand pdbqt file. 1iep_ligand.sdf, the provided ligand sdf in the tutorial, has the desired center to be the grid center. For your own work you can manually set the grid center for your receptor, before or after you run prepare_gpf.py.

The purpose of my post is  using **prepare_gpf.py ** to generate the correct grid center info.  If I need to find the grid center manually, i would use AMDock rather than Autodock Vina.
However, thank you for your solution.

Hi @Forever8341,
The most appropriate choice of gridcenter depends on the objective of docking, as one receptor could have more than one meaningful binding sites. At this moment prepare_gpf.py doesn't have the ability to make the decision. If the auto option doesn't work for your receptor, you could use information from some pocket identification tools. If you are looking for one with Autodock, please try:
https://ccsb.scripps.edu/agfr/

Seems like this has settled, feel free to re-open if needed. Thanks @rwxayheee


Patch9Sprite Node (70% finished)

This PR is not ocmplete, please do not merge yet. I have it open so everyone can follow the development and make contributions.
Roadmap:

[x] Create a new Node class as a copy of Sprite.
[x] Remove unused properties (centered, frames, and region).
[x] Add Margin and Patch9Policy properties.
[x] Implement Drawing in all 5 Patch Policies.
[x] Add a Size property, since using scale looks like a bad way to handle this
[x] Add icons
[x] Make sure FlipH, FlipV and negative scales works properly
[ ] Create EditorPlugins to make development easier (edit size, margins and pivot)
[ ] Documentation

Still not sure if removing Centered param is good idea ^^'

why on earth does travis not find the PatchPolicy enum? :/

@MarianoGnu IME it's less troublesome to use just PATCH_NONE instead of the qualified PatchPolicy::PATCH_NONE. Or maybe make it more qualified: Patch9Sprite::PatchPolicy::PATCH_NONE.

Okay tests passed now, thx.

@akien-mga  The node is ready now, only missing stuff is EditorPlugins and documentation, if you wish to merge this now i can get some feedback while working on the rest.

@MarianoGnu Once you're happy with your PR, could you have a look at maybe rebasing to squash some of the commits together? I leave it up to you to see how many commits make the most sense to see how the stuff is implemented :)

Ping.

Pretty ping?

i'm sorry, i have been out of home last days and this computer is not setled for development yet
:disappointed:


[NFR]Support use keyword in Closures

Example
$func = function() use ($a) {
    return $a + 1;
}

Here $a becomes a local static variable of function $func.
@sergeyklay Who can implementation parse code.

This is definitely needed

@dreamsxin I'll try to implement parser

Refs: https://github.com/phalcon/zephir/issues/888

@dreamsxin Parser done https://github.com/phalcon/php-zephir-parser/pull/69

@sergeyklay Please help optimize code in https://github.com/dreamsxin/zephir/commit/404130d0426d1e8a83d8d4e7b4ddc799d7e4b633


HTML5 Video not displaying

Hello, so I am trying to play a html5 video hosted on my localhost in Minecraft specifically webdisplays. I put the correct URL and stuff and it loaded. But when I went over to play the HTML5 video, it was greyed out meaning I couldn't play the video?
Is there anyway I can fix it? It seems to be a bug.

Only freely available audio and video codecs are supported.
See https://github.com/cefsharp/CefSharp/wiki/General-Usage#multimedia-audiovideo


Ignore node_modules in all projects

Is it possible to ignore folders, like node_modules, from the home dir config file?
I tried the following but it didn't work. In the ~/.scss-lint.yml file, I put the following:
exclude:
  - '*.css'
  - 'node_modules/**'

This didn't work. It only worked if I put it in a project's .scss-lint.yml file. Is this intentional? I know the docs say the paths are relative to the config file. So this means that it's not possible to exclude node_modules for all projects, since it's definitely something that I don't mind being a global exclude?

Duplicated of #516. Feel free to contribute to the discussion there, but at its core we are happy to add this if someone submits a pull request!


unable to build tensorflow for GPU

NOTE: Only file GitHub issues for bugs and feature requests.  All other topics will be closed.
For general support from the community, see StackOverflow.
To make bugs and feature requests more easy to find and organize, we close issues that are deemed
out of scope for GitHub Issues and point people to StackOverflow.
For bugs or installation issues, please provide the following information.
The more information you provide, the more easily we will be able to offer
help and advice.
What related GitHub issues or StackOverflow threads have you found by searching the web for your problem?
Environment info
Operating System:
Installed version of CUDA and cuDNN:
(please attach the output of ls -l /path/to/cuda/lib/libcud*):
If installed from binary pip package, provide:

A link to the pip package you installed:
The output from python -c "import tensorflow; print(tensorflow.__version__)".

If installed from source, provide

The commit hash (git rev-parse HEAD)
The output of bazel version

If possible, provide a minimal reproducible example (We usually don't have time to read hundreds of lines of your code)
What other attempted solutions have you tried?
Logs or other output that would be helpful
(If logs are large, please upload as attachment or provide link).
bazel build -c opt --config=cuda //tensorflow/tools/pip_package:build_pip_package
..
WARNING: Sandboxed execution is not supported on your system and thus hermeticity of actions cannot be guaranteed. See http://bazel.io/docs/bazel-user-manual.html#sandboxing for more information. You can turn off this warning via --ignore_unsupported_sandboxing.
WARNING: /home/ammalik/TensorFlow/tensorflow/util/python/BUILD:11:16: in includes attribute of cc_library rule //util/python:python_headers: 'python_include' resolves to 'util/python/python_include' not in 'third_party'. This will be an error in the future.
INFO: Found 1 target...
ERROR: /home/ammalik/.cache/bazel/_bazel_ammalik/27908a9a0ff0347c2aebe63a8fa99002/external/zlib_archive/BUILD:7:1: undeclared inclusion(s) in rule '@zlib_archive//:zlib':
this rule is missing dependency declarations for the following files included by 'external/zlib_archive/zlib-1.2.8/compress.c':
'/opt/local/gcc/6.2.0/lib/gcc/x86_64-pc-linux-gnu/6.2.0/include-fixed/limits.h'
'/opt/local/gcc/6.2.0/lib/gcc/x86_64-pc-linux-gnu/6.2.0/include-fixed/syslimits.h'
'/opt/local/gcc/6.2.0/lib/gcc/x86_64-pc-linux-gnu/6.2.0/include/stddef.h'
'/opt/local/gcc/6.2.0/lib/gcc/x86_64-pc-linux-gnu/6.2.0/include/stdarg.h'.
Target //tensorflow/tools/pip_package:build_pip_package failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 962.954s, Critical Path: 0.69s

You'll get more sympathy if you actual use the template instead of just quoting it, but I believe your problem is related to/helped by https://github.com/tensorflow/tensorflow/issues/3431#issuecomment-234131699.
It that doesn't work: your gcc is a custom install, right? You'll probably have it easier using your distributions standard builchain.

Are you using CUDA 8.0? Right now we only support 7.0 - 7.5. But we're actively working on supporting 8.0. See #2559.
@davidzchen is it possible setting the CUDA toolchain is what caused the "undeclared inclusion" error with zlib? Possible duplicate of #2109.

When building natively, I can build using cuda8 without any problems.
But this issue report is missing too much information.
Is it possible reporter is missing either the prerequisites:
$ sudo apt-get install python-numpy swig python-dev python-wheel
Or forgot running ./configure before building?

Closing due to inactivity. Feel free to reopen if this is still an issue (and please add more information as requested in the comments above).


please update readme regarding comparison with whisper.cpp and possibly others

Hello, I noticed the readme compares whisper.cpp and gives certain transcription times for it.  Can someone please update that perhaps?  There's been a recent release that addresses the beam size slowdown with whisper.cpp that I believe is significant...See here:
https://github.com/ggerganov/whisper.cpp/releases/tag/v1.5.0
It states:
At last, whisper.cpp now supports efficient Beam Search decoding. The missing piece was the implementation of batched decoding...On modern NVIDIA hardware, the performance with 5 beams is the same as 1 beam thanks to the large amount of computing power available. With Metal, the speed with 5 beams is a bit slower compared to 1 beam, but it is significantly faster compared to 5x times the time for single batch which was observed with the old naive implementation.
Also, if possible can there be direct "apples to apples" comparisons with other options as well such as:
https://github.com/sanchit-gandhi/whisper-jax
https://github.com/Vaibhavs10/insanely-fast-whisper
EDITED:
I'm messaged the fine folks over at Huggingface as well for clarification, the goal being to get accurate numbers and not hyperbole.  Thanks!
SEE HERE
AND SEE HERE
And I'd like to get comparisons from the whisper.cpp people as well, but they don't compare their implementation to faster-whisper nor jax nor insanely-fast-whisper so...not as concerned.

Here's a link to my updated conversation with the developer of insanely-faster-whisper if anyone is interested:
https://github.com/Vaibhavs10/insanely-fast-whisper/issues/82
Also, I'm not even sure if the newer GGUF format from llama.cpp uses float 32 anymore let alone float 16.  The only overlap with faster-whisper might be 8-bit quant...so if that's the case I'd ask for some re-testing of 8-bit for a true comparison.


Fixing * parsing in Markdown on federation page

The federation encyclopedia entry has an errant * that is being parsed as a Markdown italics formatter: https://developers.stellar.org/docs/encyclopedia/federation#supporting-federation
This commit fixes that bug, and also cleans up a bit of the language surrounding it.

Preview is available here:http://developers-pr153.previews.kube001.services.stellar-ops.com


Fixed #648 - JaxrsReader does not respect @ApplicationPath annotations

Fixed #648 by adding support for @ApplicationPath annotation to JaxrsReader.

Closing inactive PR. Please re-open with merge conflicts resolve if still interested. Thank you


[BUG] Cannot read property 'total_weight' of undefined

Getting an issue where the tacho doesn't load in properly
Log below is from starting the game, loading into Small Grid with a modless Piccolina config, then exiting, all after deactivating every mod except this one and cleaning cache

beamng.log

Hello, thank you for the report, indeed, I also had the problem, I will try to patch it

Update is push on the REPO
Wait the dev :)

It's live
Try it ;)

Hey buddy, had the same issue too and redownloaded it in the repo, but for some reason they still won't work (with the same errors in the console). Maybe it's a mod I have or something?

You use a vehicule mod ?
I have 200 mods on a server, with Tacho3, and I don't have the problem :D

I would have to manage to reproduce it, how do you do it? what actions?

Apparently the tacho started working again after i removed the ui app and added the basic version, then added the v2 tach back in, no idea what was going on beforehand
I guess if this method doesn't end up working for others if they end up getting this issue, then this can be reopened in the future

@Bogle911 ?

@ToadtheFungus Thank you for the feedback, for the moment, I can't create the error on my side

Im having the same issue as @ToadtheFungus where it doesnt work but adding the basic version then removing it suddenly makes it tick, though it isnt persistent a game relaunch means I have to redo that step (sorry if youre already working on a fix im just throwing my hat into the ring)

Y'all have NO other mods, and you add my mods by hand?

@Bogle911 ?

Sorry for the late reply, but yeah I have a majority of my mods off (including anything that effects the ui except yours). And somehow it's still unable to read it.

Are you installing the mods via the repo?
You haven't enhanced tacho yet?
I tested on 3 PCs? made complete reinstalls, I absolutely cannot reproduce the problem
I'm going to try a new ZIP, I'll post it to you here during the day

Try :
fix4.zip
@Bogle911 @MlordSlav @ToadtheFungus
I finally generate the bug, and therefore, correct it

Works as it should now, nice job!


Reorganising the repository

This PR will reorganize the crates, dependencies and folder structures to make the client/runtime barrier more explicit and cleaner. For that it will move and rename crates, move traits and primitives and rebrand the srml - now paint.

[x] move docs
[x] move node, node-template & subkey into /bin
[x] clean up scripts
[ ] move primitives into runtime
[x] move core -> client
[ ] move srml -> paint
[ ] split interfaces & primitives from paint and core into runtime
[ ] fix up dependencies:

[ ] nothing in core depends on paint
[ ] nothing in runtime depends on paint
[ ] only bin pulls together runtime, client, and paint
[ ] unify dependency names across the system

[ ] clean up runtime/paint crates

[ ] clean up support
[ ] clean up system
[ ] split out storage and other isolated components

Optionally:

[ ] make subkey a subcommand of cli
[ ] externalize tests
[ ] combine core/client and core/service into one combining crate

Please use git mv for moving files around and preserving history. E.g. README.adoc looks like a new file, even though matches the previous document.

I did use git mv 🤔 ...
On Sun, 10 Nov 2019, 17:23 Arkadiy Paronyan<EMAIL_ADDRESS>wrote:

Please use git mv for moving files around and preserving history. E.g.
README.adoc looks like a new file, even though matches the previous
document.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/paritytech/substrate/pull/4074?email_source=notifications&email_token=AAAJ4MFUEDNJQTHCZNZRVZ3QTAYO7A5CNFSM4JLMMRXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDVA4EA#issuecomment-552209936,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAJ4MB3LKDESZDNNEUR5QTQTAYO7ANCNFSM4JLMMRXA
.

--
This communication and any attachments are confidential.

externalize tests

@bkchr , @tomusdrw : what do you think about this idea: Rather than having -test-suffixed crates in client/paint, let's move all integration tests into top-level /tests.
It would be aligning with the usual pattern used in the rust world, would allow us to have ci-scripts ensuring the dependency-rules are enforced (easily by disallowing imports crossing the entire client and paints sub-dirs) and make clear what should and shouldn't be publishable on crates.io.
What do you say?

Which kind of integration test crates do we currently have?
Regarding build-only-wasm.sh, this is no management script. So it should not be moved into .maintainer.

Which kind of integration test crates do we currently have?

I would consider everything pulling in test-client an integration test. They are currently often bundled in the crate directly, but as we were saying already, must now be split out into their own non-publishable -test-suffixed crate (so the dev-dependencies don't leak through and taint our new nice clean dependency rules). The only thing I am proposing is to move them into /tests rather than in a subdirectory per crate.
The main argument to keep them in a subdirectory is obviously to have them bundled closer together, which is also nice... Though we could also symlink ... but that's less nice...

Regarding build-only-wasm.sh, this is no management script. So it should not be moved into .maintainer.

What is it then? Nothing in substrate references it, so is it not a helper to maintain the repo? (not maintainer, btw)

Regarding build-only-wasm.sh, this is no management script. So it should not be moved into .maintainer.

What is it then? Nothing in substrate references it, so is it not a helper to maintain the repo? (not maintainer, btw)

It can be used when you want to just rebuild the wasm runtime of your project.

combine core/client and core/service into one combining crate

What's the reasoning for that? Why not reexport client from service instead?

combine core/client and core/service into one combining crate

What's the reasoning for that? Why not reexport client from service instead?

Yeah, why? We should split up the crates more, to improve the compilation times. Combining those crates will blow up in our face really directly.

Yeah, why? We should split up the crates more, to improve the compilation times. Combining those crates will blow up in our face really directly.

I came by @tomaka earlier, but should have written it down here, too, I guess. I updated the task to say:

split core/client into its sub-components as standalone crates and move the remaining glue into core/service into one combining crate

The thinking is: if we actually split out more of the traits, either into runtime or a client-traits and then split out the independent components, the actual remaining in client is the struct having two actual functions and all others are just patching through to the traits (leading to us lazy devs depending directly on it rather than the descriptive trait). So, the thinking goes: to prevent us being that lazy and also because the glue is effectively only needed for service, the distinction of client and service is ... just weird.

This needs to be merged before as well: https://github.com/paritytech/substrate/pull/4086

@gnunicorn I disagree that the service and client crates should be unified. Service is about gluing together a block database / import (i.e. client) with network and other background workers. Unifying them means that there is no way to depend on only the database/import aspects without pulling in the entirety of libp2p and more. That is pretty bad IMO.

There is clearly a misunderstanding regarding the client unification: the general idea is split what is currently in the substrate-client-crate into subcomponents and interfaces that can be imported independently from substrate-client and then think about unifying client and service.

Can you create a script that does this reorg?  There is no way I can review this by hand.

@gnunicorn you or anybody else deleted the CODEOWNERS file. That needs to be restored.

Nope, [it was moved to docs](
https://github.com/paritytech/substrate/blob/the-big-reorg/docs/CODEOWNERS]

which is a valid place to store it according to github documentation.

On Wed, 13 Nov 2019, 21:02 Bastian Köcher<EMAIL_ADDRESS>wrote:

@gnunicorn https://github.com/gnunicorn you or anybody else deleted the
CODEOWNERS file. That needs to be restored.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/paritytech/substrate/pull/4074?email_source=notifications&email_token=AAAJ4MCXTSL4QTUB7IGOJIDQTRMO7A5CNFSM4JLMMRXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOED7OZ4A#issuecomment-553577712,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAJ4MD4UOPJPQXS2CUDRPLQTRMO7ANCNFSM4JLMMRXA
.

--
Wichtige Mitteilung
Diese Mitteilung wurde von Parity Technologies
Deutschland GmbH kommuniziert, eine im Handelsregister des Amtsgerichtes
Charlottenburg unter HRB 190583 B registrierte Gesellschaft mit
beschränkter Haftung (GmbH). Die Geschäftsführerin der GmbH ist Frau Dr.
Jutta Steiner. Der registrierte Geschäftssitz ist Glogauer Straße 6 in
10999 Berlin, Deutschland.
Diese Mitteilung enthält Informationen welche
vertraulich sind und welche eventuell die Vertraulichkeit der
Rechtsberatung ("Anwaltsgeheimnis") berühren. Sie ist ausschließlich für
den/die vorgesehenen Empfänger bestimmt. Wenn Sie nicht der/die
beabsichtigte(n) Empfänger sind, benachrichtigen Sie bitte<EMAIL_ADDRESS><EMAIL_ADDRESS>und löschen Sie diese Nachricht sofort.

Some moves seem not to have been done with git mv? Like client/api/src/backend.rs. That's going to kill history for those files.

All moves have been done with git mv but if then other changes happened to the file, git(hub) history doesn't really show that. That is due to the way git handles changes internally, there isn't really a distinction between git rm file && git add file_at_new_path and git mv file file_at_new_path, similarly as it can't have any empty folders. For a changeset with moves and changes, that squashed it is almost impossible to retain a state that the history shows as moves only.


build(deps): update scalafmt-core from 3.4.2 to 3.4.3

Updates org.scalameta:scalafmt-core from 3.4.2 to 3.4.3.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scalameta", artifactId = "scalafmt-core" } ]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Codecov Report

Merging #48 (d3fabca) into main (dc743c3) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main       #48   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            1         1
  Lines           18        18
  Branches         1         1
=========================================
  Hits            18        18

Continue to review full report at Codecov.

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


Implement support for getSupportedVoices and voice selection on iOS

This would close #37 and partially complete #38 - I'll take a shot at Android shortly in another PR

I'll take a shot at Android shortly in another PR

Please create two separate PRs for #37 and #38 so that in case of an issue the features can be reverted individually. It also makes it easier to review the PRs.

Closing in favor of #91 and #92


Release compilation issue using Swift PM

Goals

Build project with Realm via Swift Package Manager
Expected Results

The project to build successfully, but it doesn't (However it works ok with same version on Cocoapods)
Actual Results

Showing All Messages
/Users/dave/Library/Developer/Xcode/DerivedData/TestRealm-cexqmmixscidkqairqvranppknzi/SourcePackages/checkouts/realm-core/src/realm/alloc.hpp:328:5: Aligned deallocation function of type 'void (void *, std::align_val_t) noexcept' is only available on iOS 11 or newer
Steps for others to Reproduce

Create a new Xcode project - i'm using 12.1. I don't change any of the defaults.
iOS deployment target is 14.1
I add swift package dependency at repo: https://github.com/realm/realm-cocoa
I do an archive/release build
It doesn't build

(note that if I use Cocoapods, then it works ok)
Code Sample

Version of Realm and Tooling

Realm framework version: ?
Realm Object Server version: ?
Xcode version: 12.1
iOS/OSX version: 14.1 / Mac 10.13.6
Dependency manager + version: Swift PM

Sorry...closing/opening... i hit enter by mistake... it's late.. i'm tired. 😂😢

The fix for this will be available in the next release of Realm Cocoa.

Until then you can point realm-core to master if you need to release, the fix is already there.


Added highlightDates2 and highlightDates3 ranges

Sometimes we need diffrent highlighted date ranges with diffrent styles. I added highlightDates2 and highlightDates2 props. It can be very useful to apply different styles.

Codecov Report

Merging #840 into master will decrease coverage by 0.26%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #840      +/-   ##
==========================================
- Coverage   85.89%   85.62%   -0.27%
==========================================
  Files          12       12
  Lines         645      640       -5
  Branches      120      120
==========================================
- Hits          554      548       -6
- Misses          7        8       +1
  Partials       84       84

Impacted Files
Coverage Δ

src/month.jsx
82.6% <ø> (-0.38%)
:arrow_down:

src/calendar.jsx
87.06% <ø> (-0.66%)
:arrow_down:

src/week.jsx
68.18% <ø> (-1.39%)
:arrow_down:

src/datepicker.jsx
91.66% <100%> (+0.1%)
:arrow_up:

src/day.jsx
89.06% <100%> (-1.08%)
:arrow_down:

Continue to review full report at Codecov.

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

Ok, I think it might be an array. I'll do it.

Cool, keep in mind that the API will need to be backwards-compatible

Yep, this.highlightedDates may be an array of moment or multidimensional array of moments

That could work; it's not obvious how you might specify the class name for the additional date ranges in a sane way, but maybe you can find something that works well =)

I think className + arrayIndex, like ''react-datepicker__day--highlighted2''. Beside this, have no idea how to make it better.


Feat/target option

Summary
The option target, denoting the target architectures the extension can be used on, was added to the Action, since both vsce and osvx now support it.
Changes

optional target option added to the Action

Related Issues
Implements #37

Hey @HaaLeo, thanks for this extension! I'm already using it to publish my theme and am happy to help make VS Code extensions available on more platforms!
I looked at the sources from osvx and implemented this according to how I understood those, since it seems like osvx handles target differently...but I'm not 100% certain if I got it all right 😅. Is there any way to test the extension in this "development" state?

Hi @alexravenna, thx for your contribution. It is somewhat trick to test this GH action. But you can reference your repo/branch instead of HaaLeo/publish-vscode-extension@v1. I've done that before with a hello-world VS Code extension.
I'll hope to be able to review your PR throughout this week. But I cannot promise 😅

This doesn't quite work. With the following snippet (note the dry-run), the generated visx does not include TargetPlatform="linux-x64" as expected
     - name: Package Extension
       id: packageExtension
       uses: HaaLeo/publish-vscode-extension@v1
       with:
         pat: stub
         preRelease: true
         dryRun: true
         yarn: true
         target: ${{ matrix.config.name }}

A quick look at the commits in this PR shows that the --target option is applied to the publishing step, which makes some sense.
However, since the action also supports dryRun (pack only), that mode should not generate a defective visx.


update.intl.miui.com is needed for Xiaomi Smartphones

update.intl.miui.com is used to check for firmware updates. This hurts security.

From the search:
https://github.com/unknownFalleN/xiaomi-dns-blocklist/issues/24
https://github.com/hagezi/dns-blocklists/issues/794
Thanks for pointing out the issue.

Also removed:
api.sec.intl.miui.com

Also added some trackers from https://github.com/AdguardTeam/AdGuardSDNSFilter/issues/1278 which I missed earlier


Bugfixes

Resolve #307
Resolve #355
Resolve #372
Resolve #402
Adjust kokomi skill timing
Fix kokomi skill not clearing the burst dmg bonus snapshot on 2nd swap
Add attack element to damage log

reviewed all except optimizer regex change. everything else looks ok. if you're confident with optimizer regex change go ahead and merge


Added 'destroy' method to affix

I'm writing an ajax application that requires the affix plugin to be toggled on and off, depending on whether the page/content as sufficient height to warrant the affix.
The destroy method has allowed me to do this, and I think could be useful to others.  It removes the the plugin from the element, stops the events triggering, and removes any styles.
If this is indeed useful to others, the unit test could be fleshed out to ensure the style and event triggering are removed - right now it just checks the plugin was removed.

Tests passed. Automated cross-browser testing via Sauce Labs and Travis CI shows that the JavaScript changes in this pull request are: CONFIRMED
Commit: ab67f16ca424fce032d78e47a38fa82533f845cf
Build details: https://travis-ci.org/twbs-savage/bootstrap/builds/80094962
(Please note that this is a fully automated comment.)

All the plugins have destroy methods in Bootstrap v4. Not sure what our stance is on trying to add them to v3.

Bootstrap 3 is no longer being officially developed or supported.
All work has moved onto our next major release, v4. As such, this issue or pull request is being closed as a "won't fix." For additional help and support, we recommend utilizing our community resources. Thanks for your understanding, and see you on the other side of v4!
<3,
@mdo and team


Jupyter mimetypes

We need to support

[x] application/javascript - #8
[x] text/html (partially, see #2)
[x] text/markdown - #4
[x] text/latex - #7
[ ] image/svg+xml
[X] image/gif
[X] image/png
[X] image/jpeg
[ ] application/pdf
[X] text/plain

Knocked out the simple ones first to get an interface started.

Considering how application/pdf is implemented on the notebook (a link), I'm not implementing that one.

It would be good to revisit the svg component with React 15, coming out :soon:. Alternatively, we can bring in the native DOM bits of what @n-riesco implemented for Hydrogen.


Update connect middleware for 1.0

Several changes:

Reuse of an existing client

client instanceof Raven.Client

returned false, preventing an existing client from being used.

Create raven instances with Raven.config instead of new Raven.Client

DRYer code. Made the existing client check into a reusable function.

@dhritzkiv thanks for the report/fix. I see the issue here - the new recommended usage is fine, but the backwards compat interface on top of it is slightly broken.
I generally agree with most of your changes except the switch to using Raven.config instead of new Raven.Client. Raven.config is not an instance factory - it's a config method on an existing instance.Changing new Raven.Client to Raven.config here will just update the config on the singleton instance and return that, rather than creating a new instance with the given config.
I'm going to take your PR and make this change + a couple small tweaks on top and publish it to get the patch out quickly. This will go out as v1.0.1 and v1.1.1.

Resolved in #246.


Koel on a multi-server environment

How would koel be installed on a multi-server environment? As it requires node, typically node applications are installed with the following setup:
+-------+          +--------+          +---------+
| Nginx |          |        |          |         |
|Reverse| <------> | Nodejs | <------> |  Mysql  |
| Proxy |          |        |          |         |
+-------+          +--------+          +---------+

However, koel requires php as well - which makes the matter more confusing. I've never used laravel before, but it looks like it requires a webserver to work.
How would one install koel on a multi-server setup? Do you install it on the "backend" side, behind the virtual network and proxy things using nginx? How do you do that?
Some pseudocode would be much appreciated, as I'm trying to set it up this way. If I can solve this issue, I would graciously make a pull request to the documentation, and document the procedures for a multi-server setup. Thank you!

Do you install it on the "backend" side, behind the virtual network and proxy things using nginx?

Yep. It's actually what my setup looks like. After installing PHP, basically you have two choices:

Configure nginx to run PHP with PHP-FPM, or
Install Apache and use nginx to proxy it.

Both should be fairly straightforward, and you'll find a lot of tutorials online tailored for Laravel itself. Good luck!


How can I use RVC on my CPU?

I have an NVIDIA graphics card, but I don't want to use the GPU, I just want to use my CPU.
When I run my code, RVC automatically runs on my GPU.
How can I change the device?

OK, i'll support that

I created a pull request where I fix this by adding a variable that allows you to use the CPU or GPU for inference.


Respect defer_build for Pydantic dataclasses

Also return early if defer_build is set for Pydantic models.

Change Summary

Related issue number

Checklist

[ ] The pull request title is a good summary of the changes - it will be used in the changelog
[ ] Unit tests for the changes exist
[ ] Tests pass on CI
[ ] Documentation reflects the changes where applicable
[ ] My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

So the reason why the added _force_build argument was required is because currently ultimately, rebuild_dataclass calls complete_dataclass. Because the configuration can come from both the decorator or the __pydantic_config__ attribute, complete_dataclass sets cls.__pydantic_config__:
https://github.com/pydantic/pydantic/blob/59a3de71c6592a0e088ce9c7c4c7dd1950a05b7b/pydantic/_internal/_dataclasses.py#L146
So that the following works as expected:
@pydantic_dataclass(config={'strict': True}
class DC:
    a: int

assert DC.__pydantic_config__ == {'strict': True}

If in rebuild_dataclass, we pass a new config object, as done currently here:
https://github.com/pydantic/pydantic/blob/c2a325b720d70b692603f8150c161f2b9bd136a2/pydantic/dataclasses.py#L338-L345
The following will happen:
@pydantic_dataclass
class DC:
    __pydantic_config__ = {'defer_build': True}  # or as a decorator parameter, doesn't matter

assert DC.__pydantic_config__ == {'defer_build': True}
rebuild_dataclass(DC)
assert DC.__pydantic_config__ == {'defer_build': True}  # AssertionError, `'defer_build'` is now set to `False`

And is inconsistent with the BaseModel behavior. Besides, I think the config dict on models and dataclasses shouldn't change after the class is defined, no matter if a rebuild was performed or not.

And is inconsistent with the BaseModel behavior. Besides, I think the config dict on models and dataclasses shouldn't change after the class is defined, no matter if a rebuild was performed or not (and this is what's causing issues with TypeAdapter failing tests I think).

I see, makes sense. Let's revert back then to use the _force_build flag. Apologies for the back and forth on the diff.


ci: Add just configuration for GPU benchmarks and deployment

Upgrades bench runners and enables benchmark configuration via a justfile and bench.env.

We should switch to fibonacci with a canned config, or more specifically pushing a justfile to the repo:
https://github.com/casey/just

just is amazing, but thought I'd mention a few issues I've had from a first pass with it:

No explicitly supported lists or for loops, have to use shell script
Unclear what the difference is between a recipe, script, and variable
Comments aren't always comments, e.g. the line before a shebang script
Conflicting syntax/patterns for global set shell vs shebang script
No actively maintained VSCode integration
Beware of hidden tabs when copy-pasting, causing whitespace errors
Unhelpful error messages make it tricky to debug
Not great support for nushell
Doesn't support interpolation of strings and backticks (yet)

None of these are disqualifying, but it will need some additional effort if we want the whole team to use it for bench/CI configuration.

If you would prefer a python script, a shell script, or anything else to host the benchmark command instead of a justfile

Nothing better immediately comes to mind, pardon the late-night rant :smile: In the interests of time LGTM, and advocate for justfile usage mainly in GH actions rather than general-purpose bench scripting for now.

@samuelburnham see https://github.com/samuelburnham/lurk-rs/pull/8


(maint) Remove broken benchmark test

Refer to this link for build results (access rights to CI server needed):
http://jenkins-enterprise.delivery.puppetlabs.net/job/enterprise_puppetdb_init-multijob_githubpr-stable/43/
Test FAILed.

Refer to this link for build results (access rights to CI server needed):
http://jenkins-enterprise.delivery.puppetlabs.net/job/enterprise_puppetdb_init-multijob_githubpr-stable/42/
Test PASSed.


Feature: Improve UI of About Page

About Feature
The feature is of improved UI of the about page.
Description
-The About page UI is not smooth, causing a bad experience for the visitor.
-Fix the incorrect page title
Technologies Used
Screenshot

Connect Us On Social Media -

[X]  Star the repository
[X]  GitHub
[X]   LinkedIn
[X]   YouTube
[X]    Discord

Thank you for raising the issue in GameSphere 3.0

@Durgesh4993 Looking forward to getting assigned!