How to increase grpc message size to send and receive more than 4MB?

We have large data more then 4mb to be store in sate store using dapr but due to 4mb limit of grpc it gives error:
Status(StatusCode="ResourceExhausted", Detail="grpc: received message larger than max (4234557 vs. 4194304)")
we tried the below

as well as --dapr-http-max-request-size flag still same issue, do you have any suggestion other then compression of data or chunking the data?

You can control the max message size Dapr allows on its gRPC and HTTP connections through the max-body-size parameter.
Here's a docs page that can help you: https://docs.dapr.io/operations/configuration/increase-request-size/

Hi @elena-kolevska,
We already tried out adding this flag when testing using a self-hosted instance of dapr. Is there another way because this one does not seem to work as it still returns the same error.

I tested this locally earlier today with a simple python script that tries to save a large file in a Redis state store and it worked as expected. A few things to check: is the size in bytes you're specifying correct? Are you passing this parameter to the server (dapr run --dapr-http-max-request-size <num bytes>) or to the client? It needs to be done on the server side.


Add policy to tracking allocator

We want to have a policy switch for the tracking allocator: either throw or print.
This should be achieved through an additional template argument.

fixed by #820


(PUP-8046) Fix problem with Ruby generator and Ruby keywords

When generating Ruby code from an Object data type containing
attributes or functions with names that are Ruby keywords, those names
were used verbatim in the generated code. This made it impossible to use
attribute or function names such as ensure.
This commit alters the generator so that all names that are reserved in
Ruby get prefixed with an underscore letter in the generated Ruby code.
The change is invisible from the Puppet code.

CLA signed by all contributors.


Chakra CLI usage with postinstall script is incorrect

Subject
Advanced Theming
Description
In documentation it is said that you can specify postinstall script and it'll regen theme typings.

Screenshot

This won't work if you are publishing it as UI library as @chakra-ui/cli is specified in dev dependencies. So i think it's going to be fair to change this part a bit and specify how to deal with theme typing generation when using it in library.

P.S.
I don't thing that it is useful to regen typings every time you add a dependency to your library. So this part of documentation, in my opinion, is pretty useless for now.

Hey @TheAsda!
Thanks for your feedback.
The postinstall regeneration of the types is needed when you add a new dependency as the old generated types get deleted during every install process.
Concerning the publication of the theme as a package, please refer to this part of the docs. You will need to provide the users of your theme package with a guide on how to setup their own script to generate the typings from your theme with the @chakra-ui/cli.
I hope this helps! Feel free to close this issue if it did 😊

Ok, got it!


If a scenario list is used in a job, cannot have "question_text" or "question_name" as fields

Can't reproduce - this seems to work:
from edsl import Scenario, QuestionFreeText

if True:
    sl = Scenario({"question_text": "What is your name?"})
    q = QuestionFreeText(question_text="{{ question_text}}", question_name="example")
    q.by(sl).show_prompts()
else:
    # OK
    sl = Scenario({"question_text_alt": "What is your name?"})
    q = QuestionFreeText(
        question_text="{{ question_text_alt}}", question_name="example"
    )
    q.by(sl).show_prompts()

results = q.by(sl).run(disable_remote_inference=True)
results.select("answer.*").print(format="rich")


[Event Request] Table 81 "Gen. Journal Line" - JobTaskIsSet

Please add a new event with Handled-Pattern into the procedure "JobTaskIsSet". While our solution is calculating the return value on other fields we need to overrule the standard code.
OLD CODE:
procedure JobTaskIsSet(): Boolean
begin
    exit(("Job No." <> '') and ("Job Task No." <> '') and ("Account Type" = "Account Type"::"G/L Account"));
end;

NEW CODE:
procedure JobTaskIsSet(): Boolean
var
    // start kvspsa - Variables added
    IsHandled: Boolean;
    ReturnValue: Boolean;
    // stop kvspsa
begin
    // start kvspsa - Event Raiser
    IsHandled := false;
    OnBeforeExitJobTaskIsSet(Rec, ReturnValue, IsHandled);
    if IsHandled then
        exit(ReturnValue);
    // stop kvspsa
    exit(("Job No." <> '') and ("Job Task No." <> '') and ("Account Type" = "Account Type"::"G/L Account"));
end;

EVENT-PUBLISHER:
[IntegrationEvent(false, false)]
local procedure OnBeforeExitJobTaskIsSet(GenJnlLine: Record "Gen. Journal Line"; var ReturnValue: Boolean; var IsHandled: Boolean)
begin
end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


Start http server in cli

Boot a http.Server in the CLI app, mirrors zeit/micro#406.

Fair enough. I assume it'll still be possible to set it up in a similar way to micro-dev for those not using now (using said new programmatic API)?


[stable/redis-ha] redis-ha doesn't failover properly

Is this a request for help?:
This is notifying the project of a problem with the redis-ha chart where the default behavior makes it unable to failover. I've forked the chart and am working on fixing these issues on my own but don't have the ability to open source that code (yet).

Is this a BUG REPORT or FEATURE REQUEST? (choose one):
This is a Bug Report.
Version of Helm and Kubernetes:
> helm version
Client: &version.Version{SemVer:"v2.6.0", GitCommit:"5bc7c619f85d74702e810a8325e0a24f729aa11a", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.6.0", GitCommit:"5bc7c619f85d74702e810a8325e0a24f729aa11a", GitTreeState:"clean"}

> kubectl version
Client Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.6", GitCommit:"4bc5e7f9a6c25dc4c03d4d656f2cefd21540e28c", GitTreeState:"clean", BuildDate:"2017-09-14T06:55:55Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.11-gke.0", GitCommit:"1870178bced7159908f06015f5bb0aa4ded6db76", GitTreeState:"clean", BuildDate:"2017-09-29T05:45:11Z", GoVersion:"go1.7.6", Compiler:"gc", Platform:"linux/amd64"}

Which chart:
redis-ha
What happened:
We tried to use this chart "out of the box" and found that it does not failover correctly and can lose all data. It also can take a long time to failover in default configuration when it does failover.
What you expected to happen:
Various things are expected to happen:

If the master pod goes away (there are several ways to replicate this), then a slave should be promoted to master.
If Kubernetes creates a new master pod, then it should sync to a promoted slave (and possibly become master).

How to reproduce it (as minimally and precisely as possible):
> helm install redis-ha --name foo
...
# k=kubectl
> k get pods
NAME                                     READY     STATUS    RESTARTS   AGE
foo-redis-ha-master-0                    2/2       Running   0          34s
foo-redis-ha-sentinel-1737623389-1w5sl   1/1       Running   0          34s
foo-redis-ha-sentinel-1737623389-7b3jx   1/1       Running   0          34s
foo-redis-ha-sentinel-1737623389-zrfxf   1/1       Running   0          34s
foo-redis-ha-slave-0                     1/1       Running   0          34s
...
> k delete pod foo-redis-ha-sentinel-1737623389-1w5sl
# now repeat the pod deletion on the newly launched sentinel pod 4 more times
...
# At this point, we have simulated losing 5 sentinel pods over time. The three
# remaining sentinels (two in independent pods, one in the master) know about
# a total of 8 sentinels, even though only 4 are running.
> k exec -ti foo-redis-ha-sentinel-1737623389-7b3jx -- bash -c 'cat sentinel.conf'
sentinel myid d7b3f54f334fd0721cca169cf7f792669c3558ab
sentinel monitor mymaster <IP_ADDRESS> 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel config-epoch mymaster 0
# Generated by CONFIG REWRITE
port 26379
dir "/"
protected-mode no
sentinel leader-epoch mymaster 0
sentinel known-slave mymaster <IP_ADDRESS> 6379
sentinel known-sentinel mymaster <IP_ADDRESS> 26379 cc981e138859ba752a269a014bbfef2201382de5
sentinel known-sentinel mymaster <IP_ADDRESS> 26379 54744636b1a4bb13bcc0e518cd4b9268d06c52fe
sentinel known-sentinel mymaster <IP_ADDRESS> 26379 1ee83fac0d64c032e022492754e2bbe8e01d3a1e
sentinel known-sentinel mymaster <IP_ADDRESS> 26379 26a9bcfaef60d5bc79bc52cc12f2d140c16b0761
sentinel known-sentinel mymaster <IP_ADDRESS> 26379 96700e230e4cd86e28f25be33bfd340f215c0c00
sentinel known-sentinel mymaster <IP_ADDRESS> 26379 24fbc2c84c73345c7917b5218d6ebcdf60aaceb2
sentinel known-sentinel mymaster <IP_ADDRESS> 26379 bb7ac45221b560ef8ee1c1e56fa410a99c01bf83
sentinel known-sentinel mymaster <IP_ADDRESS> 26379 dfa78ef5ab0cc5f9e68ca0454ec0a501ced1ae2c
# In another terminal, simulate the master becoming unavailable
> k exec -ti foo-redis-ha-master-0 bash
Defaulting container name to master.
Use 'kubectl describe pod/foo-redis-ha-master-0' to see all of the containers in this pod.
bash-4.3# redis-cli -p 6379 DEBUG sleep 1000
... # this hangs for 1000 seconds
# or alternately just delete the master pod

At this point, if one of the newer sentinels tried to become leader then failover might happen. If one of the older ones does, it won't be able to get a majority because so many sentinels are gone and no slave will be promoted. If the master then comes back (on the same IP address, as with container death), then it will become master again. I think (but haven't played with this part), if you're not using persistent volumes then you would lose all your data.
If the master pod instead just goes away entirely, the statefulset will helpfully create a new one, but the sentinels will never consider it master. The existing slave was never promoted to become master either (depending on which sentinel tried to be leader and how long it took) so the service is permanently unusable without intervention. The only intervention that makes everything available again is to tell all the sentinels to reset so they can fail over, but by the time this happens probably the slave hasn't synced from master in a long time and may not be a candidate for failover.
Side note: it also takes 6 minutes in the current (default) configuration between attempts to elect a leader for failover. It's normal for at least one leader election to fail during loss of a master. If the only slave then fails in that six minutes (or 12 -- I saw it take 25 minutes to failover) then you would certainly lose your data, though in our case the sentinels after that 25 minutes decided the slave wasn't promotable.
Anything else we need to know:
There are a few issues going on here some of which I've fixed in our private code (will share if I can!) and some I'm planning to fix using some examples I've found:

The default timeouts are way too long. Our biggest availability concern (and I suspect many users) is just being able to not care about individual pods. For example, if you want to do a Kubernetes cluster version upgrade in GKE, it needs to be able to drain each node in sequence. So a shorter timeout to detect lost pods is more important than a longer timeout to allow recovery without failover after network split. I've modified the underlying docker container startup script to allow injecting the full configuration (master, slave and sentinel mode) via /etc/config as a mounted volume with default values taken out of the chart values file.
Per redis sentinel docs, all existing sentinels should be told to "reset" when removing a sentinel (search that page for "Adding or Removing Sentinels") or slave instance. I've made this work by having an additional pod startup that watches for DELETED events via the watch api (specifically /api/v1/watch/namespaces/{}/pods with a selector) and then sends a reset command to each sentinel in the endpoint ('/api/v1/namespaces/{}/endpoints/{service}) with a sleep in between (this is again per the docs). Another alternative is to have a sidecar in each sentinel pod to do this, but I also had to add an api proxy to get the credentials to work right and in any case, would prefer not to add roles to the sentinels if I can add it just to a single isolated pod that doesn't take even indirect external traffic.
Having master and slaves in different stateful sets makes it hard to work with. Failing back to the master doesn't happen because if a new instance of master is started (on death of old one), it doesn't start up in slave mode and so never syncs data and can never be promoted (if it comes back on the same IP, then the sentinel will tell it to slave). Other examples I've looked at (see below) just put them all in the same stateful set which allows (on first install of the chart) the first one to start to become master and the rest slave. I'm planning to do this.
Labeling which pod is currently in each role (master or slave) by interrogating the sentinels may allow having services for write vs read-only endpoints. I might do this, but it's not necessary for our use cases (we always call thru a sentinel-aware client).

Some examples I used to figure things out:

https://github.com/tarosky/k8s-redis-ha - uses fairly non-ideal interrogation of internal DNS names (using dig) to figure out which pods are active, but assigns master/slave roles in a startup script for hte redis service itself.
https://github.com/CommercialTribe/kube-redis - uses a sidecar container to each redis-server that make kubectl calls at startup to figure out role and then monitors.
https://github.com/muchlearning/kubernetes-haproxy/blob/master/watch.py - example of how to monitor for pod changes (this case is somewhat different, but it was a good reference)

Note on server versions: when we first discovered this issue, it was actually on a cluster on version v1.7.8-gke.0 so I don't believe this is an issue with the kubernetes version.

Updating to note that I should be able to submit some PRs with fixes for parts of this, so hopefully I can do that soon. :)

@ludwick Thank you for this detailed write-up. We ran into all of the issues you described when testing out this chart. Looking forward to your PRs!

Life gets ahead of one!
We've been using our fork and improvements for a while, but I haven't packaged them up yet (I can contribute but it's not exactly a priority for me to do that work during "business" hours).  Anyway, I'll try to put up a simple fork up even if it's not ready to get merged here.

@ludwick just a soft reminder, that it would be great if you can manage to get the fork up :)

Hey all - any news on this?

Okay this is completely not in the shape to "just merge". For one, it looks like the docker image used to run redis itself has had some changes. But in the interests of making sure others can re-use it, here's my changes.
First, the underlying docker image used to run the redis pods (primary & backups & sentinels) as updated to use a single statefulset. This change is here.
We wrote a sidecar monitoring container to keep track of when sentinels died because we discovered you could end up with stale sentinels that didn't exist but that contributed to quorum decisions. This repo is right here.
Finally, here are the chart changes. Note this branch is off a pretty old commit of this repo. I didn't want to try to resolve any conflicts and get it up-to-date right now (would just put this off even more).
About this version has been running for us in production since last November with few issues. There are still some theoretical but rare issues. For example, if you lose the current primary (master) pod and then very quickly (<30 seconds) lose too many backups, then it doesn't really recover properly and you have to just kick pods  over (most common cause: loss of nodes the redis pods are on). This and other less than ideal choices could be fixed with more work, but it's rare in production for us (since we have enough nodes and redis pods are unlikely to land on the same node) though we have seen it in our usually  constrained dev/test clusters occasionally. Practically speaking, we're likely to move to a cloud redis offering since we don't want to be experts on maintaining this kind of thing. :)

There's so many issues with the stable/redis-ha chart it really should be moved into incubator. I just ran into the same issues with no failover happening.
Just to name a few other big issues I've encountered as well:
Race condition with masters #5441
Announced service no longer working #3197
PVCs possibilities #3403
I'm working on a major refactor of the chart loosely based off the PR #6706 to try to make it more production ready but still has some way to go.

@ssalaues thanks! I just hit an issue this morning as well. Master died and then I had 3 pods labeled redis-role: slave. I relabeled one of the pods to master and of course k8s relabeled it back to slave.
I'll give the redis-operator a shot, but look forward to your update


Support JsonPath functions in JsonPath expressions

Fixes #11291
Description
This PR allows users to use JsonPath functions  in JsonPath expressions during ingestion. Currently, JsonPath is used to extract values inside a JSON object. However, JsonPath supports a bunch of function expressions which are not supported by Druid now.  For example, '$.property_name.length()' can be used to get the length of a Json array object 'property_name'. This function would be useful in some cases.
The reason why Druid does not support JsonPath functions is very simple, the original code assumes that the JsonPath expressions would return a Json object. However, if a JsonPath function is applied, the return type is the raw object instead of Json object.
So fixing the bug of 'length()' function also brings support to other functions. I also brings the support of these functions to orc/avro/parquet data format.
Following matrix shows the current supported JsonPath functions and corresponding data formats.

Function
Description
Output type
json
orc
avro
parquet

min()
Provides the min value of an array of numbers
Double
✓
✓
✓
✓

max()
Provides the max value of an array of numbers
Double
✓
✓
✓
✓

avg()
Provides the average value of an array of numbers
Double
✓
✓
✓
✓

stddev()
Provides the standard deviation value of an array of numbers
Double
✓
✓
✓
✓

length()
Provides the length of an array
Integer
✓
✓
✓
✓

sum()
Provides the sum value of an array of numbers
Double
✓
✓
✓
✓

concat(X)
Provides a concatenated version of the path output with a new item
like input
✓
✗
✗
✗

append(X)
add an item to the json path output array
like input
✓
✗
✗
✗

keys()
Provides the property keys (An alternative for terminal tilde ~)
Set
✗
✗
✗
✗

append, concat are not fully supported, because I don't see there's strong need to use them.
keys() is not supported because it's not supported by current JsonPath library used by Druid. And also I don't see there's a strong need to use this JsonPath function.

This PR has:

[X] been self-reviewed.

[ ] using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)

[X] added documentation for new or modified features or behaviors.
[ ] added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
[ ] added or updated version, license, or notice information in licenses.yaml
[ ] added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
[X] added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
[X] added integration tests.
[X] been tested in a test Druid cluster.

CI failes when testing ORC extension which might has something to do with this PR. I will check it.

Marked as WIP because a change to a binary ORC message file was lost. I have to re-do the change.

Hi, @FrankChen021, we've run into this issue, and I was wondering if we can help get this PR over the finish line. Do you think you'd have the time to update the PR for the lost change to the ORC file? If not, we can take a look.
At a quick glance, it seems like the failing assertion is:
Assert.assertEquals("2", Iterables.getOnlyElement(row.getDimension("struct_list_struct_intlistLength")));

I'm wondering if this is a spurious check, and the assertion for struct_list_struct_middleListLength just below it is the intended check. I don't see a JSON path spec that'd produce the struct_list_struct_intlistLength in the row, but I'm definitely missing some context here.

@dkoepke There must be some reasons that I added a new field to the ORC example file and that check. But I can't remember now. I will take a look in this weekend.

@zachjsh @jon-wei  Thanks for your review.


Light State not refreshing

Found another interesting bug, unsure if it is with the integration or home assistant.
I was trying to pass some data in scripts to turn on the lights with specific brightness and/or colour temps, as seen below:
service: light.turn_on
data_template:
entity_id: '{{ entity }}'
brightness_pct: 100
When running the script with a specific light, the light does turn on but the "On" state is not visible in either Home Assistant or the Tapo App. In both softwares, the light is considered off although it is physically on. This is using the same L530 we used to debug the brightness and colour temp bug in a previous issue, running on 1.2.8 (I can post the software and hardware details again if needed).
On the other hand, if I run the script without passing any other data, apart from entity_id, the script works fine and the state is correctly refreshed in both tapo app and HA.
service: light.turn_on
data_template:
entity_id: '{{ entity }}'

Can you post the log after executing the service with brightness? In the log, there should be strings like: Setting brightness...

Reinstalled the integration and seems to be fine, I probably did something wrong in my previous manual installation.


Settled up icon on group card

Quick implementation for idea 1 in https://github.com/scastiel/spliit2/issues/44
Demo: https://www.loom.com/share/760c75995df94df1bdc91205631e365e?sid=5959bc98-c2a5-4332-8f2f-50f551611d05
Also happy to discuss alternative ideas for how to achieve "Indication of "Settled up" groups"
V2 with groupings of groups: https://www.loom.com/share/1c7edc686d0d43b5a01d3f467438def1

Thanks @acuteengle, amazing job 👍
I update your PR to fix a couple of TypeScript issues. I also added a title at the top of each section (Starred groups, Recent groups, Archived groups), I think the page looks better this way!


enable sort by tx.blockNumber

support DataTable sorting.

blockNumber or date fields have same meaning.
disable sort by tx.value. (tx.value is a string)

Apologies for my delay in merging these PRs. I will get to all of them tomorrow.


Get list of all abilities

Is there a way to get a list of all possible abilities?
With GetAxieDetail you can get the parts abilities for a specific axie, but I would like to get all possible abilities.

I could think of one way, by getting axie details from random axies and collecting all unique abilities.
Do you know of a better way?


LDAP group DN

Rancher Version:
1.1.1
Setup Details: (single node rancher vs. HA rancher, internal DB vs. external DB)
single node rancher
Environment Type: (Cattle/Kubernetes/Swarm/Mesos)
Cattle
Steps to Reproduce:
Configure access control through OpenLDAP
Expected:
Is it possible to support authentication through LDAP groups, so users in a particular DN can log in rather than the entire organisation.  And also Admin users set through a similar DN group.

+1

@asanami If you are asking for authentication an user based on LDAP credentials and authorization based on LDAP group membership, then the answer is: this has already been implemented.
Try enabling OpenLDAP via the "Admin" -> "Access Control" menu entry. For being successful at that you need to know the DN and password of an existing service account in your LDAP tree which rancher uses to bind onto your LDAP tree. After that you are able to permit/restrict access to particular environments based on LDAP groups (See Manage Environments).
The second part of your question, i think, is referring to something discussed in issue #5488

when did that land? because I also think that you can't do group-based authentication - my last test, which is about 5 weeks old, resulted in full access for EVERY ldap user. so the authentication basically mutated to a "are you in LDAP so you may pass" thing.

I think what @flypenguin is asking for setting restricted access to Rancher based on groups in ldap. This will deny login to any users out of the groups.
This is implemented for Active Directory - not yet for OpenLDAP access.
I think this is same as issue https://github.com/rancher/rancher/issues/5141

Well, not only login / not login, but to be able to have the full group-based management what is done when using GitHub authentication. At least environment-based access for different groups, and admin / non-admin access, etc. :)

@flypenguin environment-based access for different groups is already supported, that is what @funbar mentioned in his comment.
And login / not login will be taken care of by https://github.com/rancher/rancher/issues/5141
Can you describe what other functionality you are looking for  other than the two above?

Closing in favor of #5141.
@flypenguin The admin functionality based on groups would be this ticket. Basically,  being able to give admin access to an entire group instead of individually. https://github.com/rancher/rancher/issues/5488


Added route to get RSS file

Adding rss route to return signed URL, doing a PR to both dev and staging for this.

Looks good


Look forward to the code

Good job. @yeates have schedule of releasing the code or demo?

Thanks for your attention! This work is currently under peer-review. My coauthors and I believe it is necessary to release the code and weights after acceptance. But, we plan to release the dataset recently, so please stay tuned.


Fix #137 : Resolving pen stroke feature

Issue Title:
resolve issue: #137
Type of change ☑
What sort of change have you made:
I added some functions to ensure that on clicking of the pen button the thickness button can be turned on or off. And various types of pen styles can be selected by clicking on the arrow button.
Example how to mark a checkbox:-

[x] My code follows the code style of this project.
-->
[x] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[x] Code style update (formatting, local variables)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Checklist: ☑

[x] My code follows the guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly wherever it was hard to understand.
[x] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.
[x] I have added things that prove my fix is effective or that my feature works.
[x] Any dependent changes have been merged and published in downstream modules.

How Has This Been Tested? ⚙
I have checked the changes in my computer and it is working properly.

@kumar1397 Your code is not synced with the latest changes, kindly resolve it.
Actual :

Yours:

I'll advice you to copy the changes you did to make your functionality work & re-clone the repo after syncing it & then make the changes then create a PR.

@kumar1397 Do update me or else I have to close the PR & unassign you the issue.

closing due to inactivity.


undefined method 'first' for embedded with belongs_to self

Is this a bug or am I doing it wrong?
class Foo
  include Mongoid::Document
  embeds_many :bars
end

class Bar
  include Mongoid::Document
  embedded_in :foo
  belongs_to :other, class_name: 'Foo'
end

foo1, foo2 = Foo.create, Foo.create
foo1.bars.create(other: foo2)

.../gems/activemodel-3.1.2/lib/active_model/attribute_methods.rb:385:in 'method_missing': undefined method 'first' for #<Bar:0x007fdedea16e08> (NoMethodError)
from .../gems/mongoid-2.3.3/lib/mongoid/attributes.rb:184:in 'method_missing'
from .../gems/mongoid-2.3.3/lib/mongoid/relations/embedded/many.rb:263:in 'block (2 levels) in substitute'
from .../gems/mongoid-2.3.3/lib/mongoid/relations/embedded/atomic.rb:61:in 'call'
...

What I actually want to accomplish is something like this (in pseudo-code):
class Image
   has_many :distances, foreign_key: "image1_id or image2_id"
   def similar(max_distance = 2)
      distances.where(:distance.lte max_distance).map{|d| [d.distance, d.the_other_image]}
   end
end

class distance
   belongs_to :image1
   belongs_to :image2
   field :distance, Integer
end

Distance is the "distance" between two images as calculated by the Similie image fingerprinting gem.
I was brainstorming ways to solve this when I stumbled upon that error.

So if I have this correct, you essentially want to ask any image for other images that are within a certain distance of it?

Almost correct, but they won't be plotted and the distance isn't geometrical distance but rather a value describing how similar two images look visually. If it's two completely different images, the distance will be large but if it's the same image cropped, resized and watermarked, the distance will be small.
They will be used for duplicate detection and "other images similar to this one".
When an image is uploaded I will store its fingerprint (just a large integer) and then a background job will calculate its distance to all other images using their stored fingerprint.

Ok I see what you're trying to do... Then try this, since you don't need the inverse reference to the other one:
class Foo
  include Mongoid::Document
  embeds_many :bars
end

class Bar
  include Mongoid::Document
  embedded_in :foo
  belongs_to :other, class_name: 'Foo', inverse_of: nil
end

foo1, foo2 = Foo.create, Foo.create
foo1.bars.create(other: foo2)

Yes, that works! Thanks.
Thinking about it I won't use embedding though, because it will potentially make the Image document humongous.

Yeah I was trying to think of a quick way to model it in a different manner as well, my first instinct was to use map reduce but it would be slower querying than pre-calculating on a bg job... If I think of anything while working I'll let you know.

My new approach to finding similar images is this:
class Image
  def similar(max_distance = 2)
    ImageDistance.similar_to(self, max_distance)
  end
end

class ImageDistance
  belongs_to :image1, class_name: 'Image'
  belongs_to :image2, class_name: 'Image'
  field :distance, type: Integer

  def self.similar_to(image, max_distance = 2)
    any_of({image1_id: image.id}, {image2_id: image.id}).
    and(:distance.lte => max_distance).
    order(:distance).map do |d|
      [d.distance, (d.image1 == image ? d.image2 : d.image1)]
    end
  end
end

The ImageDistance class makes sure the image with the lowest id is image1 and the other is image2 and then has a unique index on [image1, image2].


Issue with Padrino

One user has reported a problem where there's an exception thrown when sending errors from a Padrino app. This is with version 1.2.6 of the rollbar gem.
Backtrace: http://i.imgur.com/PQaev3T.png?1

Closing this out as it's quite old and hasn't come up since.


Count of Tralling Ciphers in N!

…rial of a number
Description of Change

Checklist

[x] Added description of change
[x] Added file name matches File name guidelines
[x] Added tests and example, test must pass
[x] Added documentation so that the program is self-explanatory and educational - Doxygen guidelines
[x] Relevant documentation/comments is changed or added
[x] PR title follows semantic commit guidelines
[x] Search previous suggestions before making a new one, as yours may be a duplicate.
[x] I acknowledge that all my contributions will be made under the project's license.

Notes:

@ayaankhan98 @Panquesito7 Can I contribute to this file/repo/question?

Can I contribute to this file/repo/question?

Sure, you can re-make this PR and make it up to the repository standards.
We'll be glad to review your PR, and we'll review it as soon as possible.
Thank you. 🙂


lib.systems: introduce toolchain, cc, and bintools attributes

Things done
Replaces useLLVM, useArocc, and useZig with toolchain, cc, linker, and bintools attributes. This might not produce any rebuilds but we'll see. This has the advantage of preventing using${compiler} flags from colliding and not working correctly if we were to stack multiple pkgs* together.

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

I'd appreciate a "next steps" portion of this PR

Next step is to add exports for LD or change exports for LD to the linker explicitly set. The idea is the bintools and linker can be less connected. From there, it'll probably be more explicit defining of the CC and other tools. Maybe a setup hook inside CC wrapper or other stuff could do it. Then I'll redo my CPU model PR and make some of that optimization stuff more flexible between different compilers.

where you give some guidance on how and what's going to happen next, especially if there are breaking changes.

Probably any other things we could look into doing that makes it easier to add an LLVM bootstrap to Linux.

Hmm. I like the design. But I wonder about backwards compatibility. Will users suddenly experience this not working as expected in their existing expressions?
(orthogonal) Ideas:

Support the old attributes, rewriting them as the new.
Put assertions in that fire if the old attributes are in use.
(alternatively, emit trace deprecation warnings)
Catch the case where users supply something invalid. (Currently they can put anything in there, which can be confusing if there is a typo and things don't work as intended).

I don't know what level of support users should expect of these (existing) attributes, but I can say that I would probably find things quite confusing when this lands, had I not seen this PR.

Will users suddenly experience this not working as expected in their existing expressions?

Yeah, it'll just not work lol

Support the old attributes, rewriting them as the new.

Tried as a warning or throw but it was causing stdenv to fail.

Put assertions in that fire if the old attributes are in use.

This could work, I can easily add in asserts to the platform stuff to make that work.

(alternatively, emit trace deprecation warnings)

Mentioned earlier, tried this. We'd see like 8 warning every time stdenv is used.

Catch the case where users supply something invalid. (Currently they can put anything in there, which can be confusing if there is a typo and things don't work as intended).

This is likely the simplest and best solution. Add a few asserts which check to ensure nobody is passing the deprecated attributes.

It is possible to use clang with the GCC runtimes. Is a straightforward expression available here which would be of the form f stdenv where it would return true if compiler-rt was in use and false if gcc was in use? This question is independent of whether the llvm toolchain is in use, because you can use a clang compiler with the gcc standard libraries, and there are cases where it is useful to be able to detect this situation.
Today for instance clangStdenv.hostPlatform.useLLVM returns false; would the equivalent in the new world be clangStdenv.hostPlatform.toolchain == "gcc", and is that weird?

It is possible to use clang with the GCC runtimes.

Afaict, that's already possible and the default behavior on Linux.

Afaict, that's already possible and the default behavior on Linux.

I realise, but just trying to think through the meaning of these new values (and also the old ones such as useLLVM); and whether they are clear and expressive enough.

These new values are more fine grain, useLLVM already conveyed to use the LLVM toolchain. The compiler attribute only switches out the compiler being used. Linker only will change the linker and bintools changes the binary tools. However, toolchain is a more "global" control that changes all the options. This allows for more precise control over the platform's build environment.

How would Darwin be represented in this taxonomy? ``

Darwin is an odd one

toolchain = apple, cc = clang, bintools = llvm, linker = ld64

That is close, the linker defaults to cctools. I don't think we'd support changing these options much outside of Linux. It's just simpler enough to support as is outside of Linux.

That is close, the linker defaults to cctools. I don't think we'd support changing these options much outside of Linux. It's just simpler enough to support as is outside of Linux.

It’s currently cctools, but I’m suggesting it ought to be ld64 since that’s the actual linker being used. Given that there are other linkers available for Darwin (such as lld and emerald), it would be nice if changing the linker also worked for Darwin. (I assume changing cc to gcc is also expected to work? Is that potentially an alternative to using gccStdenv?)

I’ll add that addressing Darwin support beyond the default doesn’t have to be part of this PR, but I would like to see what such support would like so it can be addressed separately.

It’s currently cctools, but I’m suggesting it ought to be ld64 since that’s the actual linker being used.

Oh gotcha

Given that there are other linkers available for Darwin (such as lld and emerald), it would be nice if changing the linker also worked for Darwin

Yeah, I can make that happen once I start making the linker attribute work separately from bintools in my follow up PR.

I assume changing cc to gcc is also expected to work?

It should, I'm not sure whether it actually does work as intended.

Is that potentially an alternative to using gccStdenv?

It can be, it applies through everything using stdenv rather than an explicit stdenv.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/community-team-updates/56458/11

I have to agree, it seems to me that we are replacing an ad hoc system with a better, but still ad hoc system that, however, is more difficult to test. The use* flags as ugly as they may be just add another way of bootstrapping the package set (per supported local/crossSystem combination). It has other problems of course, especially when we have a lot of such flags. What the necessity of the toolchain argument implies, is that you can't (yet) arbitrarily combine pieces of a toolchain. I would question whether even our own wrapper code is free of such assumptions.
What concerns me about the proposal presented here is that it doesn't achieve a clear separation between the parts it introduces:

toolchain overlaps with everything else, but can't be reduced to a shorthand for other flags. It implies linker, cc, bintools, but other code still will have to check toolchain. This is problematic and will invite expressions to check the incorrect value because in normally cases they are associated with each other.
bintools overlaps with linker. I appreciated this is future work, but then I'd at least enforce that the behavior matches the prescription, i.e. if we have conflicting bintools and linker, I'd fail for now.

If it represents things like use of libunwind, those should also be split up into their own fields.

I think another problem of our current approach with elaborate is that in principle every field can be set manually and be computed. Some fields should probably always be computed because they are a property of the platform or a property of the combination of platform and toolchain, so it would just not work to specify this manually. This is stuff like exceptions, runtime libs, libunwind etc. typically.
It doesn't make sense to remove such properties from the platform set necessarily because a) it's best that they are managed in a central place so expressions don't need to duplicate the logic and b) what may be computed for some platforms is configurable for others [citation needed] or may become configurable later [citation needed].

toolchain overlaps with everything else, but can't be reduced to a shorthand for other flags. It implies linker, cc, bintools, but other code still will have to check toolchain. This is problematic and will invite expressions to check the incorrect value because in normally cases they are associated with each other.

Right. What I’d like is that toolchain is only shorthand for other flags, and that all downstream packages check linker, cc, bintools, unwind, etc. It’s okay if we don’t make everything downstream perfectly orthogonal for now as long as we make an effort to check what the packages actually care about.
Though, really, once we do that, it seems that the utility of the toolchain shorthand is small enough – constructing custom cross package sets is not that common a use‐case – that we can simply dispense with it entirely.

bintools overlaps with linker. I appreciated this is future work, but then I'd at least enforce that the behavior matches the prescription, i.e. if we have conflicting bintools and linker, I'd fail for now.

Actually, I believe the correct thing for Darwin today is LLVM bintools but Apple linker. AIUI we use very little of cctools at this point and it’s basically an LLVM platform as far as bintools go.

However, if we split it up – which I agree is a good idea – then what remaining meaning does toolchain have?

Toolchain is covering more than just the cc, linker, and bintools. It's guarding previous checks for useLLVM as toolchain == "llvm". So it doesn't just specify what options are in use but as a simple definition for what toolchain we have in use.

It implies linker, cc, bintools, but other code still will have to check toolchain. This is problematic and will invite expressions to check the incorrect value because in normally cases they are associated with each other.

I can update the predicates to add fixed attributes which change based on the new attributes. Then it'll be easier to check. But I think having better documentation on what toolchain could be would also suffice. If people were to use a wrong value, it'd be immediately clear since there wouldn't be a change in behavior.

but then I'd at least enforce that the behavior matches the prescription, i.e. if we have conflicting bintools and linker, I'd fail for now.

I'm not sure I follow with the behavior. Some of the new behavior is in place but to get any further would require significant work and likely would have to go to staging. My thinking was to leave that change for later, especially since a lot of packages and stuff will require tuning.

Toolchain is covering more than just the cc, linker, and bintools. It's guarding previous checks for useLLVM as toolchain == "llvm". So it doesn't just specify what options are in use but as a simple definition for what toolchain we have in use.

That’s precisely the problem: we split things up, but don’t condition on the split things, so we still essentially have one monolithic coupled toolchain selector with the illusion of more specificity. “What toolchain? LLVM” is not an answer that makes sense if you can vary other components of the toolchain freely, and indeed this causes problems in practice now for Darwin. The only way to split it up that makes sense is to cover every bit of relevant variance as separate fields and ensure that all downstream packages look at those.

The reason it's like that is because I was running into infinite recursions and cases where things weren't applying correctly. Darwin uses the apple toolchain, not the llvm one. If Darwin tries using the llvm one then we get infinite recursions within libunwind and libcxx.

But the Darwin toolchain is actually almost entirely LLVM except for the linker. Those issues are what would need fixing to make this a good step forward, rather than just adding additional variables that aren’t actually independent because of bugs in Nixpkgs. If we want to split up the toolchain fields then nothing downstream of stdenv should be reading toolchain at all.

Do we want this PR to have mass rebuilds on Darwin but none on Linux? Also, I'm not familiar with how Darwin does things so changing out toolchain to use llvm will break a lot of things. To me, that feels out of the scope of this PR. My intentions with this PR was to just get started with adding the new attributes. In it's current state, it reflects how upstream operates. The only rebuild right now is just the manual which usually happens.

Another note is we'll likely have to change toolchain == "llvm" to toolchain == "llvm" && !isDarwin since things differ enough to warrant it.

I've got a log of the infinite recursion: https://gist.github.com/RossComputerGuy/d43df8fc4c3b6fe4adf8020db8c3a94a

Another note is we'll likely have to change toolchain == "llvm" to toolchain == "llvm" && !isDarwin since things differ enough to warrant it.

Again, there shouldn’t be any conditions on toolchain == "llvm" at all if we’re splitting toolchain up into multiple variables. The ways in which Darwin differs should be reflected in other variables like linker. If we just want to move away from booleans, then we could perhaps make toolchain an enum without introducing the new variables which will only cause correctness issues and confusion if toolchain is still the ultimate source of truth.

Again, there shouldn’t be any conditions on toolchain == "llvm" at all if we’re splitting toolchain up into multiple variables.

Then how do we get the same logic as useLLVM but without using that attribute? There's things which need changing that checking the CC or bintools isn't enough.

The question is what they need to check it for. If it’s for the unwinding library, we should have a field for that too. If it’s about the C++ library, we should have a field for that too. If we continue to treat “LLVM toolchain” as a monolithic thing, then we won’t be able to vary these separate fields coherently, and we’ll continue to have issues with Darwin, so introducing these new attributes brings no real benefit.

Ok, we'll probably need one for the C++ library, CC unwinder, and rtlib. Usually those are coupled with cc but can be different based on the toolchain in use.

IIRC there’s already checks like stdenv.cc.libcxx != null that let you condition on the C++ library. So not everything necessarily has to be a new platform field.

That is null on the toplevel stdenv, doesn't help in every case.


Basic UI Improvements

Agenda:

Progress:

Is this ok? Should I open a PR?

Yes, go for it!

Yayy cool. Sending in awhile


Update Pages “pestinspectionsPage”

Automatically generated by Netlify CMS

👷 Deploy Preview for chic-shortbread-66a66b processing.

Name
Link

🔨 Latest commit
5e1cdf98cc104302281df595258f69071c2a1b99

🔍 Latest deploy log
https://app.netlify.com/sites/chic-shortbread-66a66b/deploys/65643b00bf270a0008286317


How to set the value of multiple elements in one slice at one time

In NumPy, if we want to use slices to assign a group of values to an array, it will work very smoothly.
For example
a = np.zeros((4,4))
b = np.ones(4)
a[1,:] = b

Can numjs do the similar thing?

see https://github.com/nicolaspanel/numjs#basic-operations


Cannot decode image data

I tried to get the example code running.
The image decoding is failing for the fetched files: https://api.mapbox.com/v4/mapbox.mapbox-streets-v8/17/65466/43975.mvt?access_token=...
"Error: ImageCodecException: Failed to decode image data. Image source: encoded image bytes     at Object.throw_ [as throw] (http://localhost:39407/dart_sdk.js:5041:11)     at _engine.CkAnimatedImage.decodeFromBytes.createDefault (http://localhost:39407/dart_sdk.js:133885:19)     at _engine.CkAnimatedImage.decodeFromBytes.ManagedSkiaObject.new (http://localhost:39407/dart_sdk.js:132149:65)     at new _engine.CkAnimatedImage.decodeFromBytes (http://localhost:39407/dart_sdk.js:133932:43)     at Object.skiaInstantiateImageCodec (http://localhost:39407/dart_sdk.js:173809:12)     at instantiateImageCodec (http://localhost:39407/dart_sdk.js:128334:24)     at instantiateImageCodec.next (<anonymous>)     at runBody (http://localhost:39407/dart_sdk.js:37422:34)     at Object._async [as async] (http://localhost:39407/dart_sdk.js:37453:7)     at Object.instantiateImageCodec (http://localhost:39407/dart_sdk.js:128332:18)     at binding$5.WidgetsFlutterBinding.new.instantiateImageCodec (http://localhost:39407/packages/flutter/src/painting/binding.dart.lib.js:81:17)     at decodeImageFromList (http://localhost:39407/packages/flutter/src/painting/image_decoder.dart.lib.js:16:75)     at decodeImageFromList.next (<anonymous>)     at runBody (http://localhost:39407/dart_sdk.js:37422:34)     at Object._async [as async] (http://localhost:39407/dart_sdk.js:37453:7)     at Object.decodeImageFromList (http://localhost:39407/packages/flutter/src/painting/image_decoder.dart.lib.js:15:18)     at VectorTileWidget._VectorTileLayerState.new.<anonymous> (http://localhost:39407/packages/flutter_map_vector_tile/vector_tile_plugin.dart.lib.js:2244:39)     at Generator.next (<anonymous>)     at runBody (http://localhost:39407/dart_sdk.js:37422:34)     at Object._async [as async] (http://localhost:39407/dart_sdk.js:37453:7)     at http://localhost:39407/packages/flutter_map_vector_tile/vector_tile_plugin.dart.lib.js:2233:119     at _RootZone.runUnary (http://localhost:39407/dart_sdk.js:37274:59)     at _FutureListener.then.handleValue (http://localhost:39407/dart_sdk.js:32530:29)     at handleValueCallback (http://localhost:39407/dart_sdk.js:33057:49)     at Function._propagateToListeners (http://localhost:39407/dart_sdk.js:33095:17)     at _Future.new.[_complete] (http://localhost:39407/dart_sdk.js:32935:25)     at Object._cancelAndValue (http://localhost:39407/dart_sdk.js:37653:24)     at http://localhost:39407/dart_sdk.js:19279:21     at Object._runUserCode (http://localhost:39407/dart_sdk.js:37610:7)     at http://localhost:39407/dart_sdk.js:19277:17     at _RootZone.runUnaryGuarded (http://localhost:39407/dart_sdk.js:37211:11)     at _BroadcastSubscription.new.[_sendData] (http://localhost:39407/dart_sdk.js:31145:22)     at _DelayedData.new.perform (http://localhost:39407/dart_sdk.js:34417:28)     at _StreamImplEvents.new.handleNext (http://localhost:39407/dart_sdk.js:34521:15)     at async._AsyncCallbackEntry.new.callback (http://localhost:39407/dart_sdk.js:34282:16)     at Object._microtaskLoop (http://localhost:39407/dart_sdk.js:37526:13)     at _startMicrotaskLoop (http://localhost:39407/dart_sdk.js:37532:13)     at http://localhost:39407/dart_sdk.js:33303:9"
Did the format change?

Couple of questions, have you updated recently, and this is on the Master branch ?
Also is this trying to get it working in a browser ? As I can see a lot of js there..

I checked out the filter branch, there it's working on my Android device.
For Web however, the spawning of isolates is not possible due to Framework limitations. I'll do some research if there's a workaround for that.

Yes, I haven't got as far as looking at the web side as yet. My understanding was there may be something possible with web werkers, but I didn't want to go down that route until I was happy with how the other stuff worked. There's a lot involved with getting vector tiles working so it's hard to tell if it would ever be "stable" :D.

Yeah, I came here through the big flutter_map issue, which is going on already since a couple of years :D Complicated stuff, those vector tiles. However, I'll keep an eye on this project here, and wish you good luck continuing!

Out of interest, how did the filter branch perform on your device ? Looking for a bit of general feedback on other devices to mine.

At first I thought something is wrong, now I wanted to make a screenshot for you and realized it just takes ages on my old 2013 android test device it takes about 15sec to render the initial tiles after App start. When I pan around to new areas it gets slower and slower... I also built the example in release-mode but it doesn't seem to make a difference.

Thanks for the feedback. I thought it may suffer with old devices.
Out of interest, I think its probably the main.dart in the lib folder, rather than the examples folder which is the latest to test with (or try both). Also it may be worth swapping useCanvas=true and useImages=true around. useImages tries to draw to an image and then is faster after loaded, but useCanvas has some line thinning optimisations (only have one of them set to true, the other false) and doesn't use images (maybe preferable if it's not a powerful device with many cores/ram).
I'm still undecided which is preferable (and may depend on devices), so as mentioned it's all still very experimental.
Thanks again.

So far I only tested with the new main.dart (not the one from examples/).
Swapping useImages with useCanvas results in only half rendered screen on my device. Some tiles just never get rendered, doesn't matter how long I wait.
But it might not be the rendering itself which causes the problems, I noticed this in my debug log while running the app in profile mode:
2 I/flutter (11172): Warning database has been locked for 0:00:10.000000. Make sure you always use the transaction object for database operations during a transaction I/chatty  (11172): uid=10142(com.example.example) 1.ui identical 11 lines 2 I/flutter (11172): Warning database has been locked for 0:00:10.000000. Make sure you always use the transaction object for database operations during a transaction I/chatty  (11172): uid=10142(com.example.example) 1.ui identical 2 lines 2 I/flutter (11172): Warning database has been locked for 0:00:10.000000. Make sure you always use the transaction object for database operations during a transaction I/chatty  (11172): uid=10142(com.example.example) 1.ui identical 13 lines 2 I/flutter (11172): Warning database has been locked for 0:00:10.000000. Make sure you always use the transaction object for database operations during a transaction I/chatty  (11172): uid=10142(com.example.example) 1.ui identical 1 line I/flutter (11172): Warning database has been locked for 0:00:10.000000. Make sure you always use the transaction object for database operations during a transaction
I guess this code is running inside the isolate, so it's not visible to the dart profiler.
The rendering might be not the problem itself, and the bottleneck is possibly somewhere else (I haven't really looked in your code).
Besides that, maybe you want to reconsider using flutter_isolate for your package, since it's only working on iOS and Android. I did some research and found this: https://github.com/deakjahn/flutter_isolate_web it seems to be a cross-platform solution for that. There isn't much out there when it comes to cross platforming with isolates. It seems like that could be a solution. However, I failed to implement that code in a short time to give it a shot, since I never worked with isolates before and don't want to spend much time on that...
But maybe I can contribute a decent example application, so people who stumble upon this project can give it a shot and might get interested, or contribute some test results.

Mhm letting the app open for a couple of minutes and staring to pan around on zoom levels > ~15 will actually render much faster ~1-2 sec after panning to a new location. But it sometimes to "forget" to render some tiles and leaves them at a lower zoomlevel or leaves them blank.

Heya, thanks again. Out of interest, what's the device you are testing on ? I may try and see if I can borrow something similar, as it's often easier for testing then.
I haven't looked into the forgetting a tile yet, not sure if that's one that never got downloaded, or just doesn't display for some reason. I'm using my own tile layer to try and improve performance.
I'm not sold on using isolates at all, and that's why I haven't merged any of that into master. The last month or so have just been experiments with filters, styles and isolates and seeing how performant I can get them.
The biggest problem typically is drawing thick lines is super slow in canvas (issue with skia), which locks up the UI. So I've been trying to come at various angles, eg draw hairline strokes when moving, or at low zoom levels, and having a limited enforced style set. In some ways that original version was more slick than my recent style/filter/isolates work. So something for me to ponder.
I think I'll probably try and pull it together bit so everything is an option and then it's a bit easier to experiment.
Thanks again

Maybe you can also simulate it with an emulator and bad specs. It's an Galaxy Note 3, not the worst device from that time at all.
I was just contributing to a project couple of minutes ago, that used isolates for GeoJson decoding. In my test it even ran faster without isolates, just single threaded. Multi-threading in Dart doesn't seem to be as effective in most cases as in other well known languages what I've seen so far - but it's always also a question of the implementation and use case of course.
For your project I think it would make sense to also offer single threaded processing. In that way you could also make use of the dart profiler, which is pretty neat finding performance issues (it doesn't seem to work with isolates from what I've tried).
You did already a great process with it! Congratulations for that :)

Thanks for the thoughts, I think I've already done an option for not using isolates on a different branch I've just updated unimaginatively called "options" :D, where you can set useIsolates: false in the Optimisations in main.dart (not in examples). It's very much in debugging stage still, but should work similar to the other branch apart from a few tweaks like that. I'm away for a week shortly though, so won't get much change to tidy it up. You can also switch between using Images or Canvas.
I've resurrected an old tablet to test on. The problem with the emulators is simulating pinchzoom which is where for me typically the problems lie, and why I've tried isolates. If you don't use something, the ui gets blocked, but each "solution" causes another issue :D. Isolates do seem to just add another resource that's used though, it helps prevent blocking, but then it's using more resources in another way.
I'm almost wondering whether to ditch all the complexity though, as it's currently all a bit messy, go back to pure vectors (rather than options like vector to image), enforce simple fast styles.


Adding description to new revision is lagging

Description:
Below situation can be experienced when trying to add description to new revision in deployments page. The changes what we made is late to reflect in text box. It can not see any latency in other text boxes in same deployment.

Steps to reproduce:

Create new API
Go o deployment page
Try to add description to new revision

Affected Product Version:
APIM 4.0.0
Environment details (with versions):
"APIM Distributed Testing  - 2 hour session" environment

Optional Fields
Suggested Labels:
APIM 4.0.0

Duplicate: https://github.com/wso2/product-apim/issues/10609


Background changer

Describe the project you want to add with tech stack

Expected behavior

Screenshots (optional)

Additional context (optional )

Create a new issue with proper description


px4_snapflight_sanitytest fix paths and drop legacy

FYI @julianoes

It's working, and perhaps not surprisingly eagle is currently broken in master.


Updated maxConnections to 1.

The example in https://preliminary.istio.io/docs/tasks/traffic-management/circuit-breaking/ want to use  maxConnections: 1, but the destinationrules is setting maxConnections: 100, we should update document to set it as 1.
/cc @geeknoid @frankbu

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: gyliu513
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: geeknoid
Assign the PR to them by writing /assign @geeknoid in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: frankbu, gyliu513
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: geeknoid
Assign the PR to them by writing /assign @geeknoid in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Confused about the API

Hi, I'm looking to create my own Bonjour service advertisement, and this looks like the general tool to do that (though I'm new to network dev and I might be lost). I see the docs on the front page showing how to enumerate the available Bonjour services (and it worked) but I guess I'm looking for a more extensive documentation that includes advertisement.
I tried Mono.Zeroconf before but ran into problems, and this project looks like a good alternative since you're actively supporting it. :)

Hi @tealshift, the library only supports querying for devices not publishing them. I'd welcome a PR that adds that support.

Thanks for clarifying. Hopefully I can find some way to do this on Windows.


Improvements to smooth control for plots

After smooth template became default we need to find another way to control smoothness:

We should be able to save the value in between sessions. Atm, if you open plots -> change the value -> close plots -> open them again you are loosing your changes to the value.
On some high contrast light / dark themes it blends with the background behind the plots. Should be the color of the plot canvas instead.
Can we align the control to the corner and make the background transparent?
Should be a button per plot that open that control and/or control per section that can change all at once?

Can we close this after #3250?

@mattseddon I've updated the description and repurposed the ticket a bit.

Related to #3837

All state in Vega charts is stored in the data or the signals which you can read/write using the Vega View API. You should be able to use this functionality to store the state across chart changes. You can also use the same API to coordinate changes across multiple charts to address the last point. It may even be possible to bind the param for smoothing from multiple Vega views to the same input DOM element (https://vega.github.io/vega/docs/signals/#bind) but I haven't tried that.

Can we align the control to the corner and make the background transparent?

Tried this, and while it looked ok on larger plots, it looks buggy on smaller plots:

As discussed synchronously, going to close this as most tasks have been completed and we aren't planning to add a across-plot smooth control feature at the moment.


Fix handling of parametrized types in CppCodeGen

Use NameMangler.GetMangledTypeName directly to get the EEType name
Delete filtering of IsPointer and IsByRef during type emission since it works fine now

Fix #2486

@MichalStrehovsky PTLA


Empty summary items

Describe the bug
Summary' items list is empty.
To Reproduce
Steps to reproduce the behavior:
no clue
Screenshots and logs
2021-02-01 16:31:35 info: Offer #4425841358 from xxx is being processed...
2021-02-01 16:31:35 info: Offer #4425841358 from xxx checking escrow...
2021-02-01 16:31:36 info: Offer #4425841358 from xxx received offer
2021-02-01 16:31:47 info: Offer #4425841358 from xxx checking bans...
2021-02-01 16:31:54 trade: Offer #4425841358 from xxx accepting. Summary:
{
    "asked": "0 keys, 0 ref (nothing)",
    "offered": "0 keys, 0 ref (nothing)"
}
2021-02-01 16:31:55 trade: Offer #4425841358 from xxx successfully accepted; confirmation required
2021-02-01 16:32:09 info: Message sent to X (xxx): I have accepted your offer. The trade will be finalized shortly. If the trade does not finalize after 1-2 minutes has passed, please send your offer again, or add me and use the !sell/!sellcart or !buy/!buycart command.
2021-02-01 16:32:46 verbose: Offer #4425841358 from xxx state changed: Active -> Accepted (reason: VALID)
2021-02-01 16:32:49 trade: Offer #4425841358 from xxx has been accepted.
2021-02-01 16:32:49 info: Message sent to y (yyy): /me Trade #4425841358 with xxx is accepted. ✅

Summary (offer)
• Asked: 0 keys, 0 ref (nothing)
• Offered: 0 keys, 0 ref (nothing)
──────────────────────

🔑 Key rate: 51 ref/51.11 ref (prices.tf)
💰 Pure stock: 93.22 refs (88 ref, 11 rec, 14 scrap)
🎒 Total items: 449/700
⏱ Time taken: 1 minute

Version 3.0.0-beta
2021-02-01 16:32:49 info: Message sent to z (zzz): /me Trade #4425841358 with xxx is accepted. ✅

Summary (offer)
• Asked: 0 keys, 0 ref (nothing)
• Offered: 0 keys, 0 ref (nothing)
──────────────────────

🔑 Key rate: 51 ref/51.11 ref (prices.tf)
💰 Pure stock: 93.22 refs (88 ref, 11 rec, 14 scrap)
🎒 Total items: 449/700
⏱ Time taken: 1 minute

Version 3.0.0-beta
2021-02-01 16:32:49 info: Message sent to X (xxx): /pre ✅ Success! The offer went through successfully.

Additional context
The trade did contain items on both sides.
Version: 3.0.0-beta, not really latest commit.

Yea, known bug with no clue what caused it.

Investigation result:

i. Trade summary:

ii. Steam Trade History:

iii. Logs result:

iv. polldata.json entry:

Conclusion: Issue with steam-tradeoffer-manager or with Steam.
So, what's the best? To totally ignore the trade to prevent anything bad or just let it be? If we let it proceed, then if someone sent an offer with only our side have something and non on their side and he got lucky because Steam fucked, and your bot will lose everything.

and based on image iii., the itemsToGive and itemsToReceive should never be an empty array.

@idinium96 omg, I thought it was just an issue occurred in summary box. I pretty much sure we should decline "empty" trades since such are not possible to exist.

I against declining the trade. If the trade was valid, if you decline it, then your bot is reportable for declining a valid trade.

We could log such a thing and message the user that their trade has been declined because of Steam's issue.
Also we can gather more opinions in discord.


Added ts-japi to the typescript/javascript implementation list

ts-japi is a highly-modular typescript/javascript-framework agnostic library for serializing data to the JSON:API specification. It is full-featured, meaning all parts of the spec can be realized through this library.
Among other things,

This is the only typescript-compatible library that fully types the JSON:API specification and performs proper serialization.
Zero dependencies.
This is the only library with resource recursion.
The modular framework laid out here highly promotes the specifications intentions:

Using links is no longer obfuscated.
Meta can truly be placed anywhere with possible dependencies laid out visibly.

This library is designed to adhere to the specifications "never remove, only add" policy, so we will remain backwards-compatible.

Great, thanks @jun-sheaf!


[Bug]: error in profile data when area data is missing

Contact Details
No response
What happened?
I forgot to ingest the area data and by visiting my profile page I received an error:
see createAreaOptionFromData.ts:16:26
I expect that the error should be handled even if the app cannot work without area data
What browsers are you seeing the problem on?
No response
Relevant log output
No response

If this is still an Issue it also affects:

[ ] ...the areas of organizations
[ ] ...the areas of events

@phollome
Is this still an issue?

Handle missing ingest

Missing ingest is now handled by the check-diffs script and requests the user to ingest the data via the make commands


add t5 model with FP16 loader

Well assuming I didn't mess it up horribly, it should work now.
I added a dtype selector to the T5 loader node. You might have to re-add the node if it doesn't show up. Also moved the bnb load mode to there.

Is there even an FP16 version available? I tried to convert it myself, but I think I made a mistake along the way.

Alright, I've successfully converted the T5 model to fp16 and it works fine when the node is set to either auto or gpu and fp16. I've uploaded the model here: https://huggingface.co/theunlikely/t5-v1_1-xxl-fp16

@drphero Nice job. I'll grab it to check if it's 1:1 with the original and then add it to the readme.
On that note, I have a bf16 one where I combined the two safetensor files into one that I use for debugging. I can upload it to HF if you (or anyone else) is interested.

I can upload it to HF if you (or anyone else) is interested.

Certainly wouldn't hurt!

@drphero Here it is. I've tested and added both models to the readme. Thanks again!
(closing this as the FP16 loading has been added for a while now, and I'm really hoping I can switch to the official implementation once SD3 is released)


Avoid deleting GH App installation if already deleted

Summary
Fixes #3030
Change Type
Mark the type of change your PR introduces:

[x] Bug fix (resolves an issue without affecting existing features)
[ ] Feature (adds new functionality without breaking changes)
[ ] Breaking change (may impact existing functionalities or require documentation updates)
[ ] Documentation (updates or additions to documentation)
[ ] Refactoring or test improvements (no bug fixes or new functionality)

Testing
Outline how the changes were tested, including steps to reproduce and any relevant configurations.
Attach screenshots if helpful.
Review Checklist:

[x] Reviewed my own code for quality and clarity.
[x] Added comments to complex or tricky code sections.
[ ] Updated any affected documentation.
[ ] Included tests that validate the fix or feature.
[ ] Checked that related changes are merged.

coverage: 48.249% (-0.006%) from 48.255%
when pulling de4bf880bf28c2e49f8d75cc856e2fdabb14d4c2 on eleftherias:delete-provider-installation-not-found
into 6775fca3478871b96fc98c8e38ef90280d6887b9 on stacklok:main.


get_cell_ngrams yields nothing when the mention is not tabular (fix #471)

Description of the problems or issues
Is your pull request related to a problem? Please describe.
See #471.
Does your pull request fix any issue.
Fix #471.
Description of the proposed changes
get_cell_ngrams yields nothing when the mention is not tabular to align with get_col_ngrams.
Test plan
Change the assertion at test_get_cell_ngrams.
Checklist

[ ] I have updated the documentation accordingly.
[x] I have added tests to cover my changes.
[ ] All new and existing tests passed.
[ ] I have updated the CHANGELOG.rst accordingly.

Codecov Report

Merging #504 into master will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #504   +/-   ##
=======================================
  Coverage   85.80%   85.80%
=======================================
  Files          88       88
  Lines        4571     4572    +1
  Branches      855      855
=======================================
+ Hits         3922     3923    +1
  Misses        464      464
  Partials      185      185

Flag
Coverage Δ

#unittests
85.80% <100.00%> (+<0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

src/fonduer/utils/data_model_utils/tabular.py
100.00% <100.00%> (ø)


I feel this domain is wrongly blacklisted (возрождение-ук.рф)

Hello!
I believe that the domain возрождение-ук.рф is mistakenly entered in the database. The subdirectory of the gallery was deleted, the antivirus started complaining about it, although it was not published on the site.

This is because you have the option enabled to block all punycode domains. Please see the below image:


avoid amazon linux

they are slow to upgrade & closed (hard to figure out which kernel we're running for example)
the EC2 api is readily available on ubuntu, though you need to --hint ec2 to tip off Ohai in knife bootstrap

stale?

Yep, we're on debian stretch now across the board.


ReloadDates

I'm not sure if this is working correctly. I'm trying to scroll to a date, and select it (single selection) not by pressing on the date itself but by gesture. I have other logic in the didSelectDate implementation that prevents me from being able to trigger the delegate call.
So I have

calendar.scrollToDate(date)
calendar.selectDates([date], triggerSelectionDelegate: false)
calendar.reloadDates([selectedDate])

where selectedDate is the previously selected date, however it is not reloaded, and remains selected. Any ideas?

Checking this out now.

I am not understanding what you are trying to accomplish.
Just so i understand this.
You want to:

Scroll to a date
Select the date with code
Reload the selected date

And my question is, why?
If your objective is to select a date and scroll to it, then just do

calendar.scrollToDate(date)
calendar.selectDates([date], triggerSelectionDelegate: false)

Maybe if you describe an overview of what you are trying to do, then I can help you more.

I made that more confusing than it needed to be. Basically. I am wanting to scroll to and select a date different than the one already selected. However, with single selection enabled, the previously selected date does not deselect if you have 'triggerSelectedDelegate: false'

This should be working correctly.
Tell you what, I will not look into this because I have a new version being released over the weekend.
I do not see the issue you mentioned occurring in it, so it's possible that the issue is resolved in the new version. Will release it in a couple hours.

New version released. Reopen this issue if it is still occurring


As an EVCM, I want the map to be centered on the US at the right lat/long and at the right bounds/extent, so that I am not confused by non-relevant map regions

Description
We should center on and restrict our map to a relevant region and restrict zoom levels / bounds / extent such that we only highlight the US
Solution
Set center , bounds, and minZoom properties appropriately to avoid showing non-US regions to our users
Describe alternatives you've considered

Allowing users to see the whole world, as things are currently set up (see here ) means that they can get to places outside of the US, and we heard in user testing that this was confusing

Tasks

[ ] Set final center according to US map conventions
[ ] Set final minZoom and maxZoom according to US map conventions
[ ] Set final extent/bounds to the appropriate values according to US map conventions

** Gotchas **

[ ] Need to account for Alaska
[ ] Need to account for other US territories

Definition of "Done"
Users see only the US and cannot zoom outside of it.

This was already done as part of fixes for the latest version of MB


 Component Not Rendering After Signing Out When Component Has Appearance Props Added

Preliminary Checks

[X] I have reviewed the documentation: https://clerk.com/docs

[X] I have searched for existing issues: https://github.com/clerkinc/javascript/issues

[X] I have not already reached out to Clerk support via email or Discord (if you have, no need to open an issue here)

[X] This issue is not a question, general help request, or anything other than a bug report directly related to Clerk. Please ask questions in our Discord community: https://clerk.com/discord.

Reproduction / Replay Link
https://github.com/brettabamonte/Clerk-Minimal_Reproduction-SignIn_Component/tree/main
Publishable key
pk_test_Y2hpZWYtc2N1bHBpbi0xMi5jbGVyay5hY2NvdW50cy5kZXYk
Description

Steps to reproduce:
See steps and screenshots in linked git repository README.md (https://github.com/brettabamonte/Clerk-Minimal_Reproduction-SignIn_Component).
Expected behavior:
After clicking the  the user should be redirected to the sign in page with a  component displaying that has appearance props.
Actual behavior:
After clicking the  the user is redirected to the sign in page but the  component does not render when it has the appearance prop set. If the appearance prop is set the component displays properly.
Environment
System:
    OS: macOS 14.0
    CPU: (8) arm64 Apple M2
    Memory: 238.50 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.18.1 - /usr/local/bin/node
    npm: 9.8.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 118.0.5993.117
    Safari: 17.0
  npmPackages:
    @clerk/nextjs: ^4.26.1 => 4.26.1
    @types/node: 20.1.4 => 20.1.4
    @types/react: 18.2.6 => 18.2.6
    @types/react-dom: 18.2.4 => 18.2.4
    autoprefixer: 10.4.14 => 10.4.14
    classnames: ^2.3.2 => 2.3.2
    next: ^14.0.0 => 14.0.0
    postcss: 8.4.23 => 8.4.23
    react: 18.2.0 => 18.2.0
    react-dom: 18.2.0 => 18.2.0
    tailwindcss: 3.3.2 => 3.3.2
    typescript: 5.0.4 => 5.0.4

I have an issue that sounds very similar, but with the <UserButton />. After signing out, and signing back in, it renders at size 0x0.
Not sure if it's related or not, but the browser console is showing a couple of errors related to signin. The stack trace is to a packed vendors file, so the line numbers probably aren't relevant, but the error is "Uncaught TypeError: Cannot read properties of undefined (reading 'imageUrl')" and the line of code sets avatarUrl with .userData.imageUrl.

I can confirm this also happens on @clerk/nextjs: 4.27.1/next: 14.0.2. However, it happens for us independently of the use of the appearance prop

Hello all!
Just a short update here to show that I/we haven't forgotten this issue 😅 Thanks for the reproduction, I was able to also see the issue. Important bit: This also happens without the appearance prop.
After investigating I'm still not sure exactly what is causing it, might be a race condition or an issue with client side re-hydration.
We'll discuss internally a bit how we want to tackle this but I'd be interested in your opinion on this question (@brettabamonte @tjl-jg @IGassmann):
What is your expected behavior for the <SignOutButton /> as to where it should navigate?
Should it stay on the same page? Navigate to the sign in page? Navigate to a custom page one has to define?

@LekoArts I agree with @tjl-jg. I like the context to be within the component using a property. Having a default destination is nice if the property isn't declared on the component. 90% of the time, I like redirecting users to a default page like the sign in page but there are instances where it'd be nice to redirect them to a custom destination.
Thank you and the team for looking into this!

Thanks for your input!
Then you can unblock yourself by using the signOutCallback prop on the <SignOutButton /> component:
"use client"

import { useRouter } from "next/navigation"
import { SignOutButton } from "@clerk/nextjs";

export const Signout = () => {
  const router = useRouter()

  return (
    <SignOutButton signOutCallback={() => router.push('/your-path')}>
      <button>Sign Out</button>
    </SignOutButton>
  )
}

Or if you want to stay on the same page, a hard refresh will do (in the meantime):
"use client"

import { SignOutButton } from "@clerk/nextjs";

export const Signout = () => {
  return (
    <SignOutButton signOutCallback={() => window.location.reload()}>
      <button>Sign Out</button>
    </SignOutButton>
  )
}

@brettabamonte What your reproduction shows is in some sense "expected" behavior that is described in this thread here. The blank page shows because it shows the unauthenticated state of the /dashboard route which will be empty. The behavior you want kicks in because the middleware redirects to the sign-in page because /dashboard is not a public route.
With the callback prop above you can reliably do whatever you want after the signout 👍
We'll still look into the underlying issue and see if we'd need to change something DX-wise.

I have the same problem as @tjl-jg. Here is a minimal reproduction by the way: https://github.com/Sengulair/clerk-nextjs-app-issue/commit/f7a29db4ce18ac149714b72f91afff578ddeb677
It still appears on the 5.0.1 version. Do we have some workaround for that case?

@Sengulair mind giving this another try with 5.0.4

@panteliselef I've updated the reproduction to 5.0.4. Still failing with the same errors

@panteliselef I've updated the reproduction to 5.0.4. Still failing with the same errors

@panteliselef Tested with 5.0.6 and seems the problem is resolved.

Closing this as it seems resolved. @brettabamonte If the issue persists after using a version >= 5.0.6, feel free to re-open the issue.


PlayerSelector.NONE make current playing video paused when recyclerView scroll

In your BasicListActivity, I just set the PlayerSelector to NONE and manually play/pause the video with the click on ViewHolder. However, when the recyclerView finish scroll (just a little bit, to make sure that the current playing video is fully visible), the player pause automatically.
Could you please tell me how to fix this issue ? I just want to only play video by click on it. Thanks a lot.
Here is the demo video: https://www.youtube.com/watch?v=pNnxtHNzAaw

@vtproduction Currently manually start/pause the Player will not talking to Container. Which means that once you set the selector to "NONE", every Scroll will end up pausing all Players (which is expected). If you need something complicated, you may need a customized selector.

@eneim can you give me some instruction to customize it ?

@vtproduction Hi, this is not trivial, but can be done with the following steps:

I assume that you are using SimpleExoPlayerView (SEPV), because my tutorial below base on that. Using other Widget needs your own work.

You need to intercept in the manual play/pause trigger (i.e User click to play/pause from SEPV). To do this, you can use this method from SEPV (which in turn asks the PlaybackControlView to set its Dispatcher).

1'. Record the event of User clicking play/pause button. This is done by customizing the ControlDispatcher you set above, adding your own logic to remember the Item that is triggered. See my demo code below:
// Prepare the default Dispatcher.
ControlDispatcher dispatcher = PlaybackControlView.DEFAULT_CONTROL_DISPATCHER;

// TODO: Put the following into onBindViewHolder(). playerView is the SimpleExoPlayerView instance.
// adapter = the Adapter that is binding this ViewHolder.
playerView.setControlDispatcher(new ControlDispatcher() {
        @Override public boolean dispatchSetPlayWhenReady(Player player, boolean playWhenReady) {
          boolean dispatched = dispatcher.dispatchSetPlayWhenReady(player, playWhenReady);
          if (dispatched) {
              adapter.manualItem.set(getPlayerOrder());
              if (!playWhenReady) adapter.manualItem.set(-1); // User is pausing, so clear the manual one.
          }
          return dispatched;
        }

        @Override public boolean dispatchSeekTo(Player player, int windowIndex, long positionMs) {
          return dispatcher.dispatchSeekTo(player, windowIndex, positionMs);
        }

        @Override public boolean dispatchSetRepeatMode(Player player, int repeatMode) {
          return dispatcher.dispatchSetRepeatMode(player, repeatMode);
        }
      });

The setup is done when you bind data to your ViewHolder (which is a ToroPlayer of course). Here I have a field "manualItem" in the Adapter which is an AtomicInteger to save the manual player order (= adapter position). (You can use a simple int of course). This value must be negative by default (because be default there is no item triggered yet). I set it to -1 by default.
The dispatchSetPlayWhenReady is called when User click to the play/pause button. I have a default dispatcher as the delegate object. Make sure you catch the boolean value returned from it, because when dispatcher's method returns false, it means that the dispatcher didn't do anything.

Custom the Selector so that: it behaves as PlayerSelector.NONE for all players, but allows the one that is manually triggered to act by itself. The customization can be done using some other tricks, below is one of my demo:

// 1. We can use a Filter to pick the one that is manually triggered. Make sure the player wants to play too.
final Container.Filter manualPlay =
        player -> player.wantsToPlay() && player.getPlayerOrder() == adapter.manualItem.get();

// 2. Create a selector which can select only the one that is manually triggered.
PlayerSelector  selector = new PlayerSelector() {
      @NonNull @Override public Collection<ToroPlayer> select(@NonNull Container container,
          @NonNull List<ToroPlayer> items) {
        return container.filterBy(manualPlay); // This is where magic happens.
      }

      @NonNull @Override public PlayerSelector reverse() {
        return this;
      }
    };

    container.setPlayerSelector(selector); // Apply the customized NONE Selector.

Please try my suggestion above and tell me if it helps. I will push a demo reproducing this to master soon.

@eneim Thank you so much!  I will follow your steps and tell you soon.
'Cám ơn rất nhiều'

@eneim Your solution basically worked. Thanks again !

@maxbaldrighi Which version of ExoPlayer/Toro you are using. I will look into the code and see what happens.

I was using the 3.5.2 version. Now I've just updated version.
Anyways, I couldn't write you before, but I basically managed to fully understand your steps.
Just to have your confirmation: the method call to intercept in SEPV you were referring to was about to manually dispatch the PLAY and PAUSE key events as the user used the controller, right?
Because, I managed to block the unwanted onScrollChanged trigger, but now I'm struggling because I don't want to use the player's controller.
I'm trying to find a way to subclass PlayerView and be able to use the controller 's events without being forced to use the property useController, which unfortunately forces the controller's visibility to VISIBLE if true.

Hello @eneim, just a quick update.
So, in the end yesterday I managed to solve the controller visibility issue (and I'm gonna post later my solution for anyone who may need it).
I noticed, though, one thing of more pressing concern for this library: the whole thing seems to work perfectly with Toro 3.5.2, but NOT with the latest release.
I didn't have the chance to debug attentively what's happening, though. I hope to be able to do that during the weekend and to give you a more accurate report.

@maxbaldrighi Thanks so much for your information. It is definitely something wrong. I will find time to double check this.

As I promised, I'm gonna start with pasting my solution for using the manual controls without using the player's controller.
Subclassing PlayerView, I just overrode this method:
override fun dispatchMediaKeyEvent(event: KeyEvent?): Boolean {
    useController = true
    val bool = super.dispatchMediaKeyEvent(event)
    useController = false
    return bool
}

and used this line app:use_controller="false" in the xml file.
Doing so, I enable the useController property, just to make sure that the default tests based on useController property pass, and the disabling it again.
From what I saw, it seems to work fine.

I finally had the time to properly debug.
During helper initialization, ExoPlayerViewHelper.prepare(boolean) gets called with false passed as argument. Then ExoPlayable.prepare(boolean) -> PlayableImpl.prepare(boolean)
Here lies the "problem" emerged because of the different implementation between the two versions of toro of PlayableImpl.prepare(boolean):
3.5.2: no matter what value prepareSource argument carries player property is always initialized.
@CallSuper @Override public void prepare(boolean prepareSource) {
    if (player == null) {
        player = with(checkNotNull(creator.getContext(), "ExoCreator has no Context")).requestPlayer(creator);
        if (player instanceof ToroExoPlayer && volumeChangeListeners != null) {
            for (ToroPlayer.OnVolumeChangeListener listener : volumeChangeListeners) {
                ((ToroExoPlayer) player).addOnVolumeChangeListener(listener);
            }
        }
    }
    ...
}

<IP_ADDRESS>02: if prepareSource==false, player property is not initialized, because the instantiation has been moved inside ensureMediaSource().
@CallSuper @Override public void prepare(boolean prepareSource) {
    if (prepareSource) {
        ensureMediaSource();
        ensurePlayerView();
    }
}

So this means that if player==null, the methods PlayerView.switchTargetView(Player, PlayerView, PlayerView) and PlayerControlView.setPlayer(Player) carry around a null player instance, until the call to PlayerControlView.dispatchMediaKeyEvent() returns with no action performed because the test if (player == null || ...) { ... } fails.
Hope I explained everything clearly.
Any suggestions will be much appreciated!

@maxbaldrighi Thanks so much for your investigation. The change in "when Player instance is created" is a correct found. And at the time I wrote it, it is by intended. The reason is: the flag in "prepare" method suggests client that it can initialize playback resource lazily, which save some frame from dropping. This was half done in 3.5.2, the Player instance is created there, which in turns, init other resources like Renderers. Case by case, this take up to 20ms which will produce bad UX in first scroll. As a result, I also make the Player initialization to be lazy as well, and just create it for the first time when it is requested.
The reason above, doesn't take into account what you found today. I will think about this scenario carefully and will reply here as soon as I have some idea.

Perfect, thanks!
Looking forward to it!
On Sun, Oct 28, 2018 at 8:10 PM Nam Nguyen Hoai<EMAIL_ADDRESS>wrote:

@maxbaldrighi https://github.com/maxbaldrighi Thanks so much for your
investigation. The change in "when Player instance is created" is a correct
found. And at the time I wrote it, it is by intended. The reason is: the
flag in "prepare" method suggests client that it can initialize playback
resource lazily, which save some frame from dropping. This was half done in
3.5.2, the Player instance is created there, which in turns, init other
resources like Renderers. Case by case, this take up to 20ms which will
produce bad UX in first scroll. As a result, I also make the Player
initialization to be lazy as well, and just create it for the first time
when it is requested.
The reason above, doesn't take into account what you found today. I will
think about this scenario carefully and will reply here as soon as I have
some idea.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/eneim/toro/issues/263#issuecomment-433755531, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ALMDOLZWGp9AFh8yxhJF0QNS8BHy6Xw8ks5upkd_gaJpZM4QSIUR
.

Hello @eneim !
Any ETA about the issue we were talking about a few weeks ago?
Or do you have any temporary workaround in mind?
Thanks in advance!

Hi @maxbaldrighi , sorry for the wait. Can you try the <IP_ADDRESS>01-SNAPSHOT and see if it helps. In this update I change some internal mechanism that include the place where ExoPlayer instance is created. This way, the Dispatcher will be dispatched correctly.
Please follow this code link to start using this new mechanism. (Underline classes are all updated, so I need some time to document them out as a proper changelog, and further performance test).
This requires ExoPlayer 2.9.1, so let me know if it doesn't work for you.

Thank you very much for your hard work.
I am very busy at work, right now, but as soon as I can try it, I will
report the results to you!
Massimo
On Sat, Nov 24, 2018 at 8:43 AM Nam Nguyen Hoai<EMAIL_ADDRESS>wrote:

Hi @maxbaldrighi https://github.com/maxbaldrighi , sorry for the wait.
Can you try the <IP_ADDRESS>01-SNAPSHOT and see if it helps. In this update I
change some internal mechanism that include the place where ExoPlayer
instance is created. This way, the Dispatcher will be dispatched correctly.
Please follow this code link
https://github.com/eneim/toro/blob/nam/v3/370-r2901/app/src/main/java/im/ene/toro/sample/basic/BasicPlayerViewHolder.java#L78
to start using this new mechanism. (Underline classes are all updated, so I
need some time to document them out as a proper changelog, and further
performance test).
This requires ExoPlayer 2.9.1, so let me know if it doesn't work for you.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/eneim/toro/issues/263#issuecomment-441368814, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ALMDOHmpXSrFLrxQ3kLdytHE4vW6wLYJks5uyUzngaJpZM4QSIUR
.

@maxbaldrighi Can you post the solution to this issue if you found it. Thanks in advance.


[FLINK-1579] Implement History Server

This PR adds a slightly unpolished HistoryServer implementation. It is missing tests and some documentation, but is working.
This PR builds on top of #3377.
The basic idea is as follows:
The MemoryArchivist, upon receiving an ExecutionGraph, writes a set of json files into a directory structure resembling the REST API using the features introduced in FLINK-5870, FLINK-5852 and FLINK-5941. The target location is configurable using job-manager.archive.dir. Each job resides in it's own directory, using the job ID as the directory name. As such, each archive is consistent on it's own and multiple jobmanagers may use the same archive dir.
The HistoryServer polls certain directories, configured via historyserver.archive.dirs, in regular intervals, configured via historyserver.refresh-interval, for new job archives. If a new archive is found it is downloaded and integrated into a cache of job archives in the local file system, configurable using historyserver.web.dir. These files are served to a slightly modified WebFrontend using the HistoryServerStaticFileServerHandler.
In the end the HistoryServer is little more than an aggregator and archive viewer.
None of the directory configuration options have defaults; as it stands the entire feature is opt-in.
Should a file that the WebFrontend requests be missing a separate fetch routine kicks in which attempts to fetch the missing file. This is primarily aimed at eventually-consistent file-systems.
The HistoryServer is started using the new historyserver.sh script, which works similarly to job- or taskmanager scripts: ./bin/historyserver.sh [start|stop]
2 bigger refactorings were made to existing code to increase the amount of shared code:

the netty setup in the WebRuntimeMonitor was moved into a separate NettySetup class which the HistoryServer can use as well
an AbstractStaticFileServerHandler was added which the (HistoryServer)StaticFileServerHandler extend

@uce I've addressed a few of your comments (all that i gave a Thumbs up)
I will implement that we write out only 1 file instead of multiple ones; this removes plenty of edge cases and makes the JobFileFetcher irrelevant.

@uce I've addressed the remaining comments. Still undecided on the handler re-use; tests/documentation still missing.

@uce I've addressed most of your comments. Missing is some javadocs, renaming of the web-ui, bounding the size of the map in the ArchiveFetcher.

@uce I've addressed your remaining comments.

@uce I've finishes writing the remaining tests.

@uce I've added the documentation for the HistoryServer. It's integrated into the "Monitoring REST API" page since it is so closely related.

Tests passed here https://travis-ci.org/uce/flink/builds/213339988
Merging! :+1:

Looks like the PR wasn't closed as part of the merging?

According to GitHub this wasnt merged yet.

Yeah, true.

My push must have been rejected without me noticing. Sorry! I'm rerunning the tests after rebasing and pushing it.


Tpu infeed

Completed support for TPU infeed. The main change involves adding the shape array
pseudo-attr to a promoted scalar that's received from the host (on TF CPU), so
that when we send that scalar tensor from TF CPU to TPU via TensorTransfer, we
know its shape.
Also extended the compiler unit test testSendsInALoopTPU() to highlight a
redundant send from TF TPU to CPU, due to the current invariant that all BB args
must be replicated/present in all devices. That will be optimized away via data
flow analysis as a next step.

@swift-ci please test tensorflow

This change has been reviewed by Chris and Richard.

Feel free to land things like this that have already been approved (once CI succeeds).

@swift-ci please test tensorflow

sounds good!

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please test tensorflow

Richard's invocation of CI probably killed the previous on-going one: https://ci-external.swift.org/job/swift-PR-TensorFlow-Linux/181/ :)
the new one did not show failure at https://ci-external.swift.org/job/swift-PR-TensorFlow-Linux/182/, but on this page it showed failure. That's odd. I'll trigger CI again.

@swift-ci please test tensorflow

@swift-ci please test tensorflow

Oops. I saw no CI running so I tried to trigger it again.

@swift-ci please test tensorflow

@swift-ci please test tensorflow