Error occured with IoT Hub F1 tier for provision symmetric key group sample.

Context

OS and version used: Windows 10
Python version: 3.9.11
pip version: 22.2
list of installed packages: azure-iot-device==2.11.0
cloned repo: azure-iot-sdk-python (60535b5554f9da409fc26c162b54a3d230004e4e)

Description of the issue
I'm using the below resources.

IoT Hub: F1, S1 tier
DPS: S1

When I test a provisioning sample(provision_symmetric_key_group.py), get an error at the F1 tier IoT Hub.
But once I try with another IoT Hub in the S1 tier for the same process, it works fine.
According to the guide document below, it seems that the provisioning function is available in F1 tier, please check it.

https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-scaling#basic-and-standard-tiers

Code sample exhibiting the issue

https://github.com/Azure/azure-iot-sdk-python/blob/main/samples/sync-samples/provision_symmetric_key_group.py

Console log of the issue
The error log is as below.
$ python provision_symmetric_key_group.py
register_device() prov-device-01
Traceback (most recent call last):
  File "C:\Users\Rena\AppData\Local\Programs\Python\Python39\lib\site-packages\azure\iot\device\provisioning\provisioning_device_client.py", line 25, in handle_result
    return callback.wait_for_completion()
  File "C:\Users\Rena\AppData\Local\Programs\Python\Python39\lib\site-packages\azure\iot\device\common\evented_callback.py", line 69, in wait_for_completion
    raise self.exception
azure.iot.device.exceptions.ServiceError: Query Status operation returned a failed registration status with a status code of 200

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "D:\azure-iot-sdk-python\samples\sync-samples\provision_symmetric_key_group.py", line 81, in <module>
    registration_result = register_device(registration_id=device_id)
  File "D:\azure-iot-sdk-python\samples\sync-samples\provision_symmetric_key_group.py", line 75, in register_device
    return provisioning_device_client.register()
  File "C:\Users\Rena\AppData\Local\Programs\Python\Python39\lib\site-packages\azure\iot\device\provisioning\provisioning_device_client.py", line 83, in register
    result = handle_result(register_complete)
  File "C:\Users\Rena\AppData\Local\Programs\Python\Python39\lib\site-packages\azure\iot\device\provisioning\provisioning_device_client.py", line 41, in handle_result
    raise exceptions.ClientError("Unexpected failure") from e
azure.iot.device.exceptions.ClientError: Unexpected failure

What are the differences between the 2 hubs that you are using ?

What are the differences between the 2 hubs that you are using ?

I mentioned it in the text. One is the F1 tier and one is the S1 tier. The DPS used for provisioning is the S1 tier.

I tried the sample with an associated F1 tier IoT Hub without any issues.
Can you share your DPS name and registration id in a safer way via email?

Yes, I will share the information.
Based on what you said, it seems to be a DPS problem, so I tested it with another DPS and it worked fine.
Could I use an email address in your profile?

yes you can use the email address on my profile

I checked the service logs and the only reason that your group sample might have failed with that specific DPS was due to the token validation failing. This is the exact message I saw in one of the logs.
"message": SymmetricKeyAttestation SasToken validation failed as no matching enrollmentGroup was found for registration id <SOMETHING>,

The cause of the problem was that the deleted hub was set up on the DPS Linked IoT Hub.
I re-established the connection and tested it and it works.
@olivakar Thank you for your help.

To clarify the above error for token validation failing was not the cause. This was in the logs of a working DPS with F1 IoT Hub. The DPS that did not work was a different one and the message in the logs was
An error occurred while sending the request. ---> System.Net.WebException: The remote name could not be resolved: 'SOMETHING.azure-devices.net' which points to it being that the hub was deleted or changed etc.


Document runtime dependencies and fix git call in publish_doc

Fix #238
(no need a changelog entry)

Usually I only add an entry in the changelog when there is a change in the code that impacts the user (so not for design changes, refactoring, etc), whish is not the case for the readme.
In this case I'm not sure since the change of the git call is indeed in the code but it's something that was not even documented before so nobody knew of these environment variables unless they read the code. Maybe I should add an entry anyway.


Enable Compliance check for Templates

Trello task: https://trello.com/c/QXven56G/160-3-enable-template-compliance-check
other version of #7617

verified in UI, Looks good.


Add Loglevel option

Add flag for changing loglevel
Add --debug switch that enables GLI debug output

i'm thinking of changing status and targets to just do a puts to stdout instead, since they are commands that are really only run manually (rather than part of a script)

i'm thinking of changing status and targets to just do a puts to stdout instead,

you mean just in case someone sets the log level too high and it doesn't work?

right

that makes sense


E2E: go release main SLSA3 config-ldflags assets

Repo: https://github.com/slsa-framework/example-package/tree/v16.0.15
Run: https://github.com/slsa-framework/example-package/actions/runs/6752632997
Workflow name: go release main SLSA3 config-ldflags assets
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.go.release.main.config-ldflags-assets.slsa3.yml
Trigger: release
Branch: v16.0.15
Date: Sat Nov  4 04:07:58 UTC 2023

Repo: https://github.com/slsa-framework/example-package/tree/v16.0.15
Run: https://github.com/slsa-framework/example-package/actions/runs/6759068021
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.go.release.main.config-ldflags-assets.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.go.release.main.config-ldflags-assets.slsa3.yml
Trigger: release
Branch: v16.0.15
Date: Sun Nov  5 04:12:55 UTC 2023
Tests are passing now. Closing this issue.


python311Packages.google-cloud-language: 2.10.0 -> 2.10.1

Changelog: https://github.com/googleapis/python-language/blob/v2.10.1/CHANGELOG.md
Description of changes

Things done

Built on platform(s)

[ ] 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/)
23.11 Release Notes (or backporting 23.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

[ ] Fits CONTRIBUTING.md.

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

4 packages built:

python310Packages.google-cloud-language
python310Packages.google-cloud-language.dist
python311Packages.google-cloud-language
python311Packages.google-cloud-language.dist


Translate gitlab CI/CD to github

That's a thing to be done for sure, I probably could take a look at github actions, there's probably a way to use tarpaulin with this.

Tarpaulin ?

Tarpaulin is the tool I used to get the coverage of the tests on the .gitlab-ci.yml, there's probably a way to get that working using GitHub Actions!


When I perform a build, throw the following statement, is this normal?

cd doh-client && go build
cd doh-server && go build
if [ "`uname`" = "Darwin" ]; then \
        make -C darwin-wrapper; \
fi

It is normal.


want to try to make a blog website using html,css and javascript.

@swapnilsparsh I would like to contribute to this project by trying to make a simple blog website using html,css and javascript.
Tadrup Das
GSSOC'22 contributor

Hey assign this to me!

Hey assign this to me!

Don't open new issues by just adding your projects in this repo, you can directly make a PR if you have some JS project with you that is not yet on the website.
Good Luck 👍🏻

@TushitaParashar Update?

@swapnilsparsh working on the frontend part right now. Actually, exams were going on.

@swapnilsparsh   i have already finished the frontend but stuck on the backend part. So can i contribute only the frontend?

@swapnilsparsh i have already finished the frontend earlier but was stuck on the backend part. So can i contribute only the frontend?

Sorry but no


add new first and last to pagination page prop

Description (required)
Suggests documentation for upcoming new page.url.first and page.url.last feature PR.
Related issues & labels (optional)

Closes #
Suggested label:

For Astro version: 4.12. See astro PR 11176.

Lunaria Status Overview
🌕 This pull request will trigger status changes.

Learn more
By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.
You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

Locale
File
Note

en
reference/api-reference.mdx
Source changed, localizations will be marked as outdated.

Warnings reference

Icon
Description

🔄
The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.

!coauthor


Implement support for AWS GPU Instances

A/C:

[x] Energy and carbon emissions estimates should be returned for all AWS GPU Instances, via the API and CLI.

Tech Tasks:

[x] CPU Compute operational energy / carbon emissions is implemented for all instances
[x] CPU Memory operational energy / carbon emissions is implemented for all instances
[x] GPU operational energy / carbon emissions is implemented for all instances
[x] Embodied emissions is implemented for all instances
[x] Relevant unit tests are added / updated
[x] Relevant packages versions are bumped

Notes:

We can leverage Teads published data set for the implementation. Note the more modern families aren't published there yet -- we can do that and contribute it back if their team is interested.
This is the list of GPU instances we need to support:
p2.xlarge
p2.8xlarge
p2.16xlarge
p3.2xlarge
p3.8xlarge
p3.16xlarge
p3dn.24xlarge
p4d.24xlarge
g2.2xlarge
g2.8xlarge
g3s.xlarge
g3.4xlarge
g3.8xlarge
g3.16xlarge
g4dn.xlarge
g4dn.2xlarge
g4dn.4xlarge
g4dn.8xlarge
g4dn.16xlarge
g4dn.12xlarge
g4dn.metal
g4ad.4xlarge
g4ad.8xlarge
g4ad.16xlarge
g5.xlarge
g5.2xlarge
g5.4xlarge
g5.8xlarge
g5.16xlarge
g5.12xlarge
g5.24xlarge
g5.48xlarge
g5g.xlarge
g5g.2xlarge
g5g.4xlarge
g5g.8xlarge
g5g.16xlarge
g5g.metal

I have pushed this - ready for code review.


Added use-ssh option

Fixes #1421

Things to be done:
[ ] reverse / forward connections;
[ ] copying server binary.

At this point there are (1) only reverse connections implemented, (2) forwarding is not ideally stable, but generally it works.

About (2), I would test this build for a while. Also, it will be needed to have our own NDK-based tool instead of socat.

In addition to redirection of sockets this tool also makes sure that server is killed after it receives EOF in STDIN (when client disconnects).

In current version there is no requirement to turn on "USB debugging (security settings)", assuming you run as root.

I found that forward mode is working much more stable than reverse one. @rom1v do you know if application can miss connections to it?

Fixed that in 02fc377e9520a1b42fda7f29b475b3dd8364ffc5

Any progress on this? It has the potential to be a major enhancement to SCRCPY.


Cosmos DB emulator: use latest Windows image

What this PR changes/adds
Use windows-latest image
Why it does that
Potentially resolves the issue. I started a few runs and they all succeeded.
Further notes
Linked Issue(s)
Closes #845
Checklist

[ ] added appropriate tests?
[ ] performed checkstyle check locally?
[ ] added/updated copyright headers?
[ ] documented public classes/methods?
[ ] added/updated relevant documentation?
[ ] added relevant details to the changelog? (skip with label no-changelog)
[ ] linked GitHub project? (see the section on the right-hand side -->)

Codecov Report

Merging #846 (ca0ae50) into main (fb222eb) will increase coverage by 0.29%.
The diff coverage is 83.97%.

:exclamation: Current head ca0ae50 differs from pull request most recent head 85d114b. Consider uploading reports for the commit 85d114b to get more accurate results

@@             Coverage Diff              @@
##               main     #846      +/-   ##
============================================
+ Coverage     59.64%   59.94%   +0.29%
- Complexity     2188     2230      +42
============================================
  Files           594      600       +6
  Lines         12837    12984     +147
  Branches        900      904       +4
============================================
+ Hits           7657     7783     +126
- Misses         4759     4777      +18
- Partials        421      424       +3

Impacted Files
Coverage Δ

...iation/ConsumerContractNegotiationManagerImpl.java
61.21% <0.00%> (ø)

...or/api/datamanagement/asset/AssetApiExtension.java
0.00% <0.00%> (ø)

...tractdefinition/ContractAgreementApiExtension.java
0.00% <0.00%> (ø)

...ctor/api/datamanagement/asset/AssetController.java
85.18% <60.00%> (-14.82%)
:arrow_down:

...ractnegotiation/ContractNegotiationController.java
68.00% <60.00%> (-2.00%)
:arrow_down:

...datamanagement/asset/model/TransferRequestDto.java
63.63% <63.63%> (ø)

...iation/ProviderContractNegotiationManagerImpl.java
65.06% <100.00%> (ø)

...ntractAgreementToContractAgreementTransformer.java
78.43% <100.00%> (ø)

...ractdefinition/ContractAgreementApiController.java
100.00% <100.00%> (ø)

...contractdefinition/model/ContractAgreementDto.java
100.00% <100.00%> (ø)

... and 2 more

Continue to review full report at Codecov.

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


Failed login - clear Exception

Description

Include the same options into session login Exception

This issue was migrated from an old repository: https://github.com/CiscoDevNet/catalystwan/issues/45


xlockmore: 5.69 -> 5.70

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/xlockmore/versions.
meta.description for xlockmore is: "Screen locker for the X Window System"
meta.homepage for xlockmore is: "http://sillycycle.com/xlockmore.html"
meta.changelog for xlockmore is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 5.70 with grep in /nix/store/zkkwagvlbs29ych0yg6agwhy6m18659i-xlockmore-5.70
found 5.70 in filename of file in /nix/store/zkkwagvlbs29ych0yg6agwhy6m18659i-xlockmore-5.70

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
xlockmore

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/zkkwagvlbs29ych0yg6agwhy6m18659i-xlockmore-5.70 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A xlockmore https://github.com/r-ryantm/nixpkgs/archive/650a88e301b8a6cb777fabfa9953b7a273109725.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/zkkwagvlbs29ych0yg6agwhy6m18659i-xlockmore-5.70
ls -la /nix/store/zkkwagvlbs29ych0yg6agwhy6m18659i-xlockmore-5.70/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

xlockmore

Maintainer pings
cc @pSub for testing.

@ofborg eval


C++ grpc client libraries not obeying DNS TTL

What version of gRPC and what language are you using?
I'm using gRPC 1.15.1 (c++)
What operating system (Linux, Windows,...) and version?
Linux, CentOS7
What runtime / compiler are you using (e.g. python version or version of gcc)
GCC
What did you do?
Using grpc to for TTS requests, we see intermittment request failures since the grpc client library tries to make connection to stale IP address for the AWS load balancer.
AWS ELB load balancer would change its IP addresses frequently while its DNS name has the TTL set to 60 seconds.
It looks like gRPC wouldn't be able to refresh the IP address of an AWS ELB load balancer until a connection with the old IP address fails.
What did you expect to see?
gRPC client obeying DNS TTL from the server.
What did you see instead?
DNS TTL was not respected and client kept using stale library address for LB causing request to fail.
Looking for any options we could configure in environmental variable or O.S which can make the gRPC client obey DNS caching rules or worst case any code changes we can do fix this issue.
Make sure you include information that can help us debug (full error message, exception listing, stack trace, logs).
See TROUBLESHOOTING.md for how to diagnose problems better.
Anything else we should know about your project / environment?

Duplicate of #12295.


Custom select widget

As discussed in #45, we should have a custom "select" widget with type-ahead support.

This widget should also be used to implement the UI for #22.

Closes #52

Custom select widget with theories divided by theory type (i.e. Data and Knowledge, System Dynamics)
Selected theory is viewable in the notebook


Feature: Migration to NextJs

Fixes Issue
fixes #1470
Changes proposed

Modified home page.
Fixed bugs that prevented the deployment.
Minor UI Changes in the Search tab.

Check List (Check all the applicable boxes)
[x] My code follows the code style of this project.
[] My change requires changes to the documentation.
[] I have updated the documentation accordingly.
[x] All new and existing tests passed.
[x] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.

Thank you @JealousGx 👍  this is a big PR, is it possible to break it into smaller PRs?

Thank you @JealousGx 👍 this is a big PR, is it possible to break it into smaller PRs?

@eddiejaoude Done. I have broken down the skeleton PR and homepage with some bug fixes into two PRs. Let me know if anything else needs to be fixed in these PRs.

Great! Thank you! Let me take a look 👍


ERR invalid expire time in psetex

Expected behavior
JedisConnection
public void pSetEx(byte[] key, long milliseconds,byte[] value)
set expire time with TimeUnit.MILLISECONDS right.
Actual behavior
exception with the message as this issue title suggested
Steps to reproduce:
call API
ValueOperations
void set(K key, V value, long timeout, TimeUnit unit);
set timeout > 2^31 ,TimeUnit.MILLISECONDS  . Then the expireTime will be negative.(overflow)
@Override
	public void pSetEx(byte[] key, long milliseconds, byte[] value) {

		try {
			if (isPipelined()) {
				doPipelined(pipeline.psetex(key, (int) milliseconds, value));
				return;
			}
			if (isQueueing()) {
				doQueued(transaction.psetex(key, (int) milliseconds, value));
				return;
			}
			jedis.psetex(key, (int) milliseconds, value);  // why  int ?????
		} catch (Exception ex) {
			throw convertJedisAccessException(ex);
		}
	}

Redis / Jedis Configuration
Jedis version:
2.6.1
Redis version:
2.8
Java version:
JDK7

I do think this is a bug. Any value bigger than INT_MAX will cause this error... This cast is no sense.

@terry19850829 @aluenkinglee thx for reporting. Is anyone willing to open a PR to fix it?

@marcosnils
Days before, I'm busy with my job. I  see this '@' just now. Is it a bug or not?
I have never open PR before. Could I open one ?

@terry19850829 where is this cast?, I can't find in Jedis code.. Can you please paste the link where this line is please?

@marcosnils  It's my fault... The code is in another project spring-data-jedis 1.5.2 version.
It's not a jedis issue.
The cast is at org.springframework.data.redis.connection.JedisConnection line 1255 and many other positions.
I'll close this.


Add identity expansion checking in ill-form expansion

This PR try to add more checking code in error case in macro expansion. The bug in @3642 is introduced by  #3580 , which allow ill-form macro expansion in all kind of macro expansion.
In general we should separate hypothetical macro expansion and the actual macro expansion call. However, currently the Semantic  workflow we are using only support single macro expansion type, we might want to review it and make it works in both ways. (Maybe add a field in MacroCallLoc for differentiation)
Fix #3642

@flodiebold

I think you meant to use #3642, instead of @3642.

@bjorn3 oops.. not enough coffee, thanks <3

:coffee:

Thanks for looking into this by the way!

Hmm looks good to me, we should also make sure that we're limiting the expansion depth everywhere though, right? I.e. it seems to me we're probably not doing that in expression macro expansion?

Yea, good idea !! I will do another PR for that !

bors r+

bors retry


(maint) Add workflow for creating release notes

Need a deeper look, copied from Cake.Transifex.
Copied in a rush

Let's take this for a spin 😄


Replace Ahash with Fnv for Hashbrown

Alternative to #824 , will fix #812 too for systems without atomics. Fnv provides no key randomization, but it shouldn't be required for commitment scheme.

[x] Targeted PR against correct branch (master)
[x] Linked to GitHub issue with discussion and accepted design OR have an explanation in the PR that describes this work.
[ ] Wrote unit tests
[ ] Updated relevant documentation in the code
[ ] Added a relevant changelog entry to the Pending section in CHANGELOG.md
[ ] Re-reviewed Files changed in the GitHub PR explorer

How about we use SipHash for non-atomic platforms, and ahash elsewhere?

To be honest I'm not sure from top of my head if I can make cargo dependency optional based on whether a platform has atomics. Will try

Another question is whether or not try to include aHash with or without randomization if it's done as external dependency instead of default hash in hashbrown. Hashbrown itself doesn't have and option to continue aHash's features, but maybe it can be imported independently and without randomization is may have no atomics by itself

To be honest I'm not sure from top of my head if I can make cargo dependency optional based on whether a platform has atomics. Will try

I think it's possible like so: https://github.com/PyO3/pyo3/blob/fe79f548174eb8108813f202bb0df9428ddfd806/Cargo.toml#L48

restored features (inlines) on hashbrown + ahash is used on platforms with atomics

Hi! Can anyone give me some pointers on why the default-hasher of hashbrown is not suitable for us? They have changed it to FoldHash orlp/fold hash.

Mainly because it was using atomics and would not compile on some platforms

I didn’t check FoldHash. The main problem was that aHash was seeded, and seeing mechanism itself used atomics. So it may apply to FoldHash too as seeding is standard mechanism to avoid timing attacks on hash maps if queries could be externally provided/uncontrolled. For arkworks it’s not needed, but default configuration was to use such mechanism

Thanks a lot for the pointers! I just checked the seeding mechanism in FoldHash https://github.com/orlp/foldhash/blob/c55c471921ec68e07fdf1623a5d1fa6cc3f09809/src/seed.rs#L310 and it seems they provide a fixed global state for the platforms that do not support atomics.
I would appreciate it very much if you could have a look and confirm if I understood correctly.
In that case, I can go ahead and enable default-hasher from hashbrown and would simplify things.

Hi again! I would be very grateful if you could look into this.
I believe FoldHash is similar to FNV in the sense of seeding on non-atomic systems. A thumbs up from you would suffice :)

What’s the interest for the default hasher? It’s just a feature flag and only provides few extra constructor methods. Maybe Default::default() starts to work, but not sure. At the moment I do not have capacity to check building on atomic-free platforms. Seeding code will most likely work, but it also depends if hashbrown doesn’t do some manual seeding itself

Thanks for the answer.
Regarding the interest in the default hasher: I think it simplifies the code. Currently, we have this conditional dependency on aHash and FNV, while having this feature enabled (assuming that FoldHash works for both atomic/non-atomic) we can get rid of the conditional dependency + we will have more concise code for instantiating a hashmap.
I will need this in some other repos of arkworks as well.


Update config.json

Typo in URL arpspoof results in not found. It's now fixed!

Thanks very much!


Docs: incorporate pdoc to generate API docs

Incorporating the suggestion in #174.
This is a little messy.  Based on the pdoc example for Mkdocs, it seems you have to run a script to execute pdoc before the mkdocs pass. Then, because pdoc emits HTML, to get it into the mkdocs build you have to incorporate the HTML as "fake" markdown so that mkdocs will process the markdown files and incorporate it.
It works, but it's a little clunky. Here's the output on my dev machine:

There are issue with this. pdoc will use the installed tantivy module. This means that the readthedocs site will have to build the tantivy module which might turn out to be nontrivial. Instead, the pdoc execution could be done as part of CI, commiting the output markdown files (in the ./docs/api directory). That way, readthedocs only needs to operate on markdown files and no compilation is required.

Hi @cjrh,
thank you for investigating this in detail!

There are issue with this. pdoc will use the installed tantivy module. This means that the readthedocs site will have to build the tantivy module which might turn out to be nontrivial. Instead, the pdoc execution could be done as part of CI, commiting the output markdown files (in the ./docs/api directory). That way, readthedocs only needs to operate on markdown files and no compilation is required.

This makes sense to me too.


Tracking pull request to merge release-1.10.0 to main

Currently, when the task-queue application starts, it creates scheduled jobs only if those jobs don't already exist in the database. This means that if some aspects of a job are changed (e.g. the send_rebates_to_ncda job in this release has its arguments updated to contain a new timeout time), one has to delete the job first in the admin console before deploying, or update the job manually in the admin console after deploying.
For this particular release, one should delete the send_rebates_to_ncda job in the admin console before deploying. This manual step is not ideal; there's an open issue for it on jira: https://apps.nrs.gov.bc.ca/int/jira/browse/ZELDA-436


[ZEPPELIN-2841] fix a problem in shell interpreter . Working directory '.' can not be found in docker environment

What is this PR for?
shell interpreter complained that working directory '.' can not be found in docker environment.
I add a line of code to set current working directory to USER`s home, and it works.
What type of PR is it?
Bug Fix
Todos

tests

What is the Jira issue?
https://issues.apache.org/jira/browse/ZEPPELIN-2841
How should this be tested?
run shell interpreter`s test units
Screenshots (if appropriate)
Questions:

Does the licenses files need update?
No
Is there breaking changes for older versions?
No
Does this needs documentation?
No

Jenkins said that "Can't find build for commit e8cbdd180a22d1d53366c94c5432c217d70a5727 from vistep".
I have no idea about what happened. How to  fix it?

I have fix the build problem by setting travis according to what Jenkins said at last part.

I replaced System.getenv("HOME") with  System.getProperty("user.home") .
This time, Jenkins said "[ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:1.3:yarn (yarn test) on project zeppelin-web: Failed to run task: 'yarn run test' failed. (error code 1) -> [Help 1]"
I don`t understand why my code affects zeppelin-web ?

build sometimes fail because of network connection problem of flaky tests.
Could you try restart failed one?

I tried again and it passed.

LGTM and merge to master and branch-0.7 if no further comment.

This implementation has a harmful side effect that can break existing notebooks.
The problem with this fix is that it changes the meaning of all relative path-names used in any shell commands. For example, after this fix, the command ls -l data would operate on the data subdirectory of the user's home directory, whereas before the fix it would operate on the  data subdirectory of zeppelin's working directory.
One immediate change that is suggested is to change the fix to make it apply only to the narrow situation it is needed in (a Docker environment).

Can we use a try-catch block to test if we need to set working directory when zeppelin opens a shell interpreter?

I have not looked at the code in detail, so will refrain from making suggestions about the code :-)

@Leemoonsoo How about the idea above?

@sanjaydasgupta @vistep have create JIRA for the same https://issues.apache.org/jira/browse/ZEPPELIN-2903.


ally.disengage not piercing shadow roots

When using ally.js with web components, ally.disengage does not re-enable elements inside shadow roots.
When using Polymer's "shady DOM" (Polymer 1.0 default), disengage works fine. However, using shadow DOM (which will be the default in the future), elements inside shadow roots remain disabled.
Demo: http://jsfiddle.net/kmdz6Lyq/20/

When using ally.js with web components, ally.disengage does not re-enable elements inside shadow roots.

Boom.
This querySelectorAll and the querySelectorAll in maintain/hidden don't penetrate shadows.
It's tempting to try the quick fix [data-ally-disabled], :disabled to html /deep/ [data-ally-disabled], html /deep/ :disabled as done in selector/focusable. But that would exclude Firefox for now.
I guess I'd prefer maintaining a cache on the service instance, and mutate that upon observed mutation. On that topic, I'm pretty sure the MutationObserver does not see changes within a ShadowRoot. So that's the next issue to solve.
The problems exist since version 1.0.0 in maintain/disabled and maintain/hidden.

Unfortunately /deep/ and >>> will throw warnings even in Chrome currently as they have already posted an intent to deprecate https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/68qSZM5QMRQ
I agree that probably the best long term solution is to maintain a cache.

Unfortunately /deep/ and >>> will throw warnings even in Chrome currently as they have already posted an intent to deprecate

that is only partially true. Yes, currently Chrome logs a warning, but it shouldn't. The deprecation notice concerns the dynamic profile not the static one (which is the one used by querySelector). see

https://code.google.com/p/chromium/issues/detail?id=489954#c7
https://code.google.com/p/chromium/issues/detail?id=489954#c17

I agree that probably the best long term solution is to maintain a cache.

I guess this would be the perfect time to introduce WeakSet for browsers that already support it and use an array for older browsers.

On that topic, I'm pretty sure the MutationObserver does not see changes within a ShadowRoot.

This means we have to find ShadowHost elements in the context and register individual MutationObservers for each of them. oh the joy.

The deprecation notice concerns the dynamic profile not the static one (which is the one used by querySelector)

As far as Chrome is concerned I you're right. I guess if I'm reading the spec correctly it looks like this is a go for the static profile. I was a bit concerned by some talk I saw about Safari being completely opposed to /deep/: https://github.com/w3c/webcomponents/issues/78 but maybe that's old news.

guess this would be the perfect time to introduce WeakSet for browsers that already support it and use an array for older browsers.

Likely this will need to be Set rather than WeakSet since you can't iterate over WeakSet, but either way that sounds good. I'm in the process of testing an implementation of this.

This means we have to find ShadowHost elements in the context and register individual MutationObservers for each of them. oh the joy.

This doesn't sound fun. I did see some talk about adding a property to the MutationObserver config for ShadowRoot, but I think this had mixed reviews for the idea.

Likely this will need to be Set rather than WeakSet since you can't iterate over WeakSet …

I did not know that. I was aiming for the weak references, not the Set. :(

It seems like this can be broken into two bugs:

To actually querying elements within the shadow-root, possibly with /deep/ when re-enabling inert elements
Observe mutations within elements that contain a shadow-root

Thoughts?

merged your commits from #107 and resolved the remaining issues. Closing this issue, as #110 tracks the MutationObserver for ShadowDOM issue.
Thank you!


Proposal: split embark into embark and @embark/core

Overview
TL;DR
Module resolution with DApps and Embark is presently complex. See #1039, for example. If the bulk of Embark were contained in a locally installed @embark/core package, and if we make use of peer dependencies, the situation can be greatly improved. Later on, we might split up core into a collection of locally installed @embark/[name] packages, and that will work fine too.
Extra Detail
Key ideas

embark becomes a very lightweight package that can be installed globally or locally, and which provides a minimal cli.
@embark/core provides most of what embark provides now, minus the pieces in the revised embark.

minimal embark cli
It would have:

Template generator
Logic similar to the existing shim that looks for @embark/core, hooking into it where it finds it, or prompting the user to install it if wasn't found. It could even offer to install it for the user and update the DApp's package.json.

When run outside a DApp directory, the help output might look like this:
$ embark
Usage:  [options] [command]

Options:

  -V, --version                              output the version number
  -h, --help                                 output usage information

Commands:

  new [options] [name]                       New Application
  demo [options]                             create a working dapp with a SimpleStorage contract
  version                                    output the version number
  help                                       output usage information and help information

When run inside a DApp directory, it will bolt onto @embark/core's cmd.js and the help output would show the additional cli facilities that @embark/core provides (everything that embark help displays at the present time). Also, version output inside a DApp would include not only the version of embark but also of @embark/core.
@embark/core
It would consist of most of what's in embark presently, minus the parts that are in the revised package, such as bin/embark, the template generator, etc. (see the previous section).
It would be intended to always and only be installed locally. If it's installed globally, it won't cause any problems, but it would be inert and not usable by DApps. It's the same situation if you installed the bluebird package globally (npm i -g bluebird) and then want to use it from a Node project you're developing: it doesn't work that way; you need to npm i bluebird inside your project.
An important change is that any Embark dependencies that may be resolved by a DApp script or DApp dependency will need to be either:

Converted to a peer dependency of @embark/core and installed alongside it. The revised embark cli-package can help with this — after finding/installing @embark/core it can check whether any peer dependencies specified by @embark/core are not yet installed or if the already-installed versions aren't acceptable. @babel/core is an example of a package that would become an @embark/core peer dependency.
Resolved indirectly by having the DApp script require an encapsulating module within embark. Assuming the DApp script is run in the embark process or a child process, then something like this could be done: require(path.join(process.env.EMBARK_PATH, 'lib/core/utils')).  An example of a package that could be encapsulated inside an embark module is lodash.clonedeep.

Why am I proposing this?
If you're not 100% sure how module resolution works in Node, please read the docs.
There are presently three+ distinct node_modules trees in play between a DApp and Embark:

A/embark/node_modules
B/dapp([/..]*)/node_modules
B/dapp/.embark/versions/*/*

(3) isn't really a node_modules tree per se, but it works like one. (2) could be a single node_modules tree or a forest of trees that will be searched from inside out.
Depending on what's installed where, A might be in a subdir relationship with B or vice versa, or they may be the same or disjoint.
Presently, when a DApp script or dependency needs to resolve a module from Embark's node_modules, we ensure that can happen by modifying NODE_PATH, and in some cases we also have to use a "custom require" approach since our runtime modification of NODE_PATH can't take effect in embark's main process (only child processes).
These solutions work but are brittle and can have surprising results. And since they're implemented at runtime, npm may report a DApp is missing dependencies even though Embark can be expected to supply them.
How does this proposal help?
With @embark/core always in the DApp's node_modules tree/forest, and with select dependencies specified and installed as peer dependencies at the top-level of the tree in which @embark/core resides, we eliminate the need for NODE_PATH and "custom require", and we can be certain that Embark and the DApp will be able to resolve the package versions they need.
This same approach should also let us confidently deprecate Embark's library manager, and therefore eliminate (3) in the list above. Any package that might be specified in a DApp's embark.json with a non-default version could be specified as a peer dependency of @embark/core with a suitable semver range , allowing a DApp developer the freedom to specify the non-default version he wants in the DApp's package.json and to depend on npm to install it in the usual way.
The reason that it's critical for us to switch some packages to being peer dependencies is that transitive dependencies (if we moved from shrinkwrap back to package-lock for @embark/core) can be unpredictable. For one, there can be semver shenanigans with dependencies' dependencies when @embark/core is installed from the registry. Also, there's no guarantee that some other dependency of a DApp (or the DApp itself) won't specify an incompatible version of a dependency also specified by @embark/core — npm might (or might not) dedupe the incompatible version into the top-level node_modules of the DApp, and then DApp scripts (such as an ejected webpack config) and DApp dependencies might end up broken at runtime.
Note that the reason we'd need to switch from shrinkwrap back to package-lock to take advantage of @embark/core's dependencies as transitive dependencies is that shrinkwrap will keep all of them in dapp/node_modules/@embark/core/node_modules such that normal module lookup from within the DApp can't succeed... and so we'd be right back to needing NODE_PATH and "custom require". :scream:

One thing not mentioned in the write-up above is that if a DApp were to specify a dependency that itself had a peer dependency incompatible with one of @embark/core's peer dependencies, then something would have to give — either embark or the DApp or the DApp's dependency. I'm not sure how often that situation would arise, and we'd want the embark cli to be as helpful as possible identifying those situations.

Thx for making that great idea something we can all discuss formally about.
I would personally go even further via the following suggestion:

Fully namespace the packages:

@embark/cli
@embark/scripts (more on this name later)

@embark/cli only responsible to generate a app and is never use after that
Contains only new command with template generation

@embark/scripts located in package.json
Contains all the other commands
If the scripts is not inside the local package.json and use globally => throw an error with an explanation message
Later on, the scripts package can be splitted by module/core and this package can only be the entry point to embark world
Example of package.json

{
  "name": "app",
  "scripts": {
    "embark": "embark-scripts",
  },
  "dependencies": {
    "@embark/scripts": "^5.0.0",
  }
}

From there you can run:
npm run embark command or yarn embark command

Advocate strongly for npx or npm init or yarn create when using @embark/cli to avoid global install

Remove the part where the cli interact with the core

I think that would reduce the number of case we have to handle and help the user to follow not only embark convention but also JS convention.
Those techniques are used by Create React App, Create Next App, Vue.js to only name the most famous one

Really really nice to see this discussion here. Let me throw in my thoughts as well:

I actually think that the whole package naming is a separate problem that needs to be solved and discussed, but it definitely affects the consumer facing API in this effort as well. Even though, we might want to discuss this in a separate thread, I believe we will and should end up with packages such as:

@embark/core
@embark/cli
@embark/plugins/<plugin> ?
@embark/<package> // packages that are needed but not necessarily a plugin either

Ideally, @embark/cli which is our CLI would also just take advantage of @embark/core and any other plugins and packages it needs to do its work. So do other consumers that would for example want to use what's currently called EmbarkJS. Maybe they'll rather do sth. like import { embark } from '@embark/client' in the future.
But again, I think those namespacing related things are really a separate problem.

While I do think that a create-react-app equivalent might be a nice thing to have, we shouldn't forget that Embark CLI does way more than just scaffolding a new app. Yes, this might be tackled by @alaibe 's proposal of @embark/scripts, but then again, why can't we keep it "simple" (all dependency issues aside for a moment), and just have @embark/cli a local dependency of an embark project?
At the end of the day it should be possible to do ./node_modules/@embark/cli/bin/embark <command> IMO.
If one doesn't feel like introducing @embark/cli globally, just to create a new app, they can just do npx @embark/cli new [--options]. I see @embark/scripts more like whatever modules and flows are needed inside embark (CLI) to make the thing work.

Presently, when a DApp script or dependency needs to resolve a module from Embark's node_modules, we ensure that can happen by modifying NODE_PATH, and in some cases we also have to use a "custom require" approach since our runtime modification of NODE_PATH can't take effect in embark's main process (only child processes).

@michaelsbradleyjr When would a Dapp ever try to resolve a module from Embark's node modules? The only thing I can think of right now, is that a Dapp wants to import from Embark (but not its node modules). For example, something I've mentioned above:
import { embark } from '@embark/client'

But also in this case, @embark/client would be a package installed as a dependency of the app itself.

This same approach should also let us confidently deprecate Embark's library manager, and therefore eliminate (3) in the list above. Any package that might be specified in a DApp's embark.json with a non-default version could be specified as a peer dependency of @embark/core with a suitable semver range , allowing a DApp developer the freedom to specify the non-default version he wants in the DApp's package.json and to depend on npm to install it in the usual way.

I'd love that. I still don't fully get why we maintain another set of versions inside the dapp.

I don't really agree with this. It feels premature given other stuff we still need to do, overcomplicates things possibly (although I might be misunderstanding..), but more importantly in the grand scheme of things we have other priorities first.

I can provide a more thorough reply to all the points raised later today.
To @iurimatias's point, here's the problem:
The cli shim that's landing in embark v4 is supposed to make it painless to have embark installed locally or globally, or both, and have everything always work regardless of a DApp author's preferred setup.
The shim does work well, when it comes to embark commands. It's only recently become clearer to me that there are still serious challenges with regards to module resolution. Our use of NODE_PATH and "custom require" is prone to surprising behavior and needing additional work arounds as time goes on.
This proposal is a way to move forward with a setup that we know will work correctly, so long as we're careful about specifying some dependencies as peer dependencies (now, and in the future as embark evolves). It also has the benefit of laying the groundwork for breaking embark up into a set of smaller library modules. That should help make embark more flexible, allowing the components to be used in different ways, e.g. with alternative cli interfaces. Some community members have been asking about that, I think... I'm recalling discussions about angular cli and embark.

@alaibe good proposals! Here are some ideas that build on yours:
Instead of @embark/cli to house what's in utils/template_generator.js, call it @embark/new or @embark/create.
Rather than have an @embark/scripts package, I propose that each embark module that offers cli functionality can have the equivalent of cmd.js and cmd_controller.js. It would be the job of the @embark/cli module to take a list of modules and build the full cli at runtime. I'm thinking of modules like blockchain exposing the embark blockchain command, pipeline exposing the build command, and so on. We could have some meta-modules to expose commands like run which blend together the functionality of other modules; @embark/core could be thought of as a meta-module and its own cmd.js / cmd_controller.js could supply run, reset, and so on.
Importantly, none of the individual modules would directly expose anything to the command-line, i.e. no "bin" entry/ies in their package.json files. Nor would @embark/cli have a "bin" entry — it would just be for cli plumbing, i.e. building the full cli from all the pieces and passing along process.argv.
More concretely...
embark package (not namespaced) could have @embark/cli and @embark/new as dependencies. When its bin/embark is run outside a dapp it would pass '@embark/new'  (which exposes new and demo commands)  and process.argv to @embark/cli.
When the embark package's bin/embark is run inside a dapp there is something special that happens: bin/embark having detected it's running inise a dapp (it found embark.json) it checks that the package.json it found for the dapp specifies @embark/core and that it's installed. Assuming it's ready to go, @embark/core is invoked to pass a list of modules ([ '@embark/blockchain', '@embark/storage', '@embark/core', ... ]) and process.argv to @embark/cli.
embark package could be installed globally or locally, it would work either way; we can still support the shimming behavior, which is a distinct behavior from hooking into @embark/core.

I'm sure that all sounds complex, but here are the key benefits:

only the embark package exposes a "bin" entry
if @embark/[name] packages are mistakenly installed globally, nothing bad happens but they're not usable in that way
globally installed embark would have @embark/cli and @embak/new as dependencies, but that's a special case and opaque to the user
if someone wants to drive @embark modules from a completely different cli or programmatic interface, they can! they can write that interface to wire up to any number of @embark modules' cmd.js / cmd_controller.js scripts — they could do that directly, or make use of @embark/cli, depending on what best suits their use case.

@PascalPrecht agreed on nearly all points re: namespacing. See my previous comment, will definitely appreciate some feedback.
A big gain of the approach I outlined is that it would be possible to do npx embark new [--options] and it would be super fast and efficient. You can do that right now, but the temporary-install work at the beginning of npx embark ... makes it impractical because all of embark has to be installed first. If the bulk is carved off into @embark packages, the the situation is much improved.
I think keeping embark (not namespaced) as the sole "door" to the cli facilities implemented in the @embark packages would have a lot of benefits. From an Embark user's perspective:
[npx | npm run] embark [cmd] [--options]

^ that will simply offer what he wants inside or outside a DApp, regardless of whether embark has been installed globally or locally, and the plumbing to the @embark modules and peer dependencies inside his DApp would be an implementation detail that's behind the scenes.

@PascalPrecht to answer your question about resolving modules:
In both the Embark 3.1 series and 4 alphas (not sure about <=3.0.x), DApps might include a .babelrc that enables babel plugins/presets listed in the DApp's dependencies, which sometimes (not always) rely on Embark to provide those packages with peer dependencies such as @babel/core. In the 3.1.x series, there were some hacks (mysterious double-runs of webpack, process.chdir() games) that allowed webpackProcess to find modules inside both the DApp and Embark. babel-loader is an example of module inside Embark, while babel v6 plugins might have been supplied by the DApp.
Starting with 3.2.x, things got more complicated with the ejectable webpack config, which expects Embark to provide it with the lodash.clonedeep and glob packages, as well as a bunch more (compared to 3.1.x) babel related things. When the webpack config is inside embark's file tree, that's mostly[+] not a big deal because node's lookup procedure starts at __dirname of the script. BUT when the webpack config is inside the DApp... what to do?? That's where NODE_PATH and later "custom require" (old, new) came into play.
[+] "mostly", because even a non-ejected config can have problems if a DApp is using a babel plugin that needs @babel/core and the DApp is expecting Embark to provide it — in that case NODE_PATH is still needed whether Embark is install globally or locally, in the latter case because of shrinkwrap.
While the NODE_PATH and "custom require" workarounds are mostly serving the needs of the webpack config, similar workarounds would be necessary if there's ever another case of an "ejectable" script, i.e. one that might run from within embark's file tree, or maybe from within the DApp's file tree. Also, DApp authors in the wild might start relying on things in Embark's node_modules as pseudo-transitive dependencies precisely because we're using NODE_PATH and therefore making them available to the DApp. If we upgrade those dependencies, a DApp might break if we upgraded to a version that's incompatible; that is, we may have dealt with the upgrade on our end (in Embark's internals), but for the DApp author it would be a surprise. If we're not careful, we might even introduce that kind of pseudo-transitive dependency relationship in our own templates and test apps without being fully aware of it.
Another case when a DApp can try to indirectly resolve a dependency from Embark's node_modules is related to the "versions" section of a DApp's embark.json. That situation is a little different, and it can flip around such that Embark directly resolves a dependency from a DApp's .embark/versions directory.
If we step back from all of these situations and consider the bigger picture, they can all be better expressed as peer dependency relationships between a DApp and Embark. For example, glob and lodash.clonedeep could be encapsulated in an @embark/support package that's listed in the "peerDependencies" of @embark/core's package.json. Likewise, @babel/core and other babel-related things could be listed in "peerDependencies".
That will work great, but we'll need both @embark/core and all the peer dependencies to be installed in the DApp's node_modules in order for the DApp and Embark to be able find them without resorting to NODE_PATH and/or "custom require".


NPE during creation of a property for a specific class

OrientDB Version: 2.2.22
Java Version: 7+
OS: linux
It seems that OrientDB doesn't like class with name "Report". After creation of such class there are lots of interesting stuff is happening. And the only one solution: rollback to previous backup.
Creation of a new property for class "Report" or attempt to retrieve newly created class lead to the NPE in the same place.
Creation of property:
java.lang.NullPointerException
     at com.orientechnologies.orient.core.storage.impl.local.paginated.OPaginatedCluster.getEntries(OPaginatedCluster.java:1425)
     at com.orientechnologies.orient.core.storage.impl.local.OAbstractPaginatedStorage.count(OAbstractPaginatedStorage.java:1158)
     at com.orientechnologies.orient.core.db.document.ODatabaseDocumentTx.countClusterElements(ODatabaseDocumentTx.java:816)
     at com.orientechnologies.orient.core.iterator.ORecordIteratorClass.config(ORecordIteratorClass.java:141)
     at com.orientechnologies.orient.core.iterator.ORecordIteratorClass.<init>(ORecordIteratorClass.java:90)
     at com.orientechnologies.orient.core.iterator.ORecordIteratorClass.<init>(ORecordIteratorClass.java:68)
     at com.orientechnologies.orient.core.sql.OCommandExecutorSQLResultsetAbstract.searchInClasses(OCommandExecutorSQLResultsetAbstract.java:479)
     at com.orientechnologies.orient.core.sql.OCommandExecutorSQLResultsetAbstract.searchInClasses(OCommandExecutorSQLResultsetAbstract.java:468)
     at com.orientechnologies.orient.core.sql.OCommandExecutorSQLSelect.searchInClasses(OCommandExecutorSQLSelect.java:1004)
     at com.orientechnologies.orient.core.sql.OCommandExecutorSQLResultsetAbstract.assignTarget(OCommandExecutorSQLResultsetAbstract.java:209)
     at com.orientechnologies.orient.core.sql.OCommandExecutorSQLSelect.assignTarget(OCommandExecutorSQLSelect.java:530)
     at com.orientechnologies.orient.core.sql.OCommandExecutorSQLSelect.executeSearch(OCommandExecutorSQLSelect.java:512)
     at com.orientechnologies.orient.core.sql.OCommandExecutorSQLSelect.execute(OCommandExecutorSQLSelect.java:488)
     at com.orientechnologies.orient.core.sql.OCommandExecutorSQLDelegate.execute(OCommandExecutorSQLDelegate.java:74)
     at com.orientechnologies.orient.core.storage.impl.local.OAbstractPaginatedStorage.executeCommand(OAbstractPaginatedStorage.java:3200)
     at com.orientechnologies.orient.core.storage.impl.local.OAbstractPaginatedStorage.command(OAbstractPaginatedStorage.java:3138)
     at com.orientechnologies.orient.core.command.OCommandRequestTextAbstract.execute(OCommandRequestTextAbstract.java:69)
     at com.orientechnologies.orient.core.metadata.schema.OClassImpl.checkPersistentPropertyType(OClassImpl.java:2186)
     at com.orientechnologies.orient.core.metadata.schema.OClassImpl.addPropertyInternal(OClassImpl.java:1812)
     at com.orientechnologies.orient.core.metadata.schema.OClassImpl$6.call(OClassImpl.java:2606)
     at com.orientechnologies.orient.core.metadata.schema.OClassImpl$6.call(OClassImpl.java:2603)
     at com.orientechnologies.orient.core.db.OScenarioThreadLocal.executeAsDistributed(OScenarioThreadLocal.java:70)
     at com.orientechnologies.orient.core.metadata.schema.OClassImpl.addProperty(OClassImpl.java:2603)
     at com.orientechnologies.orient.core.metadata.schema.OClassImpl.createProperty(OClassImpl.java:807)

Count of documents for a class:
Caused by: java.lang.NullPointerException
	at com.orientechnologies.orient.core.storage.impl.local.paginated.OPaginatedCluster.getEntries(OPaginatedCluster.java:1425)
	at com.orientechnologies.orient.core.storage.impl.local.OAbstractPaginatedStorage.count(OAbstractPaginatedStorage.java:1158)
	at com.orientechnologies.orient.core.db.document.ODatabaseDocumentTx.countClusterElements(ODatabaseDocumentTx.java:816)
	at com.orientechnologies.orient.core.db.document.ODatabaseDocumentTx.countClusterElements(ODatabaseDocumentTx.java:770)
	at com.orientechnologies.orient.core.metadata.schema.OClassImpl.count(OClassImpl.java:1510)
	at com.orientechnologies.orient.core.metadata.schema.OClassImpl.count(OClassImpl.java:1503)

If "Report" is so specific - please make it a keyword.

@PhantomYdn just to clarify is it 2.2.2 version?

I'm sorry - you are right. I meant 2.2.22

@PhantomYdn do you have broken database, which you are talking about? Do you have logs from this database? Preferably since the creation of a class Report? That is very important.

Backup was provided through Skype.

Fixed. @santo-it description for release notes "In early versions of OrientDB deleted files did not preserve their ids correctly, as result after upgrade to latest version and creation of the cluster with the same name  all cluster files are assigned the same id, so one file overwrites another file in file system and created cluster contains incomplete information about its state. "

@laa , thank you a lot!


question about edit text dialog

is it possible to add two edit text fields in input dialogs using a custom layout?
thanks:)

This is a possible duplicate of multiple issues.
Are you asking if you can add multiple edit text fields to a custom layout. Why wouldn't you be able to?

Done, thank You:)

hey guy how you could solve this problem ... could you help me and write your code in here...

You Can see my implementation here
https://github.com/enricocid/iven-feed-reader
https://github.com/enricocid/iven-feed-reader/blob/master-as/project/app/src/main/res/layout/add_feed_layout.xml
addFeed() method in https://github.com/enricocid/iven-feed-reader/blob/master-as/project/app/src/main/java/com/iven/lfflfeedreader/mainact/ListActivity.java


OlDrawHandler test seems to be flaky

Safari 16.4 (Linux x86_64) absoluteOlDrawHandler.test.206880966.js OlDrawHandler when deactivated over olMap writes features to kml format for persisting purpose FAILED
	Expected undefined to contain '<kml'.
	<Jasmine>
	@/tmp/_karma_webpack_669706/commons.js:395514:74
Chrome Headless 114.0.5735.35 (Linux x86_64): Executed 3075 of 3075 SUCCESS (1.315 secs / 1 min 22.794 secs)
Firefox 113.0 (Linux x86_64): Executed 3075 of 3075 SUCCESS (0.885 secs / 52.827 secs)
Safari 16.4 (Linux x86_64): Executed 1695 of 3075 (1 FAILED) (0 secs / 1 min 8.701 secs)
Safari 16.4 (Linux x86_64) absoluteOlDrawHandler.test.206880966.js OlDrawHandler when deactivated over olMap writes features to kml format for persisting purpose FAILED
	Expected undefined to contain '<kml'.
	<Jasmine>

Seems not to hurt anymore


Hydration failed because the initial UI does not match what was rendered on the server on version2

I am still having hydration error whenever I insulted my local image although I have recently upgraded to version 2.

Here is an error log
Unhandled Runtime Error
Error: Hydration failed because the initial UI does not match what was rendered on the server.

See more info here: https://nextjs.org/docs/messages/react-hydration-error

Call Stack
throwOnHydrationMismatch
node_modules/.pnpm/react-dom<EMAIL_ADDRESS>(12507:0)
tryToClaimNextHydratableInstance
node_modules/.pnpm/react-dom<EMAIL_ADDRESS>(12520:0)
updateHostComponent
node_modules/.pnpm/react-dom<EMAIL_ADDRESS>(19902:0)
beginWork
node_modules/.pnpm/react-dom<EMAIL_ADDRESS>(21618:0)
HTMLUnknownElement.callCallback
node_modules/.pnpm/react-dom<EMAIL_ADDRESS>(4164:0)
Object.invokeGuardedCallbackDev
node_modules/.pnpm/react-dom<EMAIL_ADDRESS>(4213:0)
invokeGuardedCallback
node_modules/.pnpm/react-dom<EMAIL_ADDRESS>(4277:0)
beginWork$1
node_modules/.pnpm/react-dom<EMAIL_ADDRESS>(27451:0)
performUnitOfWork
node_modules/.pnpm/react-dom<EMAIL_ADDRESS>(26557:0)
workLoopSync
node_modules/.pnpm/react-dom<EMAIL_ADDRESS>(26466:0)
renderRootSync
node_modules/.pnpm/react-dom<EMAIL_ADDRESS>(26434:0)
performConcurrentWorkOnRoot
node_modules/.pnpm/react-dom<EMAIL_ADDRESS>(25738:0)
workLoop
<EMAIL_ADDRESS>(266:0)
flushWork
<EMAIL_ADDRESS>(239:0)
MessagePort.performWorkUntilDeadline
<EMAIL_ADDRESS>(533:0)

And here is my package.json
{
  "name": "docs",
  "private": true,
  "scripts": {
    "dev": "next",
    "start": "next start",
    "build": "next build"
  },
  "author": "Shu Ding",
  "license": "MIT",
  "dependencies": {
    "@code-hike/mdx": "^0.7.4",
    "clsx": "^1.2.1",
    "framer-motion": "^7.3.2",
    "next": "^13.0.5",
    "nextra": "2.0.1",
    "nextra-theme-docs": "2.0.1",
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "react-icons": "^4.7.1",
    "shiki": "^0.11.1"
  },
  "devDependencies": {
    "@types/node": "^18.11.9",
    "autoprefixer": "^10.4.13",
    "postcss": "^8.4.19",
    "tailwindcss": "^3.2.4",
    "typescript": "^4.9.3"
  }
}

can you share your repository so I'll take a look at the problem?

@B2o5T Here you go link
I haven't committed yet but this would still let you know clear image of how error was made.

This code provoke a hydration error, since it's not related to Nextra problem, I'll close it

here is fix


cmd/objdump: always assume 64 bit mode even if it is 32 bit for x86 CPU

See following code.
https://github.com/golang/go/blob/ee4fbbc6211cd978f199dd26ab73ff72cc8d95fd/src/cmd/internal/objfile/disasm.go#L298-L317
disasm_386 and disasm_amd64 pass its own CPU mode to disasm_x86, however disasm_x86 always use the hard coded value 64.
I'm not familiar with CPUs, so I cannot provide minimal example. But this is probably a bug.

@hirochachacha
I think that the x86asm means 80x86, including i386 and amd64. And the second parameter of the function description of x86asm.Decode() handles 16, 32, 64 bit processor mode.
'''
func Decode(src []byte, mode int) (inst Inst, err error)
'''
Decode decodes the leading bytes in src as a single instruction. The mode arguments specifies the assumed processor mode: 16, 32, or 64 for 16-, 32-, and 64-bit execution modes.

@dougpuob yes, so, what conclusion are you implying? Assuming 64-bit execution mode for the binary that is created for 32 bit CPU is right?

@hirochachacha
According to the second parameter of the x86asm.decode1() function treats input binary array, src, as i386 or amd64 opcode then decodes a single instruction (assembly code) of i386 or amd64.
x86asm.Decode(i386_binary_stream, 86);    // decodes a single instruction for i386
x86asm.Decode(amd64_binary_stream, 64);// decodes a single instruction for amd64

See the return data type of Decode() function is Inst, Inst.Op is the opcode of the single instruction; Inst.Len is how many byte combine the single instruction from src.
type Inst struct {
	Prefix   Prefixes // Prefixes applied to the instruction.
	Op       Op       // Opcode mnemonic
	Opcode   uint32   // Encoded opcode bits, left aligned (first byte is Opcode>>24, etc)
	Args     Args     // Instruction arguments, in Intel order
	Mode     int      // processor mode in bits: 16, 32, or 64
	AddrSize int      // address size in bits: 16, 32, or 64
	DataSize int      // operand size in bits: 16, 32, or 64
	MemBytes int      // size of memory argument in bytes: 1, 2, 4, 8, 16, and so on.
	Len      int      // length of encoded instruction in bytes
	PCRel    int      // length of PC-relative address in instruction encoding
	PCRelOff int      // index of start of PC-relative address in instruction encoding
}

@dougpuob So, what's your conclusion?

I think it is not about assuming 64-bit or 32-bit execution mode, input array is 64-bit data and you indicate 64, then function return a  64-bit instruction, so and 32-bit. My conclusion is the function returns what you told him, didn't assume.

It certainly sounds like a bug.  Does it actually mis-disassemble anything though?
Maybe disassemble a Go binary with and without the obvious fix and diff them.

z.go
package main

import "fmt"

func main() {
	fmt.Print("Hello World!")
}

patch
diff --git a/src/cmd/internal/objfile/disasm.go b/src/cmd/internal/objfile/disasm.go
index ede1141a3e..c99c34b179 100644
--- a/src/cmd/internal/objfile/disasm.go
+++ b/src/cmd/internal/objfile/disasm.go
@@ -304,7 +304,7 @@ func disasm_amd64(code []byte, pc uint64, lookup lookupFunc, _ binary.ByteOrder)
 }

 func disasm_x86(code []byte, pc uint64, lookup lookupFunc, arch int) (string, int) {
-       inst, err := x86asm.Decode(code, 64)
+       inst, err := x86asm.Decode(code, arch)
        var text string
        size := inst.Len
        if err != nil || size == 0 || inst.Op == 0 {

diff (before patch - after patch for z.o which is created by GOARCH=386 go tool compile z.go)
--- z.txt	2017-10-02 07:41:32.000000000 +0900
+++ z2.txt	2017-10-02 07:42:32.000000000 +0900
@@ -1,13 +1,13 @@
 TEXT %22%22.main(SB) gofile../Users/hiro/z.go
-  z.go:5		0x3bb			658b0d00000000		MOVL GS:0(IP), CX	[3:7]R_TLS_LE
+  z.go:5		0x3bb			658b0d00000000		MOVL GS:0, CX		[3:7]R_TLS_LE
   z.go:5		0x3c2			3b6108			CMPL 0x8(CX), SP
   z.go:5		0x3c5			7647			JBE 0x40e
   z.go:5		0x3c7			83ec20			SUBL $0x20, SP
   z.go:6		0x3ca			c744241800000000	MOVL $0x0, 0x18(SP)
   z.go:6		0x3d2			c744241c00000000	MOVL $0x0, 0x1c(SP)
-  z.go:6		0x3da			8d0500000000		LEAL 0(IP), AX		[2:6]R_ADDR:type.string
+  z.go:6		0x3da			8d0500000000		LEAL 0, AX		[2:6]R_ADDR:type.string
   z.go:6		0x3e0			89442418		MOVL AX, 0x18(SP)
-  z.go:6		0x3e4			8d0500000000		LEAL 0(IP), AX		[2:6]R_ADDR:%22%22.statictmp_0
+  z.go:6		0x3e4			8d0500000000		LEAL 0, AX		[2:6]R_ADDR:%22%22.statictmp_0
   z.go:6		0x3ea			8944241c		MOVL AX, 0x1c(SP)
   z.go:6		0x3ee			8d442418		LEAL 0x18(SP), AX
   z.go:6		0x3f2			890424			MOVL AX, 0(SP)
@@ -20,19 +20,19 @@
   z.go:5		0x413			eba6			JMP %22%22.main(SB)

 TEXT %22%22.init(SB) gofile..<autogenerated>
-  gofile..<autogenerated>:1	0x432			658b0d00000000		MOVL GS:0(IP), CX	[3:7]R_TLS_LE
+  gofile..<autogenerated>:1	0x432			658b0d00000000		MOVL GS:0, CX		[3:7]R_TLS_LE
   gofile..<autogenerated>:1	0x439			3b6108			CMPL 0x8(CX), SP
   gofile..<autogenerated>:1	0x43c			762a			JBE 0x468
-  gofile..<autogenerated>:1	0x43e			0fb60500000000		MOVZX 0(IP), AX		[3:7]R_ADDR:%22%22.initdone·
+  gofile..<autogenerated>:1	0x43e			0fb60500000000		MOVZX 0, AX		[3:7]R_ADDR:%22%22.initdone·
   gofile..<autogenerated>:1	0x445			80f801			CMPL $0x1, AL
   gofile..<autogenerated>:1	0x448			7601			JBE 0x44b
   gofile..<autogenerated>:1	0x44a			c3			RET
   gofile..<autogenerated>:1	0x44b			7507			JNE 0x454
   gofile..<autogenerated>:1	0x44d			e800000000		CALL 0x452		[1:5]R_CALL:runtime.throwinit
   gofile..<autogenerated>:1	0x452			0f0b			UD2
-  gofile..<autogenerated>:1	0x454			c6050000000001		MOVB $0x1, 0(IP)	[2:6]R_ADDR:%22%22.initdone·
+  gofile..<autogenerated>:1	0x454			c6050000000001		MOVB $0x1, 0		[2:6]R_ADDR:%22%22.initdone·
   gofile..<autogenerated>:1	0x45b			e800000000		CALL 0x460		[1:5]R_CALL:fmt.init
-  gofile..<autogenerated>:1	0x460			c6050000000002		MOVB $0x2, 0(IP)	[2:6]R_ADDR:%22%22.initdone·
+  gofile..<autogenerated>:1	0x460			c6050000000002		MOVB $0x2, 0		[2:6]R_ADDR:%22%22.initdone·
   gofile..<autogenerated>:1	0x467			c3			RET
   gofile..<autogenerated>:1	0x468			e800000000		CALL 0x46d		[1:5]R_CALL:runtime.morestack_noctxt
   gofile..<autogenerated>:1	0x46d			ebc3			JMP %22%22.init(SB)

It looks like this is a root cause of https://github.com/golang/go/issues/19988.

@dougpuob

My conclusion is the function returns what you told him, didn't assume.

I'm saying that disasm_x86 don't pass the correct argument to x86asm.Decode.

Yes, that looks like using arch instead of 64 in disasm_x86 is correct.
@hirochachacha Can you send me a CL with your fix?

Sure.


Add a link back to the app via a breadcrumb.

An alternate approach that uses the existing breadcrumbs and also has a really sensible default.

@jnunemaker Sorry this took so long, but life got a little hectic for me.
I think I prefer the way this turned out vs. #89.

Tweaked a few things: https://github.com/jnunemaker/flipper/compare/48b073006604a0671bbfcfa95a8d9e632b660c41...0c5b88232e60d9da5598c6fb11a806af89087f29

Looks great. Thanks!


Updated InputDecorator properties, changed setState type

Basically hideDivider: true should now be border: null
More info here: #https://github.com/flutter/flutter/pull/13734
Dart Analysis server complains about setState :

A function of type '(() → void) → void' can't be assigned to a location of type '(dynamic) → void'.

Thanks!


Further fixes/improvements to WebRequests

Fixes #1110

Makes timeouts use cancellation tokens.
Fixes timeout retries.
Improves the use of async/await.
Makes use of cancellation tokens more reliable.

No way to disable/choose number of retries any more?

Think this is looking good now 👍


Add ability complete flight

For #8441
I add ability completeFlight
It immediately finish a flight in progress and just jump to the end.
The following Sandcastle Code can run completeFlight
var viewer = new Cesium.Viewer("cesiumContainer");
var destination = Cesium.Cartesian3.fromDegrees(126.990525, 37.493530, 3000);

viewer.camera.flyTo({
  destination: destination,
    orientation: {
    heading: Cesium.Math.toRadians(0),
    pitch: Cesium.Math.toRadians(-60),
    roll: Cesium.Math.toRadians(0),
  },
  duration: 5,
});

setTimeout(function() {
  viewer.camera.completeFlight();
}, 3000);

Thanks for the pull request @SambaLim!

:heavy_check_mark: Signed CLA found.
:grey_question: CHANGES.md was not updated.

If this change updates the public API in any way, please add a bullet point to CHANGES.md.

:grey_question: Unit tests were not updated.

Make sure you've updated tests to reflect your changes, added tests for any new code, and ran the code coverage tool.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.
[ ] Works (or fails gracefully) in IE11.

I think positively about the same change as I mentioned earlier.
Thank you for your comment.
And I fix completeFlight code to callback "flight completed".
The following Sandcastle Code can run fixed completeFlight
var viewer = new Cesium.Viewer("cesiumContainer");
var destination = Cesium.Cartesian3.fromDegrees(126.990525, 37.493530, 3000);

function testComplete() {
  console.log('It Complete!');
}

function testCancel() {
  console.log('It Cancel!');
}

viewer.camera.flyTo({
  destination: destination,
    orientation: {
    heading: Cesium.Math.toRadians(0),
    pitch: Cesium.Math.toRadians(-60),
    roll: Cesium.Math.toRadians(0),
  },
  duration: 5,
  complete: testComplete,
  cancel: testCancel
});

setTimeout(function() {
  viewer.camera.completeFlight();
}, 3000);

Sorry for not getting back to you sooner @SambaLim, I just had to carve out some time to look more into this.  I think those are the only comments I had.  Thanks again for the pull request!

Thanks for your delicate reply.
I fix my code with your reply.
It is safer to use _currentFlight rather than newOption

Thanks @SambaLim, I test this out and something isn't quite right.
At the end of http://localhost:8080/Apps/Sandcastle/index.html?src=Camera.html, add
Sandcastle.addToolbarButton('Complete Flight', ()=>{
  scene.camera.completeFlight();
});

Then run the example and select Fly to Location with heading, pitch and roll. While the flight is happening, hit the Complete Flight button. The flight finishes, but with a different view than if you just let the flight complete on its own.  Looks like we are losing something about the flight.

Thanks to reply @mramato . I appreciate your kindness.
I fix completeFlight loose heading, pitch, roll.
Because newOptions doesn't have an orientation property.
So I create options and use it.
If you run example and hit Complete Flight, It finish well.

bump @mramato

Thanks @SambaLim, sorry for not getting back to you sooner.  I added a test and tweaked the doc.  I'll merge as soon as CI passes and this will go out with tomorrow's release.

Thanks @mramato !
I am happy to contribute to Cesium.js. Thank you for coming.


input doesnt work

for some reason, with any binary, the game launches but i cant get past the "press any key to regain control" screen. its the same with allure of the stars.

Hi! Thank you for the report. Which binaries do you mean? Could you try some older versions? What's your OS? What's your SDL library version?

One more thing: could you try not only keyboard, but also the mouse? Could you try a commandline option that starts the game not in the mode with "press any key to regain control"?

OS: linux
SDL version : 2.0.20
mouse doesnt work either
everything works fine when its run through the terminal, it seems like its the SDL window that doesnt take any inputs, including close.

Thank you.
I wonder what they broke again in SDL. I see SDL 2.0.20 is in Debian testing (https://packages.debian.org/bookworm/libsdl2-2.0-0 and Ubuntu 22.04, so it should soon be available to ordinary users. I guess I won't be able to debug until then.
Any help is kindly welcome.

And it also seems that it can't compile with sdl2 2.0.20: https://github.com/haskell-game/sdl2/issues/245

I merged some polling fix, please try with sdl2 master.

I've retried the windows CI (it uses sdl2 master branch) and it still doesn't build: https://ci.appveyor.com/project/Mikolaj/lambdahack/build/job/mun11rbmig1cb575
I can't test if it builds on Linux and whether it works once built. @aloaf: can you?

it builds, but now instead of not recognizing input at all, it completely stops responding after any input.

Oh dear. Was that with version <IP_ADDRESS> of sdl2?


Godot 4.3 buttons switching to hover style after being pressed on IOS export

Tested versions
-Reproduced on version 4.3 stable
Worked correctly on 4.2.1 stable
System information
MacBook Pro - OS 14.4 (23E214), using Godot 4.3 stable. iPhone 13 Pro using 17.6.1, and iPad mini 17.5.1 and 17.6.1
Issue description
I installed Godot 4.3 stable. I migrated a project I was working on in Godot 4.2.1 stable. When I exported it to my iPhone, the buttons would switch to the hover style after being pressed. This did not happen on 4.2.1. This occurred on both regular buttons as well as texture buttons.
Steps to reproduce
I then created a brand new project in 4.3, created just a simple button with default style in the center, made it 400x400, set an empty style for the focus so it didn't have the border. I also added a texture button with a default style, a hover style, and pressed style. I then exported it to my iPhone to test.
When I drag my finger from outside the button, into the button, it shows the hover style when in the center like expected, and when I move out, it goes back to the default like it should. When I actually press on the button, it shows the pressed style, but then instead of goign back to the normal, it switches to the hover even though my finger isn't on the button any more. If I press on another button, or any area outside the button, it then switches back to the normal style. This happens for both the default button style as well as the texture button.
I reproduced this in 4.2.1 stable, and the buttons do not respond to the hover/moving finger in and out of the button space, which is fine in this case. I did not design my project with this in mind. However the buttons do switch back to the default normal style after being pressed, which is what I want to happen again on 4.3.
I only have iOS devices to test with, not sure if this happens on Android as well.
Here is a link to a short demo of what I am trying to explain: https://youtu.be/jorcIJNQdwg
Minimal reproduction project (MRP)
Button Example.zip
To test on iOS, you'll need to put in your own Apple Store team ID as well as a bundle identifier.
I created simple Normal, Hover, and Pressed textures to better demonstrate it. You can see the differences on the default button as well, it goes slightly grey for the hover, and darker when pressed.

For anyone who comes across this and is looking for a "work around", this is what I ended up doing:
I created a class called MobileButtonFix, and MobileTextureButtonFix where I replaced the hover style with the normal style, and that got it back to how I wanted/expected it to work on mobile.
Button version:
extends Button
class_name MobileButtonFix
func _ready():
var os_name = OS.get_name()
if os_name == "Android" || os_name == "iOS":
remove_hover_style()
func remove_hover_style():
var normal_style = get_theme_stylebox("normal")
add_theme_stylebox_override("hover", normal_style)
Texture Button version:
extends TextureButton
class_name MobileTextureButtonFix
func _ready():
var os_name = OS.get_name()
if os_name == "Android" || os_name == "iOS":
remove_hover_style()
func remove_hover_style():
var normal_style = get_theme_stylebox("normal")
add_theme_stylebox_override("hover", normal_style)
With it being a class, I just replaced the button/texture button nodes with this and it works for me, and only applies when it's on android or ios, so desktop will still have the hover style correctly.


nk3 update: Handle bootloader connection issues

Users report issues with the bootloader connection after the reboot.
Apparently, the udev rules are not yet applied when we try to connect to
the device.  We mitigate this issue by performing up to three retries.
This also adds a reference to the udev rules to the error message if
nitropy is running on Linux.
Fixes https://github.com/Nitrokey/pynitrokey/issues/167

Thanks for the review!  I will add the link once the guide is available.


Add support for ~ separated resource names

In ads API, we use resource names which contain ~ to delimit multiple IDs in a path segment. For example:
message AdGroupAd {
  option (google.api.resource) = {
    type: "googleads.googleapis.com/AdGroupAd"
    pattern: "customers/{customer_id}/adGroupAds/{ad_group_id}~{ad_id}"
  };

The current microgenerator implementation doesn't appear to support this, and instead just generates a single param in its place.
Link to protos: http://shortn/_zIPrXkqkoU

Fixed in $450.


User add/password change relies on adduser and chpasswd

We assume they are there, but that's not always true. One way to workaround chpasswd is generating the user password in-place, similarly we can transliterate users to entities

Added support for the underlying entities library here: https://github.com/mudler/entities/commit/8814e761462e3d9041c8c34aaa7d23980d14beac - will try to reuse that lib instead of calling the CLI tools


Can't use meta::doForAllMembers for types with just one registered member

Thanks for sharing this library, it's really useful. However I discovered that it is not possible to compile (using MSVC15) code that relies on meta::doForAllMembers when only one member is registered for a type. I think it would be sensible to not force the user to handle this as a special case.
I'm not a meta programming expert but I tracked it down to the apply and apply_impl methods in template_helpers.inl where
std::make_index_sequence<std::tuple_size<std::decay_t<Tuple>>::value>{};

won't create a sequence for std::tuple_size<std::decay_t<Tuple>>::value == 1. I created a temporary fix by providing overloads for this case without the use of the sequence. I made a pull request from my fix but maybe you want to handle this differently.
The following code generates the compiler error:
#include "Meta.h"

#include <iostream>

struct TestStruct
{
	int someValue;
	int someValue2;
};

namespace meta
{
	template <>
	inline auto registerMembers<TestStruct>()
	{
		return members(
			member("someValue", &TestStruct::someValue)
			// Works if following line is uncommented:
			// , member("someValue2", &TestStruct::someValue2)
		);
	}
}

void main(int, char**)
{
	TestStruct test{42, 4711};

	std::cout << "Values in TestStruct:\n";
	meta::doForAllMembers<TestStruct>(
		[&test](auto& member) {
			std::cout << "* " << member.getName() << ": " << member.get(test) << '\n';
		});
}

If you're interested, here's the compiler output: cl_error.txt

You're welcome :)
This was indeed the problem with VS, probably compiler problem: it couldn't deduce template arguments for index_sequence properly when make_index_sequence was used.
Instead of going with std::enable_if, I've created function which returns std::index_sequence for specified number of args and does it without make_index_sequence for 1 member.
(Btw, this problem was fixed with VS 2015 Update 3)

Cool, thanks for the fix. At the moment I'm getting a linker error because meta::detail::makeIndexSequence<1>(void) is defined in multiple units. I don't have time to look into it right now but I'll check it out tonight. I tried to compile it with with VS15 Preview Update 2 and VS2015 Update 3.

Oops! :D
Fixed this by making the function inline

Thanks. Works as intended now. :)

You're welcome :)


Eigen assert errors (Clang + Visual Studio 2019)

For a single simple test example, (data/binary_input/apple-32/input.png), polyfit will sometimes manage to run and produce the desired output, but most of the time it will crash due to an eigen assert in the triangular solver. According to my debug trace, this happens due to CurveSequenceFitter::solve(), called from MultiPolygonTracer::trace(). Is this software not yet stable, or am I doing something wrong (my platform is OS X)?

Hi, thank you for trying out the software on OS X and creating the respective pull request for clang :)
The software was developed on Windows using the Visual Studio 2017 compiler and I did not have a chance to test it on other platforms. All the inputs/outputs in the directory run fine under these conditions, but I encounter similar issues with the 2019 compiler, which is probably related to the one you are facing with Clang. I am very sorry about this.
Support for different platform is something worth addressing. To do so the most effective way is probably to (1) set up a unit test, (2) turn on more compiler warnings (3) debug and repeat.
Similarly, I am making it more clear in the README that this is an issue.
I am keeping this issue opened as reference (editing the title) and will merge your pull request when I get to do the above, which won't be in the immediate future, but will try to give it a shot in the next few weeks.

I did find what I'm pretty sure was a bug (added to my pull request #2 ) relating to bitwise operator precedence.

Alas, one would expect that such results should be deterministic, no?  This seems like it could be serious... hmm

It's not lack of determinism in the algorithm, there is a bug in the code preventing the curve optimization stage to run. I obtain the same result by commenting out multi_polygon.cpp:256 (_solve_curves()). If you look closely, the per-corner primitive classification is the same between the two results, but the curves in the bottom row correspond to the initial guess.
As you pointed out in the first issue, the crashes you were obtaining were exactly in the CurveSequenceFitter::solve(), where the global optimization happens, hence the correlation between the two events.
I presume you managed to obtain the results by running it multiple times on the code compiled on Clang/OS X. As discussed above this is problem needs to be further investigated. I did not test the code on multiple platforms (no doubt I should have done that) and it's unfortunate that it's not showing up in VS2017. I will do my best to address it soon, after I've set up a simple test to make sure that outputs remain unchanged between commits.

According to my research on the subject, the particular eigen assert error I get can be caused by a non-triangular sparse matrix being passed to the sparse triangular solver.


Add support for configurable countdown value for AFKTimeout

Relevant components:

[ ] Signalling server
[ ] Common library
[X] Frontend library
[X] Frontend UI library
[ ] Matchmaker
[ ] Platform scripts
[ ] SFU

Problem statement:
As a user of the PixelStreamingInfrastructure library, I would like to be able to configure the countdown provided to users after an AFK timeout has elapsed. Currently this countdown value is hardcoded to 10 seconds.
Solution
This PR adds a new NumericParameter called AFKCountdown which can be configured at the same time as other AFK properties when the PixelStream is first created. The default value is 10 seconds, but this can be set to be a total of 3 minutes if desired (this upper limit can totally be adjusted based on PR feeedback, the duration we'd like to use on our team is 60 seconds).
Documentation
I have updated Frontend/Docs/Timing Out Inactive Connections.md to include a reference to the new variable/setting (I also fixed the formatting of the Markdown table which wasn't rendering correctly).
Test Plan and Compatibility
I have not yet created tests to verify the feature yet (if this is something required for the PR I wanted to wait to get the feedback/comments first).
I did find existing tests in AFKController.test.ts which exercise the countdown feature (see test 'should activate AFK timer and trigger it after specified delay if it has been enabled from settings'). I'd be happy to update this test to verify a different number of seconds for the countdown if that would be useful.
Context
We initially created this change off of the UE5.3-1.0.4 tag that we're using for our project. The changes have been rebased onto the master branch for this PR.

Thank you very much for merging this @mcottontensor.
I wanted to ask it it's possible to also back port this to an earlier release branch (in particular UE5.3-1.0.X). That way we could remove the dependency on our fork and use an updated version instead, a UE5.3-1.0.6 tag I guess.
Thanks!

💚 All backports created successfully

Status
Branch
Result

✅
UE5.3

✅
UE5.4

Note: Successful backport PRs will be merged automatically after passing CI.
Questions ?
Please refer to the Backport tool documentation

I have merged this back into UE5.3 and UE5.4 and pushed releases for each. Let me know how that goes.
Cheers.

That's phenomenal! Thank you very much for your help @mcottontensor! 🙂


Typos

Looks good to me. Would you mind rebasing on master and removing the merge commit?
I can help pull the change through our internal CI.

Done

Thanks very much for your contribution, I have merged it into master.


More details

Hi, I think your bundle could be useful.
But I need some more config details:
The readme.md file is very skinny.

You have to add the bundle in Symfony's Appkernel.php to activate it
The config is missing completely.

I need to know which data should be in parameters.yml and config.yml
Please add 'em in the README file.
Thanks in advance.

For starters you can look at the Configuration class.

I really wasted unnecessarily lot of time looking at Configuration.php so I've created a pull request #7 to address this


Ga 47 create table access types

Jira link (if applicable)
Change description
Checklist

[x] commit messages are meaningful and follow good commit message guidelines
[x] README and other documentation has been updated / added (if needed)
[x] tests have been updated / new tests has been added (if needed)
[x] Does this PR introduce a breaking change

Is there a test for "monotonically increasing version number which is incremented each time a new version of the data is written" or are we manually testing this is working correctly?

Is there a test for "monotonically increasing version number which is incremented each time a new version of the data is written" or are we manually testing this is working correctly?

I tested manually that it is increasing everytime an insert is done as shown in ticket.


Homework 2 - For testing purposes

I guess your test worked! Now it's time to implement the real stuff! :P

Expired


Proposal: Add option to memoize toString()/hashCode()

Since the models are immutable, memoizing hashCode/toString() would be nice. This is a common use case for AutoValue's @Memoized extension as well, and would make its implementation a good reference.

@hzsweers is this issue duplicate of this one  https://github.com/apollographql/apollo-android/issues/423

Oh wat. Github gave me an error earlier so I opened this one in the process of trying again. Closed the other ¯_(ツ)_/¯


In lib/trivial/makeExtensible* allow extenders to refer to refixer …

Motivation for this change
As reported by @FRidh, pkgs.overridePackages no longer works because
that function is added to the attribute set after fixing. Precisely, that
means the include pkgs in allpackages.nix doesn't pick it up with the
rest of the final fixed package set.
This changes changes makeExtensibleWithCustomName, and by extension plain
makeExtensible so that the refixer function is added as a final extension
before fixing.
Things done
Tested manually using nix-repl. Should we create an automatic test for this?
CC @nbp for posterity---I don't expect you to have any time for this.

My comment on the issue https://github.com/NixOS/nixpkgs/pull/19496#issuecomment-264695646

I honestly think we should get rid of pkgs.overridePackages, because the only use of it is to re-evaluate the Nixpkgs fix-point with a different/additional set of packageOverride-like.  Currently we have a path attribute inside Nixpkgs, and this path can be used to re-evaluate Nixpkgs the same way.
Otherwise, we should change pkgs.overridePackages to just create a new fix-point instead of re-using the current one.
@FRidh , could you describe your use-case of pkgs.overridePackages?

Currently we have a path attribute inside Nixpkgs, and this path can be used to re-evaluate Nixpkgs the same way.

The crucial difference is that will reinfer a bunch of parameters, while with overridePackages one can modify a nixpkgs without worrying about what arguments were elsewhere provided.
For a concrete usecase, think how big nix blobs like https://github.com/reflex-frp/reflex-platform/blob/develop/default.nix#L1-L19 are currently not very composable, but could be with overridePackages.  [Ideally such things wouldn't need to exist, but in practice they often do and pave the way to changes in nixpkgs proper.]

@nbp if I understand correctly packageOverrides can only be used in your ~/.nixpkgs/config.nix. I need to override the package set on a per-project base, e.g. to add additional Python packages that other packages use as well. Most of the time just overriding the Python package set is sufficient, but I think it should be possible to override the top-level set as well.
I've added the following example to the Nixpkgs manual
let
  pkgs = import <nixpkgs> {};
  newpkgs = pkgs.overridePackages ( pkgsself: pkgssuper: {
    python27 = let
      packageOverrides = self: super: {
        numpy = super.numpy_1_10;
      };
    in pkgssuper.python27.override {inherit packageOverrides;};
  } );
in newpkgs.inkscape

Also, I don't know whether it is possible, but there should be a 'straightforward' way to exclude configuration. E.g., if I test something locally it might not work elsewhere because of some setting in ~/.nixpkgs/config.nix. This is out of scope for this issue, but still something to keep in mind.

if I understand correctly packageOverrides can only be used in your ~/.nixpkgs/config.nix.

True, but you can provide a custom one as argument of import <nixpkgs>:
let
  newpkgs = import <nixpkgs> {
    config = {
      packageOverrides = pkgs: { ... };
    };
  };
in
  newpkgs.inkscape

This example will also exclude the per-user configuration, as the packageOverrides used to do.

@nbp so that then also covers my second comment, right?

Also, I don't know whether it is possible, but there should be a 'straightforward' way to exclude configuration. E.g., if I test something locally it might not work elsewhere because of some setting in ~/.nixpkgs/config.nix. This is out of scope for this issue, but still something to keep in mind.

Anyway, I'm fine using the snippet you show. The docs just need to be updated to include this, because it is quite an important feature I would argue.

That works for 1 customization, but not for the composition-of-customizations usecase I describe above.

I guess for the composition we could just accept multiple new overlays (as called in gentoo) which are new  self: super: phases in the pipeline.  Adding these overlays next to the config argument should help at extending nixpkgs is a modular-ish fashion.
I guess we could add both environment variable / list of paths, and load all overlays in the order in which they are listed.  Of course, if some argument are provided to nixpkgs, these overlays would take precedence.
This way, we have options to get rid of packageOverrides, and make nixpkgs slightly more modular and customizable by external repositories.
I will prototype this idea tomorrow.

@Ericson2314 With this PR, if one were to use
makeExtensible (self: <... some expr involving self.extend ...>)

that would be no different than the current approach of
let topSelf = makeExtensible (self: <... some expr involving topSelf.extend ...>; in <...>

right?
Actually, now that I've thought about it some more, I suppose the difference is that topSelf in the above example captures the fixpoint of a given set of extensions, so topSelf.extend is not identical to (topSelf.extend (self: super: <...>)).extend, and therefore composition breaks down in comparison to feeding extend into the attrs before fixing (as this PR does).
If we were worried about shadowing extend as a potential package name we could, alternatively, expose __fix__ before fixing, so for the (probably rare/esoteric) cases where one might otherwise want to use self.extend, they could instead use self.__fix__ directly (less convenient, but doesn't use up another attr name). The idea being that we'd change fix' to:
# current def:
# fix' = f: let x = f x // { __unfix__ = f; }; in x;

# new def:
fix' = f: let x = f (x // { __unfix__ = f; }) // { __unfix__ = f; }; in x;

Another thought: worrying about shadowing extend is a little silly: we're already doing that from the point of view of the person using the package set (e.g. if the package set defines an extend package, no one from outside can make use of it anyway -- though other packages inside can still refer to it). That's pretty inconsistent, and this PR addresses just that.
TL;DR: I'm thinking we should merge this PR and make my proposed fix' change. Thoughts, @Ericson2314?
Sorry for the winding, stream of consciousness style prose. I figure if anyone is as sleepy as I am, they too might miss some of the finer details, so I figured I'd leave this comment as is.

Any update on this pull request?

This is no longer important. Since then we have other recommended methods that work fine so I am closing this.

(note I did not go through @cstrahan 's message. Feel free to reopen if needed)


TestActivityStartedAtSameTimeAsTimerCancel is flaky

=== CONT  TestIntegrationSuite
    integration_test.go:889:
        	Error Trace:	integration_test.go:889
        	Error:      	Received unexpected error:
        	            	workflow execution error (type: WorkflowWithLocalActivityStartWhenTimerCancel, workflowID: test-activity-start-with-timer-cancel, runID: f98b5815-9604-43b3-8fa3-14122856e257): Workflow timeout (type: StartToClose)
        	Test:       	TestIntegrationSuite

This test does not appear flaky anymore in CI


[PE-D][Tester A] No possible ways to get out of filtered list

The current version does not support a method to return to the original list after filtering. So I am trapped in the filtered list after filtering.
Good ways to improve include adding a list feature or fixing the default filter.

Labels: severity.Medium type.FeatureFlaw
original: ChangruHenryQian/ped#4

The user guide has been correctly updated to show filter default command as the correct way to return to all internship entries list.

Marked as duplicate of #142


net/rpc: docs do not say that published type must be exported

Looking at:
http://golang.org/pkg/net/rpc/
There are no mentions that a published type (type of object passed to Register) must be exported. There are only several mentions that methods must be exported.
However, when I try to register a non-exported type, it fails with:
2015/04/08 18:06:45 rpc.Register: type driver is not exported
I guess it is a documentation issue.

The very first sentence of the package comment reads
Package rpc provides access to the exported methods of an object across a
network or other I/O connection.

Moreover,

Ah, I see the distinction. Will fix.


Document test-utils setup

There is no documentation about adding the jest.setup.js and there should be.

In particular, we need to document the setup script: https://github.com/doug-wade/tybalt/blob/master/packages/core/jest.config.js#L9


Changed the addition repos to be based on ${::operatingsystemmajrelease}

rather than hard coded to 7.  This makes this compatible with older
versions of RHEL

Thanks!


Unable to use node-gyp on the intranet

I am trying to install/build node modules onthe intranet. I have access to the internal NPM repository mirroring npmjs.org, but no connection to the internet.
When I run npm install (or 'node-gyp configure build' directly), the program attempts to download https://nodejs.org/dist/v0.12.4/node-v0.12.4.tar.gz, which it clearly cannot without the access to the internet. I do have this file available on my intranet.
How do I instruct node-gyp to use the local version of this file? How do I use the tool offline?

You can untar the tarball into a directory, and then point node-gyp to that directory with the --nodedir flag. Cheers!

or don't unpack the tarball and use it as is.
NODE_VER=v10.14.1
curl -sSL https://nodejs.org/download/release/${NODE_VER}/node-${NODE_VER}-headers.tar.gz \
        -o /tmp/node-headers.tgz; \
npm config set tarball /tmp/node-headers.tgz