Update filter table don't works in some of capture

Bug Report
Please answer these questions before submitting your issue. Thanks!

What did you do? If possible, provide a recipe for reproducing the error.

Config: 3x CDC server, 1xchangefeed, at first there's 20 table count.
Update changefeed, filter 2x table:  tiup ctl:v5.0.0-nightly-20210429 cdc changefeed update --config change.toml --pd=http://<IP_ADDRESS>:2379 -c=abcde

What did you expect to see?
Only 2x table from metrics

What did you see instead?

One capture still listen 6x table

Compare cdc log between cdc server, one has incorrect filter info
53:

54:

Versions of the cluster

Upstream TiDB cluster version (execute SELECT tidb_version(); in a MySQL client):
5.0.0-nightly

TiCDC version (execute cdc version):
5.0.0-nightly

/assign @asddongmen

I can not reproduce this issue in both v5.0.0-nightly and the manster branch.
If you find the problem again, please feel free to reopen this issue.


Pageable initialized only partly

Framework version: 1.1
Implementations: Spring Boot

Scenario
Execute a paged and sorted request by using the parameters ?page=0&size=10&sort=attribute,desc
and Spring Data Commons:
<dependency>
  <groupId>org.springframework.data</groupId>
  <artifactId>spring-data-commons</artifactId>
</dependency>

See here for sorting parameters.
Expected behavior
The method parameter org.springframework.data.domain.Pageable of the @RequestMapping should be filled correctly.
Actual behavior
Only Pageable.pageSize and Pageable.pageNumber are filled, Pageable.sort is not.
Steps to reproduce
Include a dependency to Spring Data Commons:
<dependency>
  <groupId>org.springframework.data</groupId>
  <artifactId>spring-data-commons</artifactId>
</dependency>

Create the following method inside a controller:
@RequestMapping(path = "test", produces = MediaType.APPLICATION_JSON_VALUE)
public String test(@PageableDefault(size = 50) Pageable pageable) {}

Execute the request on the lambda url:
/test?page=0&size=10&sort=attribute,desc

Nevermind, was a different issue. the pageable seems to work!


Ambiguous aliased imports not reported

See the following code:
from Standard.Base import all

import Standard.Table
from Standard.Table import Table

main =
    IO.println Table.new

We can see that the identifier Table is actually imported twice and so the imports are ambiguous - it could refer to the Table module from import Standard.Table or the type from from Standard.Table import Table.
Apparently, import Standard.Table takes precedence here and so the program outputs:
Execution finished with an error: Method `new` of Main could not be found.
        at <enso> colliding-import.main<arg-1>(colliding-import.enso:7:16-24)
        at <enso> colliding-import.main(colliding-import.enso:7:5-24)

But there are no errors or even warnings about the aliasing.
I think this should result in an error saying that the imports are ambiguous, or at least a warning.
I'm also surprised that it's not the last import that takes precedence (I guess that would be the behaviour that I'd expect).

Running the following code snippet does not produce any compiler errors and normally evaluates:
from Standard.Base.Data.Boolean import True
from Standard.Base.Data.Boolean import True

main =
    42

That was just a simple example that should generate a compiler error explaining that True symbol is ambiguous. Although, strictly speaking, in this case it is not ambiguous, just duplicated. But for simplicity, it is IMHO better to report errors as early as possible, and even for duplicated symbol imports, not only for ambiguous imports. It seems that we have many ambiguous symbol imports in std lib code base.

simple example that should generate a compiler error explaining that True symbol is ambiguous

It is not ambiguous. It is just imported twice. In Java this yields a warning: Unnecessary import on the second import line.


Floorthickness does not save

if you change the floorthickness to smalles and type :reload its back to big
Also you prolly made a typo here:
RoomManager.cs

queryReactor.AddParameter("wallthick", Yupi.BoolToEnum(room.RoomData.AllowPets));

Says it all... xD

Wow kkk

Thanks i will fix.


mongoose error

2 Caught exception: TypeError: Invalid schema configuration: HistoryModel schematype definition is invalid. See https://mongoosejs.com/docs/guide.html#definition for more info on supported schema syntaxes.

not interested


Fix flaky tests on macOS CI

CI tests on macOS are temporarily disabled because they are flaky.
Stack trace: https://github.com/adobe/aem-spa-project-archetype/pull/94/checks?check_run_id=260497228#step:4:5220
Lines that might be relevant:
2019-10-15T10:22:46.6726090Z [INFO] [ERROR] [ERROR] Some problems were encountered while processing the POMs:
2019-10-15T10:22:46.6733330Z [INFO] [ERROR] Unresolveable build extension: Plugin com.day.jcr.vault:content-package-maven-plugin:0.0.24 or one of its dependencies could not be resolved: Failed to read artifact descriptor for com.day.jcr.vault:content-package-maven-plugin:jar:0.0.24 @
...
2019-10-15T10:22:46.7430030Z [INFO] Caused by: org.apache.maven.wagon.TransferFailedException: Connect to repo.adobe.com:443 [repo.adobe.com/<IP_ADDRESS>] failed: Operation timed out (Connection timed out)

Might be related to https://stackoverflow.com/questions/30861293/maven-not-working-when-mvn-package-command-is-run/32514413#32514413
Internal issue: CQ-4281649

This archetype has been merged into aem-project-archetype, so this project's CI workflows have been replaced.


Update to latest rector-src dev-main

ref https://github.com/rectorphp/rector-src/pull/1359#discussion_r759953978

All checks have passed 🎉 @TomasVotruba it is ready for review.


Support a max point count in serializing series

What does this PR do?
This adds a new configuration value, "serializer_max_series_points_per_payload", defining the maximum number of series points to put in a single payload.  It then finishes a payload if the next series would put it over the limit.
Motivation
Request from intake team
Possible Drawbacks / Trade-offs
This was a minimal change to accomplish the goal without adding unnecessary risk.
Series serialization now has three limits for a payload: compressed size, uncompressed size, and number of points.  The first two are handled by the compressor, and in this patch the third is handled by the series marshalSplitCompress function.  Note that the compressor is generic to multiple metric types, not all of which have points.
A more invasive approach would involve refactoring all of this to abstract the serialization loop currently duplicated between the different metric types, and adding support for multiple per-payload maxima.  That would constitute a change to multiple metric types, though, and has a high likelihood of introducing bugs.
Describe how to test/QA your changes
With the previous agent version, observe that the rate at which
curl http://localhost:5000/debug/vars | jq .sketch_series.PayloadFull

is increasing.  Alternately, look at datadog.agent.sketch_series.payload_full for the host.
Upgrade the agent, and confirm that this rate is the same.
Configure "serializer_max_series_points_per_payload" to a small value in a situation where lots of series metrics are transmitted (such as the benchmark environment).  Confirm that the rate increases (more full payloads).
Reviewer's Checklist

[ ] If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
[ ] The appropriate team/.. label has been applied, if known.
[ ] Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
[ ] A release note has been added or the changelog/no-changelog label has been applied.
[ ] Changed code has automated tests for its functionality.
[ ] Adequate QA/testing plan information is provided if the qa/skip-qa label is not applied.
[ ] If applicable, docs team has been notified or an issue has been opened on the documentation repo.
[ ] If applicable, the need-change/operator and need-change/helm labels have been applied.
[ ] If applicable, the config template has been updated.

Is it possible to set the limit per endpoint? We'll need this new limit for the v2 api but it would be unnecessary to affect the v1 api too. Or maybe it is not a problem?

This is only for v2.  My hope is to drop v1 support once you're happy with v2.

Is it possible to set a lower default value for the limit? 100000 is very high. We are aiming more at something like 10000.

From slack:

For the limit I'm thinking of 10000 points max maybe. I'll need to run some experiments

so it looks like I added a zero -- sorry! :)


Remove snarky_bn382 library

This PR removes the snarky_bn382 library.
This library causes a circular dependency of zexe <-> marlin, so it makes sense to shift it out of this repo and up the chain. The corresponding PR to move it into the mina repo is at MinaProtocol/Mina#6464.

This was superseded by #49 (thanks @mimoo!). Closing.


Make improvements to topic mode in client

https://github.com/sopra-fs24-group-15/client/commit/1c0490b949299a80e6aa4ba0918e76017f7caeb9

https://github.com/sopra-fs24-group-15/client/commit/1b36a9a4e911d1a869a1328a85638a55dff8dab4


Possible fix of the issue 33 (Final JSON record has extraneous comma)

< 	},    ]

}     ]

This is the only difference between the two file, so the "cucumber features/cli.feature:56" scenario fails for this reason, that match with the fix

Fixed #33


Add support for building with CUDA

On Linux, use TORCH_CUDA_VERSION to specify the version of CUDA to build libtorch with.

Thanks!


Tweak gas costs: gas should be a proxy for trace length and limit should prevent trace overflows

After the tweaking of gas constants, we get about 35% reduction in gas count based on following functions used in benchmark:

Cross chain messaging - 'e2e_cross_chain_messaging token_bridge_public’

claim_public: 728’466 (new values) 1167196 (master)

‘e2e_cross_chain_messaging token_bridge_failure_cases’:
- _finalize_mint_to_private_unsafe: 978302 (new) 1530166 (master)


[BUG] nodeDownPodDeletionPolicy setting is not reflected on the UI

Describe the bug
setting nodeDownPodDeletionPolicy to delete-both-statefulset-and-deployment-pod value (either directly in the yaml values or via upgrade form) is not reflected in longhorn UI Settings page
To Reproduce
Steps to reproduce the behavior:

cluster explorer / apps & marketplace / installed apps
Edit/Upgrade longhorn
set nodeDownPodDeletionPolicy value to delete-both-statefulset-and-deployment-pod
complete upgrade process
open longhorn UI Settings/General
check Pod Deletion Policy When Node is Down value

Expected behavior
expected value: delete-both-statefulset-and-deployment-pod
actual value: do-nothing
Log
no error reported during upgrade process
Environment:

Longhorn version: v1.1.1

Rancher | v2.5.8
User Interface | v2.5.8
Helm | v2.16.8-rancher1
Machine | v0.15.0-rancher55

Installation method (e.g. Rancher Catalog App/Helm/Kubectl): Rancher Catalog App
Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version: rke 20.10.5

Number of management node in the cluster: 3
Number of worker node in the cluster: 5

Underlying Infrastructure (e.g. on AWS/GCE, EKS/GKE, VMWare/KVM, Baremetal): openstack
Number of Longhorn volumes in the cluster: 3

Additional context
starting the same Edit/Upgrade process again the value is delete-both-statefulset-and-deployment-pod in the settings.
Reproduced via terraform as well, with longhorn.default_settings = true and false values too.
Saving the value via the UI it is shown correctly the next time.

Currently, during upgrade process, Longhorn currently do not update the config to existing cluster.  We do have feature plan to resolve it https://github.com/longhorn/longhorn/issues/2570.

thank you for pointing out @cclhsu
is there any workaround we can do in the meantime to change setting programmatically? I mean longorn is not something that can be  easily dropped and fresh deployed on a prod system...
thanks.

Although It is possible to change the setting by calling Longhorn API.  However, it is not something we recommend, it might cause inconsistency between frontend and backend due to cache.    We would suggest to change to use UI until new solution is ready.

starting the same Edit/Upgrade process again the value is delete-both-statefulset-and-deployment-pod in the settings.
Reproduced via terraform as well, with longhorn.default_settings = true and false values too.
Saving the value via the UI it is shown correctly the next time.

Related to https://github.com/longhorn/longhorn/issues/2570

Let's use #2570 to track this issue, close this one.


B-17918: remove create ppm attachments from internal api - Set B

B-17918
Summary
This PR is for the deprecation of the following INTERNAL APIs:
/personally_procured_move/{personallyProcuredMoveId}/expense_summary - GET

http://milmovelocal:3000/swagger-ui/internal.html#/ppm/requestPPMExpenseSummary

/personally_procured_moves/{personallyProcuredMoveId}/create_ppm_attachments - POST

http://milmovelocal:3000/swagger-ui/internal.html#/ppm/createPPMAttachments

NOTE: All references to the deprecated APIs were removed both on the GO and client-side. To mitigate risk, all targeted APIs marked for deprecation were grouped into two branches for B-17918:

B-17918-Remove-create_ppm_attachments-from-Internal-API-A

B-17918-Remove-create_ppm_attachments-from-Internal-API-B

This PR is for branch: B-17918-Remove-create_ppm_attachments-from-Internal-API-B
The deprecation process was not observed because it's INTERNAL and not Prime (per Dre).
Verification Steps for the Author
These are to be checked by the author.

[ ] Tested in the Experimental environment (for changes to containers, app startup, or connection to data stores)
[ ] Have the Agility acceptance criteria been met for this change?

Verification Steps for Reviewers
These are to be checked by a reviewer.

[ ] Has the branch been pulled in and checked out?
[ ] Have the BL acceptance criteria been met for this change?
[ ] Was the CircleCI build successful?
[ ] Has the code been reviewed from a standards and best practices point of view?

Setup to Run the Code

Instructions for starting storybook
Instructions for starting the MilMove application
Instructions for running tests

How to test
The following have been removed from Swagger:
/personally_procured_move/{personallyProcuredMoveId}/expense_summary - GET

http://milmovelocal:3000/swagger-ui/internal.html#/ppm/requestPPMExpenseSummary

/personally_procured_moves/{personallyProcuredMoveId}/create_ppm_attachments - POST

http://milmovelocal:3000/swagger-ui/internal.html#/ppm/createPPMAttachments

Access Internal Swagger: http://milmovelocal:3000/swagger-ui/internal.htm
http://milmovelocal:3000/swagger-ui/internal.html#/ppm/requestPPMExpenseSummary (does not exist)
http://milmovelocal:3000/swagger-ui/internal.html#/ppm/createPPMAttachments  (does not exist)
Log into http://milmovelocal:3000/  (not see any React build errors, or runtime errors navigating the application)

Frontend

[ ] There are no aXe warnings for UI.
[ ] This works in Supported Browsers and their phone views (Chrome, Firefox, Edge).
[ ] There are no new console errors in the browser devtools.
[ ] There are no new console errors in the test output.
[ ] If this PR adds a new component to Storybook, it ensures the component is fully responsive, OR if it is intentionally not, a wrapping div using the officeApp class or custom min-width styling is used to hide any states the would not be visible to the user.
[ ] This change meets the standards for Section 508 compliance.

Backend

[ ] Code follows the guidelines for Logging.
[ ] The requirements listed in Querying the Database Safely have been satisfied.

Screenshots
The following have been removed from Swagger:
/personally_procured_move/{personallyProcuredMoveId}/expense_summary - GET

http://milmovelocal:3000/swagger-ui/internal.html#/ppm/requestPPMExpenseSummary

/personally_procured_moves/{personallyProcuredMoveId}/create_ppm_attachments - POST

http://milmovelocal:3000/swagger-ui/internal.html#/ppm/createPPMAttachments

Warnings

:warning:

Files located in legacy directories (src/shared or src/scenes) have
been edited. Are you sure you don’t want to also relocate them to the new file structure?
View the frontend file org ADR for more information

:warning:
This PR does not include changes to unit tests, even though it affects app code.

  Generated by :no_entry_sign: dangerJS against e866f61c33c338e87ccb4c1c3497e482e5f19edd


[Feature Request] Twitter

Would be fantastic to have a twitter flow as original: https://github.com/nraboy/ng-cordova-oauth/blob/master/src/oauth.twitter.js

Thanks for the suggestion.  It is my goal to get both versions matched up, but time is the problem now.  When time permits I'll have a look.
Best,

Have you made any progress on the Twitter provider?

+1 This would be great.

You think if I try and translate the code from ng-oauth, to ng2-oauth it should work fine for twitter ? No hidden pitfalls ? @nraboy

For the most part it would be the same.  However Angular 2 as a language allowed me to make major improvements to the ng2 library

Have you done progress with the Twitter provider?
If i've correctly understood the problem is that Twitter login still use oAuth 1.0, isn't it?
I'm using Angular5, can i use this plugin AND also the older that works with 0Auth 1.0?
Thanks


Error when trying to upload skins or access pastes.

1.16.5 Fabric
The following message appears when I try to upload/export skins, or access my pastes.
"Unknown network error, while connecting to the paste site.
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to rquested target"

You have to use a more up-to-date version of java 8 with your Minecraft 1.16 installation.
By default the Minecraft Launcher ships a Win7 version of java with the launcher and it can't connect to most websites anymore.


Socket_mode internals uses its own SSL context and not the one provided by the client

SocketModeHandler doesn't seem to use the ssl_context provided to it by the client passed to it.
I think it should use the context provided if available and fall back to the default context if not.
I'm work on a fix here: https://github.com/charlch/python-slack-sdk/commit/afd7cf098dc8006f9ab84ec4e2e906f1936950e3
Reproducible in:
pip freeze | grep slack
python --version
sw_vers && uname -v # or `ver`

The Slack SDK version
slack-sdk==3.14.1

Python runtime version
Python 3.6.5 |Man Group Plc| (default, Jul  4 2019, 14:15:57)
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

OS info
LSB Version:	:core-4.1-amd64:core-4.1-noarch
Distributor ID:	CentOS
Description:	CentOS Linux release 7.5.1804 (Core)
Release:	7.5.1804

Expected result:
I expect to be able to provide an SSL context for the websockets to use.
I can provide one to the WebClient:
WebClient(token=BOT_TOKEN, ssl=ssl_context)

and I want to use the same context for the websocket.
Actual result:
When the SocketModeHandler constructs a Connection it uses ssl.create_default_context() for the context:

and not the one I provide.
Requirements
For general questions/issues about Slack API platform or its server-side, could you submit questions at https://my.slack.com/help/requests/new instead. :bow:
Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.

Hi @charlch, thanks a lot for taking the time to report this issue and the suggestion to fix it!
Your changes look great to me 👍 If you don't mind, could you send a pull request to this repo?

Hi @seratch, I just need get the validation, codegen, black and lint steps run and fixed before I raise the pull request.
(unless you're happy with the change here anyway: https://github.com/charlch/python-slack-sdk/commit/afd7cf098dc8006f9ab84ec4e2e906f1936950e3)
Should have some time to run those and raise the PR within the next day

Fixed by #1177 - @charlch Thanks a lot for fixing this quickly! As for the next release, https://github.com/slackapi/python-slack-sdk/pull/1176 is the last remaining task. Once that PR is merged, we'll ship a new minor version shortly!


A way to disable 'preventAwait'

Although @koskimas closed #693 as 'wontfix', I'm suggesting a way to disable the behavior of preventAwait, with a small footprint. We often returning non-Promise value in async function or then() chains. It would be great if Kysely have an option for those situation, for people who aren't Knex-newbie or know how to execute query.
The name 'allowNoopAwait' is a little bit temporary, it can be renamed as 'allowAwait', 'ignoreAwait', 'disablePreventAwait', 'iKnowHowToExecute' or something you suggest.

Hey 👋

We often returning non-Promise value in async function or then() chains. It would be great if Kysely have an option for those situation

I didn't get the necessity quite honestly.

I didn't get the necessity quite honestly. Can you elaborate on that?

The code from original issue #693, and I'm not sure I can find better example.. Yeah it is not "often" but "rarely", sorry for overstating.
But it worth considering turning off the behavior that throwing error without actual logical reason.

But it worth considering turning off the behavior that throwing error without actual logical reason.

There is a logical reason. People coming from knex and objection would make the mistake of awaiting queries without execute. Kysely is heavily inspired by knex which naturally leads people thinking it behaves the same.

@koskimas I didn't denied it. I meant "programming logic error". Anyways, It was a light suggestion, never mind.

I think it wouldn't hurt to add this. But remove the delete clazz.prototype.then thing. Having a simple then method that simply passes errors and values through when prevent = false shouldn't have any measurable effect on performance.

@koskimas Yes. That was the reason I should delete then.

preventAwait actually causes issues with anybody trying to return partially built queries from async functions. Not sure if the builders originally implemented the thenable protocol, but it's obvious it shouldn't be used as a means to execute the queries. It does many that any return of queries or or attempt at query composition in async functions cannot work with preventAwait on the builders.

I'm hitting this as well to use a async function to enhance a query...
I'm trying to create a function that enhances the query (SelectQueryBuilder) with pagination, sorting and filtering options that are derived from a HTTP request.
This function looks like:
  async applyQueryParams<DB, TB extends keyof DB, O>(qb: SelectQueryBuilder<DB, TB, O>): Promise<SelectQueryBuilder<DB, TB, O>> {
    const data = await this.getValidatedData<PaginationSchema & SortSchema & FilterSchema>();
    const page = .. // derive page
    const pageSize = .. // derive page size
    const sort = .. // derive sort
    const filter = .. // derive filter

    console.log("Query builder before pagination:", qb);

    qb = qb.limit(pageSize);
    qb = qb.offset((page - 1) * pageSize);

    console.log("Query builder after pagination:", qb);

    return qb;
  }

this function needs to async as the getValidatedData() is also async.
in a handler I call applyQueryParams like:
async handle(c: C) {

    let qb = c.var.mydb
      .selectFrom('customer')
      .selectAll('customer');

    console.log("Before applying query params:", qb);

    qb = await this.applyQueryParams(qb);

    console.log("After applying query params:", qb);

    const customers = await qb.execute();

but this fails with:
Before applying query params: SelectQueryBuilderImpl {}
Query builder before pagination: SelectQueryBuilderImpl {}
Query builder after pagination: SelectQueryBuilderImpl {}
✘ [ERROR] Error: don't await SelectQueryBuilder instances directly. To execute the query you need to call `execute` or `executeTakeFirst`.

I understand the rationale behind the preventAwait for knex users, but Typescript users - not coming from Knex - are now confused and limited.

I'll remove preventAwait if you guys promise the handle all incoming issues it will cause. I'll just tag you and ignore the issue. Sounds good?

I'll remove preventAwait if you guys promise the handle all incoming issues it will cause. I'll just tag you and ignore the issue. Sounds good?

Surely without a thenable interface on the queries, there should be no issue; other than folks from knex wondering why awaiting the query doesn't work, right?

Yet another issue about this. Let's just remove preventAwait. @wirekang If you have time and interest, could you remove preventAwait everywhere and rebase this PR on top of the v0.28 branch? Just let me know if now and let's close this and I'll remove it later.

Wait a minute

@koskimas Just removed all preventAwait related lines from v0.28 branch. Is it what you meant? (This PR is for master branch).

@koskimas Just removed all preventAwait related lines from v0.28 branch. Is it what you meant? (This PR is for master branch).

New PR for v0.28 branch: #1160


Live view prob

Hello Thomas. Thanks for this great project.
I 'm experiencing a little pb with GUI interface.
I've got no "Live view working" but a black image flickering sometimes and no image stored. No changes if I set different camera settings. I'm using an ASI 120MM with flashed firmware +RPI3
Checking for ACL in all directories but everything seems to be fine.
Regards
Raph

Hi Raph,
Do you have a monitor attached or is it a headless setup?
If you have a monitor you should see the terminal with some debugging info. If it's currently dark at your place, it will start capturing images and output a line on the terminal "Saving...".
If you have a headless set up, you'll have to ssh to the RPi, kill a few processes (./capture, entr, allsky.sh) and start allsky.sh manually. Then you'll be able to see the debug info.
Keep in mind it's only saving new images during the night.
Thomas

Ok I'm with an ssh socket with MobaXterm this is a headless setup. Everything is fine with allsky.sh in a shell.
Now it's fine a little reboot and original firmware of my 120MM of march 2017 works !
Trying with different ROI, full frame is too heavy for RPI3 in Live View excepted in wired network wifi is too slow.
Thanks !


Pipenv not found

Hi. I get the error message "get-command : The term 'pipenv' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again."
How do i fix this?

It seems you may not be running the bot according to the instructions in the docs. as the bot would automatically install pipenv if it wasn't found. maybe sure you're running the bot with the included batch file in the windows docs and it should install everything you need.


[1.21.1] Game has to be launched around 5 times for it to not crash and load with Better Nether / Better End.

Mod Name
Better X Mods
Mod Homepage
https://www.curseforge.com/members/quiqueck/projects
Minecraft version
1.21.1
Describe the bug
Initially I thought that the game wouldn't launch at all, but after like 5 attempts it suddenly worked.
Steps to reproduce
Install BCLib, BetterNether, BetterEnd, WunderLib and WorldWeaver (last two are required for 1.21.x afaik)
I also have Embeddium, ModernFix, FerriteCore, ETF, EMF, Continuity, Connector, Connector Extras and FFAPI installed.
Logs
There were two different logs. One on first launch when it crashed and then I disabled every other mod that could potentially cause issues and the second log for every next crash that had the minimal set of mods installed (listed above) The second log had more errors, surprisingly. LOG1: https://mclo.gs/DfGvQDm LOG2: https://mclo.gs/vwjYmIg
Additional context
My guess is that the new BetterX dependencies introduced in 1.21.x had to be individually "reviewed" by Connector, as the number of startup crashes there were was the same with the number of variants of said dependencies (I think). I mean the variants listed in the mod list inside the game. Just like FFAPI is separated into multiple things, the new BetterX dependencies are too.  Anyways, after the game finally launched normally, everything appeared to be working smoothly, except for the world generation in the End, as described in this issue: https://github.com/Sinytra/Connector/issues/1331

Duplicate of #1338


How to handle building Docker Images with protobuf cpp toolchain requirement on mac?

After recently upgrading the scala rules for our bazel build we noticed that we can no longer build docker images on mac for scala projects.  The problems seems to be that a recent change made it so the scala toolchain will build the protobuf library from source which requires the cpp toolchain.
Previously we would run bazel run --cpu=k8 //:my_scala_docker_target and build a docker image we could push. This now fails with:
ERROR: While resolving toolchains for target @io_bazel_rules_scala//src/java/io/bazel/rulesscala/scalac:scalac: no matching toolchains found for types @bazel_tools//tools/cpp:toolchain_type
ERROR: Analysis of target '//:my_scala_docker_target' failed; build aborted: no matching toolchains found for types @bazel_tools//tools/cpp:toolchain_type

Anyone find a way to workaround this?

We're running with remote execution for a long time which require a lot of
toolchains/platform incantations so I think we're not feeling this.
On our linux machines we add
--extra_toolchains=@bazel_toolchains//configs/ubuntu16_04_clang/latest:toolchain_default
but it actually seems that on macs we're not passing it and I'm not sure
we're passing anything explicitly. On mac the default behavior AFAIR is to
use xcode. Maybe you're disabling it somehow?
On Tue, Sep 24, 2019 at 6:39 PM Richard Whitcomb<EMAIL_ADDRESS>wrote:

After recently upgrading the scala rules for our bazel build we noticed
that we can no longer build docker images on mac for scala projects. The
problems seems to be that a recent change made it so the scala toolchain
will build the protobuf library from source which requires the cpp
toolchain.
Previously we would run bazel run --cpu=k8 //:my_scala_docker_target and
build a docker image we could push. This now fails with:
ERROR: While resolving toolchains for target @io_bazel_rules_scala//src/java/io/bazel/rulesscala/scalac:scalac: no matching toolchains found for types @bazel_tools//tools/cpp:toolchain_type
ERROR: Analysis of target '//src/pipelines/examples/spark:bin' failed; build aborted: no matching toolchains found for types @bazel_tools//tools/cpp:toolchain_type
Anyone find a way to workaround this?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/bazelbuild/rules_scala/issues/851?email_source=notifications&email_token=AAKQQF4SQLEVAP2AVH5AKC3QLIYE5A5CNFSM4I2BNKIKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HNLLRXQ,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKQQF7UFALMR6YF4SFUTQDQLIYE5ANCNFSM4I2BNKIA
.

Yeah my situation is a bit different since my docker image has a jar plus some golang code to help deal with kubernetes.  So without the golang code I can target the normal cpu and build for mac and the jar will of course work fine once in the docker container.
For the golang code though I need to set --cpu=k8 which tries to pool to the k8 toolchain.  This fine for the golang build and the scala part but protobuf can not be built with that cpu since it has C++ targets.
Thanks for the pointers on toolchains, I can look into that and see if I can get the C++ protobuf targets building correctly under mac targeting the k8 toolchain.


Light miner: Diagnostics page should NOT display local blockchain details #321

#321

Link: https://github.com/NebraLtd/hm-diag/issues/321
Summary: remove local blockchain details and add validator blockchain details.

How

Uses grpc to talk to locally running gateway-rs
displays validator information in diag page. Shows "disconnected" when it can't connect to validator

Screenshots

References

Checklist

[x] Tests added
[ ] Cleaned up commit history (rebase!)
[ ] Documentation added
[ ] Thought about variable and method names

the screenshot shows disconnected because gatewayrs is listening on localhost:4467. There doesn't seem to be a way to specify interface for api endpoint right now. Will ask helium and raise an issue. My feeling they might have already fixed it but gateway-rs hasn't had a release from quite a while.

@marvinmarnold @vpetersson I want to merge this. it is reasonably tested. I can't run full test because of this. . only workaround right now is to "do host networking for miner and diag". I don't want to do and test a change that we intend to revert.

@marvinmarnold @vpetersson I want to merge this. it is reasonably tested with mock servicer. Can't run full test on device because of this. . only workaround right now is to "do host networking for miner and diag". Don't want to do and test a change that we intend to revert.

I am doing host networking. Based on the comments in the ticket, it doesn't look like helium guys will change their mind and allow binding to anything other than localhost.


Abstract AMQP client, consumer, channel

WHAT is this pull request doing?
Abstract the client, consumer, channel, amqp_connection classes into the AMQP namespace. This is to prepare our codebase for introducing multiple protocols (MQTT support, etc..)
HOW can this pull request be tested?
run specs

We now lost all git blame history on these files :face_with_diagonal_mouth:


ERROR NoMethodError: undefined method key? for nil:NilClass in conditionally_inject_charset

First off, thank you for providing/maintaining this awesome template.
My fork works very well when serving on Windows and on github pages. But when I try to run my site on Linux (Ubuntu 20.04.1), I get an error on GET requests: "ERROR NoMethodError: undefined method key? for nil:NilClass" in function conditionally_inject_charset. This makes it so that the website always shows up with "page not found".
I searched for this error message, but it seems to be pretty broadly applicable so I couldn't find a solution. Can you help me figure out how to fix the error?
To provide a simple reproduction of the error, I ran the original repository at academicpages.github.io and found that the same problem occurs on both my fork and the original repo. The problem is detailed below.
I'm running on Ubuntu 20.04.1. I installed ruby and bundle using the command from the README:
sudo apt install ruby-dev ruby-bundler nodejs

Here is the transcript of the terminal. I also attached a full transcript from install to liveserve in transcript.txt.
(base) benjis@AM:~/code/academicpages.github.io$ bundle exec jekyll liveserve
Configuration file: /home/benjis/code/academicpages.github.io/_config.yml
To use retry middleware with Faraday v2.0+, install `faraday-retry` gem
            Source: /home/benjis/code/academicpages.github.io
       Destination: /home/benjis/code/academicpages.github.io/_site
 Incremental build: disabled. Enable with --incremental
      Generating...
       Jekyll Feed: Generating feed for posts
   GitHub Metadata: No GitHub API authentication could be found. Some fields may be missing or have incorrect data.
                    done in 7.459 seconds.
 Auto-regeneration: enabled for '/home/benjis/code/academicpages.github.io'
Configuration file: /home/benjis/code/academicpages.github.io/_config.yml
 LiveReload Server: <IP_ADDRESS>:35729
    Server address: http://<IP_ADDRESS>:4000/
  Server running... press ctrl-c to stop.
[2022-06-17 09:41:18] ERROR NoMethodError: undefined method `key?' for nil:NilClass
	/home/benjis/code/academicpages.github.io/vendor/bundle/ruby/2.7.0/gems/jekyll-3.9.2/lib/jekyll/commands/serve/servlet.rb:191:in `conditionally_inject_charset'
	/home/benjis/code/academicpages.github.io/vendor/bundle/ruby/2.7.0/gems/jekyll-3.9.2/lib/jekyll/commands/serve/servlet.rb:176:in `do_GET'
	/home/benjis/code/academicpages.github.io/vendor/bundle/ruby/2.7.0/gems/hawkins-2.0.5/lib/hawkins/servlet.rb:134:in `do_GET'
	/usr/lib/ruby/2.7.0/webrick/httpservlet/abstract.rb:105:in `service'
	/usr/lib/ruby/2.7.0/webrick/httpservlet/filehandler.rb:233:in `service'
	/usr/lib/ruby/2.7.0/webrick/httpserver.rb:140:in `service'
	/usr/lib/ruby/2.7.0/webrick/httpserver.rb:96:in `run'
	/usr/lib/ruby/2.7.0/webrick/server.rb:307:in `block in start_thread'

And here is what the page looks like on the original repo:

And here is what it looks like on my work (should look like benjijang.com):

I realized that my Windows box was running Jekyll 3.9.0 while my Linux box was running Jekyll 3.9.2 (latest 3.x version). After downgrading my Linux box to Jekyll 3.9.0, my fork and the original repo started working, and after upgrading my Windows box to Jekyll 3.9.2, my fork stopped working. Therefore, I believe Jekyll 3.9.2 is the reason for the failure. Not sure why, though.
My PR should fix the problem for any others encountering this issue.

3.9.0

A useful solution for this problem, tried downgrade jekyll to 3.9.0 then problem disappeared. Great thanks😊

If you are facing problem:
vendor/bundle/ruby/3.0.0/gems/pathutil-0.16.2/lib/pathutil.rb:502:in `read': no implicit conversion of Hash into Integer (TypeError)

Just change the version of jekyll 3.9.0 to 3.9.3:
In your Gemfile:
gem "jekyll", "3.9.3"

I realized that my Windows box was running Jekyll 3.9.0 while my Linux box was running Jekyll 3.9.2 (latest 3.x version). After downgrading my Linux box to Jekyll 3.9.0, my fork and the original repo started working, and after upgrading my Windows box to Jekyll 3.9.2, my fork stopped working. Therefore, I believe Jekyll 3.9.2 is the reason for the failure. Not sure why, though.

This really helped me to solve the problem, thanks so much, it's really so delightful that the web page is displaying properly!

This appears to be addressed with the latest updates.


Animation tree animates too fast when multiple of the same scene are instanced.

Godot version: 3.1 alpha 1

OS/device including version: Windows 10

Issue description:
If a node is animated by an AnimationTree and it is instanced multiple times, each instance runs the animation faster. Two instances seems to double animation speed, three triples, ect.

Steps to reproduce:
Create a scene with an animation player and an animation. Have an animation tree within the scene run that animation. Instance multiple of the first scene within some other scene.
Minimal reproduction project:

Bug Test.zip

I can confirm the issue still occurs in 72db3000a56a6f85d348c218437d1a1dfc0953bf
Gif that presents the issue and my reproduction setup (quick setup based on Platformer 3D demo):

From my observations, it seems the issue is more complicated since in my game the player's AnimationTree speed is also directly related to the number of enemies which are instanced in the world (and enemies are not using AnimationTree at all).

I found that the TPS demo hasn't this issue but I also encounter the same issue.
Don't know why.
Anybody knows why TPS demo work?

See also MRP from #23529: AnimationTree.zip

@nagasawamaki How is TPS working for you? If I make a scene with two instances of the robot (player or enemy) the speed increases as with any other AnimationTree scene instance


TypeError: Cannot read property 'panHandlers' of undefined (SwipeRow)

TypeError: Cannot read property 'panHandlers' of undefined
This error is located at:
in SwipeRow (at connectStyle.js:392)
in Styled(SwipeRow) (at feedback-list-item/index.js:295)
in FeedbackListItem (at inbox-screen/index.js:303)
in RCTView (at View.js:45)
in View (at inbox-screen/index.js:299)
in StaticRenderer (at ListView.js:463)
in RCTScrollContentView (at ScrollView.js:852)
in RCTScrollView (at ScrollView.js:952)
in ScrollView (at ListView.js:324)
in ListView (at inbox-screen/index.js:555)
in RCTView (at View.js:45)
in View (at inbox-screen/index.js:527)
in InboxScreenComponent (at inbox/index.js:355)
......
dependencies
"dependencies": {
"@expo/vector-icons": "^10.0.3",
"@react-native-community/async-storage": "^1.5.1",
"@unimodules/core": "^2.0.1",
"@unimodules/react-native-adapter": "^2.0.1",
"babel-core": "^7.0.0-bridge.0",
"expo-asset": "^5.0.1",
"expo-constants": "^5.0.1",
"expo-file-system": "^5.0.1",
"expo-font": "^5.0.1",
"i18n": "^0.8.3",
"i18n-js": "^3.2.1",
"lodash": "^4.17.11",
"moment": "^2.24.0",
"native-base": "^2.11.0",
"prop-types": "^15.6.2",
"react": "16.5.0",
"react-dom": "^16.8.6",
"react-native": "^0.57.1",
"react-native-error-boundary": "^1.0.2",
"react-native-gesture-handler": "^1.3.0",
"react-native-image-crop-picker": "^0.25.0",
"react-native-image-picker": "^1.0.1",
"react-native-keyboard-aware-scroll-view": "^0.8.0",
"react-native-keyboard-spacer": "^0.4.1",
"react-native-permissions": "^1.1.1",
"react-native-push-notification": "^3.1.3",
"react-native-render-html": "^4.1.2",
"react-native-sentry": "^0.43.2",
"react-native-simple-markdown": "^1.1.0",
"react-native-vector-icons": "^6.6.0",
"react-navigation": "^3.11.0",
"react-redux": "^6.0.0",
"redux": "^4.0.1",
"redux-thunk": "^2.3.0",
"socket.io-client": "^2.0.4"
},

having same issue
...
"native-base": "^2.13.4",
"react-native": "0.60.4",
...

having same issue
...
"native-base": "^2.13.4",
"react-native": "0.60.4",
...

@kozillla it's removed on that version.

This is a duplicate of #2866.


Why does my bcbio run decide to: "Run locally instead of distributed" ?

Hi
I'm trying to do a distributed smallrnaseq pipeline on a slurm cluster with 495 samples using a maximum 256 cores. The first part of the pipeline was able to run across multiple nodes, but now it is at the alignment step it seems to be running in serial (i.e. one sample at a time on a single node with 16 cores allocated) and I don't really understand why. You can see in the line below it decides it needs to run locally instead of distributed. I wondered if I have not specified something incorrectly in the yaml or ipython has been setup this way on purpose? I would have thought carrying out alignment across multiple nodes at once would be preferred? If IPython can't reserve all 256 cores, does it grab as many as it can in multiples of 16 or does it just revert to running one job with 16 cores?
bcbio_nextgen.py $CLUSTER_RESOURCES ../config/$RUN_NAME.yaml -t ipython -n 256 -s slurm -q all --timeout 1440
[2018-07-31T20:37Z] n104: System YAML configuration: /projects/karsanlab/mshadbolt/resources/bcbio_config/bcbio_system.numbers_cluster.yaml
[2018-07-31T20:37Z] n104: Resource requests: atropos, picard; memory: 2.00, 2.00; cores: 16, 16
[2018-07-31T20:37Z] n104: Configuring 16 jobs to run, using 16 cores each with 32.1g of memory reserved for each job
[2018-07-31T20:37Z] n104: Running locally instead of distributed -- checkpoint passed: trimming
[2018-07-31T20:37Z] n104: Timing: organize samples
[2018-07-31T20:37Z] n104: multiprocessing: organize_samples

If you could let me know whether I'm doing something wrong on my end or if this is the expected behaviour that'd be great.
Thanks
Marion

Hi Marion,
It looks like this is a rerun of a run that was already partially processed-- that run completed the trimming step, which is why the checkpoint for trimming has passed. It is running that part locally because it thinks it was already done.
From the snippet you posted, the alignment hasn't started yet.

Hi Rory
thanks for the speedy response. Yes that's correct, I have started and stopped it a few times to try to get it to run distributed and because mirdeep seems to fail but nothing I do seems to help. I didn't post the whole thing in the interest of space but when it gets to the alignment step it is processing each in serial.
The debug file is fairly messy because I have stopped and restarted a few times and mirdeep always fails but as an example, here is a run I did on a different cluster but still with multiple nodes available, once it gets to alignment so you can see it is only running on one node:
[2018-07-31T22:30Z] hpc_head_node: System YAML configuration: /projects/karsanlab/mshadbolt/resources/bcbio_config/bcbio_system.clingenq_cluster.yaml
[2018-07-31T22:30Z] hpc_head_node: Resource requests: atropos, picard; memory: 2.00, 2.00; cores: 16, 16
[2018-07-31T22:30Z] hpc_head_node: Configuring 8 jobs to run, using 16 cores each with 32.1g of memory reserved for each job
[2018-07-31T22:30Z] hpc_head_node: Running locally instead of distributed -- checkpoint passed: trimming
[2018-07-31T22:30Z] hpc_head_node: Timing: organize samples
[2018-07-31T22:30Z] hpc_head_node: multiprocessing: organize_samples
[2018-07-31T22:30Z] hpc_head_node: Using input YAML configuration: /projects/karsanscratch/mshadbolt/KARSANBIO-1548_process_synthetic_data/synth_mirna/config/synth_mirna.yaml
[2018-07-31T22:31Z] hpc_head_node: Checking sample YAML configuration: /projects/karsanscratch/mshadbolt/KARSANBIO-1548_process_synthetic_data/synth_mirna/config/synth_mirna.yaml
[2018-07-31T22:31Z] hpc_head_node: Testing minimum versions of installed programs
[2018-07-31T22:31Z] hpc_head_node: multiprocessing: prepare_sample
[2018-07-31T22:31Z] hpc_head_node: Preparing SRR5234257_trimmed
[2018-07-31T22:31Z] hpc_head_node: Preparing SRR5234258_trimmed
...
[2018-07-31T22:31Z] hpc_head_node: Preparing SRR6381054_trimmed
[2018-07-31T22:31Z] hpc_head_node: Timing: adapter trimming
[2018-07-31T22:31Z] hpc_head_node: multiprocessing: trim_srna_sample
[2018-07-31T22:31Z] hpc_head_node: Resource requests: picard, samtools, star; memory: 2.00, 2.00, 2.00; cores: 16, 16, 16
[2018-07-31T22:31Z] hpc_head_node: Configuring 1 jobs to run, using 16 cores each with 32.1g of memory reserved for each job
[2018-07-31T22:33Z] hpc_head_node: Timing: prepare
[2018-07-31T22:33Z] hpc_head_node: ipython: seqcluster_prepare
[2018-07-31T22:33Z] hpc_head_node: Timing: alignment
[2018-07-31T22:33Z] hpc_head_node: ipython: srna_alignment
[2018-07-31T22:33Z] qh31: Preparing for mirdeep2 analysis.
[2018-07-31T22:34Z] qh31: Running mirdeep2.
[2018-07-31T22:34Z] qh31: #Starting miRDeep2
...
[2018-07-31T22:38Z] qh31: mirdeep2 failed. Please report the error to https://github.com/lpantano/mirdeep2_core/issues.
[2018-07-31T22:38Z] hpc_head_node: ipython: process_alignment
[2018-07-31T22:38Z] qh31: Aligning lane SRR5234257_trimmed with star aligner
[2018-07-31T22:38Z] qh31: Aligning lane SRR5234258_trimmed with star aligner
[2018-07-31T22:38Z] qh31: Aligning lane SRR5234259_trimmed with star aligner
...
[2018-08-01T08:12Z] qh31: Aligning lane SRR5234359_trimmed with star aligner
[2018-08-01T08:12Z] qh31: Running STAR aligner on ~/work/trimmed/SRR5234359_trimmed/SRR5234359.trimmed.clean.fastq.gz and ~/bcbio-nextgen/data/genomes/Hsapiens/hg19/star/
[2018-08-01T08:20Z] qh31: [bam_sort_core] merging from 0 files and 16 in-memory blocks...
[2018-08-01T08:20Z] qh31: Index BAM file: SRR5234359_trimmed.bam
[2018-08-01T08:21Z] qh31: Aligning lane SRR5234360_trimmed with star aligner
[2018-08-01T08:21Z] qh31: Running STAR aligner on ~/work/trimmed/SRR5234360_trimmed/SRR5234360.trimmed.clean.fastq.gz and ~/bcbio-nextgen/data/genomes/Hsapiens/hg19/star/
[2018-08-01T08:30Z] qh31: [bam_sort_core] merging from 0 files and 16 in-memory blocks...
[2018-08-01T08:30Z] qh31: Index BAM file: SRR5234360_trimmed.bam
[2018-08-01T08:30Z] qh31: Aligning lane SRR5234361_trimmed with star aligner
[2018-08-01T08:30Z] qh31: Running STAR aligner on ~/work/trimmed/SRR5234361_trimmed/SRR5234361.trimmed.clean.fastq.gz and ~/bcbio-nextgen/data/genomes/Hsapiens/hg19/star/
[2018-08-01T08:38Z] qh31: [bam_sort_core] merging from 0 files and 16 in-memory blocks...
[2018-08-01T08:38Z] qh31: Index BAM file: SRR5234361_trimmed.bam
[2018-08-01T08:38Z] qh31: Aligning lane SRR5234362_trimmed with star aligner
[2018-08-01T08:38Z] qh31: Running STAR aligner on ~/work/trimmed/SRR5234362_trimmed/SRR5234362.trimmed.clean.fastq.gz and ~/bcbio-nextgen/data/genomes/Hsapiens/hg19/star/
[2018-08-01T08:47Z] qh31: [bam_sort_core] merging from 0 files and 16 in-memory blocks...
[2018-08-01T08:47Z] qh31: Index BAM file: SRR5234362_trimmed.bam
[2018-08-01T08:47Z] qh31: Aligning lane SRR5234363_trimmed with star aligner
[2018-08-01T08:47Z] qh31: Running STAR aligner on ~/work/trimmed/SRR5234363_trimmed/SRR5234363.trimmed.clean.fastq.gz and ~/bcbio-nextgen/data/genomes/Hsapiens/hg19/star/
[2018-08-01T08:52Z] qh31: [bam_sort_core] merging from 0 files and 16 in-memory blocks...
[2018-08-01T08:52Z] qh31: Index BAM file: SRR5234363_trimmed.bam
[2018-08-01T08:52Z] qh31: Aligning lane SRR5234364_trimmed with star aligner
[2018-08-01T08:52Z] qh31: Running STAR aligner on ~/work/trimmed/SRR5234364_trimmed/SRR5234364.trimmed.clean.fastq.gz and ~/bcbio-nextgen/data/genomes/Hsapiens/hg19/star/
[2018-08-01T08:57Z] qh31: [bam_sort_core] merging from 0 files and 16 in-memory blocks...
[2018-08-01T08:57Z] qh31: Index BAM file: SRR5234364_trimmed.bam
...

Hopefully that is more helpful

It looks like it is running 3 alignments at once on a node, not just one, you can see
[2018-07-31T22:38Z] qh31: Aligning lane SRR5234257_trimmed with star aligner
[2018-07-31T22:38Z] qh31: Aligning lane SRR5234258_trimmed with star aligner
[2018-07-31T22:38Z] qh31: Aligning lane SRR5234259_trimmed with star aligner

are all kicked off at the same time. It also looks like these are the only samples that are being run. Are you sure you have more than 3 samples?

Hi Rory, those are the ones that had already aligned with a previous run, I do have more than 3 samples, I was just truncating because I thought it would be easier to read but I think I am making it more complicated for you, sorry for that!
don't worry about the FATAL ERROR, it is being caused by some ion torrent fastqs, I'd just really like the alignment to run parallel.
Here is the entire debug file so far: https://drive.google.com/file/d/1QtcS4ergAtVHRIhw6ZS5D9dKuC51Bc1s/view?usp=sharing

Oh I see, extras are elided with ....  It looks like bcbio is not scheduling the right number of resources for the alignment step, you can see it is only asking for 1 job with 16 cores, when it should be asking for more.
@lpantano this line looks like it might be the culprit: https://github.com/bcbio/bcbio-nextgen/blob/master/bcbio/pipeline/main.py#L323 would just setting samples work there?

Thanks, I totally see what you are saying now. Yeah, it looks like a bug, we will fix it.

Okay great, thanks for the help!

That is true, and you both are totally right!
I’ll work on that later today or tomorrow to fix it!
Thanks!

On Aug 1, 2018, at 2:47 PM, Rory Kirchner<EMAIL_ADDRESS>wrote:
Oh I see, extras are elided with .... It looks like bcbio is not scheduling the right number of resources for the alignment step, you can see it is only asking for 1 job with 16 cores, when it should be asking for more.
@lpantano https://github.com/lpantano this line looks like it might be the culprit: https://github.com/bcbio/bcbio-nextgen/blob/master/bcbio/pipeline/main.py#L323 https://github.com/bcbio/bcbio-nextgen/blob/master/bcbio/pipeline/main.py#L323 would just setting samples work there?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/bcbio/bcbio-nextgen/issues/2472#issuecomment-409681713, or mute the thread https://github.com/notifications/unsubscribe-auth/ABi_HMnnlNwO20wDYEK9UyfDR8zsoo9cks5uMfe4gaJpZM4Vq8L7.

I pushed a hotfix, I hope this solve it.
Let me know!

FYI it looks like it goes back to running serially on a single engine when the pipeline gets to the seqcluster step.

Hi, that is normal. It is a single job. Thanks for checking it out!
sent not from my computer

On Aug 2, 2018, at 17:37, Marion<EMAIL_ADDRESS>wrote:
FYI it looks like it goes back to running serially on a single engine when the pipeline gets to the seqcluster step.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.


Windows Desktop App will not start after display driver update

I recently updated my computers display adapter and now Toggl's Desktop app will no longer function.
I have tried uninstalling Toggl, deleting the local app data, restarting the computer and reinstalling with the current version of Toggl and the problem still persists.
When I review my resource monitor I can see Toggl there trying to open but it just immediately terminates itself.
Note that when I updated the display adapter, Toggl was active at the time but after the update was finished, Toggl immediately crashed.
Regardless, why Toggl cannot be repaired without a system restore, is beyond me but any assistance would be greatly appreciated.
OS: Windows 7 Home Premium SP1
Make/Model: HP Pavilion dv6 Notebook PC
Processor: AMD A8-3520M APU with Radeon HD Graphics (junk, I know)

Could you write to support<EMAIL_ADDRESS>so we can ask for more details and log files that show what is the exact cause of the crash.

@IndrekV case/665026


[SPIKE] Research additional Kafka monitoring/metric solutions.

Is your feature request related to a problem? Please describe.
Currently the solution we have for monitoring and getting metrics from Kafka are based one:

Kafka Exporter
JMX Exporter
Prometheus
Grafana

While these tools work OK in most situations in some cases they might not be sufficient and cause problems like high CPU utilization and a large number of outstanding issues with for example the Kafka exporter plugin.
Describe the solution you'd like
We would like to investigate any alternative solutions which might be useful to add to Epiphany to monitor and get metrics on Kafka besides the above solution. A good starting point might be this article:
https://medium.com/@giorgosmyrianthous/overview-of-ui-monitoring-tools-for-apache-kafka-clusters-9ca516c165bd
Additional context
*

Additional tools worth consideration:
https://sematext.com/blog/kafka-open-source-monitoring-tools/#toc-cruise-control-3

Additional tools worth consideration:
https://sematext.com/blog/kafka-open-source-monitoring-tools/#toc-cruise-control-3

SPIKE done in the PR: https://github.com/epiphany-platform/epiphany/pull/2063


add node-density-cni for common and med scale

pods_per_node = 45, tested this on 120 nodes
more info about the workload https://github.com/cloud-bulldozer/benchmark-operator/pull/727

pods_per_node = 45, tested this on 120 nodes
more info about the workload cloud-bulldozer/benchmark-operator#727

Weren’t we using 50 for node density heavy?

no, 100
this one failed with 50


Kata Containers 1.4.0

virtcontainers: fix sandbox store struct VFIODevice bug
virtcontainers: Add function supportGuestMemoryHotplug
make: add ability to skip go version check
cli: Fix console for big endian architecture
virtcontainers: fix not close socket with ethtool
build: introduction of archConvertStatFs function
network: support hotplug a nic several times
sandbox: Extend sandbox API
golang.mk: Check and install yq before use it
cli: refactor the config into a separated package
newContainer: Not attach device if it is a CDROM
build: check golang version meets min req.
network: Use constant string for "none" network model
runtime,netmon: build as Position-Independent-Executable
virtcontainers: Rely on new interface LinkType field
enable default network endpoints hotplug for vm factory
cli: fix the issue of using wrong path to get version
cli: add guest hook path option (v2)
factory: use customised deep compare
qemu: query migrate status
Add support for ipvlan network driver
Add cgroup support
vfio: Change the way the driver is fetched
vendor: Rely on new agent package types
network: Use tc filtering rules in bridge mode
cli: add configuration option to use or not use host netns
versions: Update golang to 1.10.4
network: Marshal BridgedMacvlanEndpoint and MacvtapEndpoint
device: fix the issue of passing wrong device address using virtio-blk
create/run: Make bundle path default to cwd
virtcontainers: Add missing API trace calls
sandbox/virtcontainers: memory resource hotplug when create container.
virtcontainers: Add missing API release calls
qemu: Disable the default romfile used by virtio-pci
Refactor network.go
network: Sort endpoints by name
virtcontainers: qemu: Add proper support for virt machine type
network: Add support for macvlan and macvtap driver
memory: update: Update state using the memory removed
block: Advertise block support for q35
vendor: fix govmm package

cba7a88 virtcontainers: fix sandbox store struct VFIODevice bug
0796f2e virtcontainers: Add function supportGuestMemoryHotplug
d73f27c test: set arch for test TestHotplugRemoveMemory
bf56858 cli: Fix console for big endian architecture
4b9a471 virtcontainers: fix not close socket with ethtool
58c1db5 make: notify user if yq is going to be installed
ab43e2a make: add ability to skip go version check
b185f31 build: introduction of archConvertStatFs function
982381b api: Cleanup StartContainer()
5777381 sandbox: Create and export Pause/ResumeContainer() to the API level
b298ec4 sandbox: Create and export ProcessListContainer() to the API level
3add296 sandbox: Create and export KillContainer() to the API level
7653726 sandbox: Create and export StopContainer() to the API level
109e12a sandbox: Export Stop() to the API level
6c3e266 sandbox: Export Start() to the API level
f5048b7 golang.mk: Check and install yq before use it
2f98b3e network: support hotplug a nic several times
842a00a cli: refactor the config into a separated package
193b324 newContainer: Not attach device if it is a CDROM
8ddc0ce network: Use constant string for "none" network model
5199777 virtcontainers: Rely on new interface LinkType field
45b2191 netmon: Rely on new interface field LinkType
7bf84d0 types: Replace agent/pkg/types with virtcontainers/pkg/types
39b95cc virtcontainers: Create a new package "types"
658bdb1 runtime,netmon: build as Position-Independent-Executable
e9aa870 network: enable network hotplug for vm factory
95f4fdb build: check golang version meets min req.
eaa5c7a CI: travis: call yq installer
cbf7fb2 CI: travis: add yq installer script
11c6753 cli: fix the issue of using wrong path to get version
21a671e network: set endpoint pci address when hotplug
33abb3e cli: add guest hook path option in the configuration file
34fe3b9 cgroups: add host cgroup support
523d49c vendor: add github.com/containerd/cgroups lib
38d56c9 netmon: Rely on agent/pkg/types instead of duplicating types
309dcf9 vendor: Update the agent vendoring based on pkg/types
0acbbf0 network: Add support for ipvlan
c38792e config: Add documentation for tcfilter in configuration.toml
17be8e3 network: Introduce constants for the network model strings
5da973d test: Add test to verify tc redirect
e20dbd0 network: Use tc redirect filter to redirect traffic to the VM
526d55b versions: Update golang to 1.10.4
62992f5 versions: Update cri containerd version for golang 1.10.2 fix
31cf6fb vfio: Change the way the driver is fetched
7a5a57d cli: test: add unit test for kata-env and kata-check
14e5437 cli: add configuration option to use or not use host netns
6935279 network: add new NetInterworkingModel "none" and endpoint type TapEndpoint
f8f2962 virtcontainers: refactor hotplug qmp functions
21d38e9 network: Marshal BridgedMacvlanEndpoint and MacvtapEndpoint
32ef29b factory: use customised deep compare
36306e2 sandbox/virtcontainers: modify tests relate to memory hotplug.
3f39d6e virtcontainers: Add missing API release calls
b72a3cd device: fix the issue of passing wrong device address using virtio-blk
ee9275f virtcontainers: Add missing API trace calls
8831245 create/run: Make bundle path default to cwd
0ae5b14 qemu: Disable the default romfile used by virtio-pci
6f0873a vendor: Update govmm vendoring
14f480a sandbox/virtcontainers: combine addResources and updateResources
8e2ee68 sandbox/virtcontainers: memory resource hotplug when create container.
b04691e network: Collapse log calls for endpoint Attach and Detach
ab15498 network: Explicitly check for veth type
3c590b0 network: Rename VirtualEndpoint to VethEndpoint
df8f21d network: Refactor network tests.
adcd910 network: Refactor network.go
8f1b28d network: Sort endpoints by name
eb77a41 qemu: make saveSandbox wait for migration completion
dffb4f9 virtcontainers: qemu: Add proper support for virt machine type
3c7cf58 tests: Add additional network tests to verifu link creation functions
378191a tests: Add tests for macvlan and macvtap endpoints
def070d golint: Refactor to reduce cyclomatic complexity
417c1f0 macvtap: Add support for macvtap
0de7572 vendor: Update govmm vendoring
581ff17 macvlan: Assign random MAC address
8847af8 network: Add support for macvlan driver
1f5792e test: fix unit test nil pointer.
4697cf3 memory: update: Update state using the memory removed.
0cab192 block: Advertise block support for q35
f4cf213 vendor: fix govmm package

/test

lgtm

Metrics CI still broken I dont think  is a blocker. Feel free to merge it when you are ready

yeah, I'm working on it - non-ksm memory footprint seems to be all over the place :-( I'm going to bump the pass band bigger whilst I figure it out so we can avoid all the blocking fails...

@bergwolf hi, I was wondering if we could merge #928, which already passed CI and its dependency:  https://github.com/kata-containers/tests/pull/926 an after that, rebase this PR, so that we can officially say that we support K8s 1.12 on this release?

@chavafg sure, let's merge it!

cool, thanks 😄

/test


Contradiction in the docs

This document states the following:

The Windows Autopilot for white glove deployment pre-provisioning process will apply all device-targeted policies from Intune. That includes certificates, security templates, settings, apps, and more – anything targeting the device. Additionally, any apps (Win32 or LOB) that are configured to install in the device context and targeted to the user that has been pre-assigned to the Autopilot device will also be installed.

Of importance is this part: any apps (Win32 or LOB) that are configured to install in the device context and targeted to the user
Install Apps on Windows 10 Devices however states the following:

If an app is deployed in device context and targeted to a user, the installation fails. The following status and error appears in the admin console:
Status: Failed.
Error: A user can’t be targeted with a device context install.

Which is correct, then?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: ca5b57d1-61b3-39d4-34ff-d6dcb858c250
Version Independent ID: 42609104-815f-9e7a-39aa-38d92cc910c9
Content: Windows Autopilot for white glove deployment
Content Source: windows/deployment/windows-autopilot/white-glove.md
Product: w10
Technology: windows
GitHub Login: @greg-lindsay
Microsoft Alias: greglin

Thanks for noticing this - I am checking to see exactly what is correct and the clarification that should be added.

@officedocsbot assign @jvsam

@officedocsbot assign @greg-lindsay

FYI, this is still under investigation. I have continued to ask but no answer yet.

Thank you for validating this hasn't been forgotten. I've tried to get an answer through other channels and found them to be similarly unforthcoming.

Hi there I have a response. It is detailed. See below - this information will be added to the Intune documentation.
Apps can only be installed in the Device Context when supported by the device and the Intune app type. The following app types support device-context installation. You can assign these apps to a device group:
•	Win32 Apps
•	Microsoft Store for Business (Offline licensed apps only)
•	LOB Apps (MSI, APPX and MSIX)
•	Office 365 ProPlus
•	Windows LOB Apps (specifically APPX and MSIX) and Microsoft Store for business (Offline apps) that you’ve selected to install in device context need to be assigned to a device group.  If one of these apps is targeted to a user, the installation fails. The following status and error appears in the admin console:
o	Status: Failed.
o	Error: A user can’t be targeted with a device context install.
NOTE: The above restriction on Windows LOB apps and MSFB apps having to be device-group targeted does not exist when used in combination with an AutoPilot WhiteGlove provisioning scenario. During device white-glove technician flow, All apps that are assigned to the device group, as well as those apps targeted at the user group will be installed as per the white glove documentation.

If this is satisfactory, please close the issue. Thanks!

Thank you! So my understanding then is that if Device-context LOB and MSfB apps are targeted to a user group, if the software attempts to install during the technician flow they'll succeed, but if they instead tried to install on an existing Windows instance it'd fail? Does this mean this type of targeting should only be set up for users that only have autopilot WG devices, and only targeted to the user the moment when WG is initiated on the device?


Slow POS minting - need some information/help

I'm debugging and trying to figure out why POS minting is slow at finding (acceptable) block, this is not on the Stratis main net.
Here is the the blocks created when POW is enabled:

Just a single VM running POW, would likely be smoother with more. Only a single VM as I'm attempting to get POS working with multiple nodes.
Initially I had a few nodes minting/staking and there was 400+ UTXOs, most of them at 100 coin/token each. Stake minimum confirms is currently at 50.
I have attempted debugging, additional logging, etc. The reason is "simply" that it is not generating a hash that is accepted in the CheckStakeKernelHash method.
// Now check if proof-of-stake hash meets target protocol.
var hashProofOfStakeTarget = new BigInteger(1, context.HashProofOfStake.ToBytes(false));
if (hashProofOfStakeTarget.CompareTo(weightedTarget) > 0)
{
     this.logger.LogTrace("(-)[TARGET_MISSED]");
     return false;
}

When debugging and logging, it appears that most of the time, hashProofOfStakeTarget and weightedTarget differs in 2 to 4 digits.
So since I was unable to get it working with many nodes and many small weight UTXOs, I made a wallet that was 283% initially when turned on. I have also turned off most nodes, so it is only 3 nodes staking. They now report:
Node staking with 90000.00000000 (241.22 % of the network weight 37310.54188802), est. time to find new block is 00:00:26.
Node staking with 1700.00000000 (4.56 % of the network weight 37310.54188802), est. time to find new block is 00:23:24.
Node staking with 10960.00048140 (29.38 % of the network weight 37310.54188802), est. time to find new block is 00:03:37.
Used to be around 45 to 50K network weight, before all additional staking was stopped. It took a while for the network weight to start falling. AFAIK it is based a bit on the previous history, so doesn't update immediately.
If my memory is correct, it worked better earlier this year (around summer-time) with POS and I did not have issues with delayed block times.
I could have tested this on Stratis main net, but since I don't have that much to stake, it would be very hard to debug and verify.
There should be no real changes on this network compared to Stratis, and I could attempt to verify with a local Stratis network as well, but I doubt it will be any different.
What additional details could I provide to help investigate the issue? Is there something I'm missing in terms of requirements for getting POS to work at a stable rate?
Here are some additional log outputs from earlier today:
POS target is '000000000000ffff000000000000000000000000000000000000000000000000', weighted target for<PHONE_NUMBER>0 coins is '000254098ff41c00000000000000000000000000000000000000000000000000'.
Stake modifier V2 is '5e21d336ef21556595aec4675e8a879923fb5b609a6fa7659baab606709d35cc', hash POS is 'ee109406a0a81981c35067db1097f661b832fee7e85841f793cd0fbcff685a94'.
(-)[TARGET_MISSED]

Later I added some additional logging to see the difference between hashProofOfStakeTarget and weightedTarget:
POS target is '000000000000ffff000000000000000000000000000000000000000000000000', weighted target for<PHONE_NUMBER>00 coins is '00c13f191369acbc000000000000000000000000000000000000000000000000'.
Stake modifier V2 is '1f29cfe7bed2347ea7c4e00af03167cccc5f2bb87a0445aef0a35c0435b8b6b2', hash POS is '1279a4bb82913962052bd31acdd005cd54a372ef61de4b4576fcc793060d9122'.
(-)[TARGET_MISSED] hashProofOfStakeTarget: '8356556710998219572096812812486193335767807938436345694059754601995544924450'  --  weightedTarget: '341436969565148269665186678828471187289138560714575432025826048316801024000'

So in this example, there is only a single digit difference, but I saw 2-4 most of the time:
8356556710998219572096812812486193335767807938436345694059754601995544924450
341436969565148269665186678828471187289138560714575432025826048316801024000

So after I turned off POW again, as the UTXO was confirmed on the new larger wallet, it found a single block and then nothing else for a long time:
Node staking with<PHONE_NUMBER>0000 (283.01 % of the network weight 38867.52851351), est. time to find new block is 00:00:22.
Found new POS block hash '22ee82ef68c6b1f94ec2a867fed0893630821f234997ff6405f83e0f488607b1' at height 1024.

Which made it drop to 90000, as I reported above.
After POW was stopped, it has found two blocks (with POS), 16 minutes in between, and 23 minutes from the previous POW block:

Now it has been running for a little while, so here is the latest blocks:

Node staking with<PHONE_NUMBER>0900 (97.41 % of the network weight<PHONE_NUMBER>9015), est. time to find new block is 00:01:05.

And here is a log where I attempted to reduce the limit for V2 POS, which does help and makes it generate blocks at a normal rate. This log is from a tiny network running Stratis main, single staker:
proofOfStakeLimitV2 @<PHONE_NUMBER>00ffffffffffffffffffffffffffffffffffffffffffffffffffff

[2018-11-02 19:01:54.9461 9] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash '7ad757ea453b3330d31a8e4373fff9cba54354c495e586d83dbca7719cca520e' at height 40.
[2018-11-02 19:03:14.8841 11] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash '8aaf400d2067a66432ffc0ab1cd3302ebe3d448feae7b942aab2ccc1f497f444' at height 41.
[2018-11-02 19:13:05.2118 7] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash 'b7548481aaa07b29501199dc5beff624f70da75598ca808f6b1ebbf01352d5c0' at height 48.
[2018-11-02 19:16:17.4726 23] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash '3e85b4be419cc5d6b20414aafe0902eba0e890a2be183b49c845d0188c59abc0' at height 49.
[2018-11-02 19:21:37.6920 25] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash 'cf06197725ea8f7f83fadc39b4316581fc547b4378b44e8fb98959d96c523f4e' at height 50.
[2018-11-02 19:26:41.5121 31] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash '971956c8f2ecb88df55dd8ed7889343d38d72861c7dbc4fe7a3d10883fafe6f2' at height 51.
[2018-11-02 19:50:09.5991 25] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash '0627fad1edec0c66b734320f6763ad999b3e41c2293743abca225ddee7888672' at height 52.
[2018-11-02 19:53:53.3483 29] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash '7dc39f426b3a53c54b1b58e3e051446604f9af1714f8767af7ff2151d8268d56' at height 53.
[2018-11-02 20:01:21.5386 8] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash '2f1568b6a7c167eb3fbd39e1c98bdb61ec70eab98cf9338c3a0d11fb8a303fae' at height 54.
[2018-11-02 20:03:45.3343 7] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash 'e0587f369ea132c43eb5659e30b10d2aeadbc2135b31fb887fedcaccc294ef36' at height 55.
[2018-11-02 20:04:49.6999 28] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash '5e7405864fbfe2214a777f6348905284538af3eb9d932fcf5d9184bb53dc2f9b' at height 56.
[2018-11-02 20:07:30.1471 8] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash 'e50906ca467f02be0bbe043847a21ec20854a56855add35b920a94ea7bf8ebc3' at height 57.
[2018-11-02 20:16:01.1637 28] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash '6ed3dfbf702d5237eff39c79a99d94182b75280adf626c59942bd814cac5d30f' at height 58.
[2018-11-02 20:34:25.2534 26] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash '43caf7920e25b40305f143fe9b0963e0985e1d32af4ac658afe1ecfc8cee4162' at height 59.
[2018-11-02 20:41:53.5895 8] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash 'a080d5d05891d116ea8c72ace188e26750afb0b7fc88b324591461f995ec5e18' at height 60.
[2018-11-02 20:51:29.3055 25] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash '40cdf1b8616655d675324355db56a86777e0aa6676d71b421dc18be9ebd10346' at height 61.
[2018-11-02 21:02:41.0443 9] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash '099a2d97e1f0e8e877d72d31593a5734f99776c91bacd7986a613963b5af3db0' at height 62.
[2018-11-02 21:05:05.6467 23] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash 'bec6ca5c07b7ebc3988a680bd262cbbd4545a5bd30da4ec2c6dd09c4cb336059' at height 63.
[2018-11-02 21:14:24.9303 24] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash '4a3501366e757ce173f1caa4db213e59f6b5c07446b97762d6622684536e3a28' at height 64.
[2018-11-02 21:50:25.3373 18] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash '6032a480ee9a05a0bc52fd4391ef360137a4f40bb86128d108f6d758f32ab596' at height 65.
[2018-11-02 21:54:57.4199 28] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash 'c32f336f6682f0c9086fea4a776dee0d7a56453352cf94b77831bd3577df5ce5' at height 66.
[2018-11-02 22:24:17.2305 17] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash 'ce9076b207c2bdd9f27ab8d35b676115a2ed6eb1e1e9267d820a0f7e2a3637bd' at height 67.
[2018-11-02 22:32:16.9636 17] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash 'a5e9fa04cc9737964e4b69f9a0a83823ba2927d64c6100253db73f4e6fa20aac' at height 68.

proofOfStakeLimitV2 @ 00000fffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

[2018-11-02 22:54:57.3330 13] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash '146a5f77e9800f4ca07f52e5fa87797416965bef0c7c5522b44ffe6d61032a9b' at height 70.
[2018-11-02 22:56:18.2992 7] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash '90218f0c2126cdd0bcc54a12178befe29ec38f9ff74ae997b5a0ba2aaaed8d2a' at height 71.
[2018-11-02 22:58:26.3824 10] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash '4527bf0960430d668df99fbe79e83e9c49bc9ad15d0f1bb8c86f595ef4a66c64' at height 72.
[2018-11-02 22:58:57.2461 20] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash 'e54b021dcfb6846114725baa69997c639034a56c060083d5038088628ee77a6a' at height 73.
[2018-11-02 23:00:50.5044 5] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash 'a1f3a7f1b59ce49b12e93228f6bc504b3597b7c888a306f126e4d6b9483e9144' at height 74.
[2018-11-02 23:01:05.6379 19] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash 'f67e1584b3f2d30719cf5891bd3f21b849cea8e8020e6ec16541a4ba7cc2b68b' at height 75.
[2018-11-02 23:02:56.9308 19] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash '28d5577d31b42dc992e2642eef89d21e32351454bac8d74227cfe39e09952d2c' at height 76.
[2018-11-02 23:04:16.9825 8] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash 'd5dbf6578278b8d886c26c1914f5cfc50e3744ce8b0bae482e688fb8da7bcfd4' at height 77.
[2018-11-02 23:05:37.1648 13] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash '3f0d3fda0a16619c797eaeb7d8ea3c201f0a2c7f42c43260bfb4a6317b9f3847' at height 78.
[2018-11-02 23:06:57.2707 7] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash '5df95f00bc7d06af3c0ae2427c9d6f1484fd653185b147a9ad10b946f095c736' at height 79.
[2018-11-02 23:08:01.5970 14] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash '3ff3ba9f9c6b8ec4aa7a59a7a401be09908a12fbdfbe757329eb1a6499441532' at height 80.
[2018-11-02 23:08:48.7871 19] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash '09bd55886f94396d3ca7b9c99cdf962afc43fcbc43b4d9945df84059db0b4141' at height 81.
[2018-11-02 23:09:55.2496 19] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash '2fa019448ec1f05bce9290b81e3a77d832639aacf8995cbb97d574c4f35c8aef' at height 82.
[2018-11-02 23:10:25.9789 4] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash '1432f1df8366959c7cf0582dc00d6f9e916294165478ee205b5d18269beb460b' at height 83.
[2018-11-02 23:11:45.9320 19] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash 'f66c9d1d332257eaf039ceee44c9c792f87a593ce251d8f438d4873d29ae99ea' at height 84.
[2018-11-02 23:13:55.4194 12] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash 'd1332bd712d86181661c3ee09f027fde39d03d2ded112fdd3087691c3d1b9b9c' at height 85.
[2018-11-02 23:14:26.2955 5] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash '17a95e6f92fa4ddcc6a73dfc9417bcef4f0a35780c764d7f969f4fd30cd2acf0' at height 86.
[2018-11-02 23:15:16.0092 22] INFO: Stratis.Bitcoin.Features.Miner.Staking.PosMinting+<CheckStakeAsync>d__41.MoveNext Found new POS block hash '292024a16f01861b220a2b4a75266bec27e74aee60d2ab018217e1e21ac390e0' at height 87.

Should it always have this low (high difficulty) value, doesn't really update at all during minting? It's not really a solution to simply reduce the V2 difficulty?

Latest Stratis full node code, with coin maturity set to 1. V2 limit as default on Stratis. Staking with 3 million makes a big difference, compared to 30K.
Here is 3 million (from genesis, single minter):

Here is 30K, after I reset network to genesis:

It is now more than 2 hours since last block.
Then I transferred 1 million to the same wallet, and then stable block generation started again:

Is this still a problem @sondreb ?

I would have to verify, but the solution I ended up with was staking with a lot more. I don't know what the lower limit is, but there appears as though there should be at least a few hundred thousand coins being staked, for it to be stable. When I reported this issue, I had only tens of thousands.
If someone want to run a network of only a few thousands coins in total, this issue might become a big problem, or is this perhaps related to the total amount of UTXO in the chain?

@noescape00 made some calculations regarding minimum stake.
Generally the there is a minimum difficulty of 750k that the nodes will not go bellow that, so if the total amount staking is less then the lowest difficulty block time will be extended (and maybe not even be in a consistent spacing)
This is the par that control the target limit
https://github.com/stratisproject/StratisBitcoinFullNode/blob/master/src/Stratis.Bitcoin.Features.Consensus/StakeValidator.cs#L127
Also note that total UTXO count must me more then coin maturity for the network to continue advancing.

It's not really a solution to simply reduce the V2 difficulty

If you have a network staking with less then the min difficulty then yes you need to reduce it.


Parameterize mariadb image.

Description
Resolves #17
How Has This Been Tested?
Unit tests should be sufficient for this change.
Merge criteria:

[x] The commits are squashed in a cohesive manner and have meaningful messages.
[x] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[x] The developer has manually tested the changes and verified that the changes work

/test unit

/test unit


Fails to load on emacs master after change in define-obsolete-variable-alias

What happened?
Emacs fails to load with backtrace pointing to https://github.com/hlissner/emacs-doom-themes/blob/master/doom-themes-ext-neotree.el#L31 , define-obsolete-variable-alias as the 4th argument is no longer optional.
What did you expect to happen?
Emacs loads normally
Steps to reproduce

Upgrade emacs 28 to https://github.com/emacs-mirror/emacs/commit/32c6732d16385f242b1109517f25e9aefd6caa5c or later
doom build
Start emacs

System Information

Emacs version: 28.0.50 / https://github.com/emacs-mirror/emacs/commit/32c6732d16385f242b1109517f25e9aefd6caa5c
Emacs Distro: Doom
Operating System: MacOS
Installed commit of doom-themes: https://github.com/hlissner/emacs-doom-themes/commit/3761dfce75144e49789b6576e187acd82e2731ee

Solved in #560

Solved in #560


Background url image on column?

Hi,
I would like to add a buttons to the middle of a row of images but having background-url and background-cover attributes are not allowed on mj-columns. Is this possible?
    <mj-section>
      <mj-column >
        <mj-image src="https://unsplash.it/300/300"></mj-image>
      </mj-column>
      <mj-column>
        <mj-image src="https://unsplash.it/300/300"></mj-image>
      </mj-column>
      <mj-column>
        <mj-image src="https://unsplash.it/300/300"></mj-image>
      </mj-column>
    </mj-section>

Hi,
As background image isn't really well supported, we limit it to the section & wrapper element only. If you want you can use mj-style to apply one, but a lot of client won't see it


Revert "Master <- Uat : Student team's work"

Reverts AIforGoodSimulator/model-server#59 due to bug in UI for input Params table

Wrong revert suggested sorry


Strange bike routing - does not use foot/bike path

I see a very strange bike route where the combined foot/cycle path is not used:
https://graphhopper.com/maps/?point=51.508632%2C7.388681&point=51.508656%2C7.38925&point=51.509213%2C7.390779&locale=de&vehicle=bike&weighting=fastest&elevation=true&use_miles=false&layer=TF Cycle
I would expect a straight line from the start point to point 1. (Yellow line in the screenshot)

I've seen this also on osm.org and in the Android app "Komoot".
I don't know since when this happens, but a few months ago it worked as expected.

It is a data issue (path not reachable due to missing street part nearby the one-way). Obvious as other routers have the same problem

I just fixed the data issue.

Thanks @ratrun!


[Feature Request] Insurance Costs

It would be great if the program could allow users to input their monthly insurance expenses. As a pay-per-mile user, my monthly insurance cost varies depending on the mileage driven. It would be helpful to see the monthly cost listed and graphed along with other expenses tracked by the program to understand better the total cost incurred throughout the year. This is not directly related to service or maintenance but would add an additional feature.

Can this be inputted in the Taxes tab?
https://docs.lubelogger.com/Records/Taxes

I did not think of utilizing that feature; that would work for the miscellaneous costs.
Thank you.


Non docker version missing gen_laplacian/ directory and

For those already running Neural-Style, and/or similar projects, many of the dependencies are already setup.
When running git clone, the gen_laplacian/ and everything it contains, is missing.

Not sure what you're driving at with this?  The gen_laplacian isn't needed now in my version...

@martinbenson I assumed it was still needed because of the -laplacian parameter in deepmatting_seg.lua, though looking at the code, is gen_all.py now the way for creating the -laplacian file?

Oh, i see. Yeah, the laplacian files get generated if needed be in gen_all.py (if they've already been done it just reads them from disk). it's all much faster and less messing about now.

@martinbenson When using gen_all.py, how does one manipulate the individual deepmatting_seg.lua and neuralstyle_seg.lua parameters?

I pulled many through to arguments on gen_all.py. See project readme for which. If there are more that would be useful then let me know or just make an edit and do a pull request.

@martinbenson I would prefer a way to have different parameters for each Lua script, but the ADAM optimizer definitely needs the corresponding -learning_rate parameter.
For other parameters, -cudnn_autotune should be toggle-able due to the nature of the command. The -content_layers and -style_layers parameters should be controllable so the user can control the target "levels" at which changes take place in the image. The various weights should be controllable as well for each script. -lbfgs_num_correction helps deal with larger image sizes using the lbfgs optimizer as per this post.
Seeing how others have manipulated the -lambda, -patch, eps, -f_radius, and -f_edge parameters, these might be useful for controlling the level of photo realism produced by the final Lua script.

@martinbenson After playing around with gen_all.py, I can see now why you went with this as opposed to manually running the scripts. It's a lot more efficient than the original project. Great work!
Though it seems that the traditional quirks of Neural-Style still apply, where the most changes to your content image occur depending on how close your image size is to the size of the training images used to train the model. I am curious to see if my optimization tricks will help speed things up, but the Multires technique might need to be implemented as an option to provide more control over the effects caused by the image size parameter.


fix: correct version in README

I think we also need to update to "php": "^8.1" in composer.json since I believe Laravel 10 support php 8.1 or above.


Form validation

for text fields with html5 pattern validation, mld behave weirdly,
if an input is required it will show the error message automatically even before the user focus on the input.
in normal case the error message should appear if the user left the input blank after losing the focus.

No, this is proper by HTML5. We are using the built in validation methods that function this way.
There is no intermediate state (yet) in browsers to work from. So we decided to deal with what HTML5 provides even if it goes against a part of the MD spec for simplicity over recreating validation handling and more sophisticated dirty-state checking ourselves.

I'm assuming nothing has changed here since the behavior appears consistent nearly 4 years later...
MDL is a great library, but it makes me sad that all of the validation errors are displayed before the user has even interacted with these fields. Would prefer if the errors were not displayed until the fields were touched. Anyone know if the HTML5 specification has changed?


Improvements from Iteration 2024.01

Improvement ideas:

Hint in the intro again to the JS Basics Wiki Page
Hint that the solutions are part of the presentations, following the excercise, but we would appreciate it if they dont copy it from the solution, but try to solve and ask for support / share the screen.
In first component or hook add some info about Rendering function, how it works and what happens.
Mention TanStack Router as alternative (especially with the typescript support)
Best Practices: When to shift from Prop Drilling/Passing to some state/context based approach
Explain Smart Components vs Dump Componets
Remove some "outlook-ish" comments, i.e. "Tip about Fragment that we will need at a future point". Also JSX + Typescript = TSX and similar things. It breaks a bit often the presentation flow, as we mention it often beforehand
Best practices: Move worthy states into the routes -> States can be stored with favorites, sent to friends, ...
Add useRef to the list of possible hooks. Generall question, do we need to touch this subject? Maybe together with forms?
Link the DTOs to the Fetch API excercise
Remove the onError function from the React Hook Form sample, but rather the errors from the formState.
The submit button has no text in the react hook form sample 🤣
Add the Profile to the routes in the sample application following the routes chapter.
Solution of React Forms check on errors.X.Type doesnt need to check on the type explicitely, but just on the errors?.x
useEffect sample auch ohne useCallback zeigen (funktion innerhalb useEffect deklarieren?). Auch wird getWindowDimension doppelt initialisiert (im State und initial im hook).
Slightly better description of excercise for useEffect (use word "clipboard")

Necessary:

TDD Slide is broken, the paragraph doesnt match the title. I.e add de TDD slide to the end of the chapter?
Vite run / watch TSC --watch to be added? CI integration? Or https://github.com/fi3ework/vite-plugin-checker

General improvements idea:

start adding sidenotes for presenter view (ideally each for themselves for the chapters they present before the next course instance)


3.0 Upgrade Recipe: Spring MVC and WebFlux URL matching changes [PathMatchConfigurer]

What needs to be done
An automated migration recipe for remediation possibility  4 of Spring MVC and WebFlux URL matching changes should be created.
Reset behavior to prior 3.0 by configuring PathMatchConfigurer (option 4 in #522)
This automated migration recipe should add the WebMvcConfigurer to reset the behavior to 2.7.

Release Note
As of Spring Framework 6.0, the trailing slash matching configuration option has been deprecated and its default value set to false. This means that previously, the following controller would match both "GET /some/greeting" and "GET /some/greeting/":
@RestController
public class MyController {

  @GetMapping("/some/greeting")
  public String greeting {
    return "Hello";
  }

}

As of this Spring Framework change, "GET /some/greeting/" doesn’t match anymore by default.
Developers should instead configure explicit redirects/rewrites through a proxy, a Servlet/web filter, or even declare the additional route explicitly on the controller handler (like @GetMapping("/some/greeting", "/some/greeting/") for more targeted cases.
Until your application fully adapts to this change, you can change the default with the following global configuration:
@Configuration
public class WebConfiguration implements WebMvcConfigurer {

    @Override
    public void configurePathMatch(PathMatchConfigurer configurer) {
      configurer.setUseTrailingSlashMatch(true);
    }
  }
}

Note
We want to contribute as many migrations as possible to OpenRewrite.
Therefore it's desired to implement this recipe as a plain OpenRewrite recipe when possible.
See OpenRewrite docs and Using OpenRewrite recipes

Condition
Any class annotated with @RestController was found.
Description
There's more than one way to deal with the change of Spring MVC and WebFlux URL matching changes.
This issue should provide a recipe to add a WebMvcConfigurer as described in the Release Notes.
Things to keep in mind:

The added class must have a unique name
The correct package must be chosen so that Boot can pick it up.
The recipe should be provided using plain OpenRewrite
A dedicated YAML recipe declaration should be provided to reference this recipe from the report section (#522)
The recipe file name should be sbu30-248-add-PathMatchConfigurer

Report Section Issue
#522
DoD

[ ] Action implemented

[ ] Description provided
[ ] Tests (single and multi-module)

[ ] Condition implemented / reused

[ ] Description provided
[ ] Tests (single and multi-module)

[ ] Recipe YAML added

[ ] Test
[ ] Integration test (single and multi-module)

[ ] Report Section YAML references this migration recipe

Additional Resources & Information
TODO for template, link to:

Example
Testing Actions
Testing Conditions
Testing Recipes
Integration Tests

@fabapp2  sorry for the late reply , I was going through the documentation you provided , so we need to enable Trailing Slash Match inside the WebMVCAutoConfiguration ?

@ishu-thakur correct. it's basically adding the given source code to the ProjectContext (to topmost application modules).
I wouldn't mind if you so it with SBM
projectContext.getApplicationModules().getTopmostApplicationModules().stream()
                .forEach(m -> {
                    String basePackage = m.getMainJavaSourceSet().getJavaSourceLocation().getPackageName();
                    String code = renderJavaCode(basePackage);
                    m.getMainJavaSourceSet().addJavaSource(projectContext, code, basePackage);
                });

Simplified as it should have a check for the unlikely case that a class with the chosen name already exists in the package and choosing a different name in this case.
You can use freemarker to render the code or just plain java string replacement, up to you.

@fabapp2 for clarity I want to ask you that

I need to add the sbu30-248-add-PathMatchConfigurer.yaml under recipes inside the sbm-reciepes-boot-upgrade ?
To add the given above code to ProjectContext inside the apply method of what Topmost applications modules ( Do you mean modules with sbm  in their name ?
And I didn't quite understand what to do with freemarker ?
Sorry, I am just new so have questions to get clarity before I proceed further :)

Hi @ishu-thakur
Great questions!

@fabapp2 for clarity I want to ask you that

I need to add the sbu30-248-add-PathMatchConfigurer.yaml under recipes inside the sbm-reciepes-boot-upgrade ?

That's correct, actually this changed in the branch webapp-demo where migrations for Spring Boot 3 related migrations were moved to src/main/resources/recipes/27_30/migration and the YAML for the report to src/main/resources/recipes/27_30/report. Not sure when exactly I'll be able to merge this back, so you might want to use the dir you mentioned for now.

To add the given above code to ProjectContext inside the apply method of what Topmost applications modules ( Do you mean modules with sbm  in their name ?

The api to access "topmost" modules, actually modules that will create a deployable (e.g.  a web application, or a shell application), these are currently the modules that no other module in the scanned project depends on.
They can be accessed like so:
projectContext.getApplicationModules().getTopmostApplicationModules();

And I didn't quite understand what to do with freemarker ?

For "migrations", called "recipe" in the issue (I should change this), there's nothing to do with freemarker.
The idea is to have a report section in the generated report (see #522 ) where freemarker might be useful to render dynmic parts of the report section. The report section allows applying recipes to the application by pressing a button (if applicable, not all changes can be automated). See here:

You might want to look into sbu30-report.yaml to see how this migration gets (already) linked in the report.

Sorry, I am just new so have questions to get clarity before I proceed further :)

Totally fine. Sorry for my late reply.
Hope this was helpful.

Hi @ishu-thakur,
any news on this? Let me know if I can help.

Hi @fabapp2 I'm sorry for late reply , I got busy with my work . But if this issue is still open i can start working on it again ?

Hi @ishu-thakur glad to have you back.
It's actually linked in the 0.13.0 report but nothing's behind it.
So yes, happy if you want to proceed. 👍


Load proto with the same options as the generated types

This PR adds the protoLoader.loadSync options so that the JS code at runtime matches the static types that are provided by this library.
Currently, the golang uint64 fields are being returned as Longs instead of strings and enums are numbers instead of strings. The runtime values are different than the TS types.
The options should stay in sync with the ones that the proto-loader-gen-types command in package.json uses.

Thanks for the contribution @jamaljsr


Clean up root build folder when running yarn clean

Background
Improve yarn clean and yarn clear-cache commands to remove all relevant files
Solution
Related files were not cleaned up in the current commands so I made some improvements
🎩

Run yarn build and verify that built files (*.d.ts, *.esnext, *.js, *.mjs, anything inside /build) are created
Run yarn clean and verify that all built files are removed
Run yarn clear-cache and verify that the the .sewing-kit directory is delete

Checklist

[X] I have :tophat:'d these changes

Looks good! Just make sure you rebase because it looks like the VisuallyHidden import was added back in and CI isn't complaining.

@elanalynn once I merge it should know to put it on top of the latest commit on main :)

@elanalynn once I merge it should know to put it on top of the latest commit on main :)


data: project addition by Shivam Katare

Add a new project to the list
I want to add a new project to the list which is a gradient generator user can generate the gradient colors, modify those colors, get the random colors suggestions, and then, will able to copy its CSS code.

I'm in GSSoC'23. Kindly assign me this issue.

Tech Stack: HTML5, CSS3, JavaScript

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Completed. Thanks for your contributions 🎉 ❤