Why does the package require a test() for each scenario?

Normally, as far as I am aware, one never matches on scenarios, since they should all be different tests for the same feature. What's the reason for having to write test(scenario_name) instead of simply providing the feature and the step matchers?

The goal is to improve readability by having the step definitions read more like the feature file, and also be structured somewhat more like typical Jest scenarios. Cucumber does not validate the ordering or even the location of step definitions, whereas this library validates that all step definitions are listed in order under each scenario block. This reduces the mental overhead when reasoning about test code, because it is no longer necessary to constantly cross-reference between the feature files and the step definitions. The trade-off for this improved readability is that step definition code still be re-used if abstracted into another function, but that function must then be called from every scenario that requires it, which is more verbose than Cucumber's approach to step definition re-usability.

As I spent a few more hours with it last night I sort of see why things are this way. Having used Cucumber in Ruby it annoyed me greatly to have to match on each scenario since typically one would just add a scenario with new steps and not having to update any matchers (given that no step was new, of course.)
I kind of see the rationale, I guess. Definitely works out better in jest! Thanks for the explanation 😊


[RFE] OpenShift cluster health checks

Is your feature request related to a problem? Please describe.
Taking advantage of the new parameter clusterHealth added in https://github.com/kube-burner/kube-burner/pull/585, add a series of OpenShift cluster health checks including:

Cluster-operator status, we can reuse part of the code of the verifyContainerRegistry() function. https://github.com/kube-burner/kube-burner-ocp/blob/main/common.go#L47-L84

Describe the solution you'd like
Check readiness of all OpenShiftt clusteroperators

cc: @shashank-boyapally

Will be adding this to ocp as well


Change "get started" on macOS to use Orbstack or Colima by default

People are most likely to have a good experience with something other than Docker Desktop on macOS.
https://ddev.com/get-started/ could use Orbstack
However, Orbstack is not yet officially documented

This was done.


feat: add aks-engine release v0.32.1

See https://github.com/Azure/aks-engine/releases/tag/v0.32.1
Tested by pushing to my fork's master and doing "brew install mboersma/aks-engine/aks-engine."

lgtm


makes callback handler of off method as optional

makes callback handler of off method as optional. Terminates all worker with the passed name of no callback is passed.
Related Issue: #5

Thanks for the review @josex2r. Yes, will club up the promises.
Off topic. Can we migrate the test suite to async/await ??

I'm going to merge and publish a minor version with your changes
And... for sure! If you want you can migrate tests 👍


chore: rome to biome

This PR introduces biome to replace rome, and fixes format and lint errors.

Thank you!


Implemented new test system

New test system now only consists of the following files

one file for all testcases
one file for the runner
one file for the color dictionary

Merge anyways, evaluator is WIP


Huge problem with infinite loop options into group.

Hi, I found an issue when your group contain options and options contains group — and it almost infinite loop. Can you please fix it?

Thanks

With this case I'm not able to save Selected options as JSON to the localStorage.


13B doesn't work for unknown reasons

Hello,
Even if it's low priority, I created this issue to follow investigations.
Feel free to close it, if it's not the way to go.

 Could you check if the changes of #154 fix the problem?

Hello,
No more issue with you patch!
Based on your commit I switched to ubsan as it is more appropriate to catch this kind of bug
rundebug: run.c
	$(CC) -O1 -g -o run run.c -lm -fsanitize=undefined -fno-omit-frame-pointer

And bingo !
Run against karpathy/master:
run.c:135:33: runtime error: signed integer overflow: 204800 * 13824 cannot be represented in type 'int'
run.c:137:40: runtime error: signed integer overflow: 552960 * 5120 cannot be represented in type 'int'
run.c:139:33: runtime error: signed integer overflow: 204800 * 13824 cannot be represented in type 'int'
<s>
run.c:313:43: runtime error: signed integer overflow: 13824 * 158720 cannot be represented in type 'int'

Still got error with ubsan on your fork though :/
lempire@spark-lab0:~/alban/fork/llama2.c$ ./run /home/lempire/alban/llama/llama2_13b.bin 1.0 20 "// js function to remove all fields named 'id' from given object\n"
run.c:132:33: runtime error: signed integer overflow: 204800 * 13824 cannot be represented in type 'int'
run.c:134:40: runtime error: signed integer overflow: 552960 * 5120 cannot be represented in type 'int'
run.c:136:33: runtime error: signed integer overflow: 204800 * 13824 cannot be represented in type 'int'

No more error nor from ubsan nor asan with #154 !!

Cool! Thank you! =)

https://github.com/karpathy/llama2.c/pull/154 is a much better fix IMHO

closing as this PR fixed the issue, ty all https://github.com/karpathy/llama2.c/pull/367


Enum not recognised in match statement if read from json file

Godot version: 3.2
OS/device including version: Kubuntu 18.04
Issue description: If using an enum in a match statement, it will not match if the value is read from a file (in this specific case, json file) and assigned to a var without static typing.
The code below will cause the match statement to not recognise the enum type:
var enum_type = parsed_json["enum_type"]
This code will be recognised in the match statement:
var enum_type : int = parsed_json["enum_type"]
Steps to reproduce:
Create a json file with a single value held in a dictionary:
{ "enum_type" : 2}

Read file from disk
Parse the source with JSON.parse() giving you a Dictionary
Assign the parsed value from the Dictionary to a var without typing.

Minimal reproduction project:
MatchBug.zip

Of course if I am doing something fundamentally wrong please let me know, but I would have thought that if you're not using static typing then this could cause some real headaches.

As you can see in a picture below, both variables have value 1, but test_enum.type1 is integer(2 - Search TYPE_INT in builtin docs) and enum_val is a float value.
Comparison of integer and float usually show correct result, but as you can see not this time, so it is better to use typed gdscript or make sure, that variables are same type enum_val = int(enum_val)

This is an expected behavior. As the JSON format does not differentiate between floats and int, the parser always interpret it as a float. Consequently, when you do your parsing, you need to cast the value to an int yourself. (which the type int does)

While JSON format does not differentiate between floats and int, it's still easy to make serialization errors like this.
The part of the code responsible for parsing a JSON number in Godot:
https://github.com/godotengine/godot/blob/cf8c679a23b21d6c6f29cba6a54eaa2eed88bf92/core/io/json.cpp#L271-L279
So, String::to_double forces the value to be converted to floating point number. I do think it makes sense to allow parsing values which are recognized by Godot natively for serialization purposes so there's no "one-way conversion". It means that to_json and parse_json should be "idempotent", so to speak.
This issue can possibly be solved very similarly to how #33241 converts incompatible values to and from JSON.

It means that to_json and parse_json should be "idempotent", so to speak.

This is simply not possible. The JSON format does not even handle keys that are not string, and the parser shouldn't any unexpected black magic behind the scene to solve the problem. The JSON format has limitations, it's up to the user to know about them (we can document it though, to avoid future issues).

Sorry I was mostly talking about the ability to encode JSON-incompatible Variants within JSON-compatible strings the way it's proposed by #33241, but yeah currently it's not possible.


OS Notifications

Would be great if this was exposed at the golang layer to make local notifications to the OS.
I guess also being able to respond to notifications sent via the Google and Apple notification servers, where the user sees the notification and then clicks on it and it routes into your app.

Thanks, something like that would be great, but I think probably out of scope for this project. I'd like for it to focus on just displaying UI.

just want to check, because i realised i explained this really badly.
I am talking about how you need to publish notifications in your apps on mobile.
Just checking because i would have thought its pretty important.
Like an email app needs to display Notifications of new email and when the user clicks on the notification it taks them to the email in questions, etc etc


Set pls initial value as minimal value in knobs.slider

Set pls initial value as minimum value if initial value isn't defined in knobs.slider

Deployed in storybook_flutter: ^0.11.2+1


⚠ Bofrost.be has degraded performance

In fbc8577, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1120 ms

Resolved: Bofrost.be performance has improved in 16690b7 after 7 minutes.


Can recommend taxi reservation deep links now

Add taxi reservation recommendation logic into app: when user type a sentence. Use text classifier to identify if the text is an address. And use geocoder to get the coordinates and update the view.
fix #36

All comments fixed. I also check into some gradlew and wrapper so anyone can work with it without needing to install Gradle beforehand.


[MTSRE-796] Bump up OPM version to 1.24.0

Signed-off-by: Ankit Kurmi<EMAIL_ADDRESS>py-mtcli
Description
Bumping OPM version from 1.19.5 to 1.24.0.

@thetechnick can you review


config: add file path to error message when parsing fails

Before:
undefined:5
}
^

SyntaxError: Unexpected token } in JSON at position 138
    at JSON.parse (<anonymous>)
    at exports.readJson (…/lib/file.js:38:17)
    at Object.exports.getConfig (…/lib/config.js:34:10)
    at Object.exports.getMergedConfig (…/lib/config.js:26:32)
    at Object.<anonymous> (…/components/git/metadata.js:8:44)
    at Module._compile (node:internal/modules/cjs/loader:1097:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1151:10)
    at Module.load (node:internal/modules/cjs/loader:975:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Module.require (node:internal/modules/cjs/loader:999:19)

Node.js v17.6.0

After:
…/lib/config.js:39
    throw err
    ^

Error: Unable to parse config file /home/~/.ncurc
    at Object.exports.getConfig (…/lib/config.js:37:17)
    at Object.exports.getMergedConfig (…/lib/config.js:26:32)
    ... 5 lines matching cause stack trace ...
    at Module.require (node:internal/modules/cjs/loader:999:19)
    at Object.require (node:internal/modules/cjs/helpers:102:18)
    at …/node_modules/require-directory/index.js:76:17 {
  cause: SyntaxError: Unexpected token } in JSON at position 138
      at JSON.parse (<anonymous>)
      at exports.readJson (…/lib/file.js:38:17)
      at Object.exports.getConfig (…/lib/config.js:35:12)
      at Object.exports.getMergedConfig (…/lib/config.js:26:32)
      at Object.<anonymous> (…/components/git/metadata.js:8:44)
      at Module._compile (node:internal/modules/cjs/loader:1097:14)
      at Object.Module._extensions..js (node:internal/modules/cjs/loader:1151:10)
      at Module.load (node:internal/modules/cjs/loader:975:32)
      at Function.Module._load (node:internal/modules/cjs/loader:822:12)
      at Module.require (node:internal/modules/cjs/loader:999:19)
}

Node.js v17.6.0

@aduh95 I think if you amend the commit message to start with fix: or feat: rather than config:, the linter will pass and this can land. (The Windows timeout is a known flaky and can be re-run.)

@aduh95 I think if you amend the commit message to start with fix: or feat: rather than config:, the linter will pass and this can land. (The Windows timeout is a known flaky and can be re-run.)

Yes. It will also be included in the changelog, and a release PR will be created (release-please only creates a PR if there's at least a fix, feat, or breaking change)


Define the basic design tokens

We should define the basic design tokens for the design system. Things it should initially include:

[ ] Typography
[ ] Colors
[ ] Spacing (margins and paddings)
[ ] Borders
[ ] Icons

Figma: https://www.figma.com/file/bPMB3lkMTOOMuKk0oGLuNm/Studio?type=design&node-id=0%3A1&t=5t1QnTliI6risXyA-1
Related to #636

/progress 40
I think I've figured this out but still not completely sure. Currently defining the list of colors and typography tokens.


Fail to build for wasm on macOS

It says SYSSOURCES contains a filename with a $ character in it - Unable to continue with all dependence set up (using  emsdk_portable and updated to latest emscripten)
I comment these lines (ZillaLibWasm.mk L251-253) out to be able to continue:
ifeq ($(findstring $,$(SYSSOURCES)),$)
  $(error SYSSOURCES contains a filename with a $$ character in it - Unable to continue)
endif

But the building process failed again, says: unable to create target: 'No available targets are compatible with this triple.' 1 error generated.

Hi there!
Thank you so much for trying ZillaLib and filing this issue.
I just committed some fixes for the WebAssembly builds on non-Windows platforms. The choice of $ as a replacement character wasn't great as on unix-like shells $ is used for environment variables. It should be better now.
As for the second problem, make sure you have the latest clang and lld with wasm support from https://releases.llvm.org/download.html. I tested with clang-8 and lld from clang+llvm-8.0.0-x86_64-apple-darwin.tar.xz and I could build fine on a not-so-up-to-date macOS.
If problems persist, you can run make wasm -n to see the command line used to invoke clang which should help us diagnose this further.
Also, you sadly have to make sure that the paths for LLVM_ROOT and SYSTEM_ROOT given in ZillaAppLocalConfig.mk don't contain any spaces as make is not good at handling such paths.

Switch to LLVM 8.0.0 solved it :)
Your framework is just amazing, I especially love small binary size cause I mostly do web games. Will try it more.
BTW. ZillaLib supports 3D rendering, but I wander is it possible to render "unshaded" style 3D graphics?
Something like

link to the game

So happy that it works!
Thanks for the praise, small output size is what drives me mostly :-)
Regarding un-shaded, graphics, with vertex coloring like in sample 31 you're halfway there. A more toon-shaded effect is sadly not supported out of the box. I played a bit with the light calculation and achieved the following look quite easily:

//light calculation for directional light
Z3L_LIGHTFACTOR " = max(dot(" Z3S_NORMAL ", " Z3U_LIGHTDATA "[1+i*3]), 0.);" //original
Z3L_LIGHTFACTOR " = (dot(" Z3S_NORMAL ", " Z3U_LIGHTDATA "[1+i*3]) > .1 ? 1. : 0.);" //toon look

//light calculation for spot light
Z3L_LIGHTFACTOR " = max(dot(" Z3S_NORMAL ", " Z3L_DIRECTION2LIGHT "), 0.);" //original
Z3L_LIGHTFACTOR " = (dot(" Z3S_NORMAL ", " Z3L_DIRECTION2LIGHT ") > .1 ? 1. : 0.);" //toon look

But the 3D functionality is still very far from a full fledged 3D engine. Things shown in the game you linked like skeletal animation, moving water, the moving sail etc. would not be easy without touching the framework I think.
Features of ZillaLib are mostly driven by the small games I make. The most advanced 3D game I made with it is Altar War, it shows the state of most of the 3D features.

Thanks for the advice. And I think this issue should be closed now.


Cannot export class descending from eventemitter3

I'm trying to accomplish this but am told:
src/index.ts(3,35): error TS4020: Extends clause of exported class 'Test' has or is using private name 'EventEmitter'.
I'm new to Typescript, so in an attempt to do the right thing I went out and read a bunch of docs. My understanding was that I needed to somehow export EventEmitter so the module has everything it needs available publicly. So I tried every export form I could think of, but nothing worked.
I did even more research and discovered DefinitelyTyped/DefinitelyTyped#7439. This is exactly what I'm experiencing, along with a second test repo which seems to indicate that this problem goes away with an older declaration. This all leaves me wondering, as a new Typescript user, where the issue lies.
Later I found Microsoft/TypeScript#6307, asked for guidance there, and was told to file another issue. So, here it is. :) Is this an issue in the official eventemitter3 declaration that they need to fix, or is it a TS bug? I'll note that everything seems to work as long as I don't export the class that descends from EventEmitter, so if there was a problem with the declaration then I'd expect that to surface regardless of whether I exported the subclass.
Thanks. Using Typescript 1.8.9.

Can you include the self-contained repro as well? Thanks!

It's the first link I posted in the issue. Is that not what you're
looking for?
Just clone it down and run npm install && tsc.

looks like it is fixed in latest. can you give typescript@next a try.

Yup, works for me. Thanks!

thanks for verifying.


python310Packages.dinghy: 0.13.4 -> 0.14.0

Description of changes
New upstream release
Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

The changelog mentions, that there's now also a cli tool (which makes a lot of sense)

Now a CLI command is registered so you can use dinghy as a command instead of python -m dinghy (though that still works).

From 13e0888d58729e3d3d05d82dc0f485bb9b84b3b9 Mon Sep 17 00:00:00 2001
From: Vincent Haupert<EMAIL_ADDRESS>Date: Wed, 2 Nov 2022 20:25:05 +0100
Subject: [PATCH] dinghy: init from python310Pacakges.dinghy

---
 pkgs/top-level/all-packages.nix | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/pkgs/top-level/all-packages.nix b/pkgs/top-level/all-packages.nix
index 2241ecf0f60..bd3586e04ca 100644
--- a/pkgs/top-level/all-packages.nix
+++ b/pkgs/top-level/all-packages.nix
@@ -456,6 +456,8 @@ with pkgs;

   dhallToNix = callPackage ../build-support/dhall/to-nix.nix { };

+  dinghy = with python3Packages; toPythonApplication dinghy;
+
   deadcode = callPackage ../development/tools/deadcode { };

   deadnix = callPackage ../development/tools/deadnix { };
--
2.38.0

Result of nixpkgs-review pr 199199 run on x86_64-linux 1

2 packages built:

dinghy (python310Packages.dinghy)
python39Packages.dinghy


Code refactor on Kyuubi Hive JDBC driver

Why are the changes needed?

This PR is separated from #3023, to make #3023 change more clear.
It is a pure code refactor, and should not break any functionality and public API.
How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[x] Run test locally before make a pull request

Thanks, merging to master


Continuously switching resolutions?

Required Info

Camera Model
{ D435i }

Firmware Version
<IP_ADDRESS>

Operating System & Version
Win10

Platform
PC

SDK Version
2.43.0

Language
python

Issue Description
We hope to achieve the tracking effect with RealSense, which may involve continuously switching image resolutions from 848x480 to 848x100.
The official website mentions that under the conditions of 848x100, it's possible to achieve 300 FPS. I have two questions regarding this:

Is it possible to adjust the position of the 848x100 image?
When switching from 848x480 resolution to 848x100 resolution, a 600ms delay occurs. Is there a way to resolve this?

Hi @friend045  Do you require further assistance with this case, please?  Thanks!

Case closed due to no further comments received.


Add net461 target

In the process of investigating XPlot using latest Google.DataTable.Net.Wrapper that targets netstandar2.0. I found that Chart.Show does not work in netcore app.
In order to launch HTML in browser across platform, it has to check OS platform by running System.Runtime.InteropServices.RuntimeInformation.IsOSPlatform. That requires XPlot to target net472. Its dependency on Deedle has to be on net461 to be compatible.
I also updated latest FSharp.Formatting on nuget instead of from appveyor.

Just found a silly mistake. Deedle does not need to be net461 to make XPlot net472 work. Will update dependencies separately.


multiple choice

multiple choice can be available?

@pheromone If you read README.md, you could see the next message at the beginning.
Before you open an issue
This library started as a basic bridge of the native iOS image picker, and I want to keep it that way. As such, functionality beyond what the native UIImagePickerController supports will not be supported here. Multiple image selection, more control over the crop tool, and landscape support are things missing from the native iOS functionality - not issues with my library. If you need these things, react-native-image-crop-picker might be a better choice for you.

OK ,i get u ,but it can not compress image in ios,maybe i used in a wrong way~

@chendongcd Could you create another task for the second problem?


[Question] Scripting SAM CLIs to build, package and deploy Lambda functions

Hi. Newbie here and hope someone can provide some guidance.
I uses Visual Studio SAM project to create multiple lambda functions. I've written a script that:
sam build
sam package
sam deploy

Everything works great. However:

sam package generates and upload to S3 {UUID} package zip files (one per function). Can I give it a more meaningful name instead of {UUID}?
Running my script will always generate and upload new package files even thought I've made no changes to my function. Is there a way/method where it will only build or package IFF there is changes to my function?

Thanks to this comment, I've found you can use the --s3-prefix to give the file a meaningful prefix at least, so now your various lambda functions can be sorted in the bucket

sam deploy --guided now adds the stack name prefix automatically.

" Is there a way/method where it will only build or package IFF there is changes to my function"

This comes under incremental builds and packaging, for which we have separate issues already.
Closing this issue.


Update fetch_enable signal

We have a requirement from OpenTitan to be able to block the CPU from executing at certain points. I propose we update the existing fetch_enable signal to do that, since it's current behavior is a bit confusing and probably not that useful.

@tomroberts-lowrisc: Do we still have this requirement? (Since I think we never allow the CPU to recover after it's been squashed, presumably another way to do this on the OT side would be to gate the fetch signal in rv_core_ibex).

@tomroberts-lowrisc: Do we still have this requirement? (Since I think we never allow the CPU to recover after it's been squashed, presumably another way to do this on the OT side would be to gate the fetch signal in rv_core_ibex).

Still need to do something here - the fetch_enable_i signal currently does nothing once the core is actually running so would need to change its behaviour and document it

Still need to do something here - the fetch_enable_i signal currently does nothing once the core is actually running so would need to change its behaviour and document it

Understood. What I meant is that we could choose just to squash outgoing fetches in rv_core_ibex. But, thinking about it, that probably isn't enough when there's also an icache.

Understood. What I meant is that we could choose just to squash outgoing fetches in rv_core_ibex. But, thinking about it, that probably isn't enough when there's also an icache.


Fix #18 Rounding issue with limiting decimals for numbers near 100 million

This fixes a floating point formatting issue described in #18

Thank you for your pull request but I found where the problem came from and I fixed the code.

Thanks!

Do you know when this will be available on npm?

Sorry for that, it's available now :)

Ah, great! Thank you.


Features are being generated as "Unknown test suite"

I'm currently using the allure-cucumber-jvm-adaptor version 1.5.1 to run the listener through a set of Cucumber tests.
When the reports are generated, I notice that only a few scenarios are recognized as behaviours, normally it's the scenarios of 2 random features (out of 10 or 12).
Looking around the allure-results i noticed that only a couple of the testsuite.xml files get the proper format
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:test-suite start="1454325877685" stop="1454325877691" version="1.4.15" xmlns:ns2="urn:model.allure.qatools.yandex.ru">
    <name>Extracting data</name>
    <title>Extracting data</title>
    <test-cases>

But most of the results just show the following format
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:test-suite start="0" stop="1454325853500" version="1.4.15" xmlns:ns2="urn:model.allure.qatools.yandex.ru">
    <test-cases>

Is this a known issue or am I getting something wrong on my gherkin files that are preventing the proper results generation?
I noticed #21 seems to be somewhat related to what I'm getting, but I'm not really sure if we are talking about the same thing in both issues.

@jorgeejgonzalez it is not enough data to analyze.
Could you provide more information?
I need scenarion name for blank test and exceptions if it present.

@jorgeejgonzalez it would be nice if you'll provide us the sample project to reproduce the problem

I encountered the exact same issue and I fixed it by removing all non-ASCII characters from the step definitions. I don't know if that'll work for you, but it's worth a try.

Ok, to provide a little more perspective, I noticed that it's only the scenarios of two features that get proper naming, if I add a third feature to the mix, the third feature wont get properly named.
But let's address this step by step.
First my pom.xml looks like this:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.famous-smoke</groupId>
    <artifactId>web-testing-framework</artifactId>
    <version>1.2.2</version>
    <packaging>jar</packaging>
    <name>Web Testing Framework</name>

    <properties>
        <apache.poi.version>3.13</apache.poi.version>
        <cucumber.version>1.2.4</cucumber.version>
        <picocontainer.version>2.15</picocontainer.version>
        <allure.version>1.4.15</allure.version>
        <allure.adaptor.version>1.6-SNAPSHOT</allure.adaptor.version>
        <aspectj.version>1.8.7</aspectj.version>
        <phantomdriver.version>1.2.1</phantomdriver.version>
        <selenium.version>2.49.0</selenium.version>
    </properties>

    <dependencies>

        <dependency>
            <groupId>com.codeborne</groupId>
            <artifactId>phantomjsdriver</artifactId>
            <version>${phantomdriver.version}</version>
        </dependency>
        <dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-remote-driver</artifactId>
            <version>${selenium.version}</version>
        </dependency>

        <dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-java</artifactId>
            <version>${selenium.version}</version>
        </dependency>
        <dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-server</artifactId>
            <version>${selenium.version}</version>
        </dependency>

        <dependency>
            <groupId>org.apache.httpcomponents</groupId>
            <artifactId>httpclient</artifactId>
            <version>4.5.1</version>
        </dependency>

        <dependency>
            <groupId>org.apache.poi</groupId>
            <artifactId>poi</artifactId>
            <version>${apache.poi.version}</version>
        </dependency>

        <dependency>
            <groupId>org.apache.poi</groupId>
            <artifactId>poi-ooxml</artifactId>
            <version>${apache.poi.version}</version>
        </dependency>

        <dependency>
            <groupId>ru.yandex.qatools.allure</groupId>
            <artifactId>allure-cucumber-jvm-adaptor</artifactId>
            <version>${allure.adaptor.version}</version>
        </dependency>

        <dependency>
            <groupId>org.easytesting</groupId>
            <artifactId>fest-assert-core</artifactId>
            <version>2.0M10</version>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>net.masterthought</groupId>
            <artifactId>cucumber-reporting</artifactId>
            <version>1.2.0</version>
        </dependency>

    </dependencies>

    <build>
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-surefire-plugin</artifactId>
                    <version>2.19</version>
                    <dependencies>
                        <dependency>
                            <groupId>org.apache.maven.surefire</groupId>
                            <artifactId>surefire-junit47</artifactId>
                            <version>2.19</version>
                        </dependency>
                        <dependency>
                            <groupId>org.aspectj</groupId>
                            <artifactId>aspectjweaver</artifactId>
                            <version>${aspectj.version}</version>
                        </dependency>
                    </dependencies>

                    <configuration>
                        <testFailureIgnore>true</testFailureIgnore>
                        <argLine>
                            -javaagent:${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar
                        </argLine>
                        <properties>
                            <property>
                                <name>listener</name>
                                <value>ru.yandex.qatools.allure.cucumberjvm.AllureRunListener</value>
                            </property>
                        </properties>
                    </configuration>
                </plugin>

                <plugin>
                    <groupId>net.masterthought</groupId>
                    <artifactId>maven-cucumber-reporting</artifactId>
                    <version>0.1.0</version>
                    <executions>
                        <execution>
                            <id>execution</id>
                            <phase>verify</phase>
                            <goals>
                                <goal>generate</goal>
                            </goals>
                            <configuration>
                                <projectName>web-testing-framework</projectName>
                                <outputDirectory>${project.build.directory}/site/cucumber-reports</outputDirectory>
                                <cucumberOutput>${project.build.directory}/cucumber.json</cucumberOutput>
                                <enableFlashCharts>true</enableFlashCharts>
                            </configuration>
                        </execution>
                    </executions>
                </plugin>

                <plugin>
                    <artifactId>maven-compiler-plugin</artifactId>
                    <configuration>
                        <source>1.8</source>
                        <target>1.8</target>
                    </configuration>
                </plugin>

                <plugin>
                    <groupId>org.eclipse.jetty</groupId>
                    <artifactId>jetty-maven-plugin</artifactId>
                    <version>9.2.10.v20150310</version>
                    <configuration>
                        <webAppSourceDirectory>${project.build.directory}/site/allure-maven-plugin</webAppSourceDirectory>
                        <stopKey>stop</stopKey>
                        <stopPort>1234</stopPort>
                    </configuration>
                </plugin>
            </plugins>
        </pluginManagement>
    </build>

    <reporting>
        <excludeDefaults>true</excludeDefaults>
        <plugins>
            <plugin>
                <groupId>ru.yandex.qatools.allure</groupId>
                <artifactId>allure-maven-plugin</artifactId>
                <version>2.0</version>
            </plugin>
        </plugins>
    </reporting>

</project>

My features are:
ExtractBrandPagesData.feature
@setup
Feature: We need to extract the Brand Page Data
  Scenario: Extracting data from famous smoke
    Given I need to Setup the Features
    And I navigate to the page "https://www.famous-smoke.com/brand-list"
    And I crawl through the list
    When I store the extracted data
    Then I should process the features

PageBreadcrumbs.feature
@actionvalidation
Feature: In every Page all breadcrumbs must go to correct links

  Scenario Outline: I will validate the navigation of the breadcrumbs
    Given I want to check the breadcrumbs of "<URL>"
    When I check all the breadcrumbs
    Then the navigation must be valid

    Examples:
    | URL |
    | https://www.famous-smoke.com/brand/no.+famous+cigars |
| https://www.famous-smoke.com/brandgroup/1502+cigars |

PageValidTitleLength.feature
@seo
Feature: The Title length of all Pages should be in a rage

  Scenario Outline: I will validate the length of the Page Title
    Given I want to the check the content of the url "<URL>"
    When I navigate to the page
    Then the title should be  under 70 characters
    Examples:
      | URL |
  | https://www.famous-smoke.com/brand/no.+famous+cigars |
| https://www.famous-smoke.com/brandgroup/1502+cigars |

Now, I actually have many more features but just with these three I can replicate the error.
If I test with the three features the title length scenarios do not generate the name and title tags
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:test-suite start="0" stop="1454539423542" version="1.4.15" xmlns:ns2="urn:model.allure.qatools.yandex.ru">
    <test-cases>
        <test-case start="1454539422112" stop="1454539422112" status="passed">
            <name>Given I want to the check the content of the url "https://www.famous-smoke.com/brand/no.+famous+cigars"</name>
            <title>Given I want to the check the content of the url "https://www.famous-smoke.com/brand/no.+famous+cigars"</title>
            <steps/>
            <attachments/>
            <labels>

But If I remove one of the other features, then they get named properly
<ns2:test-suite start="1454539293366" stop="1454539296118" version="1.4.15" xmlns:ns2="urn:model.allure.qatools.yandex.ru">
    <name>I will validate the length of the Page Title | https://www.famous-smoke.com/brand/no.+famous+cigars |</name>
    <title>I will validate the length of the Page Title | https://www.famous-smoke.com/brand/no.+famous+cigars |</title>
    <test-cases>
        <test-case start="1454539293376" stop="1454539293378" status="passed">
            <name>Given I want to the check the content of the url "https://www.famous-smoke.com/brand/no.+famous+cigars"</name>
            <title>Given I want to the check the content of the url "https://www.famous-smoke.com/brand/no.+famous+cigars"</title>
            <steps/>
            <attachments/>
            <labels>

I doubt this is a problem of encoding but it seems to me to be some sort of multithreading issue between the cucumber-jvm runner and the listener.
Just so you know, these are the runners I'm using
package com.famous_smoke.automation;

import cucumber.api.CucumberOptions;
import cucumber.api.junit.Cucumber;
import org.junit.runner.RunWith;

@RunWith(Cucumber.class)
@CucumberOptions(
		features = {"classpath:features-processed"},
		plugin = {"pretty", "html:target/site/cucumber-pretty","json:target/cucumber.json"}
)
public class FamousSmokeTest {
}

package com.famous_smoke.automation;

import cucumber.api.CucumberOptions;
import cucumber.api.junit.Cucumber;
import org.junit.runner.RunWith;

@RunWith(Cucumber.class)
@CucumberOptions(
		features = {"classpath:features/setup"},
		plugin = {"pretty", "html:target/site/cucumber-pretty","json:target/cucumber.json"},
        tags = "@setup"
)
public class FeaturesSetupTest {
}

This is part of a project I have in a public repository in github so it can be forked if you would prefer to see the issue in more context.
Regards

I doubt this is a problem of encoding but it seems to me to be some sort of multithreading issue between the cucumber-jvm runner and the listener.
I don`t see multithreading configuration on pom.xml. Are you sure what tests runs in parallel?

I didn't enable parallel running but I can't figure out anything else, if it was due to encoding then the error should be persistant, instead only two features get properly named in each run

I found some problem when using different files with the same Features names; when the second Feature with the same name of one executed previously was run, the Scenarios under this Feature were classified under a Unknown suite.
Per your sample files, it doesn't seem to be your problem, but check your project for repeated Features names, that might be the problem.

Different files with the same Features names works well. I`ve just tested.

I confirm problem. It appears if you have duplicate scenario names - not features.
If I place into folder features-setup feature A with scenario B and same feature in folder features-processed ant then start tests - problem reproduced.
But if I change scenario name in folder features-setup (and leave feature name) problem resloved.
@Jiwari you can use it as workaround until I realese bugfix.

I've been checking my scenarios and each one has an unique name and the error still occurs; maybe it has something to do with the fact that I'm using scenario outlines. Not sure if that triggers the issue

Scenario outlines may leads to this error only same example liness will in one outline.

And what difference between classpath:features/setup and classpath:features-processed?

This is a big difference to my project; our features are dynamically generated from a group of templates after scrapping some data from the web, particularly, the urls to which we are going to perform the validations.
Hence the setup feature which performs the data extraction and creates the features from the templates.

wow! I found the problem!
It happens when we have two features with scenario outlines with same parameters.
Problem found. I wil try to solve it ASAP.
P.S. Thank you for test project.

Quick research leads to conclusion what it cant be fixed on adaptor side. So Ive created an issue in https://github.com/cucumber/cucumber-jvm/issues/959 .
So until it accepted, use workaround please.

I can confirm that the workaround is working.
Thanks

I'm also facing this problem. And I'd like to mention, there is no need of different features. It also reproduced in one:
Feature:
Outline 1:
|URL|
|http://fb.com|
Outline 2:
|URL|
|http://fb.com|

Any news about fixing it?

@SButterfly yes Im working on it. You could try [this branch](https://github.com/allure-framework/allure-cucumber-jvm-adaptor/tree/migrate-to-uniques). But I wont merge it into maser because it have issues with multithreading.
To make it work you should follow special pom.xml configuration
If you will decide to try this, give me some feedback please - is it solves problem for you or not.

@clicman Well, now there are no 'Without feature' row in allure reports.
But when I opened logs, I saw
122 Scenarios (9 failed, 113 passed)
690 Steps (8 failed, 13 skipped, 669 passed)

And on xUnit tab at allure reports I saw:
Total: 110 test suites, 690 test cases

Smth gone wrong

So... Which one of provided results are actual and which are wrong? I admit it count wrong cases count in logs but should count it right in allure report.

122 is correct.
I thought it is allure report bug. Because on 'Behaviors tab' total number of scenarios is 122. But on xUnit tab total number is 110, which is wrong.

What about current bug? When can we have a release with it?

I should take some conversation with guys from Surefire team.
It has some mess with couple surefire issues:
https://issues.apache.org/jira/browse/SUREFIRE-1227
https://issues.apache.org/jira/browse/SUREFIRE-1187
https://issues.apache.org/jira/browse/SUREFIRE-1095
So if I release it now, people who uses parallel execution will start to catch bugs.

Hello, It's me.. again..
I found bug in new implementation
It looks like if two scenarios have similar names, they placed under one scenario in allure reports.
Ex
Feature: Feature

  Scenario: Scenario
    When whe run the scenario

  Scenario: Scenario
    Then scenario name shuld be complete

Then in allure reports at 'Behaviors' tab.
Feature: Feature
+- Scenario: Scenario
    +- When whe run the scenario
    +- Then scenario name shuld be complete

@SButterfly it is not an implementation bug :) Its how allure sort entities. Also it is strange to have scenarious with same name in one feature. It is breaks BDD principle (and allure and everything). Do not do that anymore.

Fixed in master. Will available in 1.6 release


Mix not exporting the same js if sass is involved

Hey

Laravel Mix Version: ^0.8.8
Node Version (node -v): 7.7.3
NPM Version (npm -v): 4.1.2
OS: Mac Sierra

Description:
Not sure really how to explain this. I created a new folder, yarn add laravel-mix. And then setup for Mix to compile react. Somehow when I use this:
let mix = require('laravel-mix');

mix.webpackConfig({
        output: {
            library: 'walterwhite',
            libraryTarget: 'umd',
            umdNamedDefine: true
        }
    })
    .react('src/index.js', 'dist/js')
    .browserSync('mysite.dev');

Then everything works fine. My library is exported, I can then use it in another project no problem.
However, if I add a line to compile SASS at the same time, like so:
let mix = require('laravel-mix');

mix.webpackConfig({
        output: {
            library: 'walterwhite',
            libraryTarget: 'umd',
            umdNamedDefine: true
        }
    })
    .react('src/index.js', 'dist/js')
    .sass('src/app.scss', 'dist/css')
    .browserSync('mysite.dev');

It doesn't compile properly anymore and my library is un-usable. No matter where I place the sass compile, wether it is above, under react or even in a separate instance of mix, it doesn't work. There are no failures, warnings or errors being displayed.
I had a look at what is compiled and there is a slight difference between the 2 configs like for example the number of exports is greater by 1 when I add sass. Maybe there's a reason for that
Does that make sense to someone?
Thanks for any help

I'm not sure, but we're adding a mix.standaloneSass() option to the next tagged release that would run Sass separate from your Webpack build. So this would fix that.

Jizaz, this took a few hours of my life.
Sure, we could use standaloneSass like @JeffreyWay suggested however the library's css won't have auto vendor prefixes etc. Not cool.
Ok, so @RomainGoncalves you can fix this by adding a mock entry first.
mix.js('node_modules/laravel-mix/src/builder/mock-entry.js', 'mix.js')
  .react('src/index.js', 'dist/js')
  .sass('src/app.scss', 'dist/css')

And then just add /mix.js to .gitignore.
Voila!

Took me quite a few hours too until I figured that sass() is causing it. Not sure if what's described in #1614 is the source of the problem, but if it is, it would be great if this could be fixed at the core.

Jizaz, this took a few hours of my life.
Sure, we could use standaloneSass like @JeffreyWay suggested however the library's css won't have auto vendor prefixes etc. Not cool.
Ok, so @RomainGoncalves you can fix this by adding a mock entry first.
mix.js('node_modules/laravel-mix/src/builder/mock-entry.js', 'mix.js')
  .react('src/index.js', 'dist/js')
  .sass('src/app.scss', 'dist/css')

And then just add /mix.js to .gitignore.
Voila!

Thank you soooo much! This was a problem with librarytarget var and window too. Works a charm.


Separate macro replacement from macro parsing

This allows you to replace any iterator of Token without having to have the original &str.
The core idea is to separate the preprocessor into 3 separate, nested iterators:

The innermost iterator (FileProcessor) deals with multiple files/lexers. If one included file runs out of tokens, it seamlessly goes on to the next one.
The middle iterator (MacroReplacer) performs macro replacement.
The outermost iterator (PreProcessor) deals with preprocessing directives. Additionally, because of the weird way I lumped the lexer and preprocessor together, it recognizes keywords and turns Token::Id into Token::Keyword as necessary.

The PreProcessor sometimes does not want to replace its tokens (e.g. for #if defined(a)). In this case, it reaches  through the replacer into the FileProcessor to drag out those tokens. Because of this, the MacroReplacer cannot have any idea of pending tokens, or its pending will conflict with the PreProcessor's  pending.
I want to support inputs other than FileProcessor (this is the whole point of the PR after all), but at the same time I need to be able to peek ahead in the input to see whether a token defined as a function macro is followed by a (. To support both these use cases, I add a new trait called Peekable; the intent is that users of rcc can use arbitrary iterators over Token by calling iter.peekable().
I'm not super happy with how tightly coupled the PreProcessor is to the FileProcessor, but that's a project for another day.
This also implements Debug for InternedStr to actually be useful, since I was looking at the debug output a lot.
Needed for https://github.com/rust-lang/rust-bindgen/pull/1782. Closes #436.
r? @pythondude325

I realized as I wrote up the PR that most of the PR description should be doc-comments, adding those now.

I don't expect much of the frontend work to be target-dependent (other than sizeof(int) and that sort of thing). It's changes to the backend that are much more likely to break on different platforms, especially linking.

Closing in favor of https://github.com/jyn514/rcc/pull/441


Name people

It should be possible (but not necessary) to give people's nicknames

i think this is done


Eliminate side effects from importing loadStripe (testability)

We would like to be able to mock out loadStripe during our unit tests, which run in a restricted, containerized CI/CD environment; however, simply importing loadStripe has side effects because stripePromise is created immediately when it's imported.  The TypeScript doc recommends against side-effects in modules, and in this case it makes testing a pain because loadStripe cannot be mocked out.  Plus it's unexpected: Intuitively, loadStripe, sounds like a function/action that loads the stripe script, when in fact it's a wrapper around Promise instance.
Unit testing would be simplified if loadStripe were a mockable function that loaded the stripe script on demand.
As a side question, using the current version of stripe (1.3.0), what is the proposed way to unit test code that depends on Stripe.js without making HTTP and XHR requests?  How can this be mocked out?

Sorry for the late reply.
Loading the stripe.js script as a side-effect is by design to enable Stripe's fraud prevention.
Is there a reason you cannot mock the entire @stripe/stripe-js module instead of trying to import the original and just mock its loadStripe function? The way to do this is highly dependent on the testing framework you're using.
Unfortunately there isn't a good way to realistically mock Stripe.js itself, whose whole purpose is to create iframes loaded from a hosted server, and proxy API calls through those iframes. Is there something in particular you'd want the mock to be besides an object with the shape of the Stripe instance, but empty implementations?

No problem on the late response.  This was actually a deal breaker for us so we moved away from using this module.
"[...] by design to enable Stripe's fraud prevention."  Sure, I understand the reason, but recommending that users either insert a <script> tag or call loadStripe() in top-level code (e.g. in a root module) would make the code testable.  The side-effects are, IMHO, overly protective and make dependent code un-testable (or at best, difficult to test).
"Is there a reason you cannot mock the entire @stripe/stripe-js module [...]?" Yes.  Namely because that would involve hooking into the module loading system or something equally duck-punch quail-kick hacky.  FWIW we're using Jasmine, which is the default for Angular.
At a minimum, it would be nice if the documentation provided a suggesting for testing code that depends on Stripe.js without making HTTP/XHR requests, as that may not be possible in a CI/CD-type environment.
As an aside, while I appreciate the libraries and robust documentation that Stripe offers, this integration has been abrasive.  There's no clear path for Angular developers to follow, and as a framework that puts testing in the forefront, this module's side-effects break the paradigm of injectable, mockable services.  In my opinion, that's a driving reason for using one of the two external Angular libraries for Stripe--ngx-stripe and stripe-angular--or rolling your own (which my team did).  Neither of those aforementioned modules uses @stripe/stripe-js, by the way; rather, both opt to use the external types, @types/stripe-v3, and load Stripe manually, which is testable.

We definitely want to make sure we don't prevent people from having tests when they use this package. We'll look into solutions, and improving our documentation on that subject.
I'm sorry your integration experience with Angular wasn't smooth. This package is pretty new and the two main goals were first party types and module support to improve the integration experience with front-end frameworks. While we first focused on React, we're looking at more officially supporting other frameworks, as well as web components.
I'll re-open to track the testability story.

Had similar issues (but not specifically with testing; just not wanting to have the module automatically impose itself on my environment), and got around it with a few tweaks to src/index.ts Specifically IIRC just need to modify stripePromise so it returns a function which returns the Promise, rather than the Promise directly, which causes the auto-insert:
const stripePromise: () => Promise<StripeConstructor | null> = () =>
	Promise.resolve().then(() => {
        ...

I get that autoloading matters to Stripe a lot because of the highly valuable data stream it provides, but not making it opt-in doesn't look very good, especially to engineers who tend to be quite critical of such things.

@benbotto, we've just released v1.4.0. The release includes an alternative import path, @stripe/stripe-js/pure which will delay loading the Stripe.js script until loadStripe is first called:
import {loadStripe} from '@stripe/stripe-js/pure';

To be clear, there is still state / side-effect, but it's when calling loadStripe() for that import path, not simply when importing the module. If you mock the loadStripe function without calling its original implementation, you should be able to run your tests fully side-effect free.
Let us know if this works for you!

Hopefully the pure entrypoint solved the problem. Please re-open if there are still issues mocking the package.


Envoy responding with errors despite correct config in config_dump endpoint

We (@astrieanna and I) are running scalability tests of Istio on GKE clusters. Our current results indicate that there's sometimes a significant delay between istio configuring Envoy and Envoy (specifically ingress gateways) successfully serving traffic based on that configuration.
Our Question
We're wondering why there's such a discrepancy between when envoy's config_dump shows a dynamic route configuration and when we stop seeing 404s for that route. This feels like a discrepancy between what config_dump gives us and how Envoy is actually behaving.
We're also interested in advice on what other information we could capture to make debugging this easier, or alternative ways to configure Envoy to help with this issue. For context, scaling the Istio control plane is pretty much our job right now, so we'd love to hear your advice 😄
Our Setup
In our test we deploy 4,000 pods with services, then every 10 seconds we create a virtualservice (which becomes a dynamic_route_config) pointing to one of our applications. We then curl the route constantly until it comes up, record the time, then curl it for a few more minutes and record the last time we see an error.
Parallel to that, we monitor the list of hostnames that the gateways know about (via dynamic_route_configs[].route_config.virtual_hosts[].name from /config_dump). We record the first time a hostname appears in a given gateway's configuration, so we have a complete picture of how long it takes for configuration distribution to happen.
Summary of Results
Here are the graphs from our most recent test on 240 nodes with 80 ingress envoys (each sharing a dedicated node with a single Istio Pilot).

The lines are the max (red) and median (blue) for the latency between the creation of the virtualservice (the kubectl apply) and one of these events:

First Gateway - first time a hostname appears on any gateway
First Success - first time a curl succeeds
Last Error - last time a curl fails
Last Gateway - last time a hostname appears on any gateway for the first time

Appendix: Full Results
Summary Results (which is where the above image is from)
We also have separate pages for each of the three runs that are summarized on that main page.

Run 0
Run 1
Run 2

Thanks!
/cc @rosenhouse @howardjohn

Are the routes served using RDS or inline using LDS? If they are served using LDS you are likely looking at connection drain time.

I'm pretty sure Istio Pilot pushes routes using RDS. The listeners are already present when the routes are pushed.

Sorry than not sure off the top of my head. I would ask the Istio team to investigate.

The istio team directed us here, since it appears that Envoy has configuration but isn't acting on it.

Not sure which version of Istio and Envoy you are running, but FWIW, Envoy had a bug https://github.com/envoyproxy/envoy/issues/7939 that used to show the rejected config instead of last applied config at some point. Based on what you are describing here, it seems config_dump might be showing rejected config?

We're using Istio 1.4.2 which from what I can tell is using Envoy v1.12.1, and that version was cut after the resolution of that issue.
Also, since the config does eventually get implemented I don't think it's rejected, unless there are reasons Envoy might reject configuration other than the validity of the configuration itself.

This remains an issue. Stale bots are bad practice.

We found that the result of 404 errors is that ClusterLoadAssingments (endpoints configured via EDS) are not yet ready for the given cluster we want to reach out hence causing 404 errors. Those endpoints are not shown in /config_dump endpoint and only in /clusters which we didn’t monitor.


Fix min and max timestamp on 32-bit machines

R: @aaltay

From travis:
************* Module apache_beam.coders.coders_test_common
W: 22, 0: Unused import sys (unused-import)
************* Module apache_beam.examples.complete.top_wikipedia_sessions
C:132, 0: Line too long (82/80) (line-too-long)
************* Module apache_beam.transforms.timeutil
W: 26, 0: Unused import sys (unused-import)

Should pylint run in jenkins?

LGTM, thank you.

@dhalperi We should run pylint in jenkins. It is already running in post-commit job. It will be part of pre-commit jobs once we have anything running in jenkins. It will require #537 or a new pre-commit job.

Thanks. R: @dhalperi

Looks like it's been merged. Manually close at will.


multi_caching checking all caches in series, even if value is found in first cache

This seems like a pretty large performance hit, especially since it doesn't appear to be needed.
The code in question:
https://github.com/BryanDonovan/node-cache-manager/blob/master/lib/multi_caching.js#L80
It seems like relying on isCacheableValue to determine if we should return the result immediately doesn't make too much sense. Do we really care if the value is cacheable at this point? We just found it in the cache and we should defer to the set function to decide if it should be cached or not.
I've been doing some profiling and this popped out. I may raise a pull request if my testing proves this to be a net gain.

Yeah, it's possible that that could be removed.  I can't remember why it's there honestly.  I doubt it's a big performance hit, especially if redis, etc. is taking a few milliseconds anyway.

I probably have a special use case that can be found here:
https://github.com/dial-once/node-cache-manager-redis/issues/19
In my testing it effectively doubles the time it takes to get something from the cache, but that's because my multi cache is a cluster of redis machines behind a load balancer, and then the master of that cluster. This way I can write to the master, but read from any of the machines behind the load balancer.
(BTW, thanks for the quick response!)

Are you using the neverCache function (or equivalent) as your isCacheableValue function?

Yes, I am for the first cache in my multiCache.
My intention is to check the load balancer first, break out of the search for the item, and then write it only to the master node.
I raised a pull request:
https://github.com/BryanDonovan/node-cache-manager/pull/42

Oh, the reason we use isCacheableValue in that spot is because if, for example, null is a cacheable value, and it's found in the first cache, we don't want to keep checking the other caches.  Instead, we want to return null right away.

That use case makes sense, but if one is caching larger values (like a serialized object) in the cache, wouldn't you want to return that as soon as it's found instead of looking for it again?
The check for null would be really fast, even if it has to look for it in a different cache.
I can see the value of what you're saying, though. Maybe we need another function to determine if the null is a valid value?

Hmm.. I'm probably not following completely.   The intention is that if a value is found, like a large serialized object, it should return it immediately and not look for it in other caches.  In that case your isCacheableValue function could be function(value) { return !!value; } or something like that.

OK, I think I see what you're saying now.  Not sure how to get around that, other than perhaps having two functions, isCacheableValue and isReturnableValue.  By default isReturnableValue could just be set to isCacheableValue.  Not sure if that solves anything though.

Yes, that is what I was suggesting. I'll take a stab at it and update my PR.

@BryanDonovan finally got around to getting those unit tests in.

Sorry @3choBoomer -- I didn't see your comment here. Can you merge the latest from upstream/master and add the same isReturnableValue logic to lib/caching.js as well please? Then I think it's good to go.

Fixes by #203


Update edge-zones-overview.md

@m0nikama : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off  I have spoken with Monika. Looks good to me.

@cherylmc: I'm sorry - only the author of this article, @ganesr, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.


Better support for non-conforming meshes

A non-conforming mesh is a mesh where the nodes of one edge may end in the middle of another edge or face. These happen in block structured AMR meshes and in unstructured meshes being used for general adaptivity. Nodes in such meshes are often called hanging nodes. Data producers can produce continuous fields on such mesh under piecewise linear interpolation by constraining dofs on hanging nodes. However, Visit's expression system cannot, in general, reproduce this continuity for expressions involving the original continuous fields in nonlinear ways. The picture below shows the issues. Left: x (blue) and y (red) contours of continous components of a vectorMiddle: Contour plot of the magnitude of the vector as computed by VisIt's expression system.Right: Contour plot of the magnitude of the vector as computed by data producer and with same continuity constraint enforcement as in original fields, namely that the dofs at the hanging node must be the average of the dofs at the ends of the longer edge it shares. There are a couple of options... Here are a couple of options to consider going forward... Define 'constrained' nodes for a ucd var in Silo This would be an optional object to associate with a field in Silo such that it defines, for each node, whether the node is constrained in some way and, if so, the constraint expression. So, for the case you had, the constraint would look like 0.5Ni+0.5Nj where Ni and Nj are node ids in the mesh. If the constraints for all fields on the mesh would be the same, we can associate the constraints with the ucdmesh object and not with ucd vars These constraints could then be applied by any expression VisIt performs resulting in continuous fields. Create a 'conforming mesh' operator that takes a non-conforming mesh and turns it into a conforming mesh Given no information, it would have to find nodes that are "hanging" nodes and then subdivide neighoring zones to make them conforming. Finding hanging nodes might be difficult in general. So, this might require that the input mesh at least be annotated in some way to indicate which nodes in the mesh are nonconforming This already has some precedent in VisIt where, for example, we take arbitrary polyhedral zones and subdivide into zootype zones.
-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.
Ticket number: 2899
Status: Pending
Project: VisIt
Tracker: Feature
Priority: Normal
Subject: Better support for non-conforming meshes
Assigned to: -
Category: -
Target version: -
Author: Mark Miller
Start: 08/29/2017
Due date:
% Done: 0%
Estimated time:
Created: 08/29/2017 02:56 pm
Updated: 09/19/2017 06:44 pm
Likelihood:
Severity:
Found in version: 2.12.3
Impact: 3 - Medium
Expected Use: 3 - Occasional
OS: All
Support Group: Any
Description:
A non-conforming mesh is a mesh where the nodes of one edge may end in the middle of another edge or face. These happen in block structured AMR meshes and in unstructured meshes being used for general adaptivity. Nodes in such meshes are often called hanging nodes. Data producers can produce continuous fields on such mesh under piecewise linear interpolation by constraining dofs on hanging nodes. However, Visit's expression system cannot, in general, reproduce this continuity for expressions involving the original continuous fields in nonlinear ways. The picture below shows the issues. Left: x (blue) and y (red) contours of continous components of a vectorMiddle: Contour plot of the magnitude of the vector as computed by VisIt's expression system.Right: Contour plot of the magnitude of the vector as computed by data producer and with same continuity constraint enforcement as in original fields, namely that the dofs at the hanging node must be the average of the dofs at the ends of the longer edge it shares. There are a couple of options... Here are a couple of options to consider going forward... Define 'constrained' nodes for a ucd var in Silo This would be an optional object to associate with a field in Silo such that it defines, for each node, whether the node is constrained in some way and, if so, the constraint expression. So, for the case you had, the constraint would look like 0.5Ni+0.5Nj where Ni and Nj are node ids in the mesh. If the constraints for all fields on the mesh would be the same, we can associate the constraints with the ucdmesh object and not with ucd vars These constraints could then be applied by any expression VisIt performs resulting in continuous fields. Create a 'conforming mesh' operator that takes a non-conforming mesh and turns it into a conforming mesh Given no information, it would have to find nodes that are "hanging" nodes and then subdivide neighoring zones to make them conforming. Finding hanging nodes might be difficult in general. So, this might require that the input mesh at least be annotated in some way to indicate which nodes in the mesh are nonconforming This already has some precedent in VisIt where, for example, we take arbitrary polyhedral zones and subdivide into zootype zones.
Comments:
After discussing this with Cyrus, his suggestion was that we treat an element that has hanging nodes attached to it as an aribtrary polyhedral element and then deal with it like we would any arbitrary polyhedral element, namely decompose it into ucd zoo elements. That would have the effect of taking the original nonconforming mesh and making it a conforming mesh. So, the question is, what minimal information is required for data producer to add so that such an operation can be easily implemented?For each hanging node in the mesh, the data producer is required to indicate the topological entity (edge in 2D / edge or face in 3D) it is intended to be connected with. In the example here, node 4 is the hanging node and the data producer, in addition to writing the ucd mesh and ucd zonelist, would be required to write an additional, connectivitylike, object where each hanging node is attached to its respective face or edge. If a hanging node is intended to be attached to an edge, as in the 2D example here, the data producer would have to indicate that. Likewise, in 3D, if a hanging node is intended to be attached to a face, the data producer would have to indicate that. But, in the example here, we're dealing with a case of just one level of refinement difference between neighboring elements. What if there are more levels of refinement? Then, along the long edge, there would be many hanging nodes. If for each such node, all we know is the bigger topological entity they are intended to be attached to is that sufficient?So, for the simple example here, if nodes are numbered 0,1,2 across the bottom, 3,4 in the middle and 5,6,7 across the top, the additional information looks like...

2898_non_conforming.C.zip
2898_non_conforming.session.zip
2898_non_conforming.silo.zip


Create a database function to provide information about "schema-mapping"

see the discussion here https://github.com/3dcitydb/3dcitydb/issues/162#issuecomment-1349633087

Schema mapping information has been added to the datatype and objectclass tables with e17ea7947fce1a2a0c56dd927a6cad15a2c17db3.


Not verified by Google error.

Google no longer allows this App. Now get the following error whenever I try to install the App:
"Sign in with Google temporarily disabled for this app
This app has not been verified yet by Google in order to use Google Sign In."

Hello Robert and thanks for the heads up.
I will have a look... 👀

The migration guide from Google is really confusing... I've published the application again and I'm waiting Google's approval. I will let you know when they come back me 😀

Thanks!

Any update?

I've received an email from Google, they are doing a review (again).
Hopefully it won't take long and the add-on will soon be available.

@RobertNL After much back and forth, the add-on should be available (and verified by Google). Could you please confirm that it's effectively the case ?

Still getting same error.
"Sign in with Google temporarily disabled for this app
This app has not been verified yet by Google in order to use Google Sign In."
I tried downloading another Docs add-in and it worked fine.
I'd still like to get this tool!

I found something in the Google Cloud console... I will send a request to get verified.

it seems to be a really nice use case. wish you could get Google to verify this app so we can use it.

I think it's now mandatory to provide a web page with the general terms and conditions and probably the privacy policies.
I will try to setup a simple page this week or next week 😉

Thanks! Love to try this out.
Robert Thomas
Innovation Program
Open Geospatial Consortium
Ph: +1<PHONE_NUMBER>
The OGC: Making Location Count...
www.opengeospatial.org
On Wed, Sep 4, 2019 at 1:38 PM Guillaume Grossetie<EMAIL_ADDRESS>wrote:

I think it's now mandatory to provide a web page with the general terms
and conditions and probably the privacy policies.
I will try to setup a simple page this week or next week 😉
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Mogztter/asciidoc-googledocs-addon/issues/34?email_source=notifications&email_token=AKEULHUG2D6ZMBKGUU237X3QH7MQXA5CNFSM4G67ZP2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD54DLHQ#issuecomment-527971742,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKEULHQKLS7WVSV5WROZU53QH7MQXANCNFSM4G67ZP2A
.

After a dozen email exchanges the add-on is now verified :tada: :tada: :tada:
You will need to signin with your Google account and then Allow the add-on to read your Google Docs document:

Let me know if it works for you.

Excellent news :+1: Will be so much easier to incorporate casual contributions and early drafts now!

I'm closing this issue as I think everything is working fine now.


Support remappings and relative imports

Fixes #3
Fixes #7
Hello, a Rust newbie here. I'm aiming to solve both previous issues but right now I'm getting unrelated errors testing against OpenZeppelin Contracts, mostly related to unsupported features such as assembly.
I'll make a better example and add it here for testing, but I'd appreciate comments.
Usage
Relative imports should work out of the box, while remappings should be specified by:
pyrometer [OPTIONS] <PATH>

Arguments:
  <PATH>

Options:
  -r, --remappings <REMAPPINGS>
  ...

Testing
I'm using the following setup for testing on a forge project:
src/
├── Counter.sol
└── Guarded.sol
lib/
└── openzeppelin-contracts/...
remappings.txt

running:
pyrometer ./src/Counter.sol --remappings ./remappings.txt

Where Counter.sol:
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.15;

import "./Guarded.sol";

contract Counter is Guarded {
    uint256 public number;

    function setNumber(uint256 newNumber) public {
        number = newNumber;
    }

    function increment() public {
        number++;
    }
}

Guarded.sol:
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.15;

import<EMAIL_ADDRESS>
contract Guarded is ReentrancyGuard {}

and remappings.txt:
ds-test/=lib/forge-std/lib/ds-test/src/
forge-std/=lib/forge-std/src/
@openzeppelin/=lib/openzeppelin-contracts/

Why reentrancy as an example?: It's the only one that worked with the current Pyromenter support. Feel free to suggest a more complex alternative

Output
Bounds: Bounds for function: function _nonReentrantBefore()
Bounds: Bounds for subcontext: _nonReentrantBefore() where:
  1. (_status != _ENTERED) == true

    ╭─[/Users/ernestognw/Documents/OpenZeppelin/contracts/lab/lib/openzeppelin-contracts/contracts/security/ReentrancyGuard.sol:56:44]
    │
 56 │ ╭─▶     function _nonReentrantBefore() private {
    ┆ ┆
 62 │ ├─▶     }
    │ │
    │ ╰─────────── Entry function call
────╯
Bounds: Bounds for function: function _nonReentrantAfter()
Bounds: Bounds for subcontext: _nonReentrantAfter()
    ╭─[/Users/ernestognw/Documents/OpenZeppelin/contracts/lab/lib/openzeppelin-contracts/contracts/security/ReentrancyGuard.sol:64:43]
    │
 64 │ ╭─▶     function _nonReentrantAfter() private {
    ┆ ┆
 68 │ ├─▶     }
    │ │
    │ ╰─────────── Entry function call
────╯
Bounds: Bounds for function: function _reentrancyGuardEntered()
Bounds: Bounds for subcontext: _reentrancyGuardEntered()
    ╭─[/Users/ernestognw/Documents/OpenZeppelin/contracts/lab/lib/openzeppelin-contracts/contracts/security/ReentrancyGuard.sol:74:69]
    │
 74 │ ╭─▶     function _reentrancyGuardEntered() internal view returns (bool) {
 75 │ │           return _status == _ENTERED;
    │ │           ─────────────┬────────────
    │ │                        ╰────────────── returns: "_status == _ENTERED" == true
 76 │ ├─▶     }
    │ │
    │ ╰─────────── Entry function call
────╯
Bounds: Bounds for function: function number()
Bounds: Bounds for subcontext: number()
   ╭─[./src/Counter.sol:7:5]
   │
 7 │     uint256 public number;
   │     ──────────┬──────────
   │               ╰──────────── Entry function call
   │               │
   │               ╰──────────── returns: "number" == 0
───╯
Bounds: Bounds for function: function setNumber(uint256)
Bounds: Bounds for subcontext: setNumber(uint256)
    ╭─[./src/Counter.sol:9:50]
    │
  9 │ ╭─▶     function setNumber(uint256 newNumber) public {
    ┆ ┆
 11 │ ├─▶     }
    │ │
    │ ╰─────────── Entry function call
────╯
Bounds: Bounds for function: function increment()
Bounds: Bounds for subcontext: increment()
    ╭─[./src/Counter.sol:13:33]
    │
 13 │ ╭─▶     function increment() public {
    ┆ ┆
 15 │ ├─▶     }
    │ │
    │ ╰─────────── Entry function call
────╯

Note
I don't feel comfortable about how many dependencies ethers_solc is bringing in, so I'm fine removing it as long as someone points me to an alternative.

Thanks so much for starting this! Ideally we don't bring in ethers-solc - its generally overkill for what we need and I am trying to keep dependencies down (ethers-core is even too heavy, and eventually ethers is likely to have a more stripped down primitive types crate).
The alternative is to just yoink out what we need from ethers-solc as I dont know of any other tooling, or roll our own from scratch. I lean toward not bringing all of ethers-solc, but as a stop gap to get the tool in a better position, I am okay bringing it and opening an issue to potentially remove it later

What's the most minimal code that you'd want from ethers-solc?

Considering what the implementation looks like right now, it's just a matter of using the code referenced by @lambda-0x here and some internal logic from RelativeRemapping as in here. Shouldn't be that difficult to replace, but I think it'll be eventually required to replicate Foundry's behavior.
I'll try to replace it if you agree @brockelmore, just wanted to confirm.

What's the most minimal code that you'd want from ethers-solc?

Realistically the only thing we need is dependency information - i.e. project root and remapping to my understanding. I dont foresee much more information needed as we need compilation artifacts or anything. I could be wrong there but really its not to the fault of ethers-solc here, just our use case for the repo is quite limited.
If you or anyone else thinks of why we might want pieces for compilation or post-compilation, I am definitely more open to using ethers-solc long term.

Considering what the implementation looks like right now, it's just a matter of using the code referenced by @lambda-0x here and some internal logic from RelativeRemapping as in here. Shouldn't be that difficult to replace, but I think it'll be eventually required to replicate Foundry's behavior.
I'll try to replace it if you agree @brockelmore, just wanted to confirm.

I guess ethers-solc actually out of the box supports both hardhat and foundry repos natively so that is a plus in that column. In my ideal world we have a foundry-dependencies crate that can load in from foundry style repos and a hardhat-dependencies crate for hardhat style repos. But maybe this is just the wrong approach and we should actually just bring in more of foundry things natively (but I want to limit our dependencies on foundry so that if foundry ever wants to take us as a dependency its trivial)
@gakonst would love your thoughts here

I guess ethers-solc actually out of the box supports both hardhat and foundry repos natively so that is a plus in that column.

I agree it's a valuable addition long term, but I decided to remove it so we can merge this and maybe add ethers-solc back in the future since I feel there are still some open questions I can't fully answer.
I can open an issue for that discussion if you like.


Add uWebSockets Install Scripts for openSUSE/Fedora

These are quite popular distributions among developers. It would be nice to have automated installation for them either.

Thanks for the suggestion @aoool - we do not plan to explicitly support these additional platforms at this time, but you are welcome to submit a pull request if you generate installation instructions for them.


fix the key==nil issue in the logs

Signed-off-by: Chen Jing<EMAIL_ADDRESS>

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@52f1fa0). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #78   +/-   ##
=======================================
  Coverage        ?   41.77%
=======================================
  Files           ?        6
  Lines           ?      888
  Branches        ?        0
=======================================
  Hits            ?      371
  Misses          ?      487
  Partials        ?       30

Flag
Coverage Δ

unittests
41.77% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


more scan jacrev/jacfwd bugs

This is a follow up of #711 (different error from #757):
import unittest
import numpy as onp
import jax.numpy as np
import functools

import jax
from jax.config import config; config.update("jax_enable_x64", True)
from jax.experimental import optimizers
from jax.test_util import check_grads

def harmonic_bond(conf, params):
    return np.sum(conf * params)

opt_init, opt_update, get_params = optimizers.sgd(5e-2)

x0 = onp.array([0.5], dtype=onp.float64)
params = onp.array([0.3], dtype=onp.float64)

def minimize_structure(test_params):
    energy_fn = functools.partial(harmonic_bond, params=test_params)
    grad_fn = jax.grad(energy_fn, argnums=(0,))
    opt_state = opt_init(x0)

    # use lax.scan, way faster compilation times.
    def apply_carry(carry, _):
        i, x = carry
        g = grad_fn(get_params(x))[0]
        new_state = opt_update(i, g, x)
        new_carry = (i+1, new_state)
        return new_carry, _

    carry_final, _ = jax.lax.scan(apply_carry, (0, opt_state), np.zeros((75, 0)))

    trip, opt_final = carry_final

    assert trip == 75

    return opt_final

initial_params = 0.5
minimize_structure(initial_params)

def loss(test_params):
    opt_final = minimize_structure(test_params)
    return 1.0 - get_params(opt_final)[0]

loss_opt_init, loss_opt_update, loss_get_params = optimizers.sgd(5e-2)

jax.grad(loss, argnums=(0,))(initial_params) # okay
jax.jacrev(loss, argnums=(0,))(initial_params) # AttributeError: 'JaxTuple' object has no attribute 'broadcast'
jax.jacfwd(loss, argnums=(0,))(initial_params) # TypeError: <class 'tuple'>

There were a few dumb bugs in the utility functions in batching.py. Luckily they were written pretty defensively and have checks for their assumptions, so we got pretty clear errors.
That said, I'd like to go through and rewrite all the utility functions in that file!

Thanks for resolving this!


Modify how we present recs

Recommendations should be focused on the paper first. In the future, we will unify rec entries from multiple people you follow if they recommend the same item in the same cycle feed.
Concretely, lets re-arrange the elements to the rough mockup below (the current style is great, the mockup is just for arrangement). We only need the date on a rec (i.e., "Yilun Hua recommended on 2/1/24:...") when there are multiple dates on a page (i.e., user profile), but not when there is a single date (i.e., a feed for a specific cycle).

Sounds good. Will create another pull request to resolve this issue!

Sounds Good. But let's prioritize that. This is actually a very important design decision. Thanks!

Sounds Good. But let's prioritize that. This is actually a very important design decision. Thanks!

Ok. Will work on this this week.

While we are doing this, we should make sure this visual bug doesn't repeat. Happens when names need to wrap

From top to bottom:

Rec Card (without showing the date)  (in /feed page)
Rec Card when multiple people rec the same paper  (in /feed page)
Rec Card at user profile page (show the date)

@yoavartzi let me know what you think about the new design!

This is really great!
I suspect in the future we might want to make the lower half a bit more compact, but that will be an issue only if we get more traffic and figure out a few more features.
Let's deploy this. Thanks!


Include steps to build/run locally

The executable in the releases is a unix executable and is not runnable everywhere.
Include requirements and steps so that we can build the project locally.

Are you trying to run it on a windows? I'll update the readme in sometime, but to build it locally -

clone the repo
pip install the dependencies in the requirements.txt file (with or without a virtualenv)
and run the code using the command: python postman_doc_gen.py [collection.json]

You will need python 3 to run the code

Thanks, will try

Tried to follow what you mentioned. Following is the result.
> python postman_doc_gen.py collection.json -o ./
Traceback (most recent call last):
  File "postman_doc_gen.py", line 30, in <module>
    d.generate_doc(args.collection, args.env, args.out)
  File "C:\...\postman-doc-gen-0.1.0\postman_doc_gen\document_g
enerator.py", line 42, in generate_doc
    self.add_items(self.side_tree, json_collection)
  File "C:\...\postman-doc-gen-0.1.0\postman_doc_gen\document_g
enerator.py", line 134, in add_items
    self.add_apis(item)
  File "C:\...\postman-doc-gen-0.1.0\postman_doc_gen\document_g
enerator.py", line 151, in add_apis
    api.examples = self.get_examples(api, item.get(constants.RESPONSE, []))
  File "C:\...\postman-doc-gen-0.1.0\postman_doc_gen\document_g
enerator.py", line 171, in get_examples
    api_example.request_body = api_example.request_body + '\n' + res.get(constan
ts.ORIGINAL_REQUEST).get(
TypeError: can only concatenate str (not "NoneType") to str

I'll take a look at this. This is un-related to the original issue and should ideally have been created as a separate issue.

@hitswa I just pushed out a new release, can you confirm if the bug is resolved for you?
https://github.com/karthiks3000/postman-doc-gen/releases/tag/v1.0.1


Uncaught (in promise) TypeError: Cannot read property 'transaction' of null

Hi everyone, I am getting this error in dev console for quite some time. Doesn't seem to cause other problem but it's bit annoying. I did tried it in safe mode on latest Atom.
Uncaught (in promise) TypeError: Cannot read property 'transaction' of null(…)dbPromise.then.db @ /opt/atom/resources/app.asar/src/state-store.js:31

Steps to Reproduce

Open atom --safe and check console

Expected behavior: [What you expected to happen]
No error in console.
Actual behavior: [What actually happened]
Error in console.
Versions
Did happen for longer time right now using 1.7.3
Elementary OS Freya (based on Ubuntu 14.04LTS)

Ok, and does this happen with every project or just a specific one?

Seems to happen to every project I tried so far. Also I've noticed an error
Could not connect to indexedDB
 Eventbubbles: true
cancelBubble: false
cancelable: true
currentTarget: null
defaultPrevented: false
eventPhase: 0
isTrusted: true
isTrusted: true
path: Array[0]
returnValue: true
srcElement: IDBOpen
DBRequesttarget: IDBOpen
DBRequesttimeStamp:<PHONE_NUMBER>123
type: "error"
__proto__: Event
dbOpenRequest.onerror @ /opt/atom/resources/app.asar/src/state-store.js:16

/cc @as-cii

Thanks for the report, @Trudko! 🙇
We've seen this problem a couple of times now and it seems like, for some reason, the underlying database gets corrupted. Some other user experienced this after installing beta side by side to Atom stable, so I wonder if this is what's happening in this case too. @Trudko: have you (ever) installed beta alongside stable? If so, we need to address beta installation to prevent this issue from happening again (maybe by providing a different database path for the different kinds of installations).
As a workaround, does opening Atom with the --clear-state-store argument fix the issue? If it doesn't, can you try deleting the /Users/<your user>/Library/Application Support/Atom/IndexedDB folder and re-open Atom again? (this path might be different in case you're not using OS X)
Thanks again! ✨

Hi @as-cii  :bow:
--clear-state-store (with or without --safe) didn't work but deleting ~/.config/Atom/IndexedDB seem to fixed the issue although I still have an error Could not connect to indexedDB. Btw I did't installed beta ever.
Thank you for your time and support!

I enabled "Capture async stack traces" in the atom debug panel and got the whole stack trace:
/usr/share/atom/resources/app.asar/src/state-store.js:31 Uncaught (in promise) TypeError: Cannot read property 'transaction' of null(…)dbPromise.then.db @ /usr/share/atom/resources/app.asar/src/state-store.js:31Promise.resolve (async)Promise @ /usr/share/atom/resources/app.asar/src/state-store.js:28save @ /usr/share/atom/resources/app.asar/src/state-store.js:27(anonymous function) @ /usr/share/atom/resources/app.asar/src/atom-environment.js:990module.exports.AtomEnvironment.saveState @ /usr/share/atom/resources/app.asar/src/atom-environment.js:983(anonymous function) @ /usr/share/atom/resources/app.asar/src/atom-environment.js:309

For me this fires exactly 2 seconds after I click on something in editor(I have hyperclick with js-hyperclick). This is certainly not an issue with js-hyperclick or hyperclick, because these two plugins run fine on my other machine.
Will try deleting my indexedDB folder.

We've seen this problem a couple of times now and it seems like, for some reason, the underlying database gets corrupted. Some other user experienced this after installing beta and stable side by side, so I wonder if this is what's happening in this case too.
…Have you (ever) installed beta alongside stable? If so, we should probably start using a different database path for the different kinds of installations.

As a workaround, does opening Atom with the --clear-state-store argument fix the issue?  If it doesn't, can you try deleting the /Users//Library/Application Support/Atom/IndexedDB folder and re-open Atom again?

@as-cii, I'm using beta alongside with stable, I also started to experience this problem lately (currently using v1.9.9 and v10.10.0-beta7 on MacOSX 10.10.5 Yosemite).
Neither --clear-state-store nor deleting the IndexedDB folder works, it solves the problem for the first app restarted, but appears again in the second app (reproducible for both stable and beta started last).
Btw, the first exception thrown prior to the reported exception here is a Could not connect to indexedDB error, which was also reported in #11254

I've found a workaround, by starting the Atom-beta app with it's own user-data dir:
open 'Atom Beta.app' --args my/project/dir --user-data-dir ~/Library/Application\ Support/AtomBeta


django 1.8 validation error

I've tried your example data are displayed as expected, but on saving I got this error:
File ".virtualenvs/myproject/lib/python2.7/site-packages/django/forms/formsets.py", line 97, in management_form
code='missing_management_form',
ValidationError: [u'I dati del ManagementForm sono mancanti oppure sono stati manomessi']

my mistake, sorry!
works fine!!


Remove related_policies links check for Speeches

https://trello.com/c/JNmI4cqs/612-speech-migration-3-write-sync-checks-and-run-it-for-speech
PublishingApi::SpeechPresenter doesn't present related_policies links as these
are keyed as policies so don't check for them.

Apparently this is the opposite of true. Closing.


Don't load default values when opening form in edit mode

As it messes up for example editing old transactions and balances.

Still happening it seems


Question: Nanostores/query test documentation

Please see this question:
https://github.com/nanostores/query/issues/17

Closing this in favor of the issue in the nanoquery repo.


Add VR badges

added in https://github.com/inttter/md-badges/commit/6f637bc060516cc9b10b8a3c52a51f8d5fca593c


Update debug action related to desync source searching

I've made some changes to the debug tool back when 1.5 originally released, but haven't bothered finishing it up. I've decided to also include a special window for it, which allows to configure the search tool. Took around half a day to make the dialog and do some final touches. Anyway, included changes:
The debug tool option now opens a window where you can configure desync source search options. It allows you to select specific elements you want to search, if you want to search mods and/or vanilla types, as well as select if you want to log all checked types. There's also 2 buttons to select 2 presets, basic and full, and the dialog by default selects the basic preset. The basic preset was tailored towards a player who may not fully understand what to look for in the other options, especially since the majority of what they'll report will be false positives.
Since the selection of logging of all classes is now inside the dialog, one of the 2 debug actions was removed as it was pointless.
Added NonBasicAttribute and applied it to all options in the enum that are, as the name suggests, non-basic. It's used for the selection of basic options in the dialog, as those options in particular will be skipped.
Added a LongEvents options, which will log every single long event. Majority of them will be false positives, but may be worth investigating. They can cause issues if they are asynchronous or if they are queued during the game loading (hosting the server), as they end up being queued twice for host.
Removed all references of Biomes Core special terrain in non-ticking updates, as those were removed some time ago (back in 1.4).
Removed the check to MaxFoundStuff that would end checking a method early, as it was extremely unlikely that a single method would have all the elements in it. It was just a waste of computational power, even if a minor one. (Also it stopped working since addition of PatchedSyncMethods, as that one was checked in a different place, so the max value would have to be lowered by 1 to compensate).
The LogUnpatchedStuff now accepts more arguments that determine what it should do. It also has a few extra checks early if the input data is correct, even if the window should already provide correct data (just in case of some weird shenanigans).
Renamed unsupportedTypes to unsupportedNamespaces, as that name is more correct. Prepatcher and Prestarter namespaces were included, as Prepatcher is going to be commonly used with MP and causes a few false positives. FisheryLib and PerformanceFish were also included, as operating on those crashes RimWorld. Also removed the note about RW namespaces, as RW itself can now be checked as well.
The dictionary containing the lists of all found issues now only include entries for stuff that can be found, so all operations performed on it generally use TryGetValue for safety.
Added a few calls to Enumerable.Distinct() to make sure we don't have duplicates and don't operate on duplicates.

Also an image for the curious of how this looks.


[Feature request] Removing fence related plugin in @vuepress/markdown

Clear and concise description of the problem
Our built-in plugins about code fence are breaking shiki highlighter, e.g., shiki has an own implementation about higlight lines, and shiki's twoslash is powerful
See https://plume.pengzhanbo.cn/guide/markdown/experiment/#开启功能 as an example, the community is patching our official pacakge to bypass this.
Suggested solution
Move the highlight lines and line number part into @vuepress/plugin-prismjs and @vuepress/plugin-shiki so that users can do more things with shiki and do not break current prismjs behvaior.
Alternative
No response
Additional context
I am planning to migrate the default highlighter to shiki for theme default.

A crucial missing parameter is at codePlugin/codePlugin.ts#L76 where the third argument of options.highlight(code, lang, meta) should be passed as token.info instead of an empty string. Some transformers when using shiki can be controlled based on token.info.

When using twoslash with VuePress, the line numbers are not functioning properly. This is because twoslash inserts additional xx\n into , causing miscalculation of extra lines due to line numbers being counted based on \n. In plugin-shiki, there is no control over line-numbers.

Can you open a pr for this? And maybe removing the line number plugin and implement it in plugin-prismjs?

Can you open a pr for this? And maybe removing the line number plugin and implement it in plugin-prismjs?

Currently, the adjustment plan involves removing the codePlugin from @vuepress/markdown and transferring its functionality to be independently implemented in @vuepress/plugin-prismjs and @vuepress/plugin-shiki.

You can open a pr to remove it, and use a patch to have plugin-prismjs and plugin-shiki implement the original feature, and we can then moving on upstream here.


Add few more conventions from ...

http://caliburnmicro.codeplex.com/discussions/256418

Done, reviewed them


cdc: limit scan task concurrency (#10262)

cherry-pick #10262 to release-5.1

What problem does this PR solve?
Close https://github.com/tikv/tikv/issues/10114
Close https://github.com/pingcap/ticdc/issues/1844
Problem Summary:
What is changed and how it works?
Limit CDC scan concurrency.
Related changes

Need to cherry-pick to the release branch

Check List
Tests

Unit test
Integration test
Manual test

Tested with TiCDC v4.0.13

v5.0.2
This PR

Release note
Fix OOM when TiCDC resumes a changefeed in a cluster that has lots of regions being captured.

/merge

/run-test

/run-test

/run-test
raftstore::test_region_heartbeat::test_region_heartbeat_report_approximate_size fails.

/run-test
cases::test_merge::test_node_failed_merge_before_succeed_merge fails

/run-test
raftstore::test_region_heartbeat::test_region_heartbeat_report_approximate_size fails.
https://ci.pingcap.net/blue/organizations/jenkins/tikv_ghpr_test/detail/tikv_ghpr_test/2105/pipeline

/run-test
raftstore::test_region_heartbeat::test_region_heartbeat_report_approximate_size fails.
https://ci.pingcap.net/blue/organizations/jenkins/tikv_ghpr_test/detail/tikv_ghpr_test/2106/pipeline/

/merge


New thermal surface and t init

Two main changes here to the thermal parts:

Switch from using the conditional mean for the TIR surface reflectivity initialization to using the cluster mean. The cluster is chosen based on the initial, heuristic inversion of the VSWIR.

Make the surface temperature prior variance a config parameter instead of being hard coded. Also make the emissivity assumed for the initial temperature estimate a config parameter too. Both parameters are also given default values that seem to work ok.

Thanks Jay! I'm fine with this.
Idea... In a future version maybe we can consider bringing the temperature part of thermal_surface.fit_params() upstairs into inverse_simple()?
Rationale: surface objects had been highly encapsulated and decoupled from any atmospheric modeling assumptions.  They really were only about the surface, with no atmosphere or instrument-related calculations.  However, the thermal fit_params() strategy uses radiance-at-sensor and atmosphere-related information, blurring the semantic distinction a bit.
Would you mind if, in a future version, I put the thermal_surface.fit_params() code into inverse_simple() with the other atmosphere & surface initialization heuristics?

I think that's a good idea, go for it! Another reason to do it is that the fit_params function call has a bunch of extra parameters that are always passed but only used when called on the ThermalSurface object. According to some guy on StackOverflow, that causes a bad "code smell". Moving the functionality as you described would help to clear the air, so to speak.

Sounds very good to me.  Is this something either of you has time to do in the immediate future (i.e. hold the PR till resolved), or should I convert this to an issue and merge the PR in?

I'll go ahead and self-assign a new issue.


arm64: cache: add arch_dcache_all()

Besides some small comments and usual nits LGTM. @JiafeiPan can you move the content of cache.S in here as well as C code? At least we have everything in one place.

Besides some small comments and usual nits LGTM. @JiafeiPan can you move the content of cache.S in here as well as C code? At least we have everything in one place.

Hi, @carlocaione, sure, but I would like to update it in another patch, thanks.