Add new rule for next(iter()) and next(iter())

Suggest change from next(iter(<comprehension>)) and next(iter(<generator>)) to next(<generator>) as next() will happily consume a generator. Need to be aware of the default argument to next() in which case the generator will need still to be wrapped in parentheses and the sentinel argument to iter() in which case this change cannot be recommended.
Also note that we cannot have a more generic rule for iter(<comprehension>) to <comprehension> as the type of the former is an iterator and the latter is an iterable (or collection/sequence), e.g. list vs listiterator.
This will work for list, set and tuple comprehensions as they implicitly create iterators, but not for dict.
This change could also apply in other contexts where the return of iter() is not assigned to a variable and will never be reused, e.g. sorted(iter(...)).

+1 on this
I came across numerous instances of this in projects I was looking at


Failed to read configuration file

I just installed this gem but when I run it I get the following. Do you know why?
$ hue
Failed to read configuration file
Cause: No such file or directory - /home/rich/.hue-cli/applications.yml

It won't help. I have the same issue and the logged response returns:
I, [2016-06-21T20:35:03.802407 #4617]  INFO -- : Found bridge (<IP_ADDRESS>:1900) with uuid: 2f402f80-da50-11e1-9b23-00178821ab7c I, [2016-06-21T20:35:05.577092 #4617]  INFO -- : UDPSocket timed out. I, [2016-06-21T20:35:05.579458 #4617]  INFO -- : Sending {"username":"386022600cc7a6d4af9390af19e06369","devicetype":"hue-cli"} to http://<IP_ADDRESS>/api I, [2016-06-21T20:35:05.592671 #4617]  INFO -- : Response 200 OK: [{"error"=>{"type"=>6, "address"=>"/username", "description"=>"parameter, username, not available"}}]
The username is deprecated and shouldn't be part of the request anymore. See:
https://github.com/Veraticus/huey/pull/24/commits/a479992e13ed064dbefcafc979e3b6ee38ed4150

i found that creating an empty file got around this but now I'm getting this.
`rich@Linuxbox:~$ hue
Application not registered.
Found bridges:
http://<IP_ADDRESS>/api (uuid: 2f402f80-da50-11e1-9b23-00178824a4b8)
Please type 'hue register' to register your application with the bridge.
rich@Linuxbox:~$ hue register
Please press the button on your bridge.
Once done, press Enter to continue with the registration.
Registering app...(b2a7381dc1c76a2ac61dba36e7781725)
parameter, username, not available
`

The registering is broken in hue-lib. I used the Python Library Phue and successfully requested a valid key. Afterwards updated the configuration file manually. Like this everything works fine.

Yup, it's broken. I'll try and test on my bridge and fix it.

Any News? I'm blocked too

Fixed.


A few of my devices stopped working today

Govee Device SKU
H6062 H6062 H6072
Govee2MQTT Version
2024.04.29-30cf7732
Describe the issue
here is the error msg :
Anyone else experieincing this?
[2024-06-02T20:33:07 INFO  govee::commands::serve] Starting service. version 2024.04.29-30cf7732
[2024-06-02T20:33:07 INFO  govee::commands::serve] Querying platform API for device list
[2024-06-02T20:33:07 INFO  govee::commands::serve] Querying undocumented API for device + room list
Error: database disk image is malformed
Caused by:
Error code 11: The database disk image is malformed
Stack backtrace:
0: anyhow::error::<impl core::convert::From for anyhow::Error>::from
1: govee::cache::cache_get::{{closure}}
2: govee::undoc_api::GoveeUndocumentedApi::login_account_cached::{{closure}}
3: govee::commands::serve::ServeCommand::run::{{closure}}
4: govee::Args::run::{{closure}}
5: tokio::runtime::park::CachedParkThread::block_on
6: tokio::runtime::context::runtime::enter_runtime
7: tokio::runtime::runtime::Runtime::block_on
8: govee::main
9: std::sys_common::backtrace::__rust_begin_short_backtrace
10: std::rt::lang_start::{{closure}}
11: core::ops::function::impls::<impl core::ops::function::FnOnce for &F>::call_once
at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/ops/function.rs:284:13
12: std::panicking::try::do_call
at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/panicking.rs:554:40
13: std::panicking::try
at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/panicking.rs:518:19
14: std::panic::catch_unwind
at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/panic.rs:142:14
15: std::rt::lang_start_internal::{{closure}}
at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/rt.rs:148:48
16: std::panicking::try::do_call
at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/panicking.rs:554:40
17: std::panicking::try
at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/panicking.rs:518:19
18: std::panic::catch_unwind
at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/panic.rs:142:14
19: std::rt::lang_start_internal
at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/rt.rs:148:20
20: main
s6-rc: info: service legacy-services: stopping
s6-rc: info: service legacy-services successfully stopped
s6-rc: info: service legacy-cont-init: stopping
s6-rc: info: service legacy-cont-init successfully stopped
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped
Startup Diagnostics
10: std::rt::lang_start::{{closure}}
11: core::ops::function::impls::<impl core::ops::function::FnOnce for &F>::call_once
at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/ops/function.rs:284:13
12: std::panicking::try::do_call
at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/panicking.rs:554:40
13: std::panicking::try
at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/panicking.rs:518:19
14: std::panic::catch_unwind
at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/panic.rs:142:14
15: std::rt::lang_start_internal::{{closure}}
at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/rt.rs:148:48
16: std::panicking::try::do_call
at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/panicking.rs:554:40
17: std::panicking::try
at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/panicking.rs:518:19
18: std::panic::catch_unwind
at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/panic.rs:142:14
19: std::rt::lang_start_internal
at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/rt.rs:148:20
20: main
s6-rc: info: service legacy-services: stopping
s6-rc: info: service legacy-services successfully stopped
s6-rc: info: service legacy-cont-init: stopping
s6-rc: info: service legacy-cont-init successfully stopped
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
++ cd /app
++ exec /app/govee serve
GOVEE_API_KEY=REDACTED
GOVEE_MQTT_HOST=core-mosquitto
GOVEE_TEMPERATURE_SCALE=C
GOVEE_EMAIL=REDACTED
GOVEE_PASSWORD=REDACTED
GOVEE_MQTT_PASSWORD=REDACTED
GOVEE_MQTT_USER=addons
GOVEE_MQTT_PORT=1883
[2024-06-02T20:36:33 INFO  govee::commands::serve] Starting service. version 2024.04.29-30cf7732
[2024-06-02T20:36:33 INFO  govee::commands::serve] Querying platform API for device list
[2024-06-02T20:36:33 INFO  govee::commands::serve] Querying undocumented API for device + room list
Error: database disk image is malformed
Caused by:
Error code 11: The database disk image is malformed
Stack backtrace:
0: anyhow::error::<impl core::convert::From for anyhow::Error>::from
1: govee::cache::cache_get::{{closure}}
2: govee::undoc_api::GoveeUndocumentedApi::login_account_cached::{{closure}}
3: govee::commands::serve::ServeCommand::run::{{closure}}
4: govee::Args::run::{{closure}}
5: tokio::runtime::park::CachedParkThread::block_on
6: tokio::runtime::context::runtime::enter_runtime
7: tokio::runtime::runtime::Runtime::block_on
8: govee::main
9: std::sys_common::backtrace::__rust_begin_short_backtrace
10: std::rt::lang_start::{{closure}}
11: core::ops::function::impls::<impl core::ops::function::FnOnce for &F>::call_once
at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/core/src/ops/function.rs:284:13
12: std::panicking::try::do_call
at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/panicking.rs:554:40
13: std::panicking::try
at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/panicking.rs:518:19
14: std::panic::catch_unwind
at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/panic.rs:142:14
15: std::rt::lang_start_internal::{{closure}}
at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/rt.rs:148:48
16: std::panicking::try::do_call
at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/panicking.rs:554:40
17: std::panicking::try
at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/panicking.rs:518:19
18: std::panic::catch_unwind
at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/panic.rs:142:14
19: std::rt::lang_start_internal
at /rustc/25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04/library/std/src/rt.rs:148:20
20: main
s6-rc: info: service legacy-services: stopping
s6-rc: info: service legacy-services successfully stopped
s6-rc: info: service legacy-cont-init: stopping
s6-rc: info: service legacy-cont-init successfully stopped
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
Additional Logs
No response
Home Assistant Logs
No response
Anything else?
No response

Sounds like you had a bad crash on the device running haos, and the cache database is corrupted.
I would suggest removing and re-adding the addon.

 You got it right indeed, had to uninstall and reinstall the add-on. Much thanks Wez!


IOError: [Errno 2] No such file or directory: '/tmp/tmpoW5Idw/chart/images/tiller.tgz'

hi, i'm using the tile-generator:latest docker image and get the following error during tile build:
Traceback (most recent call last):
  File "/usr/bin/tile", line 11, in <module>
    sys.exit(cli())
  File "/usr/lib/python2.7/site-packages/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/click/core.py", line 697, in main
    rv = self.invoke(ctx)
  File "/usr/lib/python2.7/site-packages/click/core.py", line 1066, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python2.7/site-packages/click/core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python2.7/site-packages/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/tile_generator/tile.py", line 72, in build_cmd
    build.build(cfg)
  File "/usr/lib/python2.7/site-packages/tile_generator/build.py", line 48, in build
    build_bosh_releases(config)
  File "/usr/lib/python2.7/site-packages/tile_generator/build.py", line 56, in build_bosh_releases
    tarball = bosh_release.get_tarball()
  File "/usr/lib/python2.7/site-packages/tile_generator/bosh.py", line 83, in get_tarball
    return self.build_tarball()
  File "/usr/lib/python2.7/site-packages/tile_generator/bosh.py", line 104, in build_tarball
    self.add_package(package)
  File "/usr/lib/python2.7/site-packages/tile_generator/bosh.py", line 203, in add_package
    download(file['path'], os.path.join(staging_dir, file['name']), cache=self.context.get('cache', None))
  File "/usr/lib/python2.7/site-packages/tile_generator/util.py", line 82, in download
    with open(filename, 'wb') as file:
IOError: [Errno 2] No such file or directory: '/tmp/tmpoW5Idw/chart/images/tiller.tgz'

yeah! i found the problem, the

helm_chart_dir: directory/to/helm/chart

was wrong and there were no images folder.

Also, make sure you add the images folder to your helm chart's .helmignore. (I think we have a PR to docs to include this step, and automating it is on the backlog, but a ways down.)

You can skip the .helmignore if it only contains images, we're doing that programmatically at this point: https://github.com/cf-platform-eng/kibosh/commit/7e405aa447408330bc3e3a58ffc3e2fa606d99ae


Specify version of php-parser to install with composer

php-parser 2.* is not currently compatible with this code

Hi, did you want to merge this notice?

Sorry, I missed it because of the holidays. Thank you very much :blush:

Thanks for your work on this project. As PHP 7 has been released without mysql_* I think it will be of increasing interest.


Issue with query validation?

My schema:
type Foo {
  id: ID!
  name: String!
}

type Query {
  foo(id: ID!): Foo
}

My query:
query($id: ID!) {
  foo(id: $id) {
    id
    name
  }
}

But I get a validation error:

Field foo contains type mismatch for argument id of type ID! which references variable $id of type ID!

This is unexpected since id and $id have the same type (ID!).

It works if I change ID! to String!, so it's probably just a missing case somewhere.

If I had to guess, it's probably here: https://github.com/Zaid-Ajaj/Snowflaqe/blob/14449d5343688bbe16b6eabcba9b4baa08905528/src/Query.fs#L329 (no case for "ID")

Hi @njlr, thanks a lot for filing the issue with the relevant debug information. Indeed I missed a case in the validation code but it should be fixed as of v1.5.1 :smile:


Push organization data to S3

Ref #213
Requires #298

Blocked by https://github.com/sul-dlss/operations-tasks/issues/1794


Setting a Dynamic SEQUENCE_NUMBER  for Imposm

Currently, the imposm process either stops or the container restarts. Our first suspicion is that it's due to the amount of workload coming to the container, which needs updates and improvements to the Kubernetes template.
Additionally, imposm currently uses an environment variable that represents the sequence of changesets (https://github.com/OpenHistoricalMap/ohm-deploy/blob/main/values.production.template.yaml#L363) from which it will start to recover the changes and apply them to the database. Therefore, when the container restarts, it begins from that date or from the sequence of changesets of that date, leading to a delay in getting the latest changesets. This is because the number of replications can be too many (https://planet.openhistoricalmap.org/?prefix=replication/minute/001/). For this reason, we need this sequence of changes to be dynamic or to be stored somewhere so that, when the container restarts, it starts from the latest update and not from past dates or past sequences of changesets.

done!!


Unable to create URL with that alias

Describe the bug
there is an error in the demo when clicking on the "Share Link" button that always appear on generating a link it says:
Branch.shareLink failed: Trouble creating a URL. Unable to create a URL with that alias. If you want to reuse the alias, make sure to submit the same properties for all arguments and that the user is the same owner.
Steps to reproduce
1.Open the demo on android device
2.click on "Share Link" button
3. select the sharing channel from the native popup
4. open the log and find the error that URL cannot be created as described in the description here
Expected behavior
Creating a link and copy it to clipboard or share it via other apps like whatsapp, facebook, etc
SDK Version
1.0.0
Unity Version
2021.3.27f1
Make and Model
Samsung S22 Ultra
OS
Android
Additional Information/Context
No response

any news on this?
I too face a similar issue in Flutter SDK.


Docs: Update AStar3D examples

Closes https://github.com/godotengine/godot-docs/issues/10230
The examples for custom distance calculations were comparing the IDs of the points, which doesn't really make sense. I updated the examples to use Manhattan distance as an example of non-Euclidean distance. class_name/[GlobalClass] is used here because MyAStar3D needs to be referenced from another class to be used.
Also changed _estimate_cost() to simply use the actual cost. The current example was not very instructive, since it was more expensive than calculating the real cost. This change I'm not 100% sure about.
Alternate names for Manhattan distance are "Taxicab distance" or "city block distance". Godot already uses "Manhattan distance" in a few places:
https://github.com/godotengine/godot/blob/e65a23762b36b564eb94672031f37fdadba72333/modules/noise/doc_classes/FastNoiseLite.xml#L117
https://github.com/godotengine/godot/blob/e65a23762b36b564eb94672031f37fdadba72333/doc/classes/AStarGrid2D.xml#L212-L213

For the context of navigation reviewers: I tested out this example in GDScript by extending AStar3D, adding a few points, and manually calling _compute_cost() and verifying that it returned the right values (in this case, Manhattan distance rather than Euclidean). However, I did not set up a complex test case, and I only tested the C# example to verify it compiled.

Thanks!


testThaliMobileNativeDiscoveryCoordinated.js - Getting all tests passed with the native layer

blocked on thaliproject/Thali_CordovaPlugin#1199


Unexpected token "name" of value "injector" in xxx.html.twig template

If you have this error, be sure the bundle is declared after AsseticBundle :
class AppKernel extends Kernel
{
    public function registerBundles()
    {
        $bundles = [
            ...
            new \Symfony\Bundle\AsseticBundle\AsseticBundle(),
            new AppVentus\AsseticInjectorBundle\AvAsseticInjectorBundle(),
            ...

It does avoid to override some AvAsseticInjectorBundle parameters.


New application builder (v17) does not live reload changes in linked libraries

Command
serve
Is this a regression?

[X] Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was
16.2.10
Description
The new application builder does not live reload changes to linked libraries using npm link
In order to make it work for now, revert to the old builder. For a new project, change @angular-devkit/build-angular:application to @angular-devkit/build-angular:browser and "browser": "src/main.ts", to "main": "src/main.ts", in angular.json.
Minimal Reproduction
Firstly, create a new library using terminal
ng new lib-workspace --no-create-application
cd lib-workspace
ng generate library my-lib
ng build
cd dist/my-lib
npm link
cd ../..
ng build --watch

Start another terminal
# Use SCSS and no SSR
ng new application-with-lib
cd application-with-lib
npm link my-lib

Replace app.component.ts
import { Component } from '@angular/core';
import { MyLibComponent } from 'my-lib';

@Component({
  selector: 'app-root',
  standalone: true,
  imports: [MyLibComponent],
  template: '<lib-my-lib></lib-my-lib>'
})
export class AppComponent {
}

Add preserveSymlinks = true to angular.json
"projects": {
    "application-with-lib": {
      ...
      "architect": {
        "build": {
          ...
          "options": {
            "preserveSymlinks": true,
            ...
}

Run the app
ng serve

Now change something in your library's my-lib.component.ts. Result is that no changes are reflected in your browser.
Exception or Error
No response
Your Environment
Angular CLI: 17.0.5
Node: 20.9.0
Package Manager: npm 10.1.0
OS: win32 x64

Angular: 17.0.5
... animations, cli, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1700.5
@angular-devkit/build-angular   17.0.5
@angular-devkit/core            17.0.5
@angular-devkit/schematics      17.0.5
@schematics/angular             17.0.5
ng-packagr                      17.0.2
rxjs                            7.8.1
typescript                      5.2.2
zone.js                         0.14.2

Anything else relevant?
No response

You need to specify the linked library in the tsconfig path mappings.
/* To learn more about this file see: https://angular.io/config/tsconfig. */
{
  "compileOnSave": false,
  "compilerOptions": {
     ...
    "paths": {
      "my-lib": [
        "./node_modules/my-lib"
      ]
    }
}

Currently, there is a problem however when using preserveSymlinks: true, which causes the update not to be picked up. This will addressed via https://github.com/angular/angular-cli/pull/26586


Read Mangas

Source information
Read Mangas 1.4.31
Source language
Português (Brasil)
Steps to reproduce
https://github.com/user-attachments/assets/30dd3ace-a754-4e4e-be29-ff61878440b6
Expected behavior
Carregar os capítulos
Actual behavior
Tá dando erro
Mihon/Tachiyomi version
TachiyomiSY 1.11.0
Android version
Android 11
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] I have updated the app to version 0.15.3.
[X] I have updated all installed extensions.
[X] I have tried the troubleshooting guide.
[X] If this is an issue with the app itself, I should be opening an issue in the app repository.
[X] I will fill out all of the requested information in this form.

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

Verdade!

Verdade!

Tá dando erro na hora de adicionar as obras na biblioteca também, infelizmente


Ensure header files are parseable for documentation

Problem
Some files have issues regarding documentation.  The following files have issues that need to be addressed:

[x] objects/text_object.h spews warnings about override
[ ] scriptable.h is a template
[ ] timeline.h is a template
[x] allegro_flare.h spits warnings about override
[x] automation.h spits warnings about override
[x] files in screens/ spit warnings
[x] interpolators.h spits warnings about extra ; at end of functions
[ ] files in the fonts/ are all extern definitions and do not parse

using the flag -Wno-c++11-extensions silences warnings for override and other c++11.

This comment was removed from useful.h essentially containing instructions on the old way to parse out definitions and headers.  (It's basically depreciated.)
// defines a list of general purpose, useful utility functions
// parsing this file for documentation is like this
// here is the regular expression for a section header: \n//\n// .+\n(//.*\n)*//\n\n
// captures the comments: \n(?P<comment>(\n\/\/ (.+))+)
// captures comments and definitions (but definitions have a leading newline: \n(?P<name>(\n\/\/ (.+))+)(?P<function_def>(\n.+)+)

OK update:  Documentation is no longer going to be included within in the source code.  Some early experiments messed around with using code and scripts to do this but it introduced a lot of extra noise. Doxygen has has been dropped as an option because it makes the code extra sloppy as well.
As of the time of this writing, the path forward is to write markdown files in the docs/ folder of the project.  For example, a the component AllegroFlare::Placement2D would have its documentation located in the docs/AllegroFlare/Placement2D.md file.
For now, the documentation page will be article-like, with each entry written as if it were a page in a manual.  On the other hand, the listing of the class with the exact fields and their properties are likely to be generated externally by a script at some point in the future. Either this, or, notated in a correlated yaml file (for example, docs/AllegroFlare/Placement.yml to match the example above).


Fix mm

fyi @camjc  :-)  I didn't add "PUI" to cases, b/c those are ppl under investigation, and when added those numbers are way different than the numbers returned by Google.  Cheers! jz


Fix typo in loca.js: hmtx should be head

indexToLocFormat is a property of the head table.

Would you be able to add a test to catch this? Not that I expect a regression here, but it'll be good to make sure that there's some code that makes sure this code path gets hit.

Sure. I added a test. It should fail when testing a font that uses 2-byte offsets in loca.


lib_stusb_impl: fix warning

Description
Add forgotten argument to fix warning
Changes include

[X] Bugfix (non-breaking change that solves an issue)
[ ] New feature (non-breaking change that adds functionality)
[ ] Breaking change (change that is not backwards-compatible and/or changes current functionality)
[ ] Tests
[ ] Documentation
[ ] Other (for changes that might not fit in any category)

Codecov Report
Patch and project coverage have no change.

Comparison is base (58d17f7) 85.97% compared to head (6da6b86) 85.97%.

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #291   +/-   ##
=======================================
  Coverage   85.97%   85.97%
=======================================
  Files           8        8
  Lines         385      385
=======================================
  Hits          331      331
  Misses         54       54

Flag
Coverage Δ

unittests
85.97% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


[5.5.x] extend upgrade matrix

Attention: This work is dependent on #1179.  The 5.5.37 -> 5.5.x-latest upgrade scenario is expected to fail without that work.  Please go review that first, if it isn't yet merged.
This PR adds several new upgrade scenarios to our 5.5.x branch, increasing our coverage for key gravity versions deployed in the field.  This gets us most of the value of https://github.com/gravitational/robotest/issues/155 without requiring any substantial development.
Testing done:
I successfully ran a version of this patch rebased on top of #1179 here:
https://jenkins.gravitational.io/view/Robotest/job/gravity-try-build/21/
Note: This work increases PR build time to almost 2 hours!    I'd like to keep PR builds under an hour, if possible.  We may look at bumping concurrency further:
https://github.com/gravitational/gravity/blob/20c2bc373ae33f0a401d5eed78ba9d9f8e1256be/Jenkinsfile#L33-L35
I haven't found the priority to look into that yet though.  I suspect 4 simultaneous tests may be tuned to the capacity of our GCE account.  Do you know where 4 comes from @a-palchikov (or anyone else)?

Force pushed to rebase these changes on top of #1179 in 5.5.x.  We should be good to go with this PR in the morning (if @a-palchikov doesn't request changes).


Align visitation order in Traverse with Visit and VisitMut

Traverse is codegen-ed from the AST node type definitions. The codegen generates a walker which visits children of a node in the order which they're defined in the AST types. e.g. for:
https://github.com/oxc-project/oxc/blob/8a1db6738c761b87a2581275e728445c1bb63e5a/crates/oxc_ast/src/ast/js.rs#L52-L60
Visitors are called in order matching the above:

enter_program
enter_directive + exit_directive (for each directive)
enter_hashbang + exit_hashbang
enter_statements + exit_statements
exit_program

On the other hand, Visit and VisitMut were written by hand. It's likely that for some types the visitation order is different from the types' field order. So it will be different from Traverse's visitation order.
This mismatch is going to cause problems at some point as contributors who are used to Visit/VisitMut will assume that Traverse behaves the same, and be confused when it doesn't, or unwittingly introduce bugs due to incorrect assumptions.
I think best way to tackle this is:

Write a codegen for Visit and VisitMut which does visitation in AST node field order (like Traverse does).
Diff current Visit vs codegen-ed Visit.
Where they don't match, change the field order in AST types, and run codegen again.
Keep doing that until the codegen-ed Visit and current hand-written Visit match exactly.
Throw away the old hand-written Visit and VisitMut and use the codegen from here on.

Once we switch to codegen, any changes to AST types will automatically update Visit + VisitMut to match.
In addition: We know there are also some discrepancies with Visit/VisitMut not visiting some child nodes. Likely in some cases this is a mistake (inevitable when writing this much code by hand), but in other cases it's intentional (like not visiting some TS nodes where it's pointless to do so).
The process above will reveal all such discrepancies, and then we can decide which are mistakes and which are intentional, and we can then adapt Visit, VisitMut and Traverse to make them all consistent and all reflecting what we decide is the "correct" visitation policy.

@rzvxa FYI

@overlookmotel I think this can be closed after merging #4001 and #4007

Can anybody tell me what is the difference between these two traits?
I noticed that the Visit trait is utilized in crates such as semantic, while the Traverse trait is employed in transformer and minifier crates. Could anyone clarify the rationale behind having these two different traits?
Additionally, when I am implementing my own traversal, how should I decide which trait to use?

Visit is for if you want an immutable visitor (i.e. you do not need to alter the AST), VisitMut and Traverse are mutable visitors (for when you want to mutate the AST). The difference between VisitMut and Traverse is more subtle. Read the doc comments in oxc_traverse crate for more details.
Just for future reference, for questions please open a Discussion here on Github or reach out on our Discord, rather than commenting on old issues.


Links broken on readme?

Minor issue but looks like half the links in your readme are broken. (#1-#14)

Hi - thanks for pointing this out, fixed it! (c3af947e50bf509607c029302b3a636ccdc5acb1)


Nameplates don't work (e.g. healthbars don't update)

New "stripped down" (post Legion release) implementation of nameplates don't work

Fixed in latest update

Not sure why I closed this. Have completely redone Nameplates which now work awesomely! (at least I think so) based on some excellent code from @Sticklord for AbuNameplates.


Implement inline editing in the mappings and references grid

[ ] References grid.
[ ] Mappings grid.

Can't be implemented because of lack of functionality in the Vaadin framework: https://github.com/vaadin/vaadin-grid-flow/issues/135


[VL] Daily Update Velox Version (2024_06_20)

Upstream Velox's New Commits:
97cdc63ca by xiaoxmeng, Improve stripe metadata io and increase the ssd checksum verification coverage (10220)
1a50a8afe by wypb, Add support OrcReader based on DwrfReader (10194)
11bdeb831 by Kevin Wilfong, Fix Velox counts incomplete UTF-8 chars differently than Presto Java (10204)

===== Performance report for TPCH SF2000 with Velox backend, for reference only ====

query
log/native_6158_time.csv
log/native_master_06_19_2024_27c32f1b15_time.csv
difference
percentage

q1
35.03
34.61
-0.410
98.83%

q2
23.90
25.46
1.561
106.53%

q3
41.98
38.59
-3.391
91.92%

q4
32.86
33.98
1.117
103.40%

q5
68.40
70.97
2.568
103.75%

q6
8.05
6.54
-1.512
81.23%

q7
82.69
85.08
2.397
102.90%

q8
84.00
87.11
3.115
103.71%

q9
122.85
123.67
0.822
100.67%

q10
46.99
44.85
-2.144
95.44%

q11
20.42
20.56
0.138
100.68%

q12
29.99
27.28
-2.702
90.99%

q13
38.24
39.58
1.336
103.49%

q14
20.78
18.81
-1.963
90.55%

q15
30.71
33.35
2.635
108.58%

q16
14.23
14.28
0.051
100.36%

q17
104.39
105.60
1.210
101.16%

q18
148.91
144.60
-4.311
97.10%

q19
14.75
13.77
-0.979
93.36%

q20
28.88
29.04
0.162
100.56%

q21
262.43
265.23
2.795
101.07%

q22
12.22
12.88
0.656
105.37%

total
1272.71
1275.86
3.151
100.25%


Grammar correction

that can be used the  render the latest results of all checks. Simply use that controller in your routes on any URL you desire.
that can be used to render the latest results of all checks. Simply use that controller in your routes on any URL you desire.

Thank you!


Pagefind doesn't work without --allow-run but the error message is not helpful

How to reproduce:

Install Simple Blog theme using the deno run -A https://lume.land/init.ts.
In lume task change permissions to --allow-net --allow-read --allow-write=./_site --allow-sys=homedir --allow-env --allow-run=git.
Attempt to run. The error like below will be there.
Remove the =git part. No error will be there.

The error is:
TypeError: Cannot read properties of null (reading 'on')
    {{# I omitted a few lines here. #}}
    at https://deno.land/x/lume@v2.2.4/plugins/pagefind.ts:139:40
    at Processors.run (https://deno.land/x/lume@v2.2.4/core/processors.ts:32:13)
    at eventLoopTick (ext:core/01_core.js:168:7)
    at async Site.#buildPages (https://deno.land/x/lume@v2.2.4/core/site.ts:689:5)
    at async Site.build (https://deno.land/x/lume@v2.2.4/core/site.ts:532:9)

This is because pagefind resolves the binary dynamically with this function.
And the path of this binary depends on the platform and version. This one works fine to me:
<EMAIL_ADDRESS>
But maybe in your case is a different path. I don't know if there's a good way to improve this.

Personally I’d like a note on plugin’s page.
Possibly in similar style to how MDN handles tricky pitfalls – arbitrary examples:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules#troubleshooting
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/wbr#notes
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/video#usage_notes

(Consulting the plugin’s page is the first thing I tried because, as I hoped, it could be a known problem related to order of operations or something similar.)

Good idea. Maybe each plugin should have a Permissions section to indicate which permissions are required to run it.

I've added a Permissions section https://lume.land/plugins/pagefind/#permissions


Resolved security vulnerability

https://github.com/rhoar-qe/boosters-e2e-tests/network/alert/package-lock.json/adm-zip/open

@Ladicek, thanks

I wonder what's rhoar-bot doing...

Ah, the Jenkins agent images were somehow lost. Rebuilding them now.

Yay :-)

@Ladicek I also thought about what rhoar-bot was doing. Thank you for you look at :-)


Troubleshooting latency issues

Disclaimer: This is an issue that I can't for sure determine is caused by the nginx-proxy but it's my "best guess" for now.
I have this setup (thanks @wader for helping me on more than one occasion before) using this proxy configuration:
version: "2"
services:
  nginx:
    image: nginx:1.11.5-alpine
    container_name: nginx
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - "/etc/nginx/conf.d"
      - "/etc/nginx/vhost.d"
      - "/usr/share/nginx/html"
      - "./certs:/etc/nginx/certs:ro"
    networks:
      - proxy-tier

  nginx-gen:
    image: jwilder/docker-gen
    container_name: nginx-gen
    volumes:
      - "/var/run/docker.sock:/tmp/docker.sock:ro"
      - "./nginx-compose-v2.tmpl:/etc/docker-gen/templates/nginx.tmpl:ro"
    volumes_from:
      - nginx
    entrypoint: /usr/local/bin/docker-gen -notify-sighup nginx -watch -only-exposed -wait 5s:30s /etc/docker-gen/templates/nginx.tmpl /etc/nginx/conf.d/default.conf

  letsencrypt-nginx-proxy-companion:
    image: jrcs/letsencrypt-nginx-proxy-companion
    container_name: letsencrypt-nginx-proxy-companion
    volumes_from:
      - nginx
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
      - "./certs:/etc/nginx/certs:rw"
    environment:
      - NGINX_DOCKER_GEN_CONTAINER=nginx-gen
#      - DEBUG=true

networks:
  proxy-tier:
    external:
      name: nginx-proxy

Connected to the network, I have a couple of API:s which consists of a mariaDB image and a modified nginx-php-fpm7 image (similar to https://github.com/ngineered/nginx-php-fpm/blob/php7/Dockerfile see the actual Dockerfile further down).
 Letsencrypt-certificates are generated as they should, the proxy redirects requests to the API:s, databses runs with no issues - however: latency is about 2-3 times higher for all types of requests in comparison with running the api without docker on a "normal" Debian droplet.
Is these latency losses to expect from Docker? Can this have to do with docker bridge networks which I have heard people having performance issues with?
I realize it it probably hard to determine straight away what may be causing the problems. If something in particular looks fishy, I can provide more info.
In any case, how would I go about to diagnose what may be causing the latency issues? Any go-to techniques I should use to check what's going on? I can't find anything out of the ordinary when looking through logs.
Any help would be much appreciated..!

Hi, that is weird. How and what tools do you use to measure and what latencies do you see in each case?

@wader No super sophisticated tools I use curl from the terminal and format the output according to: https://blog.josephscott.org/2011/10/14/timing-details-with-curl/
When sending a GET request (via curl) to the API on a server with the Docker configuration (as I described in the first post), I get these results on average:
curl -w<EMAIL_ADDRESS>-o /dev/null -s "https://api.docker-config.mydomain.com.com/users"
   time_namelookup:  0.061
      time_connect:  0.100
   time_appconnect:  0.249
  time_pretransfer:  0.250
     time_redirect:  0.000
time_starttransfer:  0.518
                   ----------
        time_total:  0.518

   time_namelookup:  0.125
      time_connect:  0.166
   time_appconnect:  0.306
  time_pretransfer:  0.306
     time_redirect:  0.000
time_starttransfer:  0.601
                   ----------
        time_total:  0.602

   time_namelookup:  0.125
      time_connect:  0.167
   time_appconnect:  0.309
  time_pretransfer:  0.309
     time_redirect:  0.000
time_starttransfer:  0.594
                   ----------
        time_total:  0.594

While on Debian (also DigitalOcean) - without Docker I get far better response times for the same request:
curl -w<EMAIL_ADDRESS>-o /dev/null -s "https://api.not-a-docker-config.mydomain.com.com/users"

   time_namelookup:  0.029
      time_connect:  0.076
   time_appconnect:  0.176
  time_pretransfer:  0.176
     time_redirect:  0.000
time_starttransfer:  0.249
                   ----------
        time_total:  0.249

   time_namelookup:  0.061
      time_connect:  0.102
   time_appconnect:  0.200
  time_pretransfer:  0.200
     time_redirect:  0.000
time_starttransfer:  0.280
                   ----------
        time_total:  0.280

   time_namelookup:  0.028
      time_connect:  0.069
   time_appconnect:  0.166
  time_pretransfer:  0.166
     time_redirect:  0.000
time_starttransfer:  0.240
                   ----------
        time_total:  0.240

The API's are also connected to a web interface and from there you can clearly notice that the API on Docker is slower by ~200-300 ms when playing around on the web application..!
Similar results when using Postman (which measures times for each requests) to send requests - about 200-300 ms slower.
Are there any better tools that you can recommend? Not sure if the curl-method gives any insight?

Thanks, 200-300ms difference sounds a lot yes. From what host do you curl? do you run the test locally on the same host or from a remote host? are they in the same DigitalOcean region? maybe measure RTT with ping, traceroute etc? do you have some HTTP endpoint that don't talk to the db to test with?

From what host do you curl?
do you run the test locally on the same host or from a remote host?

I curl from my location machine to two respective DO-droplets (one using / hosting the Docker system, the other one plain Debain)

Are they in the same DigitalOcean region?

One is in Amsterdam (Debian) and the other one is in Frankfurt (Docker) - although i doubt this causes the problems - do you think this could cause such a big latency difference? my local machine is  located physically closer to Franfurt than Amsterdam (not that it necessarily should make my connection to Frankfurt "faster")

maybe measure RTT with ping, traceroute etc?

So, I pinged the two servers and for the one hosting Docker, i got the average RTT: 36.889ms
For the Debain Droplet - I'm getting better RTTs: about  37.031ms. Virtually the same. 0% package loss for both the Droplets.
Will look into traceroot - I have not used this tool before. Thanks for the tip!

do you have some HTTP endpoint that don't talk to the db to test with?
I created an endpoint with no DB-communication and found that the Docker droplet still had higer latency:

Docker droplet (notice how the first request is far slower than the other ones by the way.. This is something I have been noticing as way.
Any ideas?

Ok so it does not look like a Internet latency problem. Maybe publish the http port of the container on some other port and benchmark against that? then we can measure nginx-proxy forwarding latency.
I guess one test would be to run non-docker on both droplets to just verify that they perform more or less the same... maybe messy to do?

I see, so if i understand you correctly - I should try changing the nginx containers ports to something else than 80 and 443?
  nginx:
    image: nginx:1.11.5-alpine
    container_name: nginx
    ports:
#      - "80:80"
#      - "443:443"
       - "81:80"
       - "444:443"
    ...

Would I then benchmark against mydomain.com:444 for example? Is this possible?
Sorry, I'm not a very experienced with networking - could you specify a little closer? :)

I mean that you add a "ports" config to the web container so that you can talk directly with it without going thru nginx-proxy. So for example if the web container listens on port 80 you would add a "ports: - 8080:80" for it and then benchmark using http://api.docker-config.mydomain.com.com8080

I am consistently seeing this issue myself. Some log output (URL's changed):
nginx-proxy
$ time curl --silent https://test.site.com

real    0m1.065s
user    0m0.104s
sys     0m0.052s
$ time curl --silent https://test.site.com

real    0m0.250s
user    0m0.124s
sys     0m0.016s

$ time curl --silent https://test.site.com

real    1m0.304s
user    0m0.108s
sys     0m0.028s

Note that the third request took a bit over a minute.
Using published port 10080:80
$ time curl --silent http://<IP_ADDRESS>:10080

real    0m0.048s
user    0m0.004s
sys     0m0.004s
$ time curl --silent http://<IP_ADDRESS>:10080

real    0m0.046s
user    0m0.004s
sys     0m0.004s
$ time curl --silent http://<IP_ADDRESS>:10080

real    0m0.047s
user    0m0.004s
sys     0m0.004s

Docker Info
Containers: 25
 Running: 13
 Paused: 0
 Stopped: 12
Images: 62
Server Version: 17.03.1-ce
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 214
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host ipvlan macvlan null overlay
Swarm: active
 NodeID: qblk990jgrucc18izqyky51yd
 Is Manager: true
 ClusterID: ywjpojya9tf6cb343epoikac5
 Managers: 1
 Nodes: 2
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Number of Old Snapshots to Retain: 0
  Heartbeat Tick: 1
  Election Tick: 3
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
 Node Address: <IP_ADDRESS>
 Manager Addresses:
  <IP_ADDRESS>:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 4ab9917febca54791c5f071a9d1f404867857fcc
runc version: 54296cf40ad8143b62dbcaa1d90e520a2136ddfe
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.8.0-56-generic
Operating System: Ubuntu 16.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 39.3 GiB
Name: theserver
ID: F67Q:V53W:ENI5:5LWY:6K2A:VVNF:UDX2:GLR2:SFTJ:F7XI:HX6S:YPBO
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Experimental: true
Insecure Registries:
 <IP_ADDRESS>/8
Live Restore Enabled: false

Try curl -v --trace-time ... to see where the delay is. For example the delay could be due to DNS lookup delay on the client.


Dive number in breadcrumb does not update when changed

When in Gallery or Replay mode, when selecting a different Dive number in the breadcrumb UI, the breadcrumb doesn't update, but the rest does.

Dupe of #26.


Integration of itk.js / itk-vtk-viewer

Create standard functions for displaying 2D and 3D datasets.
https://github.com/Kitware/itk-vtk-viewer

Is this still relevant?

XTK -> itk-vtk-viewer


Add user profile icon menu 🧑

[x] Logout

On Android, need to clear preference but ideally clear Play Services auth somehow
Stay on current data (offline-first) or clear everything?
Go back to onboarding?
Done by opatry/tasks-app#15

[ ] Link to help/legal/about

Help covered by another task.


Throw error if S3 credentials missing

S3 calls will fail if the access key and/or secret is missing. poormanscdn should fail to launch if all hosts don't have both an access key and secret (default values must be set or every host must have their own).

Fixed by https://github.com/alexandres/poormanscdn/commit/3abcb9a8ff150a8c15a1f1fe8b88b190353c8001


Issue when implementing odata2openapi

I try to use this module to transform odata metadata.xml file into json. As per documentation, I have implemented the following code:
const o2oapi = require('odata2openapi');

function_B (content) {
  o2oapi.parse(content)
	.then(entitySets => convert(entitySets))
	.then(swagger => console.log(JSON.stringify(swagger, null, 2)))
	.catch(error => console.error(error));
 }

The content variable is a metadata xml stream that I can display on console. I can also see the following result when logging the parse method of function B:
Promise {
 { entitySets: [ [Object], [Object] ],
   version: '1.0',
   complexTypes: [],
   singletons: [],
   actions: [],
   functions: [],
   defaultNamespace: 'ZEXAMPLE_SRV',
   entityTypes: [ [Object], [Object] ] } }

Unfortunately, I am not able to get the final result 'from swagger' to pass to another function C.
function_A (content, x, y, z){
  function_C (function_B (content), x, y ,z);
}

I have tried to adapt my code without any success. Could you please advice?
Attached my metadata file.
metadata.zip

Issue has been solved as described there: https://stackoverflow.com/questions/47576230/promise-issue-with-odata-file-parsing. I was quite surprised having to send EntitySets.entitySets to the convert method.


[bug] macro sometimes doesn't update on hearthstone used

Not reproducible

Reopening this - I've duplicated it a few times but need to gather data when it happens


[9.4-stable] Add Support for Persistent OVMF Settings in Pillar

Backport of https://github.com/lf-edge/eve/pull/4261.
A new version of #4269 , as the previous PR, targeted the 9.4-stable-EOS branch and prevented our workflows from being triggered (as the branch name had "-EOS" postfix).

I don't see this workflow running
https://github.com/lf-edge/eve/blob/9.4-stable/.github/workflows/danger.yml
Strange.

Maybe it's the problem. Found in the "PR build" workflow summary.
[Deprecation notice: v1, v2, and v3 of the artifact actions](https://github.com/lf-edge/eve/actions/runs/10990471810/workflow)
The following artifacts were uploaded using a version of actions/upload-artifact that is scheduled for deprecation: "eve-kvm-amd64", "eve-kvm-arm64", "eve-mini-riscv64", "eve-xen-amd64", "eve-xen-arm64".
Please update your workflow to use v4 of the artifact actions.
Learn more: https://github.blog/changelog/2024-04-16-deprecation-notice-v3-of-the-artifact-actions/

@uncleDecart, @milan-zededa, could you recommend a quick fix here? I need the danger workflow to run to publish the artefact to dockerhub so that tests can use them...

@OhmSpectator danger should've been triggered after successful PR build

Maybe it's the problem. Found in the "PR build" workflow summary.
[Deprecation notice: v1, v2, and v3 of the artifact actions](https://github.com/lf-edge/eve/actions/runs/10990471810/workflow)
The following artifacts were uploaded using a version of actions/upload-artifact that is scheduled for deprecation: "eve-kvm-amd64", "eve-kvm-arm64", "eve-mini-riscv64", "eve-xen-amd64", "eve-xen-arm64".
Please update your workflow to use v4 of the artifact actions.
Learn more: https://github.blog/changelog/2024-04-16-deprecation-notice-v3-of-the-artifact-actions/

They were still uploaded, you can see them in artifacts on summary page in PR/Build action here

And I don't see any workflows triggered here

@uncleDecart yep. I need to understand how to push artifacts into docker hub, so they are available by docker pull in another tool (ztest).

@uncleDecart yep. I need to understand how to push artifacts into docker hub, so they are available by docker pull in another tool (ztest).

Quickest fix I think would be to locally run make eve which will push containers to your local setup and then running ztest on that same machine will pull local container. In order to push artefacts into docker hub we will need credentials, so it's not a way to go. I'll check now the wfs...

@uncleDecart yep. I need to understand how to push artifacts into docker hub, so they are available by docker pull in another tool (ztest).

Quickest fix I think would be to locally run make eve which will push containers to your local setup and then running ztest on that same machine will pull local container. In order to push artefacts into docker hub we will need credentials, so it's not a way to go. I'll check now the wfs...

My understanding is that the danger workflow push into dockerhub. But it's not called for some reason

It's just a matter of fact. The workflows are broken in 9.4. We cannot do our regular releases here.

@yash-zededa, could you help with this? We need assistance with GH Actions for the upcoming release after merging this PR. At the moment it looks like it will not work.

@eriknordmark @OhmSpectator Are we expecting more releases for the 9.4 branch ? We can we can modify the Jenkins job to get the artefacts directly from github. I don't think it would be a direct approach but maybe we can figure out a way for this.

@eriknordmark @OhmSpectator Are we expecting more releases for the 9.4 branch ? We can we can modify the Jenkins job to get the artefacts directly from github. I don't think it would be a direct approach but maybe we can figure out a way for this.

We need to create only one release. Exactly from the state now. Then we move it to EOS again. That's my understanding.


Gracefully handle invalid status codes

Currently if an invalid status code is sent in the response, node throws an exception on writeHead that afaik can't be handled in express. Instead it just leads to a hanging request. I realize that it's best practice for people to only send valid status codes, but I have seen:
if (err) res.sendStatus(err.code || 500)
far too many times.
This change is similar to https://github.com/expressjs/express/pull/2797, which I think is ultimately a better solution. But this fix should be non breaking.

Since previous version of Node.js did allow this and it worked, doing this is a breaking change to Express that cannot land until 5.x

that afaik can't be handled in express. Instead it just leads to a hanging request.

I have never seen this. Can you please provide a test case that demonstrates this behavior? That would be the only reason to land something like this on 4.x, if you can show how Express is causing an uncatchable exception that will hang the response.

Can you please provide a test case that demonstrates this behavior?

Whoops, more testing showed you were right. It's just the uncaught exception in conjunction with bad handling of errors in the app I was looking at.
Would it be worth throwing a TypeError instead if you want this for v5? Or do you prefer merging #2797?

I mean, #2797 seemed fine enough to merge, and I think there was a bunch of conversation before that throwing an error would be less surprising than silently changing the error, especially to figure out where in the code you're giving the method the wrong input.

I definitely agree throwing an error is better, I guess the only issue I have with #2797 is that it's making different checks than what node is checking for -- but maybe that's appropriate if we don't know what changes they'll make in the future.

Ah, yea, just looked at it and I see now. This is actually the third open PR to add this check. Maybe the other one has the code number check?

There's https://github.com/expressjs/express/pull/3111, which is functionally the same as #2797. Both don't handle sendStatus or invalid numeric input.
Anyways, feel free to close this if you want. Otherwise I'd be happy to rewrite it to a) throw a type error, and b) not change the behavior around the currently deprecated ways to set status which are being removed in v5.

Gotcha. Yea, the check for the numbers I think is good, to match Node.js core. This means I believe your PR is better, and will review your PR with my thoughts on changes that need to be made :)

If you can retarget the PR to be against 5.0 branch as well, that would be awesome :)

Will do!

Closing in lieu of https://github.com/expressjs/express/pull/3143


Rewrite Fitter class

Fitter class currently depends on the C implementation of MPFIT and depends on cython to properly install. These classes / functions should be rewritten to reduce external dependencies.

It may be necessary to drop support for Python 2.6.

Support for py26 valid for LMFIT 0.9.1 only
Addressed by b37733f8fd65f36a874f3b49a67c6a17b066cdb2


[ENH] apply_join

An apply_join or join_apply (cannot find a better name) would be nice.
It would wrap the following pandas code, which I already implemented, but just haven't had the time to put into the library:
@pf.register_dataframe_method
def join_apply(df, func, new_name):
    """
    Join the result of applying a function across dataframe rows.

    :param df: A pandas DataFrame
    :param func: A function that is applied across all rows of the
        DataFrame.
    :param new_name: New column name.
    """
    df = (
        df.copy()
        .join(
            df.apply(func, axis=1)
            .rename(new_name)
        )
    )
    return df

Thoughts on:

a better name?
usefulness?

If you apply a function to all the rows, are they "reduced" somehow? Is this like adding another column? Or could there be multiple columns?

The use case here is that I want to take information from two or more columns to create a new column.
In this case, I would want to join back the result, i.e. the new pd.Series that results from the apply line.

Man I've been wanting this for the longest time.


WARNING: java.lang.IllegalArgument

Hi radionics,
see all the septs below we see a warning in the console, that it is about the control broadcaster.
I think this is something from the broadcasting line.
text from the console:
<<<....ControlP5 2.2.6 infos, comments, questions at http://www.sojamo.de/libraries/controlP5
controlEvent clear
controlEvent grounding
controlEvent connect
controlEvent select data
controlEvent analyze
controlEvent general vitality
controlEvent broadcast
Jul 29, 2018 12:37:59 PM controlP5.ControlBroadcaster invokeMethod
WARNING: java.lang.IllegalArgumentException: wrong number of arguments
Thanks for your attention. I’m looking forward to your reply.
Kind regards,
Stellalki

This is a ControlP5 issue and needs to be fixed in the ControlP5 project.

CP5 issue. I close it, because this cannot be fixed here.


Release export crashes with segfault

Godot version:
3.1-alpha 06fa780
OS/device including version:
Windows 10
Issue description:
When running a release export:

Mouse location is not being reported via get_viewport().get_mouse_position()
Build crashes with segfault (access violation) after changing scene.

I believe these two to be related. In debug builds and run from editor game runs fine.
Steps to reproduce:
Unable to replicate with minimal project (yet). Run 0.21.4 of ΔV on Windows against  06fa780 compiled with target=release tools=no to observe that:

Mouse does not move on screen (sprite position is read via get_viewport().get_mouse_position() in _process)
New Game causes to segfault.

Caused by 95131e6

Isolated down to changes in modules/gdscript/gdscript_function.cpp

Fixed by #22796.


MBCS_Tests_jaxp14_zh_CN_linux_0 fail on same linux machine

Describe the bug
MBCS_Tests_jaxp14_zh_CN_linux_0 fail on same linux machine.
The XSLTTest testcase check the output, which strict match the contents the expected data "expected_zh-cn.html"
The content of the actual output and the expected is the same, just only two lines sequence is diffrent.
I think it's not a jdk bug, but is only a envirent issue.
But I don't known how to make this testcast run pass. Anyone has any idea?
vimdiff:

beyond compare:

To Reproduce
tar xf MBCS_Tests_jaxp14_zh_CN_linux_0.tar.gz
cd MBCS_Tests_jaxp14_zh_CN_linux_0/
javac XSLTTest.java
java XSLTTest drinks_zh-cn.xml drinks_zh-cn.xsl > alios.html
vimdiff alios.html expected_zh-cn.html

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
MBCS_Tests_jaxp14_zh_CN_linux_0.tar.gz
java version:

XSLTTest.java
locale:

original test log:
===============================================
Running test MBCS_Tests_jaxp14_zh_CN_linux_0 ...
===============================================
MBCS_Tests_jaxp14_zh_CN_linux_0 Start Time: Thu May 19 14:35:07 2022 Epoch Time (ms):<PHONE_NUMBER>127
Nothing to be done for setup.
variation: NoOptions
JVM_OPTIONS:
{ itercnt=1; \
mkdir -p "/mnt_array/yansendao.ysd/aqa-tests/TKG/../TKG/output_16529421012521/MBCS_Tests_jaxp14_zh_CN_linux_0"; \
cd "/mnt_array/yansendao.ysd/aqa-tests/TKG/../TKG/output_16529421012521/MBCS_Tests_jaxp14_zh_CN_linux_0"; \
LANG=zh_CN.UTF-8 bash /mnt_array/yansendao.ysd/aqa-tests/TKG/../../jvmtest/functional/MBCS_Tests/jaxp14/test.sh; \
if [ $? -eq 0 ] ; then echo ""; echo "MBCS_Tests_jaxp14_zh_CN_linux_0""_PASSED"; echo ""; cd /mnt_array/yansendao.ysd/aqa-tests/TKG/..;  else echo ""; echo "MBCS_Tests_jaxp14_zh_CN_linux_0""_FAILED";
echo ""; fi; } 2>&1 | tee -a "/mnt_array/yansendao.ysd/aqa-tests/TKG/../TKG/output_16529421012521/TestTargetResult";

MBCS_Tests_jaxp14_zh_CN_linux_0_FAILED

Nothing to be done for teardown.
MBCS_Tests_jaxp14_zh_CN_linux_0 Finish Time: Thu May 19 14:35:07 2022 Epoch Time (ms):<PHONE_NUMBER>529

I found for the same input.txt, the result for sort input.txt on macos and on linux(alios) is diffrent. The sort result is similar to the testcase output.
macOS:

linux(alios):

I create a docker container which image is ubuntu:latese, the sort result is same to the alios:

set LANG=zh_CN.UTF-8 doesn't work

@KKES335 @takiguc - will you be able to help to answer @sendaoYan 's question?

Hello @sendaoYan .
I think yor docker image or your machine defined LC_ALL environment variable like LC_ALL=en_US.UTF-8.
$ export LANG=zh_CN.UTF-8
$ ~/jdk-17.0.3+7/bin/java -XshowSettings:properties -version 2>&1 | grep 'user\.[cl]'
    user.country = CN
    user.language = zh
$ export LC_ALL=en_US.UTF-8
$ ~/jdk-17.0.3+7/bin/java -XshowSettings:properties -version 2>&1 | grep 'user\.[cl]'
    user.country = US
    user.language = en

If LC_ALL is defined, java picks up locale setting from LC_ALL instead of LANG.
$ locale
LANG=zh_CN.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8
$

MBCS testcases checked locale setting via locale charmap.
Like ${LANG%.*}.$(locale charmap)
So above case, testcase generated zh_CN.UTF-8 locale, but actual locale was en_US.UTF-8.
I ran CI jobs and these worked fine as expected.
https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder_Simple/312/console
https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder_Simple/313/console
I put may fix into https://github.com/takiguc/aqa-tests/tree/3676
Repo: https://github.com/takiguc/aqa-tests
Branch: 3676
If possible, could you run my fix with your jobs setting ?

@takiguc

I have no idea, why my machine(alios linux) test still fail after apply your patch
LANG=zh_CN.UTF-8 bash /mnt_array/yansendao.ysd/output-aqa-tests/jdk17/20220519-1919/jvmtest-functional/functional/MBCS_Tests/jaxp14/test.sh; \
if [ $? -eq 0 ] ; then echo ""; echo "MBCS_Tests_jaxp14_zh_CN_linux_0""_PASSED"; echo ""; cd /mnt_array/yansendao.ysd/aqa-tests/TKG/..;  else echo ""; echo "MBCS_Tests_jaxp14_zh_CN_linux_0""_FAILED";
echo ""; fi; } 2>&1 | tee -a "/mnt_array/yansendao.ysd/aqa-tests/TKG/../TKG/output_16530588093973/TestTargetResult";
locale: Cannot set LC_ALL to default locale: No such file or directory
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LANG = "zh_CN.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

This is run result by command:
LANG=zh_CN.UTF-8 bash -x /mnt_array/yansendao.ysd/output-aqa-tests/jdk17/20220519-1919/jvmtest-functional/functional/MBCS_Tests/jaxp14/test.sh

On my other machine(linux ubuntu20.04, not docker contanier), the test is skip after apply your patch:

3676.patch.txt

Hello @sendaoYan .
Thank you for your testing.
I assume that locale charmap command returns ANSI_X3.4-1968 if the Linux machine does not have specified locale.
But your machine's locale charmap returned UTF-8.
Please give me more time to reconsider about another solution.

Thanks very much.

Hello @sendaoYan . Thank you for your testing. I assume that locale charmap command returns ANSI_X3.4-1968 if the Linux machine does not have specified locale. But your machine's locale charmap returned UTF-8. Please give me more time to reconsider about another solution.

Thanks very much.

Hello @sendaoYan .
Could you test following patch on your machine (alios linux), please ?
https://github.com/adoptium/aqa-tests/compare/master...takiguc:3676.diff

Hello @sendaoYan . Could you test following patch on your machine (alios linux), please ?
https://github.com/adoptium/aqa-tests/compare/master...takiguc:3676.diff

I have fixed this enviromental problem by execute below command:
sudo localedef -v -c -i en_US -f UTF-8 en_US.UTF-8
sudo localedef -v -c -i zh_CN -f UTF-8 zh_CN.UTF-8
sudo localedef -v -c -i zh_TW -f UTF-8 zh_TW.UTF-8
sudo localedef -v -c -i ja_JP -f UTF-8 ja_JP.UTF-8
sudo localedef -v -c -i ko_KR -f UTF-8 ko_KR.UTF-8

So I can't replay the failure now. May be we can close this issue now?

Thanks @sendaoYan  .
If possible, I'd like to use this issue for PR creation.
Is it OK ?


[SPARK-27434][CORE] Fix mem leak

What changes were proposed in this pull request?
close the unused file system when closing the EventLoggingListener to prevent from mem leak.
How was this patch tested?
No unit tests were implemented for this patch.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

IIUC, the stop method will only be called when the app is finished, so how could it cause memory leak?
Can you give more information about the concrete case you encountered?

Also, please fix the PR title to be more specific.

Does this component have exclusive ownership of this Hadoop FileSystem instance? Could we run into problems in case this ends up closing a shared instance?

I don't think you can close FileSystem objects. They're shared. Why is it a memory leak?

@srowen please see https://issues.apache.org/jira/browse/SPARK-27434 for detail.
we have noticed the mem leak and did a heap dump on the spark driver, and looks like it's the accumulating filesystem objects that's causing the issue.
and in the code, filesystem is never closed even tho they are not needed. all the filesystem objects got cached into the mem and close() method is to remove them from the cache so that GC can clean them, otherwise they are always referenced and will never get GCed.

@srowen filesystem is shared that's true, but it's shared within a spark context, so if the context.close() is called, I think we can safely remove it. also, the static method FileSystem.get() is like a getOrCreate, so even if it's removed, other part of the code can get it again, the object will be recreated and cached(if I missed sth, please point me to the code where it could potentially get NPE after close, I can fix that).

Hm your heap dump is convincing, although this FileSystem is just obtained from Hadoop and its cache. Generally that's not safe to close, but maybe here. I'm trying to figure out if closing it solves the problem though. You'd still have something holding a reference to this object, no? And that I don't quite see here, why that is.

@srowen
if there is indeed somewhere else that's holding that filesystem object, them this won't solve the problem you are right. but if not, removing from the cache will de-reference it from the cache, therefore could make that object orphan and then can be cleaned by GC.
I can't really guarantee that there aren't other places that could reference that object, but the fact that when spark context is closing makes me think there should really not be.

Test build #4771 has started for PR 24461 at commit d6ab612.

Let's see what tests say so far. BTW you'll need to improve the title of the PR and JIRA.

Before this goes too far.
You must not close FileSystem instances. The app itself can keep running after the SparkContext is stopped, if you want one reason.
This is not a fix for the memory leak. It's at best a workaround that will only work in very specific cases.
To fix the memory leak you need to understand where it's coming from. You just identified that it is happening, but not why or how. It may be it's not the fault of Spark at all and there's something wrong with the Hadoop code itself.

Test build #4771 has finished for PR 24461 at commit d6ab612.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

looked more into the hadoop side, FileSystem.get(URI uri, Configuration conf) has caching built in side, unless specifically disabled.
return conf.getBoolean(disableCacheName, false) ? createFileSystem(uri, conf) : CACHE.get(uri, conf);
due to this, fileSystem object will be cached and put into a map using generated Key:
       Key(URI uri, Configuration conf) throws IOException {
            this(uri, conf, 0L);
        }

        Key(URI uri, Configuration conf, long unique) throws IOException {
            this.scheme = uri.getScheme() == null ? "" : StringUtils.toLowerCase(uri.getScheme());
            this.authority = uri.getAuthority() == null ? "" : StringUtils.toLowerCase(uri.getAuthority());
            this.unique = unique;
            this.ugi = UserGroupInformation.getCurrentUser();
        }

therefore in theory if the baseLogDir is the same, and hadoop conf don't change, object will be reused between spark context, however for some unknown reason it did not and got created every time.
on the other hand, the close() method is safer than you thought. first, it's only going close one of those many cached fileSystems that are cached, not all, so it's likely you are only closing the one you created. also, closing fileSystem does not actually CLOSE that file system, according to the close method:
public void close() throws IOException {
this.processDeleteOnExit();
CACHE.remove(this.key, this);
}
it deletes the pending deletions and remove that object from the cache, that's it.
so if by any chance other threads are possessing this object, it will be fine and that thread can continue using it.
most important gain from closing this file system object is to get it de-referenced from cache, so GC can eventually reclaim it from the heap when no one else has reference to it no more.

and also, we've tested this with and without eventLog enabled. and the result is clear that with the eventLog enabled, we will run into this leak everytime after we open and close spark context several times in the same JVM and heap dumps are all similar. but without eventLog enabled, we never run into this again.

I understand how the fs cache works. You fix is still wrong.
I understand that you're seeing the memory leak when you enable the event log. But that doesn't explain the memory leak itself. The event log is just writing a file to HDFS, just like many other places in Spark.

@vanzin enable eventLog itself along does not cause problem. like long running streaming jobs, they are fine. problem only shows up when spark context gets open and closed repeatedly. which likely to create file system object every time instead of reusing the one that's cached previously.
the point where I don't understand is how this is happening, I checked the Key in the cache map, it should be the same compared to the previous one, and the equals method got overridden properly as well, hashcode method override is ok as well.
therefore I can't explain why cache is not reused for fs object, only thing I know is it's not reused.

Hm, I wonder if that's more at the root of the problem: you'd generally not close the SparkContext within one application, one JVM. I think this could be the issue? lots of stuff might not work well if you do.

It's fine (and supported) to run multiple contexts in the same JVM, as long as they're not run concurrently.

For example, https://issues.apache.org/jira/browse/HADOOP-12958 is an OOM in exactly the code path being talked about here. Maybe there are others.

yea, we run multiple contexts in sequence and that works well.
however looking at this patch: HADOOP-12958
-    private class StatisticsDataReference extends PhantomReference<Thread> {
+    private class StatisticsDataReference extends WeakReference<Thread> {

we do have that in place, since we are using hadoop-2.7.3. also to double make sure we checked runtime jar as well,  and we see that hadoop-common is using WeakReference now(from ugly binary Java class):
 Statistics^A^@^LInnerClasses^G^@7^A^@^NStatisticsData^A^@;Lorg/apache/hadoop/fs/FileSystem$Statistics$StatisticsData;^A^@^Fthis$0^A^@,Lorg/apache/hadoop/fs/FileSystem$Statistics;^A^@^F<init>^A^@|(Lorg/apache/hadoop/fs/FileSystem$Statistics;Lorg/ap    ache/hadoop/fs/FileSystem$Statistics$StatisticsData;Ljava/lang/Thread;)V^A^@^DCode^A^@^OLineNumberTable^A^@^RLocalVariableTable^A^@^Dthis^A^@^WStatisticsDataReference^A^@DLorg/apache/hadoop/fs/FileSystem$Statistics$StatisticsDataReference;^A^@^Fth    read^A^@^RLjava/lang/Thread;^A^@^GgetData^A^@=()Lorg/apache/hadoop/fs/FileSystem$Statistics$StatisticsData;^A^@^GcleanUp^A^@^C()V^A^@^MStackMapTable^G^@3^G^@8^G^@9^A^@ Signature^A^@1Ljava/lang/ref/WeakReference<Ljava/lang/Thread;>;^A^@
but what I see now is, how would WeakReference fix this problem if you still have strong reference from HashSet refers to this  StatisticsDataReference?
    public static final class Statistics {
        private final Set<FileSystem.Statistics.StatisticsDataReference> allData;
        ...
        public Statistics(FileSystem.Statistics other) {
            ...
            this.allData = new HashSet();
        }

        public FileSystem.Statistics.StatisticsData getThreadStatistics() {
            FileSystem.Statistics.StatisticsData data = (FileSystem.Statistics.StatisticsData)this.threadData.get();
            if (data == null) {
                data = new FileSystem.Statistics.StatisticsData();
                this.threadData.set(data);
                FileSystem.Statistics.StatisticsDataReference ref = new FileSystem.Statistics.StatisticsDataReference(data, Thread.currentThread());
                synchronized(this) {
                    this.allData.add(ref);
                }
            }

            return data;

}

only place this strong reference from HashSet could be removed is by calling cleanUp on StatisticsDataReference:
            private final FileSystem.Statistics.StatisticsData data;

            public StatisticsDataReference(FileSystem.Statistics.StatisticsData data, Thread thread) {
                super(thread, FileSystem.Statistics.STATS_DATA_REF_QUEUE);
                this.data = data;
            }

            public FileSystem.Statistics.StatisticsData getData() {
                return this.data;
            }

            public void cleanUp() {
                synchronized(Statistics.this) {
                    Statistics.this.rootData.add(this.data);
                    Statistics.this.allData.remove(this);
                }
            }
        }

but checking the code, seems it's never called. so it will be held in that HashSet.
in the meanwhile, new ref is been created every time this is called:
public FileSystem.Statistics.StatisticsData getThreadStatistics() {
            FileSystem.Statistics.StatisticsData data = (FileSystem.Statistics.StatisticsData)this.threadData.get();
            if (data == null) {
                data = new FileSystem.Statistics.StatisticsData();
                this.threadData.set(data);
                FileSystem.Statistics.StatisticsDataReference ref = new FileSystem.Statistics.StatisticsDataReference(data, Thread.currentThread());
                synchronized(this) {
                    this.allData.add(ref);
                }
            }

            return data;
        }

which is called in class SparkHadoopUtil by
 private[spark] def getFSBytesWrittenOnThreadCallback(): () => Long = {
    val threadStats = FileSystem.getAllStatistics.asScala.map(_.getThreadStatistics)
    val f = () => threadStats.map(_.getBytesWritten).sum
    val baselineBytesWritten = f()
    () => f() - baselineBytesWritten
  }

and
  private[spark] def getFSBytesReadOnThreadCallback(): () => Long = {
    val f = () => FileSystem.getAllStatistics.asScala.map(_.getThreadStatistics.getBytesRead).sum
    val baseline = (Thread.currentThread().getId, f())

can anyone verify if my finding makes sense?

I think you're going at this from the wrong side. You just posted a screenshot on the bug, which shows there's a memory leak. But there's nothing in the screenshot that allows you to actually identify the nature of the leak.
Have you actually looked at the heap dump to see what is stored in the HashMap that's holding on to all that memory?
Maybe that will confirm your theory, or point somewhere else. But you're the only one that has that data, and I've never seen this leak, so only you can figure that out at the moment.
(BTW I assume you're the person who filed the bug.)

@vanzin
the dumps shows a HashSet under FileSystem$Statistics that's holding up lots of mem.
and from the class definition, there is only one HashSet under that class.
also I think the HashMap there is just misleading, because in HashSet's implementation, it uses a HashMap for lookup:
public class HashSet<E>
    extends AbstractSet<E>
    implements Set<E>, Cloneable, java.io.Serializable
{
    static final long serialVersionUID = -5024744406713321676L;

    private transient HashMap<E,Object> map;
  /**
     * Constructs a new, empty set; the backing <tt>HashMap</tt> instance has
     * default initial capacity (16) and load factor (0.75).
     */
    public HashSet() {
        map = new HashMap<>();
    }

so that HashMap is just under the HashSet holding internal data structure.
I can look at the dump again, but I don't know if I can see more useful stuff. I will post back if I find anything new. but I agree, this is less likely to be a Spark issue at this moment.


Erro ao abrir link

I'm getting an error every time I try to access a link from within the markdown or html file view. The following error " Sorry, browsing not allowed.
"

The plugin isn't meant to be a browser and to be on the safe side it's intentionally not allowed to browse to another location. You can press Enter in QuickView (or click the "open with" button at the top) and then continue browsing with a browser or whatever your markdown editor is.


No output when using Quantum as a bundle plugin

https://github.com/eddow/eddow-bug-expo/tree/bpq
When Quantum is not specified at FuseBox.init but rather in a bundle fuse.bundle("myBundle").plugin(...), no output file is produced (in the dist folder) without warning nor error.
Note: If one bundle is using Quantum and a second one is made after even without Quantum, the second one has no output neither.

Quantum should be initialized in the primary config (FuseBox.init) that's the only place, and it works across the instance and applied to all bundles

I'm having the same problem. My QuantumPlugin() is defined in the init() configuration.
{ homeDir: 'src',
  output: 'dist/assets/js/$name.js',
  tsConfig: 'tsconfig.json',
  plugins: [ QuantumPluginClass { ... } ] }

The same configuration without the QuantumPlugin works perfectly.

@slezica you should inject QuantumPlugin instead.

Not sure what you mean. What I posted earlier was the live configuration object, printed with console.log(). I updated my previous comment to hold the config as written in code.

@slezica I am not sure what the problem is. Do you think you can reproduce it in a repository?


Published on NPM(Node Package Manager) ?

Dear @yxl
This project is awesome.
Could I suggest that you publish this onto npm as a node module so that we can require in as an external package?
Currently, there is no such lib found on the site. https://www.npmjs.com/search?q=amr+js

Maybe it should be wrapped in CommonJS.


ORC-984: Save the software version that wrote each ORC file.

What changes were proposed in this pull request?
I add a string to the file footer that records the version that wrote the file. We already had recorded the implementation that wrote the file as Footer.writer. I added a method that combines these two fields in the reader to produce a user facing string that describes the software version.
I also add a field to the meta data tool to show the version that wrote the file.
Because of that change and the fact that the files change size based on whether the ORC version is a snapshot or not, I had to extend the tests for TestFileDump to allow some slop for the size and to ignore the file version.
How was this patch tested?
It passes the unit tests after I updated the tools tests.

The software version in the API and tool shows up as "ORC Java 1.8.0-SNAPSHOT". When run from IntelliJ the unit tests can't find the software version, so it comes in "ORC Java unknown".

I haven't updated the C++ reader, writer, and tool yet.

BTW, according to GitHub Action jobs, all Java11+ seems to complain for some reasons.

BTW, according to GitHub Action jobs, all Java11+ seems to complain for some reasons.

This should be a bug in findbugs. Java 11 compiles try-with-resources to generate bytecode differently than java8. Findbugs is considered RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE from bytecode analysis.
https://github.com/spotbugs/spotbugs/issues/259

Ok, the changes for C++ were relatively straightforward. I did update the C++ with the new writer versions, such as the important ORC-14.
I updated the orc_split_elim_new.orc so that it was written by the 1.8.0-SNAPSHOT. I also added orc_split_elim_cpp.orc that is the same file written by c++. The Java and C++ tools show the files as having being written by the corresponding versions.

BTW, to generate the new c++ ORC file, I wrote a little utility that takes an ORC file and rewrites it using c++. It is in https://github.com/omalley/orc/tree/cpp-convert .

So, everything is ready, right, @omalley ?


Error: Cannot find module './Drivers'

This is a strange one. So if I run npm install adonis-mail-provider@latest and then cd node_modules/adonis-mail-provider/src/Mail I see the directory drivers instead of Drivers. All the other directories look fine except that one.
I know the repo shows everything correct. I tried clear the npm cache and clearing the node_modules directory. Any tips on what else I could try to fix this?

Having the same issue as well

Dear everyone,
Which operating system are you using?

Linux Mint 18 "Sarah" x86_64

Doesn't seems to be an OS issue, seems like npm has the drivers directory with lowercase.
Can u share with the adonis-mail version

Release the fix as 2.0.2 please update.


Something like iOS tableView reloadRowsAtIndexPaths

When new data enters the state after initial render the table doesn't pick it up untill it needs to rerender the rows affected.
Would be nice to be able to somehow specify that rows should be rerendered.
Would also help with partial data in issue #28 .

While I would still like 'reloadRowAtIndex' it is possible to do this by having a container which updates itself sitting under the Table, see https://github.com/ofersadgat/fixed-data-table-simple as an example.

I think reloadRowAtIndex fn would make sense given our existing API but what i would rather see is a more react "like" declarative API, although I don't have a good idea of what that would look like. If that looks like it will be a big change we may do this in the mean time. Any thoughts on this approach?

I think that the React-style approach is something like what I did in my example (see the repo linked above for more detail):
var renderCell = function(cellData, cellDataKey, rowData, rowIndex, columnData, width){
  var renderLoaded = function(rowData){
    if (cellDataKey == 'thumbnail'){
      return ;
    }
    return
{rowData[cellDataKey]}
;
  };

  return (
    <LoadingCellContainer
        data={rowData}
        dataKey={cellDataKey}
        unloaded={}
        renderLoaded={renderLoaded} />
  );
};

where you can declarativly state what to render when the data is unloaded vs loaded. The only problem with this approach (and the reason I'd prefer to have something like reloadRowAtIndex) is that it requires that you store the LoadingObjectContainer in your stores so that you can populate it when the data arrives. An alternative to reloadRowAtIndex might be: getRowDataAtIndex which will allow you to use the above approach because it will let you store the LoadingObjectContainer in the table and the actual data in your own store.

Thank you for reporting this issue and appreciate your patience. We've  notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.


Reduce allocations in ActiveRecord callbacks

In our app, IndexSet#references is called 54 times each time a model is saved.  This calls ActiveSupport's underscore method, which is relatively expensive and is responsible for a large chunk of object allocations.
This PR moves all instances of klass.name.underscore.to_sym to a common IndexSet.reference_name method, then caches the result.   WDYT?

An excellent improvement - thank you :)


Cannot start agent and collector on the same machine (OpenTelemetry distribution)

When trying to start both the collector and the agent on the same machine, the second component to start hangs without failing:
$ SPAN_STORAGE_TYPE=memory go run ./cmd/collector

In another terminal:
$ go run ./cmd/agent --reporter.grpc.host-port=localhost:14250
2020-10-15T14:11:40.555+0200	INFO	service/service.go:396	Starting Jaeger OpenTelemetry Agent...	{"Version": "", "GitHash": "", "NumCPU": 12}
2020-10-15T14:11:40.556+0200	INFO	service/service.go:240	Setting up own telemetry...
2020-10-15T14:11:40.569+0200	INFO	service/telemetry.go:110	Serving Prometheus metrics	{"address": "localhost:8888", "legacy_metrics": false, "new_metrics": true, "level": 0, "service.instance.id": "63dde494-2c17-4752-ae8c-ecd42caf7eb1"}
2020-10-15T14:11:40.601+0200	INFO	service/service.go:277	Loading configuration...
2020-10-15T14:11:40.612+0200	INFO	service/service.go:288	Applying configuration...
2020-10-15T14:11:40.612+0200	INFO	service/service.go:309	Starting extensions...
2020-10-15T14:11:40.612+0200	INFO	builder/extensions_builder.go:53	Extension is starting...	{"component_kind": "extension", "component_type": "health_check", "component_name": "health_check"}
2020-10-15T14:11:40.612+0200	INFO	healthcheckextension/healthcheckextension.go:40	Starting health_check extension	{"component_kind": "extension", "component_type": "health_check", "component_name": "health_check", "config": {"TypeVal":"health_check","NameVal":"health_check","Port":13133}}
^Csignal: interrupt

Once #2563 is addressed, this won't be such a big problem, as the port can then be overridden.

the second component to start hangs without failing

odd, since when port is in use you normally get an error and the binary should exit with it

That'd be my expectation too.


[Network] Correct parameter name and configuration for Radius server for VPNGat

Generated from RestAPI PR: https://github.com/Azure/azure-rest-api-specs/pull/1484

Codecov Report

Merging #1332 into master will decrease coverage by 0.07%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1332      +/-   ##
==========================================
- Coverage   56.05%   55.97%   -0.08%
==========================================
  Files        2692     2695       +3
  Lines       71250    71427     +177
==========================================
+ Hits        39936    39984      +48
- Misses      31314    31443     +129

Impacted Files
Coverage Δ

...7_06_01/models/effective_network_security_group.py
50% <0%> (-7.15%)
:arrow_down:

...17_06_01/models/effective_network_security_rule.py
21.05% <0%> (-5.62%)
:arrow_down:

...re/mgmt/network/v2017_06_01/models/route_filter.py
50% <0%> (ø)
:arrow_up:

...express_route_circuit_authorizations_operations.py
98% <0%> (ø)
:arrow_up:

...re/mgmt/network/v2017_06_01/operations/__init__.py
100% <0%> (ø)
:arrow_up:

.../operations/virtual_network_peerings_operations.py
16% <0%> (ø)
:arrow_up:

...t/network/v2017_06_01/models/patch_route_filter.py
38.46% <0%> (ø)
:arrow_up:

...17_06_01/models/network_management_client_enums.py
100% <0%> (ø)
:arrow_up:

...017_06_01/operations/packet_captures_operations.py
12.32% <0%> (ø)
:arrow_up:

...mt/network/v2017_06_01/models/public_ip_address.py
100% <0%> (ø)
:arrow_up:

... and 32 more

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 61c3829...e469e38. Read the comment docs.

Replaced by https://github.com/Azure/azure-sdk-for-python/pull/1373


Downgrade netatmo warning-level log to info-level

Description:
This mini-PR changes a recently-added log to info level, as the content of the log is not problematic.
Related issue (if applicable): fixes #15618
Example entry for configuration.yaml N/A
Checklist:

[x] The code change is tested and works locally.
[ ] Local tests pass with tox. Your PR cannot be merged unless tests pass

If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated in home-assistant.github.io

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

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

If the code does not interact with devices:

[ ] Tests have been added to verify that the new code works.

Thanks for the update! Logfile is much cleaner now! 😃👍🏼


In IE/FF icons code is always \22

For example screenshot
http://prntscr.com/6vyacu
Chrome(Chromium base) shows correct icons code.
related to this issue, it isn't fixed yet
https://github.com/driftyco/ionicons/issues/228

Same in Chrome, for me.

This is the very same issue as described in #228 .


Added Sublime Text 3 plugin to README.md

Updated the README.md as asked. :smiley:

This is awesome, thanks for making this!


Add new deobfuscator

You can please add deobfuscator Shape Security virtual machine???

I have previously attempted to deobfuscate Shape's VM (sample available at https://static1.st8fm.com/en_US/b2c_dvts/common/js/lib/StateFarmCommon.js?seed=AED81Gl0AQAALEz8hIvHvZeXQkQK86AUN7Y6IcUKEPYR88JgTb0AIuagh-Ma&J5odCIZGx--z=q) but I did not get very far.
But here's a few things I picked up on (first pass the script into https://beautifier.io/):
This is the function (yW) that actually executes the instructions.  yB is basically the VM context.  The "i" function of yB is the one that runs the next instruction.
    function yW(yB) {         var yV, yy;         for (;;) {             if (Mr !== X) {                 yy = Mr;                 Mr = X;                 return yy             }             yV = yB.i();             if (yB.K.length === 0) {                 Xn[yV](yB)             } else {                 jC(Xn[yV], yB)             }         }     }
The big array of functions is all of the opcodes for the VM.
The big blob of data passed to the function F is the VM "binary" (encoded of course).
var jP = F("HwGCmLkNAL4WtrM...."
The strings used in the VM
var H = ["Rmgz0NiizkdOIuLbNz5yWqxr", "ogU6wvy3sEIhOqePW2g8Guk8vqFYYQva", "1PnfdBZS", ...
All are obfuscated with a combination of base64 and XOR.
I do not have much experience with VM based obfuscation but I think if you look around you could probably find some very talented people willing to help (maybe even moreso if you offer them payment).