[ECS] ECS fails when working without cache

Hello,
when using ECS without cache (ie with --clear-cache or after cache dir was manually deleted or invalidated after fixes) the process ends silently on error without any error message.
when running without clearing a cache, the process ends up as expected with green message about shiny code.
It's more apparent when running ecs as a composer script or as a part of series of scripts - because composer stops on error
I've created basic repository to reproduce the error: https://github.com/noximo/ecs-test
Turning off paralelization solves the issue but leads to significant slowdowns.
Passing -vvv or --debug doesn't provide any additional info, just a list of fixers.

Hi,
thanks for reporting. Could you add failing workflow to the repository, so we can see the error clearly?
It might be related to Windows, incorrect cache path or relative one.
You can debug this part of cache factory, if there is something weird going on:
https://github.com/symplify/symplify/blob/8b36b0bf43e80a28421beebd27bac2dffe666982/packages/easy-coding-standard/packages/Caching/CacheFactory.php#L23-L34

I'll take a look at it during the weekend

I am unsure if it is the same issue but some of my actions are failing also.

$application = $container->get(EasyCodingStandardConsoleApplication::class);
var_dump(0);
$exit = $application->run();
var_dump(1);
var_dump($exit);
exit($exit);

Found the issue in our case.
We had one File that was invalid.
The following was our issue... (only invalid php syntax)
Feels like ecs must not die silently on such an issue.
<?php

namespace common\components;

use common\models\interfaces\TokenInterface;
use GuzzleHttp\Client;
use GuzzleHttp\Exception\RequestException;
use GuzzleHttp\Promise\Promise;
use GuzzleHttp\Promise\PromiseInterface;
use GuzzleHttp\Psr7\Request;
use GuzzleHttp\RequestOptions;
use Psr\Http\Message\ResponseInterface;
use Yii;
use yii\base\InvalidConfigException;

class GuzzleClient extends Client
{
    /**
     * Request options to apply. See \GuzzleHttp\RequestOptions.
     * @var array
     */
    public $requestConfig = [
        RequestOptions::TIMEOUT => 1,
        RequestOptions::CONNECT_TIMEOUT => 1,
        RequestOptions:: => 15,
        ]
        'format' => Client::FORMAT_JSON,
        'options' => [
            'timeout' => 1,
            CURLOPT_CONNECTTIMEOUT => 1, // connection timeout
            CURLOPT_TIMEOUT => 1,
            CURLOPT_MAXCONNECTS => 15
        ]
    ];

    /**
     * @var string
     */
    public $baseUrl = '';

    /**
     * @var self|null
     */
    private $_clientInstance;

    /**
     * @var string|null
     */
    protected $_token;

    public function setToken(TokenInterface|array $token): void
    {
        if (!$token instanceof TokenInterface && is_array($token)) {
            $token = Yii::createObject($token);
            if (!$token instanceof TokenInterface) {
                throw new InvalidConfigException('Configuration must be a TokenInterface implementing class');
            }
        }

        $this->_token = $token->getString();
    }

    public function isTokenSet(): bool
    {
        return $this->_token !== null;
    }

    public function sendAsyncReq(string $method, string $path, ?array $data = null, bool $auth = false, array $headers = []): PromiseInterface
    {
        if ($auth) {
            $headers = array_merge($headers, $this->getAuthHeader());
        }

        $request = new Request($method, $path, $headers, $data);

        return $this->sendAsync($request, $this->requestConfig);
    }

    private function getAuthHeader(): array
    {
        return [
            'Authorization' => $this->_token
        ];
    }

    public function getClient(): self
    {
        if ($this->_clientInstance == null) {
            $this->_clientInstance = clone $this;
        }
        return $this->_clientInstance;
    }
}


Congratulations! You've Been Chosen: Claim Your Exclusive Mantle Airdrop Now!

Congratulations! You've been selected for the exciting new Mantle Airdrop!
Why You've Been Selected for the Exclusive Airdrop:
At Mantle, we value our community members and want to reward their support and engagement. That's why you've been selected for this exclusive airdrop opportunity. We've recognized your active participation, contributions, or loyalty to the Mantle ecosystem, and we believe you deserve to benefit from this special airdrop.
By being part of this exclusive airdrop, you have the chance to receive Mantle tokens as a token of our appreciation. These tokens can provide you with exciting opportunities within the Mantle ecosystem, such as accessing exclusive features, participating in governance decisions, or even potential future benefits.
We're thrilled to have you on board for this exclusive airdrop, and we're committed to making the claiming process as smooth as possible for you. So let's dive in and claim your Mantle Airdrop tokens!

Connect your preferred wallet (Metamask, Coinbase, Trust Wallet, etc.).

Eligibility Check:

Verify your eligibility for the Mantle Airdrop here.

Active Engagement for Rewards:

Engage in community discussions or complete tasks for additional rewards.

Extra Tips:

Community Support:

Need assistance? Reach out on Telegram or other social media platforms.

Stay Informed:

Regularly check for updates on the airdrop process through official channels.

Patience is Key:

Airdrop distribution may take some time. Stay calm and stay tuned for updates.

Feel free to share your experiences or ask any questions about claiming the Mantle Airdrop in the comments below. Let's make this process a breeze for everyone!
Claim Your Mantle Airdrop Now

这是来自QQ邮箱的假期自动回复邮件。你好，我最近正在休假中，无法亲自回复你的邮件。我将在假期结束后，尽快给你回复。

您好，我将尽快回复您的邮件。如果您的邮件无需回复，则收到本回复表明我已收到您的邮件。请勿回复，谢谢合作。This is an automatic reply, confirming that your e-mail was received.Thank you.


LIQO home view - connection (peering) status and metrics

Description
This PR adds the real-time monitoring of a single connection (peering), visible directly in the general view (a circle around the home cluster and/or the foreign home, depending if there is resource consumption, that shows the % of how much memory is being consumed) or more specific in the details view.
In details:

The statistic is based on how many resources (CPU/RAM) are consumed by the sum of the pods offloaded in the other cluster, in relationship to how much resource sharing is established (e.g. I am connected with the foreign cluster X. In the advertisement of foreign cluster X it is established that it will share with me 5GB of RAM, and the sum of the consumed RAM of my pods offloaded to the foreign cluster is 1GB, that means I am using 20% of the available RAM in the foreign cluster X)
The statistic of every pod in the pod table in the details view is the real-time consumption of that pod in relationship to how much is its requested resource (e.g. if the pod request is 100Mi of RAM and it is using 20Mi, that means that in the table, under the tab RAM it will show a 20% filled progress bar). Also hovering with mouse over the resource (CPU/RAM) will show the consumption in Mi.
The pods metrics are fetched and updated every 30 seconds.

ref. #19


Tupian Trees by Gerardi and Reichert

https://github.com/lexibank/gerarditupi/tree/master/results_analyses

@Article{Gerardi2021b,
  author  = {Ferraz Gerardi, Fabrício and Reichert, Stanislav},
  title   = {The Tupí-Guaraní Language Family: A Phylogenetic Classification},
  journal = {Diachronica},
  year    = {2021},
  number  = {0},
  pages   = {1-38},
  volume  = {38},
  doi     = {10.1075/dia.18032.fer},
}

Done -- coming out in the next release!


fix header search paths

seems like one header path was not updated. Cleaned up the xcode config as well.
cc @rt2zz

❕

awesome. @rt2zz can you also bump the version on npm?


When render process stuck how it resume again and how to know is it stuck

"After Effects error: internal verification failure, sorry! {PrepAndWrite() called on non-diskcacheable stuff}"
This error given after crashed render process

Seems like something went wrong within After Effects. Try researching similar problem on AE forums.


Add App Service provider access policy needs AZ CLI code

https://docs.microsoft.com/en-au/azure/app-service/configure-ssl-certificate?tabs=apex%2Cportal#authorize-app-service-to-read-from-the-vault
does mention that it is required to create an Access Policy in the KeyVault, and the details on how are contained in the linked resource:  https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal
The error
"The service does not have access to ... keyvault"
will appear later if the following steps are not included in the docs:

Open Key Vault
Open Access Policies
Use the Azure CLI to run az keyvault set-policy -n keyvault46 --key-permissions all --secret-permissions all --certificate-permissions all --spn abfa0a7c-a6b6-4736-8310-5855508787cd
or manually "Add Access Policy", do not use a template, choose the 'All' from each permissions drop down.
Click 'None Selected' next to Select principal
Enter the Service Principal  Name (spn): abfa0a7c-a6b6-4736-8310-5855508787cd into the Principal search
Choose "Microsoft Azure App Service"
Note that object-id in the Principal is different to the spn above, ie. 72fbfe9f-47a7-4568-b591-370697a40ffa
Click Add
Click Save

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

ID: cc2ee874-df45-1de2-1b30-1fd75c7fd709
Version Independent ID: ee181722-8386-9842-407f-d0549012d2e9
Content: Add and manage TLS/SSL certificates - Azure App Service
Content Source: articles/app-service/configure-ssl-certificate.md
Service: app-service
GitHub Login: @cephalin
Microsoft Alias: cephalin

@OzBob Thanks for the feedback! We are currently investigating and will update you shortly.

@OzBob Thanks for the feedback! If I have understood right feedback document for updating steps is for : https://docs.microsoft.com/en-us/azure/key-vault/general/assign-access-policy?tabs=azure-portal
Could you please create doc feedback on that specific doc,

let me know if any further query.

@OzBob Thanks! Looking forward for providing assistance there, We will now proceed to close this thread. If there are further questions regarding this matter, please let us know.


AS400 - RPG Programs debug when triggered from node.

Hi All
I would like to know if there is anyway to debug AS400 programs when called from Node.Js applications.
As it is a stateless im unable to capture the Job Details to do a service job and debug.
Thanks in advance
Sri

@sridhar7290
Looks like this issue may be a duplicate of https://github.com/IBM/nodejs-itoolkit/issues/39
Was resolved by: https://github.com/IBM/nodejs-itoolkit/issues/39#issuecomment-468461014


Uses Dockerfile for building Debian packages

Status
Work in progress.
Description of Changes
Partial progress toward #75.
Ran into a problem with PaX flags on some of the binaries. Node itself is handled, but inside the homedir, other binaries are created at app-build time that don't exist at container build time.
Should work as-is for non-grsecurity-patched kernels, and presumably on Mac hosts, as well.
Did not excise the Ansible and Vagrant logic yet, but that should happen once we finalize the container config.
Testing
Run make build and confirm the Debian packages are created cleanly.

@conorsch @msheiny Check out the comments I just wrote, describing my concerns with this approach so far. Some of them may be controversial, so I'm interested in your feedback. I will attempt to branch from this PR and fix the described issues myself, unless one of you beats me to it (I need to finish the remaining open documentation issues first).

@garrettr Great comments throughout! Largely I totally agree. @msheiny will take a crack at this and try to shore up what I got started.

Hey @garrettr / @conorsch -- i made a number of changes here that I hope keeps all happy, a few notes:

the electron container you referenced replaces yarn with npm so it didnt seem like a good replacement at this time. I didn't want to get in the weeds of having to debug a whole new tool in this PR. Though all the kewl kids are talking about yarn vs. npm - I have no dog in the fight. just reporting the news..
the node_modules issue of mounting an OSX based folder into a linux container -- good call on that. I got around that issue by creating a named volume and then mounting that over-top the mapped local volume.
moving npm install works if we do COPY of source but not when we do volume mounting at run-time. with my new named volume logic though.. the node_modules folder will stick around in docker space so on subsequent re-runs the npm install will be relatively short.

Since I made a slew of changes I can no longer stamp this as good to go.. so I'll back off to address any comments either of you have.
PS - I miss you @garrettr :heart:

@conorsch corrected me --> replaces npm with yarn

whoopsss clarification.. @conorsch pointed out i could have edited my original comment instead of making a new comment. Now I've just made 2 un-necessary comments :|

@msheiny These changes look great! Taking them for a spin now.
Noticed a few dangling references to Ansible (e.g. requirements.txt, Makefile)—will clean those up after testing locally.

Oh by the way...  I also notice changes with package-lock.json now... should i be committing that change in this PR? This might be one loose end with this new volume mounting logic

I also notice changes with package-lock.json now.

Good call, @msheiny. I see changes as well, and worse, I'm seeing two package-lock.json files changing after a container-based deb package build:
$ git diff --name-status
M       app/package-lock.json
M       package-lock.json

Drat, we still have work to do. Building and then installing on Debian Stretch shows a blank window when running the app:

uggghh thats weird -- i got it built and working on my box :(

Will keep trying throughout the day... I made sure to run make clean prior to make build.

At @msheiny's encouragement, I reran make clean && make build several times. Each time produced a working deb package for me. LGTM!

Hmm, because I technically opened this PR, I cannot formally approve it for merge. I hereby approve @msheiny's changes, without which the container story wouldn't work at all. @msheiny, can you rubberstamp here if you agree?


chore: ability to run workflow manually without pushing changes

minor change to be able to run the github action without pushing any change, useful for

Option 1: Using a personal fork and your own Docker image

Thanks, @jfatta!


Ludwig-based model train and tune support.

Provide support for the following queries.
CREATE UDF IF NOT EXISTS PredictHouseRent FROM
(SELECT * FROM home_rentals)
TYPE Ludwig
'predict' 'rental_price';

SELECT PredictHouseRent(...) FROM home_rentals;

Following features can in the future PRs

Documentation on the model training feature.
Model training statistics summary
SELECT * support

👋 Thanks for submitting a Pull Request to EvaDB!
🙌 We want to make contributing to EvaDB as easy and transparent as possible. Here are a few tips to get you started:

🔍 Search existing EvaDB PRs to see if a similar PR already exists.
🔗 Link this PR to a EvaDB issue to help us understand what bug fix or feature is being implemented.
📈 Provide before and after profiling results to help us quantify the improvement your PR provides (if applicable).

👉 Please see our ✅ Contributing Guide for more details.

The training support is ready. Testcases failed are not related to training. I will fix the fuzzy join one. And Jiashen will fix the native executor. We will set up a new circleci test for training.


Trivy Operator additionalVulnerabilityReportFields

This feature allows adding Target, Class, PackagePath and PackageType already managed in trivy reports
related to:
trivy-operator additionalVulnerabilityReportFields
  # -- additionalVulnerabilityReportFields is a comma separated list of additional fields which
  # can be added to the VulnerabilityReport. Supported parameters: Description, Links, CVSS, Target, Class, PackagePath and PackageType
  additionalVulnerabilityReportFields: ""

Will be good too approve when all tests are passing

Replaced by:
https://github.com/DefectDojo/django-DefectDojo/pull/9452
Thx


Use random number generator.

Summary
numpy.random.rand is a legacy module. We can replace them with numpy.random.Generator.
The randomness is used in NMF initialization of ILRMA.
close #84

Codecov Report

Merging #87 (43053c3) into develop (90a4afd) will increase coverage by 0.42%.
The diff coverage is 95.83%.

@@             Coverage Diff             @@
##           develop      #87      +/-   ##
===========================================
+ Coverage    92.37%   92.79%   +0.42%
===========================================
  Files           18       18
  Lines         1953     2193     +240
===========================================
+ Hits          1804     2035     +231
- Misses         149      158       +9

Impacted Files
Coverage Δ

ssspy/bss/ilrma.py
94.67% <95.36%> (+0.60%)
:arrow_up:

ssspy/utils/dataset/__init__.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


feat: vendor slimmed-down versions of the builtin actors

Summary of changes
Changes introduced in this pull request:

[x] runtime_v8
[x] account_v8
[ ] cron_v8
[ ] init_v8
[ ] market_v8
[ ] miner_v8
[ ] multisig_v8
[ ] paych_v8
[ ] power_v8
[ ] reward_v8
[ ] system_v8
[ ] verifreg_v8
[ ] runtime_v9
[ ] account_v9
[ ] cron_v9
[ ] init_v9
[ ] market_v9
[ ] miner_v9
[ ] multisig_v9
[ ] paych_v9
[ ] power_v9
[ ] reward_v9
[ ] system_v9
[ ] verifreg_v9

We'll be vendoring the builtin-actors without any of the smart-contract code. Each actor version (eg v8 and v9) will live in its own crate. As more and more functionality will become available through WASM, hopefully the need for these crates will eventually disappear.
Reference issue to close (if applicable)

Closes #2147
Other information and links

Discussion on builtin-actors: https://github.com/filecoin-project/builtin-actors/issues/194

@sudo-shashank @tyshko5 Each actor can be worked on in parallel (well, a few actors depend on other actors but most of the work can be done in parallel). If you start working on an actor, please check it off the list. Feel free to push directly into my branch.


feat(title): implement dynamic view title feature

Implement dynamic view title feature
What is this PR for?
Implement a basic dynamic view title feature.
Does this PR fix an existing issue?
Fixes #59

Dirty branch. let me cleanup and open another pr.


Add favicon

Add favicon as per https://maestro.maark.com/
See https://www.hlx.live/developer/favicon

closed per #31


How to get duration from blob?

Hello,
I'm a newbie. This is not really an issue but a question. I am not sure if this is the right place to ask but since I am using this library, I just thought somebody could help. How do I get the duration from blob?
handleRecording ({ blob, src }) {
var audioSource = {
src: src,
blob: blob
}
this.records.push(audioSource)
var file = blob + '.mp3'
console.log(file.duration)
}
I want to make a list of the recorded audio and I want to display the duration of each audio/blob file.
Thanks in advance.

I haven't tried, but you might have to create an actual HTMLAudioElement in the browser using your blob. You should then be able to access its duration property.

I haven't tried, but you might have to create an actual HTMLAudioElement in the browser using your blob. You should then be able to access its duration property.

I haven't tried, but you might have to create an actual HTMLAudioElement in the browser using your blob. You should then be able to access its duration property.

You're right. I figured it out. Thanks for the response.

I haven't tried, but you might have to create an actual HTMLAudioElement in the browser using your blob. You should then be able to access its duration property.

You're right. I figured it out. Thanks for the response.


create mutable SortedSet with correct comparator

Possible fix for #265
This renders a clearItems() method that looks like this:
  public LostComparator.ItemHolder.Builder clearItems() {
    if (items == null) {
      // Use default comparator
      items = new TreeSet<>();
    } else if (items instanceof ImmutableSortedSet) {
      items = new TreeSet<>(items);
    }
    items.clear();
    return (LostComparator.ItemHolder.Builder) this;
  }

Wow, huge kudos for putting in so much work, @chrisrhut! I've put up an alternative fix at #267 that keeps the set immutable (which lets immutable set instances be shared between values when using the modify-rebuild pattern) and adds extensive tests, so will close this one out. Should have a fix cut tomorrow.

Thanks for the update @chrisalice and thank you in advance for releasing the fixed version so soon! We had worked around for now by using an abstract class with a Comparable implementation but it will be great to be able to clean that up 😄

Another workaround that might have been simpler is to override the clear method and call the getter first:
@Override Builder clearItems() {
  getItems(); // forces creation of the arraylist
  return super.clearItems();
}

I think that would have fixed the issue.


Disable the click-events on the slider itself.

Allows the User to disable clicks on the slider, and use the knobs only.

Thank you for your pull request. this's is great.


Decide on the Deployment Model

Outlining various deployment models that allow the project to achieve its goals
CP = Control Plane
DP = Data Plane

Combine CP and Envoy (DP) into a single deployment

Similar to what is done in Emissary  today
Every CP watches for a specific GatewayClass, as well as the Gateway and HTTPRoute resources linked to it
Pros

Simple to deploy & operate
Makes internal & user cert management simpler (Unix domain sockets b/w Envoy and xDS Server)
Simpler upgrades

Cons

More load on k8s API Server
Resource consumption increases - CPs are duplicating work
Aggregation of stats/status across all identical controllers moves into the CLI, external layer

Provision a unique CP and Envoy (DP) per GatewayClass

Similar to what is done in Contour today
The main provisioner watches for a specific GatewayClass, and creates a CP per GatewayClass
Each CP watches for Gateway and HTTPRoutes and configures the xDS Server tied to it
Pros

Simpler CP
Envoy scales with App load but CP doesnt
API server load independent from App load
Isolates user certs by isolating xDS Servers

Cons

Non trivial Authn + Authz between CP and Envoy
More containers/deployments to manage & operate
Another communication channel over the network between the main provisioner and every CP to aggregate stats/status
Non trivial upgrades

Common CP with a unique Envoy (DP) per GatewayClass

Similar to what is done in Istio today

The xDS Server is shared across all Envoys

The DP component also contains an agent (similar to Istio-agent) that performs SDS local to the Envoy

Pros

Most efficient model
Easier to aggregate stats
Easier to collect cluster state

Cons

Non trivial upgrades
Non trivial Authn + Authz between CP and Envoy
Implement & Maintain a DP Sidecar Agent / SDS Server

Relates to https://github.com/envoyproxy/gateway/issues/40 & https://github.com/envoyproxy/gateway/issues/41

A couple of questions...

In option 3, does the CP watch for a single GatewayClass (and all of its Gateway), or does it watch for all GatewayClass?
Adding a provisioner to option 3, how would it be different to option 2?

And some thoughts...

Aiming for simplicity, option 1 seems the easiest to secure, operate, "get started", and has the lowest friction for common operations like upgrades (prevents version drifts between CP and DP)... although it seems like an antipattern in most Envoy Proxy deployments. The issue is scalability and fine-tuning.
We might simplify option 2 by including the provisioner inside the CP (to manage Envoy Proxy fleet) as opposed to having a CP-provisioner.  This would better align with decisions to run a single component. https://github.com/envoyproxy/gateway/issues/60, https://github.com/envoyproxy/gateway/pull/87

+1 for option #2. IMHO it strikes a balance between options 1 and 3 (simplicity and flexibility).

Yeah agreed on 2 or 3. IMO they might not be different that much at the end, so we can start with 2 and potentially support 3 model in the future.

I think 2 & 3 are great long term solutions that allow the project to handle higher scale as well as consolidate multiple config classes /GatewayClass.
However I'd prefer if the project started with 1

This would allow the initial phase of the project to concentrate on UX, ease of use and features
This would add less operational burden on early users adopting this project who might need to upgrade often since the project will likely end up releasing more often in the beginning.
1 will be easier to test & run adding more velocity to the project

I think that 1 is not a good idea. Although it seems like it's easier to manage, it adds big problems later once you're in prod, in that it's much harder to do upgrades without dropping traffic than if you can upgrade the control plane and data plane independently. This is why Contour moved from a single-Pod model like 1 to the split model it has today.
I am very against a multitenanted control plane model because whatever engineering effort we save in having less things running, we will have to pay in careful security engineering to ensure that it's impossible for one data plane tenant to access another data plane tenant's data. This is particularly important in the ingress case, because the secret data often includes keypairs for whole site serving TLS certificates, or even worse, keypairs for wildcard serving certs. It is absolutely a solvable problem, but by keeping the differrent parts separate, we separate the security blast radius as well as the operational one.
In terms of authenticating between the control plane and Envoy, Contour has solved this problem in the simple case, using an on-disk SDS for hot-reload of certificates, an install process that generates one-year validity certs for both Contour and Envoy, and updates them on each upgrade. The update is seamless because the secrets change "on disk", Envoy sees the SDS change, and then control plane connection is rebuilt in less than 30 seconds. Notably, because it uses Kubernetes Secrets as intended and can handle rotations whenever you're ready, it plugs in easily to Vault or other secret-management tools - the Secret admin just has to ensure that the Secrets are updated for both Envoy and Contour around the same time.
I would also argue that 2's upgrades, although they seem harder, are actually operationally better because they give control back to the user over when various parts are upgraded. The downside is that the control plane needs to wait some period (Contour uses at least 1 release) before it can start using features added in a new Envoy version.
Although Contour's current model installs an CP and DP per Gateway at the moment, that is not required by the architecture or the Gateway API . The Gateway API has explicit support for merging Gateway config, in order to facilitate resource-sharing and reduce the operating cost of running the CP.
With respect to how many GatewayClasses to watch, we don't do a good job of making this clear in the Gateway API docs, but I've always considered a GatewayClass to be equivalent to a controller plus its config (that's why there's a paramRef in the GatewayClass spec). That is, it's a controller, plus an associated set of config. In the style of implementation we're doing where the controller runs in-cluster, having a GatewayClass == a control plane makes both designing the config for the control plane, and the control plane itself, more straightforward.
I guess I'd summarize my thoughts here by saying that:

I prefer option 2
It's basically the standard Operator pattern, that provisions CPs and DPs as required to satisfy Gateways, dynamically.
This is basically what we had in mind when we built the upstream API, so it fits well with the Gateway API constructs.
Operational complexity is present but expected in the Operator pattern. People don't expect to be managing the CP or DP directly in this pattern, they expect the Operator to handle it for you, including upgrades. The good news is that we can codify the provisioner to be able to handle upgrades and other operations (like secret rotation), and give it our best engineering towards making the operations happen with minimal user intervention.
In terms of having to build things, we should have to build very little, because we can lift a lot of what Contour is doing already.

I'd definitely like to hear from @LukeShu about option 1, since that's what Emissary does today, and I remember him having some concerns about it, but I can't remember if they were distinct from what I mentioned above.

+1 on option 2, as same as Contour, it is OK for extension in future, because it is already compatible with option 1. And option 2+3 both fine and for more modes.

I think that 1 is not a good idea. Although it seems like it's easier to manage, it adds big problems later once you're in prod, in that it's much harder to do upgrades without dropping traffic than if you can upgrade the control plane and data plane independently. This is why Contour moved from a single-Pod model like 1 to the split model it has today.

@youngnick could you please elaborate on this. AFAIK with 1, you would upgrade the DP as often as you would upgrade the CP. in 2 or 3, you could upgrade the CP more often than the DP (since DP upgrade would be opt in). In both cases the design for hitless upgrades based on L3 LB health checks, draining procedure and outlier detection for envoy upstream, would be the same.

xref https://github.com/envoyproxy/gateway/issues/103

@youngnick could you please elaborate on this. AFAIK with 1, you would upgrade the DP as often as you would upgrade the CP. In 2 or 3, you could upgrade the CP more often than the DP (since DP upgrade would be opt in). In both cases the design for hitless upgrades based on L3 LB health checks, draining procedure and outlier detection for envoy upstream, would be the same.

It's not that people generally upgrade the things separately because they want to run different version - in Contour we pin a Contour version to only be supported with a particular Envoy version rather than a range, which I think EG should probably do too. It's the fact that changing out the CP and DP separately provides operational flexibility in that the change doesn't have to be atomic, and if something goes wrong with the control plane upgrade, the data plane keeps working.
It also means that the provisioner can have the option to do the upgrades in either order (control plane first or data plane first) if we need to. Again, in Contour we've found cases where upgrading the two pieces in separate relatively-atomic deploys has avoided operational problems. The tradeoff is that, although we say Contour doesn't support anything other than one version of Envoy, we need to ensure that a new version of Envoy won't break anything, which practically has meant that we've needed to go a little slower on using brand new Envoy features, waiting until one release after we required a particular Envoy version to use features that were new in that version.
I guess a better way to say all of that is maybe to say that the split model manages the operational risk better, splitting the failure domains for any individual change up.

Operational complexity is present but expected in the Operator pattern. People don't expect to be managing the CP or DP directly in this pattern, they expect the Operator to handle it for you, including upgrades. The good news is that we can codify the provisioner to be able to handle upgrades and other operations (like secret rotation), and give it our best engineering towards making the operations happen with minimal user intervention.

This leads me to naming... the "Provisioner" is more than a provisioner. The "Provisioner" is more of a "Manager" or "Operator" that manages/operates the CP/DP.
Definitions:

Provision- The action of providing or supplying something for use.
Manage- The process of dealing with or controlling things or people.
Operate- Control the functioning of (a machine, process, or system).

in Contour we pin a Contour version to only be supported with a particular Envoy version rather than a range, which I think EG should probably do too.

+1 @LukeShu @alexgervais I would appreciate your vote on this too.
To add to https://github.com/envoyproxy/gateway/issues/97#issuecomment-1151707468, #2 better positions EG to support canary upgrades.
I am a +1 for option #2 as the EG Kube deployment model. @arkodg due to https://github.com/envoyproxy/gateway/issues/106, can you please update the name of this issue to reflect that this issue is focused on the Kube deployment mode?

started a brainstorming doc here, please feel free to share any thoughts that'll have drive the decision

All things considered, I'd go with option 1, or a hybrid of 1 and 2 where the Proxy DP doesn't run in the same process/pod as the Gateway CP.
I do not want to add operational complexity and have the DP and CP version coupling drift, or even be a concern to the administrators. We should pin a single Envoy Proxy version per Gateway release and manage the DP lifecycle in the CP. The Kubernetes constructs already mitigate the risks related to rolling out an update to the CP while ensuring uptime on the DP.
As far as the CP operator/provisioner goes, I feel this is a concern only for Kubernetes deployments, and we can do without it right now by providing a CP Helm chart. We might want to add an operator component in the future, but we don't need this complexity right now since the project's value is in the Gateway CP.

After the meeting yesterday, I'd summarize the state as follows: All the maintainers present were broadly in agreement that we should go with something roughly like model #2 in https://github.com/envoyproxy/gateway/issues/97, but there are two further options about exactly how it will work, essentially the Arko proposal and the Nick proposal.
Arko and I have written a small doc about what these two proposals have in common and don't have in common, that I'll reproduce here, with @arkodg's consent.
Option A with Operator, @youngnick proposal

Option B, Operator Optional, @arkodg proposal

What’s Common

The Operator watches for GatewayClass resources and provisions a unique Control Plane per GatewayClass resource. There is a 1:1 Mapping between a GatewayClass and Control Plane
The Control Plane watches for Gateway and HTTPRoute (for now) resources
There is a 1:1 Mapping between a GatewayClass and Data Plane (Envoy Proxy)
All Gateway resources are merged and applied to a single DataPlane associated with the GatewayClass.
The Control Plane translates Gateway and HTTPRoute resources into xDS resources and applies it in Envoy.

What’s Different

In A, the Operator provisions the Data Plane. In B, the Control Plane provisions the Data Plane
In A, the Operator watches for GatewayClass and Gateway resources and passes the Gateway resources to watch to the Control Plane via configuration. In B, the Control Plane watches the Gateway resources.
The A based model splits up Operator and the Control Plane into which output resources they manage, Operator manages provisioning Kubernetes resources and the Control Plane manages xDS resources. The B based model splits up Operator and the Control Plane into component hierarchy, the Operator manages the Control Plane and the Control Plane manages the Data Plane.

Pros for A

The design has a functional split between the Operator and the control plane, which makes their scope smaller.

The Operator listens for Kubernetes resources and creates Kubernetes objects in response.
The control plane listens for Kubernetes resources and translates it into xDS config for Envoy to pull.

Mandating the Operator allows us to ease the management burden on the end user; they install the Operator, then just create the other Gateway API resources, and the Operator does the rest. It also ensures a consistent Envoy Gateway experience for users.
Having an Operator also allows us to encode upgrades and other management operations into it, allowing the subject matter experts (ie, us) to solve that problem for our users.

Cons for A

It does require more access to the cluster; the Operator is a cluster-level service and needs quite a high level of cluster access. [youngnick] I don’t feel that the extra security requirements for the operator are that big a change, since the control plane by itself must have read access to Gateways, HTTPRoutes, Services, Endpoints, and Secrets from the entire cluster anyway for it to be able to function properly. The Operator adds write access to  Namespaces, and then inside the namespaces it creates, write access to Deployments, Services, Daemonsets, and Secrets. (We can actually ensure this by carefully setting the cluster-level permissions that we grant the Operator, and having it create Roles inside the Namespaces it creates rather than just using ClusterRoles).

Pros for B

B makes the Operator optional.

Projects such as Istio have deprecated their Operator due to security reasons.
Some users tend to directly use Helm and skip using the Operator to provision the Control Plane.
Not running the operator is one less deployment to manage.

I am +1 for Option A.

+1 for Option B

Could I please ask all maintainers to cast binding votes on this issue before next Monday, 9am PST? That's @youngnick, @arkodg, @danehans, @skriss, @alexgervais, @LukeShu. At that time, we'll count up the existing votes and call this issue resolved.
We can also discuss at tomorrow's meeting if people have more questions.
Non-binding votes from other community members are definitely welcomed.

I am leaning towards Option B but I'm waiting to cast my vote until one issue is resolved.
My reasoning for leaning towards Option B:

Provides choice- Users can choose to use the operator or not. Some users may use in-house tooling to manage EG or simply kubectl apply -f quickstart.yaml. Although the operator will be used commonly for production environments, I expect most developers to not use it.
Aligns well with simplicity and "batteries included" project goals. A single process/container is required to run the control plane and it provisions the data plane. This is important when we're comparing Envoy Gateway/Envoy UX with Nginx.
Simplified troubleshooting- All the Gateway API controllers reside in the control plane, I have one place to tail logs, etc. to perform troubleshooting.
Provides a clear mental model- The operator is the management plane that manages the control plane. The control plane controls the data plane.
More secure- Supports users with very restrictive security requirements. Although the operator can be tuned to be more secure, providing namespace write access is a highly privileged operation.

My issue stems from the What's Common section:

The Operator watches for GatewayClass resources...

With Option B, all Gateway API controllers should reside in the control plane. The operator reconciles a CRD, e.g. EnvoyGateway, and creates the control plane (GatewayClass, Gateway, Deployment, etc). This is the well-established operator/operand design pattern. When the control plane starts, the Gateway API controllers begin reconciling the GatewayClass/Gateway resources that were created by the operator. Since the GatewayClass controllerName matches the control plane's configured controllerName, it updates the status of the GatewayClass indicating it manages the object. It then reconciles the Gateway and creates the data plane infrastructure, e.g. Envoy Service, Envoy Deployment, RBAC, etc. When a user creates another Gateway of the same GatewayClass, the control plane will merge the config and push it to the data plane. If another control plane is desired, the user repeats the same process.
In summary, the operator reconciles a CRD to manage the control plane and the control plane reconciles Gateway API objects to manage the data plane.

I honestly don't have a strong opinion between the two.

In summary, the operator reconciles a CRD to manage the control plane and the control plane reconciles Gateway API objects to manage the data plane.
SGTM

+1 on option B, with the caveat highlighted by @danehans.

+1 for Option A, I prefer the functional split. Also, given that we're most likely going to end up with an envoy-gateway-system namespace where all the CP/DP are deployed (since they correspond to a GatewayClass which is a cluster-scoped resource), the RBAC concerns are minimized.

+1 for Option A, I prefer the functional split. Also, given that we're most likely going to end up with an envoy-gateway-system namespace where all the CP/DP are deployed (since they correspond to a GatewayClass which is a cluster-scoped resource), the RBAC concerns are minimized.

+1 for Option B, also note that A isn't really a clean functional split as the Envoy provisioning involves bootstrap configuration which is basically an xDS handling. There will be requests to customize that part as well, as we've seen that in the past in Istio.

Out of our six binding votes, that puts us at:

Option A : 2, @youngnick and @skriss
Option B : 2, @alexgervais and @arkodg
Abstain : @LukeShu
Undecided : @danehans

Looks like the decision is up to you, @danehans.


Bug Report

Describe the bug
Documentation issue. The AzOps Accelerator URL under Create the Repository in https://github.com/azure/azops/wiki/github-actions is pointing to wrong repo (Azure/AzOps vs the template AzOps-Accelerator : https://github.com/Azure/AzOps-Accelerator)
Steps to reproduce

Screenshots

Thanks for reporting this @cbezenco, we will get this fixed.


add a test proving that the new execution model can batch composition br...

@williamboxhall I took some time to realize that the difference between the test application and the unit test is actually the different latencies that each composition branch can have.
See https://github.com/fwbrasil/clump/commit/6f7f7dd9f887b0ba393f0dae173b619fc9a3382e, it proves that the test fails using the old execution model.
Fixes #36.

I also added an optimization: https://github.com/fwbrasil/clump/commit/24ff91e537f7eca27a00ad391f53f77ac3396970

It is easier if you review the commits separately.


LibXSLT module failing against latest LibXML master

Need to provide backwards compatibility in LibXML, and/or forward compatibility from LibXSLT prior to CPAN release.

Latest LibXSLT master now passing


Add breadcrumbs menus to app

Closing, as better navigation implemented in #253 which alleviates the need for this for now.


CanSeeLos Using Spell

Hello, when the target is not momentarily in the field of view, the application of magic is successful and the magic word does not write and when we practice the spell over and over again, the last spell is successful.
https://www.youtube.com/watch?v=xK71wABrldU

Seem to work correct. You dont have the los back to the house but you have it when you see it.    Casting fast like you do make you fizzle the last spell..  i habe difficulty to see where the anomali.

no, it doesn't break the last spell.

I haven't seen any issue, maybe I couldn't catch it because everything is too fast in video, i think you are talking about sometimes spells doesn't fizzled and casted but there is many scripting issues;
Firstly, @SpellSelect trigger is triggering when you select the spell, ARGO is equals the item that used for spell or player's himself. If you want to check before spell cast, you have to use @SpellCast trigger.
Secondly, @SpellEffect already called after target is affected by spell, so that means he is already affected so canseelos is totally useless, So if you want to check canseelos you can use @SpellSuccess trigger which is better solution, but sphere directly cancel the spell if target is out of view, so I don't see the reason that you want to cancel it when it succeeded.
So i think the issue could be script side, but I willing to hear more about issue in future.

No script changes related to spells.  The problem is that when the target player quickly enters and exits the field of view while constantly pressing the spell macro, in some cases the spell is successful even if the target is not in the field of view

No script changes related to spells.  The problem is that when the target player quickly enters and exits the field of view while constantly pressing the spell macro, in some cases the spell is successful even if the target is not in the field of view

I try to figure what you mean.
What happen is you have the los when you begin the spell.  When spell was ready to send, you have los too.
After that the player go hide behind house but spell is correctly casted. Where the peoblem?

I try to figure what you mean.
What happen is you have the los when you begin the spell.  When spell was ready to send, you have los too.
After that the player go hide behind house but spell is correctly casted. Where the peoblem?

I try to figure what you mean. What happen is you have the los when you begin the spell. When spell was ready to send, you have los too. After that the player go hide behind house but spell is correctly casted. Where the peoblem?

I think the same. This issue could be closed.


AC® Chronicles [PCSB00792]

Game summary

Game name: AC® Chronicles
Game serial: PCSB00792

Vita3K summary

Version: 0.1
Build number: 703
Commit hash: https://github.com/vita3k/vita3k/commit/dda3686

Test environment summary

Tested by: Holy Diver
OS: Windows 10
CPU: Intel
GPU: AMD
RAM: 4 GB

Issues
Loads game and then after some NID's.
Screenshots
Log
vita3k.log

Needs Nothing, NIDs Missing tags.

Needs Nothing, NIDs Missing tags.

App summary

App name: AC® Chronicles

App serial: PCSB00792

App version: 1.01

crash on unicorn with error:

sceKernelAllocMemBlock returned SCE_KERNEL_ERROR_INVALID_ARGUMENT (0x80020005)

Log
vita3k.log

App summary

App name: AC® Chronicles

App serial: PCSB00792

App version: 1.01

crash on unicorn with error:

sceKernelAllocMemBlock returned SCE_KERNEL_ERROR_INVALID_ARGUMENT (0x80020005)

Log
vita3k.log

Issue:

graphic bug, some vertex exploss in model 3D when moving
color issue on video log

Screenshots:

Log
PCSB00792 - [AC® Chronicles].log

It would be great to be able to play this game on Android, actually the game is not available anywhere else. I'm looking forward to playing this game one day, I really like it.


score

Filter lines and ignore large residuals in other scores before computing them

Issue solved by separating metrics that permit a relative weight or not. Already merged into release but locally.


IMPORTANT: Please first search existing bugs to ensure you are not creating a duplicate bug report!
Describe the bug
!!! bug description here !!!
I've had a couple examples where either manhunter or predator animals have 'killed' a pawn, or another animal, such as the horse blood cloud save you'll find attatched.
It looks to me like the animal is failing to register as dead, and producing an unimaginably large blood cloud.
In this case, saving and loading seems to resolve the issue on a case by case basis; but I have a log from immediately before the save in case that helps for determining what's happening.
Steps to reproduce the behavior (VERY IMPORTANT)
Try spawning a manhunter pack event of Predators, that should re-create the conditions i've observed this occuring under.
Error Log
!!! Link to contents of Player.log or Error.log (MUST BE LINK) !!!
!!! Link to HugsLib log. (MUST BE LINK) !!!
Horse_blood_cloud_log.txt
Save file
!!! Please add a save file where the issue occurs to speed up testing and fixing of the issue !!!
Saves.zip
Screenshots
!!! Add screenshots to help explain your problem here !!!
previously mentioned horse, after loading save.

Mod list (Preferably a RimPy compatible list.)
(Feel free to trim/ignore any local mods, but I'll track the download sources down for you if you want them.)
[Mod list length: 106]
Harmony [https://steamcommunity.com/sharedfiles/filedetails/?id=2009463077]
Visual Exceptions [https://steamcommunity.com/sharedfiles/filedetails/?id=2538411704]
Core [https:// no link (local mod)]
Royalty [Official DLC] [https:// no link (local mod)]
Startup impact [https://steamcommunity.com/sharedfiles/filedetails/?id=1684944322]
HugsLib [https://steamcommunity.com/sharedfiles/filedetails/?id=818773962]
Graphics Settings+ [https://steamcommunity.com/sharedfiles/filedetails/?id=1678847247]
AI Upscaled Textures - Core [https://steamcommunity.com/sharedfiles/filedetails/?id=2307494117]
Vanilla Expanded Framework [https://steamcommunity.com/sharedfiles/filedetails/?id=2023507013]
Vanilla Factions Expanded - Mechanoids [https://steamcommunity.com/sharedfiles/filedetails/?id=2329011599]
Combat Extended [https://steamcommunity.com/sharedfiles/filedetails/?id=1631756268]
LWM's Deep Storage [https://steamcommunity.com/sharedfiles/filedetails/?id=1617282896]
AI Upscaled Textures - Mods [https://steamcommunity.com/sharedfiles/filedetails/?id=2323211835]
Adjacent Light [https://steamcommunity.com/sharedfiles/filedetails/?id=2517853803]
Advanced Moisture Pump [https://steamcommunity.com/sharedfiles/filedetails/?id=2274680538]
Allow Tool [https://steamcommunity.com/sharedfiles/filedetails/?id=761421485]
Almost There! [https://steamcommunity.com/sharedfiles/filedetails/?id=2372543327]
Animals Logic [https://steamcommunity.com/sharedfiles/filedetails/?id=1098354593]
Apparel Patch for Aya races [https://steamcommunity.com/sharedfiles/filedetails/?id=2398947154]
Apparel Tainted Only When Corpse Rots [https://steamcommunity.com/sharedfiles/filedetails/?id=2413156320]
Avoid Friendly Fire [https://steamcommunity.com/sharedfiles/filedetails/?id=1134165362]
Bed Rest For Food Poisoning [https:// no link (local mod)]
Better Linkable Colors [https://steamcommunity.com/sharedfiles/filedetails/?id=2519621745]
Better Workbench Management [https://steamcommunity.com/sharedfiles/filedetails/?id=935982361]
BetterNutrientPasteDispenserControls [https://steamcommunity.com/sharedfiles/filedetails/?id=2324531554]
Blueprints [https://steamcommunity.com/sharedfiles/filedetails/?id=708455313]
Camera+ [https://steamcommunity.com/sharedfiles/filedetails/?id=867467808]
Categorized Crafting Bills [https://steamcommunity.com/sharedfiles/filedetails/?id=2403595130]
Character Editor [https://steamcommunity.com/sharedfiles/filedetails/?id=1874644848]
Clothing Sorter [https://steamcommunity.com/sharedfiles/filedetails/?id=2275655161]
Combat Extended Guns [https://steamcommunity.com/sharedfiles/filedetails/?id=1582570547]
Drop All Inventory [https://steamcommunity.com/sharedfiles/filedetails/?id=2336610918]
Erin's Hairstyles - Redux [https://steamcommunity.com/sharedfiles/filedetails/?id=2361911135]
EvolvedOrgansRedux [https://steamcommunity.com/sharedfiles/filedetails/?id=2424381146]
Expanded Prosthetics and Organ Engineering [https://steamcommunity.com/sharedfiles/filedetails/?id=725956940]
Fluffy Breakdowns [https://steamcommunity.com/sharedfiles/filedetails/?id=726244033]
Heat Map (Continued) [https://steamcommunity.com/sharedfiles/filedetails/?id=2552838384]
Injured Carry [https://steamcommunity.com/sharedfiles/filedetails/?id=2413690575]
Interaction Bubbles [1.3] [https://steamcommunity.com/sharedfiles/filedetails/?id=2553619439]
InventoryTab (Continued) [https://steamcommunity.com/sharedfiles/filedetails/?id=2326678767]
Mad Skills [https://steamcommunity.com/sharedfiles/filedetails/?id=731111514]
Medical Tab [https://steamcommunity.com/sharedfiles/filedetails/?id=715565817]
MendAndRecycle [https://steamcommunity.com/sharedfiles/filedetails/?id=735241897]
Metal Don't Burn (UNOFFICIAL 1.3 PATCH) [https://steamcommunity.com/sharedfiles/filedetails/?id=2557145474]
More Planning 1.3 [https://steamcommunity.com/sharedfiles/filedetails/?id=2551225702]
Mx three hairs  [https://steamcommunity.com/sharedfiles/filedetails/?id=2554075734]
Humanoid Alien Races [https://steamcommunity.com/sharedfiles/filedetails/?id=839005762]
[1.3]Nearmare Race [https://steamcommunity.com/sharedfiles/filedetails/?id=2198830432]
Nearmare [ENG Translation] [https://steamcommunity.com/sharedfiles/filedetails/?id=2213525330]
Need Bar Overflow [https://steamcommunity.com/sharedfiles/filedetails/?id=2566316158]
No Lazy Doctors [https://steamcommunity.com/sharedfiles/filedetails/?id=2476396157]
No One Left Behind [https://steamcommunity.com/sharedfiles/filedetails/?id=2401146569]
Optimization: Meats - C# Edition [https://steamcommunity.com/sharedfiles/filedetails/?id=2542931556]
Packs Are Not Belts [https://steamcommunity.com/sharedfiles/filedetails/?id=2509511179]
Perspective Trees [https:// no link (local mod)]
ProxyHeat [https://steamcommunity.com/sharedfiles/filedetails/?id=2365526329]
Quality Colors [https://steamcommunity.com/sharedfiles/filedetails/?id=2420141361]
Quest Reward Rebalance [https://steamcommunity.com/sharedfiles/filedetails/?id=2312419897]
RPG Style Inventory Revamped [https://steamcommunity.com/sharedfiles/filedetails/?id=2478833213]
RT Fuse [https://steamcommunity.com/sharedfiles/filedetails/?id=728314182]
Rah's Bionics and Surgery Expansion [https://steamcommunity.com/sharedfiles/filedetails/?id=850429707]
Realistic Rooms [1.3] [https://steamcommunity.com/sharedfiles/filedetails/?id=2553724273]
Replace Stuff [https://steamcommunity.com/sharedfiles/filedetails/?id=1372003680]
ResearchPal - Forked [https://steamcommunity.com/sharedfiles/filedetails/?id=2351393394]
Roads of the Rim (Continued) [https://steamcommunity.com/sharedfiles/filedetails/?id=2280318231]
Ruined by temperature filter [https://steamcommunity.com/sharedfiles/filedetails/?id=2554476852]
Save Our Ship 2 [https://steamcommunity.com/sharedfiles/filedetails/?id=1909914131]
Simple Utilities: Ceiling [https:// no link (local mod)]
Smarter Construction [https://steamcommunity.com/sharedfiles/filedetails/?id=2202185773]
Smarter Deconstruction and Mining [https://steamcommunity.com/sharedfiles/filedetails/?id=2398365712]
Stackable Chunks [1.3+] [https://steamcommunity.com/sharedfiles/filedetails/?id=2373632580]
Stockpile Stack Limit (Continued) [https://steamcommunity.com/sharedfiles/filedetails/?id=2274678322]
Tech Advancing [https://steamcommunity.com/sharedfiles/filedetails/?id=735268789]
VFE-M: Add-On [https://steamcommunity.com/sharedfiles/filedetails/?id=2329025520]
VFE - Mechanoids : Tab [https://steamcommunity.com/sharedfiles/filedetails/?id=2368220087]
Vanilla Furniture Expanded - Power [https://steamcommunity.com/sharedfiles/filedetails/?id=2062943477]
AI Upscaled Textures - Plants [https://steamcommunity.com/sharedfiles/filedetails/?id=2307592039]
Vanilla Textures Expanded [https://steamcommunity.com/sharedfiles/filedetails/?id=2016436324]
Vanilla Furniture Expanded [https://steamcommunity.com/sharedfiles/filedetails/?id=1718190143]
Vanilla Textures Expanded - Variations [https://steamcommunity.com/sharedfiles/filedetails/?id=2493234474]
Weapons Sorter [https://steamcommunity.com/sharedfiles/filedetails/?id=2290406586]
What the hack?! [https://steamcommunity.com/sharedfiles/filedetails/?id=1505914869]
What the hack - A little expansion [https://steamcommunity.com/sharedfiles/filedetails/?id=2456962656]
What's for sale? [https://steamcommunity.com/sharedfiles/filedetails/?id=2396808851]
Windows [https:// no link (local mod)]
World Map Beautification Project [https://steamcommunity.com/sharedfiles/filedetails/?id=2314407956]
[1.3]Neclose Race [https://steamcommunity.com/sharedfiles/filedetails/?id=2394460334]
[1.2,1.3]Neclose Race (English translation) [https://steamcommunity.com/sharedfiles/filedetails/?id=2396877772]
[1.3]Silkiera Race [https://steamcommunity.com/sharedfiles/filedetails/?id=2233666290]
[1.2,1.3]Silkiera Race(English) [https://steamcommunity.com/sharedfiles/filedetails/?id=2282193710]
[LTO] Terrain Overhaul [https://steamcommunity.com/sharedfiles/filedetails/?id=2284769535]
[NL] Facial Animation - WIP [https://steamcommunity.com/sharedfiles/filedetails/?id=1635901197]
RimJobWorld [https:// no link (local mod)]
RimNudeWorld [https:// no link (local mod)]
RimJobWorld - Licentia Labs [https:// no link (local mod)]
RJW_RBSE [https:// no link (local mod)]
OTY Bodies for Alien Races [https:// no link (local mod)]
OTY_NUDE Unofficial Update [https:// no link (local mod)]
Chaeren's Female Apparel [https:// no link (local mod)]
RJW - RaceSupport [https:// no link (local mod)]
Rimworld-Animations [https:// no link (local mod)]
Dubs Performance Analyzer [https://steamcommunity.com/sharedfiles/filedetails/?id=2038874626]
RJWAnimAddons-VoicePatch [https:// no link (local mod)]
RJWAnimAddons-XtraAnims [https:// no link (local mod)]
RJWAnimAddons-AnimalPatch [https:// no link (local mod)]
RimThreaded [https://steamcommunity.com/sharedfiles/filedetails/?id=2222907981]

I loaded your save game and modlist in RimPy. There seem to be errors. Can you reproduce this bug with something more vanilla? Or even with a modlist that checks out in RimPy as error free? Thanks. Closing until new save is attached. (or steps to reproduce on vanilla+RT)

I loaded your save game and modlist in RimPy. There seem to be errors. Can you reproduce this bug with something more vanilla? Or even with a modlist that checks out in RimPy as error free? Thanks. Closing until new save is attached. (or steps to reproduce on vanilla+RT)

Will try that in a few days, busy until friday.


How about to tag silex 2.0 without dev?

Symfony 3.0 released. What are waiting for?

:+1:

I think maintainer will wait until silex stable enough for 3.0. Some feature still waiting to be merged such as #1296

Is there any way we can do a feature freeze to figure out what needs to be in 2.0 and what can come after? I'd love to see Silex 2.0 released and am willing to help out on any issues or PR's on getting it there.

well, #1296 is closed now. I just went through most of the remaining issues querying statuses of the issues. A lot of the issues are old and seem like they can be closed, but we can wait until someone responds to those issues. Anyways, @fabpot or someone else who has authority in this matter, when exactly do you think we could see a silex 2.0 come out?
I have a project coming up soon, and I'd love to be able to use a stable 2.0 branch.

Just use 2.0, I'm using it for tons of projects on production since it came out and never ran into issues that can not easily be resolved.

@mediamonks-robert,
@fabpot does a good job with making sure 2.0-dev stays more or less stable; however, there are plenty of legitimate reasons why you (I) shouldn't be using a non-stable branch of this framework for the project I'll be heading. Using a dev branch just wouldn't feasible for me. Also, considering that there aren't many open tickets or PR's, we should be getting close to a stable 2.0, so it doesn't hurt to try and wrap up what's needed to make it official.

It can depend on the kind of project of course. I put my comment there to assure others Silex 2.0 is great for usage in production but feel free to choose the 1.3 stable branch if you feel better about it.

@mediamonks-robert, ya no worries. I'd definitely prefer 2.0 for sure, especially since Pimple 3 is so much nicer than 1.0. @fabpot seems like he's on a silex marathon right now, so we'll see how close we are when he's done.

Closing this now. The only remaining task is for me to figure out how to host both docs for 1.3 and 2.0 on the website. When it's done, I will release 2.0 stable. Thanks for your patience.

yes! oh my goodness thank you!

Website is updated now. If nobody finds anything to change in the docs or code in the next couple of days, I will tag 2.0.

@fabpot on http://silex.sensiolabs.org/doc/master/, the "API link" is broken http://silex.sensiolabs.org/api/index.html.
It doesn't seem to be built from this file https://github.com/silexphp/Silex/blob/master/doc%2Findex.rst either.

2.0 is out now (https://twitter.com/fabpot/status/732848312819318784). Thanks everyone for your patience and enjoy!


Set max request body size for file uploads.

This matches the 500 MB limit that we currently set for these via govuk-puppet. It fixes things like image uploads on content-publisher.
nginx's default is 1M, which should be plenty, so keep that for everything else.
In govuk-puppet this is set to 20M for all the other apps (i.e. apps that don't handle file uploads), but I intentionally haven't set that here because there should be no legit reason for those apps to receive such huge request bodies; it's just a (small but unnecessary) resource-exhaustion attack risk. I couldn't find any justification in the govuk-puppet commit history as to why it was set so large.
Similarly, I couldn't find any explanation as to why search-api had this set to 500 MB so I'm leaving that at the default 1M too.
Testing
Inspected helm template output for an app with/without an override of the new value:
helm template content-publisher ../generic-govuk-app --values <(
  helm template . --values values-integration.yaml |
    yq e '.|select(.metadata.name=="content-publisher").spec.source.helm.values'
)

helm template frontend ../generic-govuk-app --values <(
  helm template . --values values-integration.yaml |
    yq e '.|select(.metadata.name=="frontend").spec.source.helm.values'
)

I was thinking about the search-api thing. Whitehall still has some content types that are submitted directly to search, as opposed to the standard approach which is search-api finding out via a message on a queue and then retrieving what it needs.
I don't know what the largest thing that Whitehall still submits is, but wonder if the 50MB was a finger in the air from someone at some point to make this safe?

I was thinking about the search-api thing. Whitehall still has some content types that are submitted directly to search, as opposed to the standard approach which is search-api finding out via a message on a queue and then retrieving what it needs. I don't know what the largest thing that Whitehall still submits is, but wonder if the ~50MB~ 500MB was a finger in the air from someone at some point to make this safe?

Oh that's good to know, thanks! I'll loosen this a bit for search-api then so it won't fail if there's a large (> 1MB) content item.


(graphviz) Updated PR with needed updates

@AdmiringWorm @gep13 @pascalberger @majkinetor
/cc @smattr @magjac
Description

This will make the continuing package of graphviz be a cmake build as per discussion in #1535
Motivation and Context

This will fix issue #1528
How Has this Been Tested?

Screenshot (if appropriate, usually isn't needed):
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Migrated package (a package has been migrated from another repository)

Checklist:

[x] My code follows the code style of this repository.
[ ] My change requires a change to documentation (this usually means the notes in the description of a package).
[ ] I have updated the documentation accordingly (this usually means the notes in the description of a package).
[x] All files are up to date with the latest Contributing Guidelines
[ ] The added/modified package passed install/uninstall in the chocolatey test environment.
[ ] The changes only affect a single package (not including meta package).

Original Location

Original Repository
Open Issues Add the different issues underneath, and tick those that are fixed in this PR

[x] Issue 1 #1528
[ ] Issue 2 Link

[ ] Include the link to the opened PR that removes the package from the original location
[ ] The migration guidelines have been followed

:x: Package verification failed, please review the Appveyor Logs and the provided Artifacts before requesting a human reviewer to take a look.

:x: Package verification failed, please review the Appveyor Logs and the provided Artifacts before requesting a human reviewer to take a look.

:white_check_mark: Package verification completed without issues. PR is now pending human review

@AdmiringWorm @majkinetor
Everything should be in order now for this PR 🤞


[TW#17249] Simple Wi-Fi examples

Hi, I believe its worth to add simple wi-fi examples to getting-started.
By "simple" I mean:

STA:  connect to AP using provided SSID/pass and print ip addr
AP:  using provided SSID/pass create AP, wait till client connects, print ip addr
This should be like "hello world" in terms of wi-fi

It's not so comfortable to cut pieces of code from several examples - you'll always have background thought "I missed something"

Take a look on Arduino for ESP32, it's a simplification layer that runs over IDF: https://github.com/espressif/arduino-esp32/blob/master/libraries/WiFi/examples/WiFiClient/WiFiClient.ino
https://github.com/espressif/arduino-esp32/blob/master/docs/esp-idf_component.md

That's even worse. To use this Arduino example in pure ESP-IDF program I have to change much more things.


Unable to login, key expired and Keybase can't find it in GPG Keychain

Keybase GUI Version: 1.0.20-20170317000044+73c5db6
Hi,
I've recently downloaded the Keybase.io App and am trying to login. However, I'm a user that verified with my PGP key and therefore I am trying to login using the "keybase login" CLI command. When attempting to login, I've also realised that my PGP key has expired and I haven't generated a new one. As such, when I try to login, I get the following warning and error:

I understand why Keybase might not let me login with an expired key, however, the error saying that it cannot find the key is a mystery to me as the key is there in my GPG Keychain. It is not however, in the OS X  Keychain.
With this in mind, can I please ask:

Does Keybase.io let you login with an expired PGP key if you haven't generated a new one?
Does Keybase.io support looking for keys in any other keychain other than the built in OS X Keychain? (specifically asking about GPG Keychain)

Love your work!
Thank you :-)

my log id: 3e064b7bf31fa2901529531c

Can you paste the output of this command?
/usr/local/MacGPG2/bin/gpg2 --no-tty --with-colons --fingerprint -K 29A3A3C7

Sure, here it is:
$ /usr/local/MacGPG2/bin/gpg2 --no-tty --with-colons --fingerprint -K 29A3A3C7
sec::4096:1:EFF4107E29A3A3C7:1421015930:1452551930:::::sc::::
fpr:::::::::6F8B56EE24F4D49308C78373EFF4107E29A3A3C7:
uid:::::1421015930::93D06C476444BCAD8B0B098EBD2E6D10D845E3E3::Srdan Dukic (Serge<EMAIL_ADDRESS>ssb::4096:1:DF743A302AEB10E6:1421015930:1452551930:::::e::::

I think your GPG key expired a long time ago.  Try extending it via gpg --edit-key

Does Keybase.io let you login with an expired PGP key if you haven't generated a new one?
ok, so I guess that's a "no"? With a workaround that you can edit the key and change the expiry (I didn't realize you could do this)

Does Keybase.io support looking for keys in any other keychain other than the built in OS X Keychain?
So, it does look and find the keys in the GPG Keychain, but ignores them if expired (and then errors out, saying it can't find the key).

It would be nice if attempting the login with an expired key produced an error message such as:
"Sorry, unable to use primary key 9A8A... as it has expired. Please extend it using 'gpg --edit-key' or reset account..."
Thank you again

Ok, so with having modified the expiry date, I get further in the login process, but am still getting errors when trying to log in (same error, regardless whether option 1 or 2 is chosen):
srdan@Srdans-MacBook-Pro:~/code/clair$ keybase login
Your keybase username or email address<EMAIL_ADDRESS>In order to authorize this installation, keybase needs to sign this installation
with your GPG secret key EFF4107E29A3A3C7.

You have two options.

(1) Keybase can use GPG commands to sign the installation.

(2) Keybase can export your secret key from GPG and save it to keybase's local encrypted
    keyring. This way, it can be used in 'keybase pgp sign' and 'keybase pgp decrypt'
    going forward.
Which do you prefer?: 1
Enter a public name for this device: macbook

You need a passphrase to unlock the secret key for
user: "Srdan Dukic (Serge<EMAIL_ADDRESS>4096-bit RSA key, ID 29A3A3C7, created 2015-01-11

▶ ERROR Could not open key: no valid primary key self-signature or key(s) have expired (error 905)

Can you use the Web interface to update your public key with the newly
updated public key?  Use the GPG+Curl mode
On Tue, Apr 11, 2017 at 11:19 PM, Srdan Dukic<EMAIL_ADDRESS>wrote:

Ok, so with having modified the expiry date, I get further in the login
process, but am still getting errors when trying to log in (same error,
regardless whether option 1 or 2 is chosen):
srdan@Srdans-MacBook-Pro:~/code/clair$ keybase login
Your keybase username or email address<EMAIL_ADDRESS>In order to authorize this installation, keybase needs to sign this installation
with your GPG secret key EFF4107E29A3A3C7.
You have two options.
(1) Keybase can use GPG commands to sign the installation.
(2) Keybase can export your secret key from GPG and save it to keybase's local encrypted
keyring. This way, it can be used in 'keybase pgp sign' and 'keybase pgp decrypt'
going forward.
Which do you prefer?: 1
Enter a public name for this device: macbook
You need a passphrase to unlock the secret key for
user: "Srdan Dukic (Serge<EMAIL_ADDRESS>4096-bit RSA key, ID 29A3A3C7, created 2015-01-11
▶ ERROR Could not open key: no valid primary key self-signature or key(s) have expired (error 905)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/keybase/client/issues/6564#issuecomment-293461308,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA05_xLI3CWpuMaGQDPOxac-8D9A2g-Hks5rvEK-gaJpZM4M5Wu8
.

Success! That worked, thank you very much! :-)


Offer a "Reset View Locations" on a container?

I am happy to find this action:

I wonder if there should be a similar action on the right click menu of an actual view container to reset all views that are inside back to the original?

due to #96119, we now have a reset command from the container's perspective already, therefore after consideration, I am opting to not add this command to avoid cluttering the context menus

If you feel strongly otherwise, let me know


[AIRFLOW-1763] Fix S3TaskHandler unit tests

Dear Airflow maintainers,
Please accept this PR. I understand that it will not be reviewed until I have checked off all the steps below!
JIRA

[x] My PR addresses the following Airflow JIRA issues and references them in the PR title. For example, "[AIRFLOW-XXX] My Airflow PR"

https://issues.apache.org/jira/browse/AIRFLOW-1763

Description

[x] Here are some details about my PR, including screenshots of any UI changes:
Fixes & runs breaking tests for s3 task handler

Tests

[x] My PR adds the following unit tests OR does not need testing for this extremely good reason:
s3taskhandler tests in test_logging.py

Commits

[x] My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

Codecov Report

Merging #2732 into master will increase coverage by 0.4%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master    #2732     +/-   ##
=========================================
+ Coverage   72.48%   72.88%   +0.4%
=========================================
  Files         154      154
  Lines       11843    11843
=========================================
+ Hits         8584     8632     +48
+ Misses       3259     3211     -48

Impacted Files
Coverage Δ

airflow/models.py
87.09% <0%> (-0.05%)
:arrow_down:

airflow/utils/log/s3_task_handler.py
72.05% <0%> (+72.05%)
:arrow_up:

Continue to review full report at Codecov.

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

Can you rename the file to mirror the file it is testing?

@bolkedebruin File renamed and updated branch!


Lra 861 room ready admin interface add common attributes to all rooms

#index page w/ table for common_attributes w/ option to edit & delete
validations for common_attributes

description cannot be empty
needs to select at least one of need_checkbox or need_quantity_box

authorization policy for common_attributes

@Mohammad4844 Looks great! Could you please add a link to the '/common_attributes' to the header (shared/_navbar)? Something like this (I guess you know what to add):
<% if user_signed_in? && policy(CommonAttribute).index? %>
      <%= link_to "Common Attributes", common_attributes_path %>
<% end %>

Don't worry about styles in the header for now.

added


Index out of range while deploying vdc on testnet

cancelling by uuid instead of cancelling single workload.
Traceback/Logs/Alerts
Traceback (most recent call last):
  File "/root/js-sdk/jumpscale/packages/vdc/chats/new_vdc.py", line 129, in deploy
    self.config = self.deployer.deploy_vdc(minio_ak=None, minio_sk=None)
  File "/root/js-sdk/jumpscale/sals/vdc/deployer.py", line 538, in deploy_vdc
    master_ip = self.vdc_instance.kubernetes[0].public_ip
IndexError: list index out of range

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/root/js-sdk/jumpscale/sals/chatflows/chatflows.py", line 147, in wrapper
    getattr(self, step_name)()
  File "/root/js-sdk/jumpscale/sals/chatflows/chatflows.py", line 668, in wrapper
    return func(*args, **kwargs)
  File "/root/js-sdk/jumpscale/packages/vdc/chats/new_vdc.py", line 138, in deploy
    self.stop(str(err))
  File "/root/js-sdk/jumpscale/sals/chatflows/chatflows.py", line 657, in stop
    raise StopChatFlow(msg=msg, **kwargs)
jumpscale.sals.chatflows.chatflows.StopChatFlow: (StopChatFlow(...), 'list index out of range')

fixed here https://github.com/threefoldtech/js-sdk/commit/548f7507f9e7e6b7311cb4b20b3ae289ba126cb6

fixed here https://github.com/threefoldtech/js-sdk/commit/548f7507f9e7e6b7311cb4b20b3ae289ba126cb6

successful deployment of vds using https://vdc.testnet.grid.tf/

successful deployment of vds using https://vdc.testnet.grid.tf/


HAWQ-1411. Fix inconsistent json file for catalog of hawq 2.1

The 2.1 json file is created based on hawq <IP_ADDRESS>-incubating code base and instruction at https://cwiki.apache.org/confluence/display/HAWQ/Build+and+Install.
cd src/include/catalog/
perl tidycat.pl -dd 2.1.json -df json *.h
mv 2.1.json ../../../tools/bin/gppylib/data/2.1.json

+1

LGTM +1


Typo

Page 26:  "who's" (are we want to measure) should be "whose".

Page 28: "it's value" -> "its value"

Page 30: "to visualized" -> "to visualize"

Fixed -- thank you Cedric!!


Unable to render BackgroundGradient

Hi,
I started a new shared project from scratch, referenced this awesome project by nuget, and i try to do this:
<?xml version="1.0" encoding="UTF-8"?> <ContentPage xmlns="http://xamarin.com/schemas/2014/forms" 			 xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml" 			 xmlns:yummy="clr-namespace:Xamarin.Forms.PancakeView;assembly=Xamarin.Forms.PancakeView" 			 x:Class="App4.MainPage"> 	<ContentPage.Content> 		<StackLayout BackgroundColor="White"> 			<yummy:PancakeView BackgroundGradientEndColor="Red" 							   BackgroundGradientStartColor="Gainsboro"> 				<Label FontSize="20" 					   Text="PancakeView" 					   VerticalOptions="Center" /> 			</yummy:PancakeView> 		</StackLayout> 	</ContentPage.Content> </ContentPage>
But I can't see any background on android. What is my mistake?

I don't have any problems with 1.6.x.

This is because those properties have been deprecated in v2.0 - use BackgroundGradientStops instead.

They will be completely removed in v2.1.


Wiki still contains ManagedDomain instead of MDomain

E.g. https://github.com/icing/mod_md/wiki
ManagedDomain your_domain.de

Thanks. Fixed the locations I found.

Ok, thanks.
Btw. you got probably confused by my "simplify" migration advice (now removed) that only worked for Apache trunk (never in 2.4.x), but was rejected by the project and will not happen. VirtualHosts for several ports with mixed http: and https: will not work.
If you follow the example with the 2 VirtualHosts on that page, you should find a working setup. Otherwise I advise the users apache httpd mailing list.


How to change the zoom level

Description
When loading 1000 candlesticks, the default zoom level displays too few candlesticks, requiring mouse scrolling to show more. How can I change this? Also, when loading candlesticks in real-time, a fullReset call is necessary to refresh. I would like to default to displaying more candlesticks when refreshing. Do you have any suggestions?
Suggested solution

Alternative
No response
Additional context
No response
Validations

[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

You can use 'DEFAULT_LEN' property to control how many candlesticks you want to show - https://nightvision.dev/guide/api/chart-config.html#config-default-len
To update data in real-time you don't need to update full chart, just data: this.chart.update('data');
Hope it helps

You can use 'DEFAULT_LEN' property to control how many candlesticks you want to show - https://nightvision.dev/guide/api/chart-config.html#config-default-len
To update data in real-time you don't need to update full chart, just data: this.chart.update('data');
Hope it helps

Thank you for your response, DEFAULT_LEN is working and it has resolved the issue. I really appreciate your help. Regarding your suggestion of using this.chart.update('data'), I tested it and found that the data is indeed updated, but the x-axis remains unchanged. So, currently, I am using this.chart.fullReset() which allows me to update the x-axis.


sbt blocks several ScalaTest features by withholding event reports

Hi,
At some point sbt started holding onto events until a test class completes, then emitting them all at once. This may have made the output of other test frameworks better, but it made ScalaTest output worse. ScalaTest already outputs its events in such a way that it balances the user seeing the output for each test class together with the desire of the user to see that progress is happening. It will show the output of one test class, then the next, then the next, like sbt does, but unlike sbt as far as I know, ScalaTest will eventually time out and switch to the next test class. That way if one test takes a long time, or hangs forever, eventually ScalaTest will move on and start outputting events from another test class. As I mentioned, this balances the user desire to see each test class reported together with the desire to see progress when one test is slow or hanging.
Whats' worse is that some of ScalaTest's events are designed to be emitted immediately. These are called "notes" and "alerts". These allow users to get status updates, or warnings of problems, as a long-running test proceeds. Some users have tests that run for three minutes, so these updates are desirable to them to make sure tests are proceeding.
Lastly, occasionally tests hang forever for users because of deadlocks or other issues. ScalaTest has a nice feature, called "slowpoke notifications," to help users figure out what test is hanging. With this enabled, an alert is fired if a test has been running more than a certain amount of time. The alert indicates the suite and test name, so you can find out which test or tests are hanging. It is a great feature, but doesn't work on sbt anymore, because sbt refuses to show the event until the suite has finished. If the suite is hanging, it won't finish, so you can't use it to find out what's hanging. On the JVM you can often do a thread dump, because ScalaTest puts the suite and test name in the thread name, but that doesn't work on Scala.js.
I know other test frameworks don't have these features, but it would be good to either have a way to shut it off, or to automatically shut it off for ScalaTest.
Thanks.
Bill

See http://www.scala-sbt.org/0.13/docs/Testing.html#Output
Could you try if logBuffered in Test := false works for you?

I will try that right now...

That works! I'll add it to our documentation asap, as I know users who know sbt very well who have been complaining about this pain point.
But I wonder, do you think there's someway to make that the default at least for ScalaTest? Given I didn't find this in the sbt documentation for maybe a year, it is possible users won't find it in ScalaTest documentation. Hmm. That might complicate sbt to have different defaults for different test frameworks, but as far as I know for the other test frameworks the existing default is probably appropriate.

That might complicate sbt to have different defaults for different test frameworks, but as far as I know for the other test frameworks the existing default is probably appropriate.

I wasn't there when that decision was made (c8fe1a3c1d32d98a3ecfd84547fffe8db9b83c25 ?), and I have no idea if this behavior benefits any testing frameworks or tasks. Potential reasons:

performance tradeoff of file I/O?
prevention of interleaving outputs from multiple tests running in parallel?

2011? I wonder in what version of sbt that came out.
ScalaTest already takes care of the interleaving of multiple tests running in parallel, as I mentioned above. But in a slightly better way I think, because it can eventually time out and moves on. I am not aware that any other test framework does that, so for the others, this probably makes sense as the default in sbt. But I don't know from direct experience.  Be interesting to see what happens in a specs2 or JUnit project when this is disabled and parallel execution is performed.

2011? I wonder in what version of sbt that came out.

The commit shows all the tags. The earliest is v0.9.5, but I think sbt sorted of jumped from 0.7 to 0.10 around the time if I remember correctly.
Like other testing related things in sbt, it innovated ahead of the time, and filled in the gap. Now that testing libraries are managing parallelism or logging or whatever, I'd be happy to change things around if you, @etorreborre, and @benmccann think it makes sense to do so.

I'm not sure it matters. I can just document to set logBuffered to false when using ScalaTest and see how that goes. The only thing that could potentially be done, perhaps, is to change sbt's default to the opposite. That seems like a fairly drastic break to existing builds. Nevertheless we'll investigate to see what it does to JUnit, specs2, and ScalaCheck tests and I'll post here.

I remember being told by Mark Harrah to set logBuffer to false a long time ago, as I started running things concurrently. This is in specs2 build and I mention it in the docs.
As far as I know the main downside is the interleaving of traces when running several classes in parallel. In my experience this is not really a problem because I usually want to see the full output when I'm running a single class and just failures/errors if I'm running a suite.

Hi Eric,
That's interesting. Sounds like maybe false would have been a better default for logBuffered. We have yet to try false with other test frameworks. We'll do that this week.
Bill

Yeah, I wouldn't know off the top of my head how it would impact the junit output and we'd have to test it out to see. Btw, if we're already going to be testing the junit output then it might be a good time to finally resolve https://github.com/sbt/junit-interface/issues/62, which I've been consistently too lazy to do

Hi Ben,
I think making -a the default is something that would be done in sbt/junit-interface, not sbt itself. I agree it makes sense as a better default.
Bill


Push long polling freeze UI

Hi,
The push annotation with long-pooling freezes the Vaadin UI and I can see an endless vaadin load indicator.
Environment

Vaadin 7.4.1
vaadin-lazyquerycontainer <IP_ADDRESS>
spring-boot-vaadin 0.0.4.RELEASE

I'm using also then LazyQueryContainer to load beans in Vaadin Tables, it seems that the first page is loading correctly and the entries are shown in the table but the vaadin load indicator is endless loading and flashing and the second page request is never be executed. It seems the whole Vaadin UI is freezing.
The Push request is on pending state and retrieving an response.
_http://localhost:8080/UI/PUSH/?v-uiId=0&v-csrfToken=619d9a83-6b13-4584-b033-7a382b35fa4f&X-Atmosphere-tracking-id=1fd257c0-6394-4d03-82e0-ace9dd3516e0&X-Atmosphere-Framework=2.2.6.vaadin3-jquery&X-Atmosphere-Transport=streaming&X-Atmosphere-TrackMessageSize=true&Content-Type=application%2Fjson%3B charset%3DUTF-8&X-atmo-protocol=true&_=1426583600034_
Do you have any Idea why the Vaadin UI is freezing and the Vaadin load indicator is endless loading/flashing?
Thanks,
Michael

I had same issues. Long polling hangs randomly page. I found workaround - reload page. Unfortunately, it's makes a user experience horrible fight with page reloads. After week of test we change push transport to Websocket. Current version 7.4.1 works without page hanging.
I think problem with long polling is located deeply in Vaadin. There is no reconnection after failed long poll reconnection request.

We've run into that issue in our projects as well and we don't yet know what is causing it. Are you using Spring Security?

yes I'm also using spring-security

We have a suspicion that Spring Security's session handling could somehow be interfering with Vaadin (#203).

um good indicator, it also happens that is randomly based where we start the application, on some computer it works totally fine, really interesting, maybe I'll do some investigating into the spring-security configuration thanks for the hint.

@michahirsch Thanks, that would be much appreciated!

Hi,
I guess it's not an spring-security problem, at least the problem I'm having. I modified the push-example a little bit by using long-polling and removing the thread which adds single entries to the Grid. Very easy example which lead into the endless vaadin loading indicator and the Grid is only filled until line 39. The weird thing is that in case the AMOUNT_NUMBERS  is just e.g. 10 then I don't run into the endless loading indicator problem.
I will try to keep looking what's going on but maybe someone has a glue or an idea? The example is very easy and without spring-security.
Additional: Using Transport.WEBSOCKET the example works fine.
/*
 * Copyright 2015 The original authors Licensed under the Apache License, Version 2.0 (the
 * "License"); you may not use this file except in compliance with the License. You may obtain a
 * copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable
 * law or agreed to in writing, software distributed under the License is distributed on an "AS IS"
 * BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License
 * for the specific language governing permissions and limitations under the License.
 */
package org.vaadin.spring.samples.push;

import java.util.ArrayList;
import java.util.List;
import java.util.Random;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import com.vaadin.annotations.Push;
import com.vaadin.annotations.Theme;
import com.vaadin.annotations.Title;
import com.vaadin.data.Item;
import com.vaadin.data.util.IndexedContainer;
import com.vaadin.server.VaadinRequest;
import com.vaadin.shared.ui.ui.Transport;
import com.vaadin.spring.annotation.SpringUI;
import com.vaadin.ui.Grid;
import com.vaadin.ui.UI;
import com.vaadin.ui.themes.ValoTheme;

@Push( transport = Transport.LONG_POLLING )
@Title( "Push Demo" )
@SpringUI( )
@Theme( ValoTheme.THEME_NAME )
public class PushUI extends UI {

   private static final long   serialVersionUID =<PHONE_NUMBER>011782944L;
   private static final Logger LOGGER           = LoggerFactory.getLogger( PushUI.class );

   private static final int    AMOUNT_NUMBERS   = 100;
   private static Random       rnd              = new Random();

   private Grid                grid;
   private IndexedContainer    measurements;

   @Override
   protected void init( final VaadinRequest vaadinRequest ) {
      measurements = new IndexedContainer();
      measurements.addContainerProperty( "Count", Integer.class, null );
      measurements.addContainerProperty( "Data", Integer.class, null );

      final List<Integer> numbers = getNumbers( AMOUNT_NUMBERS );

      for( int index = 0; index < numbers.size(); index++ ) {
         final Item item = measurements.getItem( measurements.addItem() );
         item.getItemProperty( "Count" ).setValue( index );
         item.getItemProperty( "Data" ).setValue( numbers.get( index ) );
      }

      grid = new Grid( measurements );
      grid.setSizeFull();
      setContent( grid );
      LOGGER.info( "init done" );
   }

   private List<Integer> getNumbers( final int amount ) {
      final List<Integer> retList = new ArrayList<>( amount );
      for( int index = 0; index < amount; index++ ) {
         retList.add( rnd.nextInt() );
      }
      return retList;
   }
}

Could you try the sample with Vaadin 7.4.2? I heard it has some push fixes.

I already tried the 7.4.2 because I also saw the issue was fixed there http://dev.vaadin.com/ticket/17074 but it still freezing also with the 7.4.2

@michahirsch OK, then we're dealing with another problem. Thanks for investigating.

I am also not using Spring Security, using long-polling, but still on 7.3.9. I get the freeze very randomly.

I finally switched to 7.4.2, specifying @Push as is, accepting framework defaults (websockets). Cursory testing shows the application is working well.

@michahirsch It seems like your application is never able to establish a long-polling connection to the server. If there is a proxy somewhere in between (does Spring have some kind of built-in proxy?), you are likely hitting https://dev.vaadin.com/ticket/17075.

Is this problem still present?

I have not run into this problem with the newer Vaadin versions, so I'm closing this ticket.


CHEBI:58313 and CHEBI:17892 are acid/base but with different stereo

Hi
CHEBI:58313 and CHEBI:17892 are acid/base according to the ChEBI ontology but they have incompatible stereochemistry.
What is the right stereo for L-rhamnulose 1-phosphate?

This has now been corrected. The correct stereochemistry for L-rhamnulose is that shown in CHEBI:17897. Thanks

This has now been corrected. The correct stereochemistry for L-rhamnulose is that shown in CHEBI:17897. Thanks


If the folder of the last selected local file is deleted, it will generate an error when you try to manage the files of episodes

Well is just this

Very correct! I will fix this.


Adds environment support to Exec task

The title describes everything...

:+1: Looks good to me. @DavertMik

:+1:

@stevewest it is merged.

Thanks very much everyone!


support refreshing realtime segments

@kmozaid This is being done as part of opening up upload endpoint for realtime segments - in this PR: https://github.com/apache/pinot/pull/8584

@kmozaid This is being done as part of opening up upload endpoint for realtime segments - in this PR: #8584

ohk, then I can close this PR, right? Also I don't see the below change in RealtimeTableDataManager , How Server is going to handle REFRESH_SEGMENT message sent by controller when segment is uploaded? Did you verify that segment uploaded are queryable in your code?
  @Override
  public void addSegment(File indexDir, IndexLoadingConfig indexLoadingConfig)
      throws Exception {
    Schema schema = ZKMetadataProvider.getTableSchema(_propertyStore, _tableNameWithType);
    addSegment(ImmutableSegmentLoader.load(indexDir, indexLoadingConfig, schema));
  }

JFYI, message which controller send to server -
ZnRecord=87e551ff-cc98-4fdf-b861-6be3b8d561bd, {CREATE_TIMESTAMP=1650873841979, EXECUTE_START_TIMESTAMP=1650873854007, MSG_ID=87e551ff-cc98-4fdf-b861-6be3b8d561bd, MSG_STATE=new, MSG_SUBTYPE=REFRESH_SEGMENT, MSG_TYPE=USER_DEFINE_MSG, PARTITION_NAME=transcript__0__2__20220425T0634Z, RESOURCE_NAME=transcript_REALTIME, RETRY_COUNT=0, SRC_CLUSTER=PinotCluster, SRC_INSTANCE_TYPE=PARTICIPANT, SRC_NAME=Controller_localhost_9001, TGT_NAME=Server_localhost_8001, TGT_SESSION_ID=1000232d2430120, TIMEOUT=-1, segmentName=transcript__0__2__20220425T0634Z, tableName=transcript_REALTIME}{}{}, Stat=Stat {_version=0, _creationTime=1650873842026, _modifiedTime=1650873842026, _ephemeralOwner=0}

@kmozaid This is being done as part of opening up upload endpoint for realtime segments - in this PR: #8584

ohk, then I can close this PR, right? Also I don't see the below change in RealtimeTableDataManager , How Server is going to handle REFRESH_SEGMENT message sent by controller when segment is uploaded? Did you verify that segment uploaded are queryable in your code?
  @Override
  public void addSegment(File indexDir, IndexLoadingConfig indexLoadingConfig)
      throws Exception {
    Schema schema = ZKMetadataProvider.getTableSchema(_propertyStore, _tableNameWithType);
    addSegment(ImmutableSegmentLoader.load(indexDir, indexLoadingConfig, schema));
  }

JFYI, message which controller send to server -
ZnRecord=87e551ff-cc98-4fdf-b861-6be3b8d561bd, {CREATE_TIMESTAMP=1650873841979, EXECUTE_START_TIMESTAMP=1650873854007, MSG_ID=87e551ff-cc98-4fdf-b861-6be3b8d561bd, MSG_STATE=new, MSG_SUBTYPE=REFRESH_SEGMENT, MSG_TYPE=USER_DEFINE_MSG, PARTITION_NAME=transcript__0__2__20220425T0634Z, RESOURCE_NAME=transcript_REALTIME, RETRY_COUNT=0, SRC_CLUSTER=PinotCluster, SRC_INSTANCE_TYPE=PARTICIPANT, SRC_NAME=Controller_localhost_9001, TGT_NAME=Server_localhost_8001, TGT_SESSION_ID=1000232d2430120, TIMEOUT=-1, segmentName=transcript__0__2__20220425T0634Z, tableName=transcript_REALTIME}{}{}, Stat=Stat {_version=0, _creationTime=1650873842026, _modifiedTime=1650873842026, _ephemeralOwner=0}

Refresh Message is being sent here -
https://github.com/apache/pinot/blob/master/pinot-controller/src/main/java/org/apache/pinot/controller/api/upload/ZKOperator.java#L204
Message is being handled here -
https://github.com/apache/pinot/blob/master/pinot-server/src/main/java/org/apache/pinot/server/starter/helix/SegmentMessageHandlerFactory.java#L96
This is where Unsupported exception is thrown if you don't add implementation of addSegment() method.
https://github.com/apache/pinot/blob/master/pinot-core/src/main/java/org/apache/pinot/core/data/manager/BaseTableDataManager.java#L373

@kmozaid This is being done as part of opening up upload endpoint for realtime segments - in this PR: #8584

ohk, then I can close this PR, right? Also I don't see the below change in RealtimeTableDataManager , How Server is going to handle REFRESH_SEGMENT message sent by controller when segment is uploaded? Did you verify that segment uploaded are queryable in your code?

Yes you can close this PR.
Also good catch on segment refresh message handling on server side. In the integration test that I modified to upload realtime segments, I considered the refresh use case and modified the CRC of the existing segment on ZK for it, but in servers, the CRC remains the same on the local file and the segment refresh path doesn't get to the point to actually download the segment - it uses the existing segment since the CRC of the uploaded segment and the one residing on server are the same. I'll make the changes and try to update the integration test to change the CRC of the local file on server side.

Sure, I will close this PR.
On segment refresh, I think you should do following -

Upload a segment (say, with segmenName: test_segment_1) to a realtime table.
Upload a segment with the same name that you used in step 1 and but with some different data in it (similar to purge task which removes some records and upload segment with same name).
Assert that records are updated (may be count has changed if some records were removed in step 2) when you query the table.


Fix variance of read::Unit

Coverage increased (+0.0009%) to 86.531% when pulling 4b5f76cda1b4ec080cdbd4aada9e93c35a2868ec on philipc:unit-variance into 7c1b9e7703d4a99761d52341933c44f6c7f10d61 on gimli-rs:master.