HBASE-24805 HBaseTestingUtility.getConnection should be threadsafe

This maintains most compatibility while changing the handling of the shared connection to threadsafe. Note about compat as comments.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 11s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 24s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 57s
master passed

+1 :green_heart:
checkstyle
1m 36s
master passed

+1 :green_heart:
spotbugs
2m 51s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 12s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 45s
the patch passed

-0 :warning:
checkstyle
1m 14s
hbase-server: The patch generated 1 new + 185 unchanged - 0 fixed = 186 total (was 185)

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
12m 16s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1.

+1 :green_heart:
spotbugs
3m  7s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 21s
The patch does not generate ASF License warnings.

39m 12s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2180/2/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2180

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle

uname
Linux 966f99a63380 4.15.0-101-generic #102-Ubuntu SMP Mon May 11 10:07:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 7c4d66a277

checkstyle
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2180/2/artifact/yetus-general-check/output/diff-checkstyle-hbase-server.txt

Max. process+thread count
84 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2180/2/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f) spotbugs=3.1.12

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 32s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 22s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 41s
master passed

+1 :green_heart:
compile
1m 19s
master passed

+1 :green_heart:
shadedjars
5m 33s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  1s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 17s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 23s
the patch passed

+1 :green_heart:
compile
1m 17s
the patch passed

+1 :green_heart:
javac
1m 17s
the patch passed

+1 :green_heart:
shadedjars
5m 31s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 57s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 25s
hbase-common in the patch passed.

-1 :x:
unit
157m 16s
hbase-server in the patch failed.

185m 46s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2180/2/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2180

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux d242fb1ceff8 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 7c4d66a277

Default Java
1.8.0_232

unit
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2180/2/artifact/yetus-jdk8-hadoop3-check/output/patch-unit-hbase-server.txt

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2180/2/testReport/

Max. process+thread count
4418 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2180/2/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 31s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 31s
master passed

+1 :green_heart:
checkstyle
1m 33s
master passed

+1 :green_heart:
spotbugs
2m 49s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 37s
the patch passed

-0 :warning:
checkstyle
1m 10s
hbase-server: The patch generated 1 new + 185 unchanged - 0 fixed = 186 total (was 185)

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
11m 57s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1.

+1 :green_heart:
spotbugs
3m  8s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 22s
The patch does not generate ASF License warnings.

37m 40s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2180/3/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2180

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle

uname
Linux 78b164caeed5 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 7c4d66a277

checkstyle
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2180/3/artifact/yetus-general-check/output/diff-checkstyle-hbase-server.txt

Max. process+thread count
94 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2180/3/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f) spotbugs=3.1.12

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 35s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 22s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 14s
master passed

+1 :green_heart:
compile
1m 26s
master passed

+1 :green_heart:
shadedjars
6m 31s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  0s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 51s
the patch passed

+1 :green_heart:
compile
1m 29s
the patch passed

+1 :green_heart:
javac
1m 29s
the patch passed

+1 :green_heart:
shadedjars
6m 31s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  0s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
1m 26s
hbase-common in the patch passed.

+1 :green_heart:
unit
177m  5s
hbase-server in the patch passed.

208m 18s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2180/3/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2180

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 1a315ccbce1d 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 7c4d66a277

Default Java
1.8.0_232

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2180/3/testReport/

Max. process+thread count
4292 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 30s
the patch passed

+1 :green_heart:
compile
1m 35s
the patch passed

+1 :green_heart:
javac
1m 35s
the patch passed

+1 :green_heart:
shadedjars
6m 18s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 17s
hbase-common in the patch failed.

-0 :warning:
javadoc
0m 40s
hbase-server in the patch failed.

_ Other Tests _

+1 :green_heart:
unit
1m 43s
hbase-common in the patch passed.

+1 :green_heart:
unit
213m 34s
hbase-server in the patch passed.

245m 51s

Subsystem
Report/Notes

Docker
Client=19.03.12 Server=19.03.12 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2180/3/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/2180

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 387946ea8e86 4.15.0-101-generic #102-Ubuntu SMP Mon May 11 10:07:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 7c4d66a277

Default Java
2020-01-14

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2180/3/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-common.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2180/3/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-server.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2180/3/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-common.txt

javadoc
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2180/3/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-server.txt

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2180/3/testReport/

Max. process+thread count
2965 (vs. ulimit of 12500)

modules
C: hbase-common hbase-server U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-2180/3/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

I do not know why the precommit job on ci-hadoop ran multiple jobs for this PR, but in run number 2 this was the failure:
[INFO]
[ERROR] Errors:
[ERROR] org.apache.hadoop.hbase.client.TestFromClientSideWithCoprocessor5.testScanMetrics[1]
[ERROR]   Run 1: TestFromClientSideWithCoprocessor5>TestFromClientSide5.testScanMetrics:989 Did not count the result bytes expected:<60> but was:<180>
[ERROR]   Run 2: TestFromClientSideWithCoprocessor5>TestFromClientSide5.testScanMetrics:922 Â» IO
[ERROR]   Run 3: TestFromClientSideWithCoprocessor5>TestFromClientSide5.testScanMetrics:922 Â» IO

in run number three there were no failures.
Looking at the test ouput for TestFromClientSideWithCoprocessor5, I don't think there's enough detail to figure out what happened.
It looks like the final two were loss of ZK under load:
-------------------------------------------------------------------------------
Test set: org.apache.hadoop.hbase.client.TestFromClientSideWithCoprocessor5
-------------------------------------------------------------------------------
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 332.892 s <<< FAILURE! - in org.apache.hadoop.hbase.client.TestFromClientSideWithCoprocessor5
org.apache.hadoop.hbase.client.TestFromClientSideWithCoprocessor5.testScanMetrics[1]  Time elapsed: 33.18 s  <<< ERROR!
java.io.IOException: org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode = ConnectionLoss for /hbase/hbaseid
Caused by: org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode = ConnectionLoss for /hbase/hbaseid

If I had to guess I'd say in the first case maybe we have a retry mechanism that can recount scan metrics?
In any case I am reasonably certain these failures are not related to the test change here.

I do not know why the precommit job on ci-hadoop ran multiple jobs for this PR, but in run number 2 this was the failure

@busbey this was my doing, I did it for the same reason on test failure i.e "could not figure out if the test failure was relevant as per stdout and stderr" and hence thought of triggering another build.


[Bug Report] CarRacing car_dynamics.py TypeError

Describe the bug
Simply running the CarRacing-v2 environment will result in a TypeError for me.
The problem arises because in gymnasium/envs/box2d/car_dynamics.py line 177 causes :
w.joint.motorSpeed = dir * min(50.0 * val, 3.0) TypeError: in method 'b2RevoluteJoint___SetMotorSpeed', argument 2 of type 'float32'
So just casting it all to the same type, eg.
w.joint.motorSpeed = float(dir * min(50.0 * val, 3.0))
fixes it for me.
Same (?) for line 261 with
w.ApplyForceToCenter(
                (
                    p_force * side[0] + f_force * forw[0],
                    p_force * side[1] + f_force * forw[1],
                ),
                True,
            )

I just use float again, and it works, eg.
w.ApplyForceToCenter(
                (
                    float(p_force * side[0] + f_force * forw[0]),
                    float(p_force * side[1] + f_force * forw[1]),
                ),
                True,
            )

After applying float to these three lines, the environment works again.
As I have no deeper understanding of what is happening in the code, this is the simplest solution I could think of, but the real issue probably lies somewhere deeper.
Code example
import gymnasium as gym

env = gym.make("CarRacing-v2", render_mode="human")

observation = env.reset(seed=42)

for _ in range(1000):
    action = env.action_space.sample()
    observation, reward, terminated, truncated, info = env.step(action)

    if terminated or truncated:
        observation, info = env.reset()
        print("Done!")
        break

env.close()

System info
macOS Sonoma Version 14.6.1
python 3.9.13
pip list :
box2d-py             2.3.5
cloudpickle          3.0.0
Farama-Notifications 0.0.4
gymnasium            0.29.1
importlib_metadata   8.4.0
numpy                2.0.2
pip                  22.0.4
pygame               2.6.0
setuptools           58.1.0
swig                 4.2.1
typing_extensions    4.12.2
zipp                 3.20.1
Additional context
No response
Checklist

[X] I have checked that there is no similar issue in the repo

Downgrade numpy to 1.24, it is a NumPy 2.0 related issues

thank you for telling me that!i stucked in this problem for the entire afternoon!


Going back in the Inspector while editing a GridMap node makes it and the previous node selected

Godot version:
2db4942
Issue description:
Basically this:

Hi, I'd like to help. Could you specify steps to recreate the bug?

@vazzup Basically what's said in the title, select a GridMap node, go back in the inspector, using these:

And both the GridMap and the previous node will be selected.

Ok, thanks. Will look into it

Yes, it is also a bug in the master branch. Also, if there are multiple previous nodes, all of them get selected.

I'm looking at the editor_node.cpp file and I think the change will be around line no. 1476 in the _edit_current function.

Hi, after digging deep, I'm a bit stuck with this bug. I think the bug may be from the EditorInspector::update_tree function, but I can't say for sure. Can someone else please point me in the right direction?

I've also seen that this works with more nodes than just the gridmap node.

theres also strange behavior while debugging remote tree (which is running on android device),
When one select a node (in debugger) , other nodes will select itself randomly, and theres no way to stop it, thus no way to use this feature to debug / change properties in inspector at runtime, ect.
Its not easy to reproduce it on simple project with fiew nodes created in editor,
but it begin to appear in projects with higher count of nodes created at runtime.
Just mentioning it here, since it sounds similar, ...but perhaps i should make a new issue for this.

Hi! I'm able to reproduce the bug, but it doesn't seem to be related to GridMaps only. In my case, any node will cause this issue. It doesn't seem to influence functionality, however, since the inspector displays the correct Node and its properties. The only issue is that several nodes look highlighted. Additionally, the further you go back in history, the more Nodes get highlighted (once again, not influencing functionality, but aesthetics only).

Still valid in 4e0f31a
As mentioned above, this applies not only to GridMap, but also mixed-type nodes, e.g. when you select Node2D then Spatial, then go back and then forward (going back doesn't seem to trigger it), both get selected. Might be somehow related to #36291


Need to add support for W3C variant of WebDriver protocol

The W3C WebDriver spec is getting close to CR status, and some endpoints (notably GeckoDriver and EdgeDriver) will only support the new spec. There are some changes that will need to be made to this project to make it work as this transition is made, most notably:

responses no longer include a status field. Instead they include an error field with a text value if an error occurs.

The various low-level actions endpoints (e.g. keyboard and mouse actions) are no longer supported. Instead a single actions endpoint is defined that takes a message representing a sequence of keyboard, mouse, and touch screen actions.

Acknowledged. I will get to this soon, hopefully this week.

I'm working through this now.
Do you happen to know if there is a recommended way to interrogate the remote to decide on what dialect to use? I'd like to maintain compatibility to allow this client to be used by both Selenium 2 and 3 (for a period of time).
Otherwise, I can deduce W3C spec compliance from the presence or absence of particular methods. Or, I'll ask the Selenium folks.

See https://github.com/SeleniumHQ/selenium/blob/master/java/client/src/org/openqa/selenium/remote/ProtocolHandshake.java for how Selenium does this in Java.

That commit supports the latest nightly of Firefox through Geckodriver.
What I've learned is that adding W3C compatibility is more of a process than a single task.
I'll keep tabs on the issues linked there and continue to update this code.


Add Packit's statement on Source Git work for 2023/Q3

This is to be explicit about our priorities for the next quarter.

@lbarcziova @mfocko Can you please take another look?


Explicit device tensors

On-device initialization for Tensors
Checklist

[x] Confirmed that run-checks all script has been executed.
[X] Made sure the book is up to date with changes in this PR.

Related Issues/PRs
Covers renaming and related refactoring as it was agreed and described in #518
Changes
Allows for explicit creation of tensors on specific devices. All public interfaces (of layers, models, etc.) have been refactored accordingly, and now allow to specify a Backend::Device during initialization. Onnx macroses support generation of device-aware models too.
Testing
All the tests I could find and run are passing, including

cargo test
./run-checks.sh std
./run-checks.sh no-std
./run-checks.sh typos
./run-checks.sh examples

Hi!
@antimora @nathanielsimard I generally agree that something like init_default can be useful, but new_default... It is not very idiomatic to Rust naming conventions. In Rust, whenever you want to construct something with default settings, you simply implement Default trait, and create an instance by calling the default() method.
So, I propose to alter the naming. Again. Let's replace the vague _default suffix by _autodev. It hints at its purpose: automatic selection of device. And it has the same number of characters as _default, thus making it possible to do the refactoring more or less using a simple "find and replace" tool, without breaking code formatting.
Another decent names could be be

_autoloc (automatic location, to me sounds as neutral as _autodev),
_adevice (any device, hints at randomness)
_bestdev (the best device we can choose, implies the choice is not random)
_somedev (hits at an arbitrary choice of the device too)

but you can come up with something even better. What do you think?

Sounds good. My top preferences:

'_defaultdev'
'_devauto'
'_devdefault'
'_autodev'
'_devault'

@antimora Hi! All the changes you requested were implemented. Specifically:

I chose _devauto suffix as a replacement for the _default.
All modules that have their own weights now also have a init_devauto() method.
ONNX models now include new_devauto() method as well
All introduced *_devauto methods have at least one test covering them.

All the tests and checks I know of are passing.

@kpot, I don't think the new naming is correct. First, "automatic" is associated with something intelligent and not error-prone, so "auto device" isn't the same as "default device." Second, I don't think using dev for "device" is actually a good idea; it's normally used for development, and it will be very confusing!
However, I agree that using _default isn't the best naming convention, so let me propose something a bit radical: remove all functions with the default device! It will make the API smaller, and someone can always use Default::default() explicitly where it applies. I think the only place where it makes sense to use the default device is in tests, not in production code where it can cause device errors.
Enforcing users to specify the device where it's required is not a bad idea, even if it's more verbose.
The only functions where the default device could be used is when implementing the From trait. So someone could still use the following:
let tensor = Tensor::from([5.0, 10.0]);

I believe this could be used for most tests. What is your opinion, @kpot, @antimora, @louisfd?

@nathanielsimard Well, this was my original proposal too, to get rid of all the twin *_device methods and make them a new norm. Any constructor that internally creates some device-bound parameters must be given a device explicitly. Any half-measures like _devauto will inevitably lead to more bugs. So yeah, I support your suggestion. This will require a lot of refactoring within tests (yay, more refactoring!) but it's worth it.
@antimora Do you approve?

@nathanielsimard Well, this was my original proposal too, to get rid of all the twin *_device methods and make them a new norm. Any constructor that internally creates some device-bound parameters must be given a device explicitly. Any half-measures like _devauto will inevitably lead to more bugs. So yeah, I support your suggestion. This will require a lot of refactoring within tests (yay, more refactoring!) but it's worth it.
@antimora Do you approve?

Yes, I guess in the end it would be the right solution. So I approve it.
I appreciate your willingness to go through big changes and stand by the right decision. I myself had to scrap a big chunk of code during a Burn PR review a few times.

@kpot I think it would be easier to merge the PR right now as is and refactor the tests in other PRs. We only have to remove all occurrences of autodev in the codebase before deleting the functions. This way, it minimizes git conflicts as well as making the upcoming PR reviewable! What do you think, @antimora?

@kpot I think it would be easier to merge the PR right now as is and refactor the tests in other PRs. We only have to remove all occurrences of autodev in the codebase before deleting the functions. This way, it minimizes git conflicts as well as making the upcoming PR reviewable! What do you think, @antimora?

Yep. Lets go ahead and merge it!


How to map the 'val_1_vqa_result.json' with 'all_questions.json' for val set in pretrain.yaml?

'val_1_vqa_result.json' is the file produced after evaluation during training, and there are only 'question_id' and 'answer' for each item in it. How to map each item to those in 'all_questions.json' for val set in pretrain.yaml, so that I could check the val performance?
I also find that there are 21092 question-answer pairs in 'val_1_vqa_result.json', while 67578 question-answer pairs in 'all_questions.json' for val set in pretrain.yaml, the number does not match!


[ERROR:flutter/runtime/dart_vm_initializer.cc(41)] Unhandled Exception: PlatformException(SHARED_PREFERENCES_NOT_AVAILABLE, class c3.b isn't parameterized, sharedPreferences.get, null)

hello I hope you are well I find your plugin great and I am working on an application which requires notifications when I initialize the genial_notification plugin they work correctly in debug mode but when I use it in release mode I encounter this problem:
E/flutter (18712): [ERROR:flutter/runtime/dart_vm_initializer.cc(41)] Unhandled Exception: PlatformException(SHARED_PREFERENCES_NOT_AVAILABLE, class c3.b isn't parameterized, sharedPreferences.get, null)
E/flutter (18712): #0 StandardMethodCodec.decodeEnvelope (package:flutter/src/services/message_codecs.dart:651)
E/flutter (18712): #1 MethodChannel.invokeMethod (package:flutter/src/services/platform_channel.dart:334)
E/flutter (18712):
E/flutter (18712): #2 MethodChannelAwesomeNotifications.initialize (package:awesome_notifications/awesome_notifications_method_channel.dart:299)
E/flutter (18712):
E/flutter (18712): #3 NotificationService.initialzeNotification (package:reservoo/notification/notification_service.dart:8)
E/flutter (18712):
E/flutter (18712): #4 main (package:reservoo/main.dart:14)
E/flutter (18712):
E/flutter (18712):
and here is my code: void main() async{
WidgetsFlutterBinding.ensureInitialized();
await AwesomeNotifications().initialize(
"resource://drawable/flutter_logo",
[
NotificationChannel(
channelKey: 'basic_channel',
channelName: 'Basic notifications',
channelDescription: 'Notification channel for basic notifications',
),
],
debug:true
);
/Workmanager().initialize(
callbackDispatcher, // The top level function, aka callbackDispatcher
);/
SystemChrome.setPreferredOrientations([DeviceOrientation.portraitUp]).
then((value) {
initializeDateFormatting().then(() =>
runApp(
const reserve()
)
);
});
}
I need your help to resolve this problem please thank you!

Same here, on Flutter sdk 3.16.5,  compileSdkVersion 34, distributionUrl=https://services.gradle.org/distributions/gradle-8.0-all.zip

This breaks the app hard - it cannot start!

https://github.com/rafaelsetragni/awesome_notifications/issues/814#issuecomment-1850478345

@ndusart thank you a million times! this bug has absolutely killed my apps!


Implement NuGet restore for referenced workspaces

Currently, the nuget_fetch rule and the gazelle parser only parse nuget packages for the current workspace. This means that references to external workspaces will fail to build if they contain packages or target frameworks not used by the current workspace.
This was encountered in an e2e test of the runfiles implementation: the e2e/hello workspace does not reference netstandard2.1 but the runfiles library targets netstandard2.1 so the nuget_restore rule failed the build.
A workaround was implemented to hardcode the inclusion of the runfiles target_framework in nuget_fetch rule.

This could be made easier by enforcing the use of Directory.Packages.props


Should points be immutables?

To make Point immutable, we would just need to make the following method private:
https://github.com/bdelespierre/php-kmeans/blob/46e205156a92e1488edd06fc8e32ec30664a9467/src/Point.php#L27
Would it make sense for points to be immutable? Is there a way we benefit from this in terms of clarity or performance?
@battlecook what's your opinion on this?

Is there any reason to expose the function as public to change the values of points?

None actually.

I usually design as private unless there is a reason to make it public.

That's good practice!
Let's make points immutables in the next version :+1:


Implementation of per message deflate extension

Planned for a future version!
https://tools.ietf.org/html/rfc7692

Hey @marci4, I want to struggle with this issue but it seems a bit dated. I just wanted to confirm whether it is still expected/needed or not.
Also, I may have to request your opinion on some design issues sometimes if that's okay ? 😅

hello @haruntuncay,
thank you for your interest in this issue!
Yes this is still somewhat planned but I simple does not have the time for this.
Of course, you can send me a mail or ping me in github whenever you want :) Always happy to help.
Best regards,
Marcel

Hi @marci4,
I have been doing some research on LZ77, Deflate and their implementation and now I have some free-time and I want to start on the implementation but I would like to hear your opinion on something;
I have found this generic LZ77 implementation by Apache but I don't know about license issues and I also implemented LZ77 myself using the same hash chaining technique that is described in section 4 of RFC-1951 Deflate Algorithm with a circular-sliding window.
Now, I don't know which one would be more suitable for the project and I wanted to hear your idea on which should be chosen. I personally would like to use my own implementation because I think it would be easier to maintain and has no license issues, btw I will share my impl on github later today.
Do you think it is more suitable to choose ready-built implementation or implement it separately and use that ? (both for LZ77 and Deflate)

Why would the Apache license be a problem?

Hey @marci4,
Do you know about java.util.zip.Deflater ? Based on this stackoverflow question, he says that java.util.zip.Deflater can produce rfc 1951 compliant output. Since I don't know java.util.zip.Deflater very much, I wanted to ask you about it. Do you think it can get the deflate compression part done or should I write a deflator implementation around this LZ77 implementation ?

TL;DR
I see problems in including sources licensed under Apache-2 in this project and would like to do without them.
Long story:
On my work I was among other things busy the last half year to examine Chromium, CEF and CefSharp and the licenses contained therein.
In addition to the many licenses of the components and their different storage structure, a closer look revealed that there are some sources which do not correspond to the described license.
For example:

Wrong license in the defined dependency file
Modifications of the license without the consent of the license holder by copying the source file
Mixed licenses, although defined as single/wrong license in dependency file (MIT was stated, but Facebook’s BSD+Patents License was included)

All these things I would like to avoid for this project.
If we include the Apache component in this project, I think it will have the following effects:

This project wouldn't be pure MIT anymore, so it would either have to take over the Apache license or it would have to contain the Apache license in the LICENSE file as well as in Maven (which in my eyes only TooTallNate can decide).
This includes the current NOTICE as well as possible new ones.
A certain amount of administration is required to ensure that the latest version of the component is always used.

Although it is not difficult for us as an OpenSource project to integrate other OpenSource software, this leads to a considerable additional effort for the users of the library in the administration of the licenses and the resulting compliance with these.
In my opinion, there are therefore the following possible solutions:

Using the component and the associated license adjustment, etc.
Using a dependency implementing the defined component, which can defined via pom.xml.
Write it yourself

The last variant would be my favorite.

Hey @marci4,
Do you know about java.util.zip.Deflater ? Based on this stackoverflow question, he says that java.util.zip.Deflater can produce rfc 1951 compliant output. Since I don't know java.util.zip.Deflater very much, I wanted to ask you about it. Do you think it can get the deflate compression part done or should I write a deflate implementation around this LZ77 implementation ?

I am pretty sure you can use the Deflater, e.g. https://github.com/TakahikoKawasaki/nv-websocket-client is also using it for their implementation.
Best regards,
Marcel

Hey @marci4,
Hope you're doing well. When you have the time, could you please check the implementation from this gist . I would like to hear your opinion on it, before submitting a PR. Btw, I will delete the gist file after your review.

Hey
Yes doing really good. Currently on a vacation :)
The implementation looks clean :)
Nothing I can really spot. Thank you for your work !
Best regards,
Marcel
Am March 7, 2019 9:12:13 PM UTC schrieb haruntuncay<EMAIL_ADDRESS>
Hey @marci4,
Hope you're doing well. When you have the time, could you please check
the implementation from this
gist
. I would like to hear your opinion on it, before submitting a PR. Btw,
I will delete the gist file after your review.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/TooTallNate/Java-WebSocket/issues/574#issuecomment-470695967

--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

@marci4, Thank you for taking the time to review it. I will send a PR soon. Have a fun vacation :)

Fixed with #866


Add LinkRaster

Added functionality for interfacing with ADI in order to display to a window.  LinkRaster is a type that has the same API as Raster, except that it doesn't own the pixel data.  This is useful if you're writing to a screen and have a pixel buffer already.

Alternate implementation using Raster::with_pixels.


IntelliJ IDEA refactorings

Implement a number of changes which reduce warnings reported by IntelliJ IDEA on its default settings (as discussed on the mailing list).

Coverage decreased (-0.006%) to 95.167% when pulling 856327acf5c34642ba10264045bf1ffdfa2deb9f on jbduncan:intellij-idea-refactorings into a37d19eb45d76cd6ab4e2c8fa9fc156bf7be97db on apache:master.


Quick fix for KeyError: 'dataset'

Hi there,
If you are facing KeyError: 'dataset' issue, you can fix by:

go to your webui_folder\venv\Lib\site-packages\gradio_client and edit serializing.py file
go to the end of the serializing.py, and add one line inside COMPONENT_MAPPING:
"dataset": StringSerializable,
it should look like after modifing:

Save
Restart your webui.

it should work well now, I tested 900 hands on webui latest version 1.5.1 + gradio 3.32.0 + gradio_client 0.3.0
it should fix the issues:

https://github.com/jexom/sd-webui-depth-lib/issues/32
https://github.com/jexom/sd-webui-depth-lib/issues/35
https://github.com/AUTOMATIC1111/stable-diffusion-webui/issues/11855

I know webui plans to update gradio to latest(3.39) in later release v1.6.0 (see https://github.com/richrobber2/canvas-zoom/issues/88), but likely it still dataset map in https://github.com/gradio-app/gradio/blob/v3.39.0/client/python/gradio_client/serializing.py

there are several ways to fix the issue permanently:

I am not sure the reason why gradio miss this code, it may have some reasons, but it could be gradio client bug, should be fixed in gradio side.
replace the code https://github.com/jexom/sd-webui-depth-lib/blob/efa9f616b30ea0f27e5dadf40ab41815012d1d78/scripts/main.py#L47 using gr.Examples by another way to show the image lib, may could be gallery component https://www.gradio.app/docs/gallery I guess.
totally give up gradio component and use other tech, like pure javascript instead to display the image lib (as a webui extension developer, I prefer to rebuild my page by HTML/CSS/JS rather than using gradio honstlly)

@alexbofa i don’t see the issue that images not show up on my side, I tested the default images from this extension and 900 hands, and they work well. If you could provide more information I may help.

works for me also

gr.gallery solution looks okay and possible

@alexbofa i don’t see the issue that images not show up on my side, I tested the default images from this extension and 900 hands, and they work well. If you could provide more information I may help.

I didn't have time to fix the message, because I found a problem in the issue. It's possible, as I wrote in the updated post, that the problem is that I'm using a symbolic link for "Extensions" https://github.com/jexom/sd-webui-depth-lib/issues/29

2. by another way to show the image lib, may could b

dataset = gr.Examples(examples=os.path.join(maps_path, t), inputs=[png_input_area],examples_per_page=24,label="Depth Maps", elem_id="examples")
Should be replaced by what?

gonna have to do this: https://github.com/jexom/sd-webui-depth-lib/issues/36#issue-1839673234

@pipa0979 you don’t need to do that you pointed out, that’s some my personal suggestions for the extension author or someone who wants to contribute the fix. To fix it quickly you just need to do my first comment as @webcoderz showing

it works,thanks a lot

TLDR:
The problem for me was miaoshouai-assistant. Removed it, deleted venv folder. Works now.
Longer version:
I had tried everything I found on this page and a few others with no luck.
I can't say whether or not anything on this page helped my solution mentioned here work better or if there was no effect. All I  know is the fixes didn't work until I removed the miaoshouai-assistant extension. I really liked that extension and hope it's updated to working again for me.
Steps I performed to get my stable diffusion working again:

Delete the venv folder
Delete the Miaoshouai-assistant folder in /extensions
Run webui-user.bat

The venv folder was rebuilt and started working. The reason I take extra care to point this out is because I tried running SD with no extensions in the /extensions folder and still got the same error. I can only guess that miaoshouai-assistant puts something in the folder that causes the issue, or requires a dependency that causes the issue.
Hope this helps ♥

你不需要这样做，你指出的，这是我对扩展作者或想要贡献修复的人的一些个人建议。要快速修复它，您只需要按照所示执行我的第一条评论即可

It worked for me. Thank you

@XMUykyz Hello, download this fork: https://github.com/wywywywy/sd-webui-depth-lib


.shrink Behaviour on nested column.row on flexbox 6.3.1

How to reproduce this bug:

What should happen:
Shrink should "shrink" the column
What happened instead:
Column is expanded to full width
Test case:
Here is with Foundation Flexbox 6.3.1
Change the CSS to 6.3.0 and see how it worked!
https://codepen.io/wecodeart/pen/KWBZRm

Also resize the window for small screens to see what I'm talking about.

@canterberrie can you take a look at this?

Found a problem here:
.column.row.row, .row.row.columns {
    float: none;
    display: block; /*here should be flex*/
}

@BicanMarianValeriu a row that is also columns is currently very deliberately set to display block. See the discussion here: https://github.com/zurb/foundation-sites/issues/9857#issuecomment-294941227

@BicanMarianValeriu If you take a look at this example: https://codepen.io/canterberrie/pen/wdMYJX?editors=1100
.shrink columns are working as expected inside of a .row.column
In your original example you have a .row nested directly inside of a .row, and a .column directly inside of a .column, which is incorrect use of the grid. Going to close this issue, but if have a good use case for using the grid this way we can reopen it.


ghprbCommentBody is wrong when new commits are pushed

To allow retesting of only specific tests, in the case of an intermittent failure, I have added a step to a build script that checks ghprbCommentBody for a retest message that matches a certain pattern (e.g. retest tests1 please). When the plugin triggers a build after a retest comment is posted everything works fine, but if a new commit is added to the PR branch to trigger a build, the ghprbCommentBody is still set to previous retest message used. Even if I were to add in another comment to the PR (thinking it might only be looking at the most recently comment) before pushing a new commit, the ghprbCommentBody remains set as the previous retest message.
This may be related to https://github.com/janinko/ghprb/issues/365.

This might quite possibly be related. I'm not sure, but it might be that in the cases where I noticed the problem described in #365 I always was dealing with PRs that had commits added after being initially opened. Can't test this right now though...


Custom products variables don't work in export feed (product comparison)

Used Shopware Version: <IP_ADDRESS>
Description: The custom products variables don't work in the export feed (product comparison)
swagCustomizedProductsTemplate
swagCustomizedProductsTemplateId
swagCustomizedProductsTemplateVersionId
Environment: SW <IP_ADDRESS> CUS 4.1.0
Steps to reproduce:

create custom product set and assign to a product
add the product to a dyn. product group and use it in a product comparison sales channel
add the 3 variables

Expected result:

as only the product that has the custom product assigned, the feed should display the 3 variables

Actual result:

error message: {"errors":[{"status":"400","code":"FRAMEWORK__STRING_TEMPLATE_RENDERING_FAILED","title":"Bad Request","detail":"Failed rendering string template using Twig: Failed rendering string template using Twig: Neither the property \u0022swagCustomizedProductsTemplate\u0022 nor one of the methods [...] exist and have public access in class \u0022Shopware\\Core\\Content\\Product\\SalesChannel\\SalesChannelProductEntity\u0022

[public] Automated response: This issue is linked to the internal issue https://shopware.atlassian.net/browse/CUS-634.
[created from CUS-634, comment 484973]


data_object_type  values of "Metagenome Raw Reads" in mongodb

there are data_object_type  values of "Metagenome Raw Reads" in mongodb, but that is not yet a permissible value in file type enum

I am going to add that permissible value and merge it in. @scanon please either add some metadata/annotations to the new permissible value, or delegate that to someone else who has the subject matter knowledge

in src/schema/nmdc.yaml
  file type enum:
    permissible_values:
      Metagenome Raw Reads:
        todos: add annotations

@mbthornton-lbl please add slot description to FileTypeEnum value "Metagenome Raw Reads"

PR is here: https://github.com/microbiomedata/nmdc-schema/pull/1266


Update Remove-DatabaseFromAvailabilityGroup.md

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

sharepoint/sharepoint-ps/sharepoint/Remove-DatabaseFromAvailabilityGroup.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


EEPROM Writes - Too many EEPROM.write() can crash board - needs recovery...

While testing, my memory reduction code, with EEPROMs, I thought I should try to verify that EEPROM still worked.  So I tried a simple program to write to all memory locations and then try to read them back.  When I ran it, it hung and the board become totally unresponsive.  If you reset the board, it will not run.  You need to do a firmware recovery to reuse the board.
I tested this on the released version of OpenCM9.04 Arduino release and it had the same problem...  Note: if I have the test case only output 64 items in the run it appears to work, but if you reboot and try again, reboot... on the 4th run it will die the same way....  Right now I have it configured to try to output 256 items and it does it in the first run.
#define MAX_INDEX 256
#include <EEPROM.h>
void setup() {
  // put your setup code here, to run once:
  while (!Serial) ;
  pinMode(LED_BUILTIN, OUTPUT);
  Serial.begin(115200);
  Serial.println("EEPROM Test");
  // lets try writing to EEPROM
  uint16_t max_index = EEPROM.length();
  if (max_index > MAX_INDEX) max_index = MAX_INDEX;
  Serial.printf("EEPROM length: %d Max Test: %d\n", EEPROM.length(), max_index);
  uint32_t start_time = micros();
  for (uint16_t i = 0; i < max_index; i++) {
    EEPROM.write(i, i & 0xff);
  }
  Serial.printf("Write time: %d\n", micros() - start_time);
  Serial.println("Start read back");
  start_time = micros();
  for (uint16_t i = 0; i < max_index; i++) {
    uint8_t b = EEPROM.read(i);
    if (b != (i & 0xff)) {
      Serial.printf("Read mismatch: %d %x!=%x\n", i, b, i & 0xff);
    }
  }
  Serial.printf("Read time: %d\n", micros() - start_time);
}

void loop() {
  digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));
  delay(250);
 }

I then instrumented the EEPROM code in drv_eeprom.c
static uint16_t EE_VerifyPageFullWriteVariable(uint16_t VirtAddress, uint16_t Data)
{
  HAL_StatusTypeDef flashstatus = HAL_OK;
  uint16_t validpage = PAGE0;
  uint32_t address = EEPROM_START_ADDRESS, pageendaddress = EEPROM_START_ADDRESS+PAGE_SIZE;
  vcp_printf("EEVPFWV %x %x ", VirtAddress, Data); vcp_flush_tx();;

  /* Get valid Page for write operation */
  validpage = EE_FindValidPage(WRITE_IN_VALID_PAGE);

  /* Check if there is no valid page */
  if (validpage == NO_VALID_PAGE)
  {
    vcp_printf("NO_VALID_PAGE\n"); vcp_flush_tx();
    return  NO_VALID_PAGE;
  }

  /* Get the valid Page start address */
  address = (uint32_t)(EEPROM_START_ADDRESS + (uint32_t)(validpage * PAGE_SIZE));

  /* Get the valid Page end address */
  pageendaddress = (uint32_t)((EEPROM_START_ADDRESS - 1) + (uint32_t)((validpage + 1) * PAGE_SIZE));

  vcp_printf(" PAGE%d %x %x ", (validpage==PAGE0)? 0 : 1 , address, pageendaddress); vcp_flush_tx();
  /* Check each active page address starting from begining */
  while (address < pageendaddress)
  {
    /* Verify if address and address+2 contents are 0xFFFFFFFF */
    if ((*(__IO uint32_t*)address) == 0xFFFFFFFF)
    {
      /* Set variable data */
      vcp_printf(" HFP %x %x %x  ", FLASH_TYPEPROGRAM_HALFWORD, address, Data); vcp_flush_tx();
      flashstatus = HAL_FLASH_Program(FLASH_TYPEPROGRAM_HALFWORD, address, Data);
      /* If program operation was failed, a Flash error code is returned */
      if (flashstatus != HAL_OK)
      {
        vcp_printf(" fail %x\n", flashstatus); vcp_flush_tx();

        return flashstatus;
      }
      /* Set variable virtual address */
      vcp_printf(" HFP %x %x %x  ", FLASH_TYPEPROGRAM_HALFWORD, address + 2, VirtAddress); vcp_flush_tx();
      flashstatus = HAL_FLASH_Program(FLASH_TYPEPROGRAM_HALFWORD, address + 2, VirtAddress);
      /* Return program operation status */
      vcp_printf(" status %x\n", flashstatus); vcp_flush_tx();
      return flashstatus;
    }
    else
    {
      /* Next address location */
      address = address + 4;
    }
  }

  /* Return PAGE_FULL in case the valid page is full */
  vcp_printf("PAGE_FULL\n"); vcp_flush_tx();
  return PAGE_FULL;
}

I recovered the firmware and ran the test again, with this stuff and it spewed the data...

   Wonder if Page 1 is valid?
Time to debug...

Looking at this, what I find interesting is that:
In drv_eeprom.c lines 126...
#define ADDR_FLASH_PAGE_126   ((uint32_t)0x0801F800) /* Base @ of Page 126, 1 Kbytes /
#define ADDR_FLASH_PAGE_127   ((uint32_t)0x0801FC00) / Base @ of Page 127, 1 Kbytes */
So this page looks correct for PAGE0:
EEVPFWV 0 0  PAGE0 801f800 801fbff  HFP 1 801f804 0   HFP 1 801f806 0   status 0
But for Logical Page1, which are first write is showing: EEVPFWV ff ff  PAGE1 802f800 802fbff
Which is not Page_127...
The function EE_FindValidPage returns PAGE0 or PAGE1
Which are defined:
#define PAGE0                 ((uint16_t)0x0000)
#define PAGE1                 ((uint16_t)0x0040)

The computation for The pages address is:
 address = (uint32_t)(EEPROM_START_ADDRESS + (uint32_t)(validpage * PAGE_SIZE));
pageendaddress = (uint32_t)((EEPROM_START_ADDRESS - 1) + (uint32_t)((validpage + 1) * PAGE_SIZE));

So wondering why PAGE1 is defined as 0x0040?  Wonder what would happen if it was defined as 0x01?

@KurtE ,

So wondering why PAGE1 is defined as 0x0040? Wonder what would happen if it was defined as 0x01?

Oh, sorry and thanks...
The value of PAGE1 is invalid. The problem does not occur until 0x01.
If I make a correction, it will affect your PR.
Do you want to modify and apply PR?

@OpusK
That I can do...

@KurtE,
Thanks again for your contribution!


Adding support for external service bindings

Tools like odo may adopt ServiceBinding CR as the resource it creates for service. In that case, users can create the binding themselves and our operator should be able to point to the Service Binding CRs created externally:
spec:
  bindings:
    autoDetect: <true or false>
    resourceRef: <name of a manually created ServiceBinding CR>

More details on the PR: https://github.com/application-stacks/runtime-component-operator/pull/76

Delivered. Closing.


Menu Bar

Implemented using buttons! We're planning on changing it to just text links at the top of the site once we have implemented the correct CSS.

I'm going to leave this open, but I'm thinking of deleting the menu_bar branch as the basic functionality is done. We can open another branch down the line for playing with the CSS and the polished when we have a branch that has the website with full functionality. What do you guys think?


Use submodule namespace for extension packages

Following the best practices for creating and discovering plugins using namespace packages, we should move extensions into a submodule namespace such as glass.ext instead of using the main project namespace.
This prevents extensions from accidentally breaking all of GLASS (again).
On the negative side, it is a breaking change, after which all existing imports of glass.camb need to change to glass.ext.camb.
On the positive side, it means that glass can have an __init__.py into which we can import all public functions.

I think this would also make it finally possible to enable doctests via pytest (#84).


Flutter_quill version 8.1.1 Invalid argument(s): Could not find the default tooltip for Attribute{key: direction, scope: AttributeScope.BLOCK

My issue is about [Mobile]
the issue is caused if
QuillToolbar(configurations: QuillToolbarConfigurations(showDirection: true)),
══╡ EXCEPTION CAUGHT BY WIDGETS LIBRARY ╞══════════════════════
The following ArgumentError was thrown building<…>
QuillToolbarToggleStyleButton(dirty, dependencies:<…>
[QuillToolbarProvider], state:<…>
_QuillToolbarToggleStyleButtonState#a8586):<…>
Invalid argument(s): Could not find the default tooltip for<…>
Attribute{key: direction, scope: AttributeScope.BLOCK, value:<…
rtl}<…>
<…>
The relevant error-causing widget was:<…>
QuillToolbar<…>

quick fix for now
QuillToolbar(configurations: QuillToolbarConfigurations( buttonOptions: QuillToolbarButtonOptions(direction: QuillToolbarToggleStyleButtonOptions(tooltip: 'Direction', iconData: Icons.format_textdirection_r_to_l)),
showDirection: true))

My issue is about [Mobile] the issue is caused if
QuillToolbar(configurations: QuillToolbarConfigurations(showDirection: true)),
══╡ EXCEPTION CAUGHT BY WIDGETS LIBRARY ╞══════════════════════ The following ArgumentError was thrown building<…> QuillToolbarToggleStyleButton(dirty, dependencies:<…> [QuillToolbarProvider], state:<…> _QuillToolbarToggleStyleButtonState#a8586):<…> Invalid argument(s): Could not find the default tooltip for<…> Attribute{key: direction, scope: AttributeScope.BLOCK, value:<… rtl}<…> <…> The relevant error-causing widget was:<…> QuillToolbar<…>

Hi, thank you for the report, please consider sending more information on how to get this issue and more information on what are you trying to do and the version you are using

Flutter_quill version 8.1.1
when I try to add a direction button without overriding QuillToolbarToggleStyleButtonOptions(tooltip: 'Direction', iconData: Icons.format_textdirection_r_to_l)),
the package does not find the tooltip. and icon of the direction button.

Flutter_quill version 8.1.1 when I try to add a direction button without overriding QuillToolbarToggleStyleButtonOptions(tooltip: 'Direction', iconData: Icons.format_textdirection_r_to_l)), the package does not find the tooltip. and icon of the direction button.

I'm late but now I'm able to encounter the issue, give us some time and it will be fixed soon.

Flutter_quill version 8.1.1 when I try to add a direction button without overriding QuillToolbarToggleStyleButtonOptions(tooltip: 'Direction', iconData: Icons.format_textdirection_r_to_l)), the package does not find the tooltip. and icon of the direction button.

The issue is fixed in this commit
You will get the fix in version 8.1.11
If you still have any other issues or questions, feel free to ask us at anytime.


Unable to filter using document table

I have struggled to find a cause on my end, but I've been unable to do so. I can't seem to make the document table plugin filter on any fields. Clicking the +/- filter options seems to do nothing.
I have reproduced this issue on index patterns both with and without a timestamp. I've tested on Chrome/Brave/Edge browsers (which granted are all chromium based). I've cleared my caches and used incognito modes... I've experienced this issue on both ES 7.8.0 and now 7.8.1 with the corresponding latest enhanced table plugin for each of those releases. I'm currently using 1.9.2 on ES 7.8.1.
Does this work for others on this version of ES? If so does anyone have any suggestions for me to try?

Hi
After tests, I confirm the bug.
I work on it for next release.
But for now, if you want a version without this bug, I advice you to use enhanced table for kibana 7.7.1

@fbaligand this plugin helped us improving our dashboards and the only feature thats not working is filter (+/-).

Hi,
Good news: I implémented the issue fix and it will be available in next release!

That's great news! Thank you for your response.

Good news: enhanced table v1.10.0 is out with this issue fixed and more enhancements!
https://github.com/fbaligand/kibana-enhanced-table/releases/tag/v1.10.0


A case for un-deprecating UIProcedure

In V5. UIProcedure was deprecated, for different reasons.
In most applications the new UIBlockProcedure can indeed be used in its stead.
However I've been trying to find a way to use the new api for a complex condition which needs to present some UI to the user and wait for user input and i have not been able to find a way to use do so without writing a custom class.
Basically the new UIBlockProcedure misses the shouldWaitUntilDismissal behavior, which UIProcedure had.

Hi @danthorpe,
My use case is bit different from the iOS view transitioning use case.
It's more along the lines of the user sign-in use case described in the WWDC 2015 session Advance NSOperations.
I need the user to be connected before the app will present some parts of its ui.
The old UIProcedure allowed me to implement this behavior,  by allowing the procedure to be completed only after manually calling finish, if the shouldWaitUntilDismissal is set.
i don't think that the new api allows this use case.


[VS Code] Timed out waiting for agent process to start.

<!--
For Visual Studio problems/feedback, please use the Report

@juliolpj Thanks for reporting this! We're tracking this issue via #360, so I'm going to close this as a duplicate. Per this comment by @mikehdt, could you try re-installing the Live Share extension and see if that helps?